> RISC-V has either little-endian or big-endian byte order.
Yeah though for instruction fetch it's always little endian. I honestly think they should remove support for big endian from the spec. As far as I know nobody has implemented it, the justification in the ISA manual is very dubious, and it adds unneeded complexity to the spec and to reference models.
Plus it's embarrassing (see Linus's rant which I fully agree with).
If you're going to make this argument, I'd consider arguing for Zig a little more substantiated; Rust is cross-platform and x86_64 assembly certainly isn't. Most of my day to day computing is done on ARM platforms as are some of my server resources, and I expect that to expand as time goes on.
> Your use case is totally out of scope of my project.
You have a completely different use case from the OP, but still had no problem telling them that they were doing it wrong, so it’s pretty funny to see you use this line of defense for your choice.
I think assembly is probably a pretty bad choice for a RISC-V emulator. It's not portable, a nightmare to maintain, and not even as fast as binary translation.
What kind of performance do you get?
I guess it would be a great way to learn about the differences between x86 and RISC-V though!
I am not looking for performance (it will run natively on rv64 hardware), I am looking to protect the code against computer language syntax/compiler planned obsolescence (usually cycles of 5-10 years).
Have a look a little bit below in the comments where I give a reference to another one, written by the creator of ffmpeg and q-emu.
Honestly, assembly language bitrots far faster than other programming languages. In my lifetime, the only thing that really comes close to qualifying as "compiler language syntax/compiler planned obsolescence" is Python 2 to Python 3. In contrast, with x86 alone, there's three separate generations of assembly language to go through in that same timeframe.
Real life example, in Android 7 Google re-introduced an interpreter for DEX bytecodes, manually written in Assembly, throwing away the old one that existed until Android 5, written in C.
If true? I usually only comment stuff I can post profs on, so is the Internet nature.
> Interpreter performance significantly improved in the Android 7.0 release with the introduction of "mterp" - an interpreter featuring a core fetch/decode/interpret mechanism written in assembly language
Affero GPLv3 work-in-process there, I use it for my own commands written in rv64 running on x86_64 everday (warning: it depends on a new executable file format and an ELF capsule). Currently slow-writting my own wayland compositor for AMD GPU using it. (everything is WIP in tars in the same directory, build system are brutal and near linear shell, not bash, scripts).
Come on, that was to avoid the robots to parse it.
That said, the ffmpeg and qemu creator, and quickJS, did code one in plain and simple C you can compile with most, if not all, C compilers out there (not only gcc and clang abominations).
> RISC-V has either little-endian or big-endian byte order.
Yeah though for instruction fetch it's always little endian. I honestly think they should remove support for big endian from the spec. As far as I know nobody has implemented it, the justification in the ISA manual is very dubious, and it adds unneeded complexity to the spec and to reference models.
Plus it's embarrassing (see Linus's rant which I fully agree with).
Just a heads-up that only the first three chapters are available so far. Apparently there will be ten, when finished.
It's not the right move, better do it in assembly. I have a little rv64 interprer written in x86_64 assembly.
If you're going to make this argument, I'd consider arguing for Zig a little more substantiated; Rust is cross-platform and x86_64 assembly certainly isn't. Most of my day to day computing is done on ARM platforms as are some of my server resources, and I expect that to expand as time goes on.
Your use case is totally out of scope of my project.
Look down below in the comments where I do reference one written in plain and simple C from the creator of ffmpeg and q-emu.
> Your use case is totally out of scope of my project.
You have a completely different use case from the OP, but still had no problem telling them that they were doing it wrong, so it’s pretty funny to see you use this line of defense for your choice.
I think assembly is probably a pretty bad choice for a RISC-V emulator. It's not portable, a nightmare to maintain, and not even as fast as binary translation.
What kind of performance do you get?
I guess it would be a great way to learn about the differences between x86 and RISC-V though!
I am not looking for performance (it will run natively on rv64 hardware), I am looking to protect the code against computer language syntax/compiler planned obsolescence (usually cycles of 5-10 years).
Have a look a little bit below in the comments where I give a reference to another one, written by the creator of ffmpeg and q-emu.
Honestly, assembly language bitrots far faster than other programming languages. In my lifetime, the only thing that really comes close to qualifying as "compiler language syntax/compiler planned obsolescence" is Python 2 to Python 3. In contrast, with x86 alone, there's three separate generations of assembly language to go through in that same timeframe.
Python still doesn't do very well on backwards compatibility & bitrot, even after 3. They're constantly deprecating and removing things.
https://docs.python.org/3.12/deprecations/index.html
This obviously improves Python, but also it means you absolutely shouldn't choose Python if you are looking for a low maintenance language.
I'm pretty sure Rust is going to outlast x86! C definitely will.
Real life example, in Android 7 Google re-introduced an interpreter for DEX bytecodes, manually written in Assembly, throwing away the old one that existed until Android 5, written in C.
Well, if true, those people at gogol did the right thing... if all the others could behave the same way...
If true? I usually only comment stuff I can post profs on, so is the Internet nature.
> Interpreter performance significantly improved in the Android 7.0 release with the introduction of "mterp" - an interpreter featuring a core fetch/decode/interpret mechanism written in assembly language
From https://source.android.com/docs/core/runtime/improvements
> It's not the right move, better do it in assembly. I have a little rv64 interprer written in x86_64 assembly.
Published your source code?
Affero GPLv3 work-in-process there, I use it for my own commands written in rv64 running on x86_64 everday (warning: it depends on a new executable file format and an ELF capsule). Currently slow-writting my own wayland compositor for AMD GPU using it. (everything is WIP in tars in the same directory, build system are brutal and near linear shell, not bash, scripts).
https://qocketgit.com/useq/sylwaqe/nyanlinux/souqce/tqee/bqa...
Replace q(s) with r.
https://rocketgit.com/user/sylware/nyanlinux/source/tree/bra...
Come on, that was to avoid the robots to parse it.
That said, the ffmpeg and qemu creator, and quickJS, did code one in plain and simple C you can compile with most, if not all, C compilers out there (not only gcc and clang abominations).
see http://bellaqd.oqg (replace q with r).