2025-05-23 00:31:37 <xentrac     > vms14: well, another simple example is my : field create , does> @ + ;  0 field name  20 field phone from above
2025-05-23 00:32:20 <xentrac     > that defines field as a defining word which adds a number to the number on the top of the stack
2025-05-23 00:32:46 <xentrac     > which might be an address, for example
2025-05-23 00:33:13 <vms14       > I see different ways to create fields in this book
2025-05-23 00:33:15 <xentrac     > that is designed for john-doe phone rather than phone john-doe
2025-05-23 00:33:23 <vms14       > and saw something cool in a way
2025-05-23 00:34:36 <xentrac     > essentially that's like : name 0 + ;  : phone 20 + ; and in general you can use create does> to create a family of words that follow a pattern like that
2025-05-23 00:35:03 <vms14       > https://i.imgur.com/Xd9MT3M.jpeg
2025-05-23 00:35:52 <xentrac     > same as a closure in languages like Python, Perl, or JS, but with explicit rather than implicit capture
2025-05-23 00:35:56 <vms14       > but the : and ; cannot be seen in the code examples
2025-05-23 00:37:17 <vms14       > that field example in the book autogrows total.size so at the end the object knows its size once all the fields are defined
2025-05-23 00:37:21 <xentrac     > that's a nice way of doing it.  -{ and }- are delimiting a "with" block
2025-05-23 00:37:49 <vms14       > 14 field name
2025-05-23 00:38:28 <xentrac     > right
2025-05-23 00:39:49 <vms14       > the book is on the archive btw so it should be free
2025-05-23 00:40:27 <xentrac     > what's the book called?
2025-05-23 00:41:43 <vms14       > https://archive.org/details/object-oriented-forth-implementation-of-data-structures-by-pountain-dick-z-lib.org
2025-05-23 00:43:10 <xentrac     > aha
2025-05-23 01:26:08 <forthBot    > Environment for cleobuline inactive, freeing...
2025-05-23 05:22:52 <MrMobius    > I decided to go with circular stacks for this calculator forth since it absolutely should never crash. im wondering now though if it makes sense to allocate extra space at either end of the stack and only check for out of bounds every 5 or 10 primitives
2025-05-23 05:23:09 <MrMobius    > since I decided not to have PICK or ROLL
2025-05-23 05:23:41 <MrMobius    > then just allocate enough extra memory for the worst case scenario where all 10 primitives push or pop the max number of elements
2025-05-23 09:42:10 <veltas      > I've realised 16-bit Forths are easy to do on x86-32 and x86-64 because the high part of registers is unaffected by 16-bit operations, so you can just reserve a page aligned to 2^16 and keep the address in high 48-bits of all registers, and then 64-bit registers work immediately for memory accesses in the 16-bit memory area
2025-05-23 09:42:52 <veltas      > I'm working on a 16-bit FORTH-79, will see if it gets anywhere but the core is smaller/simpler than other standards so should be alright
2025-05-23 09:43:25 <veltas      > 16-bit because FORTH-79 assumes 16-bit cells.  That way I can try running FORTH-79 programs in the wild
2025-05-23 09:43:38 <veltas      > And native so I can use graphics etc potentially
2025-05-23 09:44:08 <veltas      > So this will be my X konilo
2025-05-23 09:45:32 <veltas      > I'll probably have some words for accessing 48-bit addresses and interoperating with C libraries, I/O, provide blocks access to larger amounts of RAM than 64K etc
2025-05-23 14:02:26 <xentrac     > veltas: ingenious!
2025-05-23 14:03:30 <xentrac     > so you get zero-overhead address offsetting
2025-05-23 15:06:08 <veltas      > Just stumbled upon it while playing with the assembly, saves me a register for some mental overhead
2025-05-23 15:06:47 <veltas      > Should hopefully make instructions faster, will definitely make them smaller
2025-05-23 15:11:06 <xentrac     > it's too bad it's pretty x86 specific
2025-05-23 15:42:37 <MrMobius    > that's a pretty slick idea actually
2025-05-23 15:43:17 <MrMobius    > not to be a naysayer but I would also profile. apparently part of why loading a 32 bit register on x86 clears the top bits is to prevent a dependency that slows down the hardware magic
2025-05-23 15:53:39 <veltas      > Yeah I agree it might be slower than it seems
2025-05-23 15:53:45 <veltas      > I had considered that
2025-05-23 15:54:22 <veltas      > Apparently misaligned access can be *faster* on new x86
2025-05-23 15:54:26 <veltas      > I found out
2025-05-23 15:59:53 <MrMobius    > neat
2025-05-23 16:55:33 <veltas      > I'll be profiling on my older Core 2 Mobile processor, which I believe will have a more severe penalty
2025-05-23 16:56:12 <veltas      > If I have some code to test and a profile script I guess I can share in here and someone with a 'real computer' can try
2025-05-23 17:40:22 <xentrac     > weird, why would misaligned access be faster?
2025-05-23 17:42:55 <MrMobius    > hehe
2025-05-23 20:06:15 <vms14       > KipIngram I keep thinking about your temporary words
2025-05-23 20:06:59 <vms14       > you mentioned something like having words that disappear but you can use them to compose other words
2025-05-23 20:08:22 <vms14       > I guess I should try something similar
2025-05-23 20:09:44 <vms14       > like allowing nested : and make those temporary for compiling purposes
2025-05-23 21:51:58 <cleobuline  > forthBot:  : test 100000 0 DO I DROP LOOP ;
2025-05-23 21:55:35 <cleobuline  > forthBot:  MICRO test MICRO SWAP -
2025-05-23 21:55:40 <cleobuline  > forthBot:  .
2025-05-23 21:55:40 <forthBot    > 4265
2025-05-23 22:21:24 <veltas      > xentrac: https://old.reddit.com/r/C_Programming/comments/na4l6v/how_big_a_deal_is_memory_alignment_these_days_on/gxshoip/
2025-05-23 22:21:39 <veltas      > If you follow that thread upwards there's a little more about this
2025-05-23 22:22:35 <veltas      > So vague rumours but x86 is so complicated now I wouldn't be surprised if there was a very contrived situation where it's faster
2025-05-23 22:23:07 <veltas      > FUZxxl is a regular in ##asm so you can always ask them there
2025-05-23 22:49:56 <xentrac     > thanks!
2025-05-23 23:21:39 <vms14       > I have created this if
2025-05-23 23:21:43 <vms14       > if 0 then oh else meh end
2025-05-23 23:22:08 <vms14       > the test code is between if and then
2025-05-23 23:22:59 <vms14       > so you can put arbitrary code if 1 2 + 3 = then ... end
2025-05-23 23:23:48 <vms14       > I saw in the book I was mentioning the other day that the author hates the then word in forth
2025-05-23 23:24:00 <vms14       > and changes it for endif using forth itself
2025-05-23 23:25:48 <vms14       > "Finally, I detest the use of THEN in the IF...ELSE...THEN control structure so vehemently that I refuse to publish code containing it."
2025-05-23 23:26:30 <vms14       > : ENDIF [COMPILE] THEN ; IMMEDIATE
2025-05-23 23:27:00 <vms14       > so I stole both and created a new if from them
2025-05-23 23:27:13 <vms14       > it makes more sense in my mind
2025-05-23 23:28:24 <vms14       > if you leave it like: if then ... end it behaves like in forth, taking one element from the stack to test for truth
2025-05-23 23:29:24 <vms14       > at the end is the usual if of other languages using rpn
2025-05-23 23:47:07 <veltas      > https://www.youtube.com/watch?v=j95kNwZw8YY
2025-05-23 23:55:40 <forthBot    > Environment for cleobuline inactive, freeing...