Compatibility with other Simulators

[mortbopet]

Compatibility with other Simulators

[mortbopet]

Yes, the use of a0 for environment calls is to match what venus does. However, i would be very open to aligning with the gnu toolchain or some other standard, and i think there is great value in aligning the three applications (Venus, Ripes and RARS) given that each application is a valuable teaching tool on its own, whilst still complementing each other.

I have not implementing a testing interface for Ripes - embarrassingly enough, most testing of Ripes is manual testing. The reason is, that there exists a high degree of coupling between the UI, assembler and simulator, which makes headless testing quite awkward.
There is currently no active development on Ripes, given that i am focusing most of my time on VSRTL. Once in a stable state, VSRTL is intended to be used in a revised version of Ripes, which should make a lot of things - including testing - much simpler.

I have considered creating a temporary testing interface for Ripes which would be able to execute unit tests, albeit slowly. This has however not yet been done - mostly because of my focus on VSRTL. But given your test suite, i'll see if i can get something implemented soon.

[TheThirdOne]

I manually tested a few of RARs tests and it seems like aside from system calls, they're fairly compatible. A few missing directives like .global and .space stopped a copy paste compilation. I would be willing to add small compatibility features like those if it would be merged in.

Once in a stable state, VSRTL is intended to be used in a revised version of Ripes, which should make a lot of things - including testing - much simpler

How much is it intended to change? Should I hold off on adding directives and such until the revised version is completed?

Also, I found a bug in mulhu. I believe it will only ever output 0 because the inputs are multiplied as uint32_t instead of uint64_t.

Here is a snippet of a failing test from RARS's test:

.text
 main:

test_7:
 li x1, 0x80000000
 li x2, 0xffff8000
 mulhu x30, x1, x2 # ALU ouputs 0 
 li x29, 0x7fffc000
 bne x30, x29, fail

pass:
 li a0, 42
 li a7, 93
 ecall
fail:
 li a0, 0
 li a7, 93
 ecall

If you want I can manually test some more instructions that might be problematic.

[mortbopet]

I manually tested a few of RARs tests and it seems like aside from system calls, they're fairly compatible. A few missing directives like .global and .space stopped a copy paste compilation. I would be willing to add small compatibility features like those if it would be merged in.

This would purely require changes in the assembler, and are welcome changes.

Once in a stable state, VSRTL is intended to be used in a revised version of Ripes, which should make a lot of things - including testing - much simpler

How much is it intended to change? Should I hold off on adding directives and such until the revised version is completed?

These changes will be on a simulator level and will not be connected to anything assembler related, so as above.

Also, I found a bug in mulhu. I believe it will only ever output 0 because the inputs are multiplied as uint32_t instead of uint64_t.

Thank you for finding the issue! I'll take a look on the failing instruction asap.

If you want I can manually test some more instructions that might be problematic.

If you have the time, that would be much appreciated. But to not waste anyones time, having just some form of automatic testing support in Ripes should be a priority.

[mortbopet]

a6da9b9 introduces rudimentary unit-testing abilities but is still a step up from manual testing. Feel free to add unit tests by adding files in https://github.com/mortbopet/Ripes/tree/master/test and in the https://github.com/mortbopet/Ripes/blob/master/test/tests.qrc file

[mortbopet]

@TheThirdOne Are you still in active development of RARS? I would very much like to get in touch with you regarding future simulators and RISC-V tools.

[TheThirdOne]

@mortbopet, I'm not sure I'd call it "active development", but I generally spend a few hours a week working on new features (currently loading elf files and a better logging system).

I would be happy to talk with you about RISC-V simulators and tools.

[mortbopet]

@mortbopet, I'm not sure I'd call it "active development", but I generally spend a few hours a week working on new features (currently loading elf files and a better logging system).

I would be happy to talk with you about RISC-V simulators and tools.

Sounds great! I'd like to continue over e-mail, however i generally avoid sharing it on public forums (GitHub really needs a DM feature!). If you have linkedin, you can catch me here.

[TheThirdOne]

I have sent an email off to your live dot dk email.