segmented memory models

[Roy J. Tellason]

On Sunday 03 August 2008 22:57, Jim Brain wrote:
> CPUs need to fetch vectors from a fixed address.  Anywhere you put them
> 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
> bottom alleviated the need to keep moving it as the "top" of memory
> keeps moving up.

Since that's also where the system goes on reset,  I don't see a problem with 
using that address as a null pointer,  as long as it's going to get tested 
before it gets dereferenced.  :-)

I'm a little curious about all those restart instructions,  anyhow,  and why I 
never saw any real use of them much.  I seem to recall one of them being used 
for a debugger and that was about it.  Then there's the extra ones you get 
with the 8085.  Anybody know of other uses for those?

> > 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
> the design moves.  If there are processing penalties for relative
> addressing, you've sealed the programmer's fate.

Not all programs,  though.  The operating system,  I'd think,  and drivers for 
specific devices.  Not likely applications.  Or were they handling their own 
I/O?

(Snip)

> For the record, I despise the segmented architecture of the 8086,

I've found it distasteful enough to not want to ever really have to deal with 
it.  I was doing assembly language programming under CP/M,  but once it 
started to sink in that I was going to be dealing with other chips with that 
nonsense,  I shifted my interest to c instead,  and don't think I'd care to 
deal with anything lower-level than that.  And even in c under DOS you had to 
worry about different memory models and similar nonsense.

> but I truly understand and appreciate the pains the designer went to allow
> porting of 8080 apps (I think porting might be too much to call it, I
> think a simple assemble would do the trick, as the 8080 assumed a 64kB
> address space, which is the same as one segment.  Why the overlapped is
> unclear to me, but I wouldn't call that a bug.  And, I admit that I
> despise the segments only because I didn't care about the 8080, and thus
> compatibility with it was not on my radar.

I found the 8080 (but more so the z80) to be of some interest,  but porting 
all existing apps to newer chips never made all that much sense to me,  
considering the other differences besides the CPU chip.  More available RAM, 
a lot more standardization of system architecture,  a lot more common 
standard hardware,  and all sorts of other stuff.  It was no surprise to me 
at all to see lots and lots of newer apps and I don't recall seeing all that 
much that got ported over,  or at least not that much that I knew about.  And 
yet that backward compatibility seems to have been an issue for a lot of the 
designers for some reason.

> I reserve "brain damaged" for something that does not satisfy
> requirements available at time of design, or were blatantly obvious at
> design time, or shows a clear lack of ingenuity or creativity on the
> designer's part, and cannot be explained away by compatibility concerns
> or reactive pressures (designing something in because, in spite of the
> best efforts to document that people not do it, they do anyway)
>
> Jim

-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin