ucbesvax.turner@ucbcad.UUCP (06/30/83)
#N:ucbesvax:12800003:000:1097 ucbesvax!turner Jun 30 01:18:00 1983 Can anyone venture a theory as to why many microprocessor architectures are so terrible? I am referring here to 8080 and its derivatives. It's hard for me to believe that there just weren't good architects around at the time, or that the medium was the main constraint. I am told that Datapoint machines are TTL implementations of a slight variant of 8080. And that the 8080 was originally a design commissioned by the Japanese phone company, who later rejected it as too slow for their purposes. These stories could be apocryphal. Why wasn't the first uP a Nova? Or perhaps a PDP-11 subset? Or at least something *good*? The 6800 was a reasonably intelligent design, since it as much as said: "forget speed, use stacks", and provide (voila!) a stack-oriented architecture. The much-later 6809 is, to my mind, the first really good 8-bit machine to appear, and seems to take a position midway between the 6800 and the 68000. Finally, has anyone heard of the 1802, which I have been told is a very slow but architecturally elegant CMOS uP? Michael Turner ucbvax!ucbesvax.turner
tdl@sequel.UUCP (07/01/83)
My theory as to why early micros weren't very elegant is that they were designed by hardware people as solutions to hardware problems. It wasn't until they were used for a while and the amount of code written for them became substantial that the software aspect became more important than the hardware aspect. Its for the same reason that noone thought to write compilers for the first micros. Tom Lovett Sequel Computer Systems pur-ee!sequel!tdl or ogcvax!sequel!tdl
guy@rlgvax.UUCP (07/02/83)
The version of the origin of the 8008 I saw, in (if I remember correctly) an
article in an old issue of IEEE Computer magazine written by somebody at
Intel, said that the original impetus for the 8008 was as a replacement for
a TTL machine built by Datapoint as the brain of one of their terminals.
The original intent was just to make a MOS 1-chip version of that processor,
but the guy who did this said, "Hey, this could be a useful CPU! What a
neat idea - a CPU on one chip!" and tweaked it a little to make it more
general. The rest, of course, is history... I've also heard that some
of the limitations of the 8008 were due to limited chip real estate.
It's interesting to note that the most popular "member" of the 8-bit side of
that family (from all the machine descriptions I've heard) is 1) not made by
Intel and 2) has added a *lot* of stuff to the architecture. I refer, of
course, to the Z80. Unfortunately, Zilog seems to have had trouble following
up that success - a pity, because the Z8000 seems to be a fairly clean and
regular architecture. It has a read, if somewhat odd, large address space
capability (it's called "segmented mode" but pointers are really 24 bits
long; there are no "segment registers" which have to be managed independently
of the general registers), a good orthogonal instruction set with the usual
PDP-11ish addressing modes, "enough" general registers, and a decent set of
32-bit arithmetic instructions (unlike a certain otherwise excellent 16-bit
micro with 32-bit capabilities but no 32-bit multiply or divide). Of the
four major 16-bit micros (I include Zilog here, even though the Z8000 is running
quite a bit behind the 80.*[68] and 680.. families), all but the 8086 and
cousins are quite PDP-11 influenced. In fact, most of the highly-praised
"mainstream" mini/micro architectures are - the PDP-11 (by definition), the
VAX-11, the MC68000, the Z8000, and the NS16032 (any I've forgotten?). The
people who did the PDP-11 have a lot to be proud of.
In a computer architecture "January term" seminar in college,
somebody discussed the three design teams that worked on PDP-11 designs. One
was DeCastro's group, which essentially did the Nova; one was the group that
did the PDP-11; and one was the group that did the GRI-99, which was a machine
that dropped off the edge of the earth, as far as I can tell. Interesting
to note that the PDP-11 was one of the first popular minis to be a Complex
Instruction Set Computer, while the Nova was definitely a Restricted
Instruction Set Computer (of course, it didn't have thousands of general
registers, but hardware was expensive then) - in fact, it was a fairly clean
and regular RISC, as opposed to some of the machines of the time. The
PDP-11 type architectures won out eventually, but the idea of a machine with
a simple instruction set is making a comeback. Of course, the emphasis is not
now on cost (minimal machine means fewer chips means fewer boards) but on
things like using the low-cost VLSI hardware for tons of registers instead
of for control logic and microcode store.
Guy Harris
{seismo,mcnc,we13,brl-bmd,allegra}!rlgvax!guyguy@rlgvax.UUCP (07/02/83)
Also, I do remember something about a Japanese calculator manufacturer being the driving force behind the 4004; I think it was also a case of an LSI implementation of an existing MSI/SSI processor. I can't remember whether they eventually rejected the chip, or whether there was a Japanese phone company working with the 8008 who eventually rejected it. Guy Harris
newman@utcsrgv.UUCP (Ken Newman) (07/02/83)
The 8080 was a successor to the even more wretched 8008, which was designed as a terminal controller, not a general purpose uP. The 1802 is indeed VERY slow, has abominable addressing modes, and as a result is very difficult to write any assembler code for. Its only nice feature is it comes in a CMOS version, but then so do the 6800 and 6502.
chris@umcp-cs.UUCP (07/02/83)
From: ucbesvax.turner@ucbcad.UUCP
Finally, has anyone heard of the 1802, which I have been told
is a very slow but architecturally elegant CMOS uP?
Yes! The 1802 is kinda neat. Also, it's not slow. For most
applications it's faster than a Z80 (especially if you buy the 10 MHz
(!) version) [don't quote me on this, I've never done a timing
comparison]. And the CMOS is nice too, very low power, no heating, etc
etc. The OSCAR sats use(d?) 1802s, and I think the Venus probes did
also.
The world's shortest loop:
20 # decrement PC!
The 1802 is the only uP I know of with GHI (Get High) (8x I think)
and SEX (Ex I think) instructions. (Seriously!)
- Chris
--
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs
ARPA: chris.umcp-cs@UDel-Relaymason@utcsrgv.UUCP (Dave Mason) (07/02/83)
The 1802 does have a couple other interesting features (tho Newman is right
about difficult to code for) the address bus is 8 bits multiplexed, so
extra chips are needed to interface anything resembling standard memory.
On the other hand, it has a built in DMA, and for the right application
can be quite good. Its real problem is that subroutine calls are a crock!
If you need more than 2-3 modules, forget it. Its not really that slow..
unless you try to use more subroutines!
I think the reasons the 8080 was/is so awful are historical... the 4004
4-bit controller chip was produced I BELIEVE on contract, someone at Intel
thought they might sell a few if they made it a shade more general..so they
made the 8008...a few more changes made the 8080...and it was cast in stone!
The Z-80 was designed by some ex-Intel people to be upward compatible,
so that's their excuse, but I really don't understand why the 6800 & 6500
people didn't do a better job. Probably related to the silicon real-estate
shortage and more probably to the abysmal state (i.e. non-existence) of
decent chip circuit design software. When you're doing it by hand, trying
to catch up, for a presumed simple market, you make the hardware as simple
as you can.
Sorry for the long history lesson, but from the question about the
8080 it seems some people must be new to the micro area..hope its helped.
-- Gandalf's flunky Hobbit -- Dave Mason, U. Toronto, CSRG
utcsrgv!mason@UW-BEAVER (ARPANet)
or {cornell,watmath,ihnp4,floyd,allegra,utzoo,uw-beaver}!utcsrgv!mason
or {cwruecmp,duke,linus,lsuc,research}!utzoo!utcsrgv!mason(UUCP)ka@spanky.UUCP (07/03/83)
The 8008 architecture was reasonably good as far as it went. It was a very primative, for example a memory to memory move required six instructions. However, jump to subroutine was one instruction, which makes the 8008 a definite improvement over DEC's KMC. Although a large number of instructions were required to get anything done, the instruc- tion set was simple and regular. I don't think that writing a code generator for it would be very difficult. The main problem with the 8080 instruction set is that it is a superset of the 8008 instruction set. Whether INTEL was right about the importance of upward compatability I don't know. They did, however, grab a huge market share, so they must have done something right. Probably the fact that they were selling largely to electrical engineers rather than to programmers helped. Kenneth Almquist
hal@cornell.UUCP (07/03/83)
One of the articles in this conversation said something like "I don't
understand why they [the 8008-8080 designers] didn't do a better job.
After all, much was known about computer architecture at the time."
Well, yes, but...
How many good chip designers are also good computer architects? Perhaps
there are some now, but back when the original microprocessors were built,
probably very few people were good at both. The original microprocessors
remind me a lot of early computer designs before very much was known about
computer architecture. The hardware folks put together something that
could execute instructions, then left it to the software folks to see
if they could figure out how to use it effectively and come up with good
code generators for compilers in spite of the instruction set. There are
VERY few examples of good computer design. The only encouraging thing is
that there is more awareness of how hard it is to do it right, and that a
really good design must take into account lots more than circuits.
Hal Perkins uucp: {decvax|vax135|...}!cornell!hal
Cornell Computer Science arpa: hal@cornell
bitnet: hal@crnlcsmarc@emory.UUCP (07/05/83)
The original microprocessors were designed to operate video terminals. Thats about all they'll ever be good for... (not a lover a crapy 8-bit micro junk) -- Marco -- No flames any 8080, 6502 , etc... lovers... -- I don't care.
ptw@vaxine.UUCP (P. Tucker Withington) (07/05/83)
Personal opinion only and no offense... I think that unfortunately the first microprocessors were doomed to reinvent the wheel because hardware and software were still separate disciplines at that time. To a software type, the first u-cpu's looked like nothing more than a hardware type's attempt to formalize the finite state machines they had been building out of shift registers for years. The u-cpu instruction set was an accident of the Karnaugh map. Yes, the 4004 fell out of a contract to build a shift register for a calculator and the 8008 out of a contract for a CRT controller. Their use a cpu's was mostly fortuitous, as the many early programming hacks to implement stack disciplines (and register saves) make evident. The 6800/6502 were the first move to attempt to profit by the the existing knowledge of u-computers, and were modelled on the 11, within the limits of technology at the time. The 6502 group split off because they saw the limits as not as restrictive as the 6800 implementation would make one think. It's unfortunate that the [Z]80[.*] is a slave to upward compatibility, given its feeble root stock. It's unfortunate that the 6809 was left in the dust of its younger and abler cousin. But that's history and we can't really complain about whats being produced now. The 432 is even a little too advanced! ...end of personal opinion caveat. --Tucker (ptw@vaxine.UUCP)
mjl@ritcv.UUCP (07/05/83)
When I was in graduate school, I had a summer job working on a
relatively early 8080-based system: an electronic voting machine. It
quickly became apparent that though the 8080 was an engineer's dream
(at least in 1975), it was a programmer's nigtmare. What was worse,
since few of the engineers (at that time, anyhow) had any appreciation
of software problems, they would perform nifty circuit design tricks
that made such problems as interrupt handling much more difficult.
In any event, if you think the 808x series is fun, look up the specs on
the old Fairchild F8. Part of my job was to convert the 8080 code to
run on the F8. The instruction sets were wildly divergent, the memory
was cramped (2K bytes of RAM for all status variables and lever
counters), and of course all was in assembly language. Things reached
the ultimate in absurdity when I told the chief engineer that most of
my problems stemmed from the architectural incompatibility of the two
processors. His response: "What do you mean the architectures are
incompatible? They're both NMOS!"
Waiting for the perfect machine (will it be a RISC)?
Mike Lutz
{allegra,seismo}!rochester!ritcv!mjlgillies@mit-eddie.UUCP (07/06/83)
The osborne Microprocessor handbook states that both the Rockwell 6500 and Motorolla 6800 CPUs were designed as enhancements of the Intel 8008, not the 8080. As enhancements to the *8008*, I would say that Motorolla and Rockwell did a fairly nice job.
henry@utzoo.UUCP (Henry Spencer) (07/06/83)
Don't credit the 1802 with being a nice machine just because it
has been used in satellites. The space computer market is highly
specialized, and in particular they are willing to put up with
the most amazing atrocities in the architecture if the chips are
radiation-resistant. The 1802 was used for its radiation-hardened
CMOS-on-sapphire fabrication technology, not for its (gag) beauty.
--
Henry Spencer
U of Toronto
{allegra,ihnp4,linus,decvax}!utzoo!henrycrc@floyd.UUCP (07/06/83)
The COSMAC 1802 is produced by the Retrograde Corporation of America: RCA. The 1802 is not only elegant, it is painful to program. Subroutine return addresses are stored in one of 16 cpu registers. To address a location in memory, one must go indirect through a register. To load a register with a 16 bit address, one must do two ( load accumulator, transfer acc to register half). That's FOUR instructions to put an address in a register. # I don't remember the memnonics, but this is what you did. LDA low-half-of-address #byte loaded to acc STRL R1 #put acc in register low half LDA high-half-of-address #byte loaded to acc. STRH R1 #put acc in register high half. # now you can reference the memory location Electrically the COSMAC 1802 has a cute *feature*. The little beast does not have a 'memory select' line. It has 'read select' and 'write select' which it asserts when it is serious about an address on the address bus. Early COSMAC documention did not mention that during operations such as increment register, it throws the register contents out on the address bus. (presumably for debugging.) It is up to memory devices to restrain themselfs until 'memory read' or 'memory write' is asserted. I used one in a school project and found that I couldn't get anyone to program the bloody thing. The COSMAC is well suited for use in applications where there is little or no RAM and its registers can be used instead. AND where the programs involved are very simple, such as the triggers of Nuclear bombs which is an application where I believe it is used. (It was one of the first microprocessers available with radiation hardening.) Not afraid to dislike simple and crude architectures: Charles Colbert
bernie@watarts.UUCP (07/08/83)
The fact remains that despite their "terminal controller" roots, a lot of 8-bit micros are far more powerful than some of the bizarre minis that thrived during the sixties and seventies. Anyone out there ever program a Nova? --Bernie Roehl
bernie@watarts.UUCP (07/08/83)
Yes, the 1802 is truly ugly. However, it was never intended as a general- purpose processor; the reason it keeps its return addresses in registers is because there may be no RAM at all in the system (just the processor and some ROM). In fact, it's possible to design trivial 1802 systems at low cost for use in cars and cash registers and nuclear warheads. No one (aside from Popular Electronics and RCA itself) would seriously attempt to design a user-programmable micro around the 1802. --Bernie Roehl P.S. Similar comments apply to the Fairchild F8.
padpowell@wateng.UUCP (PAD Powell[Admin]) (07/08/83)
Ah yes, the 1802. This little gem has to be used to be believed.
I actually designed some data acquisition systems which used the
fool thing. The interface to other devices was quite ugly.
However, my giggles were only matched by the cries of pain and horror
of the programmers. For most (all) of them, it was their first
experience with assembler (ex Fortran types), and cross compilation.
When they got a development system that used the 1802, they ran some
assemblies (using paper tape!), and then all went out and got drunk.
Men were men, and chips were chips in those days, boy. None of this
"user-friendly" cr*p!
Patrick ("Ah, the good old days") Powellnewman@utcsrgv.UUCP (Ken Newman) (07/09/83)
Re lack of micros built around 1802 - I have seen one micro built around it (from Netronics?) with some kind of monitor, Basic, and Forth. I recall the embarassing delay while they tried strenuously to write a Basic for the wretched thing, and finally announced it with a big fanfare. Gawd, I can imagine what that code looks like.
ramsey@inmet.UUCP (07/12/83)
#R:rlgvax:-74100:inmet:2500002:000:749 inmet!ramsey Jul 11 18:26:00 1983 Quite a few of you seem to dislike the 1802. Apparently none of you have realized that the 1802 was not intended to be programmed in its assembly language. This fact was made quite clear in the first article I saw about the 1802 (in IEEE Computer, many moons ago). In fact, it was intended to support inner interpreters for such things as FORTH and P-code. Having written parts of a FORTH interpreter for the thing, I can attest to the success of their efforts. For a general mix of FORTH code, an 1802A was quite capable of outrunning both Z80s (2 mhz) and 8080As. Then again, I don't know too many Z80 based systems that could run for weeks off a pair of transistor radio batteries. As far as I'm concerned, the 1802 was ahead of its time.
andy@mit-vax.UUCP (Andy Beals) (07/14/83)
While it may be good for satelites, the 1802 is also a really cosmic (ahem) little processor - it is aoso good for any low power application and it makes a good little controller. While it may seem to be a pain to program the little bugger, it is just a matter of putting your mind into the right freame of mind - just as apl or lisp or forth all require swapping out your c generating software.