Re: [Tinycc-devel] alloca for tcc (x86) - second cut

[Rob Landley]

On Wednesday 09 May 2007 12:56 am, David A. Wheeler wrote:
> I need to add a padding configuration option, but otherwise I think this
> version's ready to go.  Thoughts? 

Looking at this more closely (I.E thinking of applying it and reading it again 
to decide):

Starting with the assembly code:

1) I still think the add should be 3, not 7.

2) Why are you special casing a 0-byte allocation?  I note that glibc returns 
non-null for malloc(0) (it _does_ allocate a zero byte object on the heap), 
and other things return NULL, and mostly this seems like a "don't do that" 
thing.  Since we never call free() on an alloca()'d pointer, and they should 
never write to or read from it (after all, there's no memory there), then 
returning a pointer to the current stack location without adjusting it (which 
seems like what the code would do without the special casing) sounds 
perfectly reasonable here...

What _really_ confuses me is that you make sure to pad each allocation with at 
least an extra 4 bytes, _and_ you special case 0.  I could almost see one or 
the other (although I disagree with both), but combining the two goes beyond 
defensive programming.  (Stupid code should break.  If you want to improve 
the situation, make it break early.)

Also, the man page says:

RETURN VALUE
       The  alloca()  function returns a pointer to the beginning of the allo‐
       cated  space.   If  the  allocation  causes  stack  overflow,   program
       behaviour is undefined.

It never says anything about returning NULL.  One reason to use alloca() 
actually is that it _can't_ return NULL, which happens on a NOMMU system that 
gets its heap pathologically fragmented...

3) Why is the __bound__ thing a separate function?  They seem identical except 
for the call __bound_new_region thing, which can be #ifdeffed out and tested 
for otherwise since it's a library function, not emitted inline.

(On a side note, the call to __bound_new_region is fed the amount we were 
requested to allocate, not the amount we actually did.  I suppose that's 
intentional, I just continue to be uncomfortable about it...)

4) Daniel's arm version is way the heck shorter than your x86 version, and 
seems more like what I'd expect for tcc...

Next, why is there an #ifdef _TINYC_ in a header file that's going to be 
installed in /usr/lib/tcc/include?  How is anything other than tcc ever going 
to find that file to #include it, and should we humor them if they do?

Did we ever figure out what the #include order should be 
for /usr/lib/tcc/include vs /usr/include?  (Do compiler .h files come before 
system .h files?  Is there a standard for this?)

The Makefile grows increasingly evil.  I need to roto-rooter it, but I'll wait 
until after the next release.  (I want to make the sucker build on x86-64.  
I'm not talking about producing x86-64 target code, I mean host x86-64.  No 
real reason it _shouldn't_ work, and if it doesn't I can probably fix it...)

Rob