I am swayed by your argument, although I should mention that in hardware, it really wasn't complicated to make MUX always execute. Immediates also always execute, so there are just some simple tests to determine if the instruction is predicated or not, and the predicate result is always an input to the ALU. That being said, I could eliminate all of that by using one or two conditional MOVs. Also, you have an excellent point about compilers. It seems like a sensible instruction, but if it's a huge challenge to get compilers to generate it, or it's used inefficiently, then we should just skip it. I didn't bother with rotate instructions for a similar reason. I'm sure that compilers do generate them, but there's no good way to specify them in high level languages, and they can be implemented using a few extra instructions.
Ok, so since I can't really work on this today, I'm just going to put it on the agenda: MUX will go away, and we'll have conditional MOV. On Wed, Mar 13, 2013 at 4:17 AM, Mark Marshall <[email protected]>wrote: > 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) >> > > -- 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)
