(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]> 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]> > 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]> 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]> >>> wrote: >>> >>>> On Jul 19, 2025, at 8:02 AM, ron minnich <[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-Me761cd298a65132674bf0900> >>> ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcd29ad8a4559a4cf-M8137517c115dcead9fea4328 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
