Path: utzoo!utgpu!water!watmath!clyde!att!mtunx!pacbell!ames!ncar!noao!nud!tom From: tom@nud.UUCP (Tom Armistead) Newsgroups: comp.arch Subject: Re: RISC machines and scoreboarding Message-ID: <1096@nud.UUCP> Date: 22 Jun 88 16:12:22 GMT References: <1082@nud.UUCP> <28200166@urbsdc> Reply-To: tom@nud.UUCP (Tom Armistead) Organization: Motorola Microcomputer Division, Tempe, Az. Lines: 25 In article <28200166@urbsdc> aglew@urbsdc.Urbana.Gould.COM writes: > >> On RISC processors without a scoreboard*, how are the results of memory >>references guaranteed to be available before they are used in subsequent >>2) If the compiler/assembly writer is required to wait a certain number >>of ticks after a load before using the results of the load, how is the >>required amount of delay determined? Can you assume you always get a > >Usually by assuming a cache hit; the entire processor stalls on a cache miss. >Details of the stall may vary. This makes sense for RISC processors with a common data and code bus. After all, if the data cache misses, the bus is being hogged by the data unit and the instruction unit then has to stall until the data transaction finishes (although a few instructions might have been prefetched). I had gotten used to the split instruction and data buses on the 88k which yields different behaviour in the above case. On the 88k, a data cache miss doesn't neccesarily create an instruction pipe stall. I think this is better from a performance standpoint but it does require some type of scoreboarding to handle the data dependencies properly. -- Just a few more bits in the stream. The Sneek