Re: What is byte-code ?

Nathan Moore wrote:


> Chris Dollin wrote:


(snip)


>> The most recent VM I wrote had instructions that were 16 bits
>> wide. You could say it had 16-bit bytes. (As it happens, the opcode
>> part was 5 bits wide, with 3 other bits that were either an operand
>> specification or more opcode - so you *could* say it was an
>> 8-bit-byte-code, because the opcodes are 8 bits wide and the operand
>> another 8.)


> I would not consider the interpreter's instruction set to fit the
> definition of "byte code". I don't believe that just because it
> is interpreted it is bytecode.


I agree.


> Plus I'll bet that you take another hit on the codes
> that use the 3 bits left from the first 8 bits as an additional portion
> of the opcode, b/c you have to decode that as well as the first 5 bits.


No; it's a single 256-way switch. (Earlier interpreters did work the way
you describe. It's horrible; one massive switch is bad enough, but one
large switch nested inside the massive switch is too much for me to keep
track of. I never got round to seeing if using an array of function pointers
had a sufficiently small performance penalty. Maybe the next time ...)


> In addition, in the instruction decode code you will have the result of
> INSN | MASK be all high valued bits for some hosts. This means that
> your "jump to" code (or switch/case code generated by the compiler) will
> have to scale this value in some way before using it to find the correct
> place to jump, which is an additional cost.


Easy fix: in the 16-bit opcode word, put the 5:3 at the low-order end.
You still need a mask, of course. Or - if you can - store the instructions
as I = (A, 5:3, B), where A::B are the opcode bits and the width of B is
such that the masked I is already suitable scaled. (You pay in the operand
access, but since I already needed a shift, it's just a little extra shift,
and on a beautiful machine [1], you can exploit rotates. But likely not
at the C level.)


> You also have to worry about endianness and portability.


Always.


[1] The ARM.


--
Chris "electric hedgehog" Dollin

Return to the comp.compilers page.
Search the comp.compilers archives again.