3 Aug
2008
3 Aug
'08
10:19 p.m.
On Sunday 03 August 2008 22:57, Jim Brain wrote:
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)
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. 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