On 7/18/25 04:25, Shawn Rutledge wrote: > snip... > There are a couple of obstacles: Chicken uses stack allocation heavily > (Cheney-on-the-MTA implementation), and we don’t have alloca() on Plan 9. > (Why not add it?) And the other is that Chicken’s compiler generates C code: > it would have to be KenC, and avoid using any of the missing libc functions, > or else depend on npe or something. That part seems doable, just a matter of > time.
When alloca() has come up for discussion before within the 9front community, the general push back is that adding support for it was too much work for what is already fairly uncommon in the broader landscape of C code floating around. It's somewhat complicated and would (iirc) mean touching arch specific code. Additionally, I don't think if made available, many newer programs written for 9front would make use of it. Not to mention the already bit of wonky stack space constraints we have within libthread programs. Also, Plan 9 stacks are CoW between processes(RFMEM or not), not sure if that matters for how Chicken uses the stack but its worth calling out because it's different from other systems. That aside I would highly suspect that we'd need to compile the output using ape/npe. While not _too_ much work to translate I can imagine a lack of appetite of an upstream developer for codifying these differences, but I won't speak for them. Regarding chez, my only comment is that with the submodule'd libraries the code base is quite large. Probably doable but a sizeable porting effort. I never got far enough in to lisp to understand the nuance between different implementations that drives the infighting, but perhaps Sigrid's Street Lisp[0] is of interest, already runs on 9front as-is. Thanks, moody [0] https://git.sr.ht/~ft/sl ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T480d89e0fb47654b-Maea2151e52fa37c75a57a75b Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
