2023-07-16 09:58:14 <KipIngram   > Yes, it has A and B registers as well, and they also support a slate of addressing operations.
2023-07-16 10:32:57 <KipIngram   > I'm still liking the idea of an F18A "inspired" architecture.
2023-07-16 10:33:52 <KipIngram   > Did some timing tests this morning - that code to peel off the next opcode and make it a table offset looks to take way under a nanosecond on average.
2023-07-16 10:34:14 <KipIngram   > The time doing that would more or less vanish compared to the time the jump through the table took.
2023-07-16 10:35:03 <KipIngram   > I would use six bit opcodes, though.
2023-07-16 10:38:47 <KipIngram   > The compiler would be a bit fancy, since it would need to figure out how to fit jump and call offsets into the words optimally.
2023-07-16 10:39:45 <KipIngram   > It's a fairly simple thing, though - just say "can I reach where I need to reach with the remainder of this cell?  If not, then go on to the next cell early.
2023-07-16 11:17:03 <KipIngram   > If I do wind up doing an F18A-modeled design, a big decision would be whether to circularize the stacks or not.  There are some nice aspects to that even in a software system - it would completely eliminate the possibility of stack overflow.  And I've measured how much stack I use in my current system - both of them come in somewhere around 17-18 entries, at most.  So 32-entry circular stacks should work
2023-07-16 11:17:04 <KipIngram   > fine.
2023-07-16 11:26:22 <KipIngram   > The main downside of it is that to implement it efficiently would require having stack pointers that were offsets from the task's base address.  So there would be some add instructions in there that would otherwise not be required.  Along with the masking to keep the pointers in their ranges.
2023-07-16 12:02:03 <KipIngram   > Regarding multi-threading, I think in an F18A-based design the thread change check would be done when transitioning to the next 32-bit cell.
2023-07-16 12:02:16 <KipIngram   > So cells would run atomically.
2023-07-16 12:21:25 <KipIngram   > I think it would be interesting to try to do x64 and ARM implementations in parallel.  I've got platforms for both now.
2023-07-16 12:22:13 <thrig       > such a strategy would be without RISC
2023-07-16 12:22:28 <KipIngram   > Heh.
2023-07-16 12:22:51 <KipIngram   > I noticed that the F18A caches the top of the return stack as well as the data stack.
2023-07-16 12:23:02 <KipIngram   > Or, rather, he has a name for the top of return stack.
2023-07-16 12:23:21 <KipIngram   > And the descriptions read as though it's being thought of as a register.
2023-07-16 12:23:42 <KipIngram   > That makes his exec instruction RAM-free.
2023-07-16 12:23:47 <KipIngram   > He just swaps P and R.
2023-07-16 12:24:35 <KipIngram   > I'm inclined to follow his lead on instruction selection fairly closely, and then use the extra 32 instruction codes to extend in the ways I care about.
2023-07-16 13:59:57 <KipIngram   > You know, the F18A literal instruction is called @p.  Loads via P with auto-increment.  But I notice there isn't an @r - load via return address with auto-increment.  That seems like it would be useful too, for : defs with inline arguments.
2023-07-16 14:04:27 <KipIngram   > That would fit right in to things like builds: / does: and compile and so on.
2023-07-16 14:07:43 <KipIngram   > I suspect that some of the way that instruction set came down came from Chuck's careful pruning away of unnecessary stuff, but I'd bet that part of it was also getting down to 32 instructions so he could encode them in five bits.
2023-07-16 14:08:01 <KipIngram   > No swap?  No @r?  No nip or tuck?
2023-07-16 20:00:26 <crc         >  "a! >r a r>" or similar for swap (or just "over", if you didn't need anything below the two values; the circular stack makes this feasible)
2023-07-16 20:12:17 <Zarutian_iPad> crc: this being an F18 instruction?
2023-07-16 20:15:03 <crc         > yes