[Top][All Lists]

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

Re: [Tinycc-devel] Stack based target machine

From: Nick Kelsey
Subject: Re: [Tinycc-devel] Stack based target machine
Date: Wed, 22 Jun 2005 10:29:24 -0700
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

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,



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*

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.


Tinycc-devel mailing list

reply via email to

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