Re: What is byte-code ?

Nathan Moore <>
24 Mar 2005 21:16:39 -0500

          From comp.compilers

Related articles
[7 earlier articles]
Re: What is byte-code ? (2005-03-08)
Re: What is byte-code ? (2005-03-08)
Re: What is byte-code ? (Carl Cerecke) (2005-03-08)
Re: What is byte-code ? (2005-03-15)
Re: What is byte-code ? (Chris Dollin) (2005-03-15)
Re: What is byte-code ? (Xous - Jose R. Negreira) (2005-03-18)
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)
[5 later articles]
| List of all articles for this month |

From: Nathan Moore <>
Newsgroups: comp.compilers
Date: 24 Mar 2005 21:16:39 -0500
Organization: Cox Communications
References: 05-03-015 05-03-026 05-03-053
Keywords: interpreter
Posted-Date: 24 Mar 2005 21:16:39 EST

Chris Dollin wrote:
> Depending on why you mean by `byte` and `bytecode` that may not be true ...
> 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 had posted another more elaborate
definition that was culled -- don't know why). Your VM's instruction
set is very much like that of many hardware CPU's (as I'm sure you
know), but when done in software, you incure the expense of separating
out the 5 bit operation code from the rest of the 16 bits, before
decoding (ie jumping to the code that does the operation or decodes the
rest of the opcode if it is one of those cases). This separation
of components, which you most likely do with a MASK | INSN is not
expensive, but does have to be done for every instruction, which may
not be the case for a VM whose instructions are addressable by the
host machine. 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.
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. (same is true of the other
3 bits when used as opcode on the hosts where the above is not true).
You also have to worry about endianness and portability.

This really doesn't have much to do with the definition of bytecode, but
why bytecode works well in VM's and particularly portable VMs.
I just don't think that just because something is a VM the code that it
eats can be defined as bytecode. This definition would make all machine
languages and infact all bit-streams be included in the set of bytecode.

Nathan Moore

Post a followup to this message

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