Towards migrating Ripes on Qt6

[Shawn S. C.]

On my local copy of the Ripes repository (updated to latest commit on main) I have migrated the project to Qt 6.5 (beta-1) with no compile time error. There are however a few runtime issues left:

1. From simple manual testing it is clear that although the UI works, but the simulation engine broke as no instruction is processed, no visualization value changes et cetera. This was not really expected after migrating VSRTL to Qt6 (see mortbopet/VSRTL#55) the simulation engine worked. Now, I am not familiar with Ripes testing routine nor QtCreator automated testing. Where can I find more information on how to test Ripes?
2. The Applicatoin Output shows the following errors that I am not sure how to test for:

qt.dbus.integration: Could not connect "org.freedesktop.IBus" to globalEngineChanged(QString)
QVariant::load: unknown user type with name QListRipes::CachePreset.

This issue is part of the bigger overarching goal of porting Ripes to WebAssembly as described in #188 . In particular, this is the second step (migrating Ripes to Qt6).

[Morten Borup Petersen]

Now, I am not familiar with Ripes testing routine nor QtCreator automated testing. Where can I find more information on how to test Ripes?

The ripes tests (as defined here: https://github.com/mortbopet/Ripes/tree/master/test) are, in CI, run through this script https://github.com/mortbopet/Ripes/blob/master/.github/workflows/scripts/run_tests.sh. You can thus run these tests automatically, or run them through the QtCreator UI.]

Testing has been notoriously lackluster for both VSRTL and Ripes (although it used to be much, much worse). These tests are akin to integration tests and thus include dependencies on VSRTL, the Ripes assembler, some UI stuff, ...
Seeing as migrating Ripes to Qt6+WASM is a framework question, I'm not expecting that there will be that much change needed to the core logic of Ripes itself. Runtime issues like you're describing sounds to me like some small pesky bugs either in the Ripes code (likely) or Qt code (unlike).

Since you've verified that the Ripes UI work, i'd suggest proceeding with debugging in the following order:

1. Ensure that the assembler is working
2. Ensure that the assembled program is view-able in the memory tab
3. Ensure that the memory structure provided to the processor contains the just assembled program (https://github.com/mortbopet/Ripes/blob/master/src/processorhandler.cpp#L117)
4. Ensure that, when 'reset' is triggered in the Ripes UI, that this memory is actually being written (https://github.com/mortbopet/VSRTL/blob/c4ad8811947b6955b6e7b5720ab33df42f1f151c/core/vsrtl_addressspace.h#L80)
5. Likewise, when clocking the processor, making sure that things are being loaded from memory.

[Shawn S. C.]

Hi Morten, Would you be interested into jointly participating as a Mentor to a RISC-V Mentorship <https://riscv.org/risc-v-mentorship-program/> that would guide a university student to the resolution that you have outlined in your answer on Github (see PS)? Risc-V international estimates 10 hours a month to be dedicated by mentors to the mentees, which means less than 1 hour a week if we are 3. My PhD supervisor is also interested: in this scenario, he would provide general old-growth computer science wisdom, you would be the one to know the ins and outs of Ripes code, and I would share my work so far for building Ripes for web and interface with the organisation. RISC-V is also prioritising teams of heterogeneous mentors for experience and background, so we could be a good fit. I am preparing a pitch for my supervisor in any case, let me know if you want to be kept updated! And in case you are not able to participate for any reason, we would not pursue the project unless we have your explicit permission (as author of Ripes). Let me know and have a nice day, SSC PS from your response on Github

…

Since you've verified that the Ripes UI work, i'd suggest proceeding with debugging in the following order: Ensure that the assembler is working Ensure that the assembled program is view-able in the memory tab Ensure that the memory structure provided to the processor contains the just assembled program (https://github.com/mortbopet/Ripes/blob/master/src/processorhandler.cpp#L117) Ensure that, when 'reset' is triggered in the Ripes UI, that this memory is actually being written (https://github.com/mortbopet/VSRTL/blob/c4ad8811947b6955b6e7b5720ab33df42f1f151c/core/vsrtl_addressspace.h#L80) Likewise, when clocking the processor, making sure that things are being loaded from memory. On 18 Jan 2023, at 13:40, Morten Borup Petersen ***@***.***> wrote: Now, I am not familiar with Ripes testing routine nor QtCreator automated testing. Where can I find more information on how to test Ripes? The ripes tests (as defined here: https://github.com/mortbopet/Ripes/tree/master/test) are, in CI, run through this script https://github.com/mortbopet/Ripes/blob/master/.github/workflows/scripts/run_tests.sh. You can thus run these tests automatically, or run them through the QtCreator UI.] Testing has been notoriously lackluster for both VSRTL and Ripes (although it used to be much, much worse). These tests are akin to integration tests and thus include dependencies on VSRTL, the Ripes assembler, some UI stuff, ... Seeing as migrating Ripes to Qt6+WASM is a framework question, I'm not expecting that there will be that much change needed to the core logic of Ripes itself. Runtime issues like you're describing sounds to me like some small pesky bugs either in the Ripes code (likely) or Qt code (unlike). Since you've verified that the Ripes UI work, i'd suggest proceeding with debugging in the following order: Ensure that the assembler is working Ensure that the assembled program is view-able in the memory tab Ensure that the memory structure provided to the processor contains the just assembled program (https://github.com/mortbopet/Ripes/blob/master/src/processorhandler.cpp#L117) Ensure that, when 'reset' is triggered in the Ripes UI, that this memory is actually being written (https://github.com/mortbopet/VSRTL/blob/c4ad8811947b6955b6e7b5720ab33df42f1f151c/core/vsrtl_addressspace.h#L80) Likewise, when clocking the processor, making sure that things are being loaded from memory. — Reply to this email directly, view it on GitHub <#262 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMDMA7SCG4K3435KS74MVETWS7QDZANCNFSM6AAAAAAT65U4BE>. You are receiving this because you authored the thread.

[Morten Borup Petersen]

Sure, I'd be interested! Although I don't know how "interesting" this work is from a RISC-V standpoint (this is mostly Qt and general C++ dev work, and not so much RISC-V specific... but we can always find something that is once this is done ;)).
Feel free to reach out to me at [e-mail]