Hi. I've not had much to say recently, but I thought I'd jump in here.
I don't like the MUX instruction, and think we should remove it. When implementing the simulator it was a source of annoyance, it's the only instruction that behaves in this way (using the predicate bits differently). If it wasn't for this instruction it would have been very easy to handle the predicate logic in a very clean way, but this one instruction adds a lot of complexity. I also don't think it gains you very much. The use case seems to be very small, it allows us to copy either register A or register B into register C, but the only advantage of this over a conditional move is that it allows us to keep the three registers separate. I can't imagine many cases where we couldn't collapse either A & C or B & C into the same register, in which case a conditional move is all that is required. In the rare cases where we have to keep them separate I think an additional single instruction is acceptable. C = MUX(cond) A, B Can be written as: if(cond) C = A if(!cond) C = B I would always choose symmetry and simplicity. my two (euro) cents. Mark. PS. We're not trying to create instruction sets to make writing assembly programs nice and easy. We're creating instruction sets to make the compilers life easy. I don't know how easy it is to get GCC to issue a MUX instruction, but I bet it's much harder than the conditional move, which almost all instruction sets have these days. PPS. Have any of you ever looked at the Parallax Propeller instruction set? It's very interesting because it was basically designed to make writing assembler programs easy / cool / powerful (their market is very different from ours). http://www.parallax.com/propeller/ On 11 March 2013 16:32, Timothy Normand Miller <[email protected]> wrote: > Just for fun, let's argue about this. > > We have decided that MUX and MOV instructions are co-redundant. MOV is an > obvious special case of MUX, where one source is the destination or the > predicate is Always. MUX is just an abbreviation for AT MOST two MOV > instructions with opposite predicates, but it can often be implemented with > just a single conditional MOV if the other MUX input is already in the dest > reg. > > All things being equal, keeping MUX is better IN A BARREL PROCESSOR. The > problem is in the non-barrel case [*]; MUX _always_ introduces two register > dependencies, which can lead to more stalls. By contrast, if the predicate > for a MOV instruction resolves to false, we can just drop the instruction, > leading to NO stalls in the single-MOV case. > > We just don't want to unnecessarily keep these two instructions. > > Aaaaaannnnddddd... FIGHT! > > > > > [*] A barrel processor issues one instruction from each thread > round-robin, avoiding all branch and dependency hazards. The alternative > is to switch threads only on potential stall conditions. We want to > support this at least in the simulator. The tradeoffs between the two > options mostly pertain to interaction with cache miss latencies on loads. > > -- > Timothy Normand Miller, PhD > Assistant Professor of Computer Science, Binghamton University > http://www.cs.binghamton.edu/~millerti/ > Open Graphics Project > > _______________________________________________ > Open-graphics mailing list > [email protected] > http://lists.duskglow.com/mailman/listinfo/open-graphics > List service provided by Duskglow Consulting, LLC (www.duskglow.com) >
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
