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