2024-03-16 03:19:03 <joe9        > any ideas for a jump implementation in forth? I like the colorforth's jump but it needs to be in a definition.
2024-03-16 03:39:09 <zelgomer    > jump?
2024-03-16 03:39:17 <joe9        > yes, the jump tables
2024-03-16 03:39:50 <zelgomer    > cells + @ execute
2024-03-16 03:45:35 <joe9        > It is a macro and cannot be used at runtime.
2024-03-16 03:45:40 <joe9        > in colorforth.
2024-03-16 03:49:42 <zelgomer    > : jump  cells + @ compile ; immediate
2024-03-16 03:50:17 <zelgomer    > i don't know, need more description than "in colorforth"
2024-03-16 09:09:02 <veltas      > KipIngram: The aim is I'll have e.g. some optimised x86-64 words I INCLUDE and then I INCLUDE some slower generic implementations, and write WEAK after them all, so only the ones I didn't optimise are left and take up space in the dictionary
2024-03-16 09:10:10 <veltas      > zelgomer: It won't interact with vocabs / wordlists.  It will just search the search order and remove the def if another's found, not changing order/current
2024-03-16 09:10:29 <veltas      > It's not as sophisticated as MARKER, it's meant to be used just right after a definition
2024-03-16 09:14:30 <veltas      > crc: Thanks for the example
2024-03-16 09:14:55 <veltas      > Blocks are too cool, every time I see them it makes me want to do stuff with them again
2024-03-16 09:57:05 <veltas      > 64-bit is crap
2024-03-16 09:57:53 <veltas      > We've got to come to terms with that eventually
2024-03-16 10:58:55 <MrMobius    > 64 bit is crap?
2024-03-16 11:01:47 <veltas      > The problem isn't really with 64-bit, but having 8-byte integers/addresses everywhere is just too fat
2024-03-16 11:03:11 <veltas      > C is better than Forth at this because it distinguishes normal integers from pointers/sizes, but you still end up with 8-byte quantities everywhere
2024-03-16 11:05:38 <veltas      > I was thinking there's usually nothing stopping us from using a 32-bit memory model on 64-bit, I'm guessing most OS's will let us map memory in the lower 4GB address space
2024-03-16 11:06:25 <veltas      > Then we can do 64-bit native forth with 32-bit words, with doubles for 'far' addressing as necessary
2024-03-16 11:10:08 <veltas      > I'm not sure if what I'm saying is equivalent to https://en.wikipedia.org/wiki/X32_ABI
2024-03-16 11:46:21 <GeDaMo      > You could use a 64 bit base address with a 32 bit offset
2024-03-16 11:55:19 <veltas      > Possible performance impact but that's one approach
2024-03-16 11:55:35 <veltas      > Better to just take advantage of virtual memory if that's an option
2024-03-16 13:24:06 <veltas      > Yeah I think performance/size impact of register+offset although it's a reasonable tradeoff if you make less assumptions about your operating environment
2024-03-16 13:24:24 <veltas      > I just don't, I assume I'm either in control or working with an OS that doesn't hate me
2024-03-16 13:24:48 <veltas      > In control with virtual memory / MMU support
2024-03-16 13:25:09 <veltas      > Which you are if you're on 64-bit, I don't think there's a lot of 64-bit MCU's
2024-03-16 13:26:45 <GeDaMo      > Yeah, I was wondering if there were any 64 bit systems that didn't have virtual memory :P
2024-03-16 13:27:42 <veltas      > There are plenty of 32-bit MCU's without virtual memory where I'd probably prefer to limit to 16-bit addresses, and where an offset would be necessary
2024-03-16 13:28:00 <veltas      > But embedded work I feel more comfortable being very 'custom' anyway
2024-03-16 13:28:17 <veltas      > virtual memory or MMU
2024-03-16 17:50:03 <zelgomer    > veltas: fwiw you can compile 16-bit threading and keep your cell size 4 or 8 without much difficulty on x86
2024-03-16 17:51:45 <zelgomer    > just keep your code segment 64k-aligned, and limited to 64k in size obviously. you can preload your IP register with the base address and then load the bottom 16 bits without affecting the top 48
2024-03-16 17:52:59 <zelgomer    > for example, your NEXT can be just  lods %al; jmp *%rax
2024-03-16 17:54:31 <zelgomer    > misleading comment earlier. in that case rsi is your IP and rax is just a jump register that needs to be preloaded with the high 48 bits of rsi and never clobbered, but you get the idea
2024-03-16 18:59:29 <MrMobius    > you could use a 32 bit stack and store 64 bit addresses in two pieces
2024-03-16 18:59:58 <MrMobius    > and redefine a few words to match like CELLS+ instead of CELLS then +
2024-03-16 19:52:43 <zelgomer    > i've thought of the 4-byte cell x86-64 forth, too, but haven't actually tried it yet. in some ways this is closer to what i think amd imagined, and it's reflected in c
2024-03-16 20:20:42 <MrMobius    > how do you mean?
2024-03-16 20:24:06 <zelgomer    > if you look at how amd64 extends the isa, and what instructions do by default sans prefixes, they clearly imagined for most data to still be 4 bytes. all of the movs, arithmetic, etc. instructions operate on dwords by default, but addressing and push/pop (which often push/pop addresses) are quadwords by default.
2024-03-16 20:24:50 <zelgomer    > and by "reflected in c" i mean that most (maybe every? idk) x86 c compiler, when targetting x86-64, keeps ints at dword size, but pointers and size_ts are quads
2024-03-16 20:29:28 <zelgomer    > the question is how do you deal with this in c? ironically, there is no 32-bit push/pop, so if you insist on a 32-bit stack then you're forced to either waste 100% of the space or manage the stack with subs and movs. you could just concede you have a 64-bit stack, but @/!/, only fetch/store/write the bottom four bytes, and then you have some weird thing where 2@ actually winds up occupying a single stack
2024-03-16 20:29:33 <zelgomer    > cell
2024-03-16 20:29:37 <zelgomer    > er... not in c, i mean in forth
2024-03-16 21:53:00 <skvery      > Forth has two stacks.  One tha size of the native accumulator and the other the size of the native addres space.
2024-03-16 21:58:00 <zelgomer    > but if the parameter stack is smaller than the return stack, then >r is broken