02:35:55
##forth
<cleobuli_>
forthBot: LOAD ini.fth
02:35:56
##forth
<forthBot>
File ini.fth with MOON loaded
02:36:01
##forth
<cleobuli_>
forthBot: MOON
02:36:02
##forth
<forthBot>
Phase de la lune pour Fri September 26 2025
02:36:02
##forth
<forthBot>
🌒 Croissant montant Une jeune lune, un nouveau depart a Paris ! Illumination 15%
04:36:01
##forth
<forthBot>
Environment for cleobuli_ inactive, freeing...
17:55:02
##forth
<KipIngram>
So, how are variables usually done in code/subroutine threaded Forth systems? Are they just compiled as literals for the target address?
18:02:01
##forth
<veltas>
That's pandora's box you just opened
18:03:15
##forth
<veltas>
It really depends on the memory model and how you want the Forth to be linked
18:04:56
##forth
<veltas>
Generally I would try to inline the code to get the variable rather than adding a call to the xt
18:06:02
##forth
<veltas>
What's the arch/situation?
19:47:21
##forth
<KipIngram>
The "arch" is going to be a byte coded vm of my own design. That in itself has nothing to do with Forth - the Forth will be implemented on top of it using code threading. The vm will have suitable literal instructions, yet to be designed. I've been thinking I want one for "small" literals (-128-127), and another for full size ones - it'll just take the next cell in the instruction stream as the
19:47:23
##forth
<KipIngram>
literal value. But I want variables to be in process RAM, and I'll have a register denoting the base address of the running process's RAM. sp fpr this purpose I'll want an offset from that register. So it's well possible that some variables could be in that -128-127 range, but I can't count on it.
19:47:40
##forth
<KipIngram>
The compiler will work out the most compact way to compile it.
19:48:21
##forth
<KipIngram>
I'm not surprised by your Pandora's Box remark - I've never done a code threaded system before, but it didn't take thinking about it long to see that it made variables a little... odd?
19:48:57
##forth
<KipIngram>
I've thought of severals ways that could work, but none of them felt smooth and elegant like the way indirect threaded variables do.
19:49:13
##forth
<KipIngram>
Indirect threading is just an awfully nice machine.
19:50:26
##forth
<KipIngram>
Whereas as far as I can tell so far the only thing code threading does well is... code.
19:51:13
##forth
<KipIngram>
I thought maybe there was some wonderfully clever approach I'd not thought of. :-)
20:18:34
##forth
<KipIngram>
Actually I guess what I was describing above wouldn't be a normal lit - since it's an offset from a register I'd want an instruction for that, that took the offset from the code stream and added on the register to get a proper address to put on the stack.
20:18:56
##forth
<KipIngram>
A "vlit" instruction.