←back to thread

Show HN: Bedrock – An 8-bit computing system for running programs anywhere

(benbridle.com)
221 points benbridle | 3 comments | 10 Jul 25 22:20 UTC | HN request time: 0.001s | source

Hey everyone, this is my latest project.

Bedrock is a lightweight program runtime: programs assemble down to a few kilobytes of bytecode that can run on any computer, console, or handheld. The runtime is tiny, it can be implemented from scratch in a few hours, and the I/O devices for accessing the keyboard, screen, networking, etc. can be added on as needed.

I designed Bedrock to make it easier to maintain programs as a solo developer. It's deeply inspired by Uxn and PICO-8, but it makes significant departures from Uxn to provide more capabilities to programs and to be easier to implement.

Let me know if you try it out or have any questions.

Show context
vincent-manis ◴[14 Jul 25 22:59 UTC] No.44566292[source]▶
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.

replies(4): >>44566519 #>>44567108 #>>44568246 #>>44572840 #
mikestaas ◴[15 Jul 25 01:44 UTC] No.44567108[source]▶
Wouldn't the 32-bit variant just be WebAssembly?
replies(1): >>44568279 #
1. kragen ◴[15 Jul 25 06:05 UTC] No.44568279[source]▶
No, the WebAssembly spec is over 200 pages.
replies(1): >>44568657 #
2. lifthrasiir ◴[15 Jul 25 07:01 UTC] No.44568657[source]▶
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.
replies(1): >>44572996 #
3. kragen ◴[15 Jul 25 16:35 UTC] No.44572996[source]▶
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.