bedrock platform

A bedrock platform is a hardware platform or a universal virtual machine that can be expected to remain compatible with any software that has ever been written for it. Bedrock platforms can be used to prevent software rot.

Note that this is not a "shopping list" or a list of "allowed" hardware. Bedrock platform support is simply a way of maximizing the probability that a program can be run in an indefinite future and a way to keep its dependencies reliable. The concept of bedrock platform is not relevant to e.g. embedded-system-type projects that are designed for a very specific hardware, or the kind of software that is known to have a short lifespan.

A simple bedrock platform guide based on the IBM PC line:

Can you compile and run the program in FreeDOS?
- If yes, you have the bedrock support (just make sure that the compiler and other needed tools are archived somewhere).
- If not, can you create an x86 operating system image that compiles and runs the program without accessing any external resources?
  - If yes, you have the bedrock support (just archive the image and/or everything you've put in it).
If you can only run it in these environments but not compile it, it is still far better than nothing.

Some possible criteria for bedrock hardware:

The hardware has been popular and commonly available at some point of history (and preferably remains that way).
Every detail of the hardware is well-known and fully documented. (Having a 100% compatible open-source emulator can be considered full documentation)
There have been several independent manufacturers for each component.
Multiple emulators for the platform are commonly available for many different environments.
There are no copyright issues in regards to the hardware design, firmware IP, etc.
It is possible to pinpoint a "standard configuration" that is supposed to run all the programs and can be used for testing software compatibility (usually this means the original version of the hardware or the de-facto most popular variant).

Candidates for bedrock hardware:

IBM PC: Widely cloned, remains ubiquitous, every type of common component has had multiple manufacturers in different parts of the world (with the exception of OPL2/OPL3 common in classical soundcards). Can be emulated by open-source software such as ?QEMU, Dosbox or Bochs. There are also several different DOS-compatible operating systems, including FreeDOS. Standard configurations may be difficult to pinpoint.
?NES/Famicom: Widely cloned especially in China/Taiwan without any of the original Japanese components. Huge amount of available emulators, and running a ROM file with one is very straightforward. No software dependencies (as there's no internal firmware ROM).
?ZX Spectrum: Simple design that was easy enough to duplicate in Eastern-block countries even with 100% non-Western components. Clones are still manufactured, emulators are widely available.
?MSX: Standardized platform, every chip used in MSX-1 computers has had both U.S.American and Japanese manufacturers. (MSX-2 on the other hand depends on specific Yamaha chips). Emulators widely available. The firmware ROMs may pose issues as long as Microsoft exists. Also, there's no obvious standard configuration.

Raspberry Pi is an example of a platform that fails the criteria. It depends on a single-manufacturer SoC chip (Broadcom BCM2835) that doesn't have full documentation available. QEMU emulates some versions of the platform to some extent but this emulation does not cover the undocumented parts of the chip (e.g. running the GPU firmware code).

For virtual bedrock hardware, the main criterion is that the specification is simple enough that it can be implemented in a small effort for commonly available computers, and that the specification is unambiguous and frozen.

Even though optimal resource use is not a major point in bedrock platforms, having that as well would be ideal. Not only should it be possible to make minimal-overhead emulators, but to read, ?analyze, ?decompile and recompile the code in order to use it on arbitrary future computers. Writers of bedrock-platform software may want to make sure that it will be easy enough to e.g. separate code from data even when analyzing binaries.

The Maxwell's Equations of Software

Alan Kay has famously described Lisp as the “Maxwell’s equations of software”. He describes the revelation he experienced when, as a graduate student, he was studying the LISP 1.5 Programmer’s Manual and realized that “the half page of code on the bottom of page 13 was Lisp in itself.

Yes, that was the big revelation to me when I was in graduate school—when I finally understood that the half page of code on the bottom of page 13 of the Lisp 1.5 manual was Lisp in itself. These were “Maxwell’s Equations of Software!” This is the whole world of programming in a few lines that I can put my hand over.

I realized that anytime I want to know what I’m doing, I can just write down the kernel of this thing in a half page and it’s not going to lose any power. In fact, it’s going to gain power by being able to reenter itself much more readily than most systems done the other way can possibly do.