cpca@iceman.jcu.oz (C Adams) (10/30/90)
I found this in comp.sys.m88k ...... >There's an Apple ad in the "help wanted -- engineering" section of >today's local (Portland Oregon) newspaper. They're looking for >diagnostics writers to work on the "RISC Macintosh" and they're looking >for 88k assembly language experience. > -=- Andrew Klossner (uunet!tektronix!frip.WV.TEK!andrew) [UUCP] > (andrew%frip.wv.tek.com@relay.cs.net) [ARPA] So it looks like Macintosh are already placing even bets on whether CISC can keep up with RISC. If they're already starting on an 88k based Macintosh, perhaps C= should at least be showing some interest. So what would we want a RISC Amiga to be based on, 88k? Sparc? i860? MIPS? What about compatibility with existing software? I doubt C= have the money to devote any time to a RISC amiga when they seem to be having problems finding resources to devote to their existing Amiga products... Colin Adams You need to have a woman, before you can have a Sun :-) Email Address - cpca@marlin.jcu.edu.au
ckp@grebyn.com (Checkpoint Technologies) (10/31/90)
In article <1156@iceman.jcu.oz> cpca@iceman.jcu.oz (C Adams) writes: >So what would we want a RISC Amiga to be based on, 88k? Sparc? i860? MIPS? Given the Amiga product philosphy of "inexpensive", I'd have to guess the AMD29K. They're real cheap, and quite fast. After that I think 88K, because of the Motorola heritage of the Amiga. Plus I just read that Motorola dropped the price of the 88K chip set, don't remember how low. Still much higher than a 68030. >What about compatibility with existing software? Forget about it. RISC is a new architecture, a new instruction set, a new philosophy. On the other hand, the 68040 is as fast as current-generation RISC chips. So why go RISC at all? -- First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / / \\ / / Then, the disclaimer: All expressed opinions are, indeed, opinions. \ / o Now for the witty part: I'm pink, therefore, I'm spam! \/
daglem@solan.unit.no (Dag Lem) (10/31/90)
In article <1156@iceman.jcu.oz>, cpca@iceman.jcu.oz (C Adams) writes: |> So what would we want a RISC Amiga to be based on, 88k? Sparc? i860? MIPS? |> What about compatibility with existing software? |> We don't want a RISC amiga! Software compatibility? Are you joking? If you want speed, opt for a 68040. It may do fewer MIPS than RISCS, but that's NOT the way to compare 68040 with RISCS (or any other processor, for that matter). The 68000 series can perform rather complex operations with one instruction. Most RISCS do virtually nothing with one instruction. Guess you've been reading too many ads stating '..running at xx MIPS! Compare this to ..' :-) |> |> Colin Adams You need to have a woman, before you can have a Sun :-) |> Email Address - cpca@marlin.jcu.edu.au __ / |> Shorter of breath / \ __ __ / ___ _ _ |> and one day closer to death. / |/ / / / / /__/ / / / |> -Roger Waters, Time /____/ \_/|/\_/ /____\___/ / \__________ |> (Dark Side of The Moon) ______________/
ken@dali.gatech.edu (Ken Seefried iii) (10/31/90)
In article <22914@grebyn.com> ckp@grebyn.UUCP (Checkpoint Technologies) writes: >In article <1156@iceman.jcu.oz> cpca@iceman.jcu.oz (C Adams) writes: >>So what would we want a RISC Amiga to be based on, 88k? Sparc? i860? MIPS? > >Given the Amiga product philosphy of "inexpensive", I'd have to guess >the AMD29K. They're real cheap, and quite fast. After that I think 88K, >because of the Motorola heritage of the Amiga. Plus I just read that >Motorola dropped the price of the 88K chip set, don't remember how low. >Still much higher than a 68030. > First...the AMD29K is a tremendously unlikely choice. First, almost noone (maybe one company) uses it as a general purpose CPU, and AMD does not market it as such. It is used almost exclusively in embedded systems applications. It also has some not-insubstantial memory sub- system requirements (the optimal configuration implimented with VRAMS) that doesn't seem, to me at least, to lend itself to inexpensive implimentation, especially in the 8+MB range. Someone with direct 29k hardware experience should comment further. Second...loyalty to motorola seems to be a signal to *not* use the 88k (witness Sun(SPARC), SGI(MIPS), NCR(80x86), etc.). Both SPARC and MIPS can be had for less money than the 88k, and both currently have installed base advantages over the 88k. The 88k is a damn nice chip (I *love* the Tek XD88/10 on my desk at work), but there are some real caveats in the market (not technically) in using it. This has been hashed out over (inconclusively) in comp.sys.m88k and by e-mail. I'd bet that C/A could make a helluva a run at the SPARC clone market (something that is about to take off...). A low-priced colour AmigaSPARC would *really* be popular. >>What about compatibility with existing software? > >Forget about it. RISC is a new architecture, a new instruction set, a >new philosophy. This is simply not true. I regularly run MS-DOS programmes on a SPARCStation 1 using SoftPC (a programme that has been ported to the MIPS, 88k and (I think) the 29k as well). The IBM RS/6000 emulates a 386 completely in software as fast as a real 386 in many cases. RISC processors very much lend themselves to emulating other machines (within limits). A RISC simulator of an Amiga, while probably not easy, is certainly doable by reasonably sharp team. Hell, it might be easier than SoftPC since the 68k instruction set is so much cleaner and more orthoginal that the Intel rubbish. -- ken seefried iii "A snear, a snarl, a whip that ken@dali.gatech.edu stings...these are a few of my favorite things..."
torrie@Neon.Stanford.EDU (Evan James Torrie) (10/31/90)
ckp@grebyn.com (Checkpoint Technologies) writes: >In article <1156@iceman.jcu.oz> cpca@iceman.jcu.oz (C Adams) writes: >>What about compatibility with existing software? >Forget about it. RISC is a new architecture, a new instruction set, a >new philosophy. >On the other hand, the 68040 is as fast as current-generation RISC >chips. So why go RISC at all? Because next year's implementation of RISC (the 88110) will be about two to three times faster than next year's implementation of the 68040 (even with the 040 running at 50MHz) -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu Jim Bolger - a National landslide of incompetence
gilgalad@caen.engin.umich.edu (Ralph Seguin) (10/31/90)
In article <22914@grebyn.com> ckp@grebyn.UUCP (Checkpoint Technologies) writes: >In article <1156@iceman.jcu.oz> cpca@iceman.jcu.oz (C Adams) writes: >>So what would we want a RISC Amiga to be based on, 88k? Sparc? i860? MIPS? > >Given the Amiga product philosphy of "inexpensive", I'd have to guess >the AMD29K. They're real cheap, and quite fast. After that I think 88K, >because of the Motorola heritage of the Amiga. Plus I just read that >Motorola dropped the price of the 88K chip set, don't remember how low. >Still much higher than a 68030. The 040 kills the 88000 in floating point, but the 88000 is much faster than the 040 in a bunch of other things. I think that C= is concentrating on delivering excellent price/performance. The 860 would make an excellent co-processor. I don't think any chip other than the 040 is suitable for use as a replacement processor simply because of code compatability. Emulating a microprocessor with another uP is SLOW! Now, can Amiga OS and Amiga UNIX handle multi-processing on a heterogeneous network of processors? I can see my Amiga with 2 i860s an i960 and 10 040s. Of course, my pocketbook can see none of this 8-( >On the other hand, the 68040 is as fast as current-generation RISC >chips. So why go RISC at all? Eventually, CISC will not be able to keep up. The design philosophies in RISC are generally better. I don't think that cranking up the clockrate is the answer at all. Make the instructions themselves run faster. That was the philosophy behind IBM in their POWER RISC boxes. I can tell you that these machines are VERY nice. Besides, they can always crank up the clockrate later 8-) >First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / / > \\ / / >Then, the disclaimer: All expressed opinions are, indeed, opinions. \ / o >Now for the witty part: I'm pink, therefore, I'm spam! \/
mrush@ecst.csuchico.edu (Matt "C P." Rush) (10/31/90)
In article <16105@hydra.gatech.EDU> ken@dali.gatech.edu (Ken Seefried iii) writes: > [Lots of good RISC/CISC commentary deleted] > >This is simply not true. I regularly run MS-DOS programmes on a >SPARCStation 1 using SoftPC (a programme that has been ported to the >MIPS, 88k and (I think) the 29k as well). The IBM RS/6000 emulates a >386 completely in software as fast as a real 386 in many cases. RISC >processors very much lend themselves to emulating other machines >(within limits). A RISC simulator of an Amiga, while probably not >easy, is certainly doable by reasonably sharp team. Hell, it might be >easier than SoftPC since the 68k instruction set is so much cleaner >and more orthoginal that the Intel rubbish. True, a 680x0 emulator would be easy, but the Amiga has those CUSTOM CHIPS. Those would be a little trickier to emulate in software. (Not impossible, but the overhead to do it might be prohibitive). > >-- > ken seefried iii "A snear, a snarl, a whip that > ken@dali.gatech.edu stings...these are a few of > my favorite things..." -- Matt *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* % "I programmed three days % Beam me up, Scotty. % % And heard no human voices. % There's no Artificial % % But the hard disk sang." % Intelligence down here. % % -- Yoshiko % % E-mail: mrush@cscihp.ecst.csuchico.edu % *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* This is a SCHOOL! Do you think they even CARE about MY opinions?!
cameron@kirk.nmg.bu.oz (Cameron Stevenson) (10/31/90)
From article <1156@iceman.jcu.oz>, by cpca@iceman.jcu.oz (C Adams): > I found this in comp.sys.m88k ...... > > So what would we want a RISC Amiga to be based on, 88k? Sparc? i860? MIPS? > What about compatibility with existing software? What about using one of the best microprocessors on the market... Fairchild's Clipper chipset. This set gives a good balance of RISC and CISC in the one set, and is blindingly fast. Anyway, this sort of discussion normally belongs in other newgroups. Cheers for now... Cameron Stephenson Bond University Gold Coast Australia
ckp@grebyn.com (Checkpoint Technologies) (10/31/90)
In article <1990Oct30.173846.6928@idt.unit.no> daglem@solan.unit.no (Dag Lem) writes: >We don't want a RISC amiga! Software compatibility? Are you joking? >If you want speed, opt for a 68040. It may do fewer MIPS than RISCS, >but that's NOT the way to compare 68040 with RISCS (or any other >processor, for that matter). The 68000 series can perform rather >complex operations with one instruction. Most RISCS do virtually >nothing with one instruction. Guess you've been reading too many >ads stating '..running at xx MIPS! Compare this to ..' :-) Uh, (trying to be gentle) the RISC speed debates are over; RISC is faster. Whether this is because of hard-core RISC principles, or that present-day CPU chip designers simply know their jobs very well and their marketing staff jumped on a RISC marketing bandwagon, is irrelevant. (I tend to think it's the latter, considering how fast the 68040 is.) People can tell when they run their applications. -- First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / / \\ / / Then, the disclaimer: All expressed opinions are, indeed, opinions. \ / o Now for the witty part: I'm pink, therefore, I'm spam! \/
limonce@pilot.njin.net (Tom Limoncelli) (10/31/90)
In article <1990Oct30.230958.14019@engin.umich.edu> gilgalad@caen.engin.umich.edu (Ralph Seguin) writes: > >On the other hand, the 68040 is as fast as current-generation RISC > >chips. So why go RISC at all? > > Eventually, CISC will not be able to keep up. The design philosophies > in RISC are generally better. I don't think that cranking up the clockrate Eventually, CISC will not be able to keep up BUT the 680x0 has a better fighting chance than the 386/486/etc. architecture. When RISC was "new", Intel lovers said, "this is revolutionary! The instruction set it SO simple!" When RISC was "new", Motorola lovers said, "this is interesting, someone has taken the 680x0 architecture to an extreme. Yawn." One thing about RISC can not be denied: The techniques and technology learned from RISC development will benefit us all. (Yes, yes, RISC chips may get "first wack" at the new ideas). Look at what makes the 486 faster than the 386, and look at what makes the '040 faster than the '030. Predictions are dangerous things to make, nonetheless: I predict RISC technology will start to bottom out, and (based on evolution in the past) designers will start to add more and more instructions until RISC chips are even more like the 680x0. The 680x0 will evolve taking ideas from RISC. This will reach a limit when the 680x0 vs. RISC distinction becomes slim. Both of these trends happening simultaneously sure sounds like 680x0 and RISC will converge. (The last sentence is really going out on a limb... no flames please, it's just a little prediction) Or, maybe everyone will adopt a "standard" (SPARC?) and stagnate development. No new instructions would be introduced, and my prediction wouldn't come true. Or, maybe someone will invent something better than either, and all this will be for naught. :-) -Tom P.S. I'm quite pro-RISC, I just wish SPARC spelled backwards wasn't "CRAPS". -- tlimonce@drew.edu Tom Limoncelli "Flash! Flash! I love you! tlimonce@drew.bitnet +1 201 408 5389 ...but we only have fourteen tlimonce@drew.uucp limonce@pilot.njin.net hours to save the earth!"
leblanc@eecg.toronto.edu (Marcel LeBlanc) (10/31/90)
ckp@grebyn.com (Checkpoint Technologies) writes: >In article <1156@iceman.jcu.oz> cpca@iceman.jcu.oz (C Adams) writes: >>So what would we want a RISC Amiga to be based on, 88k? Sparc? i860? MIPS? >>What about compatibility with existing software? >Forget about it. RISC is a new architecture, a new instruction set, a >new philosophy. >On the other hand, the 68040 is as fast as current-generation RISC >chips. So why go RISC at all? Sorry, this simply isn't true. Even if you assume that 68040's will be shipping RSN at a top speed of 25MHz, this is already well behind the top speed of popular RISC processors. You can buy a 33MHz R3000 or a 40MHz SPARC in CMOS *today*! By the time the 68040 is available in volume quantities, we should also be seeing volume 40MHz R3000s. And don't forget, the R3000 has been around for a while. You can bet the next generation R4000 will be available long before the 68050 is. Marcel A. LeBlanc -- Electrical Eng. Computer Group, Univ. of Toronto ----------------------------------------------------------------------- leblanc@eecg.toronto.edu else: uunet!utcsri!eecg!leblanc
leblanc@eecg.toronto.edu (Marcel LeBlanc) (10/31/90)
daglem@solan.unit.no (Dag Lem) writes: >In article <1156@iceman.jcu.oz>, cpca@iceman.jcu.oz (C Adams) writes: >|> So what would we want a RISC Amiga to be based on, 88k? Sparc? i860? MIPS? >|> What about compatibility with existing software? >|> >We don't want a RISC amiga! Software compatibility? Are you joking? > If you want speed, opt for a 68040. It may do fewer MIPS than RISCS, but > that's NOT the way to compare 68040 with RISCS (or any other processor, for > that matter). The 68000 series can perform rather complex operations with > one instruction. Most RISCS do virtually nothing with one instruction. Guess > you've been reading too many ads stating '..running at xx MIPS! Compare this > to ..' :-) Here we go again. Guess you've been reading too many BYTE pseudo-technical articles again. The whole point to the RISC approach to processor (and system) design is to implement only instructions that are used, and to make those instructions as fast as possible. The 'rather complex operations' performed by CISC are usually a waste of silicon because they aren't used. And the notion that RISCs "do virtually nothing with one instruction" will certainly be news to the designers of the MIPS R3000, who worked very hard to get the 'cycles per (useful) instruction' as close to 1.0 as possible! In fact, the R3000 achieves 1.27 clocks/SPEC integer. You can be sure this is better than what the 68040 (certainly the FASTEST of the 68K line) can achieve, because Motorola's predicted performance for the 68040 isn't evenb that high. And Motorola's 'performance predictions' are claims that have yet to be proven. > __ / |> Shorter of breath > / \ __ __ / ___ _ _ |> and one day closer to death. > / |/ / / / / /__/ / / / |> -Roger Waters, Time > /____/ \_/|/\_/ /____\___/ / \__________ |> (Dark Side of The Moon) >______________/ Marcel A. LeBlanc -- Electrical Eng. Computer Group, Univ. of Toronto ----------------------------------------------------------------------- leblanc@eecg.toronto.edu else: uunet!utcsri!eecg!leblanc
peterk@cbmger.UUCP (Peter Kittel GERMANY) (10/31/90)
In article <1990Oct31.012758.26467@jarvis.csri.toronto.edu> leblanc@eecg.toronto.edu (Marcel LeBlanc) writes: >daglem@solan.unit.no (Dag Lem) writes: >In fact, the R3000 achieves 1.27 clocks/SPEC integer. You can be sure this >is better than what the 68040 (certainly the FASTEST of the 68K line) can >achieve, because Motorola's predicted performance for the 68040 isn't evenb >that high. Hm, didn't I read something like "1.2 instructions per cycle" for the 68040, or do I mix things up? -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
daglem@solan5.solan.unit.no (Dag Lem) (11/01/90)
In article <1990Oct31.012758.26467@jarvis.csri.toronto.edu>, leblanc@eecg.toronto.edu (Marcel LeBlanc) writes: |> Here we go again. Guess you've been reading too many BYTE pseudo-technical |> articles again. The whole point to the RISC approach to processor (and No, I have not read BYTE. I have read IEEE Micro (OK so the articles were written by Motorola guys). |> system) design is to implement only instructions that are used, and to make |> those instructions as fast as possible. The 'rather complex operations' |> performed by CISC are usually a waste of silicon because they aren't used. Well at least I use the fancy addressing modes of the 680x0 series. Perhaps the c compilers don't, but I cannot agree with you that they are a waste of silicon. |> And the notion that RISCs "do virtually nothing with one instruction" will |> certainly be news to the designers of the MIPS R3000, who worked very hard |> to get the 'cycles per (useful) instruction' as close to 1.0 as possible! |> In fact, the R3000 achieves 1.27 clocks/SPEC integer. You can be sure this |> is better than what the 68040 (certainly the FASTEST of the 68K line) can |> achieve, because Motorola's predicted performance for the 68040 isn't evenb |> that high. And Motorola's 'performance predictions' are claims that have yet |> to be proven. Motorolas claims (OK they are claims) the 68040 on the average uses 1.3 cycles per VERY useful integer instruction. I can't see what makes the number 1.27 seem so much smaller than 1.3 to you :-) |>Marcel A. LeBlanc -- Electrical Eng. Computer Group, Univ. of Toronto |>----------------------------------------------------------------------- |>leblanc@eecg.toronto.edu else: uunet!utcsri!eecg!leblanc __ / |> Shorter of breath / \ __ __ / ___ _ _ |> and one day closer to death. / |/ / / / / /__/ / / / |> -Roger Waters, Time /____/ \_/|/\_/ /____\___/ / \__________ |> (Dark Side of The Moon) ______________/
daveh@cbmvax.commodore.com (Dave Haynie) (11/01/90)
In article <22914@grebyn.com> ckp@grebyn.UUCP (Checkpoint Technologies) writes: >In article <1156@iceman.jcu.oz> cpca@iceman.jcu.oz (C Adams) writes: >>So what would we want a RISC Amiga to be based on, 88k? Sparc? i860? MIPS? >Given the Amiga product philosphy of "inexpensive", I'd have to guess >the AMD29K. Then again, Motorola just chopped prices on the 88k family, by a big chunk. I think you can get a basic 88100 + 88200 * 2 for just over $100 now at 16MHz. And there's this IDT version of the MIPS R3000 on the way out, with on-chip cache and MMU, for about $30 in quantity. The obvious advantage of RISC chips from the beginning, more than architectural purity, has been the small size of the fool things. The freakin' MIPS R3000 is about 1/3 the size of the 68030 even with MMU and reasonbly sized caches. Not much bigger or more complex than a 68000. That means at the high end they can move into new chip technologies faster, and at the low end they can drop price faster. Imagine what you could do with a CPU several times the performance of a 68030 for the price of a 68000. It would make one helluva C64 replacement :-). The flaw, of course, is that any new system will run UNIX, which makes the CPU piece of the pie a rather small cost concern when you look at memory, hard disk, casework, monitors, and all the other goodies every UNIX system needs no matter what CPU is inside. >First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / / -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Standing on the shoulders of giants leaves me cold -REM
daveh@cbmvax.commodore.com (Dave Haynie) (11/01/90)
In article <16105@hydra.gatech.EDU> ken@dali.gatech.edu (Ken Seefried iii) writes: >RISC processors very much lend themselves to emulating other machines >(within limits). A RISC simulator of an Amiga, while probably not >easy, is certainly doable by reasonably sharp team. Hell, it might be >easier than SoftPC since the 68k instruction set is so much cleaner >and more orthoginal that the Intel rubbish. The problem with these simulators has never been the simulation of the CPU itself. I've run three software simulators on my Amiga: PC, C64, and CP/M. The first two, commercial products, ran pretty slowly. The CP/M emulator was plenty fast. Why? Because the Z-80 is about all it has to emulate, the rest of the system is handled via system calls that can be translated into Amiga system calls. The PC emulator has to emulate not only the 80x86 instruction set, but all the I/O chips at the register level. So that wordprocessor that works just dandy on a real PC now dies in emulation as it sits there polling the keyboard controller chip, directly, 60 times a second. Similarly, that raster interrupt plus busy wait loop that used to work on the VIC-II chip in a real C64 now just plain fails with the software simulation of the VIC-II's registers sitting down underneath it. As for Amiga simulation, if you build a real AmigaRISC machine, you might be able to avoid many of these emulation problems. Emulating the 680x0 would not be a big deal. If it's an AmigaRISC of some kind, it should have a chip set that's similar enough to the Amiga's chip set to not need register level emulation of all those registers. Similarly, the Amiga OS is very function call oriented; for the most part, only games are directly banging on the hardware. So for library functions, you get direct translations into RISC versions of those, rather than having to emulate all of those 68000 opcodes. You would most likely have trouble with anything that demanded too much real time performance, but a good portion of stuff could probably be made to run. That emulation box, though, would still be a considerable amount of work. But in general, as an OS depends on only CPU and function calls, it can be reasonably emulated. As you add hardware register or time dependency, it gets increasingly hairier. > ken seefried iii "A snear, a snarl, a whip that -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Standing on the shoulders of giants leaves me cold -REM
daveh@cbmvax.commodore.com (Dave Haynie) (11/01/90)
In article <Oct.31.00.42.55.1990.6738@pilot.njin.net> limonce@pilot.njin.net (Tom Limoncelli) writes: >-Tom >P.S. I'm quite pro-RISC, I just wish SPARC spelled backwards >wasn't "CRAPS". But it's appropriate -- SPARC is a pretty big roll of the dice for Sun. They seem to be aiming it as what they would like to have established as the next "industry standard" architecture (eg, what everyone clones). >tlimonce@drew.edu Tom Limoncelli "Flash! Flash! I love you! -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Standing on the shoulders of giants leaves me cold -REM
dlt@locus.com (Dan Taylor) (11/01/90)
ckp@grebyn.com (Checkpoint Technologies) writes: >Given the Amiga product philosphy of "inexpensive", I'd have to guess >the AMD29K. They're real cheap, and quite fast. They are neither cheap nor fast. I can bury one with an '030, on ANY test. The problem with all of the 'slice processors is the extra cycles necessary to do memory ops. And the '030 can be obtained with a faster clock than the 29K. I once scrubbed a hardware managers pet project using the 29116 by showing that an '020 would meet the performance requirements, and be significantly cheaper. The number of chip required to implement a 29K is just too high. -- * Dan Taylor * The opinions expressed are my own, and in no way * * dlt@locus.com * reflect those of Locus Computing Corporation. *
aduncan@rhea.trl.oz (Allan Duncan) (11/01/90)
From article <1990Oct30.192213.12708@Neon.Stanford.EDU>, by torrie@Neon.Stanford.EDU (Evan James Torrie): >>On the other hand, the 68040 is as fast as current-generation RISC >>chips. So why go RISC at all? > > Because next year's implementation of RISC (the 88110) will be about > two to three times faster than next year's implementation of the 68040 > (even with the 040 running at 50MHz) When you configure in memory at prices we in the street can afford (ie dynamic ram) riscs stop dead, as their high mip speed is derived from memory fetching on every cycle, whereas a cisc spends some time decoding giving the memory time to catch its breath. With sensible memory interfacing (and you don't get anything else these days at these speeds) the effective computation you get is a function of memory bandwidth, not cisc/risc. Split instruction/data paths and dual ported data memory are probably the way of the future, but not at the cheap end of the market. Wider buses too. Allan Duncan ACSnet a.duncan@trl.oz (03) 541 6708 ARPA a.duncan%trl.oz.au@uunet.uu.net UUCP {uunet,hplabs,ukc}!munnari!trl.oz!a.duncan Telecom Research Labs, PO Box 249, Clayton, Victoria, 3168, Australia.
leblanc@eecg.toronto.edu (Marcel LeBlanc) (11/01/90)
daglem@solan5.solan.unit.no (Dag Lem) writes: >|> And the notion that RISCs "do virtually nothing with one instruction" will >|> certainly be news to the designers of the MIPS R3000, who worked very hard >|> to get the 'cycles per (useful) instruction' as close to 1.0 as possible! >|> In fact, the R3000 achieves 1.27 clocks/SPEC integer. You can be sure this >|> is better than what the 68040 (certainly the FASTEST of the 68K line) can >|> achieve, because Motorola's predicted performance for the 68040 isn't evenb >|> that high. And Motorola's 'performance predictions' are claims that have yet >|> to be proven. > Motorolas claims (OK they are claims) the 68040 on the average uses 1.3 > cycles per VERY useful integer instruction. I can't see what makes the > number 1.27 seem so much smaller than 1.3 to you :-) That's the point I was trying to make - the clocks/instr are nearly identical if you can trust Motorola's claims. You made the statement that RISCs "do virtually nothing with one instruction", when it is clear from MEASURED data that the R3000 does MORE with it's instuctions than the yet to be measured 68040. At identical clock speeds, the 68040 _might_ come close to the R3000 in performance, but then the R3000 is already up to 40MHz, while the 68040's best is 25MHz. Another thing to note is that based on published performance claims, Motorola's statements of VAX-MIPS are not nearly as trustworthy as MIPS'. Here are a few numbers comparing measured SPEC data vs. Published MIPS: (these numbers were compiled by John Mashey) SPEC SPEC SPEC Published System Integer Float mark mips 14.6 10.8 12.2 17.0 Motorola 8864SP, 20MHz, 128K 18.3 13.5 15.2 21.0 Motorola 8864SP, 25MHz, 128K 21.4 15.8 17.8 25.0 Motorola 8612, 33MHz, 32K 19.4 16.8 17.8 20.0 MIPS Magnum, 25MHz, 64K Motorola's idea of MIPS is not as inflated as other companies, but you do have to take their claims with a grain of salt. > __ / |> Shorter of breath > / \ __ __ / ___ _ _ |> and one day closer to death. > / |/ / / / / /__/ / / / |> -Roger Waters, Time > /____/ \_/|/\_/ /____\___/ / \__________ |> (Dark Side of The Moon) >______________/ Marcel A. LeBlanc -- Electrical Eng. Computer Group, Univ. of Toronto ----------------------------------------------------------------------- leblanc@eecg.toronto.edu else: uunet!utcsri!eecg!leblanc
wayned@wddami.spoami.com (Wayne Diener) (11/01/90)
>In article <2425@trlluna.trl.oz> aduncan@rhea.trl.oz (Allan Duncan) writes: >From article <1990Oct30.192213.12708@Neon.Stanford.EDU>, by torrie@Neon.Stanford.EDU (Evan James Torrie): >>>On the other hand, the 68040 is as fast as current-generation RISC >>>chips. So why go RISC at all? >> >> Because next year's implementation of RISC (the 88110) will be about >> two to three times faster than next year's implementation of the 68040 >> (even with the 040 running at 50MHz) > >When you configure in memory at prices we in the street can afford (ie >dynamic ram) riscs stop dead, as their high mip speed is derived from >memory fetching on every cycle, whereas a cisc spends some time decoding Well, not exactly. If you're talking about high performance systems and are willing to grant that they'll need a fair amount of memory, it's fairly easy and inexpensive to go to, say, 4 way interleaving on the memory, use slower RAM chips than we're trying to stick in our machines right now and still decrease the actual memory cycle time. Four megabytes, consisting of 16 256K simms would cost less than $500, and using even 120 NS parts would yield an effective access time of 30 NS. Using 16 1 MB simms would give a 16 MB memory module for less than $1500. Same sort of timing calculations. The problems arise in any memory expansion. If you start out at the four MB level, then that's also your expansion increment. -- |---------------------------------------------------------------| | // Wayne D. Diener | | // Spokane, WA | | \\ // E-mail reply to: | | \X/ To: isc-br!hawk!wddami!wayned@uunet.uu.net | |---------------------------------------------------------------|
dlt@locus.com (Dan Taylor) (11/01/90)
leblanc@eecg.toronto.edu (Marcel LeBlanc) writes: >In fact, the R3000 achieves 1.27 clocks/SPEC integer. You can be sure this >is better than what the 68040 (certainly the FASTEST of the 68K line) can >achieve, because Motorola's predicted performance for the 68040 isn't evenb >that high. And Motorola's 'performance predictions' are claims that have yet >to be proven. I'd be careful about that. Numbers like 1.18 for integer on the '040 are showing up regularly. -- * Dan Taylor * The opinions expressed are my own, and in no way * * dlt@locus.com * reflect those of Locus Computing Corporation. *
cpca@iceman.jcu.oz (C Adams) (11/01/90)
In article <22914@grebyn.com>, ckp@grebyn.com (Checkpoint Technologies) writes: > In article <1156@iceman.jcu.oz> cpca@iceman.jcu.oz (C Adams) writes: > >So what would we want a RISC Amiga to be based on, 88k? Sparc? i860? MIPS? > > Given the Amiga product philosphy of "inexpensive", I'd have to guess > the AMD29K. They're real cheap, and quite fast. After that I think 88K, > because of the Motorola heritage of the Amiga. Plus I just read that > Motorola dropped the price of the 88K chip set, don't remember how low. > Still much higher than a 68030. I quite like the AMD29k, but to get good performance out the them I think you need separate external buses to memory (1 for instruction, and 1 for data), as this is how the chip goes quick. I don't think you get on-chip caches yet. I could be wrong on this stuff so don't flame, correct me. > >What about compatibility with existing software? > > Forget about it. RISC is a new architecture, a new instruction set, a > new philosophy. Not what I was thinking. How about putting an emulator in the OS, and having two different formats for executables. If the OS detects a old 68000 executable, it automatically runs it under the emuator, otherwise it runs in normally. > On the other hand, the 68040 is as fast as current-generation RISC > chips. So why go RISC at all? No way. The 68040 uses 1.2 million transistors to make it as quick as RISC chips with 300,000 transistors. The i860 RISC chip uses 1 million transistors and is MUCH quicker than the i486/68040 which uses a similar amount. It may be possible to build a CISC as fast as a RISC, but with current technology it takes more hardware. Macintosh can see the death of the 680X0 series, but can C=. I have heard the next 88k chip, the 88110, will be VERY rapid.... Colin Adams You need to have a woman, before you can have a Sun :-) Email Address - cpca@marlin.jcu.edu.au
cpca@iceman.jcu.oz (C Adams) (11/01/90)
In article <1990Oct30.233553.2944@ecst.csuchico.edu>, mrush@ecst.csuchico.edu (Matt "C P." Rush) writes: > In article <16105@hydra.gatech.EDU> ken@dali.gatech.edu (Ken Seefried iii) writes: > >RISC > >processors very much lend themselves to emulating other machines > >(within limits). A RISC simulator of an Amiga, while probably not > >easy, is certainly doable by reasonably sharp team. Hell, it might be > >easier than SoftPC since the 68k instruction set is so much cleaner > >and more orthoginal that the Intel rubbish. > > True, a 680x0 emulator would be easy, but the Amiga has those > CUSTOM CHIPS. Those would be a little trickier to emulate in software. > (Not impossible, but the overhead to do it might be prohibitive). > Why emulate them in software? It should be possible to leave them in hardware. Data access to the chips is via memory accessed with are mapped to the chips, so it should be able to work ok. An emulator for the 680X0 would be a simple task, and since most of the OS is in C, a lot of the OS should be easily ported. Actually, I'd love to work on a project like this. I wonder if C= would lend me their source code :-) Colin Adams You need to have a woman, before you can have a Sun :-) Email Address - cpca@marlin.jcu.edu.au
davidm@uunet.UU.NET (David S. Masterson) (11/01/90)
In article <1156@iceman.jcu.oz> cpca@iceman.jcu.oz (C Adams) writes:
So what would we want a RISC Amiga to be based on, 88k? Sparc? i860? MIPS?
What about compatibility with existing software?
Isn't there already a RISC based Amiga? (based on the Transputer)
Software may not be compatible, but at up to 120 Mips and 8Kx8K virtual screen
graphics, who would care as long as there was software?
--
====================================================================
David Masterson Consilium, Inc.
(415) 691-6311 640 Clyde Ct.
uunet!cimshop!davidm Mtn. View, CA 94043
====================================================================
"If someone thinks they know what I said, then I didn't say it!"ken@dali.gatech.edu (Ken Seefried iii) (11/02/90)
In article <dlt.657408889@fafnir.la.locus.com> dlt@locus.com (Dan Taylor) writes: >ckp@grebyn.com (Checkpoint Technologies) writes: > >>Given the Amiga product philosphy of "inexpensive", I'd have to guess >>the AMD29K. They're real cheap, and quite fast. > >They are neither cheap nor fast. I can bury one with an '030, on ANY >test. The problem with all of the 'slice processors is the extra >cycles necessary to do memory ops. Ooops...little confusion here. We are talking about the AMD 29000 32-bit CPU, not the 2901 bit-slice, and certainly not the 29116 (gee, I got one of those in my VME video controller...;'). Probably many of the folks around here never new the 2901's exsisted... In any case, were not the 2901/29116 pretty much past their prime when the 68020 rolled out? Not really suprising that they had inferior performance at that point in the game, though in their day they were pretty hot... -- ken seefried iii "A sneer, a snarl, a whip that ken@dali.gatech.edu stings...these are a few of my favorite things..."
dean@coplex.UUCP (Dean Brooks) (11/02/90)
leblanc@eecg.toronto.edu (Marcel LeBlanc) writes: >daglem@solan5.solan.unit.no (Dag Lem) writes: >Another thing to note is that based on published performance claims, >Motorola's statements of VAX-MIPS are not nearly as trustworthy as MIPS'. >Here are a few numbers comparing measured SPEC data vs. Published MIPS: >(these numbers were compiled by John Mashey) >SPEC SPEC SPEC Published System >Integer Float mark mips >14.6 10.8 12.2 17.0 Motorola 8864SP, 20MHz, 128K >18.3 13.5 15.2 21.0 Motorola 8864SP, 25MHz, 128K >21.4 15.8 17.8 25.0 Motorola 8612, 33MHz, 32K >19.4 16.8 17.8 20.0 MIPS Magnum, 25MHz, 64K >Motorola's idea of MIPS is not as inflated as other companies, but you do >have to take their claims with a grain of salt. What's even more peculiar is that the 20MHZ 8864SP drops in at 35.7 MIPS in real life. And we can achieve that speed rating on a semi-loaded machine most of the time. Its one thing to talk about the speed difference between CISC and RISC, but it is entirely different when you actually sit down and put a use to one. Fastest damn FP I have seen in a mini. Apparantely, the above values a wee bit understated. -- dean@coplex.UUCP Dean A. Brooks Copper Electronics, Inc. Louisville, Ky UUCP: !uunet!coplex!dean
davidm@uunet.UU.NET (David S. Masterson) (11/02/90)
In article <15497@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: The flaw, of course, is that any new system will run UNIX, which makes the CPU piece of the pie a rather small cost concern when you look at memory, hard disk, casework, monitors, and all the other goodies every UNIX system needs no matter what CPU is inside. I would think that casework and monitors would be true of any system regardless of operating system. Memory and hard disk, though, are a function of the flexibility and power of the software you use on the system. The more power and flexibility demanded, the more resources needed. In this case, Unix is more the standard than the CPU and Unix has become resource consumptive. On the question of CPU, though, with the blinding speed at which higher powered CPUs come out, how cost effective would it be to design a system to allow for this moving target ("I'll swap you my CPU for your CPU and a CPU to be named later" ;-). -- ==================================================================== David Masterson Consilium, Inc. (415) 691-6311 640 Clyde Ct. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"
eachus@linus.mitre.org (Robert I. Eachus) (11/02/90)
But why do any emulation at all. The 3000 has a Co-processor
slot, and any GOOD board designer should be able to build an
i860/88000/AMD29000/MIPS/you choose board that slots in there. The
hard part would be to modify AmigaDOS to recongize which processor a
task should run on.
Of course it would be easier to build a board with a mailbox to
talk to AmigaDOS and run Unix on your i860 board. Add an ethernet
connector and support for a (separate) internal hard disk and it might
be a pretty nice accelerator board. But then again it is like some of
the recipies I heard for converting a 64 to a 128 first carefully
remove the power cord and save it...
Seriously with an Ethernet board my Amiga is a very nice machine,
and when I need more than a 68030's worth of cruch power I do an
rlogin or an rsh. (I actually have aliases that do one or the other.)
If I need a huge number cruncher box, I don't use a workstation. (Or,
more correctly I use a workstation to display the results.) It might
be nice to have an iPSC/2, or a MIPS R2000, or an Encore Multimax in
my Amiga, but I don't notice that they are not there now.
--
Robert I. Eachus
with STANDARD_DISCLAIMER;
use STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...joseph@valnet.UUCP (Joseph P. Hillenburg) (11/02/90)
I was thinking maybe parallel processing, andhaving an MC680x0, as well as a RISC chip. The obvious choice, IMHO, is a SPARC, sinceit's real close to Motorola chips. (And was based on the 680x0). SOmeone suggested using a program to detect which CPU the software was for, and then the OS could justrun the program on the appropriate CPU. If Commodore did something like that, then full parallel processing wouldn't be far off for the masses. -Joseph Hillenburg UUCP: ...iuvax!valnet!joseph ARPA: valnet!joseph@iuvax.cs.indiana.edu INET: joseph@valnet.UUCP
lindblad@cc.helsinki.fi (11/02/90)
> to get the 'cycles per (useful) instruction' as close to 1.0 as possible! > In fact, the R3000 achieves 1.27 clocks/SPEC integer. You can be sure this > is better than what the 68040 (certainly the FASTEST of the 68K line) can > achieve, because Motorola's predicted performance for the 68040 isn't evenb Current beta (or something like that) versions of 68040 do one istruction 1.3 cycles. And it's instruction set is optimized in a way that mostly used istructions are fastest. Difference between 1.27 and 1.3 is not worth mentioning. Today there are already 30-40 MHz versions of RISC chips. Well, I think that within months there will be something like 50 or 60 MHz versions of 68040., as there are alredy 50 MHz 68030s and 60 MHz 68882s producted. I don't think that it would be worth putting RISC chips on Amiga as CPUs, simply because of differences in instruction sets of 68000-series and RISC processors. But in future, there will propably be some special purpose RISC chips on Amiga (like Intels i860 (I hope that VLIW-processor was i860)). In few years RISC chips go far ahead 040 and then in about three years there will be 68050 and it equals the speeds, and then RISCs go ahead again. But still most computers to be sold will be CISC computers. For now.
AXN100@psuvm.psu.edu (11/03/90)
Just to add my $0.02 worth wouldn't any Risc Amiga have to have all of the custom chips to do graphic sound etc., and wouldn't this make emulation of a "regular" amiga possible? --------------------------------------------------------------------------- If all the world's a stage and we are but actors, where's the curtain? --| ------------------------------------------------------------------------
leblanc@eecg.toronto.edu (Marcel LeBlanc) (11/03/90)
lindblad@cc.helsinki.fi writes: > M. LeBlanc wrote: >> to get the 'cycles per (useful) instruction' as close to 1.0 as possible! >> In fact, the R3000 achieves 1.27 clocks/SPEC integer. You can be sure this >> is better than what the 68040 (certainly the FASTEST of the 68K line) can >> achieve, because Motorola's predicted performance for the 68040 isn't evenb >Current beta (or something like that) versions of 68040 do one istruction >1.3 cycles. And it's instruction set is optimized in a way that mostly used >istructions are fastest. Difference between 1.27 and 1.3 is not worth >mentioning. And by what measurement does Motorola get the claim of 1.3 cycles/instr? This is why I specifically quoted official SPEC numbers for the R3000. NO 68040 workstation vendors have released any SPEC results! None, not ONE! This isn't surprising, because the 68040 isn't officially released yet. If you remember the original article, I wasn't trying to say that the R3000 would have significant speed advantage at equal clock rates, I was just responding to the original poster's claim that "RISCs do virtually nothing with one instruction", which is clearly not true. > Today there are already 30-40 MHz versions of RISC chips. Well, I think >that within months there will be something like 50 or 60 MHz versions of >68040., as there are alredy 50 MHz 68030s and 60 MHz 68882s producted. This doesn't mean anything, since a 50 MHz 68030 isn't even as fast as a 10 MHz R2000. Clock rates don't mean much when cycles/instr are vastly different. 50 MHz 68040 in a few months? We were supposed to be able to buy 25 MHz 68040's almost a year ago. You can buy 40 MHz R3000s today, but you still can't get a 25 MHz 68040. Not that I really care. I'm quite happy with a 68030 Amiga. > I don't think that it would be worth putting RISC chips on Amiga as >CPUs, simply because of differences in instruction sets of 68000-series and >RISC processors. But in future, there will propably be some special purpose >RISC chips on Amiga ... I agree. Let's stick with 680x0's in Amigas for now. >But still most computers to be sold will be CISC computers. For now. Sad, but true. Marcel A. LeBlanc -- Electrical Eng. Computer Group, Univ. of Toronto ----------------------------------------------------------------------- leblanc@eecg.toronto.edu else: uunet!utcsri!eecg!leblanc
peter@dbaccess.com (Peter A. Castro) (11/06/90)
in article <90306.212717AXN100@psuvm.psu.edu>, AXN100@psuvm.psu.edu says:
+
+
+ Just to add my $0.02 worth wouldn't any Risc Amiga have to have all of
+ the custom chips to do graphic sound etc., and wouldn't this make emulation
+ of a "regular" amiga possible?
Just to add $0.02 to your $0.02, the 68040 as an optimization of the most
used instructions to be approximately 1.3 cycles per instruction. Most
RISC processors have optimizations that cycles per instruction approaches
1.0. Being that RISC processors would have to do "interpretation" of 68000
code in order to simulate the execution, it is very doubtful that any RISC
processor, running at the same speed, could "emulate" the 68040. The
best the RISC processor could achieve would be "simulation" and at a
reduced equivalent speed. You could argue that the RISC chip be run at
a faster speed, but why not just run the 040 at a fast speed as well?
Remember that the A3000 has a 68030 with the envisionment that a 68040
board will be added to it (upgrade?).
On another note, why not look at the MISC (Minimal Instr. Set Computer)
architecture, which purports to be able to load different emulation sets
to approach emulation speeds of various processors (Latest UnixWorld, I
think). Imagine, stick a disk in, boot up, and *pow* run your favorite
processor/machine emulation on your Amiga. Boy, wouldn't that be neat!
--
Peter A. Castro INTERNET: peter@dbaccess.com // //|
c/o DB Access Inc. UUCP: {uunet,mips}!troi!peter // //||
2900 Gordon Avenue, Suite 101 FAX: (408) 735-0328 \\ // //-||-
Santa Clara, CA 95051-0718 TEL: (408) 735-7545 \// // ||daveh@cbmvax.commodore.com (Dave Haynie) (11/06/90)
In article <1990Oct31.165728.3196@jarvis.csri.toronto.edu> leblanc@eecg.toronto.edu (Marcel LeBlanc) writes: >Another thing to note is that based on published performance claims, >Motorola's statements of VAX-MIPS are not nearly as trustworthy as MIPS'. >Here are a few numbers comparing measured SPEC data vs. Published MIPS: >(these numbers were compiled by John Mashey) >SPEC SPEC SPEC Published System >Integer Float mark mips >14.6 10.8 12.2 17.0 Motorola 8864SP, 20MHz, 128K >18.3 13.5 15.2 21.0 Motorola 8864SP, 25MHz, 128K >21.4 15.8 17.8 25.0 Motorola 8612, 33MHz, 32K >19.4 16.8 17.8 20.0 MIPS Magnum, 25MHz, 64K >Motorola's idea of MIPS is not as inflated as other companies, but you do >have to take their claims with a grain of salt. Your point is correct, but lots of folks seem to get confused these days over the terminology in it. SPECmarks aren't a true measure of any "instructions/ second", but in fact a measure of preformance relative to a VAX 11/780 on a series of integer and floating point benchmarks. SPECmarks are certainly more accurate than any MIPS claim, especially since the SPEC series benchmarks are more "real-world" than programs like Dhrystone, often used to calculate MIPS. That's why marketing folks continue to speak in terms of MIPS and quote Dhrystone 1.1 numbers when these come out favorable (perhaps due to weak but fast instructions in the first case and optimizing compilers and/or Dhrystone-sized caches in the second case). The other main problem is that Motorola's claim of MIPS for any chip is just a claim for that Chip, everything being perfect. SPECmarks are a test of a real living system, which includes the memory bus performance, compiler performance, etc. Between real live 68030 systems on the market, you can see more than a 4:1 variation in performance based on memory and system architecture and on compiler performance. Benchmark suites like SPEC and AIM were designed to make an attempt at measuring this true system performance, unmasked by cache or cheap compiler tricks. So you would expect any chip claim to be the best possible performance with that system, which would usually be an impossible situation. These are usually generated with simulators even before the chip works. You don't want to pay for the 25MHz 68040 system with 0 wait state main memory that would be required to get Moto's MIPS claim for the 25MHz 68040, assuming that those claims are valid. Even with a big external cache, real live systems will fall short of the ideal, at least until we get some main memories that can keep up with these modern CPUs. >Marcel A. LeBlanc -- Electrical Eng. Computer Group, Univ. of Toronto -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Standing on the shoulders of giants leaves me cold -REM
king@motcid.UUCP (Steven King) (11/07/90)
In article <885@troi.dbaccess.com> peter@dbaccess.com (Peter A. Castro) writes: > On another note, why not look at the MISC (Minimal Instr. Set Computer) > architecture, which purports to be able to load different emulation sets > to approach emulation speeds of various processors (Latest UnixWorld, I > think). Imagine, stick a disk in, boot up, and *pow* run your favorite > processor/machine emulation on your Amiga. Boy, wouldn't that be neat! And wouldn't it be great if they brought BEER!? :-) 'Minds me of the ultra-RISC machine a friend of mine came up with. One instruction: NOP. I decided that wasn't very useful so I enhanced the instruction set by adding JUMP... -- ---------------------------------------------------+--------------------------- If all you do in life are important things, then | Steven King 708-540-6771 you'll never have any fun -- unless having fun | Motorola Cellular is an important thing to you. | ...uunet!motcid!king
amiga@ccwf.cc.utexas.edu (Paul) (11/08/90)
I think the bet solution to having a RISC processor is to have an accelerator board with the 040 and a RISC. The 040 would do most of the propriatory code while the RISC would be used for FFP and other such math through the use of libraries. The RISC would also be avalable to do anything for programs that utalise it. Of course you would then have Chip mem, Fast Mem and Risc mem. The RISC would have to have it's own section of memory but it would also need access to the Main Bus (i.e. access to fast mem). Just thinking about it, wouldn't the MIPS 3000 be a great replacement for the Blitter! You Could also have the RISC do such things as real time compression to the HD, Forier transforms for sound processing, endless list of things.... I like this idea i'll do it right after I get my EE degree in 2 more years. Amiga@walt.utexas.edu .....Paul...... I like boats, they're healthier than valium. Cost more tho.
daveh@cbmvax.commodore.com (Dave Haynie) (11/10/90)
In article <39367@ut-emx.uucp> amiga@ccwf.cc.utexas.edu (Paul) writes: >I think the bet solution to having a RISC processor is to have an accelerator >board with the 040 and a RISC. The 040 would do most of the propriatory code >while the RISC would be used for FFP and other such math through the use of >libraries. While I think it would be fun and interesting to have a RISC coprocessor to play with, there are two flaws in using it for your math: 1) The 68040 floating point should be very comparable to any standard general purpose RISC chip, like a Sparc or R3000. Certainly some DSPs and the i860 could run rings around any of these under the right circumstances. That brings us to 2) The math libraries are too finely grained. For math intensive stuff, any in-line 680x0 FPU codes are going to run MUCH faster than any math library calls. Plus you get floating point variables, which you don't get between math library calls. For a good portion of the math library functions, the overhead of the call is a large portion of the cycle count for the function on any system with a hardware FPU. The math libraries are a good thing, in that they give you a standard math interface for any Amiga CPU. And, at least with the IEEE libraries, the functions will run faster with a math chip in the system. Which is OK for things like spreadsheet recalculations or other relatively short lived math functions. But nothing you're going to want to have during a 12 hour ray tracing session. What's really required to take advantage of some faster math processing units is a higher level math function library. Something that supports matrix multiplications, fourier and S transforms, etc. If you make the function itself, even on a fast math chip, last significantly longer than the function call overhead, you have a winning situation. But calling the IEEE library simply to do a 64 bit floating point multiply is already a loss on a 68030 system; making you i860 do the multiply isn't going to speed anything up there. >The RISC would have to have it's own section of memory but it would also need >access to the Main Bus (i.e. access to fast mem). Just thinking about it, >wouldn't the MIPS 3000 be a great replacement for the Blitter! On the A3000, the 68030 already can do a number of video things significantly faster than the blitter. >Amiga@walt.utexas.edu .....Paul...... -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Standing on the shoulders of giants leaves me cold -REM
aduncan@rhea.trl.oz (Allan Duncan) (11/15/90)
From article <15759@cbmvax.commodore.com>, by daveh@cbmvax.commodore.com (Dave Haynie): ... > On the A3000, the 68030 already can do a number of video things significantly > faster than the blitter. So when is the 28MHz blitter coming out? :-) Allan Duncan ACSnet a.duncan@trl.oz (03) 541 6708 ARPA a.duncan%trl.oz.au@uunet.uu.net UUCP {uunet,hplabs,ukc}!munnari!trl.oz!a.duncan Telecom Research Labs, PO Box 249, Clayton, Victoria, 3168, Australia.