@clacke A hardware-level fix for this would double the burden on the MMU, which would slow the instruction execution rate appreciably. This is the problem with super-long pipelines, and why you should never have a CPU with a pipeline longer than, say, 10 stages. And that's being generous; I *actually* can't see any reason for anything longer than 6.

Compatibility between ISAs isn't guaranteed due to the different register sizes; however, if you're clever with your coding, you can write multi-ISA code.

Cross-width compatibility isn't a priority, though, as history shows to make a cross-width-compatible ISA, you need a lot of complex mechanisms in the hardware (defeating its RISC-y nature). It's expected the compiler will paper over the differences.

Note that x86-64 is also not compatible with x86-32. :) Not even x86 is immune.

After looking up several BNFs for Smalltalk, I have only this comment to make about the language:

Though it only has 5 (originally 6) keywords and arguably one of the simplest syntaxes of any programming language out there, all the BNFs for it are (so far as I've seen to date) consistently larger than Oberon's by a non-trivial amount.

@clacke @Kooda

Thanks for the mention! My progress is very slow now that I'm working again, but I'm slowly working towards a new design for my #riscv CPU. I also have designed the S16X4-family of CPUs, all derivates of the Steamer-16 MISC CPU.

@clacke @clacke I'm actually considering the possibility of rebuilding all of my software for a stack-architecture CPU again, leaving the RISC-V engine as a coprocessor.

My KCP53000 CPU is very slow, very large, and while it *works*, it doesn't even qualify as a microcontroller by today's standards. About same perf as a 68000 in 1985.

A MISC CPU is both smaller and faster.

@clacke I've heard of it, but it doesn't look like it's nearly as easy to port as Shen. Shen is like Forth, in that it builds on top of a very small kernel of primitives and semantics. This appeals to me for its simplicity.

Plus, it's optionally statically typed! This is wonderful news, since you can apply strong typing where it makes sense, and rely on dynamic typing everywhere else.

If you want more information, I have the main project site at https://kestrelcomputer.github.io/kestrel (which links to its Github page). I also have a project page on Hackaday.io as well (https://hackaday.io/project/10035-kestrel-computer-project). @clacke

@clacke Answering your question of what the Kestrel project is.

Kestrel is my attempt to build a completely open-source (to the maximum extent I can afford) home computer design. Imagine a 64-bit Commodore 64, where you can plug in a monitor, a keyboard, and a power source, turn it on, and just start hacking right away.

This will require making my Forth dialect properly ANSI compatible, to the greatest extent that I can make it. Not hard to do; just an extra checkbox to tick off.

Yes, I'm thinking that the right steps forward for the Kestrel project is to definitely develop Forth for it, beyond the current eForth implementation, and then port Shen Lisp to run on top of Forth.

Then, from there, build much of everything else I need. Low-level code uses Forth, high-level uses Lisp. [Alternate hard and soft layers](http://wiki.c2.com/?AlternateHardAndSoftLayers) to build the total stack. Best of both worlds.

@djsundog @sarahjeong Her description of how federation works (vis a vis relationships between administrators of different sites) is *exactly* how BBS store-and-forward "networking" back in the 80s worked. Absolutely. No. Difference.

And that's a good thing, in my eyes; it opens the possibility of folks running RA on FidoNet, Citadel, or some other BBS but with Mastodon gateways. In fact, this'd be a *natural* for Citadel.