Re: What is byte-code ? (Anton Ertl)
11 Apr 2005 00:22:56 -0400

          From comp.compilers

Related articles
[14 earlier articles]
Re: What is byte-code ? (2005-03-31)
Re: What is byte-code ? (2005-03-31)
Re: What is byte-code ? (Chris Dollin) (2005-03-31)
Re: What is byte-code ? (Nathan Moore) (2005-04-02)
Re: What is byte-code ? (John Slimick) (2005-04-11)
Re: What is byte-code ? (Chris Dollin) (2005-04-11)
Re: What is byte-code ? (2005-04-11)
Re: What is byte-code ? (Nathan Moore) (2005-04-16)
Re: What is byte-code ? (glen herrmannsfeldt) (2005-04-16)
Re: What is byte-code ? (2005-05-09)
Re: What is byte-code ? (glen herrmannsfeldt) (2005-05-13)
| List of all articles for this month |

From: (Anton Ertl)
Newsgroups: comp.compilers
Date: 11 Apr 2005 00:22:56 -0400
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
References: 05-03-015 05-03-026 05-03-053 05-03-088 05-03-125 05-04-005
Keywords: VM, interpreter
Posted-Date: 11 Apr 2005 00:22:56 EDT

Nathan Moore <> writes:
>Rather than the array of f() * , if you use gcc, you could implement it
>with an array of labels if you use gcc or another compiler that supports it.
>void * LABEL[256] = { ADD, SUBTRACT, ... };
>goto LABEL[instruction];
> /* add code */
> /* update instruction pointer to reflect that this one has been done */
> goto LABEL{instruction];
>This will save you about 2 jumps per instructoin since the jump tables
>that are usually spit out by compilers are:
>jump ip+(constant*case)

I have never seen that kind of code generated. Which compiler does it
that way? Big, dense switch statements have been translated into a
range check, an array access (for the target address), and an indirect
jump to the target in the code I looked at (usually by gcc).

By using the labels-as-values extension you at least get rid of the
range check (in theory, with a switch over an unsigned char, and all
256 possible values covered by cases, the compiler could get rid of
that by itself, but I have not yet seen a compiler that does this).

>and because you won't have to jump back to the initial jump to begin the
>next instruction.

The main benefit here is not the elimination of the direct jump, but
the increased prediction accuracy of the BTB for the indirect jump,
resulting in speedups by up to a factor of 2:

Unfortunately, since gcc-3.2 gcc tends to combine all indirect jumps
into one, and put a jump to this common indirect jump where the
indirect jumps should be. It looks like this will be fixed in
gcc-4.0. See

>If you were to do this, I would suggest that you make
>an automated process of building the C source file that has the
>implementation of the instructions in it from one or more files that
>contain the per-instruction implementations and make it so that the
>method of jump table can be changed for different compilers.

Sounds like what Vmgen (
is doing; however, Vmgen also does lots of other helpful things. OTOH,
it currently has no support for dealing with bit-fields for opcodes
and arguments.

- anton
M. Anton Ertl

Post a followup to this message

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