2025-03-18 00:19:56 <veltas      > https://pastecode.io/s/sbhv35fh
2025-03-18 16:26:47 <cleobuline  > ForthBot:   40  RECUNACCI .S
2025-03-18 16:26:47 <ForthBot    > Stack: 0 1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 2584 4181 6765 10946 17711 28657 46368 75025 121393 196418 317811 514229 832040 1346269 2178309 3524578 5702887 9227465 14930352 24157817 39088169 63245986 102334155
2025-03-18 19:37:05 <lispmacs[work]> thought I'd mention this forth I ran across recently:
2025-03-18 19:37:07 <lispmacs[work]> https://github.com/dan4thewin/FreeForth2
2025-03-18 21:08:20 <KipIngram   > I hate to think about how much complexity the register renaming likely injected into the system.  I've contemplated that, and it rapidly gets involved.
2025-03-18 21:08:57 <KipIngram   > I'm certainly not saying it's insurountable - just that compared to the extreme simplicity of a "basic" system, it's quite a bit more complicated.
2025-03-18 21:13:03 <lispmacs[work]> 
ACTION is too embarrassed to ask what is register renaming

2025-03-18 21:14:07 <KipIngram   > In the link you just posted - it's a listed feature.  The system caches the top to stack elements in registers, and it will dynamically reassign which one is which such that SWAP has no run-time cost.
2025-03-18 21:14:59 <KipIngram   > Which is easy enough to do if you just have one code path, but when you start wanting things to be callable in any sequence it gets messy, requires duplicate primitives, etc.
2025-03-18 21:15:33 <lispmacs[work]> and the action of "dynamically reassigning" has not run-time cost?
2025-03-18 21:16:28 <KipIngram   > No, it's figured out at compile time.
2025-03-18 21:17:01 <KipIngram   > Say TOS is in reg1 and NOS is in reg2.  If the compiler sees SWAP, then it just says "Ok, now TOS is in reg2 and NOS is in reg1."
2025-03-18 21:17:10 <lispmacs[work]> oh, so you compile out the swap
2025-03-18 21:17:12 <KipIngram   > Or that's the basic idea at least.
2025-03-18 21:17:15 <KipIngram   > Yes.
2025-03-18 21:17:44 <KipIngram   > But any given primitive has to assume some assignment on entry, and leave some assignment when it's done.
2025-03-18 21:18:00 <KipIngram   > So stitching primitives together in arbitrary ways requires careful bookkeeping.
2025-03-18 21:18:48 <KipIngram   > And you might need two versions of a particular primitive - one that expected one assignment and one that expected the reverse, and the compiler would have to figure out which one to compile.
2025-03-18 21:19:14 <KipIngram   > Actually that might be how they do it - they might just pay the piper and carry two copies of primitives where necessary.
2025-03-18 21:19:32 <KipIngram   > It just has always struck me as a rather steep price to pay for eliminating an extremely fast operation.
2025-03-18 21:19:46 <KipIngram   > Particularly fast if both of the top two items are registered.
2025-03-18 21:20:28 <xentrac     > well, you can compile known primitives like @ ! c@ c! + - 1+ 1- * cells swap dup drop over ?do loop = or and 0= if else then and literals into machine code
2025-03-18 21:20:40 <xentrac     > into typically less than one instruction each
2025-03-18 21:20:42 <KipIngram   > It's another one of those cases where I figure if you're that hard up for performance you'll write custom assembly anyway.
2025-03-18 21:21:12 <xentrac     > I think that's what mpeForth does?
2025-03-18 21:21:24 <KipIngram   > I'm not familiar with that one.
2025-03-18 21:21:29 <KipIngram   > Could be, though.
2025-03-18 21:29:00 <DKordic     > lispmacs[work]: Thank You.