Le Wed 19 Apr, à 12:01 -0700, James Richard Tyrer a écrit : > The problem with using the FORTH stack paradigm is that the shader has > to deal with long data which means that the registers need to hold 4 32 > bit floats. Since the length of the data varies, this would probably > result in a "sparse stack" (as in a sparse matrix) with a lot of "0"s > and wasted space. I don't understand why you need a 128 bit wide data stack. But this is true that, the wider the stack registers, the more wasted space.
> OTOH, my bytecode stack machine concept first parses the fetched data > stream and then puts it on the stack (which would be packed and 32 > bits wide) only as needed for operations that can not be immediately > executed. > > However, the stack approach has the advantage that if the program is > properly written that the stack acts as a cache and you never have to > fetch a variable from main memory twice. > > With my approach you would need a small memory segment and 1 way cache > to achieve this. With a small memory segment, all the data (including > what would be immediate data otherwise) for the current operation is > placed together (like with OS/360 assembler) and then it is copied once > on the first fetch into a cache which is really a local memory. You can > also have a scratch pad local memory to cache intermediate values that > don't need to be saved. This would be particularly applicable with a > shader since, IIUC, it outputs only one vector and everything else is > discarded. I'm sorry I don't have a clear idea of your bytecode stack machine concept. What I like with the Forth-style machine is that it is simple and efficient. It is also very small, so you can multiply the processor units. Robin _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
