Dan Sugalski wrote: > Right now the only good way to find out if a value is true or not is > to do something like: > > $I0 = 1 > if $P0, done > $I0 = 0 > done: > > and look in $I0 for the result. This is OK, but if you're dealing > with a language with relatively primitive views of logical operations > (i.e they return 0 or 1) you end up with a *lot* of these little code > snippets when evaluating something like: > > if ((foo or bar) and ((x1 >= 12) or (x2 < 15) or (x5 and x6 and > x7)) goto somewhere > > (And yes, that's close to a real code snippet. Feel my pain here :) > Not a huge deal to translate, but once you hit 30K basic blocks in a > sub the register coloring algorithm really gets unhappy and dies an > unpleasant death after an hour or so.
So: branches are bad for modern (CPUs|VMs|...). I thought we'd established that? :) > Anyway, because of it I'm pondering non-flowcontrol logical ops. That > is, something like: > > istrue I0, P5 # I0 = 1 if P5 is true > isgt I0, P5, P6 # I0 = i if P5 > P6 There's definitely precedence for "primitive bools," which is one step beyond where you're writing about. PowerPCs have a condition register, which is really better thought of as a set of 32 one-bit boolean registers. The bits can be filled by gt and lt operators and the like. Next, they can be &&'d, ||'d, !'d, etc. Finally, the branch conditional instruction executes, deciding whether to branch just off of that one bit in the CR. Using CR operators can save pipeline bubbles over &&'s with branches. Of course, short-circuiting expression evaluation requires actually branching mid-expression. > Given the semi-self-serving nature of these I think some discussion's > in order first. Doesn't seem self-serving at all if it helps make common code constructs more amenable to the optimizer. -- Gordon Henriksen IT Manager ICLUBcentral Inc. [EMAIL PROTECTED]
