Re: CLR stack

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Joel wrote:

Thanks a lot, that was really helpful.

One question,.. as you said, value types are stored in the x86
processor stack

That is how people think of them, i.e. avoiding GC overhead, but if the
value type is small enough it may be in a register instead. (Of course,
if the value types are fields of another object, then they are stored
inline in that object's memory; if the other object is a value of a
reference type, then the memory of the field of the value type is stored
inline in the value of the reference type's memory, allocated from the
GC. "Value types on the stack" refers only to parameters and locals, not
fields.)

and VES locals are actually stored there.

When IL is compiled to machine code, VES locals may allocated to
registers if they are available and the value is small enough, and only
spill to stack when necessary, just like any optimizing native code
compiler. IL is like simplified source code for an optimizing native
code compiler.

How are these locals accessed from the stack?

With CPU instructions that the CLR generates when it compiles the IL
code.

push and pop instructions store or retrieve only the top of the
stack as pointed by the CPU stack pointer, how are locals at
intermediate locations in the stack accessed then?

The x86 CPU models the top of stack as being the thing pointed to by the
ESP register, and convention uses the EBP register as the frame
register. The x86 processor's instructions such as PUSH and POP modify
ESP as they push and pop, but that does not stop other instructions like
MOV and ADD from directly accessing memory operands via expressions that
use ESP or EBP. For example:

mov eax,[esp+4]

or

add eax,[ebp+12]

.... are instructions that are using locals and arguments. The x86 stack
grows downwards, so ESP+n is deeper into the stack, while values higher
than EBP would typically be arguments that have been passed on the
stack.

Don't confuse the VES model with the CPU model. The VES is an abstract
machine, or virtual machine, which provides a context for the exact
definition and specification of what IL means. IL is only a language for
a native code compiler. The fact that IL can only push and pop and can't
directly address its stack does not limit the CPU, which can do whatever
the IL compiler (the JIT compiler in the CLR) generates code for it to
do.

-- Barry

--
http://barrkel.blogspot.com/
.

Relevant Pages

  • Re: made it to page 4 of gforth tutorial
    ... the stack space anyway. ... And there are clearly going to be some platform ... came with an embedded C compiler once. ... like I've written before, if one *really* needs recursion (as I have, ...
    (comp.lang.forth)
  • Re: Atomic operations in 32 and 64 bit platforms
    ... a compiler to evaluate functions with fixed parameters in any order ... evaluation can involve loading values from memory, ... appear on the x86 stack, that is not defined by the C ...
    (comp.lang.asm.x86)
  • Re: Do buffers always start with the lowest memory address being the first element?
    ... > The C standard does not assume a downward-growing stack, ... > an upward-growing stack. ... C allows but does not require that the array produced ... > machine depends on both the C compiler and the machine. ...
    (comp.lang.c)
  • Re: switch statement, was compiler, status...
    ... Primary Register, Secondary Register, ... Stack, and abit of storage does it. ... This version of Small-C is copyrighted as a revision to Ron Cain's ... Croatia) is "Calculator Compiler" by Senko Rasik. ...
    (alt.lang.asm)
  • Re: x86-64 and calling conventions
    ... good old 32-bit x86 convention. ... arguments would be passed on the stack (in good old linear ... That's kind of what I did in the Flaming Thunder compiler (which ... The calling convention is left-to-right (since I was making my own ...
    (comp.compilers)