2026-02-21 14:33:43 I see, thanks! 2026-02-21 14:40:37 crc: Isn't it usually just : HERE DP @ ; ? 2026-02-21 14:41:10 Oh, I see now I misread that initially - I was thinking about the stack changing, not the dictionary pointer. 2026-02-21 14:42:11 Actually it's more subtle than my initial impression, and you're right that it likely varies, crc. It think in most of the systems I've written HERE *would* immediately update, just because of how I wrote it. Since that 1 2 in Guest87's code sample have changed the dictionary pointer. 2026-02-21 14:43:00 But I guess some implementations might keep all that stuff temporary until compilation is known to have succeeded, and then post the temporary variables back. 2026-02-21 14:44:15 In my systems I just update DP immediately - if an error occurs my "error recovery sledgehammer" puts EVERYTHING back the way it was at the beginning of the line, and that would include DP. 2026-02-21 14:45:13 I won't really be able to do that on this ESP32-C6, though - it's really viable only in a "RAM rich" system. 2026-02-21 14:49:13 I've used a few systems in the past that separate code and data completely, so HERE wouldn't return anything useful for accessing code related addresses 2026-02-21 14:54:39 Right. Ultimatelyl HERE is a convenience - it's the pointers that matter, and you'd just have to have one for each region. 2026-02-21 15:02:11 Guest87 would face a limit here since ANS doesn't have a standard way to get something like HERE for code space. There's likely a way to get the information, but it'll be system specific 2026-02-21 15:04:29 Given that EXECUTE takes an xt and is the main way to do indirect calls, I would guess an xt is going to be the code address or at least the code pointer on every Forth system 2026-02-21 15:04:53 It will be easy to play with that and find code, but yes it's system specific 2026-02-21 15:12:50 crc: See, that bothers me a little because it means the standard doesn't tell you how to write words that compile. That's just a step away from the very soul of Forth. 2026-02-21 15:13:05 They basically punted. 2026-02-21 15:17:04 an xt isn't actually guaranteed to be an address though. I've used at least one system where it wasn't (in that it was an index into an internal hidden table that mapped xts to the compiled words or internal primitives), though it does usually seem to be an address 2026-02-21 15:20:01 Right - this system I'm starting on now will be code-threaded running on a byte-coded vm. So something like + will be a vm instruction - its xt will indeed be a byte that indexes into a table. But then the xt for : plus + ; would be an address, pointing to vm code. The only way to know the difference will be to note that items like + will have "very small valued" xt's. 2026-02-21 15:21:30 Basically "if (xt & 0xFFFFFFFFFFFFFF00) { address } else { index }. 2026-02-21 15:23:44 XTs are indexes in my system to maintain stability 2026-02-21 15:24:58 and hide compiled code from the user. the only accessible addresses are for data 2026-02-21 15:25:51 That's just an abstraction I don't care to impose. I like things more "raw." 2026-02-21 15:27:47 right. makes sense depending on the system 2026-02-21 15:28:19 I just dont want to crash the whole machine when I have 12 programs open at once 2026-02-21 15:29:07 it's an ok compromise in that case 2026-02-21 16:36:20 I've used ABIs (Linux PPC64) where function pointers aren't the code address 2026-02-21 16:37:02 Instead they're a pointer to a record containing the code address and also the GOT(?) pointer for that function 2026-02-21 16:37:20 Because the relative global access in PPC is a lot smaller than x86 or something 2026-02-21 16:38:17 AMD64 situation is a lot simpler allowing getting 32-bit displacements from RIP, so for simple programs you can just rely on that 2026-02-21 16:38:35 And then for position-independent programs you can rely on that to get to the GOT 2026-02-21 16:39:27 I think if you're making a native-ish forth for a modern arch it's a good idea to find out how relocations etc work 2026-02-21 16:39:36 So you can build dynamically-loadable code if you wish 2026-02-21 21:45:33 I've dodged that so far. I generally just write code that's position independent, and I don't make any attempt to store compiled code for later use - I just load from source. 2026-02-21 21:46:12 I thought at times about trying to craft a system that would let me relocate code during operation, but I decided that it would bring in too much complexity and abandoned it.