Re: tcc

["Giacomo A. Catenazzi" <cate@cateee.net>]

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