Re: Managing the JIT

"Aleksey Demakov" <ademakov@gmail.com> wrote in message
> Usually a JIT compiles functions on demand.
>
> That is when it sees a call to a function that has not been compiled
> yet it generates a "trampoline" for this function. The trampoline is a
> small bit of generic code that does these things:
>
> 1) invokes the JIT compiler for the function in question;
> 2) upon compilation jumps to the newly generated binary code in RAM;
> 3) patches the call site so that all further calls go
> directly to the binary code.
>
> This way the function is compiled the first time it needs to be
> executed. And if a function is never executed it never compiled and
> JIT even never looks at its source/byte code.


<snip>


this has been one of the main reasons in the past I had refrained from
calling my compiler a JIT:
it does not exactly "JIT" things in the above sense.


rather, it typically behaved more like a traditional compiler, essentially
forcing through big chunks of source code, compiling them, and linking them
into the image.




a JIT-style strategy has been floating in my head as of late, in particular
for the development of a "generic bytecode" + trampolines and demand
compilation.




however, for the time being I have decided to "pause" my compiler/VM related
efforts in an attempt to pursue goals related to other parts of my project.




I am now thinking that, for me at least, trying to go the C++/Java/C# route
is just too much work for too little gain... (after all, I already have a C
compiler...).


implementing a C compiler "opens a can of worms", but trying for C++
"unleashes the devil", as it would seem...


so, I may change directions, and instead redirect my efforts into making a
"C-level JavaScript", namely, a JavaScript like language which has fairly
direct access to the C based world (although, likely only a subset of the
functionality).


in particular:
JavaScript style syntax;
dynamic types (actually, the compiler would likely use static-typing
internally, where dynamic case is considered as a "special" case of static
types);
...


however:
can access C functions (or, at least those operating within certain
constraints);
would have a partial (as in, very limited) pointer system;
...


so, it would relate to C similar to how C relates to assembler:
C has its own confined semantics and typesystem (vs ASM);
however, C can call freely into ASM, so long as the ASM obeys the C ABI;
and, ASM can be used to write all this stuff which can't really be written
in C.


this way, the language can be JS-like, but much of the implementation and
lower-levels would be C.


conviniently, this would also get around a lot of the "problem areas"
related to "going dynamic" in C-family languages (namely, the complexity
spikes, and one ends up with a non-orthogonal mess).


however, I have enough experience to know that, dynamic languages, by
themselves, are not particularly complicated (internally, getting C compiled
is far more scary IME...).


the major reason being that, for C, everything has to be "exact" (the
compiler can't be like "well, I have no idea what the types are here, just
do something generic..."), whereas with a dynamic language, one can get by
primarily generating code via guestimation and oportunism (or, at least,
this is how my last dynamic-language JIT worked...).




>
> http://www.gnu.org/software/dotgnu/libjit-doc/libjit.html
>


yep, interesting, will look...

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