Path: utzoo!attcan!uunet!ncrlnk!ncrcae!hubcap!gatech!udel!rochester!pt.cs.cmu.edu!k.gp.cs.cmu.edu!dkirk From: dkirk@k.gp.cs.cmu.edu (Dave Kirk) Newsgroups: comp.arch Subject: Re: penalty for microcode Message-ID: <3662@pt.cs.cmu.edu> Date: 22 Nov 88 15:53:22 GMT Organization: Carnegie-Mellon University, CS/RI Lines: 31 Distribution: usa References: <3290@ucdavis.ucdavis.edu> <7746@aw.sei.cmu.edu> <3634@pt.cs.cmu.edu> Organization: Carnegie-Mellon University, CS/RI In article bader+@andrew.cmu.edu (Miles Bader) writes: >> > >> >Now pass that microcode through a peephole optimiser, and trim it down. >> >If one operand is already in a microcode regitsr, don't move it there; >> ^^^^^^^^^^^^^^^^^^^ >> Any reasonable microcoder would have performed this optimization in his >> original code. If you are referring to your "new" expanded code, then >> please don't include it in your reduction costs over the original code. >But the two cases aren't the same; conventional microcode can't be optimized >with knowledge of the microcode due to previous (macro) instructions (because >they aren't known until run-time). If you were fetching inlined microcode >from ram, you could do this, and it probably would be an improvement >(how much? I dono...) over cisc microcode in rom. > Let me better explain my comment, and our micro architecture. Microcode registers look no different to the microcoder than macrocode registers. If there are 16 macro registers and 256 micro registers, the only difference in accessing the two is the actual address. Hence, the only time we ever "move anything to a register" is when the instruction says go to memory and get this operand. There is never a case when you move an operand from a macro register to a micro register, and THEN use it. As a result, advanced knowledge that a value may have been in a micro register during the previous macro instruction does not save any time or code. -Dave --