Re: [Tinycc-devel] Stack based target machine

[Nick Kelsey]

Ok, I have the basic ALU operations generating bytecodes, including 
detection and generating implied-literal instructions (for example, AND 
0xFF compiles to an 8-bit mask bytecode, XOR 0xFFFFFFFF compiles to a 
NOT bytecode etc).

Now I need to formally figure out the register handling.

I currently have two registers - top of stack and top of stack -1.
For operations that are symmetrical with regards to the operands (AND, 
ADD etc) it can use either register for either operand (required for 
using the result of an operation as an operand for the next).
For operations that are not symmetrical  (SUB, DIV etc) it specifies the 
specific registers to the register allocator.

There are two problems:
1) The backend doesn't know when things need to be deleted from the 
stack (ie the top-of-stack "register" is to be overwritten but a new value).
2) More optimal handling of a request to load top of stack - 1. 
(avoiding a push followed by a swap operation).

I could add one real register and only use the stack for one operand but 
that would create extra store operations.

I would appreciate any thoughts or advice on the subject,

Thanks,

Nick

PS - is TCC managed by a public revision control system? How are 
submissions normally handled?

Nick Kelsey wrote:

> *This message was transferred with a trial version of CommuniGate(tm) 
> Pro*
> Hi,
>
> I have spent most of the weekend looking through the TCC backend 
> code... very impressed... this has the potential to be the ideal 
> solution to the problem I have in mind.
>
> TCC already covers the first requirement - a compiler that is 
> practical to ship to end-users so they can write their own "scripts" 
> that interact with our application.
> On the server side TCC can compile to a native x86 machine - perfect.
>
> We also have a number of different embedded platforms... the goal is 
> to run a single program on any of these platforms.
> Unfortunately they have insufficient resources to run TCC natively, so 
> I am looking at compiling to a virtual machine.
> Actually a virtual machine solves another problem - memory. We have 
> two platforms that have limited core-addressable memory (one has less 
> than 4k) and a VM would allow us to make use of IO addressable 
> external memory by making it c-addressable.
>
> I am leaning towards the idea of a stack based VM to keep things 
> simple on the VM side (ie no general purpose registers thus no 
> register decoding and addressing required by the host cpu). In reality 
> the hardest aspect will be the compiler port so that will dictate the 
> VM architecture more than anything else.
>
> I made a few hacks in the backend of TCC but I think I am still 
> missing some concepts. In particular the register allocator (gv).
>
> Time to pause and run the concept past you... I am happy to put time 
> into coding but would appreciate your thoughts and advice.
>
> BTW - I have written a few VMs in the past, including a cycle-accurate 
> simulator of a pipelined processor that was used commercially for VLSI 
> testing.
>
> Great product, and I hope to be part of the TCC community.
>
> Nick
>
>
>
> _______________________________________________
> Tinycc-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/tinycc-devel