2024-07-16 00:31:48 lf94: I've done some experiments with similar things to the forth salon thing, but nothing that runs in a browser 2024-07-16 00:33:40 re: multicore, I'm not really aware of anything significant for this, apart from (possibly) the GreenArrays stuff. 2024-07-16 00:36:00 I experiment with this a bit in some of my vm designs (napia & nga+multicore extension), but haven't really implemented anything that takes advantage of parallel execution 2024-07-16 00:59:43 GreenArrays is a whole different sort of multi-core programming, due to the extremely limited RAM on the cores. 2024-07-16 01:00:08 I liken it to you coding up really simple "custom chips" and then wiring them together into a "circuit." 2024-07-16 01:01:48 Re: normal multicore, if you build a child task "call frame" on your stack and then dispatch the task, you're faced with whether or not to copy that frame off to the child's stack or not. Doing so takes time, of course, but not doing so just invites cache collisions between parent and child (as well as requirin the parent to leave that frame in place until the child is done). 2024-07-16 01:02:16 The parent could continue, so long as it just extended its stack. 2024-07-16 01:03:35 In my system I could let the child's frame pointer be the parent's frame pointer at the time of the call, and that would make it easy for the child to reference the parent's stack. I got a little excited about that until I thought about the likely impact on the caches. 2024-07-16 01:42:54 I would prefer to just do 1 forth runner per core 2024-07-16 01:43:08 really threads etc are just smaller bite sized programs 2024-07-16 01:43:19 i think forth could really lend itself well to concurrency 2024-07-16 01:43:40 i honestly dont know enough about the details to know what forth's concurrency primitive would be