Re: What is byte-code ?

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
trick.


--
Chris "electric hedgehog" Dollin

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