| |
There are several opcodes defined in c_cmd_bytecodes.h which are missing from
the VM implementation in c_cmd.c
Here are the ones that are not implemented:
//Family: Bit manipulation
#define OP_CMNT 0x0A // dest, src
#define OP_LSL 0x0B // dest, src
#define OP_LSR 0x0C // dest, src
#define OP_ASL 0x0D // dest, src
#define OP_ASR 0x0E // dest, src
#define OP_ROTL 0x0F // dest, src
#define OP_ROTR 0x10 // dest, src
#define OP_CMPSET 0x13 // dest, src, testsrc, testsrc
#define OP_TSTSET 0x14 // dest, src, testsrc
#define OP_WAIT 0x34 // milliseconds
The bit manipulation set seem to have odd comments following them. I guess the
original plan was to shift dest by src and store the result in dest. Kind of
like a x <<= 3 sort of operation in C or C++. I'd prefer to have these opcodes
be implemented as binary operators like x = y << 4 where the opcode would take a
dest and two sources. If the first source happened to be the destination then
you would have the <<= or >>= version of the operation.
Can anyone from NI or LEGO comment on the intended meaning of each of these
opcodes? Would anyone care to post a short snippet of C code which demonstrates
what you think each of these opcodes should do? I'm not entirely sure whether
<< is a logical or an arithmatic shift or how to distinguish between a rotate
left, a logical shift left, or an arithmatic shift left. Does anybody else
think that having three different types of shifts is a bit more than we really
need?
The CMPSET and TSTSET opcodes seem to be intended to set dest equal to src if
the comparison or the test is true. That would allow for a more optimal code
generation of a simple if statement such as if (x < y) y = 4; Sounds pretty
simple to implement and useful to have available to use in NBC/NXC.
The wait opcode will be really nice to have implemented in the NXT firmware.
I'm inclined to think it will be the hardest to implement, though. We'll need
to come up with a nice way to mark the "clump" as being in the waiting state and
store the wakeup tick in the clump record then when the VM tries to execute code
in the waiting clump it will do nothing until the current tick is >= to the
wakeup tick and then it will go on to the next instruction. It is kind of like
calling a subroutine and then continuing on in the code once the subroutine
returns.
Other opcodes that will be nice to add to the NXT firmware include the OP_ABS
and OP_SIGN opcodes which are implemented in the NBC compiler right now.
Any other opcodes you all would like to have added to the NXT VM? Another set I
have been thinking about would be for doing fixed-point arithmetic using a
cluster type that would define the fixed point number. Maybe some
bitset/bitclear/bittest opcodes would be nice to have as well.
Your thoughts or comments?
John Hansen
|
|
Message has 1 Reply:
6 Messages in This Thread:
   
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
