tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] TCC code generation for a stack based VM


From: Zoltán Lörincz
Subject: Re: [Tinycc-devel] TCC code generation for a stack based VM
Date: Wed, 3 Nov 2004 12:50:11 +0200

Hello Fabrice,

thank you  for your answer.

First of all i have a question related to the mailing list administration. 
I made a subscribtion a few days ago (saturday last week) at
http://lists.nongnu.org/mailman/listinfo/tinycc-devel but didn't got
any confirmation up to now.
Does this usually takes so long? or  something went wrong with my subscribtion?

Regarding to the VM i think i will take your suggestion.

I don't have to handle the floating/double types so the instruction
set will be reduced with a few instruction.

But i have to implement a custom byte format wich has to be simpler
than the elf format.

Best regards,
Zoltan.

Hi,


I really think that a register based VM target would be simpler to add
to TCC, and surely faster than a stack based VM.

I suggest the following parameters:


- 3 general integer registers, 3 general double registers, load and store based.

- For each instruction you have at most 3x3 = 9 versions, which you
can generate easily with the C preprocessor.

- Each instruction is 16 bit wide, some are longer to integrate 16 or
32 bit constants. 16 bit wide ops can be interesting to avoid one
table indirection in the interpreter loop.

- Extend the ELF format for this virtual machine so that you can
generate object and executables easily.

Fabrice.


Mirar wrote:

        Unfortunately it is not in my hands to change the requirements. 



It was just an idea :)



On the other hand, if we would use TCC for JIT compiling then for
every new processor we would need to write a code generator wich we
would like to avoid.



    Nah, you would require TCC to work for every new processor. The code
    would stay the same (since it would be in C)? I didn't know you
    switched processors that often.

TCC is rather small though (a few 100k), quite comparable to an
interpreter.


Why not make a registered based byte code interpreter, it might be
easier then rewriting tcc? (I haven't seen any answer whether tcc can
do that yet, but...)


/Mirar




reply via email to

[Prev in Thread] Current Thread [Next in Thread]