2025-03-23 00:30:54 <crc         > MrMobius: prior to my current vm-based designs, I always just left it to the user to deal with, though on x86, it didn't really matter
2025-03-23 00:32:06 <crc         > if I was dealing with a system that faulted on unaligned access, I'd probably just have @ and ! do operations at the byte level behind the scenes
2025-03-23 00:35:24 <thrig       > apple amd64 made you do various alignment calls, but that may just have been apple being weird
2025-03-23 03:29:07 <cleobuline  > Local time for Paris, Île-de-France, Metropolitan France, France is: 2025-03-23 ​​03:21:44 (Time time: Europe/Paris)
2025-03-23 03:39:07 <cleobuline  > ForthBot:  WORDS
2025-03-23 03:39:07 <ForthBot    > DP HELLO DOUBLE FACT POW FIBONACCI COUNTDOWN TUCK 2DROP SUM_SQUARE CUBE SUM_CUBES RECUNACCI CAT :D SOURCE PGCD PRIME? SEED RANDOM RAND DICE ROLLDICES 2DUP 3DUP NUMS STARS COUNT INIT-NUMS SHUFFLE-NUMS PICK-NUM NUM-TO-STR INIT-STARS SHUFFLE-STARS PICK-STAR PICK-2-STARS LOTO EURO foo TRIPLE POW2 TEST-CASE FACTLOOP INIT-RANDOM
2025-03-23 03:39:41 <cleobuline  > ForthBot:  SEED @ .
2025-03-23 03:39:42 <ForthBot    > 15033073099093672470495
2025-03-23 03:42:17 <cleobuline  > ForthBot:  INIT-RANDOM SEED @ .
2025-03-23 03:42:17 <ForthBot    > 1742697737
2025-03-23 03:42:27 <cleobuline  > ForthBot:  INIT-RANDOM SEED @ .
2025-03-23 03:42:27 <ForthBot    > 1742697747
2025-03-23 03:44:18 <cleobuline  > next i will do  ForthBot multiusers , with environnement for each users calling it , in a linked list it will be the best forthbot of the world :)
2025-03-23 03:46:00 <cleobuline  > ForthBot:  DP @ .
2025-03-23 03:46:00 <ForthBot    > 44
2025-03-23 10:29:52 <veltas      > MrMobius: Personally if unaligned access raises an exception, then it depends a little whether the exception is trapped in your Forth
2025-03-23 10:30:55 <veltas      > But also for performance reasons I wouldn't check it, so yeah just throw
2025-03-23 10:31:31 <veltas      > And even I write code with correct alignment, just because the performance is better on x86, not even for stability on other platforms
2025-03-23 10:31:45 <veltas      > I think most Forth code is alignment safe, or can be with minor tweaks
2025-03-23 10:33:19 <veltas      > Even the Forth standard can conform to the hardware requirements here, so it seems safe to lean on the actual architecture restrictions, and require alignment
2025-03-23 10:34:04 <veltas      > My ZX Spectrum Forth has the alignment words, they're just identity/no-op words
2025-03-23 10:42:06 <veltas      > I've found the main pain point for alignment is packing strings alongside other data, e.g. dictionary headers
2025-03-23 10:42:49 <veltas      > Usually you can put strings last, but for dictionary header the parameter area comes after the name, so you can just pad to alignment
2025-03-23 12:30:55 <KipIngram   > That problem goes away if you separate headers from bodies.
2025-03-23 12:32:06 <xentrac     > create foo  3 allot  create bar  3 cells allot still needs to worry about alignment even if headers are separate from bodies?
2025-03-23 12:32:27 <KipIngram   > My thinking on headers these days is to let the strings grow down from the top of the RAM region instead of up from the bottom.  Then you don't need separate "link" and "count" fields - the first fields of each header are fixed, and then the string is last and its count byte tells you how to get to the next (earlier) header.
2025-03-23 12:32:38 <xentrac     > (but not on a Z80)
2025-03-23 12:33:30 <KipIngram   > Well, that's true, yes.  Good point - names aren't the only strings.
2025-03-23 12:34:22 <xentrac     > you could put the count at the end of the string if you want the dictionary headers to grow up from the bottom of something.  Won't work without separate headers in either case
2025-03-23 12:36:28 <xentrac     > like  |     cfa     |     dfa     | f | o | o | 3 |  or something?
2025-03-23 12:38:50 <KipIngram   > Yeah, that's true, but then you're kind of dealing with the "odd bits" elsewhere.  I kind of like the idea of a "dictionary" being a RAM region with some management variables at the bottom and the strings growing down from the top.  A low variable will point to the last item added, and that gets you the equivalent of a linked list search.  But then if you want to you can OPTIONALLY add a low
2025-03-23 12:38:53 <KipIngram   > variable (which would be NULL when you're not doing this) that refers to a separately allocated hash table.  So hashing is an optional feature you can add to any dictionary.
2025-03-23 12:40:56 <KipIngram   > It's not really quite a fully generic dictionary, though, because it's not so feasible to remove items.
2025-03-23 12:41:24 <KipIngram   > You could invalidate them, I guess, but then you'd accumulate cruft.
2025-03-23 12:42:23 <KipIngram   > For Forth's usually "last defined, first forgotten" mode, though, it works quite nicely.
2025-03-23 12:42:53 <KipIngram   > s/usually/usual/
2025-03-23 12:48:47 <xentrac     > you could remove items off the end and then rehash the whole dictionary
2025-03-23 12:49:18 <xentrac     > oh, you mean it's not generic in that it doesn't support non-LIFO deletion
2025-03-23 12:52:20 <xentrac     > if you want non-LIFO deletion with storage reclamation for strings you need a fairly complex allocator.  not, you know, anything beyond what BASIC-80 had on the Altair
2025-03-23 12:52:42 <xentrac     > but more than just a bump pointer
2025-03-23 12:53:50 <KipIngram   > Yeah, adding that raises the complexity level a good bit.
2025-03-23 12:53:57 <KipIngram   > It's just so elegantly simnple otherwise.
2025-03-23 12:54:32 <KipIngram   > And yes - invalidation with occasional re-construction would likely be pretty practical.
2025-03-23 12:55:21 <KipIngram   > Dictionaries are pretty useful - I've used them in  Python a good bit.
2025-03-23 12:56:40 <xentrac     > an alternative often used in old Lisps was property lists.  You could imagine adding those to a Forth
2025-03-23 12:57:38 <xentrac     > you'd still need dynamic allocation, but almost just a freelist
2025-03-23 12:58:32 <xentrac     > the idea is that each "atom" or "symbol" (Forth "word") has a linked list of "properties" hung off it
2025-03-23 12:58:46 <xentrac     > each itself identified by a symbol
2025-03-23 12:59:30 <xentrac     > so the actual hashing step is done at read time when the symbol is interned
2025-03-23 13:00:17 <xentrac     > each property corresponds to a Python dict.  it doesn't garbage-collect the properties or scale to a lot of them
2025-03-23 13:01:06 <xentrac     > but often that's okay
2025-03-23 13:08:11 <veltas      > xentrac: I put the count at the start and end, and I tend to write essentially ".align 4, count; .byte count"
2025-03-23 13:08:30 <veltas      > Sorry I mean ".byte count; .align 4, count"
2025-03-23 13:08:43 <xentrac     > veltas: hmm
2025-03-23 13:08:47 <veltas      > That guarantees that the area *ends* with the count
2025-03-23 13:09:06 <xentrac     > yes, that makes sense
2025-03-23 13:09:06 <veltas      > And you can recover the full aligned offset from the count
2025-03-23 13:09:19 <veltas      > But yeah on Z80 it makes no difference
2025-03-23 13:09:46 <xentrac     > although, wouldn't you want the end of the count byte to be aligned rather than the beginning?
2025-03-23 13:09:57 <xentrac     > like, assuming 4-byte alignment:
2025-03-23 13:10:52 <xentrac     > | @ |   |   | 1 |
2025-03-23 13:10:52 <xentrac     > | > | r |   | 2 |
2025-03-23 13:11:03 <xentrac     > | s | w | a | p |   |   |   | 4 |
2025-03-23 13:11:13 <xentrac     > not, for example
2025-03-23 13:11:30 <xentrac     > | @ |   |   |   | 1 |   |   |   |
2025-03-23 13:11:51 <veltas      > Yes that's why I do ".byte count; .align 4, count", i.e. it fills the alignment padding with counts too
2025-03-23 13:12:04 <xentrac     > oh, I misunderstood
2025-03-23 13:12:06 <xentrac     > thanks!
2025-03-23 13:12:14 <veltas      > Guarantees it finishes aligned, because .align comes last, and .byte comes first to ensure there's at least one
2025-03-23 13:12:24 <veltas      > No problem, it's subtle
2025-03-23 16:24:00 <MrMobius    > actually, just masking out the bottom bits is probably easiest
2025-03-23 16:42:10 <xentrac     > 
ACTION masks his bottom bits

2025-03-23 22:17:58 <cleobuline  > ForthBot:  1 16 POW2
2025-03-23 22:17:58 <ForthBot    > 1
2025-03-23 22:18:30 <xentrac     > ForthBot: 2 5 POW2 . . .
2025-03-23 22:18:31 <ForthBot    > 32
2025-03-23 22:18:46 <xentrac     > oh, you really need to fix that multiline output
2025-03-23 22:18:53 <xentrac     > ForthBot: . . .
2025-03-23 22:18:53 <ForthBot    > Stack empty
2025-03-23 22:19:03 <xentrac     > ForthBot: . . . . . . . . . . . . . . . . . . . . . .  . . . . . . .
2025-03-23 22:19:03 <ForthBot    > Stack empty
2025-03-23 22:19:09 <cleobuline  > lol
2025-03-23 22:19:24 <xentrac     > ForthBot: . . . . . . . . . . . . . . . . . . . . . .  . . . . . . .
2025-03-23 22:19:24 <ForthBot    > Stack empty
2025-03-23 22:19:28 <xentrac     > not fixed yet
2025-03-23 22:19:43 <xentrac     > not fixed yet
2025-03-23 22:19:45 <xentrac     > ForthBot: . . . . . . . . . . . . . . . . . . . . . .  . . . . . . .
2025-03-23 22:19:45 <ForthBot    > Stack empty
2025-03-23 22:19:50 <xentrac     > still not fixed
2025-03-23 22:20:20 <xentrac     > it shouldn't be possible for one line of chat to provoke multiple lines of output, ever
2025-03-23 22:21:55 <xentrac     > because if it is people will do it by accident and annoy others
2025-03-23 22:23:25 <cleobuline  > i am working on a multiusers forthbot
2025-03-23 22:23:30 <cleobuline  > now
2025-03-23 22:23:46 <cleobuline  > this version wil be obsolète :)
2025-03-23 22:26:23 <xentrac     > a multiuser stateful interpreter is exciting!