> You are welcome to pick whatever kind of
system that you like. Whether or
> not it is "brain-damaged" is an issue of whether it performs as intended,
> NOT whether that is yours or my favorite way of doing it.
On Sat, 2 Aug 2008, Tony Duell wrote:
No, I disagree with you there.
To me, if something doesn;t perform as intended/as docuemnted, then it's
brokem. But if that intention/documentation is, shall we say, silly, then
it's brain dead (even though it performs according to that documentation).
A hardware example is the active-high edge-triggered interrupts on the
ISA bus. The system performs as intended (by the designers), it behaves
as documetned (in the IBM TechRefs). But IMHO it's still brain-dead in
that, to save one cheap TTL chip, we had IRQ conflict problems for many
years...
Ah, a matter of semantics.
They didn't INTEND to have IRQ conflicts, and thought that they could get
Of course not.
And IMHO one common expression of 'brain damage' is when the design
omitted to ccosider soemthing that later became a major issue.
away with cutting that corner, possibly through a
gross underestimate of
how much use the bus would get.
It actually might not have been much of a problem with the original 5150.
That had 5 slots, of which one was taken by the video card (probably no
IRQ line used, the MDA card, could, IIRC, use an IRQ line for the printer
port, but interrupts on the printer ports were not that important
anyway...). The original IBM expansion cards didn't, IIRC, ever use more
than 1 IRQ line each, so with only 5 sloits there were enough IRQ lines
to go round.
On the other had, with the PC/XT (8 slots) or the expansion cabinet, it
became much more of the problem.
And that's aonother expression of 'brain dead'. Not allowing for
(sensible) future expansion.
I consider that to be working "as designed", not "as intended".
YEs, the IBM PC iuterrupt system works as designed. And, IMHO, as
intended by the designer. I still consider it to be brain dead, though.
Another example of a brain-dead design, IMHO, is the 80286's behaviour on
reset.
As I understand the history :
The 8080 started executing at location 0 on reset .
Therefore, the the original Intel 8080 development system had RAM at
location 0. This machine had a hardware front panel so you could write a
JMP instruction into said RAM at location 0 to jump to whatever program
you wanted to run.
Therefore a large number of programs (including CP/M, of course) were
written assuming RAM at location 0.
On machines without a front panel and/or machine aimed at the end user,
you needed a small amount of extra hardware to either force a JMP ontto
the data bus after reset, or to have ROM mapped at location 0 after a
reset that was switvhed out (and replaced by RAM) adter the CPU had
jumped to a rotuine near the top of memory
The 8086/8088, however, tried to get round this problem by starting to
execute a program at location FFFF:0 on reset. IMHO this doesn't help
things at all, the original problem was due to a fixed location where the
CPU started executing after a reset, not where that location was in the
memory map
But the 80286 starts executing at location 0FFFF0 on reset too, even
though it has a 24 bit adress bus. That is, somewhere in the middle of
the address space. Neither at the very start, or near the top. That, on a
machine without a true MMU, is brain-dead IMHO. It lead, of course, to
the 'A20 gate' in the PC/AT, etc.
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.
-tony