richard@gryphon.CTS.COM (Richard Sexton) (09/20/87)
Note: I have X-posted this because it is interesting to more that just Atari types. Followups to the appropriate places folks! So please edit the newsgroups line! In article <8709181728.AA13664@ucbvax.Berkeley.EDU> KEITH@SYSD.SALFORD.AC.UK writes: >I have not seen any mention of Atari in connection with Transputers >recently on the digests or in the U.S. magazines so I thought you might >be interested in this... > >Most of the British computer press have printed news articles over the >past few weeks about certain Atari contracts. Apparently, Atari have >reached an agreement of some sort with a U.K. company Perihelion to >develop a Transputer based prototype ! > >Very few actual details have appeared and some of these appear to >contracdict each other. Those aspects of the machine that do seem >firm are: > >Operating System: > HELIOS is being developed by Perihelion as the standard operating > system for Transputers (this is being aided by a recently awarded > government grant). The current plans are that HELIOS will look like > UNIX with a full X-Windows interface. > > They are also reported as wanting to promote the use of C for > transputers instead of Occam to ease porting of applicaions. > >Processor: > Almost certainly the T800 (20 mhz), very impressive even when used > as a single processor system. It is a 32 bit processor and includes > an on-chip floating point unit. > > One article I have seen quotes the performance of the slower T414 > processor (20 mhz) as 10 MIPS ! > >What is not clear is the form that this new machine will take. Perihelion >chairman, Jack Lang is reported to have said that the new machine will >have "its own bit-blitter and lightning graphics of at least 1024x768 >resolution". The same article credits Lang with three stages of the >product: > > 1. As an ST add-on. In some way this is supposed to allow existing > software to run unaltered and about five times faster !? > > 2. An all new machine with an ST inside the transputers box. > This requires software to be ported over (why?) though this is > supposed to be simple for GEM based (C?) programs. The article > claimed that this would result in a faster, more connectable and > expandable box than anything produced by DEC. > > Lang (and everybody else ?) hopes to bring this in for under > 1000 pounds ($1600). > >A British ST/Amiga Rival ?? >--------------------------- > >I thought that news of a British micro that is due for official >launch at the PCW Show in London this month would be of interest >to ST users. And others... >Acorn, a company that were not exactly a raging success when they >tried to launch their BBC Micro range of computers in the U.S., have >released a machine that they claim is the worlds fastest micro ! > >The Archimedes (I know, silly name) range of micros is based on >Acorns own RISC architecture processor (the ARM). This is a 32 >bit chip with 27 general purpose 32 bit registers. In its current >form it runs at between 4 and 8 MIPS though this is really limited >by the speed of the memory (Acorn have clocked ARMs up to 18 MIPS). I hope they wern't doing NOP's :-) >There are over 20 graphics modes ranging from 25 by 40 text up to >640 by 512 (and 1280 by 978 on the A400 series) in up to 256 >simultaneous colours (i.e. 8bits/colour) from a pallette of 4096. >There is no blitter chip, but you don't miss it - the processor is so >fast that a blitter really isn't needed. The advantage of having a seperate blitter is that you can have the blitter and CPU operating simultaneously. > Software Sprites of any size >and colour (depending on mode) are provided. > >Sound is similar to the AMIGAs, using wave form tables. There are >8 sound channels each with a stereo position from 1 (left) thru >128 (centre) to 255 (right). Speech is possible but not part of the >bundled sotware. > >The machine is incredible ! I haved played with one for a few minutes >and should be able to get access to one on loan within the next few >months. It is difficult to describe how fast this machine is but two >items do illustrate the fact: > > - The desktop environment shipped with early machines is > provided on disk and is written in interpreted BASIC ! > This will be changed for the final release versions but > even now this is the fastest windowing envronment I have > seen; everything happens instantaneously, windows simply > appear ! > > - A demontration version of a game, still in development, is > supplied with the machine. You guide a "lander" type craft > over a detailed surface made up of cubic patches. You can fly > the lander in ANY direction, towards and away from the screen, > over the valleys and lakes of the planet. All the particles, > splashes in the water, the rocket motors all behave > ballistically. It may turn out to be a terrible game but it > is an incredible demonstration of processing power. > >The Operating system offers a form of multi-tasking and there is a >true multi-tasking, unix like operating system under development for >the A400 series. A 6502 emulation that can run "legal" BBC Micro >programs is supplied with the machine and a software emulation of >the 8088 running MS-DOS should also be available - both of these >emulations are supposedly faster than the machines they mimic ! > >Up to 2 or 4 slots are supported in-machine and these will be able >to take a variety of cards. One of the first cards is a co-processor >unit with a 10MHz 80186 running MS-DOS. Others for the A400 series >will include a floating point unit (normally emulated in software so >no change in code is required) and even additional, faster, ARMs >working in parrallel ! > >One of the main problems I can see at present is that memory is >currently limited to 4 MB by the memory management unit even though >the processor can address at least 32 MBs. Also, the machine could do >with a decent set of bundled software instead of the demos currently >planned. > >Prices for the A300 series are close to those of the Atari MEGA ST2 and >the A400 series is around the price of an AMIGA A2000. > >Who knows whether Acorn will risk the U.S. market again but this >machine might push Atari into proceeding with the Transputer project ! > >Keith Wolstenholme >JANET: UK.AC.SALFORD.R-D I wish Acorn a lot of luck. This sounds like a King-Hell machine. Although I wonder how fast this thing really is compared to a 25Mhz 68020. And hey, if there are 25 Mhz 68020's is it possible to get faster ones as grade outs ? 'Bridge' was selling 12 Mhz Z-80 cards for UNIBUS using grade out 8Mhz Z-80's. just how fast can you push a 68020 anyway ? ----------------------- I have some serious doubts about the wisdom of posting to both ST and Amiga groups, but I thought perhaps this was sufficiantly interesting. So lets try to be nice this time, huh ? -- Richard J. Sexton INTERNET: richard@gryphon.CTS.COM UUCP: {hplabs!hp-sdd, sdcsvax, ihnp4, nosc}!crash!gryphon!richard "It's too dark to put the keys in my ignition..."
root@sbcs.UUCP (Root) (09/21/87)
> > One article I have seen quotes the performance of the slower T414 > > processor (20 mhz) as 10 MIPS ! RISC mips, unfortunately. By the same metric, an AMD29000 cranks at 25 MIPS, the Sun SPARC does 16 MIPS. According to folks on the transputer mailing list (actually a fellow at Pixar - GOOD HEAVENS!!!), a T{4,8}00-20 version transputer (thats 20 instructions per uSec) does about 6000 dhrytones with all frequently executed code in on chip ram. This is roughly equivalent to the performance I see out of a local 25 mhz 68020 cpu (Sun-3/260). Of course, when your application is bigger than the on chip 4K ram can handle and you're forced to off chip for memory accesses, things slow down. > > > > Lang (and everybody else ?) hopes to bring this in for under > > 1000 pounds ($1600). I would presume that the above figure assumes Inmos' figure of $70/T800 next year. I find this figure very ambitious, given pricing experiences with rival complexity silicon produced in the US - i.e. a 16 Mhz 68020 is still well over $100 in reasonable quantity, in spite of being available for several years. I would estimate from experiences with 80x86, 680x0 that the best they will be able to do will be about $200 or so in quantity by 4Q88 - assuming normal industry markups, the processor silicon would cost the user 3-5X the parts cost. Anyways, the intent of this message wasn't really to throw cold water on anyones product. Just some informed speculation based on my experience with Transputers & InMos.. Rick Spanbauer SUNY/Stony Brook
ljdickey@water.UUCP (09/30/87)
In article <607@sbcs.UUCP> root@sbcs.UUCP (Root) writes: >> > One article I have seen quotes the performance of the slower T414 >> > processor (20 mhz) as 10 MIPS ! > > RISC mips, unfortunately. You seem to imply that RISC mips are not quite as good as some other kind of MIPS. Are RISC mips slower somehow? Are more instructions needed to produce the same results? Explain, please. -- L. J. Dickey, Faculty of Mathematics, University of Waterloo. ljdickey@watmath.UUCP UUCP: ...!uunet!watmath!ljdickey ljdickey%water@waterloo.edu ljdickey@watdcs.BITNET ljdickey%water%waterloo.csnet@csnet-relay.ARPA
daveh@cbmvax.UUCP (10/02/87)
in article <1138@water.waterloo.edu>, ljdickey@water.waterloo.edu (Lee Dickey) says: > Xref: cbmvax comp.sys.atari.st:5283 comp.sys.misc:879 comp.sys.amiga:8794 > > In article <607@sbcs.UUCP> root@sbcs.UUCP (Root) writes: >>> > One article I have seen quotes the performance of the slower T414 >>> > processor (20 mhz) as 10 MIPS ! >> >> RISC mips, unfortunately. > > You seem to imply that RISC mips are not quite as good as some other kind > of MIPS. Are RISC mips slower somehow? Are more instructions needed to > produce the same results? Explain, please. MIPS -> Million Instructions Per Second. Sounds clear, right? Think again. The problem is that EVERY CPU known to man has some differences in instruction size, efficiency, etc. Look at the 6502 for instance. Been around for years, 8 bit processor with mainly 8 bit registers, without question the most popular CPU for cheap home computers (Apple II line and Commodore PET, VIC, and C64/C128 lines all use varients of this). Know what? Run one of these suckers at 4MHz, and you've got yourself a sustained 1 MIP machine, with a peak MIP rating of 2 MIPS. See, the average 6502 instruction completes in 4 clock cycles, some complete in as little as 2 cycles. I guess a VAX 11/780 gives you around 1 MIPS sustained, as well, but you're certainly not going to fall for the contention that a 4MHz 6502 is faster in any way than a VAX 11/780. Now, I bet you're saying, hold on a minute, you can't compare the two, a 6502 is only an 8 bit processor, and a VAX is a 32 bit processor. Well, that's true, but there's more to it than just that. The 6502 doesn't have an instruction for 16 or 32 bit adds, so if I want to add these sized numbers, I must use a subprogram. The VAX does it in one instruction. Same with a multiply instruction, or several other things that can happen. To put it plainly, the VAX gets a heck of alot more work done in any single instruction than a 6502. Now enter RISC. No one can tell you what RISC is, but they can tell you some of the concepts of RISC. Like "one instruction per cycle", "lots of internal registers", "hard-coded vs. microcoded instructions set", "simple design so we can use fast technologies that aren't sophisticated enough for CISC designs", "LOAD/STORE only get to access memory", etc. Most RISC processors (Berkeley, MIPS, SPARC, HP, ARM, Transputer, You-Name-It) use some of these ideas. Most of them run faster than comparable CISC processors, and most have simpler instructions. So they, like the 6502, get less work done in a single instruction than comparable CISC processors. Even different CISC processors running the same memory speed get different amounts of work done per instruction. What this all means is that "MIPS" is an unreliable rating, unless its somehow standardized. One way that's being used more and more is comparable MIPS. For instance, RISC Processor A delivers a peak of 20 MIPS, sustained of 5 VAX 11/780 MIPS. > L. J. Dickey, Faculty of Mathematics, University of Waterloo. > ljdickey@watmath.UUCP UUCP: ...!uunet!watmath!ljdickey > ljdickey%water@waterloo.edu ljdickey@watdcs.BITNET > ljdickey%water%waterloo.csnet@csnet-relay.ARPA -- Dave Haynie Commodore-Amiga Usenet: {ihnp4|caip|rutgers}!cbmvax!daveh "The B2000 Guy" PLINK : D-DAVE H BIX : hazy "Computers are what happen when you give up sleeping" - Iggy the Cat
cmcmanis%pepper@Sun.COM (Chuck McManis) (10/02/87)
In article <1138@water.waterloo.edu> (Lee Dickey) writes: >You seem to imply that RISC mips are not quite as good as some other kind >of MIPS. Are RISC mips slower somehow? Are more instructions needed to >produce the same results? Explain, please. MIPS is by definition, millions of instructions per second. Unfortunately, when you compare two different architectures the value of MIPS becomes meaningless because the instructions may not be equivalent. Typically, a RISC processor requires more instructions to accomplish a given computation than a CISC processor, so if both compute the same value in the same amount of time, say 1 second, it is only natural to want to rate them at the same 'computational power'. However if you compared the number of instructions that both processors had executed in that instruction you would find that the RISC processor had executed 10 to 50% more instructions. To get around this problem many people in the industry have picked the DEC VAX 11/780 as a 'standard' of 1 MIPS. (Note the added connotations to the MIPS unit of measurement that are not explicitly stated.) There are several known programs (both synthetic benchmarks and applications) that have been run on the VAX and carefully measured. These same programs can be run on the processor under test and the results measured and compared to the VAX numbers and then some estimation of "Vax MIPS" can be deduced. When everyone does this you can compare the "MIPS" number of each system and determine relative compute power. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
sansom@trwrb.UUCP (10/02/87)
In article <1138@water.waterloo.edu> ljdickey@water.waterloo.edu (Lee Dickey) writes: >In article <607@sbcs.UUCP> root@sbcs.UUCP (Root) writes: >>> > One article I have seen quotes the performance of the slower T414 >>> > processor (20 mhz) as 10 MIPS ! >> >> RISC mips, unfortunately. > >You seem to imply that RISC mips are not quite as good as some other kind >of MIPS. Are RISC mips slower somehow? Are more instructions needed to >produce the same results? Explain, please. RISC is an acronym for "Reduced Instruction Set Computer". This implies that the computer will take more instructions to accomplish a task which may take only one instruction on a computer with an "enhanced" instruction set (such as the 68000). This may be true, but the RISC computer may still be faster since the amount of time each instruction takes is less (or _much_ less) than the amount of time an instruction takes on an enhaced instruction set computer. Does that help any? -Rich -- /////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ /// Richard E. Sansom TRW Electronics & Defense Sector \\\ \\\ {decvax,ucbvax,ihnp4}!trwrb!sansom Redondo Beach, CA /// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/////////////////////////////////////
rpw3@amdcad.UUCP (10/03/87)
And to add to what Tim Olson said, it's ironic that the "reference 1 MIPS"
machine, the DEC VAX-11/780, runs about 0.5 "Native MIPS". That is, at some
time in the past, the 780 was compared against some other (probably IBM S/360)
machine for which (on some benchmarks) that machine ran at 1 (native) MIPS,
and so the VAX, being about the same speed (ON THOSE BENCMARKS!), came to be
called a "1 MIPS" machine. But if you look at how many *VAX* instructions a
VAX is executing per second when running the "common" scalar benchmarks
(nroff, ccom, etc.), you'll see that it's about 2 microseconds/instruction,
or about 0.5 Native MIPS.
See, the VAX is *really* a very CISC machine! Each of its instructions does
twice the work of a "1 VAX MIPS" machine! ;-} ;-}
(Come to think of it, I'll bet that the IBM S/360 architecture running the
Gibson Mix is close to one VAX MIPS per Native MIPS.)
Rob Warnock
Systems Architecture Consultant
UUCP: {amdcad,fortune,sun,attmail}!redwood!rpw3
ATTmail: !rpw3
DDD: (415)572-2607
USPS: 627 26th Ave, San Mateo, CA 94403gert@nikhefh.UUCP (Gert Poletiek) (10/04/87)
In article <1138@water.waterloo.edu> ljdickey@water.waterloo.edu (Lee Dickey) writes: >In article <607@sbcs.UUCP> root@sbcs.UUCP (Root) writes: >>> > One article I have seen quotes the performance of the slower T414 >>> > processor (20 mhz) as 10 MIPS ! >> >> RISC mips, unfortunately. > >You seem to imply that RISC mips are not quite as good as some other kind >of MIPS. Are RISC mips slower somehow? Are more instructions needed to >produce the same results? Explain, please. > >-- > L. J. Dickey, Faculty of Mathematics, University of Waterloo. > ljdickey@watmath.UUCP UUCP: ...!uunet!watmath!ljdickey > ljdickey%water@waterloo.edu ljdickey@watdcs.BITNET > ljdickey%water%waterloo.csnet@csnet-relay.ARPA I do not dare to compare ALL Risc type processors to the 68*** family of processors. I can however comment a bit on the T-series from Inmos. Inmos has three general purpose transputers and a couple of dedicated transputers. These are: the T212 the T414 and the T800 (the latter is available in test quantities only right now). The T212 is a 16 bit transputer with a 16 bit data AND address bus, thus being capable of addressing at most 64 KiloByte. The T414 is a 32 bit transputer with 32 data and address bus. The 800 is also a 32 bit transputer but in addition it has a on chip 64 bit IEEE floating point unit. The T414 is comparable to the 68000 or 68010, and the T800 is comparable to the set 68020/68881. All transputers have a memory interface, 2 KiloByte onchip memory (4Kb for the T800) and 4 serial interfaces. The serial interfaces are electrically asynchronous serial links on which a synchonous protocol is implemented in the micro code level. The serial links run at 20 MegaBits per second. The T800 is clocked at 20 MHz (and planned for next year? at 30 Mhz). The floating point unit operates at a speed of 1.5 MegaFlops. The main processor operates at a speed of 10 MIPS. Using the serial links (just two wires) it is very easy to built a network of transputers (well, a multi processor system). Data transfer primitives are implemented for them, also in micro code. The transputers are multi tasking processors. Multitasking is also supported by the hardware/micro code, resulting in a context switch that takes no more than 2 to 4 MicroSeconds. For processes running concurrently on the same processor the same data transfer primitives as those used for the serial links can be used. The transputers do not have on chip registers as the 68*** processors have. In stead they have a so called evaluation stack that works very similar to the register stack in a Hewlett Packard calculator. The instructions of the transputers are all the same length, making decoding easier and faster. Also there are a lot less instructions than in the 68***. This makes that possibly more instructions are needed on a transputer than on a 68***. The following table is published in several Inmos publications on the transputer performance (note that this is not a MIPS/Flops rating, but a more or less 'real-life' rating): processor clock Whetstones/second Intel 80286/80287 8 MHz 300 000 Inmos T414 20 Mhz 663 000 NS 32332/32081 15 Mhz 728 000 MC 68020/68881 16/12 Mhz 755 000 Fairchild Clipper 33 Mhz 2220 000 Inmos T800 20 Mhz 4000 000 Inmos T800 30 Mhz 6000 000 Hope this info helps a bit, Gert Poletiek NIKHEF-H, Dutch National Institute for Nuclear and High Energy Physics Kruislaan 409, P.O.Box 41882, 1009 DB Amsterdam, The Netherlands UUCP: {decvax,cernvax,unido,seismo}!mcvax!nikhefh!gert bitnet: nikhefh!gert@mcvax.bitnet, U00025@hasara5.bitnet
pes@ux63.bath.ac.uk (Smee) (10/05/87)
The point of RISC chips is that they can go faster because they have fewer, *simpler* instructions. It's based on the theory that the vast majority of instructions used (frequency of use in real code) are the simple ones, but they have to be slowed down and made tricky in order to accomodate the fancy high-powered instructions which the processors support (store multiple, move with edit, BCD math, etc...) By restricting the set of instructions to only the simple ones, the processor can be clocked much faster (more MIPS). The complex thingies are then constructed in assembler from the simple instructions. Whether this works or not depends on how true it is that your applications mostly uses the simpler instructions. If that's true, a RISC MIP is worth about the same as a non-RISC MIP. If your application uses lots of the more complex processor instructions, the RISC MIP is less meaningful, because you'll need more of them to perform the task at hand. Really what it comes down to is that you can't meaningfully compare RISC and non-RISC machines on the basis of MIPs, because the two sorts of MIPs are totally different.
bds@lzaz.ATT.COM (BRUCE SZABLAK) (10/07/87)
One major point about RISC that I haven't seen mentioned, is that a simpler instruction set implies that a LOT less silicon is devoted to micro-code. This silicon can be used for other things such as a large number of registers or, in the Transputers case, support of high speed serial communication lines. One reason RISC's execute faster is that access to on chip memory (e.g. registers) is faster than accessing off chip registers. Also, in some RISCs the instruction set is implemented using logic as opposed to micro-code which is usually faster too.
ccplumb@watmath.UUCP (10/08/87)
In article <21@lzaz.ATT.COM> bds@lzaz.ATT.COM (BRUCE SZABLAK) writes: >One major point about RISC that I haven't seen mentioned, is that a simpler >instruction set implies that a LOT less silicon is devoted to micro-code. >This silicon can be used for other things such as a large number of >registers or, in the Transputers case, support of high speed serial >communication lines. One reason RISC's execute faster is that access to >on chip memory (e.g. registers) is faster than accessing off chip registers. >Also, in some RISCs the instruction set is implemented using >logic as opposed to micro-code which is usually faster too. I'd just like to point out that almost *none* of this applies to the Transputer. It's got *lots* of microcode (to do multiprocessing and message passing, etc.), and no registers in the VAX/68000/most RISC chips sense. Some people (myself included) would argue that if the chip is microcoded, it isn't RISC. I certainly don't think the Transputer is a RISC chip. It's stripped down in some ways, but those ways aren't the ones "RISC" chips. use. Based on the power of what's built into microcode, it's a CISC. -- -Colin Plumb (watmath!ccplumb) Zippy says: Catsup and Mustard all over the place! It's the Human Hamburger!
dave@csustan.UUCP (david j wells) (10/08/87)
In article <21@lzaz.ATT.COM> bds@lzaz.ATT.COM (BRUCE SZABLAK) writes: >One major point about RISC that I haven't seen mentioned, is that a simpler >instruction set implies that a LOT less silicon is devoted to micro-code. Also the simpler silicon is much easier to develop. Less time. Less money. Fewer bugs. (kind of like the diffference between coding a linked list v. coding a B-tree ...) The complexity is moved into software (generally the compiler) and is therfore relatively trivial to modify (compared to fixing silicon). Can you say 386? :-) David -- ----- David J Wells lll-crg!csustan!dave dave@csustan.uucp
kim@amdahl.amdahl.com (Kim DeVaughn) (10/10/87)
In article <975@csustan.UUCP>, dave@csustan.UUCP (david j wells) writes: > > Also the simpler silicon is much easier to develop. Less time. Less money. > Fewer bugs. (kind of like the diffference between coding a linked list v. > coding a B-tree ...) That's for sure! When I was working for MIPS Computer Systems on the R2000 chip, our very 1st silicon was almost 100% functional. There were a couple of layout problems that lead to an unexpected diode-like device in one area, which resulted in a multiplier that wouldn't. This was fortunate, because we didn't get packaged parts back from the fab outfit until 12/23/85, and we had a contractual committment to deliver an alpha prototype to an early customer. We spent a day or so integrating the chip into the board, and found a couple logic and timing bugs with it (the board, not the chip). The machine executed it's 1st instructions in the wee hours of Christmas Day, and a new computer was born. There was sufficient functionallity to demonstrate "significant technical progress", as the contract required, and that customer sent us our first revenues ... a check for $1.5 million! Total time to R&D the R2000 was in the neighborhood of 9 months, not counting the architectural work done at Stanford that pretty much defined the MIPS architecture. In case you're wondering, that 1st "program" was a series of instruction test cases that indicated their progress by writing to a memory location that was in reality a set of 8 leds. Helluva lot to pay for a binary led counter ... :-)! > The complexity is moved into software (generally the compiler) and is > therfore relatively trivial to modify (compared to fixing silicon). > Can you say 386? :-) Since that 1st chip spin, a few more layout/fabbing problems were discovered, and a small number of logic design bugs were found, so we ended up with a couple more chip spins before we were satisfied with the part. But that's amazingly few for a ~100K gate chip! BTW, several of the logic bugs we eventually did find were easy to get around by having the compiler generate some "kluge" code ... no huhu, cobber! /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,ihnp4,uunet,oliveb,cbosgd,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25
daveh@cbmvax.UUCP (Dave Haynie) (10/12/87)
in article <1717@bath63.ux63.bath.ac.uk>, pes@ux63.bath.ac.uk (Smee) says: > Xref: cbmvax comp.sys.atari.st:5398 comp.sys.misc:909 comp.sys.amiga:8944 > > The point of RISC chips is that they can go faster because they have fewer, > *simpler* instructions. It's based on the theory that the vast majority > of instructions used (frequency of use in real code) are the simple ones, > but they have to be slowed down and made tricky in order to accomodate the > fancy high-powered instructions which the processors support (store multiple, > move with edit, BCD math, etc...) By restricting the set of instructions to > only the simple ones, the processor can be clocked much faster (more MIPS). > The complex thingies are then constructed in assembler from the simple > instructions. Actually, there's no reason why a complex CISC instruction should slow down the simpler form of the same instruction. There are a few reasons why CISC machines of today execute instructions slower than RISC machines. One factor is that a CISC instruction is often built using microcode, while a RISC instruction can be hard-wired in, since it is much simpler to implement. If the chips run at the same speed, the CISC machine will probably win here, since any one instruction gets more work done. However, all of the RISC stuff really has one overriding factor that lets it be faster per instruction that CISC, and that's the simplicity of the design. If I have a design that can be built in 20,000 gates instead of 200,000 gates, I can use a newer, faster IC technology. So while I'm building CISC chips in NMOS, I can take my new fast CMOS process and build the much smaller RISC part. When that CMOS process is mature enough to support the size of a CISC chip, I can build my RISC chip in the newer, faster submicron CMOS process. Once that process lets me build 200,000 gate chips, my yet even faster GaAs (or whatever) may be mature enough to let me build RISC. Of course you have to track the design of main memory along with all of this, too. Even if your RISC architecture can run 20 times the instruction rate of your CISC, if there's no main memory to support this, the RISC may loose big, since it needs to get more instructions executed per second to keep up with the more work per instruction aspect of CISC. So you get strange new architectures that are loosely termed RISC, like load/store architectures, on-chip RAM, lots of registers, etc. -- Dave Haynie Commodore-Amiga Usenet: {ihnp4|caip|rutgers}!cbmvax!daveh "The B2000 Guy" PLINK : D-DAVE H BIX : hazy "Computers are what happen when you give up sleeping" - Iggy the Cat