Xref: utzoo comp.unix.xenix:3711 comp.unix.questions:9868 comp.unix.microport:1842 comp.sys.ibm.pc:20484 Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!haven!purdue!decwrl!pyramid!nsc!datack!altnet!ernie!koll From: koll@ernie.NECAM.COM (Michael Goldman) Newsgroups: comp.unix.xenix,comp.unix.questions,comp.unix.microport,comp.sys.ibm.pc Subject: Re: *nix performance Summary: DMA, Interrupts, Re-entrancy, 80386 vs 8086 vs 68K Message-ID: <170@ernie.NECAM.COM> Date: 21 Oct 88 16:49:19 GMT References: <9902@ico.ISC.COM> <736@starfish.Convergent.COM> <1901@van-bc.UUCP> <1279@umbc3.UMD.EDU> Distribution: na Organization: NEC America RATS, San Jose, CA Lines: 78 This is a reply to points Brian Cuthrie made on my reply to some questions about DMA. We seem to have a different background - I'm more software and you seem to be more hardware-oriented. I yield (in general) to your hardware knowledge so perhaps you can educate me out of some ideas I have picked up over the years. Points in order: 1. I have seen 80386's advertised at 25 MHz so I don't know why you underscore that with a question ? Since they are all non-IBM clones, I have presumed they used the basic AT motherboard with the same DMA chip from 1981, which I have been told by someone who makes PC I/O boards (designs and builds) for a living have never been built for over 5 MHz since the design isn't worth continuing. 2. My understanding of why I as a software engineer use DMA is that they are useful to make I/O a non-blocking process. Eg, I want to dump some stuff to tape but I don't want to halt my program to wait for it to complete. So, I set up the DMA to some memory-mapped I/O board and then go on with other processing. The DMA process takes EVERY OTHER CYCLE ( which the cpu often can't use) while the cpu continues on with other work. When the I/O board's buffer is full, it refuses further DMA transfers (or else I've set up the DMA to transfer only N bytes, depending on the architecture). The DMA chip generates an interrupt informing me that the transfer is completed and I either restart it if I want more transfers, or do something based on my knowledge that my I/O is done. In practice, one program usually has to block on I/O anyway so that is a good time for the OS (like UNIX) to suspend it and give the cpu to another program while the DMA runs on EVERY OTHER CYCLE. The way one does this is usually based on interrupts from the DMA or I/O board. 3. My understanding of the reason DMA isn't used much on the PC is that to get pass-through mode going on the PC's DMA requires that it do one read, transfer the byte to it's internal write buffer, and then write it to memory. Thus 2 cycles which is why I said the string moves were as fast, since the 8088 cpu has internal look-ahead cache of several bytes and so can overlap read and write somewhat. Since the I/O pins are multiplexed this may not mean much in practice. 4. We have some confusion about the word re-entrancy. My definition of it applies only to programs, not to individual hardware instructions. Here's an example of what I mean. A utility (say a terminal I/O routine) is used by a lot of other programs. Rather than make a copy of it for each user, or block all users but one from using it at a time, the utility is made re-entrant. That is program A enters it, writes a byte to a terminal and while it is waiting for the byte to go out the port, the OS allows program B to enter the utility. Obviously, B can't be allowed to trash the registers, I/O address, etc., of A, so the utility (or OS) saves the state of A in some buffer, allows B to process long enough to do something useful (based on time, or I/O) and then saves B's registers, etc., restoring A's registers etc., to allow A to continue sending, or receiving. The reason interrupts figure in all this is that usually (but not necessarily) this re-entrancy is provided at intervals signaled by a clock interrupt, or an I/O interrupt. DOS was not written to provide re-entrancy, so to provide it oneself, one must save the surrent segment registers in a very precise and careful way, reset the stack and other segment registers in an equally careful way (the DOS stack will only work for you 95% of the time) and then reverse the process upon exiting. The first time I did this, it took me many late night weeks, but after the first time it takes a day at worst. 5. The 8086 came out the same year as the 68000. Both companies had the same technologies to work with but Motorola chose a linear address space, and general purpose address and data registers. Programs written for the 68000 can run on a 68030 without change or impingeing on a program designed for a 68030. To run an 8086 program on an 80286 (which does not have a linear address space) requires major effort and you can only run one 8086 program with 80286 programs running in protected mode. Motorola had to implement some hardware instructions in software traps for a little while, but a software engineer didn't have to worry about it and life was good and stayed good. The 80286 was Intel's idea of what to do next which shows that they hadn't picked up on the linear address space and general purpose registers until later. there's usually a trade-off in micro-code between time and space, so they might have tried for more cycles but cleaner instruction set. Regards, Michael Goldman