broman@schroeder.nosc.mil (Vincent Broman) (11/08/88)
While converting the v1.3 klib88.s into a Turbo-C klib88.c, I came upon some mysteries that someone may be able to explain. 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 be simulated with a long jump. Perhaps we do not have the code really used to compile the AT configuration? 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? 3. Does anyone know why the table used by em_xfer() sits in the text segment? 4. Why was build_sig() written in assembler instead of C? Since the type of struct sig_info is available in kernel/type.h, the routine amounts to just a few lines of simple, portable C. Moreover, writing sizeof( struct sig_info) seems a better idea than using SIG_PUSH_BYTES in several places. 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 order of arguments in the routines: cp_mess, dma_read, dma_write, vid_copy, src_up, src_down, and get_byte would allow the use of faster and more natural LES and LDS instructions and the use of "far pointers" in cross-compiled code? Vincent Broman, code 632, Naval Ocean Systems Center, San Diego, CA 92152, USA Phone: +1 619 553 1641 Internet: broman@nosc.mil Uucp: sdcsvax!nosc!broman
ast@cs.vu.nl (Andy Tanenbaum) (11/09/88)
In article <BROMAN.88Nov8110617@schroeder.nosc.mil> broman@nosc.mil writes: >While converting the v1.3 klib88.s into a Turbo-C klib88.c, I came upon some >mysteries that someone may be able to explain. > >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 >be simulated with a long jump. Perhaps we do not have the code >really used to compile the AT configuration? I didn't write this code, but it definitely is the real code. >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? See above. >3. Does anyone know why the table used by em_xfer() sits in >the text segment? See #2. >4. Why was build_sig() written in assembler instead of C? Historical reasons. In an earlier life assembler was needed. >5. Was it just an oversight that segment:offset pairs are always >passed as arguments in the order (segment, offset). In essence, yes. Probably should be fixed, except that it had better be fixed everywhere of bad things happen. Andy Tanenbaum (ast@cs.vu.nl)
ZQ0018%DMSWWU1A.BITNET@cunyvm.cuny.edu (Kai Henningsen) (11/11/88)
In his article , Andy Tannenbaum <ast@cs.vu.nl> writes: >In article <BROMAN.88Nov8110617@schroeder.nosc.mil> broman@nosc.mil writes: >>While converting the v1.3 klib88.s into a Turbo-C klib88.c, I came upon some >>mysteries that someone may be able to explain. (...) >>5. Was it just an oversight that segment:offset pairs are always >>passed as arguments in the order (segment, offset). >In essence, yes. Probably should be fixed, except that it had better be >fixed everywhere of bad things happen. > >Andy Tanenbaum (ast@cs.vu.nl) Consider doing a (maybe slight) name change also, then everybody *should* notice it (even if by an asld error msg). Kai Henningsen zq0018 @ dmswwu1a . bitnet (Or what is YOUR path?)
brucee@runx.ips.oz (Bruce Evans) (11/16/88)
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.