[Top][All Lists]

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

Re: [Tinycc-devel] bytecode

From: Nick Kelsey
Subject: Re: [Tinycc-devel] bytecode
Date: Tue, 11 Oct 2005 09:56:12 -0700
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

Hi Chris,

I looked into this for one of our applications - TCC is reasonably good for generating VM code but a simple VM interpreter won't be fast to execute.

Instead I have been working on a TCC target that generates architecture, position and size independent code (with a fixed register/memory model) that can be converted into native instructions by the target processor. For a 32-bit processor the byte-codes generally translate to a single instruction or two for a literal.

The targets we use are all embedded processors, often with less than 64k of RAM - with this approach the bytecode isn't stored, it gets translated on the fly as it is downloaded. My main test target is a Ubicom ip3k and the translator uses less than 4k of code space... less space than a VM would :-)

The translator is that it is written in c-code but with an additional custom pre-processor that translates target specific assembler into binary constants so the author doesn't need to know or enter any binary numbers.

What is your application?


Chris wrote:

*This message was transferred with a trial version of CommuniGate(tm) Pro* I have seen some brief mention of bytecode targets here and there on this list over the last few years. Has anything come of any of those?

I really would like to see a C to bytecode compiler and an accompanying lightweight VM to run the bytecode. I imagine the VM would be extremely simple (relatively speaking at least), lightweight, and fast if the only functionality was similar to standard ANSI C. This would allow easy embedding of the VM in applications. Especially if it allowed direct calling to/from native (binary) system libraries.

This would be very useful as a lightweight cross-platform system that didn't require recompiling for each target and kept the simplicity of C. Dynamically loading code off the network and running directly from memory would be much easier as well.

Targeting TCC bytecode to a new processor would be as easy as porting the VM to that processor using pre-existing compiler tools for that hardware; no machine code messiness.

The Quake3 game engine actually has a VM and compiler that is pretty close to exactly what I speak of but unfortunately it's GPL'd so not all that useful for commercial embedding.

reply via email to

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