←back to thread

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

(benbridle.com)
221 points benbridle | 4 comments | 10 Jul 25 22:20 UTC | HN request time: 0s | 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
tines ◴[15 Jul 25 00:02 UTC] No.44566614[source]▶
Why 8 bit?
replies(1): >>44568292 #
kragen ◴[15 Jul 25 06:07 UTC] No.44568292[source]▶
That puzzled me too, since it's a fork of Uxn, a 16-bit architecture.
replies(1): >>44578812 #
1. benbridle ◴[16 Jul 25 04:58 UTC] No.44578812[source]▶
I had a hard time figuring out whether Bedrock counted as an 8-bit or 16-bit computer, because it doesn't line up so cleanly with the usual criteria as does a physical CPU. I decided that the 8-bit label fitted best because it has an 8-bit data path, an 8-bit instruction format, and the stacks hold only bytes. It also has a 16-bit address space and can perform 16-bit arithmetic, but so can the well-known 8-bit Z80 processor.
replies(1): >>44586152 #
2. kragen ◴[16 Jul 25 19:54 UTC] No.44586152[source]▶
The usual meaning of "data path" https://en.wikipedia.org/wiki/Datapath is the path from the register file (and/or memory access unit) to the ALU and back to the register file (and/or memory access unit). So we could say that both the 8088 and the 68000 had a 16-bit data path, because they used 16-bit buses for those transfers and a 16-bit ALU, even though the 68000 had 32-bit registers and the 8088 had an 8-bit data bus to connect it to RAM. The 68020 implemented the same instructions and registers as the 68000 (and additional ones) but used a 32-bit data path, so they were twice as fast.

In what sense does a virtual machine instruction set architecture with no hardware implementation have a "data path" separate from its arithmetic size? You seem to be using the term in a nonstandard way, which is fine, but I cannot guess what it is.

By your other criteria, the (uncontroversially "16-bit") 8088 would be an 8-bit computer, except that it had a 20-bit address space.

replies(1): >>44587506 #
3. benbridle ◴[16 Jul 25 22:29 UTC] No.44587506[source]▶
By data path, I mean the width of the values that are read from the stacks, program memory, and device bus. Pairs of 8-bit values can be treated as 16-bit values in order to perform wider arithmetic, but all data ultimately moves around the system as 8-bit values.
replies(1): >>44588412 #
4. kragen ◴[17 Jul 25 00:31 UTC] No.44588412{3}[source]▶
Whether 16-bit data moves around the system as 8-bit values or not sounds like a question about the implementation, not the architecture (the spec).

For example, the spec says, "Reading a double from program memory will read the high byte of the double from the given address and the low byte from the following address," but I'd think that generally you'd want the implementation to work by reading the whole 16-bit word at once and then byte-swapping it if necessary, because that would usually be faster, and there's no way for the program to tell if it's doing that, unless reading from the first byte has a side effect that changes the contents of the second byte or otherwise depends on whether you were reading the second byte at the same time.

(Of course if you have a "double" that crosses the boundaries of your memory subsystem's word, you have to fall back to two successive word reads, but that happens transparently on amd64 CPUs.)