[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] alloca for tcc (x86) - second cut
From: |
David A. Wheeler |
Subject: |
Re: [Tinycc-devel] alloca for tcc (x86) - second cut |
Date: |
Wed, 09 May 2007 19:25:25 -0400 (EDT) |
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
- [Tinycc-devel] alloca for tcc - first cut, David A. Wheeler, 2007/05/08
- Re: [Tinycc-devel] alloca for tcc - first cut, Rob Landley, 2007/05/09
- [Tinycc-devel] alloca for tcc (x86) - second cut, David A. Wheeler, 2007/05/09
- Re: [Tinycc-devel] alloca for tcc (x86) - second cut, Rob Landley, 2007/05/09
- Re: [Tinycc-devel] alloca for tcc (x86) - second cut, Daniel Glöckner, 2007/05/09
- Re: [Tinycc-devel] alloca for tcc (x86) - second cut, Rob Landley, 2007/05/09
- Re: [Tinycc-devel] alloca for tcc (x86) - second cut,
David A. Wheeler <=
- Re: [Tinycc-devel] alloca for tcc (x86) - second cut, Daniel Glöckner, 2007/05/10
- Re: [Tinycc-devel] alloca for tcc (x86) - second cut, Rob Landley, 2007/05/10
- [Tinycc-devel] alloca for tcc (x86) - v3, David A. Wheeler, 2007/05/09
- Re: [Tinycc-devel] alloca for tcc (x86) - v3, Rob Landley, 2007/05/12