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

Re: tcc



Adrian von Bidder wrote:
Yodel!

On Friday 13 March 2009 10:28:08 Giacomo A. Catenazzi wrote:
Adam Borowski wrote:
On Wed, Mar 11, 2009 at 11:21:08PM +0100, Stefano Zacchiroli wrote:

A C source file by itself cannot be run
without having been compiled
I guess you haven't seen the Real Men's only true scripting language.

apt-get install tcc
...
It is not real C  ;-)

few assumptions on compiled language doesn't allow you to
interpret a compiled language (and usually also the contrary).
Few programs use such assumptions, but anyway...

While I agree that modern (dynamically typed etc.) scripting languages cannot easily be compiled (note that this is only a practical difference, not a theoretical one),

You forgot that most of interpreted languages have some kind of
eval/run/exec statements/functions, which allow a program to run
code dynamically (maybe from user input). So in a "compiled" version,
an library should be able to interpret the code, thus it would not be
a complete compiled code.
Maybe programs without such constructs could be really full compiled.


I fail to see the difficulty with executing C from an interpreter. In fact C makes quite few assumptions about the runtime environment and doesn't expect much/any behind the scenes magic to happen. I bet a C interpreter could even be written so that it only uses memory when the C source also would allocate memory (entering a stack frame and malloc) [1], so while the interpreted program would probably hit OOM earlier then the compiled one, it would still do so only at the same places that a compiled program might hit OOM.

This is not the real problem.

[1] One obvious way is to parse a whole function on entering it. Given the low complexity of plain C code, it can then be executed without allocating further memory by just jumping around in the parse tree.

But this is the problem. C code could be very complex: a lot of nesting
block and hidden variables, a lot of switch cases, very long block and functions,
... which could require IMHO more memory (thus OOM).
There was some discussion on C standardization, and I don't remember the other
cases. Anyway no big stoppers, but they decided to ignore the few changes for an
interpreter C until real demand (and some real implementation, to identify
the real needs of interpreted C).

OTOH, these are theoretical concerns. Our C is also not a "real C".
I doubt that lazy linking is permitted by standard C (IIRC a program must
not enter in main() if some symbols are missing).
ciao
	cate


Reply to: