On Sat, Mar 23, 2013 at 10:17 AM, <[email protected]> wrote: > Hi ! > > Le 2013-03-23 14:34, Timothy Normand Miller a écrit : > >> On Sat, Mar 23, 2013 at 12:13 AM, <[email protected] [3]> wrote: >> >>> I would advise adding a ANDN instruction : AND with one inverted >>> operand. it speeds up boolean MUX sequences for example. >>> >> >> You mean like how this is done with SSE, where we make masks and AND >> and OR vectors together? Yeah. The thing is, since this is not a >> vector machine, can we accomplish the same thing with the same or >> better performance using conditional MOV? >> > > I'm not thinking about vectors here, but raw boolean. > I've used it quite a LOT, not in SSE but MMX anyway. > Furthermore you don't seem to have a practical way > of complementing boolean values. If you use XOR, > you need to preload a register with -1.
I think we might justify having a NOT instruction. Actually, NOT is a special case of SUB, where the carry flag is set to zero. Unfortunately, that requires that we first clear the carry flag. But I could add an extra R1 type instruction for this. I'm making a list of potentially useful instructions that don't really require any extra hardware. I'm probably forgetting something, but so far, I have NOT, FNEG, and FABS. What else would be nice to have? What else is already a special case of some other instruction? (Either already trivially, or with minor modification) What else is an integer instruction applied to a FP number? Ok, then there's the issue of booleans. Say you have a complex boolean expression. On a CPU, you can construct it out of a bunch of branches. But we'd like to predicate if we can. Now, in that case, we can't do short-circuit (can we?). The main idea would be to generate a sequence of bitwise operations where we then test the Z or N flags for predicating some instruction(s). We could make complex arrangements of instructions that perform these operations, where they predicate each other, leading ultimately to the expression we want. So, what do we decide is the canonical way to go about computing booleans? > > > I also think that the WR flag should be infered from the opcode. >>> >> >> Yeah, so the three places are the opcode, the dest register (i.e. >> zero), or an explicit bit. >> > > speaking about the dest register : I'm sure you could teach a compiler > to write to an arbitrary register and not read it back (it's "just a > matter" > of coloring a graph in such a way that it's not reused) > > Im still letting my subconscious work on >> that, but Im starting to really like the idea of having a 31-bit >> >> immediate. The question is: Which register do we store it in? If >> we use R0 as a bitbucket, then we cant use that; if we use the opcode >> >> then we can. R31 is often used (by convention) for subroutine return >> address. >> > conventions are configured into compilers. > > Remember one of the meanings of RISC : > "Relegate the Important Stuff to the Compiler" > and if you have to develop a compiler for your arch, > then you are full RISC. Don't let a compiler > (or what you think it can do or not) dictate your > architecture. Sure. This is why I've kept the instruction set to an absolute minimum. If I'm going to add an instruction, my resistance (impedance?) is lower if it's something for which I can add logic only in Decode. Really simple things, and things that have some clear performance benefit. > > > How do we inform a compiler of the fact that this is >> special-purpose? They have had to deal with the fact that x86 has >> special-purpose registers, like how CX is used for iteration count >> implicitly for some instructions, so probably not a big deal. >> > > in GCC there are files that configure that. > in other compilers... it's just "exceptions" to add > when handling the IR graph. > > > Otherwise, well, nice job :-) >>> >> >> Thanks. :) >> > > I hope you can continue to do your thing :-) > > > Me too. :) -- 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)
