
The BSPL Compiler - supdog
http://sam-falvo.github.io/kestrel/2015/09/15/bspl-compiler/
======
nickpsecurity
"PowerPC, RISC-V, MIPS, SPARC, and other kinds of RISCy CPUs, however, don't
fare nearly as well. These CPUs provide primitives that are far too atomic,
and thus, to emulate a stack CPU, you literally need to translate each Machine
Forth primitive into a sequence of RISC instructions."

More evidence that maybe we should stop using Forth for this stuff. It's a
weird language we don't otherwise use that enforces a specific model that
majority of architectures don't even support. A simple, imperative language
with macro's and inline assembly should do just fine. Maybe time to dust-off
Modula-2 or something similar. It worked on constrained, diverse hardware.
Astrobe put Oberon on ARM microcontrollers and is porting it to RISC-V so I'm
sure it's doable.

~~~
kjs3
_Maybe time to dust-off Modula-2 or something similar. It worked on
constrained, diverse hardware._

Ada would like to have a word with you. :-)

~~~
nickpsecurity
She knows she and SPARK are how the real design would be done. Just got to map
it for production to something else majority are willing to work with,
optimize, and maintain. ;)

~~~
kjs3
True, but let's not try to go a bridge to far, there. Maybe when people stop
coming to me and insisting a couple of pages of notes is a "design document"
and we can't document because we're too busy coding and shoving it out the
door we can start the conversation about formal methods. This I've heard for
30 years, so not really holding out hope.

I just meant if you want to start the baby-steps getting folks moving in the
right direction you don't have to dust off Modula-2 (which nostalgia
notwithstanding is showing every bit of it's age)[1]. Ada doesn't have much
dust on it and has a solid, free compiler and some pretty nifty software
support (e.g. AWS). Oh, sure, the ecosystem (e.g. contemporary libraries, IDE
support, tutorials) needs improvement, but that's just a matter of getting
more programmers interested.

[1] I haven't looked at any of the contemporary Modula-2-ish efforts (e.g. GNU
M2, M2R10, M3) recently and maybe things have changed, but they were all
moribund or glacial labors of love from a single or tiny team of developers.

~~~
nickpsecurity
Remember the context is replacing Forth for where it's used. This is often in
bootloaders with basically no storage and sometimes under 32-bits. I'm not
sure how well Ada works in such situations. So, we'll need a HLL that's
readable, safer, easy to compiler, and easy to produce both CISC and RISC code
for. Wirth & Jurg threw Modula-2 together in a year or two for Lilith with
students routinely porting his stuff to new platforms in months rather than
years. So, a new Modula-2 variant seemed like an easy replacement for Forth.

"but that's just a matter of getting more programmers interested."

Won't happen: they hate Ada as much as LISP. More given Clojure is going
mainstream but Ada still isn't. So, if I want to use it, I have to deliver the
result in _their_ language or build killer app that hooks them onto Ada. The
first is easier to do most of the time. Adacore even acquired a company that
specialized in deploying Ada apps as either C or C++. So, it's a proven model
which could be applied to a simpler language (eg Modula-2) for bootloaders,
etc.

~~~
kjs3
That's fair, and I don't, per se, disagree with any point.

That said, I will reiterate that it's clear that based on the several recent
attempts, un-zombie-fying Modula-2 isn't trivial. Perhaps the answer is to
grab one of these projects (or Modula-3) and throw the effort into "you're not
going to be the next Webdev language, but lets beat this low-level systems
niche into our world". Maybe start by writing a bulletproof bootloader or
something. Or some security sensitive network plumbing. Can't do any worse
than the Rust/Go guys are doing, with the bonus that Modula-[23] have actually
been used to build real bare metal systems.

I dunno...maybe I just need another scotch.

FWIW...every time I've been in a "Forth could do this, but forth makes me want
to dig my eyeballs out with spoons, what is the alternative?" scenario, I
reached for C, and haven't really been all that disappointed. I know that
makes me a bad person.

~~~
nickpsecurity
Oh, I agree about work to revive a Modula-like language. Plus that it helps to
do example projects that show why it's better. The CVSup author doing his tool
in Modula made a nice, case study in Modula vs X discussions. One solution I
thought of was just subsetting a language like Go or Pascal w/ runtime being
limited or zero. Free Pascal still has good tool support plus was first Wirth
language used in systems work. GEMSOS security kernel was also written in
Pascal. You might also find BootSafe interesting: a certified compiler and
checker from Java to Forth for increasing assurance/maintenance of Open
Firmware components. Tool is quite proprietary but the approach could be used
with Go, Pascal, etc if Forth is required.

So, there's some options on that. Far as Forth vs C, I think it's fine to
think C is acceptable for firmware as being a near-cross-platform assembly
suddenly helps there. I'd have made C default for this given all developers,
tools, and code examples available. And then we'd have this discussion to
figure out how to get rid of it.

On other hand, doing almost everything system in C then switching to Forth for
just firmware? That's worse than doing everything in C. You're a better person
for sparing the maintainers from that crap. ;)

