That's really an interpreter (as opposed to using a bytecode vm or some such)? How does it deal with memory allocation, alignment etc? And (I don't have a proper dev setup on hand) -- the obvious question -- can it run itself, in itself in itself? (And itself in tcc in itself?) ;-)
It's a real interpreter. It runs directly from the source code - it doesn't even store a parse tree or bytecode. Memory allocation and alignment is done in the standard C ways. It's designed as a scripting variant of C so it doesn't implement 100% of the C standard (eg. bitfields), so no it's not self-hosting.
Fascinating, I'll have to look at it more closely when I've got a usable command line available. I would not have thought it was feasible for a useful subset of C -- but then I tend to forget that it is a rather simple language at heart (eg: after running the pre-prosessor).
Comments
That's really an interpreter (as opposed to using a bytecode vm or some such)? How does it deal with memory allocation, alignment etc? And (I don't have a proper dev setup on hand) -- the obvious question -- can it run itself, in itself in itself? (And itself in tcc in itself?) ;-)
It's a real interpreter. It runs directly from the source code - it doesn't even store a parse tree or bytecode. Memory allocation and alignment is done in the standard C ways. It's designed as a scripting variant of C so it doesn't implement 100% of the C standard (eg. bitfields), so no it's not self-hosting.
Fascinating, I'll have to look at it more closely when I've got a usable command line available. I would not have thought it was feasible for a useful subset of C -- but then I tend to forget that it is a rather simple language at heart (eg: after running the pre-prosessor).