Re: Jit Implementation

"bartc" <bartc@freeuk.com> wrote in message news:10-03-089@comp.compilers...
> "BGB / cr88192" <cr88192@hotmail.com> wrote in message
>> "bartc" <bartc@freeuk.com> wrote
>
> [Generating asm output]
>
>>>> I added syntax as using an API to emit opcodes was lame;
>>>
>>> You mean using: genmc(hlt_opc) is lame but genmc("hlt") isn't?
>>
>> well, it is beyond this:
>> it is unlikely the API for a binary assembler could be made this simple,
>> since one also has to deal with many other argument configurations, ...
>> and
>> C lacks function overloading (meaning many different names and suffixes).
>
> I don't use C, I use a soft language with variant types, optional,
> defaulted
> and (if needed) keyword parameters. Overloading is not necessary in this
> case. I use just one function to generate code (and another one or two to
> construct operands).
>
> Obviously C can be used but it just makes life a little more difficult.


C is my main-use language.


I have used other languages, but things tend not to hold together so well
for so long, so I stick with C for most of the "heavy lifting", and use
other languages mostly for more misc and lower priority tasks.


if I had to migrate to another non-C language (besides C++), C# and Java
would be high on the list (C# because it seems like a more usable language,
and Java because at least I can manage it, and it is one of the major
accepted programming languages, although admittedly to me the language is
constraining and rather unpleasant to use...).


I also like JavaScript and ActionScript, but would not likely consider them
as main-use languages for various reasons.


...




>> additionally, one needs a function call for every instruction.
>>
>> passing a string though, one can batch a whole bunch of instructions
>> together if needed, and as well use printf-style formatting to include
>> literal values, ...
>
> There are some benefits (and in a soft language text processing is far
> easier), but I just happened to think non-text Asm would work better in my
> case.


yes, ok.


well, as noted in other groups, I have added a direct binary interface,
which gets about a 2x speedup over the "fast" textual mode (no preprocessor,
single-pass assembly), which is ~ 2.5x faster than the normal textual mode
(with preprocessor and multi-pass).


however, to me feeding in arrays of structs seems like a very awkward way of
producing ASM, so without good reason I am not sure I would use it in my
case.




>> it was my early success with JIT which prompted me to look into
>> writing a full on C compiler. FWIW, I had severely underestimated
>> the effort and complexity of this jump.
>
> It's not surprising. C seems a deceptively straightforward language to
> implement, until you encounter it's quirks, huge baggage and standard
> library. I wouldn't relish working on a C compiler (and competing with
> dozens of others).


I didn't need to write the standard library:
for native operation (within the host address space), I just used the
OS-supplied libraries (such as "MSVCRT", ...).


within my x86 interpreter, I found some usable free libs (such as pdpclib,
which is a public domain C library), and used these as a starting point (the
main awkwardness was more in adding a lot of POSIX functionality, since much
of this depends on the "kernel", which in the case of my interpreter runs in
the host address space, and is conjoined with the interpreter).




what became a major pain in writing a C compiler was more in terms of
dealing with more basic matters:
the C typesystem (lots of subtle edge cases and thorny issues exist);
code generation issues;
calling-convention issues (especially with AMD64/SysV, which is still a
particularly malevolent piece of technology IMO...);
...




but, my goal is not to compete against existing static compilers, more to
supplement them, and make dynamic features more available in otherwise
statically compiled apps.


additionally, I hope to be able to tear down many of the walls of FFI
issues, ...




dynamic-typed languages seem generally trivial to implement in comparrision.




>>> Stack machines are really, really simple to program for. And would solve
>
>> I still have much better success working with RPN than with the (IME)
>> terrible confusion of trying to figure out how to work with SSA form.
>>
>> (possibly, maybe, I am too stupid to understand SSA, I don't really
>> know...).
>
> I'll probably never grasp many of the formal compiler techniques discussed
> here. But I'm fairly confident I can produce something that works and that
> compares favourably in performance (of generated code) to others.
>
> (In fact I used to be amused when my code, which did no optimisations
> whatsoever, sometimes outperformed compilers such as gcc on some benchmark
> or other. Although that's rarer these days... And I'm more interested in
> languages so a compiler is just a means to an end; fast code is just a
> bonus)


yeah.




most of compiler optimization IME is not so much about elaborate formal
techniques, but rather avoiding doing something stupid (such as avoiding
endlessly storing and reloading the same variables, ...).


so, one can outperform GCC with default settings without too much work.
seemingly, outperforming MSVC is easier, since (although I don't know about
MSVC in the past), the recent versions are being not particularly impressive
with the efficiency of the code they produce...




I found eventually that language design wasn't really my thing, mostly since
it didn't really seem to accomplish much and there was little hope in
gaining widespread acceptance. it seemed much better to leverage languages
with which people were already familiar and were already in common use, and
try to make use of these as a starting point.


so, instead, I ended up more dealing with the issues I wanted to deal with:
the sore lack of good dynamic facilities in traditional C and C++ based
apps;
the big pain of FFI issues with typical VM's (why should I have to write
piles of boilerplate to call into my statically compiled code?...);
...




for example, some uses of my framework actually benefit statically-compiled
code much more than they serve to implement much of anything "new" ("new" is
sometimes an enemy, as "new" means unfamiliarity, compatibility issues,
possibly unforseen issues and edge cases, ...).


so, my effort more revolved around taking common standard or de-facto parts,
implementing many of them myself, and then trying to break down some of
their prior limitations.


however, even following many of the standards, avoiding variation or the
creation of (or need to create) unorthodox parts is a problem (and the end
result seems to start to resemble some bizarre chimera technology, with many
chimeric, and hence unorthodox, parts...).


at the level of metadata, my framework is in many ways unorthodox, ...

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