[Mono-list] Jit compiler

[adc]

> > mono_image_open function in image.c. This seems to happen with every
> > executable I throw at it, even extremely simple programs.
> 
> You probably have only corlib.dll installed and the corlib from cvs
> erroneously uses regular expressions that are from a different assembly.
> The included patch should fix it for you (if you run it on Linux,
> haven't tested win32 in a while).
>


Sorry guys, I have should have explained better what I was doing, I thought it was something silly that I was doing wrong.
I am running this on Linux, the problem was originally, as sugested that corlib.dll was not installed. I wasn't aware that I needed it to run monodis.
My problem now seems to be installing that, I try to make mcs and I get this error

../nant/NAnt.exe linux
fixme:win32:PE_CreateModule Unknown directory 14 ignored
FIXME:pthread_rwlock_rdlock
FIXME:pthread_rwlock_unlock
FIXME:pthread_rwlock_rdlock
FIXME:pthread_rwlock_unlock
FIXME:pthread_rwlock_rdlock
FIXME:pthread_rwlock_unlock
FIXME:pthread_rwlock_rdlock
FIXME:pthread_rwlock_unlock
err:module:fixup_imports Module (file) mscoree.dll needed by F:\Mono\mcs\nant\NAnt.exe not found

but don't waste any time I will try to get this working myself. It's not urgent anyway.


> > I ask as for my disertation I am going to investigate the worthiness of
> > writing an assembler from CIL executables to native code executables,
> > what optimisations etc can be gained by the fact that we no longer have
> > compilation speed as a major restriction (obviously we don't want a
> > compiler that takes forever but it would then be of less concern).
> 
> The idea has been floating around for some time and, yes, we think it's
> worthwhile, we just need someone to tackle it:-)
> 

Well what I intend to do is prepare a small and simple CIL to native code compiler (I currently have a disassembler for just the base instructions). Once this is done I can compare the output for code generated for functions between the static compiler and the JIT engine with the view to seeing where an advantage can be made over the JIT produced code (for example we could make multiple passes). I'll also try to see if there is a more elegant solution for problems such as that stated in the JIT thoughts file:

Consider the following code:

OPCODE:         STACK           LOCALS
LDLOC.0         (5)             [5,0]
LDC.1           (5,1)           [5,0]
STLOC.0         (5)             [1,0]
STLOC.1         ()              [1,5]

The current forest generation generates:

STLOC.0(LDC.1)
STLOC.1(LDLOC.0)

Which is wrong, since it stores the wrong value (1 instead of 5). Instead we
must generate something like:

STLOC.TMP(LDLOC.0)
STLOC.0(LDC.1)
STLOC.1(LDLOC.TMP)

Where STLOC.TMP saves the value into a new temporary variable.

Of course the alternative might be that very little improvement can be made over the JIT engine, and thus the project will not be worth doing. Either way I'll have something to write about and hopefully the results will be useful to the mono project. If it turns out that there is a large improvement then I can (if wanted) integrate my work into mono.

Anyway thanks to everyone who helped.