mwm@VIOLET.BERKELEY.EDU (Mike Meyer, My watch has windows) (10/31/87)
First, it was noted (but I didn't forward the letter) that John Gilmore had missed an important detail on the 68070. Namely, that the clock cycles he was looking at were internal clock cycles, and that the internal clock runs at twice the frequency of the external clock. So those twice-the-cycle delays were actually the same length as the MC68K chips. In summary: All on chip: the 68070 is about twice the speed of the MC68Ks Off chip, no MMU: identical to the MC68Ks Off chip, with MMU: 50% more time than the MC68Ks (1/2 an external clock) Who's going to be the first person to try one in an Amiga? We also have data on the 68882 (for you FP freaks): ------- Forwarded From: tikal!amc!motsea@beaver.cs.washington.edu (Motorola Seattle ) Organization: Applied Microsystems Corp., Redmond, WA. Subject: Re: MC68030 & MC68882 now out and available; comparisons with MC68020? Message-Id: <542@amc.UUCP> References: <4733@elroy.Jpl.Nasa.Gov> Sender: info-68k-request@ucbvax.berkeley.edu To: info-68k@ucbvax.Berkeley.EDU The 68882 *** IS *** a drop in replacement for the 68881. By reconfiguring the internal architecture [primarily in floating point register access], it is able to achieve typically 50% better performance than an 881 [all other factors being equal], and can go 2x with minor code mods... ...mark konopacky fae motorola seattle email: ...uw-beaver!tikal!motsea!mark [I am fortunate to use Applied Microsystems' node for news...] << Standard Disclaimer >> ------- End of Forwarded Message So, anybody know how much of the code floating around for the 68881 will take advantage of the 68882 (sorta like Lattice 4.0 takes advantage of the 68010)? Dale? <mike
grr@cbmvax.UUCP (11/02/87)
In article <8710302351.AA27916@violet.berkeley.edu> mwm@VIOLET.BERKELEY.EDU (Mike Meyer, My watch has windows) writes: > First, it was noted (but I didn't forward the letter) that John > Gilmore had missed an important detail on the 68070. Namely, that the > clock cycles he was looking at were internal clock cycles, and that > the internal clock runs at twice the frequency of the external clock. > So those twice-the-cycle delays were actually the same length as the > MC68K chips. In summary: > > All on chip: the 68070 is about twice the speed of the MC68Ks > Off chip, no MMU: identical to the MC68Ks > Off chip, with MMU: 50% more time than the MC68Ks (1/2 an external clock) > > Who's going to be the first person to try one in an Amiga? There are two immediate problems you have to deal with: a) the 2x clock is a problem, since the 68000/Amiga Custom Chip interface requires that the 7MHz "effective" processor clock be syncronized with the clocks that chips work with. There is no documented way to bypass the internal clock divider or reset it a known state. b) the discrete interrupt request lines are inadequate, since the interrupt encoding in Paula uses at least 6 interrupt levels. There are probably some other, more minor problems, but it's been a while since I look at the 68070 carefully. At that point it was all vapor, with no commited date for samples, let alone production. There also didn't seem to be any real commitment to making the chip cheap, i.e. it might always be significantly more expensive than a 68010 and a gate array implementation of the same sort of MMU function. The MMU itself is a bit whacky, you either get big coarse segments, or smaller segments and a lot of exceptions to handle. > We also have data on the 68882 (for you FP freaks): > > The 68882 *** IS *** a drop in replacement for the 68881. By reconfiguring > the internal architecture [primarily in floating point register access], it > is able to achieve typically 50% better performance than an 881 [all other > factors being equal], and can go 2x with minor code mods... > > So, anybody know how much of the code floating around for the 68881 > will take advantage of the 68882 (sorta like Lattice 4.0 takes > advantage of the 68010)? Dale? The 68882 is code compatible with the 68881 with the exception of requiring FSAVE/FRESTORE (sp?) sequences in the exception handling routines and more exception stack space. It looks like you could easily code to be both 881 and 882 compatible, but it's hard to say what the purveyors of 881 code have done and if or how badly it might break with an 882. ******************************************************************************** By the way, Mike wins the non-contest for being to originator of the 10,000th comp.sys.amiga article to be received at cbmvax since the name change. Hopefully, people have benefited by all this stuff in some relation to its cost to underlying usenet framework... ******************************************************************************** -- George Robbins - now working for, uucp: {ihnp4|rutgers|allegra}!cbmvax!grr but no way officially representing arpa: out to lunch... Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)