On Tue, Jun 17, 2025 at 9:02 AM Alex ... <abortretryf...@gmail.com> wrote:
> Hey John, > Okay, two ideas here... > First, as it stands now, MFORTH's neutered file access words are > read-only, but that seems more to do with the author's reluctance > <https://github.com/AbortRetryFail/MFORTH/blob/main/src/MFORTH/answords/file.asm#L446> > than any technical limitations of the machine. I don't think there's > anything stopping the user from using MFORTH to assemble machine code > somewhere in memory and then create a CO file to run it, but it doesn't > give you any tools to do so out of the box. > The second one, embedding MFORTH's interpreter? I have no idea how you'd > go about doing such a thing. Maybe it's possible, but I'm still puzzling > with how to translate DO...LEAVE...LOOP into the TASM macros. Pig iron, > rock, etc. :) > Yeah all that sounds major. Packaging just a launcher which depends on the MFORTH as a runtime seems much easier. My knowledge is mostly about pre-ANS forth. Changing where it compiles words would be a matter of changing HERE. So I guess you would decide where to locate the CO. Change HERE and interpret the program, all the words would go there. The work seems like the boilerplate entry and exit. So some assembly code to get from my CO program into the interpreter and into the "init" word for my program. And then some code for the exit to return to BASIC control. And of course ANS forth is not FIG forth so there's probably some learning to get the dictionary headers into my CO. Maybe, maybe not. Might be fun to feed MFORTH code and docs into Gemini and see if it's in the mood to write the entry/exit for me. I've played with AI stuff lately and have been able to make useful web utilities and even some embedded C code. But it's funny because sometimes Gemini whines. Like, "oh that is complicated I think we should leave it as it is" and refuses to do what I ask. -- John. >
