cvut / QtMips

MIPS CPU emulator
https://github.com/cvut/QtMips
GNU General Public License v3.0
52 stars 12 forks source link

About development of QtMips #12

Closed kchasialis closed 1 year ago

kchasialis commented 3 years ago

Hello, my plan is to extend the functionality of this tool (by adding branch predictors and L2 cache for start) but I have issues in loading and building the project on QtCreator and start developing from there while also keeping the current features intact.

To give you a better idea so you can help me further, what I tried to do is this :

I moved "qtmips_asm, qtmips_gui, qtmips_osemu, qtmips_machine" into the project directory and configured the .pro files accordingly. (I want to load the gui version for now)

I installed emscripten by following the instructions here : https://emscripten.org/docs/getting_started/downloads.html

and also installed elfutils using apt-get.

My Kits configurations are the following :

qt_kits_conf

My Compilers configurations are the following :

qt_compilers_conf

My Qt Versions configurations are the following :

qt_qtversion_conf

My CMake configurations are the following :

qt_cmake_conf

The build errors that I am getting are the following :

qt_build_errors

Any help would be much appreciated, I have tried many things that didn't work.

Thanks in advance, Kostas.

ppisa commented 3 years ago

Hello Kostas,

the first it is great that you like the program and I hope that it servers you well to study how simple and pipelined processor works.

In general, cooperation, extensions and sample are welcomed, there is in the fact separate repository to collect examples for QtMips https://github.com/cvut/QtMips-Playground and we have examples from our lectures and templates for students tasks in the subject related repository https://gitlab.fel.cvut.cz/b35apo/stud-support directory seminaries/binrep/qtmips_binrep and master/seminaries/qtmips.

As for the branch prediction visualization, it would be great enhancements. We use MARS emulator to demonstrate this for now. On the other hand, on MIPS with delay slot and branches resolved in decode state there would be no real speedup when branch predictor is used. But for education it has purpose.

On the other hand, we are limited in time and our long term goal is to demonstrate CPU architectures principles on open RISC-V architecture. I would like to start from it even in 2017 when we started QtMips, but my team has been limited and I know that switch all lectures and materials to RISC-V is impossible at that time so we decided to continue with MIPS, defacto standard for education at that time. There we are now. But I would like to switch to RISC-V for 2021/2022 year. Two our excellent students works on preparation for that switch in their fork https://github.com/hollmmax/QtMips and when the memory model is updated and tested on MIPS then we switch architecture and start that as base for RISC-V project https://github.com/cvut/qtrvsim .

I need to reveal this plan to you because our plan is to switch QtMips in (mostly) maintenance mode now. In a long term, we consider even to update it back from RISC-V version if time/enthusiasts/students appear.

So if you changes are clean, they will be accepted but we have limited time for this project now, priority is RISC-V kickoff with same features. We have considered to combine both architectures in single program, but it would make program much more complex and barrier for new students to enter into its development, so the decision is simple simulator architecture only for single target.

My default build system is Debian. The next simple command sequence should work when dependencies are resolved

git clone git@github.com:cvut/QtMips.git
cd QtMips
/usr/lib/x86_64-linux-gnu/qt5/bin/qmake
make

Another option is to build package

git clone git@github.com:cvut/QtMips.git
cd QtMips
dpkg-buildpackage

As for interactive build in QtCreator, my setup is

qtcreator-qt-5 11-1

qtcreator-qt-6 11-1

Build target is set to Debug/qtmips_gui

As for the emscripten build, I use own Qt library build and in this case I use simplified libelf included directly into QtMips, see rebased branch libelf-included , because setup matching separate libelf export from emscripten environment did not work for me well.

Then I build the QtMips for emscripten from qmake qtmips.pro file from clean build directory by

/opt/qt5/wasm-emscripten/qt/bin/qmake "CONFIG+=static" "CONFIG+=staticlib" -recursive ../QtMips/qtmips.pro

I have again my own cross-build of Windows Qt5 on my Debian GNU/Linux system build by i686-w64-mingw32. I use next config for out of the source tree Windows build

/usr/i686-w64-mingw32/qt/bin/qmake "CONFIG+=static" "CONFIG+=staticlib" -recursive ../QtMips/qtmips.pro

So I hope these hints helps. Send some long in case error. For your qtcreator setup, are you using standard install from Ubuntu package or downloaded binary install? I am not expert for Qt, but if you have problems I would discuss the advice with my colleague who is expert for Qt and works on large Qt based applications https://github.com/silicon-heaven and other personal ones https://github.com/fvacek so we should be able to provide you hints.

Best wishes,

Pavel

ppisa commented 3 years ago

Hmm... it seems that you have not installed libelf-dev package, is that a case?

And you do not need to install Emscripten for native builds.

kchasialis commented 3 years ago

Thanks for you reply,

I am a student at the National and Kapodistrian University of Athens (Greece) and my bachelor thesis will be about updating QtMips to a QtRISC version that uses RISC-V architecture instructions. It seems you are seeking a student for just that purpose. What a coincidence!

Adding a branch predictor and a L2 cache on the current version will be implemented in order for me to familiarize myself with the code of this project and how it works. The main idea is to implement a RISC-V version of this project.

I am looking forward to discussing further with you about this project.

Best wishes.

Kostas.

Στις Σάβ, 12 Δεκ 2020 στις 1:37 π.μ., ο/η Pavel Pisa < notifications@github.com> έγραψε:

Hello Kostas,

the first it is great that you like the program and I hope that it servers you well to study how simple and pipelined processor works.

In general, cooperation, extensions and sample are welcomed, there is in the fact separate repository to collect examples for QtMips https://github.com/cvut/QtMips-Playground and we have examples from our lectures and templates for students tasks in the subject related repository https://gitlab.fel.cvut.cz/b35apo/stud-support directory seminaries/binrep/qtmips_binrep https://gitlab.fel.cvut.cz/b35apo/stud-support/-/tree/master/seminaries/binrep/qtmips_binrep and master/seminaries/qtmips https://gitlab.fel.cvut.cz/b35apo/stud-support/-/tree/master/seminaries/qtmips .

As for the branch prediction visualization, it would be great enhancements. We use MARS emulator to demonstrate this for now. On the other hand, on MIPS with delay slot and branches resolved in decode state there would be no real speedup when branch predictor is used. But for education it has purpose.

On the other hand, we are limited in time and our long term goal is to demonstrate CPU architectures principles on open RISC-V architecture. I would like to start from it even in 2017 when we started QtMips, but my team has been limited and I know that switch all lectures and materials to RISC-V is impossible at that time so we decided to continue with MIPS, defacto standard for education at that time. There we are now. But I would like to switch to RISC-V for 2021/2022 year. Two our excellent students works on preparation for that switch in their fork https://github.com/hollmmax/QtMips and when the memory model is updated and tested on MIPS then we switch architecture and start that as base for RISC-V project https://github.com/cvut/qtrvsim .

I need to reveal this plan to you because our plan is to switch QtMips in (mostly) maintenance mode now. In a long term, we consider even to update it back from RISC-V version if time/enthusiasts/students appear.

So if you changes are clean, they will be accepted but we have limited time for this project now, priority is RISC-V kickoff with same features. We have considered to combine both architectures in single program, but it would make program much more complex and barrier for new students to enter into its development, so the decision is simple simulator architecture only for single target.

My default build system is Debian. The next simple command sequence should work when dependencies are resolved

git clone git@github.com:cvut/QtMips.git cd QtMips /usr/lib/x86_64-linux-gnu/qt5/bin/qmake make

Another option is to build package

git clone git@github.com:cvut/QtMips.git cd QtMips dpkg-buildpackage

As for interactive build in QtCreator, my setup is

[image: qtcreator-qt-5 11-1] https://user-images.githubusercontent.com/1687989/101964055-59488400-3c10-11eb-9907-c747ef7eb684.png

[image: qtcreator-qt-6 11-1] https://user-images.githubusercontent.com/1687989/101964068-66657300-3c10-11eb-8c56-8dffb4c6e4d8.png

Build target is set to Debug/qtmips_gui

As for the emscripten build, I use own Qt library build and in this case I use simplified libelf included directly into QtMips, see rebased branch libelf-included , because setup matching separate libelf export from emscripten environment did not work for me well.

Then I build the QtMips for emscripten from qmake qtmips.pro file from clean build directory by

/opt/qt5/wasm-emscripten/qt/bin/qmake "CONFIG+=static" "CONFIG+=staticlib" -recursive ../QtMips/qtmips.pro

I have again my own cross-build of Windows Qt5 on my Debian GNU/Linux system build by i686-w64-mingw32. I use next config for out of the source tree Windows build

/usr/i686-w64-mingw32/qt/bin/qmake "CONFIG+=static" "CONFIG+=staticlib" -recursive ../QtMips/qtmips.pro

So I hope these hints helps. Send some long in case error. For your qtcreator setup, are you using standard install from Ubuntu package or downloaded binary install? I am not expert for Qt, but if you have problems I would discuss the advice with my colleague who is expert for Qt and works on large Qt based applications https://github.com/silicon-heaven and other personal ones https://github.com/fvacek so we should be able to provide you hints.

Best wishes,

Pavel

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/cvut/QtMips/issues/12#issuecomment-743482462, or unsubscribe https://github.com/notifications/unsubscribe-auth/AINQWQXOYAVC6AHTSKEFSGTSUKUNBANCNFSM4UXIXWRQ .

kchasialis commented 3 years ago

About the build errors, I fixed it by allowing QtCreator clone the project from github and do the configuration of the files automatically.

The problem was that I had the wrong structure of the project and QtCreator did not recognize the separate .pro files for each subdirectory. Anyway, thanks for the reply and I am really looking forward to discussing about the update to RISC-V (please see previous reply).

Thanks, Kostas.

Στις Σάβ, 12 Δεκ 2020 στις 1:37 π.μ., ο/η Pavel Pisa < notifications@github.com> έγραψε:

Hello Kostas,

the first it is great that you like the program and I hope that it servers you well to study how simple and pipelined processor works.

In general, cooperation, extensions and sample are welcomed, there is in the fact separate repository to collect examples for QtMips https://github.com/cvut/QtMips-Playground and we have examples from our lectures and templates for students tasks in the subject related repository https://gitlab.fel.cvut.cz/b35apo/stud-support directory seminaries/binrep/qtmips_binrep https://gitlab.fel.cvut.cz/b35apo/stud-support/-/tree/master/seminaries/binrep/qtmips_binrep and master/seminaries/qtmips https://gitlab.fel.cvut.cz/b35apo/stud-support/-/tree/master/seminaries/qtmips .

As for the branch prediction visualization, it would be great enhancements. We use MARS emulator to demonstrate this for now. On the other hand, on MIPS with delay slot and branches resolved in decode state there would be no real speedup when branch predictor is used. But for education it has purpose.

On the other hand, we are limited in time and our long term goal is to demonstrate CPU architectures principles on open RISC-V architecture. I would like to start from it even in 2017 when we started QtMips, but my team has been limited and I know that switch all lectures and materials to RISC-V is impossible at that time so we decided to continue with MIPS, defacto standard for education at that time. There we are now. But I would like to switch to RISC-V for 2021/2022 year. Two our excellent students works on preparation for that switch in their fork https://github.com/hollmmax/QtMips and when the memory model is updated and tested on MIPS then we switch architecture and start that as base for RISC-V project https://github.com/cvut/qtrvsim .

I need to reveal this plan to you because our plan is to switch QtMips in (mostly) maintenance mode now. In a long term, we consider even to update it back from RISC-V version if time/enthusiasts/students appear.

So if you changes are clean, they will be accepted but we have limited time for this project now, priority is RISC-V kickoff with same features. We have considered to combine both architectures in single program, but it would make program much more complex and barrier for new students to enter into its development, so the decision is simple simulator architecture only for single target.

My default build system is Debian. The next simple command sequence should work when dependencies are resolved

git clone git@github.com:cvut/QtMips.git cd QtMips /usr/lib/x86_64-linux-gnu/qt5/bin/qmake make

Another option is to build package

git clone git@github.com:cvut/QtMips.git cd QtMips dpkg-buildpackage

As for interactive build in QtCreator, my setup is

[image: qtcreator-qt-5 11-1] https://user-images.githubusercontent.com/1687989/101964055-59488400-3c10-11eb-9907-c747ef7eb684.png

[image: qtcreator-qt-6 11-1] https://user-images.githubusercontent.com/1687989/101964068-66657300-3c10-11eb-8c56-8dffb4c6e4d8.png

Build target is set to Debug/qtmips_gui

As for the emscripten build, I use own Qt library build and in this case I use simplified libelf included directly into QtMips, see rebased branch libelf-included , because setup matching separate libelf export from emscripten environment did not work for me well.

Then I build the QtMips for emscripten from qmake qtmips.pro file from clean build directory by

/opt/qt5/wasm-emscripten/qt/bin/qmake "CONFIG+=static" "CONFIG+=staticlib" -recursive ../QtMips/qtmips.pro

I have again my own cross-build of Windows Qt5 on my Debian GNU/Linux system build by i686-w64-mingw32. I use next config for out of the source tree Windows build

/usr/i686-w64-mingw32/qt/bin/qmake "CONFIG+=static" "CONFIG+=staticlib" -recursive ../QtMips/qtmips.pro

So I hope these hints helps. Send some long in case error. For your qtcreator setup, are you using standard install from Ubuntu package or downloaded binary install? I am not expert for Qt, but if you have problems I would discuss the advice with my colleague who is expert for Qt and works on large Qt based applications https://github.com/silicon-heaven and other personal ones https://github.com/fvacek so we should be able to provide you hints.

Best wishes,

Pavel

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/cvut/QtMips/issues/12#issuecomment-743482462, or unsubscribe https://github.com/notifications/unsubscribe-auth/AINQWQXOYAVC6AHTSKEFSGTSUKUNBANCNFSM4UXIXWRQ .

ppisa commented 3 years ago

Hello Kostas,

it is great. As for the branch predictor and L2 cache demonstration, they are on our long term radar, but there is no plan to work on them during next development period. So if you take these tasks then I can guarantee you that you do not fall into risk that somebody else from my students would take this task during next 9 months.

L2 cache should be easy, cache object can be reused, cascaded etc... and then there can be added another item (L2 Cache) to Direct and Cached in https://github.com/cvut/QtMips/blob/master/qtmips_gui/memorydock.cpp#L59 . Problem is that there would be collision with memory model rewrite now. I hope that @jdupak would be ready soon.

As fr the branch prediction, it should be relatively independent and porting to RISC-V version should be easy even if you start in MIPS one. I would be happy if we can demosntrate single and two bit Smith branch predictor in QtMips. Then some variant with global history only or combined predictor would be great. You can start with new dock window. Then you need to decide, if branch predictor state is represented by some table or graphics canvas similar to the cache one. Each has its advantage, from small index range the graphics can visualize each FSM state graphically. But it would be hard to navigate when the index range is higher (32 sets...). Another possibility is to have table but when it is updated or you click on line with FSM state then it is visualized in single common small FSM visualization canvas. So you can consider and try some such implementation. As I have already said, on MIPS there can be computed statistic in the predictor but there is no reason to influence core state. SO it can be pure core state observer. On RISC-V it can be enhanced because there it can help to reduce some cycles in correctly predicted decision, target. Etc.. Other think is if you build BHT only or even BTB.

By the way, I have looked at your course and your professors has prepared nice documentation for students to easy their start with the simulator. But it has disadvantage for broader use that it is in Greek language only. Please, can you ask if there is plan to translate it in English or if you can get presentation source and translate it yourself. I think it would provide great service to broader community. We can put link to the result or PDF file on QtMips wiki or somewhere else.

Best wishes,

Pavel

kchasialis commented 3 years ago

Hello, we plan on adding some other features on QtMips and I was wondering if you agree with them and if you have programmed them to be done anyway.

The first feature is adding more input/output syscalls like read/print floats, integers etc.

The second one is adding floating point support.

Finally, I discussed with my professor Dimitris Gizopoulos and we agreed on translating the slides in English and send them back to you.

Best, Kostas.

https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon Virus-free. www.avast.com https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Στις Τρί, 15 Δεκ 2020 στις 10:06 π.μ., ο/η Pavel Pisa < notifications@github.com> έγραψε:

Hello Kostas,

it is great. As for the branch predictor and L2 cache demonstration, they are on our long term radar, but there is no plan to work on them during next development period. So if you take these tasks then I can guarantee you that you do not fall into risk that somebody else from my students would take this task during next 9 months.

L2 cache should be easy, cache object can be reused, cascaded etc... and then there can be added another item (L2 Cache) to Direct and Cached in https://github.com/cvut/QtMips/blob/master/qtmips_gui/memorydock.cpp#L59 . Problem is that there would be collision with memory model rewrite now. I hope that @jdupak https://github.com/jdupak would be ready soon.

As fr the branch prediction, it should be relatively independent and porting to RISC-V version should be easy even if you start in MIPS one. I would be happy if we can demosntrate single and two bit Smith branch predictor in QtMips. Then some variant with global history only or combined predictor would be great. You can start with new dock window. Then you need to decide, if branch predictor state is represented by some table or graphics canvas similar to the cache one. Each has its advantage, from small index range the graphics can visualize each FSM state graphically. But it would be hard to navigate when the index range is higher (32 sets...). Another possibility is to have table but when it is updated or you click on line with FSM state then it is visualized in single common small FSM visualization canvas. So you can consider and try some such implementation. As I have already said, on MIPS there can be computed statistic in the predictor but there is no reason to influence core state. SO it can be pure core state observer. On RISC-V it can be enhanced because there it can help to reduce some cycles in correctly predicted decision, target. Etc.. Other think is if you build BHT only or even BTB.

By the way, I have looked at your course and your professors has prepared nice documentation for students to easy their start with the simulator. But it has disadvantage for broader use that it is in Greek language only. Please, can you ask if there is plan to translate it in English or if you can get presentation source and translate it yourself. I think it would provide great service to broader community. We can put link to the result or PDF file on QtMips wiki or somewhere else.

Best wishes,

Pavel

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/cvut/QtMips/issues/12#issuecomment-745124117, or unsubscribe https://github.com/notifications/unsubscribe-auth/AINQWQWTGWHBEWMQHIM5MZ3SU4KHHANCNFSM4UXIXWRQ .

kchasialis commented 3 years ago

Also, I was wondering if a developer has some free time to guide me through the code execution path.

For example, suppose we load the input elf file into the simulator, I would like to know how/where is it parsed, how/where are the mips instructions generated, how/where are the delay slots added? etc.

This would really speed up the development on my end. However, I totally understand that you may not be available due to other responsibilities and that is totally fine.

Thanks.

Στις Τρί, 15 Δεκ 2020 στις 10:06 π.μ., ο/η Pavel Pisa < notifications@github.com> έγραψε:

Hello Kostas,

it is great. As for the branch predictor and L2 cache demonstration, they are on our long term radar, but there is no plan to work on them during next development period. So if you take these tasks then I can guarantee you that you do not fall into risk that somebody else from my students would take this task during next 9 months.

L2 cache should be easy, cache object can be reused, cascaded etc... and then there can be added another item (L2 Cache) to Direct and Cached in https://github.com/cvut/QtMips/blob/master/qtmips_gui/memorydock.cpp#L59 . Problem is that there would be collision with memory model rewrite now. I hope that @jdupak https://github.com/jdupak would be ready soon.

As fr the branch prediction, it should be relatively independent and porting to RISC-V version should be easy even if you start in MIPS one. I would be happy if we can demosntrate single and two bit Smith branch predictor in QtMips. Then some variant with global history only or combined predictor would be great. You can start with new dock window. Then you need to decide, if branch predictor state is represented by some table or graphics canvas similar to the cache one. Each has its advantage, from small index range the graphics can visualize each FSM state graphically. But it would be hard to navigate when the index range is higher (32 sets...). Another possibility is to have table but when it is updated or you click on line with FSM state then it is visualized in single common small FSM visualization canvas. So you can consider and try some such implementation. As I have already said, on MIPS there can be computed statistic in the predictor but there is no reason to influence core state. SO it can be pure core state observer. On RISC-V it can be enhanced because there it can help to reduce some cycles in correctly predicted decision, target. Etc.. Other think is if you build BHT only or even BTB.

By the way, I have looked at your course and your professors has prepared nice documentation for students to easy their start with the simulator. But it has disadvantage for broader use that it is in Greek language only. Please, can you ask if there is plan to translate it in English or if you can get presentation source and translate it yourself. I think it would provide great service to broader community. We can put link to the result or PDF file on QtMips wiki or somewhere else.

Best wishes,

Pavel

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/cvut/QtMips/issues/12#issuecomment-745124117, or unsubscribe https://github.com/notifications/unsubscribe-auth/AINQWQWTGWHBEWMQHIM5MZ3SU4KHHANCNFSM4UXIXWRQ .

ppisa commented 3 years ago

Hello Kostas,

as for the manual, if you have some stable URL for the course and or manual, we can add link to it there. Other option is to put it onto QtMips wiki... or some other materials... I believe it could help others and bring even more interest in your course.

As for the syscalls, I would prefer to keep them really matching MIPS (then RISC-V) Linux kernel syscalls numbers. I agree to implement more SPIM/MARS ones for education. But no specific ones like printf etc... If you want to run C program with printf, malloc, etc., then we have setup with Newlib or muslibc tested. Simple one for our students is there

https://gitlab.fel.cvut.cz/b35apo/stud-support/-/tree/master/seminaries/qtmips/os-emu-example

As for floats etc... I am not sure if it worth to invest so much time into MIPS edition. There are two ways how to implement them, one is directly implement them as addon outside of pipeline in MEM phase, other is to implement them in decode and then pass FPU registers numbers through pipeline and implement FPU in EXE and MEM phase. Question is if to visualize FPU data path. For sure, its visualization cannot be unconditional, it would distract students when they start. FPU registers can be separate dock as well.

I think that branch prediction is the good first goal. It is relatively separated, porting to RISC-V version would be relativelly straightforward.

We can find some time to guide you through code. But you should read first Karel Koci thesis. Actual implementation is based on it and architecture has been well defined. On the other hand, I have corrected quite lot of internals and added quite lot of functionality.

ELF file is parsed in ProgramLoader::ProgramLoader(QString file) : elf_file(file) https://github.com/cvut/QtMips/blob/7c38d97da0f188752ff8863478b5ac130d4d93c1/qtmips_machine/programloader.cpp#L50

Loadable sections are fed byte by byte to the memory model in void ProgramLoader::to_memory(Memory *mem) https://github.com/cvut/QtMips/blob/7c38d97da0f188752ff8863478b5ac130d4d93c1/qtmips_machine/programloader.cpp#L107

The actual instruction execution is realized by functions representing stages combinatorics logic. Its starts there

https://github.com/cvut/QtMips/blob/7c38d97da0f188752ff8863478b5ac130d4d93c1/qtmips_machine/core.cpp#L265

struct Core::dtFetch Core::fetch(bool skip_break) struct Core::dtDecode Core::decode(const struct dtFetch &dt) struct Core::dtExecute Core::execute(const struct dtDecode &dt) struct Core::dtMemory Core::memory(const struct dtExecute &dt) void Core::writeback(const struct dtMemory &dt) bool Core::handle_pc(const struct dtDecode &dt)

Same as if you implement it in Verilog or in VHDL, the single cycle CPU is build by serial interconnection of these functions run sequentially in the single clock period

void CoreSingle::do_step(bool skip_break) https://github.com/cvut/QtMips/blob/7c38d97da0f188752ff8863478b5ac130d4d93c1/qtmips_machine/core.cpp#L698

In the pipeline version these stage functions operate between interstage registers, struct variable which are part of the Core object. In this case last stage register is fill by processed previous stage state (MEM->WB), then when input interstage is processed and de facto empty, preceding stage function (EXE->MEM) is executed....

void CorePipelined::do_step(bool skip_break) https://github.com/cvut/QtMips/blob/7c38d97da0f188752ff8863478b5ac130d4d93c1/qtmips_machine/core.cpp#L757

As for the actual decode of the instruction code to the ID->EXE signals, they are generated from description

static const struct InstructionMap instruction_map[] https://github.com/cvut/QtMips/blob/7c38d97da0f188752ff8863478b5ac130d4d93c1/qtmips_machine/instruction.cpp#L704

The decode starts by indexing the first level table by opcode field. If the subclass is not NULL then the other bit field is extracted and used to index in more detailed table.

The map of instruction descriptions sorted by mnemonic code is generated at QtMips startup. It is used for assembler and interactive code editor.

Generally attempt is to keep code simple, not optimized too much to make it easy readable. Opcodes tables match in the style these in reference CA book, stage and core logic matches basic HDL design so this C++ code can be used by students even as help tool for their Verilog design in Advanced Processor Architectures class and vice versa HDL design can be used as introduction to QtMips implementation.

Best wishes,

Pavel

kchasialis commented 3 years ago

Thanks, I'll check them out.

Στις Τετ, 16 Δεκ 2020 στις 5:38 μ.μ., ο/η Pavel Pisa < notifications@github.com> έγραψε:

Hello Kostas,

as for the manual, if you have some stable URL for the course and or manual, we can add link to it there. Other option is to put it onto QtMips wiki... or some other materials... I believe it could help others and bring even more interest in your course.

As for the syscalls, I would prefer to keep them really matching MIPS (then RISC-V) Linux kernel syscalls numbers. I agree to implement more SPIM/MARS ones for education. But no specific ones like printf etc... If you want to run C program with printf, malloc, etc., then we have setup with Newlib or muslibc tested. Simple one for our students is there

https://gitlab.fel.cvut.cz/b35apo/stud-support/-/tree/master/seminaries/qtmips/os-emu-example

As for floats etc... I am not sure if it worth to invest so much time into MIPS edition. There are two ways how to implement them, one is directly implement them as addon outside of pipeline in MEM phase, other is to implement them in decode and then pass FPU registers numbers through pipeline and implement FPU in EXE and MEM phase. Question is if to visualize FPU data path. For sure, its visualization cannot be unconditional, it would distract students when they start. FPU registers can be separate dock as well.

I think that branch prediction is the good first goal. It is relatively separated, porting to RISC-V version would be relativelly straightforward.

We can find some time to guide you through code. But you should read first Karel Koci thesis. Actual implementation is based on it and architecture has been well defined. On the other hand, I have corrected quite lot of internals and added quite lot of functionality.

ELF file is parsed in ProgramLoader::ProgramLoader(QString file) : elf_file(file)

https://github.com/cvut/QtMips/blob/7c38d97da0f188752ff8863478b5ac130d4d93c1/qtmips_machine/programloader.cpp#L50

Loadable sections are fed byte by byte to the memory model in void ProgramLoader::to_memory(Memory *mem)

https://github.com/cvut/QtMips/blob/7c38d97da0f188752ff8863478b5ac130d4d93c1/qtmips_machine/programloader.cpp#L107

The actual instruction execution is realized by functions representing stages combinatorics logic. Its starts there

https://github.com/cvut/QtMips/blob/7c38d97da0f188752ff8863478b5ac130d4d93c1/qtmips_machine/core.cpp#L265

struct Core::dtFetch Core::fetch(bool skip_break) struct Core::dtDecode Core::decode(const struct dtFetch &dt) struct Core::dtExecute Core::execute(const struct dtDecode &dt) struct Core::dtMemory Core::memory(const struct dtExecute &dt) void Core::writeback(const struct dtMemory &dt) bool Core::handle_pc(const struct dtDecode &dt)

Same as if you implement it in Verilog or in VHDL, the single cycle CPU is build by serial interconnection of these functions run sequentially in the single clock period

void CoreSingle::do_step(bool skip_break)

https://github.com/cvut/QtMips/blob/7c38d97da0f188752ff8863478b5ac130d4d93c1/qtmips_machine/core.cpp#L698

In the pipeline version these stage functions operate between interstage registers, struct variable which are part of the Core object. In this case last stage register is fill by processed previous stage state (MEM->WB), then when input interstage is processed and de facto empty, preceding stage function (EXE->MEM) is executed....

void CorePipelined::do_step(bool skip_break)

https://github.com/cvut/QtMips/blob/7c38d97da0f188752ff8863478b5ac130d4d93c1/qtmips_machine/core.cpp#L757

As for the actual decode of the instruction code to the ID->EXE signals, they are generated from description

static const struct InstructionMap instruction_map[]

https://github.com/cvut/QtMips/blob/7c38d97da0f188752ff8863478b5ac130d4d93c1/qtmips_machine/instruction.cpp#L704

The decode starts by indexing the first level table by opcode field. If the subclass is not NULL then the other bit field is extracted and used to index in more detailed table.

The map of instruction descriptions sorted by mnemonic code is generated at QtMips startup. It is used for assembler and interactive code editor.

Generally attempt is to keep code simple, not optimized too much to make it easy readable. Opcodes tables match in the style these in reference CA book, stage and core logic matches basic HDL design so this C++ code can be used by students even as help tool for their Verilog design in Advanced Processor Architectures class and vice versa HDL design can be used as introduction to QtMips implementation.

Best wishes,

Pavel

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/cvut/QtMips/issues/12#issuecomment-746491711, or unsubscribe https://github.com/notifications/unsubscribe-auth/AINQWQV54TFPWOCHUWW75MLSVDH6NANCNFSM4UXIXWRQ .

kchasialis commented 3 years ago

By the way, can you tell me what's wrong with the following code?

https://pastebin.com/DRpCuss3

Its purpose is to hit a load-use hazard so I can see for myself how graphics are displayed (if any) and how/where the code flushes the next instruction that should not be executed.

However, it seems to infinitely execute nop instructions after exiting branch instead of exiting the program.

Compiled as follows :

mips-linux-gnu-gcc mips_test.o -o mips_test mips-linux-gnu-gcc -nostdlib mips_test.o -o mips_test

Στις Τετ, 16 Δεκ 2020 στις 5:38 μ.μ., ο/η Pavel Pisa < notifications@github.com> έγραψε:

Hello Kostas,

as for the manual, if you have some stable URL for the course and or manual, we can add link to it there. Other option is to put it onto QtMips wiki... or some other materials... I believe it could help others and bring even more interest in your course.

As for the syscalls, I would prefer to keep them really matching MIPS (then RISC-V) Linux kernel syscalls numbers. I agree to implement more SPIM/MARS ones for education. But no specific ones like printf etc... If you want to run C program with printf, malloc, etc., then we have setup with Newlib or muslibc tested. Simple one for our students is there

https://gitlab.fel.cvut.cz/b35apo/stud-support/-/tree/master/seminaries/qtmips/os-emu-example

As for floats etc... I am not sure if it worth to invest so much time into MIPS edition. There are two ways how to implement them, one is directly implement them as addon outside of pipeline in MEM phase, other is to implement them in decode and then pass FPU registers numbers through pipeline and implement FPU in EXE and MEM phase. Question is if to visualize FPU data path. For sure, its visualization cannot be unconditional, it would distract students when they start. FPU registers can be separate dock as well.

I think that branch prediction is the good first goal. It is relatively separated, porting to RISC-V version would be relativelly straightforward.

We can find some time to guide you through code. But you should read first Karel Koci thesis. Actual implementation is based on it and architecture has been well defined. On the other hand, I have corrected quite lot of internals and added quite lot of functionality.

ELF file is parsed in ProgramLoader::ProgramLoader(QString file) : elf_file(file)

https://github.com/cvut/QtMips/blob/7c38d97da0f188752ff8863478b5ac130d4d93c1/qtmips_machine/programloader.cpp#L50

Loadable sections are fed byte by byte to the memory model in void ProgramLoader::to_memory(Memory *mem)

https://github.com/cvut/QtMips/blob/7c38d97da0f188752ff8863478b5ac130d4d93c1/qtmips_machine/programloader.cpp#L107

The actual instruction execution is realized by functions representing stages combinatorics logic. Its starts there

https://github.com/cvut/QtMips/blob/7c38d97da0f188752ff8863478b5ac130d4d93c1/qtmips_machine/core.cpp#L265

struct Core::dtFetch Core::fetch(bool skip_break) struct Core::dtDecode Core::decode(const struct dtFetch &dt) struct Core::dtExecute Core::execute(const struct dtDecode &dt) struct Core::dtMemory Core::memory(const struct dtExecute &dt) void Core::writeback(const struct dtMemory &dt) bool Core::handle_pc(const struct dtDecode &dt)

Same as if you implement it in Verilog or in VHDL, the single cycle CPU is build by serial interconnection of these functions run sequentially in the single clock period

void CoreSingle::do_step(bool skip_break)

https://github.com/cvut/QtMips/blob/7c38d97da0f188752ff8863478b5ac130d4d93c1/qtmips_machine/core.cpp#L698

In the pipeline version these stage functions operate between interstage registers, struct variable which are part of the Core object. In this case last stage register is fill by processed previous stage state (MEM->WB), then when input interstage is processed and de facto empty, preceding stage function (EXE->MEM) is executed....

void CorePipelined::do_step(bool skip_break)

https://github.com/cvut/QtMips/blob/7c38d97da0f188752ff8863478b5ac130d4d93c1/qtmips_machine/core.cpp#L757

As for the actual decode of the instruction code to the ID->EXE signals, they are generated from description

static const struct InstructionMap instruction_map[]

https://github.com/cvut/QtMips/blob/7c38d97da0f188752ff8863478b5ac130d4d93c1/qtmips_machine/instruction.cpp#L704

The decode starts by indexing the first level table by opcode field. If the subclass is not NULL then the other bit field is extracted and used to index in more detailed table.

The map of instruction descriptions sorted by mnemonic code is generated at QtMips startup. It is used for assembler and interactive code editor.

Generally attempt is to keep code simple, not optimized too much to make it easy readable. Opcodes tables match in the style these in reference CA book, stage and core logic matches basic HDL design so this C++ code can be used by students even as help tool for their Verilog design in Advanced Processor Architectures class and vice versa HDL design can be used as introduction to QtMips implementation.

Best wishes,

Pavel

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/cvut/QtMips/issues/12#issuecomment-746491711, or unsubscribe https://github.com/notifications/unsubscribe-auth/AINQWQV54TFPWOCHUWW75MLSVDH6NANCNFSM4UXIXWRQ .

ppisa commented 3 years ago

By the way, can you tell me what's wrong with the following code? https://pastebin.com/DRpCuss3 Its purpose is to hit a load-use hazard so I can see for myself how graphics are displayed (if any) and how/where the code flushes the next instruction that should not be executed. However, it seems to infinitely execute nop instructions after exiting branch instead of exiting the program.

The memory after the loop is full of NOPs. So that is correct behavior. Processor does not know that there was no code in the source. You can stop execution by "break" instruction and even that should be enforced in the loop, because next run or step button press continues after break instruction.

final:  break
    beq $zero, $zero, final
    nop

Or you can add invocation of the exit syscall

    addi    $v0, $zero, __NR_exit
    addi    $a0, $zero, 0
    syscall
ppisa commented 1 year ago

No activity for almost two years. QtMips mainline build reimplemented with CMake. Configurable endianness tested and problem with LCD fixed. Main development continues on RISC-V version https://github.com/cvut/qtrvsim/