Re: .Net applications, not optimized for CPU at all?

Marco van de Voort <marcov@xxxxxxxx> wrote:

IL is based on a stack machine and compilation to native code is not
optimized that much (compared to a native compiler), so yes you may be
right that the code should be larger.

I thought JVM IL was based on stackmachine, but one of the differences of
.NET was that it was not per se, because it doesn't have to be
interpretable?

Both Java VM and MSIL are logically stack machines. The biggest
different between the two, and the one which makes a difference for
creating a somewhat performant interpreter, is that the JVM instructions
are typed (e.g. iadd vs fadd for integer addition versus floating-point
addition), while the MSIL instructions aren't. With MSIL, the
instruction types must be inferred from the state of the stack, which is
itself implied by prior stack load / typecast etc. instructions.

Since the Java VM (the CLI does this too) needs to verify its
instructions before running (to ensure that there is exactly one
possible stack representation per instruction in a method, amongst other
things) anyway, it's a pretty arbitrary distinction. It could have
chosen to tag the operation type at this stage.

Another big difference between the Java VM and MSIL is exception
handling / try-finally blocks, with the Java VM using a kind of computed
jump, whereas MSIL uses a list of ranges.

I've written compilers for both the Java VM and MSIL, so I'm pretty
familiar with the differences.

As said, IL usually is nothing more than a linearised parse tree.

This implies that all the usual compiler tricks can be applied. The
biggest limitation with both JVM and CLI as target architectures with
respect to performance in the context of a code generation for a single
method is the limit to the clever things you can do with register
allocation, pointers and stack allocation. You end up relying on the JIT
compiler to think hard, but part of the definition of a JIT compiler is
something which doesn't have time to think hard.

NGEN may do more in this area in the future, but for now the primary
advantages are the reduction of startup cost and the increase of shared
code pages.

-- Barry
.

Relevant Pages

  • Re: CLR, Value/Ref types, and the thread stack/heap
    ... It comes from the MSIL instructions. ... I4 on the stack. ... Don't confuse the CLR with the C# compiler. ...
    (microsoft.public.dotnet.framework.clr)
  • Re: Bison/Flex To ByteCode
    ... I would assume there are 2 stacks my compiler ... How would this instruction get handled and represented on a stack ... integers get pushed to the stack with a special opcode that simply ... -> jump instructions, call instructions, comparisons, conditonal jumps, ...
    (comp.lang.cpp)
  • Re: Forth Research Topics
    ... efficiently than the ZPU. ... since instructions have to be multi-cycle. ... the C compiler to control a CPU stack instead of registers. ...
    (comp.lang.forth)
  • Re: Seymour remembered
    ... > manage to get a loop into this buffer, ... I wasn't certain from the article which Fortran compiler they were ... Instructions were 15, 30, or 60 bits long so theoretically the stack ...
    (comp.lang.fortran)
  • Re: Forth Research Topics
    ... that is what seems to make the ZPU a bit clunky ... since instructions have to be multi-cycle. ... The internal data stack would be used as register space. ... the C compiler to control a CPU stack instead of registers. ...
    (comp.lang.forth)