Re: What is byte-code ?

Chris Dollin <>
11 Apr 2005 00:18:16 -0400

          From comp.compilers

Related articles
[13 earlier articles]
Re: What is byte-code ? (Nathan Moore) (2005-03-24)
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: Chris Dollin <>
Newsgroups: comp.compilers
Date: 11 Apr 2005 00:18:16 -0400
Organization: HPLB
References: 05-03-015 05-03-026 05-03-053 05-03-088 05-03-125 05-04-005
Keywords: interpreter
Posted-Date: 11 Apr 2005 00:18:16 EDT

Nathan Moore wrote:

> Chris Dollin wrote:
>> 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 ...)
> So what, you have several cases w/ the same code for all of the
> instructions that only use the first 5 bits to determine the operation
> and the other 3 of the octet as extra operands when the first 5 bits
> match?

Yes. It seemed the most straightforward solution. (As it happens, the
case where the 3-bit field is 7 is also often a special case: 0-6
specifies a register, 7 specifies a pull/push of the operand stack.)

> Rather than the array of f() * , if you use gcc,

I didn't want to commit to gcc (especially since one of my targets
was the ARM).

> and because you won't have to jump back to the initial jump to begin the
> next instruction. 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.

Indeed. My friend Steve Leach has done some VM investigation where the
same code fragments for the instructions) are stitched together in
different ways for comparison purposes: switch cases, functions, and
GCC label targets. If I remember rightly, label targets were fastest
on x86 machines, but functions were fastest on Power PC. Were I to
be doing another round of VM exercises, I'd play the same kind of

Chris "electric hedgehog" Dollin

Post a followup to this message

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