Open magiwanders opened 1 year ago
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:
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 https://github.com/mortbopet/Ripes/issues/262#issuecomment-1386993480, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMDMA7SCG4K3435KS74MVETWS7QDZANCNFSM6AAAAAAT65U4BE. You are receiving this because you authored the thread.
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 mpetersen@microsoft.com
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:
This issue is part of the bigger overarching goal of porting Ripes to WebAssembly as described in mortbopet/Ripes#188 . In particular, this is the second step (migrating Ripes to Qt6).