Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!nosc!trout.nosc.mil!broman From: broman@schroeder.nosc.mil (Vincent Broman) Newsgroups: comp.os.minix Subject: klib88.s strangenesses Message-ID: Date: 8 Nov 88 02:06:17 GMT Sender: nobody@nosc.NOSC.MIL Reply-To: broman@nosc.mil Organization: none Lines: 29 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