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.
Show HN: Bedrock – An 8-bit computing system for running programs anywhere
11–20 of 69 posts
Re: Show HN: Bedrock – An 8-bit computing system for running programs anywhere
#12For people curious about the differences between this and Uxn (as I was): https://benbridle.com/articles/bedrock-differences-from-uxn....
Re: Show HN: Bedrock – An 8-bit computing system for running programs anywhere
#13This 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…
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...
Re: Show HN: Bedrock – An 8-bit computing system for running programs anywhere
#14Why 8 bit?
Re: Show HN: Bedrock – An 8-bit computing system for running programs anywhere
#15I 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.
The Java bytecode instruction set actually has a quite complicated specification: https://docs.oracle.com/javase/specs/jvms/se8/html/
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.
Re: Show HN: Bedrock – An 8-bit computing system for running programs anywhere
#16I'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?
Based on the OP, I think the idea is that it's very easy to port this emulator to a new system.
Re: Show HN: Bedrock – An 8-bit computing system for running programs anywhere
#17Love 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.
Re: Show HN: Bedrock – An 8-bit computing system for running programs anywhere
#18This 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…
Wouldn't the 32-bit variant just be WebAssembly?
Re: Show HN: Bedrock – An 8-bit computing system for running programs anywhere
#19I'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?
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.
Re: Show HN: Bedrock – An 8-bit computing system for running programs anywhere
#20Fun 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.