[Mono-devel-list] proposal for a different JIT
Varga Zoltan
vargaz at freemail.hu
Tue Oct 14 14:03:09 EDT 2003
Hi,
I thought about using KSI for an AOT compiler some time
ago, but
there are some problems: the main problem is that KSI is not an
official part of gcc, and will never be, because that would
enable
the creation of possibly non-free fronts ends to gcc, which
is agains
FSF policy. So if we wanted to use KSI, we would have to
distribute
our own extended version of gcc, which is a lot of work. For an
example of a project which choose this route, see:
http://www.cs.mu.oz.au/research/mercury/download/gcc-backend.html
bye
Zoltan
Emanuele Ruffaldi <pit at sssup.it> írta:
>
> Hello there,
>
> I propose an alternative way for the implementation of the
JIT in the
> Mono system. The idea is to use the back end of the GCC
compiler, but
> instead of creating a full front-end I propose to use the
KSI front-end,
> that is a direct mapping of the GCC back-end tree (for
details see
> http://ftp.pld-linux.org/people/malekith/ksi/)
>
> Whenever a part of an assembly has to be jitted the JIT
should generate
> a KSI source code that is quite platform indepentent and
then the GCC
> back-end can compile it with different levels of
optimizations. During
> the generation of the KSI code all the references to
internal functions
> and variables can be fixed as constants improving the
performance.
>
> I've tested this solution in a Cygwin (sorry) environment
with GCC
> 3.3.1, where a custom program generates the KSI code on
the fly, calls
> the GCC tools (ks1, as and ld) and then loads the shared
library created
> by the linker.
> There is no need to have a full GCC running but only
these files
> (almost 5.5MB):
>
> ksi1.exe
> ld.exe
> as.exe
> cygwin1.dll
>
> I think that working on Linux, and with some optimizations
the memory
> requirements can be reduced.
>
> This solution should be used only on the platforms where
doesn't exist a
> custom written JIT (like now for the x86), because a
custom JIT is much
> faster. I realize that there are many problems in the
adoption of this
> solution but it should be faster than the simple
intepretation, and can
> be adapted to the AOT too.
>
> Thanks,
> Emanuele Ruffaldi
>
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>
More information about the Mono-devel-list
mailing list