Path: utzoo!attcan!uunet!munnari!otc!metro!ipso!runx!brucee From: brucee@runx.ips.oz (Bruce Evans) Newsgroups: comp.os.minix Subject: Re: klib88.s strangenesses Message-ID: <1825@runx.ips.oz> Date: 15 Nov 88 20:14:22 GMT References: Reply-To: brucee@runx.OZ (Bruce Evans) Organization: RUNX Un*x Timeshare. Sydney, Australia. Lines: 42 Vincent Broman writes: >1. em_xfer() does a PUSHF and an INT 0x15 around line 696, although >the procedure comments explain why the INT is impossible and must The comments are out of date. A normal consequence of redundant comments. I reverted to the call method since 0x15 is nominally reserved by Intel and got lost when I cleaned up 0x8 to 0x16 which are all used by the 386 (except 0x15!). This should be done for 286's too. >2. The rebooting code tests (ps == -1) when ps is either uninitialized >or set equal to 1 in kernel/main.c . Can this be right? Yes, test picks up the 1 and the other bits aren't used. >3. Does anyone know why the table used by em_xfer() sits in >the text segment? It should be in the data segment. The BIOS pointer is ES:SI. Using the code seg keeps the routine together for easier editing, but a .data and a .text would do this better. >4. Why was build_sig() written in assembler instead of C? There really is a reason. Notice that struct sig_info is _exactly_ the same as the stuff to be pushed, so build_sig() can not only be done in C, it can be eliminated. But this presupposes lots about how the compiler packs data into the struct (alignment etc). Since there are other processor-specific things done in C, the extra portability is hardly worth it. There is a reason not to to use a struct assignment to replace build_sig() - cc produces hideous code, about 50 static instructions and 40 instructions/byte, even in 1.3. >5. Was it just an oversight that segment:offset pairs are always >passed as arguments in the order (segment, offset), whereas the 8088 >hardware expects far pointers to be (offset, segment)? Switching The argument order must have been decided by someone who didn't know much about 8088 assembler. The wrong order is normal in DOS compilers' libraries too. Of course the other order is better. I changed cp_mess() to do it right. There is only a little extra performance, but there is a principle involved.