[vincent-manis]

This is the latest in a very honourable tradition. My first encounter with it was with Martin Richards's BCPL system in 1972. The compiler generated a hypothetical ISA called OCODE, from which backends generated pretty good native code for Titan-2 and System/360, among others. One of those backends generated INTCODE, which was an extremely reduced ISA, for which an interpreter could be easily written (I wrote one in Fortran). Richards also provided the BCPL compiler and runtime library in INTCODE, so you could quickly have BCPL running interpretively. Then you could use this interpretive version to bootstrap a native-code backend implementation. Put this all together, and you now have a very easy compiler port.

Wirth's Pascal-P compiler of 1974(?) used the same idea, also in aid of a highly portable compiler. I have never been able to find out whether this was an independent invention, or whether Wirth was influenced by Richards's work.

Of course, the JVM and CLR are descendents of this, but they build a very complex structure on the basic idea. Writing an implementation of one of these virtual machines is not for the faint of heart.

So I think Bedrock can be very useful as a compiler target, if nothing else. However, I must agree with some of the other commenters that the 64KiB address space makes it very much of a niche tool. Come up with a 32-bit variant that's not much more complicated, and I think you have a winner.

[kragen]

Wirth did it before BCPL in EULER, but virtual machines of various kinds predate EULER; Schorre's META-II output a textual assembly language for a fictitious processor, and Short Code predated that, but was intended to be written by hand. Simulators for one real computer on another were already commonplace by the 01960s, so that you could keep running your programs for an obsolete machine, and I don't remember anyone specifically saying so, but I would assume that designers of planned computers were writing such simulators for their designs by the end of the 01950s.

[ripe]

Regarding the 64kB limit: I notice that an implementation can provide the programmer an optional memory block of up to 64MB, IIUC:

https://benbridle.com/projects/bedrock/user-manual/memory-de...

[jonjacky]

Another early example is Stoy and Strachey's virtual machine for running their OS-6 operating system on the Module One minicomputer, starting around 1969 [1,2]. It was written in BCPL. Butler Lampson wrote that it influenced the early pre-Smalltalk OS for the Xerox Alto, also in BCPL [3].

1. https://academic.oup.com/comjnl/article-abstract/15/2/117/35...

2. https://academic.oup.com/comjnl/article-abstract/15/3/195/48...

3. https://www.microsoft.com/en-us/research/publication/an-open...

[mikestaas]

Wouldn't the 32-bit variant just be WebAssembly?

[kragen]

No, the WebAssembly spec is over 200 pages.

[lifthrasiir]

Not to disagree, but WebAssembly intentionally does contain two equivalent descriptions (prose vs. mathematical) and two different formats (binary vs. text), plus a completely independent redefinition of IEEE 754 (!). The true size would be more like around 100 pages, where the instruction definitions would take about a half of them if my prediction from the table of contents is close enough. Maybe highly desugarable "WebAssembly Zero" might be defined and would be a good fit once SpecTec can produce a working modular interpreter.

[kragen]

I think Bedrock's choice of not having floating point at all is a good example of the divergence in design goals.

That said, I don't see a completely independent redefinition of IEEE 754 in the 226-page https://webassembly.github.io/spec/core/_download/WebAssembl.... In §4.3.3 it does restrict IEEE 754, for example requiring a particular rounding mode, and it defines NaN propagation details that the IEEE 754 spec leaves open-ended IIRC, and it does define some things redundantly to IEEE 754, such as addition and square roots and so on. But it doesn't, for example, describe the binary representation of floating-point numbers at all, even though they can be stored in linear memory and in modules (it just refers you to the IEEE spec), nor permit decimal floating point. §4.3.3 only runs from p. 74 to p. 87, so it would be hard for it to independently define all of IEEE 754.