On Tuesday 08 May 2007 2:17 am, David A. Wheeler wrote: > I've attached a first cut implementation of alloca for tcc. This one > allocates cleanly straight off the stack - no monkeying with malloc() at > all. It currently doesn't actually call the bounds-checking functions, > though I know in principle what it needs to call. Runs on Linux; _may_ work > on Windows, but I suspect that there's some oddities involving page access > that would need to be accounted for.
Last I checked, tcc could also produce arm output. I take it this is going to need an arm version of the .S file? (This goes in... libtcc?) There's no included change to the makefile to make anything actually use this, I take it you just make a .o from the .S, #include the .h and give it a try? (I assume this isn't something I should attempt to merge just yet. :) I'm not convinced increasing the size of the allocation is a plus, other than possibly rounding up for alignment reasons. Otherwise, by that logic every char array we declare on the stack should have extra memory allocated. I tend not to assume that people who use my code will be stupid (or more accurately, I assume there's nothing useful I can do about it if they are, and the best thing I can do is make the results of their stupidity show up as promptly and obviously as possible). Could the extra memory for the bounds checker be guarded with an #ifdef of some kind, please? The man page warns that the broken glibc headers unconditionally #define alloca() as __builtin_alloca(). We might as well use that name rather than trying to fight the FSF brain damage. Other than that, it looks good. :) Rob _______________________________________________ Tinycc-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/tinycc-devel
