mark@mips.COM (Mark G. Johnson) (11/04/90)
Sometimes RISC evangelists will tell you is that if you choose a
simplified instruction set, you can build a fast CPU, using relatively
little hardware, on an aggressive schedule. That's why, (they say), the
first CPU chips in newly-available semiconductor technologies are likely
to be RISCs. For example, the first 32b uP's in Gallium Arsenide were
RISCs -- it was a good way to quickly crank out a fast machine while
staying within a constrained gate-budget, at a time when VLSI GaAs was
still slightly out-of-reach. {Disclaimer: occasionally, I propound
these views myself.}
RISCs, even 32-bit ones, were simple: the Acorn ARM is about 10K gates,
the Fujitsu SPARC is 20K gates + register file, the first MIPS ("R2000")
is 110K transistors {about 30K gates}, and the MC88000's integer CPU
was small enough that, even in the first implementation, there was
enough room on the chip to include floating point hardware. Call it
30K gates for the 88000's integer CPU.
Now, perhaps, today's world is different. Lots of ASIC vendors are
glad to sell you sea-of-gates gate arrays which contain well over
100,000 usable gates. These are available in CMOS, BiCMOS, BiCMOS-ECL,
and recently, Gallium Arsenide. If you're willing to limit your options
to straight CMOS, the number is closer to 200K usable, wireable gates.
A little bit of trivial finger-counting reveals that 100K+ gates is
enough to do something potentially interesting. Therefore I put
forward the idea that a multiple-CPU-on-the-same-chip processor is
now feasible, practical, and (controversy coming:) useful. How about
spending the gate budget as follows:
SPARC CPU: 30K gates } all of these reside on the
MIPS CPU: 30K gates } same die, a 100K gate array
i286 CPU: 30K gates } in BiCMOS technology
If this chip were finished, complete, debugged, and available today,
imagine the cool things you could do with it. Also imagine the
Budzillions of dollars' worth of software already written for your
machine. Also imagine the frolic and fun of porting the O/S's and
other system software onto this three-brained, schizophrenic machine.
"An excellent source of thesis topics," as they say at 6100 Main in
Houston.
Of course you could pick other CPUs if you like; the slick thing is
that the reduced instruction set ones enable you to slap several of
em on the same die and still have room "left over" for a 286, a Z80,
and a couple of 6502's. How about a 200Kgate CMOS array having an
Am29000, a CRISP, 2 Transputers, an 88k, and a 286? Or how about
6 SPARCs and MMUs on the same chip?
Given the obvious desirability and superiority of this idea :-),
why are some folks instead using millions of gates, spread across
several chips, to implement a single CPU (e.g. NexGen, Metaflow,
SpEc, Edge)? :-)
--
-- Mark Johnson
MIPS Computer Systems, 930 E. Arques M/S 2-02, Sunnyvale, CA 94086
(408) 524-8308 mark@mips.com {or ...!decwrl!mips!mark}henry@zoo.toronto.edu (Henry Spencer) (11/04/90)
In article <42737@mips.mips.COM> mark@mips.COM (Mark G. Johnson) writes: >spending the gate budget as follows: > > SPARC CPU: 30K gates } all of these reside on the > MIPS CPU: 30K gates } same die, a 100K gate array > i286 CPU: 30K gates } in BiCMOS technology Actually, I suggested something like this quite a while ago, when some Intel bigshot had mumbled in public about soon being able to put four CPUs on a single chip and what can we possibly do with it all. If you're Intel, it's obvious: one 860, one 486, one 80960, and fill up the last slot with odds and ends like 8080, 8008, 4004, 2920, etc. Then you at last have compatibility among Intel CPUs: one chip runs software for any of them! -- "I don't *want* to be normal!" | Henry Spencer at U of Toronto Zoology "Not to worry." | henry@zoo.toronto.edu utzoo!henry
pcg@cs.aber.ac.uk (Piercarlo Grandi) (11/05/90)
On 3 Nov 90 22:46:12 GMT, mark@mips.COM (Mark G. Johnson) said, somwhat tongue in cheek: mark> Sometimes RISC evangelists will tell you [ ... that RISC CPUs need mark> ridiculously low gate counts, 10k to 30k and that this means that mark> one can build RISC cpus with very advanced, low density mark> technologies ... ] Note that the gate counts of some non RISC chips were also low; the original 68k, the 286, the Z8000. mark> Now, perhaps, today's world is different. Lots of ASIC vendors are mark> glad to sell you sea-of-gates gate arrays which contain well over mark> 100,000 usable gates. mark> A little bit of trivial finger-counting reveals that 100K+ gates is mark> enough to do something potentially interesting. Therefore I put mark> forward the idea that a multiple-CPU-on-the-same-chip processor is mark> now feasible, practical, and (controversy coming:) useful. Ahem. This was the subject of some of my earlier postings: why not have multiple RISC CPUs on a chip instead of a single superscalar one. Nobody bothered to reply... Sigh sigh... But now you add a perverse twist to this idea: mark> How about spending the gate budget as follows: mark> SPARC CPU: 30K gates } all of these reside on the mark> MIPS CPU: 30K gates } same die, a 100K gate array mark> i286 CPU: 30K gates } in BiCMOS technology mark> If this chip were finished, complete, debugged, and available mark> today, imagine the cool things you could do with it. Also imagine mark> [ ... other similar perversions ... ] Your idea is crazy, but not crazy enough to be marketable :-). Given that the main attraction of the greatest commercial successes in computer architecture, the 370 and 80x86 lines, is protection of software investment, I think that the best idea would not be to have a chip with multiple RISC souls, because the RISC instruction sets are too recent and too few dusty decks run on them. What about a chip with the 1100, 6000, 370, 6502, 8080, 80286, 68000, instruction sets on it? I don't think that a simple implementation (with some instructions trapped) of any of these would take a lot of gates. mark> Given the obvious desirability and superiority of this idea :-), mark> why are some folks instead using millions of gates, spread across mark> several chips, to implement a single CPU (e.g. NexGen, Metaflow, mark> SpEc, Edge)? :-) Now let's instead switch to very serious mode: What about the IBM RS/6000 that is a 3-4-5 way superscalar and takes 6 million transistors and is not ROMP compatible? Are superscalable instruction sets necessarily different from currently existing ones? Do you need millions of transistors to build a superscalar? Again, is it better to spend a large transistor budget on a superscalar CPU, with a new, superscalar oriented instruction set, or on multiple CPUs on a chip with an existing RISC instruction set? -- Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
pcg@cs.aber.ac.uk (Piercarlo Grandi) (11/06/90)
On 4 Nov 90 01:49:01 GMT, henry@zoo.toronto.edu (Henry Spencer) said:
henry> In article <42737@mips.mips.COM> mark@mips.COM (Mark G. Johnson) writes:
henry> Actually, I suggested something like this quite a while ago, when some
henry> Intel bigshot had mumbled in public about soon being able to put four
henry> CPUs on a single chip and what can we possibly do with it all. If you're
henry> Intel, it's obvious: one 860, one 486, one 80960, and fill up the last
henry> slot with odds and ends like 8080, 8008, 4004, 2920, etc. Then you at
henry> last have compatibility among Intel CPUs: one chip runs software for
henry> any of them!
Except for oddities like the 860 and 960, isn't the 486 still designed
to be almost binary compatible with the 8008? Sigh!
--
Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.ukdavidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (11/06/90)
In article <PCG.90Nov5195229@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: | Except for oddities like the 860 and 960, isn't the 486 still designed | to be almost binary compatible with the 8008? Sigh! As far as I know the 80486 and 8008 are completely compatible at the level of the first two digits of the part number. The instruction set is 100% diferent, so the only binary compatibility is that they both will read ones and zeros. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) The Twin Peaks Halloween costume: stark naked in a body bag
andras@alzabo.uucp (Andras Kovacs) (11/07/90)
I would like to invite everyone to read the "IBM Research Journal"
describing the POWER architecture (what a name, eh? Performance Optimization
With Enhanched RISC - the prototype's codename was AMERICA).
Anyway, I enjoyed the hardware overview of the chip very much. Previously
I thought that "this must be an over-engineered chip if they used 6 million
transistors". But after reading about it, I feel that the RISC 6000 is a true
state-of-the art chip which incorporates the latest research technology.
(I am not an EE, sadly).
So I am not convinced that the right thing is to put multiple processors
on the same die. I believe the solution will be some very fast VLIW chip
with minimum instruction set which will be able to emulate all today's CISC
chips (and probably RISC ones as well) at a reasonable speed. My 4 MIPS ARM
can emulate an 8086 + the PC hardware (which is a bitch) at a ratio of 1.4
to the original 4.77 MHz IBM PC. Apparently the (roughly) 12 MIPS ARM3 can
emulate at the speed of a PC AT (even at the original 6 MHz, that's not bad
for me). So I expect that a 100-150-200+ MIPS VLIW MISC chip could do a
beautiful job of emulating ANY of today's chips at a reasonable rate.
This was my $0.02's worth :-)
--
Andras Kovacs
andras@alzabo.UUCPjbuck@galileo.berkeley.edu (Joe Buck) (11/07/90)
In article <2841@crdos1.crd.ge.COM>, davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes: > In article <PCG.90Nov5195229@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: > > | Except for oddities like the 860 and 960, isn't the 486 still designed > | to be almost binary compatible with the 8008? Sigh! > > As far as I know the 80486 and 8008 are completely compatible at the > level of the first two digits of the part number. The instruction set is > 100% diferent, so the only binary compatibility is that they both will > read ones and zeros. Well, they are pretty much compatible at the assembly language level. When the 8086 was first announced, one of Intel's big claims was that, although the binary encoding had changed, you could reassemble your 8080 programs and they would run on the 8086. Since the 8080 is the 8008 plus some extra instructions, and since the 80486 supports 8086 instructions, it therefore follows that yes, you can run your 8008 assembly language programs on the 80486; however, you need a 8008 (or 8080) disassembler followed by an 80486 (or 8086) assembler to do it. So Piercarlo is essentially correct. -- Joe Buck jbuck@galileo.berkeley.edu {uunet,ucbvax}!galileo.berkeley.edu!jbuck
moliver@shadow.pyramid.com (Mike Oliver) (11/07/90)
In article <39409@ucbvax.BERKELEY.EDU> jbuck@galileo.berkeley.edu (Joe Buck) writes: >In article <2841@crdos1.crd.ge.COM>, davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes: >> In article <PCG.90Nov5195229@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >> >> | ... isn't the 486 still designed >> | to be almost binary compatible with the 8008? Sigh! >> >> The instruction set is >> 100% diferent, so the only binary compatibility is that they both will >> read ones and zeros. > >Well, they are pretty much compatible at the assembly language level. >When the 8086 was first announced, one of Intel's big claims was that, >although the binary encoding had changed, you could reassemble your >8080 programs and they would run on the 8086. Nope. Intel claimed that large chunks of your ASM80 code could be massaged into ASM86 with the assistance of some program (I forget its name; it ran on the blue-box MDS's), but that some human intervention would probably be necessary. For anything of any complexity it was faster and ultimately more reliable to recode by hand. > Since the 8080 is the >8008 plus some extra instructions, and since the 80486 supports 8086 >instructions, it therefore follows that yes, you can run your 8008 >assembly language programs on the 80486; however, you need a 8008 >(or 8080) disassembler followed by an 80486 (or 8086) assembler to do >it. So Piercarlo is essentially correct. Piercarlo is wrong, possibly pending some better definition of what "almost binary compatible" means. Even if the translation from ASM80 to ASMx86 were completely automated and 100% reliable, that would establish only source (and not binary) compatibility. To put it another way: I have some C code that will compile and run on 680x0, 80x86 and a number of other architectures. Does this mean that the 680x0 is binary compatible with the 8008 ? Cheers, Mike. moliver@pyramid.com {allegra,decwrl,hplabs,munnari,sun,utai,uunet}!pyramid!moliver
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (11/07/90)
In article <39409@ucbvax.BERKELEY.EDU> jbuck@galileo.berkeley.edu (Joe Buck) writes: | Well, they are pretty much compatible at the assembly language level. | When the 8086 was first announced, one of Intel's big claims was that, | although the binary encoding had changed, you could reassemble your | 8080 programs and they would run on the 8086. Just isn't so. The claim was that you could run your 8080 assembler through a compiler (they sad translator) which generated the 8086 assembler source. It did this by actual flow analysis as well as just changing the mnemonics. The resulting program will only use a total of 64k code and data, rather than take advantage of any of the capability of the 8086. The product is XLT-86, runs on CP/M-86, and I ran about 100k lines of code through my copy at work. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) The Twin Peaks Halloween costume: stark naked in a body bag
andras@alzabo.uucp (Andras Kovacs) (11/08/90)
In article <2841@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes: >In article <PCG.90Nov5195229@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: > >| Except for oddities like the 860 and 960, isn't the 486 still designed >| to be almost binary compatible with the 8008? Sigh! > > As far as I know the 80486 and 8008 are completely compatible at the >level of the first two digits of the part number. The instruction set is >100% diferent, so the only binary compatibility is that they both will >read ones and zeros. Although Mr. Grandi was somewhat lax in his wording, it is a fact that the 8086 was designed to be 'object level compatible' with the 8080 - I don't know about the 8008. The term means that a programmer (coder? software engineer? :-)) who had experience with the 8080 (supposedly in an embedded-controller context) would be able to 'translate' any existing code to the 8086 rather quickly + be able to use the added benefits of the 16-bit architecture. (Think about dedicated registers: A-AX (accu.), B-BX/C-CX (pointer, counter), D-DX/E-??? (gen. purpose 16bit reg.), HL/BP-SI-DI (dedicated pointer regs.)). So in this sense, the 486 indeed propagates an outdated programming model which was intended primarily for the controller market - and kept certain compatibility with the 8080. The problem did come with the IBM PC and its 8088 - an IBM dude said in Byte's 15th anniversary issue that they picked the 8088 as the CPU for the IBM PC 'cause THEY HAD DEVELOPMENT EXPERIENCE WITH THE 8080 AND IT'S 8 BIT PERPHERALS! (NB the IBM PC was done by Entry Systems Division of IBM - they basically wanted an 'intelligent RJE' which can run programs on it's own). How comes that IBM doesn't try to conquer the workstation market based on Intel 486/586/??????86 ? Because they know (I assume) that the 486/386/286/8086/8080 programmer's model SUCKS, and although with better manufacturing technology they can speed it up (386/486), it's doesn't really worth the effort except providing blindingly fast f*****g DOS machines! Which is fine by me, I would like to see all the world's x86es recalculating huge Lotus 1-2-3 spreadsheets in 1 zillionth of a second and let me fiddle with my cute RISC processor to solve 'real problems'! (Which are real problems? I don't know, I am just an immigrant... :-)) I am not damning the emergence of the IBM PC - that sucker indeed did give power to the people. But I loathe the x86 line after meeting Miss RISC and I would like to quote someone's .signature (can't recall whose): "To understand and appreciate a 386 is mutually exclusive." (Sorry for the long article :-)) -- Andras Kovacs andras@alzabo.UUCP
cik@l.cc.purdue.edu (Herman Rubin) (11/08/90)
In article <42737@mips.mips.COM>, mark@mips.COM (Mark G. Johnson) writes: .................... | SPARC CPU: 30K gates } all of these reside on the | MIPS CPU: 30K gates } same die, a 100K gate array | i286 CPU: 30K gates } in BiCMOS technology > If this chip were finished, complete, debugged, and available today, > imagine the cool things you could do with it. Also imagine the > Budzillions of dollars' worth of software already written for your > machine. Also imagine the frolic and fun of porting the O/S's and > other system software onto this three-brained, schizophrenic machine. > "An excellent source of thesis topics," as they say at 6100 Main in > Houston. So you would have 3 highly limited CPUs with largely similar capabilities. Big deal. Or by intelligently designing the operations so that different operations could use the same gates, you could get most, if not all, of the operations suggested by posters to this net, as well as other things which can be done quickly in hardware but are slow in software. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!hrubin(UUCP)
brent@uwovax.uwo.ca (Brent Sterner) (11/08/90)
In article <2722@l.cc.purdue.edu>, cik@l.cc.purdue.edu (Herman Rubin) writes: > In article <42737@mips.mips.COM>, mark@mips.COM (Mark G. Johnson) writes: > > .................... > > | SPARC CPU: 30K gates } all of these reside on the > | MIPS CPU: 30K gates } same die, a 100K gate array > | i286 CPU: 30K gates } in BiCMOS technology Sorry if this has been suggested before, but why not: 3 of SPARC CPU: 30K gates or 3 of MIPS CPU: 30K gates or 3 of i286 CPU: 30K gates ie, 3 different dies. Integrate each with a symmetric multi-processing os (ooops, my s/w background is showing :-) to really exploit the capacity of the chip. Most people I know have a favourite system, and do *not* switch among systems like the above (necessity excepted). Could be a screamer in a ws environment, provided you could handle the io. -- Brent Sterner Technical Support Manager, Academic Systems Fast: <BRENT@uwo.ca> <BRENT@UWOVAX.BITNET> <129.100.2.13> Telephone (519)661-2151 x6036 Slow: Computing & Communications Services, Natural Sciences Building The University of Western Ontario, London, Ontario, Canada N6A 5B7
pcg@cs.aber.ac.uk (Piercarlo Grandi) (11/08/90)
On 6 Nov 90 23:05:22 GMT, moliver@shadow.pyramid.com (Mike Oliver) said: moliver> In article <39409@ucbvax.BERKELEY.EDU> moliver> jbuck@galileo.berkeley.edu (Joe Buck) writes: jbuck> In article <2841@crdos1.crd.ge.COM>, davidsen@crdos1.crd.ge.COM jbuck> (Wm E Davidsen Jr) writes: davidsen> In article <PCG.90Nov5195229@odin.cs.aber.ac.uk> davidsen> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: pcg> ... isn't the 486 still designed to be almost binary compatible pcg> with the 8008? Sigh! davidsen> The instruction set is 100% diferent, so the only binary davidsen> compatibility is that they both will read ones and zeros. Well, the *encoding* of the instruction set is 100% different, but the flavour of the register level architecture has been carefully preserved -- the 8008 architecture is actually a *subset* of the 486 one. It is much the same story as the HP1000 line of machines, or the Pr1me series 50 one. Backwards compatibility at any cost. jbuck> Well, they are pretty much compatible at the assembly language jbuck> level. When the 8086 was first announced, one of Intel's big jbuck> claims was that, although the binary encoding had changed, you jbuck> could reassemble your 8080 programs and they would run on the jbuck> 8086. moliver> Nope. Intel claimed that large chunks of your ASM80 code could moliver> be massaged into ASM86 with the assistance of some program [... moliver> but in the end ... ] it was faster and ultimately more reliable moliver> to recode by hand. Well, isn't the distance between claim and reality always a bit large? Still: moliver> Piercarlo is wrong, possibly pending some better definition of what moliver> "almost binary compatible" means. Well, I stretched things a bit here :-), "almost" is used in a less usual qualitative sense, not the more common quantitative one. "Almost binary" was indeed meant to be "at the assembler/architecture level". The 8086 was consciously and unconsciously designed as the successor to the 8080, and effort was expended to make it feel as familiar as possible to 8080 programmers, for obvious commercial reasons. Consider: NEC sells a processor that can run both 8080 and 8086 programs (the V20). I doubt that apart from the decoder there is much difference between the implementations of two modes. I think that it would not have been that easy to haven 8086/6502 chip instead. And indeed note that you cannot (I am not that usre on this) run concurrently 8080 and 8086 programs on the chip, i.e. it does not have two fully distinct CPUs. Incidentally: this shows that Mark Johnson's perverse idea on multiple CPUs on a chip is not entirely new... My point was the same that is repeated here and there in the Isaacson et. al. book on the 386 - the 80386 was designed to be broadly backwards compatible with the 8086, which was designed to be broadly backwards compatible with the 8080, which was designed to be broadly backwards compatible with the 8008. This bible like lineage still is apparent in many architectural aspects of the 80386 architecture, which indeed does still uncannily resemble that of the 8008 -- a matter of degree, of course, but strong enough. In a private e-mail message (still thinking over it) I received a claim that the 80x86 architecture is the best micro CISC around, the argument being that the essential flavour of its architecture is uniquely suited by design to be implemented as a micro -- for example dedicated registers (a feature that I like, incidentally). Whatever the merit of this claim, it is essentially based on the idea that the 8008/8080/8086/80386 lineage is the right one. This may be disputed, but it is intriguing to note the argument. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
hamilton@dg-rtp.dg.com (Eric Hamilton) (11/09/90)
In article <7692.27393066@uwovax.uwo.ca>, brent@uwovax.uwo.ca (Brent Sterner) writes: |> In article <2722@l.cc.purdue.edu>, cik@l.cc.purdue.edu (Herman Rubin) writes: |> > In article <42737@mips.mips.COM>, mark@mips.COM (Mark G. Johnson) writes: |> > |> > .................... |> > |> > | SPARC CPU: 30K gates } all of these reside on the |> > | MIPS CPU: 30K gates } same die, a 100K gate array |> > | i286 CPU: 30K gates } in BiCMOS technology |> |> Sorry if this has been suggested before, but why not: |> |> 3 of SPARC CPU: 30K gates or |> 3 of MIPS CPU: 30K gates or |> 3 of i286 CPU: 30K gates |> |> ie, 3 different dies. Integrate each with a symmetric |> multi-processing os (ooops, my s/w background is showing :-) |> to really exploit the capacity of the chip. Most people I |> know have a favourite system, and do *not* switch among |> systems like the above (necessity excepted). Could be a screamer |> in a ws environment, provided you could handle the io. |> -- Well, yeah, but how are you going to feed this beast? It wants data and instructions in vast quantities..... Somehow you have to deliver three instructions per clock cycle, and at least one data transaction.... Put a unified cache in the chip with the three processors, and then you'll have a system with no snooping/intervention/writeback penalties. That will run your favorite symmetrical multiprocessor OS fast, if the cache is big enough. But we're chewing up space at a most discouraging rate. You won't like the consequences of putting the cache outside.
przemek@liszt.helios.nd.edu (Przemek Klosowski) (11/10/90)
In article <PCG.90Nov8151919@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >Consider: NEC sells a processor that can run both 8080 and 8086 programs >(the V20). I doubt that apart from the decoder there is much difference >between the implementations of two modes. I think that it would not have >been that easy to haven 8086/6502 chip instead. And indeed note that you >cannot (I am not that usre on this) run concurrently 8080 and 8086 >programs on the chip, i.e. it does not have two fully distinct CPUs. > Of course you cannot run concurrently 8080 and 8086: how do you suppose they will share the bus? on the other hand, the 8086 binary code can be called from 8080 code (but it can't nest). I would suggest to slowly wind down the discussion of the compatibility between 8086 and 8080. I feel that all relevant arguments were stated, sometimes redundantly. Just to show you that I too have an opinion, I will say that I believe most microprocessor architectures fall into small number of flavors, and within each flavor translation between the ASSEMBLY languages is automatic in 95% and possibly highly nontrivial in 5%. It is source code compatibility in any case. C has the better of it. -- przemek klosowski (przemek@ndcva.cc.nd.edu) Physics Dept University of Notre Dame IN 46556
feustel@netcom.UUCP (David Feustel) (11/10/90)
I got hooked on the 8086 family in part because character string operations are done so much better there than in any other machine I've looked at and also because the 8086 followed the Multics hardware model documented by Organik in his book on Multics. -- David Feustel, 1930 Curdes Ave, Fort Wayne, IN 46805, (219) 482-9631
ingoldsb@ctycal.UUCP (Terry Ingoldsby) (11/16/90)
> In article <PCG.90Nov5195229@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: > > | Except for oddities like the 860 and 960, isn't the 486 still designed > | to be almost binary compatible with the 8008? Sigh! I think what you are remembering is that when the 808(6/8) first came out, Intel made available a tool that would convert most 8080 code to 8086 code. As I recall, it sort of assigned certain 8080 registers to match 8086 registers, and either used instructions that performed the same operation or a sequence of instructions to get the same effect. I don't believe it was 100% effective, but was intended to assist software developers in getting their code converted quickly. I may be wrong. -- Terry Ingoldsby ctycal!ingoldsb%cpsc.ucalgary.ca Land Information Services or The City of Calgary ...{alberta,ubc-cs,utai}!calgary!ctycal!ingoldsb