paul@cacilj.UUCP (Paul Close) (05/17/88)
My question concerning the "fast" board is this: How much faster will
memory references be? It seems to me that the memory on the ST right now
has around a 120ns access time, just about right for one memory reference
every 8MHz clock cycle. So even if you run the CPU at 16MHz, the memory
STILL takes 120ns which now throws the processor into a wait state (or more?).
Net gains on memory accesses: 0. (Is my logic correct?)
Question two: would it be possible to replace the memory with faster chips
to eliminate or reduce the number of wait states? Otherwise memory won't be
faster, I/O won't be faster -- what do you actually gain?
--
Paul Close paul@cacilj.CTS.COM ...!{uunet, ucsd, crash}!cacilj!paul
Shaw's Principle:
Build a system that even a fool can use, and only a fool will want to use it.saj@chinet.UUCP (Stephen Jacobs) (05/18/88)
Paul Close correctly observed that if you speed up the cpu to 16 MHz but keep the 120 ns memory you'll introduce wait states. But a very rough estimate is that 68000 code has a memory reference about every 3 cycles (that's both oper- and and instruction references). The big problem is with video refresh, which is all memory references. But the compute part of operation should suffer relatively little from wait states.
rwa@auvax.UUCP (Ross Alexander) (05/18/88)
Paul Close wonders (use `p' to read parent article) if a 16 MHz cpu running on the current ST motherboard would be an improvement. My answer is Yes. Of course I/O and memory accesses can't be improved due to the timing and other restrictions of the design. But many, many instructions of the MC68000 repetoire uses cycles for things other than memory access; for instance, division and multiplication times are almost completely CPU-clock-speed dependant rather than memory-speed dependant. On the whole, one might not (will not) get a two-to-one speed up, but for math-intensive applications such as ray-tracing you will notice the improvement. Ross Alexander, Athabasca University alberta!auvax!rwa
gert@prls.UUCP (Gert Slavenburg) (05/19/88)
According to some local statistics of 68000's in operation, a crude approximation is that a 68000 spends approximately half of its cycles internal and half externally (due to memory reference statistics). The external cycles still take the same amount of time, the internal cycles go twice as fast. Hence, what used to take 'n' seconds, now takes '0.75*n' seconds. Or at most a performance of 1.33 * that of an ST with a 8 MHz processor. Add to this the fact that there is an increased number of memory requests per time unit, and hence more collisions with the video accesses (if this applies on the ST, I'm not sure). This would lower the performance a little more. So you get somehwere between a 1.2 to 1.33 * speedup, roughly. I wouldn't consider that enough of a speedup in relation to the expected cost.
pes@ux63.bath.ac.uk (Smee) (05/19/88)
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.
pes@ux63.bath.ac.uk (Smee) (05/19/88)
By the way, to anticipate the obvious next question, when the DMA is active, it steals memory cycles from the CPU (68000). The operant principle (as I keep saying) is 'the Video Shifter *ALWAYS* wins'.
lharris@gpu.utcs.toronto.edu (Leonard Harris) (05/22/88)
Also, why not just unsolder the st's 68000, cut the clock line from the MMU ( i think) and add a 16 MHz oscillator? Seems thats all thats needed. /leonard 16 MHz 68000 are scarce and costly up here in Toronto. What kind iof