Hi all.

I've been thinking about Tim's todo list, and I'm going to try to note down
all of my thoughts.  I've also been hacking at some code, which I'll also
discuss.

(as always, this might be a bit "stream-of-consciousness")

Each assembler instruction can be of one of many different types of modes
where a mode describes the parameters to the instruction and where any
result is written.

All instructions write to zero or one register (this is true of all of the
instructions in the simulator and almost all assembly instructions I have
ever seen).  I am going to make the sweeping decision that this is true of
all of our instructions.

I will write the mode for an instruction that takes two registers as
parameters and returns the result into a registers as "R=op(RR)".  An
instruction that doesn't return a result would be written as "op(RR)".
Some instructions max take a integer or float as an additional operand, and
I will use I and F to represent them.  (For he C++ code, these get
shortened to RoRR and oRR).  A list of all the modes we are currently using
is therefore:

enum OpcodeMode {
    // 1 - flag
    // 2 - R
    // 3 - I
    // 4 - F
    OM_unknown = 0,
    OM_o       = 0x1000,
    OM_oF      = 0x1040,
    OM_oI      = 0x1030,
    OM_oR      = 0x1020,
    OM_oRF     = 0x1024,
    OM_oRI     = 0x1023,
    OM_oRR     = 0x1022,
    OM_Ro      = 0x1200,
    OM_RoF     = 0x1240,
    OM_RoI     = 0x1230,
    OM_RoR     = 0x1220,
    OM_RoRF    = 0x1224,
    OM_RoRI    = 0x1223,
    OM_RoRR    = 0x1222,
};

The mode will come in very useful when we are writing a parser or when we
are trying to define the instruction set's binary representation.

The size of I and F might be variable.  If they were always 32-bit then
that would be great, but often we only need a much smaller constant.  We
can sign extend small integers and we can build up 32-bit values by
concatenating smaller integers.  Floats can be built in the same way.  We
could pre-load constants into register memory before a GPU program is run
as well (this will make a lot of sense for infrequently used math constants
like pi, but we might still want to have a few small integers).

The mux and fmux instructions are different from all of the others.  For
every other instruction the predicate indicates if the instruction should
do anything, for mux it says what it should do (but the target is always
written to).  We can leave this inconsistency in, I'm just mentioning it
here.


Tim wanted some easily configurable instruction set.  I toyed with having
it defined by aa text file read at run time, but this doesn't work as you
need to have written the functions that get called for each instruction
before then.  My solution was to have everything instruction-set specific
in one C++ file, with a framework that should hopefully make it easier to
add or modify instructions.

The parser gets all of it information about the instruction set at run time.

The new parse is slightly cleaner than the old one (theres still a lot of
error checking that can be added).  It's quite dumb at the moment, but I
don't see any point in changing it yet (you have to specify every constant
as a single number, not an expression, for instance).


I've now checked in this new code.  You can probably most easily see the
changes that I've made by looking at the file test_spec.oga2.  The
instruction set is defined in shader-instructions.cpp.  I'll do a clean-up
pass later, and then this file should contain only instruction set specific
code.

As always, I'd like to hear what you all think.

Mark Marshall.


On 21 July 2012 23:50, Timothy Normand Miller <[email protected]> wrote:

> There are lots of things to do, but two simple ones that can be done
> short-term that I can think of are:
>
> - Parser for a general assembly language for the simulated processor
> - A binary representation for the machine language
>
> Since the instruction set is parameterizable, the number of bits in
> the binary representation of an instruction will vary with the
> parameters.  So I suggest we just use uint64 for simulation
> instructions and just populate however many bits are necessary.  So
> what we need is a dynamically constructed representation.  We can
> arbitrarily reject binary formats that require more than 64 bits per
> instruction, and in the case that the format needs less than or equal
> to 32 bits or even 16, there's no point in changing the data type in
> the simulator.
>
> --
> 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)

Reply via email to