Hi. I'm glad to hear that there's some activity on the OGP again. It seems like an interesting idea that Timothy's had, and I'll definitely try to help as much as I can.
I like the processor design. It's what wikipedia calls a barrel-processor (which isn't a term I've seen used on this list yet http://en.wikipedia.org/wiki/Barrel_processor). It's nice, from a hardware point of view you have a very long pipeline, From a software point of view there is no pipeline (instruction N has fully completed before instruction N+1 has started). I've had a play with your code, and I have some questions and ideas for changes. I have actually made some of these changes,and a attach my modified version. Two minor changes: - As this is c++ I'd use bool's for booleans, not bit fields. - I'd rather not to use a hacky macro to convert a uint32 to a float, this should be a union (TO_INT, TO_FLOAT). The other coding change that I made was to have a slightly more powerful way of defining all of the opcodes. The macro INS_LIST (in oga2-opcodes.h) is a list of all opcodes. We use this one list to generate all per-opcode data. I added predicate support (a simple syntax for now. [4] before an instruction gives it predicate n). How is the predicate stuff supposed to work? Do you expect nothing to happen for an instruction where the predicate is false? (This needed adding for jmp). Your code sets write_target to false if the predicate is false, but what about instructions that don't write a target (memery requests & jmp's?). I added simple memory requests. This is a can of worms. I assumed that the memory requests only worked on 32-bit quantities and one-in-four 8-bit requests get promoted to a 32-bit request. consider: read-req addr=<foo> len=5 read 8 read 32 read 8 read 32 read 8 read 32 read 8 read 32 That sequence will read only 5 32-bit values. The first value read will be returned in four 8-bit chunks. The following sequence could also be valid (I think it should be): write 8 write 8 write 8 write-req addr=<foo> len=1 write 8 The four 8-bit values get packed into one 32-bit value. The write-req only has to happen before the fourth 8-bit write. (Basically, what I'm saying here is that it seems to make sense to split out the part of the memory pipe that does 32-bit to 8-bit splits from the rest of it. I think this will maek the hardware easier, and we can always disallow the slightly bizarre cases above in the compiler?) There are a few instructions that you are missing as well. We need variants that loads constants (I assume, possibly others, shifting by a constant amount, etc.). It's probably worth adding some instructions to help calculate some hard math functions as well. Square root and inverse square root spring to mind. We have a long pipeline, which means we could get a lot done. It would also be helpful (if we didn't want to calculate the whole square root) to calculate a partial answer. It's then much easier to calculate the complete answer in only a few instructions. t0 = aprox-square-root(X) t1 = (t0 + X/t0) / 2 If t0 has n bits of accuracy t1 has 2n bits of accuracy. (Theres a really nice geometric proof of this, which I love. We have a rectangle of area X. We need to convert it to a square of area X. A more "square" rectangle will have one side that is the average of the sides of our initial rectangle). Good work so far, and I might hack some more on this. I'd appreciate feedback on my changes and ideas. MM On 1 July 2012 20:22, Timothy Normand Miller <[email protected]> wrote: > Here you can browse the source of the first compilable version of the > OGA2 simulator. > > > http://sourceforge.net/p/openshader/code/ci/9d84745908ebdf51569b5efaa8b718aa4d81ab4b/tree/simulator/ > > My main goal was to get something to compile and run, however trivial. > As a result, there is some truly horrid coding, which I apologize > for. If you pull this tree and 'make' it, you'll get a demo that runs > three instructions in an infinite loop. > > -- > Timothy Normand Miller, PhD > http://www.cse.ohio-state.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)
