CompuServe Messages

Generally the theoretic limit on addressing memory is based on the number of physical pins coming out of the CPU chip. Each pin sends a 1 or 0 bit at a time. The 386 chip can address, I think, about 4 terabytes of memory. Of course, no one can get that much in their PC, yet, but that's why the 486 chip is a 386 CPU with a cache and math coprocessor included. There really was no reason to make a chip with more pins that would increase the potential address space. (The additional functions require pins, too, I think, but the extra pins don't address memory.) The 586 (GASP! I mean the *Pentium* {hear the heavenly chimes?}) is still a 386 CPU with additional functions included in the chip. This reduces the time delay of the other functions by integrating all into the one chip. The problems with the 8086 and the 286 had to do with the number of pins, mostly. The whole REGISTER:OFFSET addressing scheme was devised to try to get around this limitation (and is the reason there's HMA for DOS or some ONE program to reside in. Set the register to the last 8 (or is it 16)K of addressable memory and then bump up the offset and you end up scootching yourself past the 1024 limit. Regrettably, we still have to accomodate the REGISTER:OFFSET scheme to be backward compatible and this is one reason it's hard to exploit the 386 and better processors. The other reason, of course is because DOS has built into it the hardware addressing between 640K and 1024K. Those addresses interrupt the contiguousness (is that a word?) of memory and so a big program can't be contiguous from "conventional" memory on up. Instead of all these multitasking (and, presently, slow) operating systems/environments people are working on, I wish someone would just tweak DOS to remap its hardware down to the bottom of memory and give us a DOS-fast, clean, but [continued in the reply]