Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!swrinde!ucsd!ucbvax!agate!shelby!neon!hoelzle From: hoelzle@Neon.Stanford.EDU (Urs Hoelzle) Newsgroups: comp.arch Subject: load delays on SPARC Message-ID: <1990Nov12.232129.21399@Neon.Stanford.EDU> Date: 12 Nov 90 23:21:29 GMT Organization: Computer Science Department, Stanford University Lines: 47 OK, here's something I've been wondering about for a long time: on the SPARC, loads take *always* at least 2 cycles, and stores take 3 (in all the Suns I know of). Even if the load's result isn't used by the next instruction. Why??? If the compiler is able to fill the load delay slots with other instructions, the load should be just one cycle, right? E.g. load [l0], l1 add l2, l3, l2 sub l2, 1, l2 add l2, l1, l2 ; use the loaded value *should* take at most 4 cycles. One argument would be that it is a Good Thing to avoid pipeline interlocks this way, speeding up the basic cycle etc. But SPARCs do have interlocks, and in the sequence load [l0], l1 add l1, l2, l1 the load takes *3* cycles. So if the control logic can stall the pipeline for one cycle to let the load complete, why not stall it for 1 or 2 and make the load one cycle? Similar story for stores: why not use a store buffer and make the store 1 cycle? Is there any SPARC implementation which does loads and stores in one cycle, and if not, why can others do it (e.g. MIPS)? I believe that the problems with loads & stores contribute significantly to the relative slowness (high CPI) of SPARC vs {MIPS,R6000,...} at identical clock rates. If I'm wrong, please correct me. [I know this is a question of implementation, not architecture - but why would anyone want to implement it this way?] -Urs ------------------------------------------------------------------------------ Urs Hoelzle, CS PhD student hoelzle@cs.stanford.EDU Center for Integrated Systems, CIS 42, Stanford University, Stanford, CA 94305 -- ------------------------------------------------------------------------------ Urs Hoelzle, CS PhD student hoelzle@cs.stanford.EDU Center for Integrated Systems, CIS 42, Stanford University, Stanford, CA 94305