4 Aug
2008
4 Aug
'08
1:21 p.m.
Tony Duell wrote:
This is not a $deity-given requirement. For example, after a reset, the
CPU could 3-state the address bus, assert an extra output pin (or assert
a normally-unused combination of pins, for example Rd and Wr asserted at
the same time), and then read in the location to start executing from on
the address pins. I know of no commericla processor which did it this
way, but it's certainly possible. Whether it's a sensible thing to do is
another matter.
Today I would agree, but when the 8086 was designed, CPU real estate was
very expensive, and I seriously doubt such a "fluff" feature would have
made it to tapeout.
I wasn't aware that this was a requirement of C,
or any other language.
If someone deferenced (void*)0, most systems like to return something
(or preferably, trap the access and throw an exception). If you deref
NULL, I think many implementations return 0.
No it doesn't, given that a PDP11 address to a
program is always 16 bits.
The 18 or 22 bit phuysicall addresses were created by the MMU.
Did an MMU exist for the 8086?
The issue here was witht he 80286 .vs. the 8086. Not the 8080. It was
clear the 8088 had sold very well (IBM and all that :-)), it was likely
the 80286 would sell well as well.
I'm not sure I follow. I thought you argued moving the vectors to
$ffff:0000 was bad, but I believe that was done on the 8086. By the
time the 286 was designed, backwards compatibility mandated the reset
vectors stay in the same place, even though that was no longer top of RAM.
I still think such a position is too hard on the designer. I'll take
the unnamed person's defense. I don't know that I can argue the IRQ
concern, but I'll look into it. I can definitely see the vector mod
fixing an issue:
"8086 Designer, come here"
"yes?"
"OK, we have all these 8080 users yelling at us because they want to
start RAM at $0, and we require the vector go there."
"yes, we assume there should be ROM at 0, followed by RAM"
"Well, their designs work best if RAM starts low (zpage and all) and ROM
goes up high"
"Uh, OK, so we didn't understand the use case well enough"
"Fix it in the 8086!"
"How, we're committed to backwards compatibility"
"Put them at top of memory map"
"But, if we ever support more RAM, we'll have to move them"
"Not a problem. DO it."
"Compatibility issues!"
"Do IT NOW! The CPU users detest having to perform trickery to get the
jmp call into the CPU on reset. It's a kludge, and the Industry wants
RAM low"
Later, I can then see management reneging on the promise to move the
vectors.