2023-12-10 01:06:36 zelgomer: I wrote up a 1-2 kb of source that will do all the 64-bit binary operations, including the moves. Supports reg/reg and indirect with and without offsets. I have no idea how to verify it, though. Everything I checked (just a random sampling) was encoded correctly. 2023-12-10 01:10:35 It's here if you're interested: 2023-12-10 01:10:37 https://pastebin.com/Fn1U77Mt 2023-12-10 01:11:09 A handful of unary operations too, but I was just starting those when I set it aside for a while. 2023-12-10 02:23:59 KipIngram: thanks. i'm verifying mine by assembling all of the permutations with gas, then with mine, and then use objdump to disassemble and diff 2023-12-10 02:26:28 i have all of the add, sub, and, xor, etc. group working, all register sizes and addressing modes. well, except for indirect through rbp and the SIB byte because i broke those refactoring something 2023-12-10 03:07:55 RSP and RBP are exceptional someone. I don't know exactly a "textbook" way of describing it, but there's a difference in those patterns. 2023-12-10 03:08:09 Wait, I'm sorry. 2023-12-10 03:08:14 Not RBP and RSP. 2023-12-10 03:08:25 rsp and the r8-r15 equivlaent one. r13 I think. 2023-12-10 03:30:32 yeah. and it's r12 2023-12-10 03:31:20 and then there's bullshit with the new 8-bit regs spl bpl sil and dil 2023-12-10 03:32:22 they correspond to ah, ch, dh, and bh but with a rex prefix, so there's no way to address the *h registers and spl/bpl/sil/dil in the same instruction 2023-12-10 03:34:47 and then there are special case instructions when src is immediate value and dest is al or *ax, but they don't apply to r8b/r8w/r8d/r8 2023-12-10 03:35:05 for some reason i can't fathome 2023-12-10 03:36:04 at least gas and objdump didn't recognize them. i didn't actually try to execute it to see what it does. probably causes my cpu to explodw 2023-12-10 05:12:38 That sounds so trying. :-| 2023-12-10 05:13:14 I am primarily interested in the instructions I need for writing "most of" a Forth. That is, I don't mind poking bytes for a few primitives. I just don't want to have to do it for all of them. 2023-12-10 05:13:25 So i might be able to avoid the 16-bit and 8-bit variants. 2023-12-10 05:16:10 Also, in a lot of his chips Chuck doesn't even offer less than cell access. If you need that you shift and mask. He probably sees it as a) simplifying the hardware and b) encouraging us to write the most performant algorithms. Just design your application so you don't need to do extensive 8/16 bit accesses. But if you're working with an x86, it's a shame to not take advantage of the capabilities when 2023-12-10 05:16:12 they're RIGHT THERE. 2023-12-10 17:05:08 The idea of having to create and validate a full x86 assembler gives me as much heartburn as you alluded to up there. 2023-12-10 17:05:16 I won't be trying to pull that off. 2023-12-10 17:05:50 If you manage it then kudos to your determination. 2023-12-10 17:08:27 lol. like i said, i don't plan to do every instruction. but of those i use, i want to be confident it's right. it's hard enough to debug some of this stuff without also questioning whether your instructions are even encoded right 2023-12-10 17:08:45 That's for sure. 2023-12-10 17:10:32 I have as a goal to write this "emulator/generator" such that as I add each new bit to the system then from there on out that bit will actually operate - that function will no longer be emulated but will be handled by the "final real deal." That way it comes on line in tiny bits so I can troubleshoot each one at the time I deploy it. 2023-12-10 17:10:38 "x86 is an octal machine" https://gist.github.com/seanjensengrey/f971c20d05d4d0efc0781f2f3c0353da 2023-12-10 17:11:17 That's not really a full validation, though; I'd only be validating the particular use cases that ongoing system development called upon. So it's less than perfect, but it seems a lot better than trying to write the whole thing and then have to figure out where it's not working. 2023-12-10 17:12:43 The "assembler" will be used only to write the actually vm instruction bits. So those will all be initially emulated with lines of C, and the C will get replaced one bit at a time as I produce the implementation for each instruction. 2023-12-10 17:13:15 So at least if I do an iteration of that and it breaks things, I'll know exactly what to go look at. 2023-12-10 17:13:58 The framework for that is going to be a little hoop-jumpy, since the C emulator will hold stuff in variables that the final vm will hold in registers. 2023-12-10 17:14:29 So when a new vm implemenation gets installed, there will have to be some framework that moves those variables into registers, runs the new code, an then moves the values back into the variables. 2023-12-10 17:14:48 During that phase it sure won't win any performance races. 2023-12-10 17:15:08 geez. this is sounding eerily close to where i got lost in the weeds and finally had to put forth down and see sunlight again years ago 2023-12-10 17:15:33 Uh oh. Well, I may find myself in the same experience then. 2023-12-10 17:15:38 lol 2023-12-10 17:15:40 It's what I'm going to TRY to do at least. 2023-12-10 17:16:24 I've wanted a system that can rebuild itself for years, but one time after another I've written a system that works really well, but then never pulled off the final step to making it able to rebuild. 2023-12-10 17:16:35 So this time I'm going to try to create it that way right from the start. 2023-12-10 17:17:12 this time around i'm trying to keep myself grounded to avoid that rabbit hole. think of forth on my pc as an interpreter, nothing more. in that interpreter, implement a cross assembler with macros, nothing more. then start actually targetting microcontrollers and doing real work 2023-12-10 17:20:38 i keep having ideas in the shower about how i might compile to native code, but i keep having to remind myself that is not in scope for what i want to do right now. that's a distraction, just let it go! 2023-12-10 17:21:39 A goal here will be that once I have it done, I'll only need to replace the "vm layer" to move it to another platform. I want the non-vm portion to be binary portable across platforms. Cell size and endien type may be issues there; I'll have to see how all that looks as I get into it. 2023-12-10 17:21:44 this is why forth is so challenging to me. it causes my imagination to go crazy and it's so easy to veer off target 2023-12-10 17:22:23 you can definitely get onto slippery slopes with this stuff. 2023-12-10 17:22:41 try turning off the targetting computer? 2023-12-10 17:22:42 when i'm writing c, the boundaries are well defined and i can clearly see the end product from the start 2023-12-10 17:23:00 and use the forth? 2023-12-10 17:25:38 KipIngram: i think when i was considering a "vm layer" type of thing before, my plan was for the vm's cell size to be 64 bit, the largest i'd ever want. anything smaller woyld have to emulate it. like you said, wouldn't win any races, but that's not what that layer is for 2023-12-10 17:26:28 forth is probably closer to free verse unlike a stricter poetic form 2023-12-10 17:36:20 zelgomer: Yes, that would certainly be a way around the cell size issue. And I really do like what I can do with 64 bit. My only heartburn about that is that the platform I have my eye on for any future hardware projects I undertake (MAX32655) is 32-bit, and I'd at least like to have a native system for that platform. 2023-12-10 17:36:28 That's all still fuzzy right now, though. 2023-12-10 17:37:10 I think what you just said is a sound way through it, though. 2023-12-10 17:38:07 Especially since I want the gadget side system to be able to communicate with threads on my notebook side system the same way it communicates with other threads on the gadget. 2023-12-10 17:38:28 I.e., where threads happen to be running should be transparent at the application level. 2023-12-10 17:39:08 I guess that's somewhat above the vm level, though. 2023-12-10 17:50:32 One problem I might run into with emulating a 64-bit system on a 32-bit system is register availability. I'd need two registers instead of one to cache tos, and in this one I'm also planning to cache top of return stack. I'm not sure I have two surplus registers lying around. 2023-12-10 17:53:51 IA-32 is somewhat register starved 2023-12-10 17:54:16 Oh yes. I just couldn't implement my preferred design with only eight registers to work with. 2023-12-10 17:54:27 Well, I could, but it would be slow by comparison. 2023-12-10 17:54:40 Can't implement it "right." 2023-12-10 17:55:33 I was initially bothered by having so many registers active, because I'd viewed Forth as supporting "very fast context switching." But these days my attitude is "they exist as resources - better to make use of them than largely leave them idle." 2023-12-10 17:56:12 Since I didn't use them "just to be using them" - each new register brought into play was in service of some feature I wanted.