Path: utzoo!attcan!uunet!mcvax!ukc!dcl-cs!bath63!pes
From: pes@ux63.bath.ac.uk (Smee)
Newsgroups: comp.sys.atari.st
Subject: Re: 16MHz board -- fast CPU, slow memory?
Message-ID: <2559@bath63.ux63.bath.ac.uk>
Date: 19 May 88 10:57:22 GMT
References: <725@cacilj.UUCP>
Reply-To: pes@ux63.bath.ac.uk (Smee)
Organization: AUCC c/o University of Bath
Lines: 34


The effect of a faster-clocked 68000 would be non-trivial to determine, and
would depend to a great extent on what (precisely) the program is doing --
in particular, how much of what it is doing is in the registers.

Even in the worst case, the 68000 cannot hit memory every clock cycle.  I
believe that the best you can get out of it (or worst, depending on point
of view), if you write a program designed to hit memory as often as possible,
is one memory reference every two cycles.  More typical programs should
make even fewer memory references.

On the other hand, this fact is already used to advantage.  In the ST, the
memory management chip actually GUARANTEES alternate clock (memory) cycles
to the Video Shifter.  The Video Shifter ALWAYS wins.

Because most 68000 instructions take even numbers of cycles to do things,
typical (or 'normal') operation is that the Video Shifter gets all the even
clock cycles, and the CPU gets to reference memory only during odd clock
cycles.  Usually both the Shifter and the CPU are happy with this arrangement,
because the Shifter is getting all the memory refs it needs, and the CPU is
being allowed to look at memory as often as it can actually cope with.  Since
some 68000 instructions may use odd numbers of cycles, and since the CPU and
the Shifter are not tightly synchronized, they may occasionally fall into
step.  In this case, the 68000 is WAITed (the Shifter ALWAYS wins) to get
them back onto alternate memory reference cycles again.

So, a faster-clocked 68000 wouold gain you NOTHING AT ALL during sequences
of instructions which require maximum rate (every 2 clock cycles) memory
references -- it would just spend more time being WAITed.  On the other hand,
it could go a lot faster when doing things which don't have to hit memory --
like multiply and divide which first come to mind.

The net effect, then, is fairly unpredictable, depends on the precise nature
of the program.