Re: Bytecode Compiler

Lars Duening <lars@bearnip.com> wrote:
> Chris Cranford <chris.cranford@tkdsoftware.com> wrote:


>> Something has to tell the virtual machine to advance the
>> stack pointer by the number of local variable storage slots that are
>> needed. This again could just be a simple opcode like:
>>
>> 0000 advsp_2 // Advances the stack pointer by 2 slots. This
>> // basically gives me two local variable slots.


> The compiler could also determined the number of local variables needed
> and annotate the bytecode program with this information out-of-line.
> This can be done for a whole function at once: if at the deepest block
> nesting the function needs n slots, then that is what the VM allocates -
> there is no need to create/destroy variable slots just because one block
> inside the function has been entered or left.


> The ability to store meta-information outside the actual bytecode is a
> great help in implementing a VM.




At least Java takes this path: the code block of a method contains
information on the number of local variables (max_locals) and the
maximum stack size that the execution will consume the operand stack
(max_stack). These are computed at the bytecode generation time.




>> Another option would be to assume a maximum number of slots for local
>> vars like the java virtual machine does of 255.


> Always allocating a fixed number of variable slots would be very
> inefficient: most of the slots would go unused, and sometimes the number
> wouldn't be enough.


> And while I'm not an expert on the Java VM, I don't think that the Java
> VM always allocates 255 variables slots - rather I think that this
> number is an implementation restriction on the maximum number of local
> variables.




Using the information max_locals and max_stack it is trivial to
allocate almost correct amount of slots for execution.


A Java VM cannot restrict the maximum amount of slots to 255 because
according to the specification, there can be 65535 local variables.
Local variables are accessed with typed instructions Tload and Tstore,
where T is the type of the accessed variable, i for int, f for float
etc.


For accessing local variables that are located above the first 255
local slots, there is a special instruction 'wide', which instructs
the load and store instructions to use two-byte operands instead of
one byte operand.




br,
Pietu Pohjalainen

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