Glenn Fowler wrote: > > On Mon, 13 Nov 2006 09:39:28 +0100 Roland Mainz wrote: > note that this is a non-ast problem > no ast code uses > > int foo = some_size; > some_type bar[foo];
Yes, I know... but remember the prototype code I send you... The idea is to use the stack for such temporary allocations since it has significant advantages over memory from the heap, including: - Allocations do not require a function call, just a few instructions (e.g. store pointer, adjust stack pointer etc.) - The code size and complexity shrinks significantly (e.g. no |free()| required in most situations) - Allocations on the stack benefit from larger page size (remember my patch to map the stack with 64k pages instead of 8k pages on SPARC; machines like UltraSPARC-1/2 and Niagara will greatly benefit from this) - Allocations on the stack are likely coming from memory which is already in the cache hieracy (e.g. L2 or L1 cache) since it was used previously (e.g. no cache blocks need to be shuffeled around to make room for "yet another temporary buffer" from heap) - Less heap+BSS (as done in "the great libcmd purge" for ksh93s_20061031) would be required for temporary storage (footprint) Beyond that it was one of the main reasons to compile ksh93 with C99 enabled (the other reason was to get C99 math to enable the usage of these functions from the shell script level (and get rid of the "division by zero" thing)) ... ... the only problem that the OS/Net build system has some "hiccups" with "variable length arrays" ... but that isn't your problem (that's mine) and shouldn't prevent the usage of C99 variable length arrays in the AST codebase. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
