Re: [Tinycc-devel] Porting TCC to RTLinux

[Calin A. Culianu]

On Wed, 22 Nov 2006, Basile STARYNKEVITCH wrote:

> Le Wed, Nov 22, 2006 at 12:25:22PM -0500, Calin A. Culianu écrivait/wrote:
> > Hi,
> >
> > I am trying to get tinycc-0.9.23 to exist as an embedded facility in the
> > linux kernel.
> >
> > Sound crazy?  Want to know why?
> >
> > Well, the reason for this is that I am writing a realtime linux control
> > application that runs in kernel context (under rtlinux).  My control
> > application dynamically generates a turing machine (basically a finite
> > state machine with memory and variables) which then gets run as a realtime
> > task.
>
>
> > Anyway, so I need to be able to generate C code and compile it in the
> > kernel.
>
>
> If you want to generate code dynamically, there are other alternatives
> than generating C and compiling it (even with a fast, but not very
> efficient, compiler like tcc).
>
> You could generate code in some other low level language. In
> particular, C-- has been designed for that (it is a language designed
> to be generated, not human written [1]).  Also LLVM [2] might be
> interesting for you.
>
> You could use some machine code gneneration toolkit, like GNU
> lightning [3,4] or libjit [5]. Or some VM with JIT inside like Parrot [6]
>
> Given what I understand of your goals, I would avoid generating source
> code, and use lightning or perhaps libjit. BTW, lightning is certainly
> usable with a very shallow stack. (But it might not have been ported
> to AMD64).
>
> References
> 1. http://cminusminus.org/
> 2. http://llvm.org/
> 3. https://savannah.gnu.org/projects/lightning/
> 4. http://www.gnu.org/software/lightning/lightning.html
> 5. http://www.southern-storm.com.au/libjit.html
> 6. http://www.parrotcode.org/

Wow Basile.  Your advice is really helpful and thoughtful.  You even 
provided references!!  Thanks!!


My thoughts, and please do correct me if you think my thinking is faulty:

C-- or the other langauges/systems designed for code generation would be 
ideal but alas the code actually needs to be as human-friendly as possible 
(certain expression and functions in this generated turing machine are 
specified by human programmers and C-- seems a bit *too* low-level).

Actually even C is a bit too low-level, but it will do.  Ideally I would 
want a higher level language like python or even GNU Octave (I know, it's 
yucky -- but is ok at annotating mathematical expressions with is what we 
really need).

Virtual machines are actually a great way to go too -- although none of 
them seem terribly embeddable right off the bat.  One of the nice things 
about TCC is its embedability because it is a small, easily modified 
program.

Anyway VMs might suffer from a different class of problem -- namely due to 
the hard realtime requirements of this appliation they may not be ideal. 
Our task period is 166 usec so performance counts -- we want to pack as 
much in one task cycle as possible.  A JIT and/or VM solution might have 
performance limits that are too easy to hit.  You can fit a lot of native 
code in 166usecs on modern computers, but something interpreted might have 
instruction limits a couple orders of magnitude smaller.

I think for now I will stick to TCC.  Again the requirement of a 
human-readable, human creatable language that is really FAST at runtim is 
something I can't seem to easily overcome with anything but C compiled to 
native code.

I do however appreciate your advice and will explore the other 
alternatives and references you provided for my own curiosity -- thanks 
for being so helpful!!

-Calin