Live data from Hacker News

Running a Minecraft Server and more on a 1960s UNIVAC Computer

farlow.dev

31–39 of 39 posts

Re: Running a Minecraft Server and more on a 1960s UNIVAC Computer

#31

Favourite article I've read in a while, what a delight. I wonder what kind of performance you could get if someone hand wrote a dedicated, modern C compiler for it.

According to the article, it takes 40 univac instructions to run a single risc-v instruction, so potentially up to 40x the current performance. Though you'd probably need more instructions to do things than a single one, so probably less than that, say 10-20x? Especially if you made a custom compiler that made the best use of the hardware you could, since it's weird

RISCV is a VEEEEERY poor emulation target - the piecemeal scattering of immediates all over the instr makes it very slow to assemble them (lots of ANDs, shifts, and ORs) . Re-encoding them is one solution, yeah, but then this is a mandatory messy post-compilation step that also needs to know what is code and what is data. It is almost a pessimal setup. MIPS is much simpler to emulate

Re: Running a Minecraft Server and more on a 1960s UNIVAC Computer

#32

Earlier quoted context omitted.

According to the article, it takes 40 univac instructions to run a single risc-v instruction, so potentially up to 40x the current performance. Though you'd probably need more instructions to do things than a single one, so probably less than that, say 10-20x? Especially if you made a custom compiler that made the best use of the hardware you could, since it's weird

RISCV is a VEEEEERY poor emulation target - the piecemeal scattering of immediates all over the instr makes it very slow to assemble them (lots of ANDs, shifts, and ORs) . Re-encoding them is one solution, yeah, but then this is a mandatory messy post-compilation step that also needs to know what is code and what is data. It is almost a pessimal setup. MIPS is much simpler to emulate

Hey, wait a minute, you're the guy who got Linux to run on a 4004 by writing a MIPS emulator[1]! If there's anyone who's been down a similar path before it'd have to be you.

[1] - https://dmitry.gr/?r=05.Projects&proj=35.%20Linux4004

Re: Running a Minecraft Server and more on a 1960s UNIVAC Computer

#33
post #32

Earlier quoted context omitted.

RISCV is a VEEEEERY poor emulation target - the piecemeal scattering of immediates all over the instr makes it very slow to assemble them (lots of ANDs, shifts, and ORs) . Re-encoding them is one solution, yeah, but then this is a mandatory messy post-compilation step that also needs to know what is code and what is data. It is almost a pessimal setup. MIPS is much simpler to emulate

Hey, wait a minute, you're the guy who got Linux to run on a 4004 by writing a MIPS emulator[1]! If there's anyone who's been down a similar path before it'd have to be you. [1] - https://dmitry.gr/?r=05.Projects&proj=35.%20Linux4004

Yup. And that one of the reasons why not RISCV

Re: Running a Minecraft Server and more on a 1960s UNIVAC Computer

#37
post #3

What a great write up, and a video too! Even though Minecraft stuff ofc was a bit of a bait, it would be interesting see the answer to "Can it run Doom?".

Not Doom, but a ZMachine interpreter might run with:

- Zork I-III

- Calypso

- Tristam Island

- All the Z3 machine games at IF archive

- The rest of Infocom propietary games

https://www.ifwiki.org/List_of_Z-machine_interpreters

Also: https://ifdb.org/viewgame?id=lkr2jf03np19ieix

Now, if the game was libre software it could be improved and ported to Puny Inform (a 'lite' version of Inform6 tuned for smaller machines) creating a really small Z3 file being able to play it from the PDP10 and 8 bit microcomputers to anything from today. From smartphones to PDA's to GNU/Linux with Frotz to Winfrotz and Lectrote and Fabularium for Android/Mac and iOS.

So, 'does it run Doom'? Man, you can play Zork in a pen with writting detection. How cool is that?

Re: Running a Minecraft Server and more on a 1960s UNIVAC Computer

#39
post #38

Does anyone know why the jal RISC-V instruction scrambles it bits in this way? https://msyksphinz-self.github.io/riscv-isadoc/html/rvi.html...

RISC-V's instruction encoding is designed to keep the bits of literals in common positions between different instruction types. I believe this is to simplify/speed up instruction decoding. The MSB of the literal is always the MSB of the instruction, which makes sign extension consistent. Most of the other bits in the J-type encoding line up nicely with the I-type or U-type encodings.
Post reply on HN