plouff@nac.dec.com (08-Jan-1988 0946) (01/09/88)
[] For Commodore folks: This month's _AmigaWorld_ has an article about the CSA 68020 board for the A2000. The performance numbers seem disappointingly low, and some of the explanations a bit screwy. Can someone answer two simple questions? The answers to these are not obvious in my rather meager document set or from rereading the slush pile of saved comp.sys.amiga articles. 1. When the operating system recognizes a 68020, what exactly does it do? Is the '020 instruction cache turned on by ROM Kernel routines (or elsewhere in the OS), or must the user run a separate program? 2. Other than running self-modifying code, can one get in trouble running with the cache enabled? Thanks in advance, Wes Plouff Digital Equipment Corp. UUCP: ...!decwrl!nac!plouff Littleton, Mass. Internet: plouff%nac.dec@decwrl.dec.com "Which TV show do YOU watch with the shock of recognition?"
kjws@eagle.ukc.ac.uk (K.J.W.Smithers) (01/10/88)
In article <8801081459.AA16543@decwrl.dec.com> plouff@nac.dec.com (08-Jan-1988 0946) writes: >[] > >1. When the operating system recognizes a 68020, what exactly does it >do? Is the '020 instruction cache turned on by ROM Kernel routines (or >elsewhere in the OS), or must the user run a separate program? > > >Wes Plouff The system recognises the 68020 and turns on the cache. CSA provide routines to turn the cache on and off. It makes about 30% difference in the speed of the 68020 for programs like fastman (mandelbrot). I haven't found a single incompatible program which worked when i turned off the cache but i haven't tried very hard. I still can't get my 68020 to work with my A2090 board this may be a consideration if you are looking at such a system. Also CSA provides a modification required for b2000 rev 4.0 4.2, 4.1 doesn't work at all! (correct?) this has to be done to the main board and requires one wire link and one cut track. Hope this is of use. Kit Smithers kjws@ukc.UUCP or !mcvax!ukc!kjws
harald@ccicpg.UUCP ( Harald Milne) (01/10/88)
In article <8801081459.AA16543@decwrl.dec.com>, plouff@nac.dec.com (08-Jan-1988 0946) writes: > For Commodore folks: This month's _AmigaWorld_ has an article > about the CSA 68020 board for the A2000. The performance numbers seem > disappointingly low, and some of the explanations a bit screwy. Can > someone answer two simple questions? The answers to these are not > obvious in my rather meager document set or from rereading the slush > pile of saved comp.sys.amiga articles. Well this has not been discussed at great length. I read this article, and was suprised to learn that the 68020 would run slower than the 68000. I got an answer from fellow engineers working with 68020 controllers. The 68020 works well with a 32 bit bus. The Amiga is 16. When the 68020 requests a 32 bit quanity like an address, it has to generate 2 address requests to retrieve this data. More time spent in bus transfers. Your are right, the answers are not obvious. > 1. When the operating system recognizes a 68020, what exactly does it > do? As far as I know, it adjusts for the difference in stack frames, and you can query the CPU type. > Is the '020 instruction cache turned on by ROM Kernel routines (or > elsewhere in the OS), or must the user run a separate program? Good question. > 2. Other than running self-modifying code, can one get in trouble > running with the cache enabled? Wow, I have not even considered cache coherency. What a HUGE can of worms. If memory is written to without the CPU's knowledge, then that "hit" in the cache is "dirty". For the 68020 this should not be a big deal. Self modifying code? You want to do this? (Ive done this to an 8080 to get to port addresses, but yucko!). Now if we were talking about the 68030, we would be getting into big trouble, since the 68030 also caches data. The Amiga with all her coprocessors writing into memory, could not garentee data is not "dirty" without bus watching techniques (The same problem occurs in multi-processing environments). I guess that means the 68030 cache has gotta go! 8^( I was hoping to see cache expansion versus 32-bit memory solutions. You know, like using the TI cache extension chip. Please! Somebody tell me I am wrong! -- Work: Computer Consoles Inc. (CCI), Advanced Development Group (ADG) Irvine, CA (RISCy business! Home of the CCI POWER 6/32) UUCP: uunet!ccicpg!harald
daveh@cbmvax.UUCP (Dave Haynie) (01/12/88)
in article <8801081459.AA16543@decwrl.dec.com>, plouff@nac.dec.com (08-Jan-1988 0946) says: > > 1. When the operating system recognizes a 68020, what exactly does it > do? Is the '020 instruction cache turned on by ROM Kernel routines (or > elsewhere in the OS), or must the user run a separate program? The '020's cache is turned on by the OS, and left alone after that. The OS also sets the 68020 flag in ExecBase, and the 68881 flag if appropriate. The GetCC() vector is also set for the 68020, and any internal OS uses of exception stack frames (if any) are set so the OS will run just fine. > > 2. Other than running self-modifying code, can one get in trouble > running with the cache enabled? I've never found any reason to turn off the cache. Even though the C-A board (A2620 by name) has on-board RAM, making a run from 16 bit only RAM rather moot, I have found that with all 32 bit RAM disabled, the 68020 system will run slightly faster than the plain 68000. This speed increase is probably attributable to caching and to the fact that non-memory operations will still happen at 14.2MHz. I don't understand why the CSA board would run slower from 16 bit memory than the 68000, though never having used the CSA board I'm not in a position to argue that point. But it's obviously an implementation detail if anything, not a fundamental problem with 68020s on the Amiga. > Thanks in advance, > Wes Plouff > Digital Equipment Corp. UUCP: ...!decwrl!nac!plouff > Littleton, Mass. Internet: plouff%nac.dec@decwrl.dec.com -- Dave Haynie "The B2000 Guy" Commodore-Amiga "The Crew That Never Rests" {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"
daveh@cbmvax.UUCP (Dave Haynie) (01/13/88)
in article <8822@ccicpg.UUCP>, harald@ccicpg.UUCP ( Harald Milne) says: > Well this has not been discussed at great length. > I read this article, and was suprised to learn that the 68020 > would run slower than the 68000. > I got an answer from fellow engineers working with 68020 controllers. > > The 68020 works well with a 32 bit bus. The Amiga is 16. When the > 68020 requests a 32 bit quanity like an address, it has to generate 2 > address requests to retrieve this data. More time spent in bus transfers. What you're missing here is that, in most cases, the 68000 would also have to run two memory cycles. The 68000 works with 32 bit addresses just like the 68020, even if only 24 bits of those addresses are considered significant. With the cache enabled, we've found a 68020 board, depending on design, can run somewhat faster than a 68000 out of slow 16 bit memory. Give it fast 32 bit memory and you're talking about a 3x-4x speed increase. > -- > Work: Computer Consoles Inc. (CCI), Advanced Development Group (ADG) > Irvine, CA (RISCy business! Home of the CCI POWER 6/32) > UUCP: uunet!ccicpg!harald -- Dave Haynie "The B2000 Guy" Commodore-Amiga "The Crew That Never Rests" {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (01/13/88)
In article <3129@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >in article <8801081459.AA16543@decwrl.dec.com>, plouff@nac.dec.com (08-Jan-1988 0946) says: >> 2. Other than running self-modifying code, can one get in trouble >> running with the cache enabled? > >I've never found any reason to turn off the cache. > If you want to play Dark Castle, you'll have to turn the cache off, guy. BTW, I recently acquired an '020/'881 card (slightly nefariously, I must confess (I don't know why I *must* confess, but there it is)), and have found the following things to work/not work: Stuff that works: Product: Made by: Works only if you: Comments: -------- --------------- ------------------ --------- Dark Castle Three Sixty Turn cache off Faery Tale MicroIllusions Runs Great! Shanghai Activision Mind Walker Broderbund/Synapse Marble Madness Electronic Arts It Works! Surprise! Sonix Aegis Perfect! Hacker II Activision Flight Simulator subLogic Seems no faster. VideoScape 3D Aegis Deluxe Paint Electronic Arts Perspective faster <All killer demos work, too. Nemesis runs a bit too fast, though.> Stuff that doesn't work: Product: Made by: Problem: -------- --------------- ----------- AudioMaster Aegis Samples *WAY* too fast; all other functions OK. There's a lot of stuff I don't have.... _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
harald@ccicpg.UUCP ( Harald Milne) (01/13/88)
In article <3129@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes: > in article <8801081459.AA16543@decwrl.dec.com>, plouff@nac.dec.com (08-Jan-1988 0946) says: > > 1. When the operating system recognizes a 68020, what exactly does it > > do? Is the '020 instruction cache turned on by ROM Kernel routines (or > > elsewhere in the OS), or must the user run a separate program? > The '020's cache is turned on by the OS, and left alone after that. The OS > also sets the 68020 flag in ExecBase, and the 68881 flag if appropriate. The > GetCC() vector is also set for the 68020, and any internal OS uses of > exception stack frames (if any) are set so the OS will run just fine. But the cache must be purged at some point. If you exit a task, the code in the cache can hit again, with new code loaded into the same location, the result is disasterous. Is the cache ever purged? The OS must handle this somehow. > > 2. Other than running self-modifying code, can one get in trouble > > running with the cache enabled? > I've never found any reason to turn off the cache. There shouldn't be, provided the cache is properly handled. There must more going on than the above mentioned. > Even though the C-A board (A2620 by name) has on-board RAM, making a run > from 16 bit only RAM rather moot, I have found that with all 32 bit RAM > disabled, the 68020 system will run slightly faster than the plain 68000. A2620 eh? I like it. 8^) > This speed increase is probably attributable to caching and to the fact that > non-memory operations will still happen at 14.2MHz. I absolutely agree with that. > I don't understand > why the CSA board would run slower from 16 bit memory than the 68000, though > never having used the CSA board I'm not in a position to argue that point. > But it's obviously an implementation detail if anything, not a fundamental > problem with 68020s on the Amiga. Well to fill you in, the offending comments that appeared in the Feb issue of Amiga/World. To quote: (From page 28, first paragraph on that page) "The 68020 naturally generates 32-bit addresses and expects data in 32-bit chunks. It takes additional time for the processor to generate a 24-bit 68000 address to access the 16-bit memory of the Amiga." I think that's a bit ambiguous. The 68020 is claimed to run at 86% of the speed of the 68000. For some reason, this sound like it's running without the cache enabled. This was derived from running the Dhrystone benchmark from Fred Fish disk #1. Compiler unknown (At least to me at this moment, but I would suspect the inefficient Lattice compiler at that time period). The only explanation I have for this behaviour, is the need for an extra address cycle to get the other 16-bit quanity. (It would take 2 address cycles to get a 32-bit quanity from 16-bit memory, correct?) > Dave Haynie "The B2000 Guy" Commodore-Amiga "The Crew That Never Rests" > {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy > "I can't relax, 'cause I'm a Boinger!" I just can't relax either. Damm this Amiga. 8^) -- Work: Computer Consoles Inc. (CCI), Advanced Development Group (ADG) Irvine, CA (RISCy business! Home of the CCI POWER 6/32) UUCP: uunet!ccicpg!harald
mph@rover.UUCP (01/15/88)
In article <9055@ccicpg.UUCP> harald@ccicpg.UUCP ( Harald Milne) writes: >In article <3129@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes: >> in article <8801081459.AA16543@decwrl.dec.com>, plouff@nac.dec.com (08-Jan-1988 0946) says: > Well to fill you in, the offending comments that appeared in the Feb >issue of Amiga/World. > > To quote: (From page 28, first paragraph on that page) > > "The 68020 naturally generates 32-bit addresses and expects data in >32-bit chunks. It takes additional time for the processor to generate a 24-bit >68000 address to access the 16-bit memory of the Amiga." > Now you know why I dropped my Amiga World subscription - too much ignoramous verbosous. The 68000 also uses 32 bit addresses - at least from the code stream point of view. It has full 32-bit internal registers just like to '020 - in fact, the user model is identical. The slower speed is most likely the result of a poor implementation of the '020 to Amiga memory bus interface. Say wasted cycles in arbitration, or insertion of wait states to allow slow logic to settle. Another possibility is that somehow the '020 benchmark got its stack misaligned of perhaps its data area - this would trap on the 68000, but runs fine, albeit slower, on the 68020. Mark Huth
daveh@cbmvax.UUCP (Dave Haynie) (01/19/88)
in article <9055@ccicpg.UUCP>, harald@ccicpg.UUCP ( Harald Milne) says: >> The '020's cache is turned on by the OS, and left alone after that. The OS >> also sets the 68020 flag in ExecBase, and the 68881 flag if appropriate. The >> GetCC() vector is also set for the 68020, and any internal OS uses of >> exception stack frames (if any) are set so the OS will run just fine. > But the cache must be purged at some point. If you exit a task, the > code in the cache can hit again, with new code loaded into the same location, > the result is disasterous. Is the cache ever purged? The OS must handle this > somehow. I'm not exactly sure what happens here. You'll never run into trouble during task swaps, since everything running is running at a unique place in memory. If a program exits and a new one is loaded into that same memory location, obviously the cache must be purged, providing is could possibly contain any reminant of that removed program at that point. This isn't a very large cache we're talking about. Maybe Andy knows the truth here... > I think that's a bit ambiguous. > The 68020 is claimed to run at 86% of the speed of the 68000. > For some reason, this sound like it's running without the cache > enabled. I read the AmigaWorld article. I just can't think of any reason why this slowdown should be, other than as an "implementation detail" of the CSA board. Or perhaps the Dhrystone benchmark with the cache disabled hits some particularly bad features of any 68020 to 68000 interface. Have to try that benchmark on our board. > The only explanation I have for this behaviour, is the need for an extra > address cycle to get the other 16-bit quanity. (It would take 2 address cycles > to get a 32-bit quanity from 16-bit memory, correct?) Right. Whether you're a 68000 or a 68020. There's the rub. >> "I can't relax, 'cause I'm a Boinger!" > I just can't relax either. Damm this Amiga. 8^) I did relax a few weeks ago, but I had to fly a few thousand miles from my Amigas in order to achieve this feat. > Work: Computer Consoles Inc. (CCI), Advanced Development Group (ADG) > Irvine, CA (RISCy business! Home of the CCI POWER 6/32) > UUCP: uunet!ccicpg!harald -- Dave Haynie "The B2000 Guy" Commodore-Amiga "The Crew That Never Rests" {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"
harald@ccicpg.UUCP ( Harald Milne) (01/20/88)
In article <3161@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes: > in article <9055@ccicpg.UUCP>, harald@ccicpg.UUCP ( Harald Milne) says: > Well Dave, I wan't to personally thank you for your response. A big THANKS! > >> The '020's cache is turned on by the OS, and left alone after that. The OS > >> also sets the 68020 flag in ExecBase, and the 68881 flag if appropriate. The > >> GetCC() vector is also set for the 68020, and any internal OS uses of > >> exception stack frames (if any) are set so the OS will run just fine. > > > But the cache must be purged at some point. If you exit a task, the > > code in the cache can hit again, with new code loaded into the same > > location, the result is disasterous. Is the cache ever purged? The OS must > > handle this somehow. > > I'm not exactly sure what happens here. You'll never run into trouble > during task swaps, since everything running is running at a unique place > in memory. If a program exits and a new one is loaded into that same > memory location, obviously the cache must be purged, providing is could > possibly contain any reminant of that removed program at that point. This > isn't a very large cache we're talking about. Maybe Andy knows the truth > here... > Is Andy an OS guru? I'll probably get flamed for asking that. I know this an OS issue, and I know that as a hardware designer it would not be fair to ask you these questions. I feel that CBM has done a commendable job just in addressing this issue. Somebody at CBM was really thinking, to come up with solutions to these issues. Sorry, but Im just terribly curious about these implemention details. It's not that I'm worried that CBM did something wrong, I'm just curious just exactly what CBM did. I wasn't even aware that these "changes" were incorporated into 1.2. As an idiot consumer. It's not very obvious at the consumer level. Of course, on usenet, it's a different story. Does Max Toy read this? Anyway, little by little, I'm putting the pieces together. It's a bit painful, doing that from out "here". Is there any developer info attainable, that covers these issues? > > I think that's a bit ambiguous. > > > The 68020 is claimed to run at 86% of the speed of the 68000. > > > For some reason, this sound like it's running without the cache > > enabled. > > I read the AmigaWorld article. I just can't think of any reason why this > slowdown should be, other than as an "implementation detail" of the CSA > board. Or perhaps the Dhrystone benchmark with the cache disabled hits > some particularly bad features of any 68020 to 68000 interface. Have to > try that benchmark on our board. Please do Dave, I certainly would like to know. In fact I really would like to see these benchmarks run on all the consumer add-ons. As it stands, I would rather get a CBM supported enhancement, opposed to third party enhancements, since CBM should know where they are headed. And if CBM can deliver on their promise in delivering the most cost effective 68020/68881 or whatever solution, I for one would be one real happy SOB. I for one think CBM can. I'm holding out. Make my day! > > The only explanation I have for this behaviour, is the need for an extra > > address cycle to get the other 16-bit quanity. (It would take 2 address > > cycles to get a 32-bit quanity from 16-bit memory, correct?) > > Right. Whether you're a 68000 or a 68020. There's the rub. Ahhh. Thanks Dave, maybe I can relax now! 8^) I would hate to be the source of disinformation. I will not touch what I don't know. At least not in advice. Looks like you will not either. Commendable. Keep up the excellent work! > I did relax a few weeks ago, but I had to fly a few thousand miles from > my Amigas in order to achieve this feat. Boy can I understand that! > Dave Haynie "The B2000 Guy" Commodore-Amiga "The Crew That Never Rests" > {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy > "I can't relax, 'cause I'm a Boinger!" -- Work: Computer Consoles Inc. (CCI), Advanced Development Group (ADG) Irvine, CA (RISCy business! Home of the CCI POWER 6/32) UUCP: uunet!ccicpg!harald
stever@videovax.Tek.COM (Steven E. Rice, P.E.) (01/21/88)
In article <8822@ccicpg.UUCP>, Harald Milne (harald@ccicpg.UUCP) replied to some questions from article <8801081459.AA16543@decwrl.dec.com>, by plouff@nac.dec.com (08-Jan-1988 0946). Harald's answer to question #2 needs some amplification: >> 2. Other than running self-modifying code, can one get in trouble >> running with the cache enabled? > > Wow, I have not even considered cache coherency. What a HUGE can of > worms. If memory is written to without the CPU's knowledge, then that > "hit" in the cache is "dirty". For the 68020 this should not be a big deal. > Self modifying code? You want to do this? (Ive done this to an 8080 to get > to port addresses, but yucko!). > > Now if we were talking about the 68030, we would be getting into big > trouble, since the 68030 also caches data. The Amiga with all her > coprocessors writing into memory, could not garentee data is not "dirty" > without bus watching techniques (The same problem occurs in multi-processing > environments). > > I guess that means the 68030 cache has gotta go! 8^( Fortunately, no! There is an input, Cache Inhibit In (CIIN*), which inhibits cacheing of data and/or instructions on a cycle-by-cycle basis. By asserting CIIN* on each access to CHIP RAM, you will prevent the cacheing of data (and instructions) that come from the area accessible to the blitter, et. al. As long as you keep your instructions, stack, and non-displayed data in FAST RAM, you will still have the caches working for you. 8^) Steve Rice ----------------------------------------------------------------------------- * Every knee shall bow, and every tongue confess that Jesus Christ is Lord! * new: stever@videovax.tv.Tek.com old: {decvax | hplabs | ihnp4 | uw-beaver}!tektronix!videovax!stever
harald@ccicpg.UUCP ( Harald Milne) (01/23/88)
In article <4795@videovax.Tek.COM>, stever@videovax.Tek.COM (Steven E. Rice, P.E.) writes: > In article <8822@ccicpg.UUCP>, Harald Milne (harald@ccicpg.UUCP) replied > to some questions from article <8801081459.AA16543@decwrl.dec.com>, by > plouff@nac.dec.com (08-Jan-1988 0946). > > If memory is written to without the CPU's knowledge, then that > > "hit" in the cache is "dirty". For the 68020 this should not be a big deal. From giving thought to what Steve said below, I think the above needs to be answered a little differently. I overlooked the possibility instructions can be DMAed into CHIP RAM. It appears (That is assuming 68020 boards do run with cache enabled in CHIP RAM) that Amiga's OS would have to purge the cache. Since I don't know what the Amiga's OS does internally, specific to the 68020, somebody from CBM would have to answer this question. Then again, I could be making a wrong assumption here. Does anybody know? > > Now if we were talking about the 68030, we would be getting into big > > trouble, since the 68030 also caches data. The Amiga with all her > > coprocessors writing into memory, could not garentee data is not "dirty" > > without bus watching techniques (The same problem occurs in multi-processing > > environments). > > > > I guess that means the 68030 cache has gotta go! 8^( > > Fortunately, no! There is an input, Cache Inhibit In (CIIN*), which > inhibits cacheing of data and/or instructions on a cycle-by-cycle basis. > By asserting CIIN* on each access to CHIP RAM, you will prevent the > cacheing of data (and instructions) that come from the area accessible > to the blitter, et. al. > > As long as you keep your instructions, stack, and non-displayed data in > FAST RAM, you will still have the caches working for you. 8^) > > Steve Rice Now the question is, is there a signal present that indicates CHIP/FAST ram access? Is it present on the A2000 MMU conector? Im not sure I can trust my outdated A2000 schematics in my A2000 manual, which I don't have with me at this present time. Sorry about all the questions. -- Work: Computer Consoles Inc. (CCI), Advanced Development Group (ADG) Irvine, CA (RISCy business! Home of the CCI POWER 6/32) UUCP: uunet!ccicpg!harald
daveh@cbmvax.UUCP (Dave Haynie) (01/26/88)
in article <4795@videovax.Tek.COM>, stever@videovax.Tek.COM (Steven E. Rice, P.E.) says: > Fortunately, no! There is an input, Cache Inhibit In (CIIN*), which > inhibits cacheing of data and/or instructions on a cycle-by-cycle basis. > By asserting CIIN* on each access to CHIP RAM, you will prevent the > cacheing of data (and instructions) that come from the area accessible > to the blitter, et. al. Of course, you also want CINN* asserted for any access to any I/O devices. > As long as you keep your instructions, stack, and non-displayed data in > FAST RAM, you will still have the caches working for you. 8^) > Steve Rice And you make sure that you can invalidate the cache after a DMA from the expansion bus takes place. And intelligent map expansion devices into your CINN* equation; if the device is regular memory, you'd like it cachable, if it's an I/O device, or something weird like bridge card memory, you'd want it to be non-cachable. -- Dave Haynie "The B2000 Guy" Commodore-Amiga "The Crew That Never Rests" {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"
aburto@marlin.NOSC.MIL (Alfred A. Aburto) (01/26/88)
-------------- I recently posted some floating-point test results which can be used to compare the performance of the CSA Turbo-Amiga with 16-bit memory to the Amiga with 16-bit memory. All the Turbo-Amiga 7.16 MHz results which I posted were run with 16-bit memory. The 14.32 MHz results were all with 32-bit memory. ----------------------------------------------------------------------- Some comparisons (68020 Cache was ON, Software Floating-Point, 7.16 MHz Clock Speed, 16-bit memory): CPU Floating-Point Ops Per Sec Lattice C V3.03 68000 1.1 Lattice C V3.03 68020 2.5 Lattice C V4.0 68000 5.2 Lattice C V4.0 68020 5.7 Manx Aztec C V3.4B (mx.lib) 68000 2.3 Manx Aztec C V3.4B (mx.lib) 68020 4.4 Absoft Fortran 77 V2.2C 68000 3.2 Absoft Fortran 77 V2.2C 68020 6.2 ------------------------------------------------------------------------- Some more comparisons (68020 Cache was ON, Software Floating-Point, 14.32 MHz Clock Speed, 32-bit memory): CPU Floating-Point Ops per Sec Lattice C V3.03 68020 4.7 Lattice C V4.0 68020 15.3 Manx Aztec C V3.4B (mx.lib) 68020 8.7 Absoft Fortran 77 V2.2C 68020 12.7 ------------------------------------------------------------------------- Sun 3/160 Result (68020 Cache was ON, Software Floating-Point, 16.67 MHz Clock Speed, 32-bit memory): Sun f77 Release 3.4 68020 14.2 ------------------------------------------------------------------------- Seems to me the Amiga with 68020 and 16 or 32 bit memory performs fairly well and it compares favorably with other similar systems. Of course 32-bit memory is preferred (and the 68881). Al Aburto
aburto@marlin.NOSC.MIL (Alfred A. Aburto) (01/27/88)
---------
These are the Dhrystone V1.1 results with the Turbo-Amiga (68020) with
Cache ON and OFF, and with 16-bit and 32-bit memory. 50,000 iterations
were conducted with the 'register' option selected using Manx Aztec C
V3.4B.
System CPU Memory Clock Cache Time Dhrys/sec Gain Over
(bits) (MHz) (sec) Amiga 1000
Turbo-Amiga 68020 32 14.32 ON 16.48 3034 2.79
Turbo-Amiga 68020 32 14.32 OFF 18.20 2747 2.53
Turbo-Amiga 68020 16 7.16 ON 42.72 1170 1.08
Amiga 1000 68000 16 7.16 --- 46.00 1087 ----
Turbo-Amiga 68020 16 7.16 OFF 53.76 930 0.86
The Turbo-Amiga with 16-bit memory, 68020, and Cache OFF is a highly
degraded mode of operation. With the Cache ON some minor to moderate
performance improvements with 16-bit memory can be achieved.
Of course different test programs and different compilers will yield
different results. For example, with a program (FLOPS) which estimates
the average time to do double precision adds,subs,muls, and divides with
an output in thousands of floating-point operations per second (KFLOPS)
we get (with software floating-point):
------- 68020 Cache ON --------
System Language CPU Memory Clock KFLOPS Gain Over
(Bits) (MHz) Amiga 1000
Turbo-Amiga Lattice C V4.0 68020 32 14.32 15.3 2.94
Turbo-Amiga Lattice C V4.0 68020 16 7.16 5.7 1.10
Amiga 1000 Lattice C V4.0 68000 16 7.16 5.2 ----
Turbo-Amiga Absoft F77 V2.2C 68020 32 14.32 12.7 3.97
Turbo-Amiga Absoft F77 V2.2C 68020 16 7.16 6.2 1.94
Amiga 1000 Absoft F77 V2.2C 68000 16 7.16 3.2 ----
Turbo-Amiga Aztec C V3.4B(mx.lib) 68020 32 14.32 8.7 3.78
Turbo-Amiga Aztec C V3.4B(mx.lib) 68020 16 7.16 4.4 1.91
Amiga 1000 Aztec C V3.4B(mx.lib) 68000 16 7.16 2.3 ----
Turbo-Amiga Lattice C V3.03 68020 32 14.32 4.7 4.27
Turbo-Amiga Lattice C V3.03 68020 16 7.16 2.5 2.27
Amiga 1000 Lattice C V3.03 68000 16 7.16 1.1 ----
The 68020 with 16-bit memory (Cache ON) does provide performance
improvements over the 68000, but the amount of improvement is program
and compiler dependent. In some cases only a slight improvement (8% with
the Dhrystone) but in others maybe a factor 2 improvement (Absoft F77 above).
To get the most out of the 68020 we need to utilize 32-bit memory at higher
clock speeds as much as is possible in our programs --- then improvements
of nearly a factor of 3 over the 68000 should be fairly consistent it
appears.
Al Aburto
nosc!marlin!aburto
nosc!marlin.nosc.mil!aburtouzun@wolf.UUCP (Roger Uzun) (01/28/88)
Will the CA 2620 board have any sort of disabling feature. That is if someone has to run Barbarian, Terrorpods or some such piece of ... err .. Software will we be able to kick the 68020 off the bus without physically removing the card? -Roger "Move CC,<EA>" Uzun
uzun@wolf.UUCP (Roger Uzun) (01/28/88)
If anyone has the source to the Drhystone or Whetstone or any other standard benchmarks could you post it or mail it to me. In C that is. Thanks -Roger "Collecter of Meaningless Numbers" Uzun
hah@mipon3.intel.com (Hans Hansen) (01/29/88)
In article <3204@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes:
$in article <9750@ccicpg.UUCP>, harald@ccicpg.UUCP ( Harald Milne) says:
$
$> Now the question is, is there a signal present that indicates
$> CHIP/FAST ram access?
$>
$> Is it present on the A2000 MMU conector?
$
$Basically. To detect CHIP RAM for any CPU cycle, look at A23, A22, and A21.
$Are they all 0. Yes? You're accessing CHIP RAM. No? Not in CHIP RAM.
$<poof>
Not completely true. The A500 and B2000 are inserting the additional 512K
of RAM inside of the CHIP memory port and it must be addressed with the
same constraints as CHIP RAM. As such this additional 512K is not really
fast RAM. For those who are new to the Amiga the A500 and B200 are looking
to the future when they will have the FAT AGNUS (addresses 1Meg instead of
the 512K that AGNUS addresses). To make the conversion easy CA Engineering
have a jumper in the A500 and B2000 to change the addressing from $080000 to
$C00000.
$--
$Dave Haynie "The B2000 Guy" Commodore-Amiga "The Crew That Never Rests"
$ {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy
$ "I can't relax, 'cause I'm a Boinger!"
Hans hah@inteloa.UUCP4526P@NAVPGS.BITNET ("LT Scott A. Norton, USN") (01/29/88)
>I recently posted some floating-point test results which can be used >to compare the performance of the CSA Turbo-Amiga with 16-bit memory to >the Amiga with 16-bit memory. ... > CPU Floating-Point Ops Per Sec ^^^^^^^^^^^ I hope you mean "Million Floating-Point Ops Per Sec" :-) LT Scott A. Norton, USN Naval Postgraduate School Monterey, CA 93943-5018 4526P@NavPGS.BITNET 4526P@NPS.ARPA
cmcmanis%pepper@Sun.COM (Chuck McManis) (01/30/88)
|>>I recently posted some floating-point test results which can be used |>>to compare the performance of the CSA Turbo-Amiga with 16-bit memory to |>>the Amiga with 16-bit memory. |>... |>> CPU Floating-Point Ops Per Sec |> ^^^^^^^^^^^ |>I hope you mean "Million Floating-Point Ops Per Sec" :-) Hmmm, if they are MFLOPS then the military would definitely be interested. :-) But seriously, I think they were "K" FLOPs or Thousands/per second. Al ? --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.
kjws@eagle.ukc.ac.uk (K.J.W.Smithers) (01/31/88)
In article <628@wolf.UUCP> uzun@wolf.SanDiego.NCR.COM (PUT YOUR NAME HERE) writes: >Will the CA 2620 board have any sort of disabling feature. That is >if someone has to run Barbarian, Terrorpods or some such piece of >... err .. Software will we be able to kick the 68020 off the >bus without physically removing the card? > >-Roger "Move CC,<EA>" Uzun Whilst we're on the subject does anyone know how to get the CSA 68020 board to run in 68000 only mode. There *IS* a link which is marked '68000' and is supposed to provide such a function. CSA say however that the board still requires a modification for this to work. If so I might (stressed) be persuaded to sell my A1000 which is kept for my mindless amusement and as a debugging terminal. ------------------------------------------------------------------------------ STILL trying to go hard and fast .... Kit Smithers
daveh@cbmvax.UUCP (Dave Haynie) (02/02/88)
in article <628@wolf.UUCP>, uzun@wolf.UUCP (Roger Uzun) says: > Will the CA 2620 board have any sort of disabling feature. That is > if someone has to run Barbarian, Terrorpods or some such piece of > ... err .. Software will we be able to kick the 68020 off the > bus without physically removing the card? Yup. Basically, during a full reset, you'll be able to disable the 68020, dropping back of course to the 68000. The 68020's RAM won't be available to you, but it does allow 68000 operations. This option wasn't put in to let you run things that break on the 68020, though as a side effect, it will of course let you do just that. Such programs are broken anyway if they don't work on the '020, and should be upgraded by their publishers. However, if you're developing a program on the 68020, it's very possible to generate code that'll break on a 68000 without meaning to. For instance, the 68020 doesn't care about word alignment of it's data, while misaligned data on the 68000 is an open invitation to the GURU. Things like that. I'd hardly expect any developer to have to go out and buy a second Amiga just for 68000 compatibility testing. So you get this compatibility mode. > -Roger "Move CC,<EA>" Uzun -- Dave Haynie "The B2000 Guy" Commodore-Amiga "The Crew That Never Rests" {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"
daveh@cbmvax.UUCP (Dave Haynie) (02/02/88)
in article <2769@omepd>, hah@mipon3.intel.com (Hans Hansen) says: > In article <3204@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: > $in article <9750@ccicpg.UUCP>, harald@ccicpg.UUCP ( Harald Milne) says: > $> Now the question is, is there a signal present that indicates > $> CHIP/FAST ram access? > $> Is it present on the A2000 MMU conector? > $Basically. To detect CHIP RAM for any CPU cycle, look at A23, A22, and A21. > $Are they all 0. Yes? You're accessing CHIP RAM. No? Not in CHIP RAM. > $<poof> > Not completely true. In the context of cache consistency, that IS completely true. And that's what this thread is about, eh? What's that they say about questioning wizards.... > The A500 and B2000 are inserting the additional 512K of RAM inside of the > CHIP memory port and it must be addressed with the same constraints as CHIP > RAM. EXCEPT for things that relate to custom chip operation. Like cache consistency. You don't your data cache to cache CHIP RAM, because something like a BLIT or some floppy disk DMA will write to it. Only, from the point of view of the rest of the system, you're never sure when that writing will take place. So you don't cache any of it. Agnus can't write to $C00000 memory any more than she can write to the first Fast RAM card you've got sitting autoconfigured at $200000. So the only rules you have follow in dealing with cache consistency are those you apply to system/expansion bus DMA. The $C00000 RAM looks exactly like Fast RAM in this case. > Hans hah@inteloa.UUCP -- Dave Haynie "The B2000 Guy" Commodore-Amiga "The Crew That Never Rests" {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"
aburto@marlin.NOSC.MIL (Alfred A. Aburto) (02/03/88)
> >Hmmm, if they are MFLOPS then the military would definitely be interested. :-) >But seriously, I think they were "K" FLOPs or Thousands/per second. Al ? > >--Chuck McManis Yes, you're right. I goofed it up. Should be "thousands of floating-point operations per second", or "KFLOPS". Thanks.
alex@xicom.UUCP (Alex Laney) (02/09/88)
In article <2769@omepd>, hah@mipon3.intel.com (Hans Hansen) writes: > > ... To make the conversion easy CA Engineering > have a jumper in the A500 and B2000 to change the addressing from $080000 to > $C00000. If the jumper is set the other way today, what is the result? Does think make the memory block unusable? Is it another way of making the A2000 look like an A1000. I've not seen it mentioned the result of toggling the jumper. -- Alex Laney alex@xicom.UUCP ...utzoo!dciem!nrcaer!xios!xicom!alex Xicom Technologies, 205-1545 Carling Av., Ottawa, Ontario, Canada We may have written the SNA software you use. The opinions are my own.
bryce@eris (Bryce Nesbitt) (02/21/88)
In article <508@xicom.UUCP> alex@xicom.UUCP (Alex Laney) writes: |In article <2769@omepd>, hah@mipon3.intel.com (Hans Hansen) writes: |> |> ... To make the conversion easy CA Engineering |> have a jumper in the A500 and B2000 to change the addressing from $080000 |> to $C00000. | |If the jumper is set the other way today, what is the result? The OS will appear to come up with 1 Megabyte of chip ram. This will crash out as soon as memory is filled up enough to hit the "extra" 512K of not-really-chip-ram. |\_/| . ACK!, NAK!, EOT!, SOH! {o o} . Bryce Nesbitt (") BIX: mleeds (temporarily) U USENET: bryce@eris.berkeley.EDU -or- ucbvax!eris!bryce