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
[email protected]
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
_______________________________________________
Tinycc-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
