Top
Best
New

Posted by todsacerdoti 1 day ago

Easy RISC-V(dramforever.github.io)
383 points | 77 commentspage 2
bigprovolone 1 day ago|
if you're looking for an nice RISCV emulator try RARS https://github.com/TheThirdOne/rars
LarsDu88 23 hours ago||
Great work! I was wondering about this after trying out Easy6502. It would be nice to have a more visual component like Easy6502 which has a draw buffer and snake game tho :)
ge96 13 hours ago||
tangent I want to link back to this https://github.com/mortbopet/Ripes
ReFruity 1 day ago||
I like this. Do you have a link to your simulator code? I might borrow for a personal project of mine if it's ok.
klelatti 1 day ago|
https://github.com/dramforever/easyriscv/blob/main/emulator....
lachlanj 1 day ago||
Has anyone seen anything similar to this for x86?
adgjlsfhk1 1 day ago|
making this in x86 would be fairly tricky since there isn't the same sort of unified core (there used to be, but that was the 16 bit extension set which isn't how x86 is used now).
Ethan312 1 day ago||
Nice project. RISC-V tools like this make learning architecture concepts much easier. It’s great to see more hands-on resources that help people move from theory to actual CPU behavior.
sylware 22 hours ago||
Even if there are not that expensive to implement, I do not use official ABI register names, neither pseudo-instructions (I use a command to generate the code on the side).

Once RISC-V has performant silicon implementations (server/desktop/mobile/embedded), the really hard part will be to move the software stack, mostly closed source applications like video games.

And a very big warning: do NOT abuse an assembler macro-preprocessor or you will lock your code on that very assembler. On my side I have been using a simple C pre-processor to keep the door open for any other assembler, at minimal technical cost.

dontlaugh 22 hours ago|
The games are barely moving to ARM, they won’t move to yet another architecture. Desktop games will remain x86 windows for the foreseeable future merely due to the existing catalogue.

The only exception is console games, where the architecture doesn’t matter anyway.

sylware 21 hours ago||
Yep, the super hard part: this rv64 "catalog" is empty.

If you put emulation (hardware accelerated or not), game devs won't compile for rv64. Look at how valve proton is hurting native elf/linux gaming: game devs hardly build anymore for native elf/linux (but this may be related to the toxic behavior of some glibc and gcc devs though), even though their game engine has everything linux support.

Firehawke 18 hours ago||
It's also how easy the userland can break things. Windows backwards compatibility tends (even if it's not 100% successful on this) to stay relatively stable. It's kind of funny that the most compatible way to distribute Linux binaries for games is to target Proton/Wine.
sylware 16 hours ago||
proton/wine has no official technical support hence illegal in tons of countries.

Since proton/wine is unreliable in time, this is a disaster.

And there is a lot of BS around that: if some devs support their game on elf/linux via proton, they will have to QA it on a linux system anyway, so it does not change that much, even less with a game engine which has everything linux already... it only add the ultra-heavy-complex and then bug inducing proton/wine layer... an horrible mess to debug. One unfortunate patch, proton/wine side or game side, and compat is gone, and you are toast... and those patches do happen.

Conclusion: the only sane way is PROTON = 0 BUCKS.

I play only F2P games with proton (mostly gachas), no way I'll pay bucks for a game without technical support.

Valve should allow to pay games _only_ for the games with official elf/linux/proton support (aka the game devs do QA on elf/linux with valve proton... which would be no better than stupid if their game engine has elf/linux support already in). Why not let elf/linux users play all games which do not have official elf/linux support for free, well, those which run, and run decently, and until an unfortunate patch...

doublerabbit 1 day ago||
Within the basic "123" ASM demo, I get that x10 - Becomes 0x00000123 as we are taking the integer of x0 and applying 123 to end of it but why is the sp (x2) register at 0x40100000?

What is that sp? Is it important? Why isn't that at 0x000000? Why isn't that explained? That's when I get lost.

ajxs 1 day ago|
'sp' is the 'stack pointer' register. There's an explanation of the stack later in the guide: https://dramforever.github.io/easyriscv/#the-stack