As per C99, variable length arrays are allowed so conforming compilers would have to support the equivalent of alloca() but the plan9 C dialect is older.
> On Jul 19, 2025, at 9:22 AM, Charles Forsyth <[email protected]> > wrote: > > (except that you can do all the work in C, and with extern register you might > make them strictly equivalent) > > On Sat, 19 Jul 2025 at 17:21, Charles Forsyth <[email protected] > <mailto:[email protected]>> wrote: >> the work required to manage that seems broadly equivalent to saving, >> restoring and managing a frame pointer. >> >> On Sat, 19 Jul 2025 at 17:19, Charles Forsyth <[email protected] >> <mailto:[email protected]>> wrote: >>> languages such as Ada that have dynamically-sized values, including values >>> returned as unconstrained array types, run a second stack in parallel, >>> putting the dynamically-sized things on that. i suppose it's similar to >>> Weinstein and Wulf's QuickFit (one very fast malloc strategy) but with >>> stacked lifetimes. >>> >>> >>> On Sat, 19 Jul 2025 at 17:05, ron minnich <[email protected] >>> <mailto:[email protected]>> wrote: >>>> Sorry, I got that confused, but I still believe that, clever or no, they >>>> should just find a way to not use alloca. >>>> >>>> >>>> >>>> On Sat, Jul 19, 2025 at 8:53 AM Bakul Shah via 9fans <[email protected] >>>> <mailto:[email protected]>> wrote: >>>>> On Jul 19, 2025, at 8:02 AM, ron minnich <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>>> >>>>>> I'd argue that fixing Chez not to need alloca is a better approach. >>>>> >>>>> I believe it is Chicken Scheme that requires alloca() as it uses "Cheney >>>>> on the MTA" garbage collection method that essentially allocates all heap >>>>> objects on the stack. It is a very clever scheme (no pun intended) that >>>>> handles tail recursion extremely well. From >>>>> >>>>> https://web.archive.org/web/20160630144131/http://home.pipeline.com/~hbaker1/CheneyMTA.html >>>>> >>>>> Since the C "stack" never contracts, we can allocate all of our closures >>>>> and user data structures on this stack as automatic/dynamic/local data. >>>>> All closures and user data structures whose sizes are known at compile >>>>> time are statically allocated in the C "stack" frame; dynamic arrays and >>>>> other data structures whose size is unknown at compile time can be >>>>> allocated by C's alloca primitive (or equivalent), which also obtains >>>>> space from the "stack".[3] >>>>> <https://web.archive.org/web/20160630144131/http://home.pipeline.com/~hbaker1/CheneyMTA.html#fn3>Since >>>>> our C "stack" is also the "heap", there is no distinction between stack >>>>> and heap allocation. >>>>> >>>>> Since none of our C functions ever returns, the only live frame on this >>>>> "stack" is the top one. However, within many of the dead frames will be >>>>> found live closures and live user data objects. Eventually, the C "stack" >>>>> will overflow the space assigned to it, and we must perform garbage >>>>> collection. Garbage collection (GC) by copying is a relatively >>>>> straight-forward process. There are a number of static roots, as well as >>>>> the latest continuation closure, which is passed to the GC as an >>>>> argument. (Forming an explicit continuation closure for the GC avoids the >>>>> necessity of scanning C stack frames.) The live objects and live closures >>>>> are all copied (and thereby condensed) into another area, so that >>>>> execution can be restarted with a "stack" frame at the beginning of the C >>>>> "stack" allocation area. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> So emulating alloca() with malloc() [I think Dough Gwyn did this a long >>>>> time ago] kind of defeats the purpose. >>>>> Most Scheme implementations don't rely on this trick. > > 9fans <https://9fans.topicbox.com/latest> / 9fans / see discussions > <https://9fans.topicbox.com/groups/9fans> + participants > <https://9fans.topicbox.com/groups/9fans/members> + delivery options > <https://9fans.topicbox.com/groups/9fans/subscription>Permalink > <https://9fans.topicbox.com/groups/9fans/Tcd29ad8a4559a4cf-M8137517c115dcead9fea4328> ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcd29ad8a4559a4cf-M13a08432cc5aa3c9c1f909d8 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
