mipt-ilab / mdsp Goto Github PK

What steps will reproduce the problem?
1. Delete comments in main of test.cpp

What is the expected output? What do you see instead?
MemVal functions should work (functions are correct) but it crashes.

What steps will reproduce the problem?

r469 introduced a problem that leads to the fact that Makefile build of MDSP 
fails.

This issue is critical and must be fixed ASAP.

Currently funcsim is way too concise about its errors  - it's most often 'cout 
<< "Error!";'. This should be fixed: a real problem should be reported.

Another thing is not to use cout at all. We need a special methods for logging 
the messages, be they warnings, debug infos or critical errors.

The bug owner will be responsible for designing and implementing the new 
logging system and also changing all places in the code that want to report 
something.

Purpose of code changes on this branch:

The first steps with Google's reviewing system AND with working with SVN 
branches.

Look! 
 * I created a branch, modified it, then committed to branch, and then asked for a code review! 
 * If you approve my review, then I'll merge my branch with main trunk.

I think that is the way our students should work with code too.

After the review, I'll merge this branch into:
/trunk

Currently funcsim is able to simulate several operations of MOVE class and a 
single HLT instruction. This is good but obviously not enough.

To improve funcsim's completeness we need more instructions.

This task requires its owner to do the following:

1) Implement at least one instruction for unconditional jump 
2) Implement at least one instruction for conditional jump
3) Implement several instructions that perform arithmetic functions so we can 
start doing simple calculations
4) Write unit tests that check new functionality:
   - at least one test per new instruction
   - a test does these actions: fills the operands required, puts instruction to memory, sets up %PC register to point to new instruction, calls Core->run(1), then checks the resulting operands to be correct.
5) Write assembly and machine code tests that check new functionality
6) Document new tests in wiki.

Currently funcsim lacks any of SIMD instructions. Please implement them. They 
are listed on MDSP reference document, page 75, table 5.14. Their semantics are 
described in Appendix B.2

This task is the first step to implement our timing model. Therefore it is a 
high priority task.

The ports is the foundation of the performance model, you need to implement 
them from scratch.

The implementation should be divided in the following steps:

1) First of all you need to read the wiki page dedicated to the desing of the 
ports: 
http://code.google.com/p/mdsp/wiki/CommunicationBetweenModulesThroughPorts. 
Note that it is not about how to implement the ports, it is about how they 
should work in the model.

2) Then you should propose an approach for the implementation of the ports and 
discuss it with Alexander Titov or any other mentor.

3) When your approach is approved you will start coding in your branch.

4) Review your code, commit into the main trunk.

5) Create a wiki page dedicated to your implementation of the ports.

6) Make a presentation about the implementation of the ports for the team.

Most of the mistakes were in whitespaces. We can switch on testMemVal and 
testMemModel now.

Actions required:

1) Add new tests that do the following: 
 - ~ 100 instructions without any branches: loads/stores, arithmetic commands etc
 - ~ short cycle algorithm (~30 cycles of some memory accessng etc)
 - reading and writing  of full memory space (256k), one byte (word?) at a time.
 - Something of your wish: any sane combination

2) All tests are highly _desired_ to have both assembly code and actual machine 
code (I am not sure that our assembler currently is able to handle all the 
required machine instructions, you'll need to check this). In case it 's not 
possible - try to write simple

3) Tests are allowed not to work completely - it will be another task to make 
them work (but if you see that you can easily fix some problems please do so). 
If they crash funcsim - it's OK.

4) New tests should be described in wiki - their names, what they do, their 
algorithms, current status (work/doesn't work)

5) All tests should be ended by HLT instruction.

1. Config.cpp and config.h were rewritten. Now they parse all arguments 
mentioned in our wiki.
2. Some changes in main.cpp to work with new config.cpp
3. Changes in sheduler.cpp to work with new config.cpp
4. Boost (ver 1.44) headers were uploaded.
5. Boost (ver 1.44) libraries were uploaded. They are compiled for:
    a) Microsoft Visual Studio 2008
    b) GCC in 32-bit Linux (by Yuri)
    c) GCC in 64-bit Linux (also by Yuri)
    d) GCC in CygWin
6. Makefile is more smart now: it links necessary libs depended on system.
7. VSPROJ file is also changed.
8. Every system was tested.

After the review, I'll merge this branch into:
/trunk

Purpose of code changes on this branch:
Check and fix current disassembling features of funcsim.

When reviewing my code changes, please focus on:
1. Changes in core.cpp. Some pieces of code were deleted (such as checking for 
zero instruction or printing binary codes in inverted form), because they were 
necessary before, but now we have more convenient ways to do that.

2. Changes in operation.cpp are not very important. Most of them are about how 
to present information in disassembled form.

3. Added all-tests.bin. It includes all operations which can be executed at 
this moment.

After the review, I'll merge this branch into:
/trunk

Currently fullsim is able only to load "raw" binary code which is placed at 
hardcoded position. This might be inconveient. We should able to load some 
simple basic form of ELF-typed binaries with help of external libelf project.

An owner of this issue will be required to do the following things:

* understand what an ELF is
* devise a simple ELF-based file type that we'll be loading
* understand what fucntions useful for us libelf provides.
* learn how to link code against static libraries
* make our own binary reader that recognizes the ELF and loads it appropriately.

FuncSim should have mode of operation when it prints current instruction 
disassembly (or just hex codes in the case it does not have disasm for a 
particular instruction yet)

The current core::run() has a major flaw - it is not "classical" i.e. it does 
not conform to 'fetch-decode-execute-write-results-advance_pc' form. This 
should corrected:

* all stages must be present, though they are are allowed to do nothing useful 
except for printing out "I am here!"

* all stages must be in the exact sequence.

Now MDSP works correctly. It executes all the operations from the 
simple_test.bin.

After the review, I'll merge this branch into:
/trunk

The recent testing of main trunk showed that unit tests of funcsim fail at 
disassembly tests. That is because the disassembler format was actually changed 
to more accurate. This situation is usually called "тесты 
протухли".

The required action: modify unit tests so that they correspond to the new 
format.

As this bug has priority 'Critical' the owner is allowed to commit *fixes* 
directly to main trunk without a code review.

Purpose of code changes on this branch:

Implement several ALU and PFLOW instructins. Make tests.

When reviewing my code changes, please focus on:

New binary test. Instruction execution at all.

After the review, I'll merge this branch into:
/trunk

Currently fullsim is able only to load "raw" binary code which is placed at 
hardcoded position. This might be inconveient. We should able to load some 
simple basic form of ELF-typed binaries with help of external libelf project.

An owner of this issue will be required to do the following things:

* understand what an ELF is
* devise a simple ELF-based file type that we'll be loading
* understand what fucntions useful for us libelf provides.
* learn how to link code against static libraries
* make our own binary reader that recognizes the ELF and loads it appropriately.

Currently our build based on Makefile makes only release binary. This is 
inconvenient as for debugging purposes we need debug information to be present 
in binaries.

The owner of the bug is expected to accomplish the following tasks:
 * Learn how the Makefiles are  made;
 * Learn what are the debug options for compiler that we use;
 * Learn how to pass and handle the type of release insode the Makefile;

The expecteed result: 
 * when one uses `make` - he gets release binaries
 * when one uses `make DEBUG=yes` he gets debug binaries 

1) Made log methods constant.
2) Made log methods to accept variable amount of arguments

When I try to launch assembler without input arguments the following 
assertion appears:

kosarev@server:~/svn/trunk/sources$ ./bin/asm
asm: asm/tokenan.cpp:37: void TokenAn::initFileLength(const char*): Assertion 
`f' failed.
Aborted

I expect some useful information instead of just "f".
svn rev. 237.

Purpose of code changes on this branch:
To avoid compiler warnings.

After the review, I'll merge this branch into:
/trunk

64BitPortability flag was removed.

After the review, I'll merge this branch into:
/trunk

A some test information.

After the launch of funcsim model the following error appears:

kosarev@server:~/svn/trunk/sources$ ./bin/funcsim ../tests/simple_test.bin
Input file: ../tests/simple_test.bin
Init. Start PC: 0x0
ERROR: Out of Memory!
funcsim: funcsim/memory.cpp:357: ByteLine MemVal::getByteLine() const: 
Assertion `0' failed.
Aborted

What does it mean "Out of Memory"? I expect that the model should inform me 
about the address, size of memory block being written.

By the way, memory.* file have poor comments. It is not simple to figure 
out what the problem is.

svn rev. 237

If you are not the owner of the code, please forward (change owner) the 
issue to proper person.

1. Study Doxygen system
2. Describe in Wiki how to install Doxygen and how to document project's code 
for Doxygen
3. Prepare a presentation to the team about Doxygen usage

Purpose of code changes on this branch:

implementing ports engine.

When reviewing my code changes, please focus on:

demonstration of work:

g++ sources/funcsim/demoports.cpp sources/funcsim/log.cpp

After the review, I'll merge this branch into:
/trunk

I made changes directly in trunk
Some cosmetic changes (see attached patch file)

D       sources/asm/1.S
D       sources/asm/Doxyfile
D       sources/asm/all-test.S
M       sources/funcsim/funcsim.vcproj
D       boost/stage
D       boost/stage/lib
D       boost/stage/lib/libboost_program_options-vc90-mt-1_44.lib
D       boost/stage/lib/libboost_program_options.a
D       boost/stage/lib/libboost_program_options-vc90-mt-gd-1_44.lib
A  +    boost/libs/32/libboost_program_options-cygwin-mt-1_44.a
D       boost/libs/32/libboost_program_options-gcc44-1_44.so
A  +    boost/libs/32/libboost_program_options-vc90-mt-1_44.lib
A  +    boost/libs/32/libboost_program_options-vc90-mt-gd-1_44.lib
D       boost/libs/64/libboost_program_options-gcc44-1_44.so
M       Makefile

i`ve changed printing methods in the core class

ps some explanation of variable arguments might be usefull

requested changes applied

Currently fullsim is able only to load "raw" binary code which is placed at 
hardcoded position. This might be inconveient. We should able to load some 
simple basic form of ELF-typed binaries with help of external libelf project.

An owner of this issue will be required to do the following things:

* understand what an ELF is
* devise a simple ELF-based file type that we'll be loading
* understand what fucntions useful for us libelf provides.
* learn how to link code against static libraries
* make our own binary reader that recognizes the ELF and loads it appropriately.

Can't compile funcsim model.
svn rev 247

kosarev@server:~/svn/trunk/sources$ make funcsim
g++ -Wall    -c -o funcsim/core.o funcsim/core.cpp
g++ -Wall    -c -o funcsim/flags.o funcsim/flags.cpp
g++ -Wall    -c -o funcsim/memory.o funcsim/memory.cpp
g++ -Wall    -c -o funcsim/operation.o funcsim/operation.cpp
g++ -Wall    -c -o funcsim/register_file.o funcsim/register_file.cpp
g++ -Wall    -c -o funcsim/main.o funcsim/main.cpp
In file included from funcsim/main.cpp:12:
funcsim/config.h:39:8: warning: extra tokens at end of #endif directive
In file included from funcsim/main.cpp:13:
funcsim/defines.h:6:8: warning: extra tokens at end of #endif directive
g++ -Wall funcsim/core.o funcsim/flags.o funcsim/memory.o 
funcsim/operation.o funcsim/register_file.o funcsim/main.o -o bin/funcsim
funcsim/main.o: In function `main':
main.cpp:(.text+0x213): undefined reference to `Config::Config(int, 
char**)'
main.cpp:(.text+0x221): undefined reference to `Config::handleArgs()'
main.cpp:(.text+0x36d): undefined reference to `Config::~Config()'
main.cpp:(.text+0x3a7): undefined reference to `Config::~Config()'
collect2: ld returned 1 exit status
make: *** [funcsim] Error 1

DO NOT FORGET TO COMPILE THE FUNCSIM BEFORE DOING COMMIT!

Current simple_test.bin does not provide conditions for the simulator to 
gracefully exit - it has no stop instruction and thereofore simulator just runs 
until it encounters memory marked as uninitialized and crashes.

Thus the owner of this bug should do two things:
1) Modify the simple_test.bin the way it contains HLT instuction.
2) Verify that funcsim exits with no error on new binary

Another good thing to do is to add full-test to regular testing script.

1. Study smart pointers conception
2. Study realizations of smart pointers in STL (std::auto_ptr) and Boost 
(http://www.boost.org/doc/libs/1_45_0/libs/smart_ptr/smart_ptr.htm)
3. Describe study results in wiki
4. Make a presentation about smart pointers for the team

As our funcsim will be a part of clock-precise simulator one day, it should be 
controllable by external entities. At the moment we start a simulation process 
with `void core::run()` method. This should be changed to the following scheme:

 * the main execution is run by `int core::run(int requested)' i.e. we specify that a core should execute no more than requested instructions, and it will return the amount of actually performed actions (which might be less). That is a functional core.
 * a separate object called scheduler is responsible of calling the core and of interacting with user. That is a scheduler
 * Functional core should provide interface that can be later used by clock-precise part. 

Thus, we'll be able to build two distinctive simulators on the same functioanl 
core - funcsim (core + sceduler) and clock-presise (core + clockl model).

Currently fullsim is able only to load "raw" binary code which is placed at 
hardcoded position. This might be inconveient. We should able to load some 
simple basic form of ELF-typed binaries with help of external libelf project.

An owner of this issue will be required to do the following things:

* understand what an ELF is
* devise a simple ELF-based file type that we'll be loading
* understand what fucntions useful for us libelf provides.
* learn how to link code against static libraries
* make our own binary reader that recognizes the ELF and loads it appropriately.

*NOTE*

This activity is for mentor only! Students are not expected to contribute to it.

To perform quality assurance of our project it would be nice and fun to have a 
server that performs regular testing.

Such server should do the following tasks e.g. twice a week:
 * Fetch latest SVN
 * Build all modules
 * Run defined set of tests
 * Report results to mailing list 

I, Grigory Rechistov, is the initial owner of this bug and will try to 
implement such a server.

In wiki
http://code.google.com/p/mdsp/wiki/FuncSimDesign#Command_line_arguments
there is a description of all command line arguments that our model should 
handle.

Class config.cpp is responsible for handling the arguments. It should be 
extended to support all the arguments described.

Please use certain "standard" libraries for the solution. It is libgetopt on 
Linux and ??? on MS VS.

I made changes directly in trunk
Some cosmetic changes (see attached patch file)

D       sources/asm/1.S
D       sources/asm/Doxyfile
D       sources/asm/all-test.S
M       sources/funcsim/funcsim.vcproj
D       boost/stage
D       boost/stage/lib
D       boost/stage/lib/libboost_program_options-vc90-mt-1_44.lib
D       boost/stage/lib/libboost_program_options.a
D       boost/stage/lib/libboost_program_options-vc90-mt-gd-1_44.lib
A  +    boost/libs/32/libboost_program_options-cygwin-mt-1_44.a
D       boost/libs/32/libboost_program_options-gcc44-1_44.so
A  +    boost/libs/32/libboost_program_options-vc90-mt-1_44.lib
A  +    boost/libs/32/libboost_program_options-vc90-mt-gd-1_44.lib
D       boost/libs/64/libboost_program_options-gcc44-1_44.so
M       Makefile

i`ve managed to complete the task,yet some important things are to be done:
1)input check,now it looks like:
funcsim PATH NUMBER
PATH is a path,number is the number of steps to simulate
as all checks are made in config module,i decided not to change it
2)i had to split main_function.h into .h & .cpp
3)also some minor coding style\output issues

ps sorry for late commit.

Currently fullsim is able only to load "raw" binary code which is placed at 
hardcoded position. This might be inconveient. We should able to load some 
simple basic form of ELF-typed binaries with help of external libelf project.

An owner of this issue will be required to do the following things:

* understand what an ELF is
* devise a simple ELF-based file type that we'll be loading
* understand what fucntions useful for us libelf provides.
* learn how to link code against static libraries
* make our own binary reader that recognizes the ELF and loads it appropriately.

Build of MS VS 2008:

\main.cpp(33) : error C3861: strtoll: identifier not found

Our assembler `asm` is quite well written piece of code. Though there is 
absolutely no documentation on this program. 

The owner of this tracker will have to do the following:

* Learn (and document) how to build asm, what are the possible flags
* Learn (and document) the usage of the program
* Describe the list of currently supported instructions, as not every one  
described in MDSP reference manual are implemented.
* Describe the format of binary generated by the assembler.

Currently we have only one VCPROJ at that is for building funcsim. `asm` and 
`test` cannot be built using Visual Studio at all! This is not right.

The owner of this bug should perform the following steps:

1) Determine what files are used to build `asm` and `test` binaries
2) Create two new MS VS 2008 projects (they should be created as "Console 
Empty" projects, be specially careful about it!), name them asm.vcproj and 
test.vcproj, place them near funcsim.vcproj
3) Add files required for every binary to the corresponding VCPROJ.
4) Build them, make sure that they are OK.
5) Update the solution file `mdsp.sln` with two new projects.
6) Add new files to SVN

Currently a regular test on Windows MS VS 2008 reveals a number of compilation 
warnings. This is not a safe practice to leave this as is - a warning can turn 
to an error in a lot of unusual conditions.

Therefore, the reasons of these warnings should be found, explained and fixed.

Issue concerns coding style of memory.h

1. Comments don't satisfy the requirements of coding style.
2. There is no names of arguments in method declaration.

Example:

/* Returns ByteLine with specified length from specified
address. If that position is invalid, recalls exception */
ByteLine readBL(  mathAddr, unsigned int);

Fix it please for whole file.