2022-07-08 10:57:26 <KipIngram   > That makes sense.  Mine is set up so that the stored form of the system consists of a pair of data blocks - I think I can put those anywhere I like, point a register to each one of them, and jump to the start point; it should run.
2022-07-08 10:57:46 <KipIngram   > All the variables and so on would have whatever value they had when the blocks were saved.
2022-07-08 10:58:08 <KipIngram   > I'd have to do more to have the stacks start up in a non-empty state.
2022-07-08 11:02:32 <KipIngram   > Right now it loads from the ELF, but I copy those two ranges into an allocated block of RAM, set the registers, and then jump into that block.
2022-07-08 11:02:57 <KipIngram   > I basically abandon the ELF-loaded stuff, though I do use it for COLD; make a new copy and start over.
2022-07-08 11:06:32 <KipIngram   > The ELF load has some code at the end that's used for initialization, but isn't copied to the allocated region.  The dictionary expands into the region it would have occupied into the copy.  But of course it's still present in the ELF loaded region, for when it's re-used by COLD.
2022-07-08 11:07:04 <KipIngram   > If I want COLD in a future gadget deployment, I'll have to change that; there won't be a second copy of things lying around in that case.
2022-07-08 11:08:30 <KipIngram   > The ELF-loaded stuff never has its permissions changed, so at least the .text section part of it is guaranteed unwritable.
2022-07-08 11:16:22 <KipIngram   > Our conversation here the last few days has got me thinking, though, that there are two things involved here - there's "the system," and there's the stuff that interacts with me via the console.  In future applications I'm going to want those fairly well split; host handling the latter and gadget handling the former.  Right now, though, they're kind of intermingled with each other.  :-(
2022-07-08 11:17:10 <KipIngram   > I could see that boundary being either ine-oriented or character oriented - the way the system works right now is more character oriented.
2022-07-08 11:18:04 <KipIngram   > I feel like that's *probably* what I want, but I'm not 100% sure.
2022-07-08 11:18:44 <KipIngram   > That's kind of the whole purpose of the ANSI stuff - to allow that sort of terminal control to be projected from a remote system.
2022-07-08 11:19:19 <KipIngram   > But EXPECT is big and complex, and that structure does mean it's "on the gadget."
2022-07-08 11:19:46 <KipIngram   > Maybe I need to try to think in terms of having a Forth on both sides, with a more easily movable boundary.
2022-07-08 11:23:23 <KipIngram   > Hey, here's a thought.  What if an address range on the host was mapped to a RAM range on the gadget?  You access one of those addresses, and the os throws a fault.  You intercept that and do whatever you need to do to bring about the right result on the gadget.
2022-07-08 11:23:37 <KipIngram   > Then EXPECT could run on the host, but deliver the string to a  TIB on the gadget.
2022-07-08 11:23:55 <KipIngram   > That's probably all kinds of flaky.
2022-07-08 14:17:37 <KipIngram   > Hey, what was the system we discussed a few days ago?  I think it was for an MSP430 tethered; the Forth ran on a host and delivered a small binary to the micro when you were ready for it to?
2022-07-08 14:18:02 <KipIngram   > And otherwise kind of emulated things?
2022-07-08 14:18:38 <KipIngram   > Or not really emulated - sounded it like it managed the micro's address space remotely until you downloaded the code.
2022-07-08 14:24:15 <lispmacs[work]> KipIngram: Mecrisp-Across
2022-07-08 14:24:45 <lispmacs[work]> https://mecrisp-across-folkdoc.sourceforge.io/
2022-07-08 14:25:21 <KipIngram   > Yes - thanks.
2022-07-08 14:25:44 <KipIngram   > I'm thinking about all this tethered stuff now, and that seemed like a pretty good way to set things up.  Definitely worth being familiar with.
2022-07-08 14:26:21 <KipIngram   > I'm bracing myself up for another round of work on mind, and I want to do what I can to have good ideas in mind BEFORE I do the work instead of after.
2022-07-08 14:26:41 <KipIngram   > I have pretty much zero shame about stealing good ideas.  :-)
2022-07-08 14:26:56 <KipIngram   > After all, most of how my system works came from a book anyway.
2022-07-08 14:27:13 <KipIngram   > My very first solo venture into Forth building was pretty abysmal, which I discovered when I found that book.
2022-07-08 14:27:29 <KipIngram   > god that was a long time ago.
2022-07-08 14:27:37 <KipIngram   > Getting close to 40 years.
2022-07-08 14:30:43 <KipIngram   > It had all the behaviors it was supposed to have, but it was about 10x too complicated under the hood.
2022-07-08 14:31:07 <KipIngram   > Well, maybe not 10; maybe 3-5.  But... after I read the book it was ugly to me.
2022-07-08 14:56:19 <KipIngram   > Does mecrisp-across offer host-side Forth functionality as well?  So that you could make definitions on the host to exercise the client in various ways and so on (test harness)?
2022-07-08 14:57:06 <KipIngram   > And if it does, does it somehow know whether words like @ or ! should apply to a host address or a target address?
2022-07-08 14:58:07 <KipIngram   > Better way to say that - are there stacks on host and target, and if so, how do words know which one to use?
2022-07-08 14:58:54 <KipIngram   > I could imagine it being ONLY a target access system that keeps the bulk of the overhead (dictionary and so on) on the host.
2022-07-08 15:09:12 <lispmacs[work]> KipIngram: I think this is the page you are looking for: https://mecrisp-across-folkdoc.sourceforge.io/how-mecrisp-across-works.html#ma-how-work
2022-07-08 15:09:39 <lispmacs[work]> I think the host is another MC with same architecture
2022-07-08 15:09:43 <KipIngram   > Oh, thank you.  I was on the site but on a different page.
2022-07-08 15:10:09 <KipIngram   > Got a dental appt in a few minutes (hell of a way to spend an afternoon of vacation...), but I will digest that later.
2022-07-08 15:10:37 <lispmacs[work]> host controls target over JTAG
2022-07-08 15:10:52 <KipIngram   > Right - I'd caught that part.  Holds it in reset most of the time.
2022-07-08 15:11:29 <KipIngram   > I'm kind of pondering here how, in a dual-platform tethered system, you could most easily issue a word stream that could effect either side.
2022-07-08 15:11:40 <KipIngram   > Without things getting terribly "long-winded."
2022-07-08 15:12:02 <KipIngram   > A nice clean way to specify "who I'm talking to" at the moment.
2022-07-08 15:12:17 <KipIngram   > Seems like a mode of some kind would be called for, but I don't want to rush into that idea.
2022-07-08 15:12:31 <KipIngram   > Words that you've actually *defined* for one side or the other are no problem.
2022-07-08 15:12:54 <KipIngram   > But it seems like there are some common Forth words that might apply to either (things like @ and !).
2022-07-08 15:14:39 <KipIngram   > I guess Chuck would say use color.  :-)
2022-07-08 15:14:53 <KipIngram   > And that does actually seem like a sensible application for it.
2022-07-08 15:16:20 <KipIngram   > And very tidy, in terms of source appearance.
2022-07-08 17:42:32 <KipIngram   > Ok, survived that.
2022-07-08 17:42:39 <KipIngram   > Even the shots weren't bad today.
2022-07-08 18:07:14 <KipIngram   > lispmacs[work]: That page still leave some questions.  The part about how the target is managed is clear.  But the Forth that's running on the Cortex host - I assume it's a full Forth.  So does the system just have separate words for the target and the host?
2022-07-08 18:07:51 <KipIngram   > Say, different names for host @ vs. target @?
2022-07-08 18:08:08 <lispmacs[work]> hmm... let me look at... THE SOURCE!
2022-07-08 18:08:18 <KipIngram   > :-)
2022-07-08 18:08:47 <KipIngram   > That seems like it would be the simplest way - as usual in Forth.  One word does one thing.
2022-07-08 18:09:13 <thrig       > STATE-aware words aside
2022-07-08 18:09:17 <KipIngram   > But it does mean you have two dialects to remember to use.
2022-07-08 18:09:20 <KipIngram   > Right - that aside.
2022-07-08 18:09:30 <KipIngram   > And the . dependence on BASE.
2022-07-08 18:09:39 <KipIngram   > Thought I guess that's still one thing.
2022-07-08 18:10:43 <KipIngram   > Oh, by the way, I mentioned the other day that large matrix of conditional returns and recurses I have.  Well, in a fully standard Forth system, every one of those conditional recursion words, since they become a jump, would have to be immediate and have run-time counterparts.
2022-07-08 18:11:02 <KipIngram   > I dodged that by making the compiler a hair more powerful and designating those words with a bit in the header.
2022-07-08 18:11:18 <KipIngram   > If that bit is set, then when the word is compiled it's followed by an offset back to the beginning of the word.
2022-07-08 18:11:38 <lispmacs[work]> so, looks like there are words "host" and "target" for switching back and forth
2022-07-08 18:11:47 <KipIngram   > Ok, so a mode gets set.
2022-07-08 18:12:04 <KipIngram   > And I assume it would just be checked at compile time and not run-time.
2022-07-08 18:12:28 <KipIngram   > That would be the "second simplest way" to handle it, I think.
2022-07-08 18:12:46 <KipIngram   > And you'd just live with the ugly of all those "host" and "target" instances cluttering up your source.
2022-07-08 18:13:09 <KipIngram   > Sort of like choosing a vocabulary.
2022-07-08 18:13:18 <KipIngram   > In fact, you could DO it with vocabularies.
2022-07-08 18:13:19 <thrig       > yeah two vocabs could help there
2022-07-08 18:13:25 <KipIngram   > ^ :-)
2022-07-08 18:13:28 <KipIngram   > Great minds...
2022-07-08 18:13:54 <KipIngram   > Say, are vocabulary words usually immediate or not?
2022-07-08 18:14:17 <KipIngram   > I think I'd lean toward yes, but I don't really  know what's done "in the world."
2022-07-08 18:14:51 <KipIngram   > I usually don't use them enough for it to really matter that much, but this case might call for them to be used quite a bit sometimes.
2022-07-08 18:16:00 <lispmacs[work]> KipIngram: here is a snippet from the README: https://bpa.st/5WQQ
2022-07-08 18:22:06 <KipIngram   > Yeah, it's pretty clear now.
2022-07-08 18:22:41 <KipIngram   > It's really a brilliant approach for micros - from blank chip to working prototype; bam.
2022-07-08 19:12:23 <KipIngram   > I assume you could probably use the same idea for larger, more competent targets by having pre-built "starting images" that comprised the base system.  Load one up into the target image buffer, then extend it and burn it exactly as outlined in that README.
2022-07-08 19:12:55 <KipIngram   > And whether or not there was a dictionary resident on the target could be optional -  nothing would stop you from having that information there as well.
2022-07-08 19:13:03 <thrig       > the sticky wicket being that folks don't really read the README
2022-07-08 19:13:20 <KipIngram   > Then you've got one methodology that covers all the bases.