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

[David A. Wheeler]

Rob Landley:
> Starting with the assembly code:
> 
> 1) I still think the add should be 3, not 7.

Understand.  I've added a constant at the top of the file to ease configuration.

> 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.)

The special-casing isn't for the return code, tho since I needed to 
special-case it I may as well return a sensible value.  It's because some 
programs call alloca(0) at the "top" of a main loop for compatibility with 
"alloca-using-malloc" implementations.  (They use alloca(0) as a "please do 
garbage collection" call).  If alloca(0) actually ALLOCATES some space each 
time it's called (which padding would normally do), and the calling function 
never returns (which is true for such loops), the stack space used will grow 
without bound. But I _have_ to add padding for the bounds-checking case, and I 
prefer the option of adding padding at other times too.  So I need the special 
case to make SURE that there's no allocation when alloca(0) happens.

> 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.

Because you can have separately compiled libraries, all using alloca(), where 
SOME use the bounded version and others don't.  I believe both need to exist so 
that the "right one" gets called.  The other "bounded" functions do the same 
thing.  I thought about having a single file and using macro magic to generate 
both, but I'm not sure it'd be better.

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

That code doesn't interface with the bounded stuff... and if you use "-b", it 
should handle alloca() too.  Using the bounding requires padding, for example, 
which makes mine longer.  (The bounded version could be a LITTLE shorter, but 
it seemed more useful right now to make it clear what was different and what 
was the same.)

The code could be a little shorter if I used the FASTCALL interface.  But on a 
quick look, it looked like the FASTCALL interface was different than most 
everyone else's, and we may want to change it so it can interface to other 
FASTCALL interfaces.  Using cdecl added some, but also makes it resistant to 
changes in the compiler.  It'd also be shorter if it was inline instead of a 
real subroutine call... but that'd requiring mucking in the code generators, 
while having a callable function is more modular.

> 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?

Just being defensive.

> 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?)

It seems to me that by default the tcc #includes should override the system 
ones.

--- David A. Wheeler