2024-01-27 15:47:01 <zelgomer    > what is the prescribed method for implementing the user dictionary space in a c forth? do you just malloc a huge region that you think will be more than enough? or are there clever strategies for mallocing small chunks as needed and making them appear to be contiguous, or rendering contiguity unnecessary?
2024-01-27 15:49:47 <GeDaMo      > You could use realloc to increase the size of the chunk and make all your memory references offsets to a base pointer
2024-01-27 15:50:20 <zelgomer    > yup, was thinking of that too
2024-01-27 15:51:33 <zelgomer    > and the more i think of it, that probably is the way. x86 has indexed indirect addressing, so it shouldn't even cost much
2024-01-27 15:52:29 <zelgomer    > i've done a near complete 180 from where i started a few months ago. i'm really considering a new workflow model
2024-01-27 15:53:22 <user51      > Just think about where you'll be after a few more months!  :P
2024-01-27 15:53:39 <zelgomer    > exactly
2024-01-27 15:54:53 <zelgomer    > rather than writing one glorious forth to rule them all, i'm thinking every project i start should begin with a very minimal c file to bootstrap a host forth, and then from there write the compiler for the target, and then compile the target source
2024-01-27 15:55:29 <GeDaMo      > Another advantage of the base + offset is you can make the offset 32 bits on a 64 bit system if you're sure you only need 4GB and save some memory
2024-01-27 15:55:42 <zelgomer    > the reason being: this reduces any project's build dependencies to only a native c compiler, which today is ubiquitous
2024-01-27 15:59:02 <zelgomer    > GeDaMo: true. in my asm implementations i was already playing games with short threading - you can lodsw to only update the low 16 bits of rax, leaving the high 48 alone - but i think the base+offset is the only way to achieve that in portable c
2024-01-27 16:05:56 <zelgomer    > plus i think the self-contained-forth-project is more in line with the philosophy of forth as a technique rather than any one implementation
2024-01-27 16:10:47 <zelgomer    > i wonder if it even makes sense to go so far as to write the host forth to emulate properties of the target system
2024-01-27 16:12:08 <zelgomer    > e.g., if the goal is to target a 16-bit uC, then maybe all cells and virtual addresses should be 16 bits, and maybe some built-in word to switch address space (like a segment register)
2024-01-27 22:09:08 <zelgomer    > hm. but using base+offset addressing, then how do you represent execution tokens for builtin code words, since they live in the program data segment? i could tokenize xts <256, but then i start to wonder whether i should tokenize all xts just to keep it simple
2024-01-27 22:10:20 <GeDaMo      > You could separate executable / data by pages
2024-01-27 22:11:05 <GeDaMo      > That might get a bit fiddly
2024-01-27 22:31:29 <zelgomer    > well, since the body for a code word is basically just a function pointer, i suppose i could simply initialize the dictionary with headers and bodies for builtin words at startup. i was just hoping to avoid a heavy-handed runtime initialization like that, but i suppose it's fine
2024-01-27 22:32:15 <zelgomer    > i can generate the vocabulary linkage at the same time instead of having to manage it manually in static struct definitions
2024-01-27 22:32:57 <zelgomer    > which, come to think of it, i suppose the dynamic linker has to resolve at program initialization for aslr, anyway, so nothing is really lost