2023-12-10 11:05:08 <KipIngram   > 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 11:05:16 <KipIngram   > I won't be trying to pull that off.
2023-12-10 11:05:50 <KipIngram   > If you manage it then kudos to your determination.
2023-12-10 11:08:27 <zelgomer    > 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 11:08:45 <KipIngram   > That's for sure.
2023-12-10 11:10:32 <KipIngram   > 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 11:10:38 <GeDaMo      > "x86 is an octal machine" https://gist.github.com/seanjensengrey/f971c20d05d4d0efc0781f2f3c0353da
2023-12-10 11:11:17 <KipIngram   > 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 11:12:43 <KipIngram   > 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 11:13:15 <KipIngram   > 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 11:13:58 <KipIngram   > 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 11:14:29 <KipIngram   > 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 11:14:48 <KipIngram   > During that phase it sure won't win any performance races.
2023-12-10 11:15:08 <zelgomer    > 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 11:15:33 <KipIngram   > Uh oh.  Well, I may find myself in the same experience then.
2023-12-10 11:15:38 <zelgomer    > lol
2023-12-10 11:15:40 <KipIngram   > It's what I'm going to TRY to do at least.
2023-12-10 11:16:24 <KipIngram   > 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 11:16:35 <KipIngram   > So this time I'm going to try to create it that way right from the start.
2023-12-10 11:17:12 <zelgomer    > 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 11:20:38 <zelgomer    > 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 11:21:39 <KipIngram   > 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 11:21:44 <zelgomer    > 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 11:22:23 <KipIngram   > you can definitely get onto slippery slopes with this stuff.
2023-12-10 11:22:41 <thrig       > try turning off the targetting computer?
2023-12-10 11:22:42 <zelgomer    > when i'm writing c, the boundaries are well defined and i can clearly see the end product from the start
2023-12-10 11:23:00 <zelgomer    > and use the forth?
2023-12-10 11:25:38 <zelgomer    > 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 11:26:28 <thrig       > forth is probably closer to free verse unlike a stricter poetic form
2023-12-10 11:36:20 <KipIngram   > 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 11:36:28 <KipIngram   > That's all still fuzzy right now, though.
2023-12-10 11:37:10 <KipIngram   > I think what you just said is a sound way through it, though.
2023-12-10 11:38:07 <KipIngram   > 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 11:38:28 <KipIngram   > I.e., where threads happen to be running should be transparent at the application level.
2023-12-10 11:39:08 <KipIngram   > I guess that's somewhat above the vm level, though.
2023-12-10 11:50:32 <KipIngram   > 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 11:53:51 <thrig       > IA-32 is somewhat register starved
2023-12-10 11:54:16 <KipIngram   > Oh yes.  I just couldn't implement my preferred design with only eight registers to work with.
2023-12-10 11:54:27 <KipIngram   > Well, I could, but it would be slow by comparison.
2023-12-10 11:54:40 <KipIngram   > Can't implement it "right."
2023-12-10 11:55:33 <KipIngram   > 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 11:56:12 <KipIngram   > 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.
2023-12-10 19:23:05 <zelgomer    > i just realized something about x86 that never occurred to me before. push/pop are the only instructions that can move data between two memory locations without going through a register. i wonder how this can be exploited?
2023-12-10 21:02:18 <KipIngram   > Wait - you can push memory  locations?  That never even occurred to me.
2023-12-10 21:02:52 <KipIngram   > but the MOVS instructions can do that as well.
2023-12-10 21:03:17 <KipIngram   > They move from [si] to [di] with increment in either direction.  And you can put the rep prefix on them.
2023-12-10 21:05:04 <thrig       > it's strcpy Jim but not as we know it
2023-12-10 21:30:06 <zelgomer    > oh yeah movs
2023-12-10 21:32:38 <zelgomer    > get your movs on