[Gcl-devel] Re: alloca

[Camm Maguire]

Greetings!

"Mike Thomas" <address@hidden> writes:

> Hi Camm.
> 
> You've been very naughty - there is no equavalent to alloca() on Windows and
> I note it's use is discouraged on Linux.
> 

!! Wow.  Who could possibly discourage alloca on Linux?  The praises
of alloca echo throughout the techdoms of cyberspace, as a blindingly
fast, robust (in the sense of guaranteed non-interference with other
memory), gc-and-free free memory allocation method.  It is no more
unconventional than the notion of variably-size automatic C
variables.  I suppose it could get one into trouble if one runs out of
space, but one can either check the return value, or even trap the
signal generated for reliable error recovery.


> Is there a way of avoiding alloca()?  Note that  the process stack on
> Windows is strictly limited at link time and there is no automatically
> deallocated memory as such.

OK, stack space limits are fine, as long as they are not too small,
but the beauty of stack allocation is that there is no deallocation at
all!  Surely

int
foo(void) {

char bar[4096];

}

int
main() {

foo();
foo();

}

works properly on Windows in the sense that the second foo places bar
at the same location as the first, no?

But yes, alloca can be replaced if needed.  I'd recommend a "stack
string", which should work properly with the gc:

int
foo(void) {

struct string st={0};
object x=(object)&_s;
void *v;
set_type_of(x,t_string);
x->st.st_self=v=alloc_contblock(n);
x->st.st_dim=n->st.st_fillp=n;

}


> 
> I suppose that the alloca space is relied upon to be immovable - I tried
> replacing alloca with malloc and just wound up with a crash.
> 

Wow.  malloc should work.  The above is just malloc without having to
explictly do a free.

Do I understand from subsequent mail that this is now fixed?

> Much as I hate to encourage further C preprocessor macro use, perhaps you
> could whack in some kind of system specific wrapper macro which allocates
> and if necessary, deallocates, like this:
> 
> #define WITH_LOCAL_MEMORY (amount, expression, variable_type_and_name) \
> { \
>    variable_type_and_name = whatever_allocation_function ( amount );
>    expression /* code using variable_name*/  \
>    maybe_dellocation_function (variable) \
> }


This is fine for the C code, if you'd like, but the compiled C doesn't
have the block close at hand when the macro is written.

> 
> Note that I hope I've fixed the problem with the GCL malloc we discussed
> earlier.

Great!

> 
> As a matter of interest, contrary to my earlier message the memory use of
> the newly hatched Windows HEAD GCL compilation is not so bad I was fooled by
> the larger reserved heap under the current scheme.
> 

Great!  Should be much more compact -- i.e. at least 50% more cons room.

> It is extraordinarily slow, and of course it falls over due to lack of
> alloca().

See separate post here.

Thank you again!!

> 
> Cheers
> 
> Mike Thomas.
> 
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah