At 05:38 AM 6/14/96 -0700, anonymous-remailer@shell.portal.com wrote:

at Thu, 13 Jun 1996 11:30:44 -0800 jim bell <jimbell@pacifier.com> may have written...

...

Brain-dead segmented architecture, 64k per segment limitation code segments, ever hear of code segments? Data segments maybe?

There is nothing wrong, conceptually, with _software_ segments... In fact, even hardware segmentation is okay _IF_ the maximum size of those segments will NEVER (in the computer architecture's entire lifetime, and that includes later compatible CPU's) be challenged by the largest program and data to be run on that machine. But a 64K byte segment size is truly and astoundingly bad design, even for 1976. Even a 2**24 byte (16 megabytes) segment size would have turned into a wall a few years ago. A 2**32 byte (4 gigabyte) limit would not be a problem for at least 10 more years.

Ever actually do any 8086 assembler?

A minimal amount, fortunately. Liked 8080 and Z-80 far better. (Not that I think their limited address space is "better," merely that their design matched their intended uses far better.)

You would have liked them. In fact, even the MAC's O/S had them built in as I recall, just not a hardware limitation with the 68000. A good programmer was not limited by these.

...

1-megabyte memory limitation. The only thing that made it OK, I concede here... But if you actually write code instead of pasting code together, 1MB is plenty of RAM with this processor.

It's still a problem. I just ran Microsoft Windows Anti-virus a few days ago, on a 1.6 gigabyte hard drive, and it said I was "out of conventional RAM." (Not because of "too much code," but because of too much data.) With 16 megabytes of DRAM, total, that's a laugh! Try explaining this problem to a person who doesn't understand the distinction between "conventional" and extended memory. They will have no idea that a stupid design decision made in 1976 caused a problem in 1996. Most people don't understand the WHY behind that idiotic 1 megabyte limitation, and how it could so easily have been fixed. As I understand it, when they were designing the 8086 the maximum-size package that Intel dealt with was a 40-pin ceramic package. Well, look at the pinout of an 8086 and you'll see the problem: Even with address/data multiplexing, you simply can't get more than 20 address bits out of a 40-pin package and keep the necessary control and power lines. That's a limitation, and that's bad, but it turns out they made a bad design worse. The best fix would have been to get a 44 or 48 pin package,(as, for example, the Z-8000 did) and dedicate at least 4 more bits to the address, which would have been a limitation of 16 megabytes, or 8 more, which would have been 256 megabytes. But the Intel packaging people were apparently given a veto on the whole thing, and they stayed with a 40-pin package. But here's how they made it worse: In the 8086 architecture, there are two 16-bit registers added together (with a 4-bit offset) to form a 20-bit address. Even if the designers were forced to accept that the initial implementation of the 8086 would only have a 40-pin package, at the very least they could have changed the segment offset to 8 bits or even 12 bits, which would have formed a 24 or 28-bit address internal to the 8086, of which only the lower 20 bits could be available. Any computers built with this specific chip would be limited to a physical 1-megabyte memory space, HOWEVER future implementations of this architecture (for instance, the equivalent of the 80286) would have more address lines. More RAM could be installed in them. So far, that sounds just like the 80286, right? Wrong. (The '286 can only access memory space above 1 megabyte by shifting to "protected mode," which is incompatible with DOS.) Unlike the way it actually was with the 8086 vs. the 80286, the software would be compatible, because the segment addressing would have been identical, and their would no longer be any sort of physical 1-meg limitation remaining. In other words, there would be no residual conventional memory limitation, and "we'd all live happily ever after." (True, programmers would eventually write programs which exceed the memory capacity of the 8086, but that would not have affected newer computers.) Somehow, I think if you could corner one of the 8086 designers, ideally with a 12-gauge shotgun, he'd say, "Doh! We didn't think of that!" That's right, they didn't think of that, because they _JUST_DIDN'T_THINK!_ And over 200 _BILLION_ dollars of money has been spent on computers limited by a brain-damaged architecture, when they could just as easily have avoided the problem back in 1976 with a trivial fix. The one conceivable defense that Intel could muster would be, "We didn't anticipate this. We didn't intend for the 8086 to be used as a general-purpose computer." True or not in 1976, that defense was not available to IBM in 1980: They were fully aware of the problem, and they knew about the 68000, and yet they chose the 8088 anyway. The same short-sighted pig-headedness that would later be demonstrated by Bill Gates when he said something like "Nobody will ever need more than 640 kilobytes of RAM" was shown by Intel people in the middle 1970's.

What was brain dead was the fact that IBM in it's infinite wisdom "stole" near half of that for it's poor hardware designs (640k-1MB range).

IBM did add to the problem, true, but they "only" cut down the address space to 640 from 1 megabyte. Even 1 megabytes would have been an intolerable limitation. Had Intel allowed a logical address space of 256 megabytes or even 16 megabytes, the loss of 380 kilobytes would not have been particularly limiting. Believe me, I'm not defending IBM, they're both guilty of gross stupidity.

Joseph L. (Joe) Moll, Greenville, SC USA mailto:oolid@acqic.org

Jim Bell jimbell@pacifier.com