segmented memory models
ard at p850ug1.demon.co.uk
Mon Aug 4 13:54:25 CDT 2008
> Tony Duell wrote:
> > And IMHO one common expression of 'brain damage' is when the design
> > omitted to ccosider soemthing that later became a major issue.
> Do you design for a living? If so, then my hat is off to you for
Alas, as is well known, I don't design for a living. I wish I did...
However, I have done so in the past.
I am also not arrogant enough to suggest that my designs were ever
perfect. I am quite sure I've made my fair share of brain-dead decisions.
> thinking of *EVERY POSSIBLE* use of the design you have made. I design
I think that;'s going a bit far....
I don't consider that the Z80 is brain-dead because it only has a 16 bit
address bus, for all 64K is nowhere near enough memory for a personal
computer now. 16 bit address was a reasonable choice at the time.
I do consider the IBM PC interrupt system to be brain dead because
-- It lead to major problems later on
-- The 'correct way to do it' was well-known by every electronic engineer
worth his NaCL, and had been used in many previous machines.
-- The 'cost' to do it right was 1 or 2 inexpensive ICs.
> for a living, and I think you're asking way too much of a designer. The
IMHO part of being a designer is thinking how the design could be used
(other than its originally-intended use),
> best designers plan for the stated requirements and try to consider the
> long term, but they are not prophets.
> I think subjecting the designers choices to things that came much later
> is ludicrous.
> And on the RAM at $0000 issue, I think that is simply Intel and the PC
> environment responding to bad choices that people made. Intel 8080
> designers no doubt assumed (as the MOS folks did), that startup vectors
> would be in ROM. The Development Board chose RAM + switches to offer
> some flexibility, which is to be expected. That CP/M and later systems
> assumed RAM at $0 can't be blamed on Intel. The fact that they later
Agreed, and nor do I blame it on Intel.
> tried to fix the issue by moving the jump table to the top segment seems
The poiont is that that fixed nothing. The issue, IMHO, was not caused by
_where_ the procesor started execuding on rest.
> to me to be reacting to the "status quo", not creating a bad design.
> CPUs need to fetch vectors from a fixed address. Anywhere you put them
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
> will offend someone. I think Intel putting them at the bottom sounds
> like a fine design, at least in the '70s. 'C' and it's desire to have
> address 0 be NULL was not around on the micros, and putting it at the
I wasn't aware that this was a requirement of C, or any other language.
> bottom alleviated the need to keep moving it as the "top" of memory
> keeps moving up.
> > And what maces the design worse is that the problem had been considered
> > (and correctly solved) before. On the PDP11, the top part of the address
> > space was used for I/O devices. And it was the top part on all PDP11s,
> > whether they had 16, 18, or 22 bit addressing.
> I don't think I would call that a correct design. It forces all
> programs to treat all IO as relative addresses, since they will move as
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.
> the design moves. If there are processing penalties for relative
> addressing, you've sealed the programmer's fate.
> It was a good choice for minicomputers, as they specced out multiple
> addressing options for various levels of the market, and programmers all
> designed with that in mind. How was Intel to know the 8080 would sell
> as well as a DEC CPU?
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.
More information about the cctalk