Re: Jit Implementation

"BGB / cr88192" <cr88192@hotmail.com> wrote in message
> "bartc" <bartc@freeuk.com> wrote
>> "BGB / cr88192" <cr88192@hotmail.com> wrote in message
>>> "bartc" <bartc@freeuk.com> wrote in message
>>>> "BGB / cr88192" <cr88192@hotmail.com> wrote in message
>>>>> "bartc" <bartc@freeuk.com> wrote in message


[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.


> 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.


> 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).


>> 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)


--
Bartc

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