Support RV64

[TheThirdOne]

When I initially ported RARS, I did not include support for rv64 because it seemed unnecessary. However, as time has passed it has seemed more and more worthwhile.

The two big reasons to support rv64 as I see it are:

• The Patterson and Hennessy book uses rv64
• A bunch of tooling for rv32 is hard to get correctly installed
  • notably support for rv32 has yet to be merged into glibc

I don't expect to handle this soon, but if this is an important feature to you please do tell me.

The discussion in #73 prompted this issue's creation.

[TheThirdOne]

Notes from a quick read of the specification:

• The RV64 section explains how to update an rv32 system, so aside from XLEN changes the rest of rv32 can be ignored.
• 6 bit immediates are a little bit of an issue, but getting it working even if incorrect programs behave strangely is still good.
• Shift instructions change what bits they ignore between bases
• BigInteger will be needed for M
• FCVT.L.? is new in both F and D
• FMV.X.D is a new instruction in D

Overall, not too bad. It will require some time, but I don't think there is anything tricky. Adding additional testing for RV64 seems like the biggest source of work.

[BenjaminBeichler]

You may also update the printInt-Syscalls, as all of them (also eg. prinIntHex), are not able to print 64bit values. Or we may specify new syscalls and mark the old one for 32bit numbers.

[BenjaminBeichler]

Maybe you should also review the other syscalls (e.g. sleep, rand, ...) whether you need a change for 64bit

[TheThirdOne]

Thanks for mentioning system calls. I had actually forgotten to consider them. I think I'll have to do a once over on all of them to see if each needs to be updated at all.

The system calls inherited from MARS and SPIM are in a little bit of a weird place as neither of those simulators supported 64 bit registers. I think I would probably be inclined to leave them truncating 64 bit values. I'm torn on whether or not to make a 64 bit version of them in that case. On one hand they take a lot of code and system call numbers as compared to the Linux equivalents (because there are so many). However, students definitely do use them because they provide a simpler interface than the Linux alternatives and I don't want to make 64 bit mode better for students by allowing direct reference to Patterson and Hennessy and worse because they can't read and write values as easily.

For the Linux system calls, they should have defined semantics for 64 vs 32 bit so it should be easy to make them work.

[BenjaminBeichler]

I think it is maybe enough to document the truncation, and add only the print/readInt64 at the end (and maybe refer to the syscall-number in the 32bit readInt).

From my perspective, the Linux API is nice, but for my exercises I know the students are already overwhelmed by the easy interface :-) I also haven't used the stuff, since I think the simulator has a different focus; a learning tool for assembler programming with easy inspectable state.

Nonetheless, I also understand your point, so I can't help you with the decision ...

[TheThirdOne]

I just published the release that adds support for this (https://github.com/TheThirdOne/rars/releases/tag/v1.5).