3 ms·

Completely agree and I'll go a bit further. I see old consoles and computers as the only VMs that will last. In 500 years, assuming we all survive, I believe it

by gxd 2y ago

Completely agree and I'll go a bit further. I see old consoles and computers as the only VMs that will last. In 500 years, assuming we all survive, I believe it's more likely that code targeting the NES will be runnable than code targeting today's browsers, .NET or the JVM. The reason is that while these competing VMs are well documented, they are extremely complex and code targeting them tend to rely on idiosyncrasies of current operating systems, browsers and even hardware. Also, the retro hardware itself is the ultimate documentation. You can look at every chip using (nowadays) accessible equipment and create an absolutely perfect replica in software or FPGA. VM documentation, however, can contain inaccuracies. My speculative fiction statement of the day is that only software targeting relatively simple architectures will stand the test of time.

jebarker 2y ago
Not to mention that so much more modern software will fail due to requiring network connectivity to non-existent services
Klonoar 2y ago
Isn't this general idea what the 100 Rabbits people theorize? i.e with uxn and all that
- gxd 2y ago
  I had never heard of it, so I went to find out more. Yes, I think it's the same philosophy. Very cool project. Unfortunately, it seems that they went against the project's very principle by inventing a new language, new VM and toolchain instead of simply targeting one of the existing platforms. I can see why they wanted to build an abstraction layer, so their code is portable across different classic (and modern) platforms, but this is one more case of https://xkcd.com/927/ https://xkcd.com/927/. It would have been totally okay if they had said "The future of software is creating applications targeting the Amiga 1000", or anything else from the 80s-90s, which I'll arbitrarily define as "simple enough to accurately emulate forever".
  - entaloneralie 2y ago
    > Unfortunately, it seems that they went against the project's very principle by inventing a new language, new VM and toolchain instead of simply targeting one of the existing platforms. The intentions of Uxn are not directly in line with using say, a commodore 64, for preservation and as a portability layer, which is a monumental project to implement for each new system. The project's core principle is to design something perfectly tailored at hosting a handful of specific programs, document it in a way that if needed, others could create their own systems based on their own vision, and not centralize all preservation efforts around a handful of retrocomputing emulation. https://wiki.xxiivv.com/site/devlog https://wiki.xxiivv.com/site/devlog https://100r.co/site/weathering_software_winter.html https://100r.co/site/weathering_software_winter.html It's more akin to using brainfuck or subleq, or Another World's VM or even Alan Kay's Chifir where the goal is to target a virtual machine that is so small(< 100 loc) that it can be easily ported. As opposed to a system so complex that it might take someone months to implement a passable C64, Amiga, or ST80 emulator. https://tinlizzie.org/VPRIPapers/tr2015004_cuneiform.pdf https://tinlizzie.org/VPRIPapers/tr2015004_cuneiform.pdf Other related similar projects: https://dercuano.github.io/notes/uvc-archiving.html https://dercuano.github.io/notes/uvc-archiving.html
    - gxd 2y ago
      Thank you for the great links! It can be really hard to get accurate emulation with a somewhat loosely defined, high level VM such as some of your examples. If it's that small and simple, programmers might accidentally create a dependency on implementation idiosyncrasies. Just see what happens on the retro computing scene when emulators aren't perfectly cycle and hardware accurate - applications, the "demoscene" being a good example of them, that rely on very low-level details of the architecture don't work on certain emulators. If we want to create a new "forever VM", that VM would have to very strictly define behaviors across I/O, graphics, audio and other areas. I don't want the application to stutter or run too fast on future emulators. I want the emulation to be perfectly cycle accurate.
      - entaloneralie 2y ago
robinsonb5 2y ago
Another aspect of this is the relative simplicity of the toolchain. On my 10-year-old PC (Core i5 something or other) I can build a cross assembler and C compiler for the Amiga in around 21 seconds (vbcc, Vasm, Vlink). I can build the same on the Amiga itself in minutes (admittedly quite a lot of minutes!) rather than hours. Meanwhile, I read recently of a build of llvm on a RISC-V SoC taking well over 12 hours.
majormajor 2y ago
I think it has less to do with the architecture or medium and more to do with the type of media itself. We are more likely to actively preserve art in usable forms than something like JIRA. We play Chess more than we use whatever contemporary accounting tool. We read old novels more than we read transcripts of business meetings. So we'll be more motivated to keep these architectures and games continually preserved.
devilbunny 2y ago
> code targeting the NES Well, the 6502 in general. It's an extremely important processor in history. People want to emulate NES, Commodore, Atari 8-bit, Apple II - so an accurate 6502 emulator has a HUGE base of nostalgic geeks to improve it.
- ddingus 2y ago
  Yes, and we have freely available, cycle accurate 6502 emulation code bodies along with full coverage tests that include both the official opcodes and many illegal ones. Mostly the ones people used such as LAX, which can get the same value into both registers on a single read. I just had a fleeting thought right now related to that behavior: Basically, that opcode works because of how simple the design is. Electrically, wiring both registers up does the trick. And many parts of the chip can work together like that even though none or it was intended. I wonder what a revisit, that takes these now well understood behaviors into consideration, would look like! Zeroing all or multiple registers, same with bit ops, maybe inc, dec... Many new, efficient instructions are possible. Would be a fun programming exercize and design one too.

by gxd 2y ago

jebarker 2y ago

Not to mention that so much more modern software will fail due to requiring network connectivity to non-existent services

Klonoar 2y ago

Isn't this general idea what the 100 Rabbits people theorize? i.e with uxn and all that

gxd 2y ago
I had never heard of it, so I went to find out more. Yes, I think it's the same philosophy. Very cool project. Unfortunately, it seems that they went against the project's very principle by inventing a new language, new VM and toolchain instead of simply targeting one of the existing platforms. I can see why they wanted to build an abstraction layer, so their code is portable across different classic (and modern) platforms, but this is one more case of https://xkcd.com/927/ https://xkcd.com/927/. It would have been totally okay if they had said "The future of software is creating applications targeting the Amiga 1000", or anything else from the 80s-90s, which I'll arbitrarily define as "simple enough to accurately emulate forever".
- entaloneralie 2y ago
  > Unfortunately, it seems that they went against the project's very principle by inventing a new language, new VM and toolchain instead of simply targeting one of the existing platforms. The intentions of Uxn are not directly in line with using say, a commodore 64, for preservation and as a portability layer, which is a monumental project to implement for each new system. The project's core principle is to design something perfectly tailored at hosting a handful of specific programs, document it in a way that if needed, others could create their own systems based on their own vision, and not centralize all preservation efforts around a handful of retrocomputing emulation. https://wiki.xxiivv.com/site/devlog https://wiki.xxiivv.com/site/devlog https://100r.co/site/weathering_software_winter.html https://100r.co/site/weathering_software_winter.html It's more akin to using brainfuck or subleq, or Another World's VM or even Alan Kay's Chifir where the goal is to target a virtual machine that is so small(< 100 loc) that it can be easily ported. As opposed to a system so complex that it might take someone months to implement a passable C64, Amiga, or ST80 emulator. https://tinlizzie.org/VPRIPapers/tr2015004_cuneiform.pdf https://tinlizzie.org/VPRIPapers/tr2015004_cuneiform.pdf Other related similar projects: https://dercuano.github.io/notes/uvc-archiving.html https://dercuano.github.io/notes/uvc-archiving.html
  - gxd 2y ago
    Thank you for the great links! It can be really hard to get accurate emulation with a somewhat loosely defined, high level VM such as some of your examples. If it's that small and simple, programmers might accidentally create a dependency on implementation idiosyncrasies. Just see what happens on the retro computing scene when emulators aren't perfectly cycle and hardware accurate - applications, the "demoscene" being a good example of them, that rely on very low-level details of the architecture don't work on certain emulators. If we want to create a new "forever VM", that VM would have to very strictly define behaviors across I/O, graphics, audio and other areas. I don't want the application to stutter or run too fast on future emulators. I want the emulation to be perfectly cycle accurate.
    - entaloneralie 2y ago

robinsonb5 2y ago

Another aspect of this is the relative simplicity of the toolchain. On my 10-year-old PC (Core i5 something or other) I can build a cross assembler and C compiler for the Amiga in around 21 seconds (vbcc, Vasm, Vlink). I can build the same on the Amiga itself in minutes (admittedly quite a lot of minutes!) rather than hours. Meanwhile, I read recently of a build of llvm on a RISC-V SoC taking well over 12 hours.

majormajor 2y ago

I think it has less to do with the architecture or medium and more to do with the type of media itself. We are more likely to actively preserve art in usable forms than something like JIRA. We play Chess more than we use whatever contemporary accounting tool. We read old novels more than we read transcripts of business meetings. So we'll be more motivated to keep these architectures and games continually preserved.

devilbunny 2y ago

> code targeting the NES Well, the 6502 in general. It's an extremely important processor in history. People want to emulate NES, Commodore, Atari 8-bit, Apple II - so an accurate 6502 emulator has a HUGE base of nostalgic geeks to improve it.

ddingus 2y ago
Yes, and we have freely available, cycle accurate 6502 emulation code bodies along with full coverage tests that include both the official opcodes and many illegal ones. Mostly the ones people used such as LAX, which can get the same value into both registers on a single read. I just had a fleeting thought right now related to that behavior: Basically, that opcode works because of how simple the design is. Electrically, wiring both registers up does the trick. And many parts of the chip can work together like that even though none or it was intended. I wonder what a revisit, that takes these now well understood behaviors into consideration, would look like! Zeroing all or multiple registers, same with bit ops, maybe inc, dec... Many new, efficient instructions are possible. Would be a fun programming exercize and design one too.