Skip to main content
Home Forums 68kMLA Mac SE/30 to SCSI chip pinouts — #17
Post #17 by Gorgonops
Source Forum68kMLA
Category68k
Post DateThu, 11 Oct 2012 - 18:12
Original URLhttps://68kmla.org/bb/threads/mac-se-30-to-scsi-chip-pinouts.26313/
Post
I guess these old processors aren't pipelined at all?
Technically the 68030 *is* pipelined. (Going by the definition of "pipelining" meaning that the CPU is divided into functional units which can operate somewhat asynchronously with each other and execute certain tasks in parallel.) Even the 68000 is "slightly pipelined", in that it has the ability to prefetch the next instruction and decode it while the execution unit it is processing the current one. (The 68030's reference manual covers the details regarding it's pipelining; skimming, the short version seems to be that it prefetches and decodes up to three instruction words ahead, and those fetches can be coming from the internal instruction cache which also works independently.) Pipelining doesn't necessarily imply "Superscaler" (actually *retiring* more that one instruction at once) nor does it say anything about how many cycles a given step in the process takes. The 68040/80486 generation were the first consumer 32-bit CPUs that could execute a "typical" instruction in a single clock... not counting Acorn's ARM, of course.

(Even the lowly 8086 had some ability to run the bus interface and the execution unit in parallel in order to streamline processing of multi-word instructions, although this was somewhat hamstrung by the fact the CPU used the same ALU hardware used by the execution unit to do effective address calculations, meaning the "pipeline" would stall on every non-immediate memory access. The 80286 solved this problem, which was why it was four to six times faster than the 8086 clock-for-clock for some operations, making it arguably the biggest single performance leap in x86 history.)

I'm so used to thinking of a memory access taking one cycle these days, that I've always considered the SE/30 as having a theoretical bandwidth of 32 bits X 16 MHz = 64 MB/s. So wrong. Sigh.
Reading the application manual it looks like in theory the very fastest you can do a single 32 bit word memory transfer with the 68030 is in two cycles; manual says at 16Mhz you'll need ~45ns SRAM. The CPU also supports a "Burst Mode", *only* used for filling the onboard caches, that with sufficiently fast RAM takes 2 cycles for the first word and one cycle for each of the next three words. (Manual says you'll need 35ns or better SRAM, and you'll have to arrange it essentially as a 128 bit "wide" array that takes a single address at the start of the cycle and auto-increments for each subsequent read cycle.) I'm guessing Apple's bus simply ignores the burst modes and ties everything down to the maximum timings the DRAM controller can handle. So... if you were to re-engineer the SE/30 from *scratch* you could potentially push the numbers up to the 32MB/sec ballpark if you really, really wanted to. But if you look at the instruction timing tables you'll see that is pretty literally squeezing blood from a stone.

Look on the bright side: For 1987 a ~15Mb/sec memory bus was respectable, and was about the limit of DRAM technology at the time. The first 68040/80486-class machines didn't have much faster DRAM to work with, which was why caching was so important in the early 90's timeframe. (running from cache those machines could run rings around a 68030 but for a bulk memory copy it's all about the DRAM controller, and with 70-80ns RAM still typical you still might only be getting somewhere in the high 20's MB/sec without interleaving.) Context is everything when judging those machines.

mp.ls