2026-02-14 01:29:12 It seems that earlier ESP32's only allowed instruction execution from a subset of the RAM - ChatGPT keeps falling into that idea on the C6. But I don't see ANY indication of that in the technical reference, and if I point thta out to the AI it will then agree with me (though that doesn't necessarily mean anything with that thing). 2026-02-14 01:29:20 But as far as I can tell you can execute anywhere in RAM. 2026-02-14 01:29:51 There is a protection setup, though, so you can define domains that will limit permissions. It looks like the start-up default is that the high power cpu has all permissions on all of RAM, though. 2026-02-14 01:44:03 This is all it took to get an "echo application": 2026-02-14 01:44:06 https://pastebin.com/knxUMtY2 2026-02-14 03:35:58 should i implemnent 'reset' and 'cold' ? 2026-02-14 03:59:47 I like to, but we may be back again to that "low level me" and "higher level you." :-) 2026-02-14 04:00:32 What I usually do in my system is start out by allocating a RAM block and then copy the loaded code up into that RAM block to run. So the loaded block remains unchanged. So cold is easy - I just re-copy the loaded code. 2026-02-14 04:01:30 I usually have QUIT clear the return stack and enter the interpreter loop, WARM clears the data stack and enters QUIT, and COLD re-launches everything. 2026-02-14 04:02:07 I don't do reset, though - what does it normally do? 2026-02-14 04:14:00 KipIngram, in embedded mcu's a reset guarantees a default configuration of all peripherals 2026-02-14 04:14:58 I always reset my mcu after every upload test as I dont want any strange states lingering that can really confuse things 2026-02-14 04:27:09 Right, I know re: hardware, but rendar said a day or two ago his system is some higher level thing. 2026-02-14 04:27:31 I just wondered what it would do in a system such as his, that would be different from cold. 2026-02-14 04:32:24 ahh, oops, apologies then 2026-02-14 04:46:24 what would be the best way of doing BRANCH and 0BRANCH on STC? my best idea is compiling a `jmp` instrtuction and then pasting in a relative jump later, but maybe there's an easier way i'm not thinking of? 2026-02-14 04:46:53 (pasting in the appropriate relative jump *into* the jmp instruction) 2026-02-14 05:18:36 nepeta: Yes, exactly. Not unlike "" is "". 2026-02-14 05:19:36 More clearly: that is exactly what the Word ""is""... is in STC. 2026-02-14 05:22:40 ""AMD64.jz is FORTH.0branch"" ;). Do We need to repeat the mistakes? 2026-02-14 05:28:56 nepeta: If it's a forward jump, you don't know yet where it's going. So you compile the jump opcode but leave the target vacant (just make space for it) and leave the address of that space on the stack. Then later when you figure out the target, you get that address off the stack and patch the value in. 2026-02-14 05:29:32 If it's a backward jump, you've left the target address on the stack, and when it comes time to compile the jump, you grab the target off the stack. 2026-02-14 05:38:54 Executing, and therefore compiling an undefined Factor that can be resolved later is a very reasonable choice. 2026-02-14 05:39:57 Common Lisp Condition System!? 2026-02-14 06:26:41 KipIngram: Re C6 http://pb1n.de/?ea7dd2 . I hope it helps somehow. 2026-02-14 12:08:44 Thanks. I think it's true that esptool.py can "copy directly to RAM" (I think it's how they get their "stub" over there for execution in esptool itself) but apparently the bundle delivered has to be specially formatted, and I don't have my hands on an easy way to do that. 2026-02-14 12:09:13 I'm pretty happy with what I've worked up now, though - or am in the process of working up. 2026-02-14 12:11:14 Workflow wise, I think my process will be a) create my machine code however I do it (toolchain, Python generator, whatever), b) run a bash "upload" script I'll write on it, which will deliver it into a buffer in the C program running on the ESP, and c) via picocom just issue a "go" command - the C code will do a function call to the code in the buffer. 2026-02-14 12:11:50 If that code actually works and returns properly, then my little environment will still be running - otherwise I'll have to reset the ESP and start over. 2026-02-14 12:12:20 That might require restarting picocom, but I don't know yet. 2026-02-14 12:14:46 Oh, by the way, in the C version of the "led blink" program, there were three calls to library routines - one to init the GPIO pin, one to set it as an output, and then one in the loop to toggle it. I was able to replace the one in the loop with a direct RAM operation (no library call) and the thing still blinked. So that confirms that I know where the hardware is in the address space. I haven't 2026-02-14 12:14:48 yet tried to replace the calls outside the loop. 2026-02-14 12:27:19 I assume that when I use a "pointer to function" feature to transfer control to the buffer code, a standard C calling convention process will be run. So to get back I think all I will need is to make sure my code does a correct "C return." And of course I could return a value if I write the code right, so there will be some pretty straightforward testing I can do. 2026-02-14 12:28:34 If I make my entry and exit code load and save the processor registers properly, and put some commands in the C to inspect the buffer and so on, I should be able to use this setup to actually test the vm as it comes together.