>>
>> I've been thinking about this since reading your email, and it occurs
>> to me the microops may be loads, ops, stores, or opstores and still
>> roughly fall into a RISC style architecture. Stores have to wait
>> around in the store queue anyway, so they could wait for their data to
>> be generated by the ALU without a significant penalty. The most common
>> sort of macroop is a load/op/store where one operand is in memory. In
>> those cases, if you merge the op and the store, you'd go from 3 ops to
>> 2, explaining (in this simplified version of the world) the 1.5x
>> difference. If you look at the SSE instructions, this sort of single
>> memory operation and computation merging is how a lot of them are
>> organized, although perhaps loadops instead of opstores (I forget the
>> details).
>
> My general impression is that we go too far in terms of saying "here's
> a minimalistic RISC-like set of uops and I'm going to build everything
> out of that" as opposed to "if I'm going to implement x86, what uops
> should I implement to be able to do that efficiently".  You may well
> be right about at least one source of the uop bloat, but it would be
> better at this point to have some hard evidence of which specific
> instructions or types are causing the increase.

Yeah, picking the microops was a big concern for me when I was  
starting out. If you remember, I closely based what we have now on  
that patent I found for what looks like an older, 32 bit version of  
AMD's integer microop set. The SSE microops I just made up, but I  
spend a decent amount of time (a day or two) surveying the  
instructions, grouping them in various ways, identifying common  
behaviors, etc. In the end it's all a guess/approximation and it can  
never be 100% right like has been said, but the choice was far from  
arbitrary. I (and AMD before me, so to speak) did ask "if I'm going to  
implement x86, what uops should I implement to be able to do that  
efficiently".

Gabe

Gabe
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Reply via email to