2023-06-15 08:02:22 <veltas      > KipIngram: Yeah after doing that you might appreciate why I stopped using rbp for data stack register for amd64 ilo
2023-06-15 08:59:56 <KipIngram   > Yeah.  It's a nuisance, and the instructions are also bigger.
2023-06-15 09:01:32 <KipIngram   > I use rbp as my "exception" register - You know I have that {| ... |} mechanism that will let me return from deep code.  rbp holds a value that helps me implement that.  I call it the "exception pointer."
2023-06-15 09:01:51 <KipIngram   > Works like so:
2023-06-15 09:02:02 <KipIngram   > : foo ... {| ... |} ;
2023-06-15 09:02:05 <KipIngram   > ...code...
2023-06-15 09:02:07 <KipIngram   > ...code...
2023-06-15 09:02:17 <KipIngram   > : bar ... |} ;
2023-06-15 09:02:46 <KipIngram   > If bar executes that |}, then the ; following returns us FROM FOO.
2023-06-15 09:02:59 <KipIngram   > Doesn't matter how much intervening code there is.
2023-06-15 09:03:33 <KipIngram   > Obviously that deep |} is likely to be conditional - I use it in my FIND and the deep |} gets executed if I get a name match.
2023-06-15 09:05:52 <KipIngram   > Anyway, the point here is that it's a rarely used feature, so I "don't use rbp very much."
2023-06-15 09:06:07 <KipIngram   > It was the last register I pressed into service.
2023-06-15 09:07:11 <KipIngram   > |} doesn't transfer control immediately - it just adusts the stacks.  So the ; in bar still executes.  It's just that when it does the return stack is in the state you'd expect for the ; in foo.
2023-06-15 09:50:41 <KipIngram   > If there was code between |} and ; in foo, it would execute normally if I returned to foo and executed the |} there, but if the |} down in bar executes, we would not execute the post |} code in foo.
2023-06-15 09:51:29 <KipIngram   > I guess the short way of saying that is to say that |} affects RP but doesn't affect IP.
2023-06-15 09:52:21 <KipIngram   > |} restores both IP and SP to the state they had at {|
2023-06-15 09:52:33 <KipIngram   > It doesn't change TOS, though.
2023-06-15 09:52:46 <KipIngram   > That's how a result come up from the deep code.
2023-06-15 09:53:02 <KipIngram   > In the case of FIND, that's the CFA of the sought for word.
2023-06-15 10:21:18 <KipIngram   > So as far as "frames" go I have four words: { } {| |}
2023-06-15 10:22:14 <KipIngram   > { does FP->return stack, SP->FP.  <n> } does FP->SP, return stack -> FP, drop <n> data stack items.
2023-06-15 10:23:10 <KipIngram   > {| and |} do similar, except return stack gets saved/restored as well and |} doesn't do the "additional item dropping."
2023-06-15 10:30:59 <KipIngram   > I think I'm going to write my assembly stuff so that it uses its own set of pointers to keep track of where it's putting things.  That covers the "creating new targets" situation.  Then, to use the tools in my running system, I'll wrap that in a wrapper that copies the system's state variables into the assembler's state, runs the assembly, and then copies the assembler state back to the system state.
2023-06-15 10:31:08 <KipIngram   > Then I can use the stuff for either purpose.
2023-06-15 10:31:29 <KipIngram   > Slightly clunky, but I guess those operations have to be done somehow.
2023-06-15 10:32:59 <KipIngram   > sys{ ...assembly... }sys would get that job done.
2023-06-15 10:49:39 <KipIngram   > Meanwhile, for tinkering around, I can just point the assembler state at some blocks and assemble.  Call into it to test things.