1 Aug
2008
1 Aug
'08
10:35 p.m.
Note: This was written at a eariler date than mailed.
This is due to the fact I personally do not have a net connection
and read email whenever and however I find a unsecure IEEE 802.11g
"Wi-fi" access point. As of such, I ask that would someone please be
so kind as to compile all relevant replies to this email into a digest
and email that to me, as at the last time I checked my email, I had
over thirty thousand unread email messages (30,069 to be exact) from
over the last 20 months or more and I am simply too lazy to junk them
all -- it's a GMail account and the ratio of incoming daily mail to
storage growth is low enough that accumulating email appears to be a
non-issue, even with 3 very high volume mailing lists subscribed;
wine-dev, cctalk, and I think LKML. (Normally, I sort this all out
using a rather ad-hoc set of regexp filters in Thunderbird)
My question is rather perplexing. When most people refer to
segmented memory, AFAIK, they mean banked memory systems, where
each segment is like a piece of paper, that is, seperate from each
other. On the contrary, the Intel 8086's segmented memory model is
like lessing some source code and using the terminal arrow keys
or K/L to move the display one line; given segment X, segment X+1
contains almost all of the memory of segment x, except for a new
line of 16 bytes (which the metaphor between a new line in 'less'
and the segment differential is rather ironic; most hex editors I have seen
display exactly 16 bytes of data per line)
The question is, is the Intel 8086's memory model brain-damaged? IMHO,
extremely much so.
1 Aug
1 Aug
11:10 p.m.
Segin Noname wrote:
Note: This was written at a eariler date than mailed.
This is due to the fact I personally do not have a net connection
and read email whenever and however I find a unsecure IEEE 802.11g
"Wi-fi" access point. As of such, I ask that would someone please be
so kind as to compile all relevant replies to this email into a digest
and email that to me, as at the last time I checked my email, I had
over thirty thousand unread email messages (30,069 to be exact) from
over the last 20 months or more and I am simply too lazy to junk them
Then you're clearly not interested in an answer.
Sorry, but my time is too valuable to handle *your* email problems.
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
11:47 p.m.
On Fri, 1 Aug 2008, Segin Noname wrote:
The question is, is the Intel 8086's memory model
brain-damaged? IMHO,
extremely much so.
It is a base and offset set of pointers. There are other systems that I
much prefer, such as a 32 bit flat addressing scheme, but that would have
required a BIGGER kludge for intel to have kludged it onto their
processors that were built around 16 bit address bus.
There is a long term trade-off between new design elegance v
compatability with the 4 bit predecessors.
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.
Base and offset segmentation is NOT my favorite, but it is a valid
possibility for some types of systems. Saying that it is "brain-damaged"
is on a par with declaring big-endian (or little-endian) to be
"brain-damaged".
--
Grumpy Ol' Fred cisin at xenosoft.com
2 Aug
2 Aug
11:57 a.m.
On 1 Aug 2008 at 20:47, Fred Cisin wrote:
It is a base and offset set of pointers. There are
other systems that I
much prefer, such as a 32 bit flat addressing scheme, but that would have
required a BIGGER kludge for intel to have kludged it onto their
processors that were built around 16 bit address bus.
It seems to me that Intel was attempting to solve two problems with
the 16-byte segment + offset addressing. The first, and likely most
important in Intel's mind was to afford addressing of more than 64K
bytes. The second was to give some sort of location-independent
facility for addressing code and data. Recall that in the 808x, all
addresses are absolute, with on-the-fly relocation a reall PITA.
The 8086 gives one the capability of position-independent code and
data, at least to a granularity of 16 bytes. The downside is that
when addressing a structure of more than 64K in size, address
computation gets a little too involved for my taste. I think that a
couple of special-purpose segment+offset arithmetic instructions
might have helped quite a bit.
Intel certainly could have used its segment registers as 64KByte-
sized address pointers, but then the relocatability aspect would have
suffered at the expense of simpler segment arithmetic.
I think it's important to keep perspective here. The 8086 dates from
1978, only a year after the 8085. It was never intended to be the
end result of 16-bit development at Intel, but a placeholder until
the 432 "micromini" could be deployed. Moto deployed the 6809 a
year later in a similar role-filling mode, the difference being that
the 68K was a winning design, where the 432 fell on its face, leaving
Intel with the x86.
Back around 1977, there was a lot of chatter about "16 bitters". One
of the big issues for systems designers was the company behind the
chip. National was horrible in terms of support (PACE). TI
(TMS9900) wasn't much better. GI seemed to be disintrerested in its
CPU (CP1600). DG didn't want to talk to people who might compete with
it (MicroNOVA) and Fairchild was loathe to admit that it even sold
the 9440. All of the above suffered from one problem--64K address
space size.
Cheers,
Chuck
1:09 p.m.
Chuck Guzis wrote:
Back around 1977, there was a lot of chatter about
"16 bitters". One
of the big issues for systems designers was the company behind the
chip. National was horrible in terms of support (PACE). TI
(TMS9900) wasn't much better. GI seemed to be disintrerested in its
CPU (CP1600). DG didn't want to talk to people who might compete with
it (MicroNOVA) and Fairchild was loathe to admit that it even sold
the 9440. All of the above suffered from one problem--64K address
space size.
Lets not forget Dec did not have the 'home' computer idea at all
unlike the *PC*. I am now building a PC clone is seems again
as I want a 12/24 bit cpu using bit slice components from about
that same era ... 1978 ish. I am asumming 512x8 proms were
out by then. 16Kb x 1 drams was normal memory size of memory
chips. 512Kb of memory addressing is planned in hindsight
as compared to 256Kb (18 bits) as what could have been planed
had this computer been designed in the 70's. The only thing I
have done is made the memory cycle speed .666 us ( .333us)
access time with wait states for the last two (4K) pages of
memory. This gives me the best of both worlds ... slow I/O and
150ns memory chips for a clock speed faster than a PC .8 us.
In this era of megabyte memory chips is is easy to forget
the memory sizes that could be put on a printed circuit
card.
Cheers,
Chuck
PS. I download a intel memory data book from bitsavers
from 1973 ( note more memory databooks could be
usefull)
and marveled of the small rack of 1mega-bit memory
made from 1kx1 drams compared to core of the same size.
4:48 p.m.
Is it possible that when designing the 8086, it's architect already had in
mind the 286?
In that processor the segments are capable of implementing a Multics-style
OS.
[that would assume the 8086 was a "quick hack" to tide Intel over until the
technology
for better chips existed]
And at that time the coming dominance of Unix-derived OS's (or of Microsoft)
was
not as obvious as we now may think with 20-20 hindsight.
Andy
3 Aug
3 Aug
1:51 p.m.
On 2 Aug 2008 at 21:48, Andy Holt wrote:
Is it possible that when designing the 8086, it's
architect already
had in mind the 286? In that processor the segments are capable of
implementing a Multics-style OS. [that would assume the 8086 was a
"quick hack" to tide Intel over until the technology for better chips
existed]
It wouldn't surprise me that an 80286-like chip was on the drawing
board when the 8086 was launched. Intel tended to think pretty far
ahead back then. Indeed, the 432 had segments.
And at that time the coming dominance of Unix-derived
OS's (or of
Microsoft) was not as obvious as we now may think with 20-20 hindsight.
Multics-derived OSes weren't the only game in town using protection
schemes back then. When the 8086 was launched, OS memory protection
was very much current thinking, just as OOP and message-passing OSes
were current mainstream thought when the 432 was designed.
An earlier comment was made about "home PCs" not being seen when the
first generation of 16-bit chips were deployed. That may have been
true, but "business computers" were very much part of mainstream
thought. Chip manufacturers could look at the success of the likes
of the DEC and DG minis and easily see where the future was pointed.
I do recall that the Intel rep did say that the 432 was designed as
an Ada machine. That may have been speculation on the part of
marketing type, but it demonstrates where the thinking was.
What's ironic to me is that the i960 RISC processor arose out of the
ashes of the very-very-CISC 432. From one extreme to the other.
Another curiosity was the interesting game thatSiemens was playing.
Around 1978 they paired up with AMD to form a joint venture called
"American Micro Computers" or AMC to develop a support base for the
Z8000. When that flopped, they tried the same approach with Intel a
few years later with a joint venture, called BiiN to develop a
support base for the i960, which ultimately flopped. I have some AMC
manuals, but no BiiN paper.
Does anyone own any of the development system hardware produced by
either AMC or BiiN? It should be pretty rare.
Cheers,
Chuck
2:28 p.m.
Chuck wrote:
I do recall that the Intel rep did say that the 432
was designed as
an Ada machine. That may have been speculation on the part of
marketing type, but it demonstrates where the thinking was.
It was a "retcon". When the key aspects of the 8800 architecture (which
became the 432) were developed, HOLWG hadn't even yet narrowed the
competition from four languages down to two.
It's more a matter that when the Green proposal was chosen in mid-1979,
it happened to be a moderately good fit for the 432 architecture. Since
the DoD was backing it, the expectation was that Ada would become very
popular.
The first high-level language Intel shipped to 432 customers actually
was not Ada, but rather a Smalltalk dialect called OPL ("Object
Programming Language"), derived from Rosetta Smalltalk. The Rosetta
Inc. web site apparently went away within the last year.
Eric
2 Aug
2 Aug
3:21 p.m.
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,
This is not how I have learned to use "brain-damaged". A cretinous
design, implemented perfectly, is still cretinous.
Whether a segmented architecture such as the 8086's *is* brain-damaged
is a separate issue; as you point out, this depends on the intended
use. (For general-purpose computing, I am inclined to say it is, but
that's orthogonal to my principal point here.)
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
4:41 p.m.
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.
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...
-tony
8:18 p.m.
> 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
away with cutting that corner, possibly through a gross underestimate of
how much use the bus would get.
I consider that to be working "as designed", not "as intended".
But, there is no question that mistakes happen, and that design decision
sure seems to be one.
I also don't understand the reasoning behind the mode switching in the
80286.
Back to the OP, . . .
I don't see the segmented architecture as a mistake, but as a successful
attempt to do something that in the long term may have been of
questionable value. In the short term, it sure made porting software from
CP/M easy. Lisa and Mac software took a while to develop, but the PC was
inundated with software immediately. It seemed like it took longer to
edit and reprint the manuals than to port the software.
Similar to the OP, I've even heard programmers declare it to be a bug that
overflowing an offset register doesn't increment the high nibble of the
segment register!
Were either the 5150 or the 8086 architecture intended to last until 1990?
--
Grumpy Ol' Fred cisin at xenosoft.com
9:39 p.m.
On 2 Aug 2008 at 17:18, Fred Cisin wrote:
Were either the 5150 or the 8086 architecture intended
to last until 1990?
I don't think the 8086 was intended to last until 1983. I can
remember asking our Intel sales engineer about using the 8086
sometime around 1979. His response was to wait for the Real Deal--
the iAPX432/8800. At about that time, we were starting to get early
data and then steppings of the 80186 and decided to use that chip
instead of the 8086, the '186 being more advanced and faster than the
8086. We included a socket for the 80286, even though real working
(i.e. protected mode running) software (Xenix) wasn't ready by any
stretch at the time (the port of Xenix to the 80286 was a joint
Microsoft/Intel deal, with Intel doing the kernel work). Both the
80186 and 80286 were ceramic LCC package and ran at 6 MHz. What was
surprising is that no IBM PC product ever used the 80186.
I recall a bug in the early 186 steppings that damned near drove me
nuts (or maybe it actually did). We'd have a system running that
would seemingly crash at random every other day or so. Being an
early stepping, there was no ICE for the thing and with the on-chip
peripherals, there weren't a lot of places to hang a logic analyzer.
You'd write some diagnostic code and it'd run flawlessly for a week.
Eventually, it turned out that what was happening was that the SI
and DI registers would get clobbered by DMA activity. After much
lost hair, we discovered the problem, and phoned the Intel
application engineer assigned to the 80186. He told us, that yup,
they knew about it--had for a week. Just never bothered to tell
anyone about it.
A month out of my life that I don't miss at all.
If you haven't yet, by all means research the 432--the architecture
is about as far from the 8080/8086 family as one could get. Perhaps
a picture of what the PC (at least the advanced models) might have
been.
Cheers,
Chuck
3 Aug
3 Aug
12:04 a.m.
Chuck Guzis wrote:
...
If you haven't yet, by all means research the
432--the architecture
is about as far from the 8080/8086 family as one could get. Perhaps
a picture of what the PC (at least the advanced models) might have
been.
I'm surprised that the intel specs for it haven't been scanned and put
online somewhere. Just about all other intel databooks have made it
online, so I don't know why the 432 is exempt. Or maybe I'm just not
looking hard enough. I have no real need to see it; just passing curiosity.
The list's Eric Smith appears to have the most comprehensive webpage
about the 432:
http://www.brouhaha.com/~eric/retrocomputing/intel/iapx432/
but even it doesn't contain the datasheets and manuals -- just the names
of all the data sheets and manuals that are known.
12:11 a.m.
On Saturday 02 August 2008 21:39, Chuck Guzis wrote:
What was surprising is that no IBM PC product ever
used the 80186.
I seem to recall something about the use of "reserved" interrupts or similar
that was the reason behind that -- apparently somebody (m$?) used 'em anyhow,
making the '186 not an option.
I do remember seeing a small number of '186 machines out there, but they
never did seem to get any traction.
--
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
1:31 a.m.
On 3 Aug 2008 at 0:11, Roy J. Tellason wrote:
I seem to recall something about the use of
"reserved" interrupts or similar
that was the reason behind that -- apparently somebody (m$?) used 'em anyhow,
making the '186 not an option.
Right from the beginning, Intel reserved interrupt types 0-31
(decimal), with 0-4 having defined functions on the 8086/88. The 186
used 5 for a bounds exception (BOUND instruction), 6 for unused
opcode exception (useful!), and 7 for ESC opcodes if enabled. The
DMA controllers used 10 and 11 for signalling TC; and the timers used
8, 18, and 19. External interrupts (INT0-INT3 pins) were mapped to
12-15.
Of course, neither the DMA controllers nor the timers were anything
like the 8237 or 8254 from a programming standpoint.
It seems to me that someone used the 80186 in 8086 compatibility mode
with the traditional 82xx support devices to maintain compatibility
(Tandy 2000?). The 80186 was quite a bit faster than the 8086 for
the same clock speed.
It was the 80C188 that seemed to find all sorts of applications in
the embedded world. It was available in several variations,
including with an on-chip UART.
Cheers,
Chuck
1:47 a.m.
From: rtellason at verizon.net
On Saturday 02 August 2008 21:39, Chuck Guzis wrote:
The 186 was really intended as a controller. It was an 86 instruction
to simplify coding in languages that were developed for the 86.
It had a few enhaced functions. Memory mapping saved external
hardware. As I recall, it had a serial port as well. This made it
good for embedded Forths.
Dwight
_________________________________________________________________
Reveal your inner athlete and share it with friends on Windows Live.
http://revealyourinnerathlete.windowslive.com?locale=en-us&ocid=TXT_TAG…
What was surprising is that no IBM PC product
ever used the 80186.
I seem to recall something about the use of "reserved" interrupts or similar
that was the reason behind that -- apparently somebody (m$?) used 'em anyhow,
making the '186 not an option.
1:16 p.m.
> 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 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
2:02 p.m.
On 3 Aug 2008 at 18:16, Tony Duell wrote:
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.
Think about it--it makes sense from Intel's point of view. They get
a CPU that boots in real mode with a memory map identical to that of
the 8086. Software interrupts still vector to low memory, the reset
jump is at the top of addressable memory. When you enter protected
mode, the memory layout is pretty much immaterial. The jump to
0FFFF0 does not preclude using "shadowing" any more than it does to
put the jump to 00000. Remember that the 80286 was intended as a
product-line filler for the 808x line and probably intended to be
(from everything I've read) the last member of the family.
To me, the huge break in the family philosophy is represented by the
80386; essentially implementing not only real mode, but TWO protected-
memory management architectures. You may have exchanged your horse
for a car, but you've still got a buggy whip and feedbag, just in
case.
Cheers,
Chuck
10:57 p.m.
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
thinking of *EVERY POSSIBLE* use of the design you have made. I design
for a living, and I think you're asking way too much of a designer. The
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
tried to fix the issue by moving the jump table to the top segment seems
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
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.
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.
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?
Applying the accumulated knowledge of history to attack a designer who
did not have access to that knowledge is bad form, in my opinion.
For the record, I despise the segmented architecture of the 8086, 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 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
11:28 p.m.
Jim Brain wrote:
Tony Duell wrote:
I do design for a living, and, although your point regarding being
unable to predict the future with perfect accuracy rings true, I would
argue that prototypes really help with getting the really big screw-ups
out of your designs.
Peace... Sridhar
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
thinking of *EVERY POSSIBLE* use of the design you have made. I design
for a living, and I think you're asking way too much of a designer. The
best designers plan for the stated requirements and try to consider the
long term, but they are not prophets.
4 Aug
4 Aug
12:19 a.m.
On 3 Aug 2008 at 23:28, Sridhar Ayengar wrote:
I do design for a living, and, although your point
regarding being
unable to predict the future with perfect accuracy rings true, I would
argue that prototypes really help with getting the really big screw-ups
out of your designs.
I consider neither the reset vector nor the segmentation feature of
the 80x86 to be a design screw-up, but rather a design decision.
Regardless of the technical quibbling, it works.
Real screw-ups are the "you can't get there from here" sort--where
there are no good work-arounds and the problem prevents customers
from getting useful work done. Sometimes, this stems
from a
misunderstanding of the customer's needs.
For example, on the 80286, I can imagine an engineer saying to
himself "Once you've entered protected mode, why would you *want* to
go back to real mode?" Hence, the really weird kludge using the
keyboard controller to reset the CPU into real mode on the PC AT.
Without the then-undocumented LOADALL instruction, protected-mode
Windows may have been delayed until the 80386. Quel horreur!
Cheers,
Chuck
7 Aug
7 Aug
2:41 p.m.
On Sun, Aug 3, 2008 at 9:19 PM, Chuck Guzis <cclist at sydex.com> wrote:
Without the then-undocumented LOADALL instruction,
protected-mode
Windows may have been delayed until the 80386. Quel horreur!
Ummmm..... Protected-mode Windows WAS delayed until the 80386. (Or
am I missing the joke?) Windows 286 (aka 2.10) was real mode.
Windows 386 (also having version number 2.10) had a 386 protected mode
kernel that used the virtual 8086 mode to separate tasks.
AFAIK, the first windows with a 286 protected mode was Windows 3.0
with its "standard mode". A lot of Windows 286 apps wouldn't run in
standard mode.
Eric
3:54 p.m.
On 7 Aug 2008 at 11:41, Eric J Korpela wrote:
AFAIK, the first windows with a 286 protected mode was
Windows 3.0
with its "standard mode". A lot of Windows 286 apps wouldn't run in
standard mode.
Well, to be fair, Windows 286 and Windows 386 appeared at virtually
the same time. Although 286 used the HMA, if available, you're
absolutely correct in that it didn't make use of 286 protected mode.
That was still the province of the "DOS extender" stuff like Phar
Lap.
ISTR Windows 3.0 "standard mode" on a 386 could be considerably
faster than using the 386 "enhanced" mode--if you had enough memory
installed.
Cheers,
Chuck
5:20 p.m.
On Thu, Aug 7, 2008 at 12:54 PM, Chuck Guzis <cclist at sydex.com> wrote:
ISTR Windows 3.0 "standard mode" on a 386
could be considerably
faster than using the 386 "enhanced" mode--if you had enough memory
installed.
It was for Windows apps, but the penalty was a single non-multitasked
DOS box. In "enhanced mode" windows apps were living in a shared v86
machine, rather than under 286 protected mode. It took a lot of
fiddling with page tables to keep them happy without really enforcing
a 640K shared address space.
Pardon me, I'm having flashbacks about locking and unlocking memory handles.
Eric
4 Aug
4 Aug
12:30 a.m.
Sridhar Ayengar wrote:
Jim Brain wrote:
I can't argue that. Are you stating, though, that the 8080
or 8086
design did not go through a prototype stage?
I would rebut (only slightly) that I find it is getting harder to do a
"prototype" design. Customers want it right the first time, there's no
time or budget for a "prototype", and it cna be hard to simulate a new
design to the degree needed to ensure all of the issues are resolved.
Luckily, new designs ararely break a ton of new ground, and costs of raw
materials are much less now, so it's easier to hedge your bets by
designing in some backup plans for a worst case scenario.
To keep things on topic, I find the CBM 1351 mouse design serves as a
good example of my point. Long after the C64 had been introduced, it
was still a good seller, and Berkely Softworks had managed to put a GUI
on it in the name of GEOS. A clever chunk of code, no matter your
impression of GUIs in general. While I never found the tool all that
exciting from a user point of view, the developer in me marveled at the
functionality they crammed into 64kB and 320x200 and 170kB disks.
Still, a UI needs a mouse, and the C64 was not designed for one. If we
take Tony's perspective, we know that Xerox was doing GUI and
mouse-driven UI work ong before the 64 came out, so some might argue
that the 64 design should have included a mouse port (heck, we coudl
argue that for all PCs, but I digress). I don't take that view.
Still, CBM engineers looked at their options for adding a mouse to the
64. The obvious candidates were the soft 1200 bps uart on the user
port, but that would preclude telecomm apps. An expansion card option
with a proper uart was another path, but multi-slot expansion cards were
not the norm then, and GEOS already effectively needed the expansion
slot for the RAM expansion unit (REU). The cassette port could work,
but the engineers no doubt kept coming back to the joystick port, as
they is the normal location for non-KB input device installation. Hmmm,
5 IO pins and 2 8-bit ADCs are all they had to work with. Other designs
used the analog pins for absolute positioning, but that made pixel-level
positioning impossible. Clearly, some relative positioning approach was
needed, and the design should minimize the use of the digital IO, since
the joystick port IO was shared with the KB (one port are the low 5 bits
of the KB columns, the other is the 5 low bits of the KB rows).
In order to satisfy all of the business requirements (use no other
ports, > 8 bit positioning, minimize digital IO usage), they came up
with a clever (in my opinion) approach.
They designed an IC that kept two digital counters (X and Y) and then
translated the low 6 bits of the counters on the two POT lines. Instead
of trying to generate a variable resistance (that would require tuning
and other such things), they took advantage of the known properties of
the SID POT lines. The lines work by counting the discharge of a cap to
a preset reference value over a 256 cycle period. Further, then end the
cycle by clamping the POT line to ground for 256 cycles. So, the design
implemented was:
Watch the POT line for the line to drop to ground.
Wait 256 cycles
wait another 256 - (low 6 bits of internal counter)*2
bring line high for (low 6 bits of internal counter)*2 cycles
repeat
This process ensured the line was always high at the end of the 512
cycle period in order to see the next clamp to ground event. The *2
took care of the inherent jitter of the design (PAL 64s ran a bit slower
than 1MHz, NTSC a bit above, the ASIC in the mouse ran at 1MHz exactly,
so the low bit of the SID POT line would jitter. Thus, the programmer
would take the low 7 bits, lsr, and then have the counter value modulo
64. A bit of additional work on the programmer's side and overflow
could be handled as well. The top bit was left off because the design
relied on a small resistance on the ADC line to allow the ASIC to drive
the line high but still see the low clamp event. Thus, there was no way
to reach above 250 or so on the scale, and the design was much simpler
if just 6 effective bits were used.
Now, looking at it one way, the design is awful, as it abuses so many
things. On the other hand, I find it an elegant solution to the problem
at hand. Many 1351 mice were sold because they were easy to understand,
reliable, and easy to install/remove.
Jim
Tony Duell wrote:
I do design for a living, and, although your point regarding being
unable to predict the future with perfect accuracy rings true, I would
argue that prototypes really help with getting the really big
screw-ups out of your designs.
Peace... Sridhar 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
thinking of *EVERY POSSIBLE* use of the design you have made. I
design for a living, and I think you're asking way too much of a
designer. The best designers plan for the stated requirements and
try to consider the long term, but they are not prophets.
1:19 a.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
1:56 a.m.
Roy J. Tellason wrote:
On Sunday 03 August 2008 22:57, Jim Brain wrote:
specific devices. Not likely applications. Or were they handling their own
I/O?
I think, at the time in Intel history, I would not fault the designer
for assuming there was no OS or there was no guarantee an OS would be
calling the shots. I'm not sure of who was first (MOS, Moto, Intel,
others), but I know the 6502 did not assume an OS, and I think the 8080
was a bit older than the 6502.
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.
Even today, when we design a new X, it's very important to ensure that X
is backwards compatible with X-1, even though we are sure that few will
care. I would go so far as to label designs that were not backwards
compatible (without good reasons) with the moniker we're discussing
here. Note that the designer ensuring backwards compatibility is not
the same as encouraging it. Still, it's drilled into a designer's
head. Don't break compatibility unless there a *VERY* good reason.
Jim
2:47 a.m.
On 4 Aug 2008 at 1:19, Roy J. Tellason wrote:
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?
There aren't any "extra" RST instructions for the 8085, just new
vectors. Recall that the 8085 has several external interrupt pins
(IRQ 5.5, 6.5 and 7.5), which simply simulate calls to locations
002C, 0034 and 003C respectively.
One early use for the RST instructions was before the day of the 8259
PIC. You could implement a rudimentary vectored interrupt scheme
with a priority encoder and a buffer to gate a 1-byte RST instruction
as part of the interrupt acknowledge protocol. Note that the RST
instruction takes the form 11nnn111, where nnn is the "number" of the
RST. A hangover from the 8008, whose RST was encoded 00nnn101.
Cheers,
Chuck
9:59 a.m.
From: cclist at sydex.com
On 4 Aug 2008 at 1:19, Roy J. Tellason wrote:
Hi
RST's were useful to start up an output interupt as well. Depending
on hardware, these might not self start. One needed a first output
to start things. By using the same vector, one didn't need to duplicate
code.
Dwight
_________________________________________________________________
Your PC, mobile phone, and online services work together like never before.
http://clk.atdmt.com/MRT/go/108587394/direct/01/
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?
There aren't any "extra" RST instructions for the 8085, just new
vectors. Recall that the 8085 has several external interrupt pins
(IRQ 5.5, 6.5 and 7.5), which simply simulate calls to locations
002C, 0034 and 003C respectively.
One early use for the RST instructions was before the day of the 8259
PIC. You could implement a rudimentary vectored interrupt scheme
with a priority encoder and a buffer to gate a 1-byte RST instruction
as part of the interrupt acknowledge protocol. Note that the RST
instruction takes the form 11nnn111, where nnn is the "number" of the
RST. A hangover from the 8008, whose RST was encoded 00nnn101.
Cheers,
Chuck
2:54 p.m.
Tony Duell wrote:
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.
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 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
another matter.
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.
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.
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.
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.
-tony
4: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.
5:15 p.m.
It was thus said that the Great Jim Brain once stated:
If such a think existed, it would have been an external circuit, and would
have been very hard to support since the 8086 did not include support for
restartable instructions (same situation on the 68000).
-spc (Well ... a paged-type memory protection would have been difficult on
the 8086. A segmented virtual protection system might have been
easier to support)
Tony Duell wrote:
It really depends upon the implementation. Under MS-DOS, it would return
whatever was in location DS:0, or if dereferenced as a far pointer, 0:0,
would give you the address of the Divide-by-0 exception routine. On the
68000, it would give you the initial stack pointer upon reset. Modern
systems with memory protection usually mark location 0 as protected and no
allow read/write access. I think the default action on VMS (or maybe the
Unix varients on the VAX) allowed one to read from location 0, which always
returned 0.
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? 
5:27 p.m.
On Monday 04 August 2008, Sean Conner wrote:
It was thus said that the Great Jim Brain once
stated:
The PDP-11 doesn't support restartable instructions either. You don't
need restartable instructions to support an MMU, only to support
virtual memory type operations. For example, my Z80-based Altos 8000
has a bank-switching MMU that could operate the same way as an MMU on a
808[68] would.
Pat
--
Purdue University Research Computing --- http://www.rcac.purdue.edu/
The Computer Refuge --- http://computer-refuge.org
Tony Duell wrote:
If such a think existed, it would have been an external circuit,
and would have been very hard to support since the 8086 did not
include support for restartable instructions (same situation on the
68000). 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?
6:20 p.m.
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.
And that's where I disagree. The addreess FFFF:0000 can _also_ be
interpretted as '16 bytes below the physical top of memory. Given that
the reset routine is likely to be in ROM, and given that contiguous RAM
is generally a good thing, IMHO it would have been better if the physical
address outputted by an 80286 for the first instruction after reset was
FFFFF0 (not 0FFFF0). One way to do this would have been similar to the
PDP11 I/O address trick (which is why I brought that up), namely that in
real mode, the 'extra' 4 address lines of the 80286 (over the ones of the
8086) are all set to the same state and that state is the logical AND of
the top so-many-bits of the current segment register.
-tony
8:09 p.m.
Tony Duell wrote:
No, not as a single chip (AFAIK). But that doesn't
stop somebody building
one if they want to.
And AFAIK there is no MMU for the PDP11/20 (the first PDP11
implementation). And yet it got the extension of 16 bit program addresses
to 18 bit bus address 'correct' ((a) what all other 11's do and (b) what
was sensible to do given the fact that I/O devices sit at the top of the
address space)/
I'll stand my ground. The fact that one could build an MMU for the 8086
is different from requiring one in the design of a PC that used the
8086. In fatc, who's to say the 8086 designer expected the computer
developers to use an MMU? It's not like they could force them to do so.
No, I don;t think putting the reset at the top of
memory was inherrently
silly. It's just that it doesn't seem to have served any real purpose.
The problems on the 8080 systems caused by having reset jump to location
0 were really due to the fact that reset jumped to a fixed location, not
where that location was. So moving it somewhere else neither helped nor
hindered anyone.
I think I made a convincing case in one of my previous posts. I can see
clearly that 8080 board designers would have carped quite a bit about
having to map ROM into $000 for boot and wanted that to go away in the
next iteration of the board. Or, perhaps Intel just noticed where
everyone was going, with RAM at 0, and wanted to help make it easier to
design in the 8086 (I think this was at a time where Intel's dominance
of the CPU market was not even on the RADAR, so I suspect they did what
they could to ensure an easy design in. To play that car further, by
the time the 80286 came out (and to use your argument that Intel knew
the 80286 was a sure thing), they probably didn;t care about it as
much. People would use the 80286 because it was the next in the
lineage, and the x86 was a force to be reckoned with. So, for the poor
designer who no doubt raised the issue you describe, I can easily see
them beaten down by the marketing and management types, saying, don't
waste silicon on it, we *own* this market!
And that's where I disagree. The addreess
FFFF:0000 can _also_ be
interpretted as '16 bytes below the physical top of memory. Given that
the reset routine is likely to be in ROM, and given that contiguous RAM
is generally a good thing, IMHO it would have been better if the physical
address outputted by an 80286 for the first instruction after reset was
FFFFF0 (not 0FFFF0). One way to do this would have been similar to the
PDP11 I/O address trick (which is why I brought that up), namely that in
real mode, the 'extra' 4 address lines of the 80286 (over the ones of the
8086) are all set to the same state and that state is the logical AND of
the top so-many-bits of the current segment register.
I really think compatibility concerns trumped the implementation of this
idea.
And, even if they truly should have implement the idea you describe, I
just don't think it qualifies as "brain dead" that they did not.
5 Aug
5 Aug
5:03 a.m.
On 4 Aug 2008 at 23:20, Tony Duell wrote:
IMHO it would have been better if the physical
address outputted by an 80286 for the first instruction after reset was
FFFFF0 (not 0FFFF0). One way to do this would have been similar to the
PDP11 I/O address trick (which is why I brought that up), namely that in
real mode, the 'extra' 4 address lines of the 80286 (over the ones of the
8086) are all set to the same state and that state is the logical AND of
the top so-many-bits of the current segment register.
My gripe with all of the X86 series is that there are no status lines
indicating which segment register is being used to generate an
address. The NEC V40, for example, tells you this, so you can have 4
separate address spaces of 1M each. Fetching from a different space
on reset is a no-brainer to implement.
Cheers,
Chuck
10:02 a.m.
And AFAIK there is no MMU for the PDP11/20 (the first
PDP11
Not as a product. However, lo these many years ago (neigh
on to 3 decades), I was shown an object that consisted of
numerous DEC modules and told that it was one of three MMUs
that had been built for the 11/20. Since we also had an
11/20 there, it was at least plausible. To my knowledge,
it was later lost to a great clean-out. Now, I have no
idea whether it really was an 11/20 MMU, but I do recall
a while back coming across a mention of what sounded like
an experimental MMU for it. So such a thing did exist
in legend and myth...
BLS
11:37 a.m.
2008/8/5 Brian L. Stuart <blstuart at bellsouth.net>:
Probably doesn't count as a bona fide MMU, but I remember reading
something about an add-on for the 11/20 which did kernel/user memory
protection. IIRC it was called the KS11 and was some kind of special
order option, so there probably weren't that many made. Could it be
that that's what you were shown?
--
Steve Maddison
http://www.cosam.org/
And AFAIK
there is no MMU for the PDP11/20 (the first PDP11
Not as a product. However, lo these many years ago (neigh
on to 3 decades), I was shown an object that consisted of
numerous DEC modules and told that it was one of three MMUs
that had been built for the 11/20.
11:49 a.m.
And AFAIK there is no MMU for the PDP11/20 (the first
PDP11
Not as a product. However, lo these many years ago (neigh
on to 3 decades), I was shown an object that consisted of
numerous DEC modules and told that it was one of three MMUs
that had been built for the 11/20.
7 Aug
7 Aug
3:02 p.m.
On Mon, Aug 4, 2008 at 1:21 PM, Jim Brain <brain at jbrain.com> wrote:
Did an MMU exist for the 8086?
Most of the PC compatible 8086/8088 machines in my collection have one
or two. The most common variety is on the graphics card to map
graphics memory into the address space of the processor. The second
most common would be EMS cards, which depending upon their vintage
could map 16kB pages of expanded memory into a 64k window (EMS
1.0-3.0) or remap any 16kB page in the processor address space to
expanded memory (EEMS or EMS 4.0).
4 Aug
4 Aug
4:39 p.m.
> address 0 be NULL was not around on the micros,
and putting it at the
On Mon, 4 Aug 2008, Tony Duell wrote:
I wasn't aware that this was a requirement of C,
or any other language.
C actually insists that address 0 is an invalid address!
But, one of the best things about C is that it is easy to shove it out of
the way when you want to do something else.
--
Grumpy Ol' Fred cisin at xenosoft.com
4:46 p.m.
>>>> "Fred" == Fred Cisin
<cisin at xenosoft.com> writes:
> > address 0 be NULL was not around on the
micros, and putting it
> at the
Fred> On Mon, 4 Aug 2008, Tony Duell wrote:
> I wasn't aware that this was a requirement of
C, or any other
> language.
Fred> C actually insists that address 0 is an invalid address!
Pedantically: not quite. It says that 0 is the token representing a
null address. It doesn't say that the encoding of such a pointer is
the same as that of the integer 0.
In practice that's probably the case in all platforms -- certainly all
current ones. I'm not 100% sure about the PDP-10, never mind the
Cyber 6600... both of which have oddball pointers.
paul
5:15 p.m.
From: Paul Koning
Sent: Monday, August 04, 2008 1:46 PM
>>>>> "Fred" == Fred Cisin
<cisin at xenosoft.com> writes:
>>> address 0 be NULL was not around on the
micros, and putting it
>> at the
Fred> On Mon, 4 Aug 2008, Tony Duell wrote:
>> I wasn't aware that this was a requirement of C, or any other
>> language.
Fred> C actually insists that address 0 is an
invalid address!
Pedantically: not quite. It says that 0 is the token
representing a
null address. It doesn't say that the encoding of such a pointer is
the same as that of the integer 0.
In practice that's probably the case in all
platforms -- certainly all
current ones. I'm not 100% sure about the PDP-10, never mind the
Cyber 6600... both of which have oddball pointers.
It's not that the PDP-10 has "oddball pointers", but rather that
"address" is
not the same data type as "(byte) pointer". I assume that something
similar is
true on the CDC 6x00 family, but I haven't looked at one since
September, 1970,
before I dropped the Compass programming class at UT Austin.
Thanks,
Rich
Rich Alderson
RichA at vulcan.com
Server Engineer, PDPplanet Project (206)
342-2239
Vulcan, Inc., 505 5th Avenue S, Seattle, WA 98104 (206)
465-2916 cell
7:03 p.m.
On 4 Aug 2008 at 14:15, Rich Alderson wrote:
It's not that the PDP-10 has "oddball
pointers", but rather that
"address" is not the same data type as "(byte) pointer". I assume
that
something similar is true on the CDC 6x00 family, but I haven't looked
at one since September, 1970, before I dropped the Compass programming
class at UT Austin.
I never used C on a 6600 (or any other CDC machine for that matter),
but yeah, the addressing granularity is a 60-bit word. Oddly, that
didn't seem to affect the efficiency of languages such as COBOL that
rely heavily on character data. In fact, COBOL on a 6600 was one of
the fastest implementations of any machine of the time. Character
move loops for example, were typically coded (except by "brain dead"
programmers) to move 10 characters per loop pass--and duplexed load
units made it easy to write an in-stack loop where an instruction
issued every cycle and memory was kept busy.
I have no idea how the implementors of 6000-series C decided to
fashion their character pointers. I can well imagine that they were
"weird".
But byte (whatever you want to call a byte) addressability is just an
artificial convenience anyway if your CPU has a wider datapath than a
byte. The CDC STAR, for example, had bit addressability.
Cheers,
Chuck
11:27 p.m.
C actually
insists that address 0 is an invalid address!
Pedantically: not quite. It says
that 0 is the token representing a
null address. It doesn't say that the encoding of such a pointer
is the same as
that of the integer 0.
Right. Indeed, the encoding of a null pointer may vary from type to
type (within certain bounds; as a simple example, char * and void *, by
special fiat, must use the same representation).
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
4:55 p.m.
Fred Cisin wrote:
C actually insists that address 0 is an invalid
address!
Which is one reason why ANSI C on the transputer is such an...
interesting, shall we say, variant of the language. Address
0x00000000 is in the middle of the address space on a
transputer, due to the weird signed nature of addresses.
The compiler quietly changes 0 into 0x80000000 when it's
used as a pointer, so make sure your casts are OK!
--
John Honniball
coredump at gifford.co.uk
5:06 p.m.
It was thus said that the Great Tony Duell once stated:
The C Standard say the token "0" (in a pointer context) is to be
translated to a null address in the target architecture, and in most
implementations, that address is indeed 0, but it doesn't have to be.
Also, dereferencing such a pointer causes undefined behavior, which means
what happens really depends upon the C compiler and underlying hardware.
-spc ("Oooh, look at that magic smoke ... I just have derefenced a NULL
pointer ... ")
> 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
Some CPUs added a register to point to the vector table. The 80286 and
68010 (and above) did this. The default location is the fixed locations
used on the 8086 and 68000.
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.
5:14 p.m.
On Monday 04 August 2008, Sean Conner wrote:
It was thus said that the Great Tony Duell once
stated:
The C Standard say the token "0" (in a pointer context) is to be
translated to a null address in the target architecture, and in most
implementations, that address is indeed 0, but it doesn't have to be.
C also does not require that the value of a pointer be the actual
address stored by the pointer. You could have said that the actual
address is the value of the pointer minus 2^31 (or 2^15, 2^19 or
whatever).
In any case, C does not require that the physical/logical address "0" is
equivalent to NULL, only that the value of a pointer is NULL if its
value is "0".
Pat
--
Purdue University Research Computing --- http://www.rcac.purdue.edu/
The Computer Refuge --- http://computer-refuge.org
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. 
8:14 p.m.
On Mon, Aug 04, 2008 at 05:06:17PM -0400, Sean Conner wrote:
I ran into this when someone at Lucent ported a simple utility from an
NCR Unix box to a Sun box - somewhere, someone was dereferencing a null
pointer (getting strlen() perhaps?)... on the NCR box, the implementation
treated the length of a null pointer as the same as a pointer to a null
(character). On the Solaris machine, it threw a segfault.
It took me a bit of time to convince the guys that both implementations
were valid and that it wasn't a "Solaris bug".
This particular implementation issue is, IIRC, one reason the Amiga
puts a $00000000 at $0000000 (and uses $00000004 as its "ExecBase"
pointer location)... the two ways to catch these sorts of user code
issues are to either stuff something like $DEADBEEF at $00000000
or to use Enforcer to trip up your program if you try to dereference
a null pointer (presuming your development platform has an MMU, of
course). Either way, you'll quickly find null-pointer derefs and
be able to take them out to avoid "undefined behavior".
-ethan
--
Ethan Dicks, A-333-S Current South Pole Weather at 5-Aug-2008 at 00:00 Z
South Pole Station
PSC 468 Box 400 Temp -75.8 F (-59.9 C) Windchill -112.0 F (-80.0 C)
APO AP 96598 Wind 9.9 kts Grid 28 Barometer 672.2 mb (10924 ft)
Ethan.Dicks at usap.gov http://penguincentral.com/penguincentral.html
I wasn't
aware that this was a requirement of C, or any other language.
The C Standard say the token "0" (in a pointer context) is to be
translated to a null address in the target architecture, and in most
implementations, that address is indeed 0, but it doesn't have to be.
Also, dereferencing such a pointer causes undefined behavior, which means
what happens really depends upon the C compiler and underlying hardware.
11:20 p.m.
[nil pointer deref story]
It took me a bit of time to convince the guys that both
implementations were valid and that it wasn't a "Solaris bug".
I ran into a related issue recently. A moderately popular open source
project uses nonportable constructs involving varargs function calls,
passing NULL, uncast, as a varargs argument and expecting it to be a
nil pointer when fetched in the called function. Between a lack of
implementations to point to where it'll fail and some very creative
reading of the standard on the part of the "other side", I was unable
to convince them this was invalid code....
Grrr.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
5:22 p.m.
On Sunday 03 August 2008, Jim Brain wrote:
Tony Duell wrote:
I'll assume from that comment that you aren't familiar with PDP-11
addressing. They are still fixed addresses, they all map to (octal)
160000 through 177777 by default. The extra bits of address space are
accessible only by programming the memory mapping hardware in the CPU,
which can map the I/O page (always the top 8192 bytes of memory) to any
8k boundry in the logical 64kB memory map.
This requires no relative addressing, since the device can always appear
at the same location in memory, unless you chose to move it by changing
the memory map.
And, in case you're worried that hardware had to be adjusted depending
on what address bus used, it didn't. The CPU asserts a I/O page line
on the bus whenever there's an access to the I/O page of address space,
So, the device only needs to check 12 address lines (memory accesses
are 16 bites wide) and the I/O page line, regardless of how wide the
address bus on the CPU is.
Pat
--
Purdue University Research Computing --- http://www.rcac.purdue.edu/
The Computer Refuge --- http://computer-refuge.org
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.
6:25 p.m.
And, in case you're worried that hardware had to
be adjusted depending
on what address bus used, it didn't. The CPU asserts a I/O page line
on the bus whenever there's an access to the I/O page of address space,
So, the device only needs to check 12 address lines (memory accesses
are 16 bites wide) and the I/O page line, regardless of how wide the
address bus on the CPU is.
Actually, that's only yhe case on the Q-bus, which could have either 18
or 22 address lines (was there ever a version that only drove 16 address
lines?)
On the Unibus, there are always 18 address lines, and devices check all 18
of them. On machines without an MMU, or with the MMU turned off, the top 2
address lines (A16 and A17) are asserted if all of A13...A15 are 1's.
AFAIK, that was the case from the very first PDP11, which is the whole
point of this discussion, the machine was designed with the future in
mind Unibus machines with 22 bit addressing have a special memory bus
(not UNibus) with 22 address lines, and a second, simple, MMU, called the
Unibus Map, between the 18 Unibus address lines and the 22 memory address
lines for DMA.
-tony
6:38 p.m.
On Monday 04 August 2008, Tony Duell wrote:
The 11/03, and LSI-11/2, probably the SBC-11/21, and the 11/23 when not
fitted with an MMU. I can't think of any others off the top of my
head. :)
And, in case
you're worried that hardware had to be adjusted
depending on what address bus used, it didn't. The CPU asserts a
I/O page line on the bus whenever there's an access to the I/O page
of address space, So, the device only needs to check 12 address
lines (memory accesses are 16 bites wide) and the I/O page line,
regardless of how wide the address bus on the CPU is.
Actually, that's only yhe case on the Q-bus, which could have either
18 or 22 address lines (was there ever a version that only drove 16
address lines?) On the Unibus, there are always 18 address lines, and
devices check
all 18 of them. On machines without an MMU, or with the MMU turned
off, the top 2 address lines (A16 and A17) are asserted if all of
A13...A15 are 1's. AFAIK, that was the case from the very first
PDP11, which is the whole point of this discussion, the machine was
designed with the future in mind Unibus machines with 22 bit
addressing have a special memory bus (not UNibus) with 22 address
lines, and a second, simple, MMU, called the Unibus Map, between the
18 Unibus address lines and the 22 memory address lines for DMA.
Still, this is equivalent to how the QBUS did it, only without using a
separate line to signal I/O page accesses.
Pat
--
Purdue University Research Computing --- http://www.rcac.purdue.edu/
The Computer Refuge --- http://computer-refuge.org
7:55 p.m.
Patrick Finnegan wrote:
I'll assume from that comment that you aren't
familiar with PDP-11
I understood the argument as "8086 put the 'vectors' (in quotes,
since
they are not just the addresses, but the opcode as well) at the top of
RAM, which did not solve anything., because in the next generation of
CPU, those addresses fell in the middle of the memory map. So, on the
one hand, you could constrain the memory map (ala PDP-11), which it
appears would be considered an "elegant" design, or we lift the top of
the address space, now exposing the 'vectors' as being in the middle of
the memory map, and that is considered "bad".
Dunno, given the choice between fixed map with MMU to push blocks of RAM
into view, or lifting the top of memory, I think the x86 designers
picked a wise path.
And, in case you're worried that hardware had to
be adjusted depending
on what address bus used, it didn't. The CPU asserts a I/O page line
on the bus whenever there's an access to the I/O page of address space,
So, the device only needs to check 12 address lines (memory accesses
are 16 bites wide) and the I/O page line, regardless of how wide the
address bus on the CPU is.
I noted the concern in general, but it does indeed appear the PDP-11
designers handled it with elegance. Still, I think we're comparing
apples to oranges. The Intel crowd had very little control over the
computer design, while the DEC team controlled all aspects of the
design, including the CPU. If the IBM team hadworked very closely with
the Intel designers in bringing out the 5150, I would agree with Tony's
point. But, we know IBM broke the rules in bringing out the unit,
pulling off the shelf and already available parts to bring the machine
to market. If they *had* collaborated as described, I fear the PC would
never have made it. I tend to believe it arrived because the folks who
designed it took the non-IBM approach, not in spite of that approach.
5827
days inactive
5832
days old
56 comments
23 participants
participants (23)
-
andyh＠andyh-rayleigh.freeserve.co.uk -
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
blstuart＠bellsouth.net -
brain＠jbrain.com -
cclist＠sydex.com -
cisin＠xenosoft.com -
coredump＠gifford.co.uk -
dkelvey＠hotmail.com -
eric＠brouhaha.com -
ethan.dicks＠usap.gov -
frustum＠pacbell.net -
korpela＠ssl.berkeley.edu -
mouse＠Rodents-Montreal.ORG -
pat＠computer-refuge.org -
Paul_Koning＠Dell.com -
ploopster＠gmail.com -
RichA＠vulcan.com -
rtellason＠verizon.net -
segin2005＠gmail.com -
spc＠conman.org -
steve＠cosam.org -
trixter＠oldskool.org