Re: What is byte-code ?

Chris Dollin <kers@hpl.hp.com>
31 Mar 2005 23:33:02 -0500

          From comp.compilers

Related articles
[10 earlier articles]
Re: What is byte-code ? torbenm@diku.dk (2005-03-15)
Re: What is byte-code ? kers@hpl.hp.com (Chris Dollin) (2005-03-15)
Re: What is byte-code ? xous@xouslab.com (Xous - Jose R. Negreira) (2005-03-18)
Re: What is byte-code ? nathan.moore@sdc.cox.net (Nathan Moore) (2005-03-24)
Re: What is byte-code ? anton@mips.complang.tuwien.ac.at (2005-03-31)
Re: What is byte-code ? anton@mips.complang.tuwien.ac.at (2005-03-31)
Re: What is byte-code ? kers@hpl.hp.com (Chris Dollin) (2005-03-31)
Re: What is byte-code ? nathan.moore@sdc.cox.net (Nathan Moore) (2005-04-02)
Re: What is byte-code ? slimick@venango.upb.pitt.edu (John Slimick) (2005-04-11)
Re: What is byte-code ? kers@hpl.hp.com (Chris Dollin) (2005-04-11)
Re: What is byte-code ? anton@mips.complang.tuwien.ac.at (2005-04-11)
Re: What is byte-code ? nathan.moore@cox.net (Nathan Moore) (2005-04-16)
Re: What is byte-code ? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2005-04-16)
[2 later articles]
| List of all articles for this month |

From: Chris Dollin <kers@hpl.hp.com>
Newsgroups: comp.compilers
Date: 31 Mar 2005 23:33:02 -0500
Organization: HPLB
References: 05-03-015 05-03-026 05-03-053 05-03-088
Keywords: interpreter

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



Post a followup to this message

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