2022-01-28 12:37:52 <joe9        > @crc, you around?
2022-01-28 12:48:49 <crc         > joe9: yes
2022-01-28 12:49:10 <joe9        > Do you know of inferno?
2022-01-28 12:49:22 <crc         > I've read a bit on it, never used it :(
2022-01-28 12:49:55 <joe9        > I am experimenting with a forth user space on a plan9 kernel following similar ideas and have some numbers http://okturing.com/src/13047/body
2022-01-28 12:50:24 <joe9        > the inferno model avoids syscall gates and uses linear memory (no paging)
2022-01-28 12:50:43 <joe9        > It seemed easy to add address checking to forth bindings
2022-01-28 12:52:19 <Zarutian_HTC> joe9: what are syscall gates?
2022-01-28 12:52:26 <joe9        > just syscalls
2022-01-28 12:52:38 <joe9        > kernel syscalls
2022-01-28 12:52:53 <joe9        > such as what linux/unix provides.
2022-01-28 12:52:59 <crc         > so about 15% faster using forth?
2022-01-28 12:53:10 <joe9        > on a raw syscall speed, sure.
2022-01-28 12:53:11 <Zarutian_HTC> oh, I thought it might be something like VirtualDynamicObject or some such
2022-01-28 12:53:46 <Zarutian_HTC> basically sysenter or software interrupts instr?
2022-01-28 12:54:24 <joe9        > this is direct threaded forth (based on felix forth). So, the forth's NEXT will be 2x the actual CALL/RET (4 instructions vs 2)
2022-01-28 12:54:38 <joe9        > 10:53 < Zarutian_HTC> basically sysenter or software interrupts instr? -- yes
2022-01-28 12:55:23 <Zarutian_HTC> good, I hate things trying to muck up the memory space of programs I write
2022-01-28 12:55:43 <joe9        > yes, forth macros do the address checking.
2022-01-28 12:56:16 <joe9        > every forth userspace process is in a sandbox literally.
2022-01-28 12:56:26 <Zarutian_HTC> once had some AV software try to inject itself into a process at a clients site
2022-01-28 12:58:44 <Zarutian_HTC> that injected dll got written over by some forth words which caused the other processes where that dll had been injected to crash mysteriously
2022-01-28 12:59:10 <crc         > I'm not one who chases performance, but it's nice to see an example where a forth beats a C equivalent
2022-01-28 12:59:22 <crc         > nicely done :)
2022-01-28 12:59:26 <Zarutian_HTC> but this was more than a decade and a half ago
2022-01-28 13:01:00 <joe9        > @crc, do you see any benefit in pursuing an effort like this?
2022-01-28 13:01:11 <joe9        > add job control, some userspace programs, etc.
2022-01-28 13:02:06 <joe9        > basically, a forth shell. It needs a file system too.
2022-01-28 13:03:37 <eris[m]11   > <joe9> "the inferno model avoids syscall..." <- hm?
2022-01-28 13:04:12 <joe9        > eris[m]11: it turns it to a direct function call on native architecture.
2022-01-28 13:04:25 <joe9        > on hosted machines, there is no alternative.
2022-01-28 13:04:44 <joe9        > the language is meant to protect memory, address bounds, etc.
2022-01-28 13:05:12 <crc         > joe9: yes; I like a Forth based userspace
2022-01-28 13:12:47 <crc         > 
ACTION works within forth and forth based tools whenever it's practical

2022-01-28 13:14:04 <joe9        > crc, were you able to understand the  numbers I presented easily? I am not sure if I should change the presentation
2022-01-28 13:16:47 <crc         > yes, it's pretty straightforward
2022-01-28 13:26:48 <joe9        > do you know of any forth shells around?
2022-01-28 13:27:06 <joe9        > so, I can see if I can just port the code instead of coding one from the ground up..
2022-01-28 13:31:20 <eris[m]11   > you keep saying forth shell as if it's something you need to keep around
2022-01-28 13:31:32 <eris[m]11   > the notion of a shell, that is
2022-01-28 13:31:45 <eris[m]11   > whats wrong with just.... a forth repl with file words
2022-01-28 13:32:06 <crc         > https://archive.softwareheritage.org/browse/origin/directory/?origin_url=https://bitbucket.org/cowile/forsh.git
2022-01-28 13:32:29 <joe9        > eris[m]11: nothing, just need to add job / process control.
2022-01-28 13:32:44 <joe9        > I do not mean a shell per-se. I think the forth repl is better.
2022-01-28 13:32:52 <joe9        > just need to add some job control and piping.
2022-01-28 13:33:02 <eris[m]11   > ok
2022-01-28 13:33:02 <eris[m]11   > ahh
2022-01-28 13:34:02 <eris[m]11   > hmm
2022-01-28 13:34:06 <eris[m]11   > forth already has a mechanism for piping, essentially
2022-01-28 13:34:11 <eris[m]11   > the stack
2022-01-28 13:34:27 <joe9        > the forth stack is not a pipe.
2022-01-28 13:34:40 <joe9        > I mean it can be treated as one.
2022-01-28 13:35:27 <joe9        > but, I have  each forth user process with it's own parameter and return stacks and heap and dictionary.
2022-01-28 13:35:58 <joe9        > I want to keep each forth process to it's own memory for memory protection and address bounds checking, etc.
2022-01-28 13:36:29 <crc         > I use an environment built around a line editor written in my forth with some utilities
2022-01-28 13:36:43 <joe9        > is it hosted somewhere?
2022-01-28 13:37:18 <crc         > the core bits are at https://git.sr.ht/~crc_/rx/tree
2022-01-28 15:05:23 <joe9        > any ideas for argument processing with forth? use words as arguments?
2022-01-28 15:36:35 <bluekelp    > it doesn't appear from the docs that ATLAST supports multiple instances in a single program. does anyone know if this has been added somewhere?
2022-01-28 15:37:20 <bluekelp    > I haven't dug into the source to assess how difficult this would be to do
2022-01-28 15:41:00 <crc         > I don't think the source is well set up for that; iirc most of the state is in a bunch of global variables
2022-01-28 15:41:16 <eris[m]11   > hmm
2022-01-28 15:41:36 <eris[m]11   > personally the way i'd do it is a single global variable for a linked list
2022-01-28 15:42:30 <eris[m]11   > and have the items of the list be pointers to the code after the ATLAST
2022-01-28 15:42:48 <eris[m]11   > but i dont know what atlast is implemented as
2022-01-28 15:43:29 <crc         > https://github.com/ForthHub/Atlast/blob/master/atlast.c lines 112-235 lists most of them
2022-01-28 15:44:16 <eris[m]11   > oh my, in C?
2022-01-28 15:44:22 <crc         > atlast was basically intended as a way to add scriptability to applications (similar to autolisp in older autocad)
2022-01-28 15:44:28 <crc         > eris[m]11: yes
2022-01-28 15:44:33 <eris[m]11   > ah
2022-01-28 15:44:33 <eris[m]11   > i assumed something else entirely
2022-01-28 15:44:34 <eris[m]11   > like
2022-01-28 15:44:39 <eris[m]11   > i thought this was a 'defer'
2022-01-28 15:44:41 <eris[m]11   > based on the name
2022-01-28 15:44:42 <eris[m]11   > lol
2022-01-28 15:44:50 <crc         > it wasn't intended to be a standalone forth
2022-01-28 15:44:54 <eris[m]11   > scratch everything i just said from the record :)
2022-01-28 15:45:15 <eris[m]11   > i assumed ATLAST was a word ala go's or zig's defer, which moves execution to the end of a scope
2022-01-28 15:45:41 <crc         > 
ACTION worked extensively with atlast 1.x many years back

2022-01-28 15:46:08 <eris[m]11   > `foo = malloc (something); defer free(foo)`
2022-01-28 15:46:10 <eris[m]11   > that kind of thing
2022-01-28 15:48:20 <bluekelp    > @crc are there more "modern" ATLAST implementations or something for adding basic "scripting" to an application?
2022-01-28 15:48:57 <bluekelp    > sounds like I need to hack the source. but it's worth asking :)
2022-01-28 15:50:45 <bluekelp    > I want a more contained/constrained and multi-tenant forth - for simple scripting inside an app. but do not want VM A to be able to poke at VM B except through well defined communication paths
2022-01-28 15:51:27 <crc         > https://github.com/quoha/ATLast attempted to reduce state, but I think it's atlast v1 derived and don't remember it beings completed
2022-01-28 15:53:39 <crc         > https://github.com/andrewtholt/ATlast is the only active fork I see, but it's still using a lot of global state
2022-01-28 18:13:14 <veltas      > joe9: That 9ferno forth stuff looks cool
2022-01-28 18:18:02 <joe9        > veltas: yes, I am excited about it too.
2022-01-28 18:19:04 <veltas      > Very impressed, more interesting than what I'm doing lol