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 16 hours ago [-]
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.
jonjacky 6 hours ago [-]
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].
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 6 hours ago [-]
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.
treetalker 1 days ago [-]
I'm not steeped in computer science, so please pardon me if the following are dumb questions.
> Programs written for Bedrock can run on any computer system, so long as a Bedrock emulator has been implemented for that system.
Isn't that true of any program? As long as the language that the program is written in is implemented on the system, any (valid?) program in that language will run on that system?
bottom999mottob 14 hours ago [-]
In theory, if a program is written in a high-level language and you have a correct implementation (interpreter, compiler, runtime) of that language on a new system, then the program should be able to run there.
In practice, this is not always so straightforward, especially as you move closer to machine-level details or consider compiled binaries.
Many compiled programs are built for a specific architecture (x86, ARM, etc.). They won’t run on a different architecture unless you provide either: A cross-compiler (to generate new native code for that architecture), or an emulator (which mimics the old architecture on the new one)
kragen 37 minutes ago [-]
Yes, but it might do something different there, such as print an error message and exit.
Wowfunhappy 22 hours ago [-]
Based on the OP, I think the idea is that it's very easy to port this emulator to a new system.
Walf 19 hours ago [-]
Not quite. Programs normally need to be compiled per system type, and sometimes per system, due to differences in the OSes' versions, APIs and hardware. The idea behind this type of emulator is that you need compile it only once, and the emulator takes care of those differences for you. The Bedrock program would always ‘see’ the same OS and hardware.
obscure-enigma 14 hours ago [-]
moreover, once "it can run anywhere" is defined, you can't run it anywhere
bottom999mottob 14 hours ago [-]
One-size-fits-all never fits everyone :)
Animats 16 hours ago [-]
There's Open Firmware, which runs on a portable Forth interpreter. That was supposed to be a standard for board setup code. But proprietary systems won out. It was too open.
Lerc 7 hours ago [-]
I have thought of doing a similar thing from time to time.
I had thought it could have a use in producing tiny visual apps. I am still somewhat bitter from when I found a volume control that used 3MB on a machine with 256MB total.
It seems you can change the shape of the display, which I like, although I don't really understand the documentation text
>Writing to this port group will perform an atomic write, requesting on commit that the width of the screen be locked and changed to the value written.
Locked and changed?
You also seem to be using double to refer to two bytes, is that correct? If so, I would recommend something that won't confuse people so much. Word is a common nomenclature for a 16 bit value, although it does share the space with the concept of machine words.
And of course to use it for a lot of things it would have to be able to talk to the outside world. A simplified version of what Deno does for allowing such capabilities could allow that. In the terms of Bedrock it would be easiest to have a individual device for each permission that you wanted to supply and have the host environment optionally provide them. I'd put the remote bytestream into it's own device to enable it that way.
> each pixel having both a foreground and a background colour
how does that work?
pjc50 14 hours ago [-]
I thought this might be like the ZX spectrum, but that covers each 8x8 block with a foreground and background colour; "sprites" are then bitmaps over that. This does say two colours per pixel, which is confusing.
You set up a palette of 16 colours, then write 0-15 to the coordinates where you want to set a pixel, but you can also choose between an overlapping foreground and background layer (colour 0 on the foreground layer is transparent).
I guess it's no more weird than some hardware designs from the 80's...
Lerc 8 hours ago [-]
I made a fantasy console with 3x3 pixel cells defined in 16 bits to do any two of 16 colours in the cell
4 bits : color A
4 bits : color B
8 bits : select A or B for the first 8 pixels of the cell
The last Pixel is always color A. You can independently change all pixels in the cell because changing the last pixel on its own can be done by swapping A and B and inverting the second byte.
In hindsight I don't think there was much advantage to the last bit being the odd one out. The code for setting individual pixels in a cell was pretty custom anyway. If I were to do it again, I'd place the color A pixel in the center.
And I do find myself working on a memory constrained device again, so perhaps I'll be giving it a go.
"To assemble a source code file program.brc and save the result as the program program.br, run the command..."
Where are the brc files?
_def 13 hours ago [-]
Ah, you're right, I didn't see that.
severak_cz 11 hours ago [-]
It's a pity there is not some similar concept using more high level language (instead of assembly).
But I can see why as every interpreted language can be "fantasy console" on itself.
kragen 16 hours ago [-]
I like things like this.
One of the big differences from Uxn is the introduction of undefined behavior; by design, you can break it, unlike Stanislav's legos. So presumably Bedrock programs, like C programs, will do different things on different implementations of the system. That's not fatal to portability, obviously, just extra write-once-debug-everywhere work.
nxobject 24 hours ago [-]
This is fantastic! As someone who's used PICO-8 in after-school STEM enrichment classes (and has evaluated uxn), one of the frustrations that my students have always had is easy I/O and persisting state -- for saving/loading game progress and settings, of course. The clipboard and registry devices seem like a good fit.
I hope you stick with this!
behrlich 24 hours ago [-]
> I designed Bedrock to make it easier to maintain programs as a solo developer.
Can you say more? I really love this idea but can’t think of any practical use case with 65k of memory. What programs are you now more easily maintaining with Bedrock? To what end?
apgwoz 7 hours ago [-]
It’s true you can’t build giant video editors or even photo editors. But, if you reestablish your expectations and think 8-bit retro, you’ll be reminded that very few things didn’t exist in some form in the 80s… just at a smaller scale. Spreadsheet? Check. Paint programs? Check. Music composition? Check.
Fun stuff Ben! Nicely done. I'm building a simple terminal that talks over a SPI port or IIC port and this looks like it would be a fun demo to run on it.
great_psy 23 hours ago [-]
I have not delved to deep in the code, but is there any functional differences it has over Java other than the size ?
Presumably Java would also be pretty tiny if we wrote it in bytecode instead of higher lever Java.
Which means implementations also have to be correspondingly complicated. You have to handle quite a few different primitive data types each with their own opcodes, class hierarchies, method resolution (including overloading), a "constant pool" per class, garbage collection, exception handling, ...
I would expect a minimal JVM that can actually run real code generated by a Java compiler to require at least 10x as much code as a minimal Bedrock VM, and probably closer to 100x.
WantonQuantum 21 hours ago [-]
Love this! Takes me back to the literal 8-bit computers of the 80s when it was much easier to learn to program with, for example, BASIC built into the operating system.
untech 24 hours ago [-]
Love it, I think it's very cool! I am not sold on its "everlasting" promise yet, but as an addition to the family of "fantasy" platforms seems very solid.
szczepu 23 hours ago [-]
My immediate reaction was, "oh, like Uxn!" but then of course I read it was originally a fork of Uxn. I love these 'toy' OSes, the more the better.
lihaciudaniel 5 hours ago [-]
Wow awesome imagine this in a browser console, for ... management of the codes, you are genius
ninetyninenine 5 hours ago [-]
Someone should make this for highly parallel architectures that runs over GPUs.
freeone3000 5 hours ago [-]
Lacks power. Existing solutions are SPIR-V and PTX.
ninetyninenine 4 hours ago [-]
I know. I mean something that's simple and has this old school flavor. Like say if GPUs were the standard in the 80s.
lastdong 23 hours ago [-]
The demos are surprisingly fun!
tines 22 hours ago [-]
Why 8 bit?
kragen 16 hours ago [-]
That puzzled me too, since it's a fork of Uxn, a 16-bit architecture.
Rendered at 22:08:34 GMT+0000 (Coordinated Universal Time) with Vercel.
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.
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...
https://benbridle.com/projects/bedrock/user-manual/memory-de...
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.
> Programs written for Bedrock can run on any computer system, so long as a Bedrock emulator has been implemented for that system.
Isn't that true of any program? As long as the language that the program is written in is implemented on the system, any (valid?) program in that language will run on that system?
In practice, this is not always so straightforward, especially as you move closer to machine-level details or consider compiled binaries.
Many compiled programs are built for a specific architecture (x86, ARM, etc.). They won’t run on a different architecture unless you provide either: A cross-compiler (to generate new native code for that architecture), or an emulator (which mimics the old architecture on the new one)
I had thought it could have a use in producing tiny visual apps. I am still somewhat bitter from when I found a volume control that used 3MB on a machine with 256MB total.
It seems you can change the shape of the display, which I like, although I don't really understand the documentation text
>Writing to this port group will perform an atomic write, requesting on commit that the width of the screen be locked and changed to the value written.
Locked and changed?
You also seem to be using double to refer to two bytes, is that correct? If so, I would recommend something that won't confuse people so much. Word is a common nomenclature for a 16 bit value, although it does share the space with the concept of machine words.
And of course to use it for a lot of things it would have to be able to talk to the outside world. A simplified version of what Deno does for allowing such capabilities could allow that. In the terms of Bedrock it would be easiest to have a individual device for each permission that you wanted to supply and have the host environment optionally provide them. I'd put the remote bytestream into it's own device to enable it that way.
Couldn't have done it without you
how does that work?
You set up a palette of 16 colours, then write 0-15 to the coordinates where you want to set a pixel, but you can also choose between an overlapping foreground and background layer (colour 0 on the foreground layer is transparent).
I guess it's no more weird than some hardware designs from the 80's...
In hindsight I don't think there was much advantage to the last bit being the odd one out. The code for setting individual pixels in a cell was pretty custom anyway. If I were to do it again, I'd place the color A pixel in the center.
And I do find myself working on a memory constrained device again, so perhaps I'll be giving it a go.
But where are the source codes?
The source for the examples and assembler/emulator is also there, follow the links.
I mean, if you take a look at this page: https://benbridle.com/projects/bedrock/bedrock-pc.html
"To assemble a source code file program.brc and save the result as the program program.br, run the command..."
Where are the brc files?
But I can see why as every interpreted language can be "fantasy console" on itself.
One of the big differences from Uxn is the introduction of undefined behavior; by design, you can break it, unlike Stanislav's legos. So presumably Bedrock programs, like C programs, will do different things on different implementations of the system. That's not fatal to portability, obviously, just extra write-once-debug-everywhere work.
I hope you stick with this!
Can you say more? I really love this idea but can’t think of any practical use case with 65k of memory. What programs are you now more easily maintaining with Bedrock? To what end?
Presumably Java would also be pretty tiny if we wrote it in bytecode instead of higher lever Java.
Which means implementations also have to be correspondingly complicated. You have to handle quite a few different primitive data types each with their own opcodes, class hierarchies, method resolution (including overloading), a "constant pool" per class, garbage collection, exception handling, ...
I would expect a minimal JVM that can actually run real code generated by a Java compiler to require at least 10x as much code as a minimal Bedrock VM, and probably closer to 100x.