68020 performance on an A500 and bad magazine articles

[teppic]

I was reading an article from Amiga Computing. Now I know they didn't have the internet to check things as easily, but there seems a lot wrong here.

The 68000, which we all know and love, has a 24 bit address bus and 16 bit internal registers. That is, it can move data internally 16 bits at a time. It works at a clock rate of 7.16MHz — a respectable rate of knots — but there is always room for improvement.

The model up from the 68000 is the 68010, which is slightly faster because it has an internal ram cache. Here the processor remembers the last couple of bytes it was looking at and a few bytes on either side for good measure.

After completing execution of an instruction it checks to see whether or not it can use the data held in its ram instead of reading the slower main memory. If it can, the operation is much faster, since no external accessing has to be carried out.

The 68020 goes one step further because it is a 32 bit processor. This sounds wonderful until you realise that the processor needs two cycles of the 7.16MHz clock to read the data from the Amiga's 16 bit ram into its registers. The Animate Turbo Board counters this problem by upping the clock rate to a whoppingly fast 14MHz.

Unfortunately — isn't there always an unfortunately? — the rest of the custom chips in the Amiga will still chug along at 7MHz, limited by the speed the processor can get the operating system data from the roms.

I was wondering about the actual situation, as I'm unsure of a few things.

If the 68020+ is connected to the Amiga's 16bit RAM I would think it doesn't need to make any more accesses than the 68000 for the same data?

I know that the custom chips won't run any faster with a 32bit/higher clocked CPU, so my assumption is that it's only slow due to two things:

i) the bus is being locked by the custom chips (just as it is with the 68000), making the CPU wait

ii) the CPU is being limited by the bus speed it uses to access the memory, which is still running at the usual rate (I don't know if this is actually ~7MHz)

i.e. nothing at all to do with it being a 32bit processor.

These two things would also presumably be removed if you had any fast ram installed and used that (whether it's 16 or 32bit).

[derSammler]

There is nothing wrong in that article.

If software is compiled for the 020 and making full use of 32-bit, you need two 16-bit reads from memory for anything that is stored as 32 bit. For older software, nothing changes, of course.

[teppic]

How would you not need two reads from memory on the 68000? It explicitly says the 020 has to make twice as many RAM reads as the 68000 because it's 32bit.

As for nothing wrong... the registers aren't 16bit on the 68000. The 68010 doesn't have a ram cache, it has a very limited loop cache. The speed of the custom chips doesn't have anything to do with ROM accesses. Increasing the CPU freq to 14MHz wouldn't make it access a 7MHz bus twice as fast.

Another quote from it,

Other programs actually ran slower by a very small amount, probably due to the increase in processing speed being absorbed by the need to access ram twice as often.

[No.3]

Forget about this article, almost everything is wrong there.

[teppic]

Originally Posted by No.3

Forget about this article, almost everything is wrong there.

It followed on from an earlier article in the magazine which said very similar things. This one was from John Kennedy, while the earlier one was Jez San.

In the earlier one he said that the 68020 isn't really any faster than the 68000 in most cases on an A500 because it has to do everything in 32bits (again, saying it therefore needs to access RAM twice as often), while the 68000 can do it once with it being connected to 16bit RAM.

With multiple articles on this I was wondering if I was missing something...

[AestheticDebris]

I suspect the author just didn't understand 680x0 architecture. He's assuming (incorrectly) the the 68000 was entirely 16-bit and thus optimal when hooked up to a 16-bit bus, whereas the 020 is 32-bit and must therefore be having to double access memory each time it reads because of the 16-bit bus.

This might be true on some architectures, but 680x0 doesn't really work like that. Logically it's designed like a 32-bit CPU, it just accesses things in 8, 16 or 32 bit chunks depending on the bus size available. Now it's certainly true to say a 68020 isn't running at full speed when accessing 16-bit memory, but that doesn't make it slower than a 68000, just slower than a 68020 with a 32-bit bus.

[No.3]

The 68000 has 32 bit registers and a 32 bit instruction set (but the ALU is only 16 bit). The data bus is only 16 bits wide i.e. when e.g. working with 32 bit data, the 68000 has to do two 16 bit RAM accesses to piece together the 32 bit data.

The 68020 is a full 32 bit processor i.e. also the ALU is 32 bit and the data bus is 32 bit. As the A500 memory is only 16 bit wide there are, again, two 16 bit RAM accesses required to piece together the 32 bit.
When working with 16 bit data it doesn't seem to matter (for the 68000 as well for the 68020) but it does, as optimized software will read/write two 16 bit data at once i.e. instead of two 16 bit memory accesses it will do one 32 bit memory access which is quite a lot faster!

=> It is brain dead to run a 68020 without 32 bit memory, but I know, there were a few A500/2000 turbo cards without 32 bit memory.

[teppic]

I'm guessing that the main issue with running a 68020 without direct memory attached is the Amiga bus - it's going to have to be running effectively the same MHz as the 68000 whenever it's accessing memory? And on top whenever the chipset wants to access the memory the 68020 is going to have to sit and wait for it.

It'd be interesting to know how a 68020 with access to 16bit fast RAM would compare (like the memory you can add to a hard drive expansion). I guess the slow bus speed would still have a big impact, but at least it wouldn't have any contention for the memory.

As for a 14MHz 68020 actually running a little bit slower than the 68000 on the machine for many programs as that article says - that seems ... strange?

[Thomas Richter]

The difference is that the 68020 requires less clock cycles to perform the same operation compared to the 68000, and the 68020 has an instruction cache, so it does not have to access the RAM for every instruction fetch. The statement above that the 68010 has a cache is wrong - it does not. It only has a loop mode where an instruction fetch of a single 16-bit word upfront a "dbcc" instruction is not needed. That rarely help.

[Karlos]

A 68020 on a 14MHz 16-bit bus shouldn't be dramatically worse than running it on a 32-bit bus at 7MHz. The Falcon 030 got away with using a 16-bit bus at 16MHz;

Of course, running it on a 14MHz 32-bit bus to uncontended local fast memory is the only way to fly.

[teppic]

Originally Posted by Karlos

A 68020 on a 14MHz 16-bit bus shouldn't be dramatically worse than running it on a 32-bit bus at 7MHz. The Falcon 030 got away with using a 16-bit bus at 16MHz;

Of course, running it on a 14MHz 32-bit bus to uncontended local fast memory is the only way to fly.

With a 14MHz 68020 using the Amiga's system memory though it's going to be a 14MHz CPU working with a 7MHz system bus though isn't it?

I've read before that the effective system bus is 3.5MHz, but I don't know the details.

I'd imagine that aside from the instruction cache, the 68020 can't run really much faster than a 68000 without access to its own faster memory.

[teppic]

I did some more research on this, and it seems using chip memory is the major issue with upgraded CPUs. If I understood correctly this is the situation:

The chipset controls the bus every alternate cycle, so the 7MHz memory speed on chip RAM is effectively reduced to 3.5MHz for the CPU -- no matter what kind of CPU is running. That's before any slow downs due to slow chipset operations.

That isn't an issue for the 68000 as it only accesses memory ever other cycle anyway.

An upgraded 68020 at 14MHz is then accessing chip memory at a maximum of 3.5MHz and that will be effectively lower when the chipset is busy as the CPU is forced to wait.

With any 16bit fast RAM installed, the 68020 (or higher) can access that at the full 7MHz without any delays from the chipset.

With 32bit memory installed on the CPU expansion card you do obviously gain the benefit of the full data width being used, but that would seem to have less of an impact than effectively running memory at 3.5MHz max.

If anything's incorrect there please do let me know.

[No.3]

The memory (and all the other buses) are clocked @ 3.5 MHz and with a 16 Bit bus this gives an overall bandwidth of 7 MB/s.


With Chip-Mem the CPU can, theoretically, have 7 minus what-graphics-and-other-DMA-accesses-need MB/s. In reality the technical maximum is at 3.5 MB/s as normally the CPU can access Chip-Mem only every second cycle.

Using real Fast-Mem the CPU has the full bandwidth of 7 MB/s as it can access the 3.5 MHz clocked memory at every cycle.

It does't matter if it is a 68000 or a 68020 CPU, both are limited to 3.5 MB/s respective to 7 MB/s. (and 32 bit fast-mem @ 3.5 MHz would result in 14 MB/s for the 68020)


As I already said, if the 68000 wants to read 4 bytes of data from memory it has to do two 16 bit reads from memory.
The 68020 would like to read the 4 bytes of data using a single 32 bits read from memory, but if the memory is only 16 bits wide the access has to be split a into two 16 bit reads slowing down the 68020.

[teppic]

According to what I read the 68000 only accesses memory every other bus cycle, and the chipset use the other cycle to lock chip ram for their access (regardless of what the CPU is doing).

If the memory bus is only 3.5MHz then that'd mean the CPU could only access the bus half of that time (i.e. equivalent to a 1.75MHz bus), which seems very low.