mipt-ilab / mdsp Goto Github PK
View Code? Open in Web Editor NEW[2009 – 2012] MDSP: functional simulation of a Multimedia Digital Signal Processor
License: MIT License
[2009 – 2012] MDSP: functional simulation of a Multimedia Digital Signal Processor
License: MIT License
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.
Original issue reported on code.google.com by [email protected]
on 26 Oct 2010 at 7:08
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.
Original issue reported on code.google.com by [email protected]
on 28 Nov 2010 at 7:36
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
Original issue reported on code.google.com by [email protected]
on 15 Mar 2011 at 7:16
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
Original issue reported on code.google.com by [email protected]
on 28 Mar 2011 at 6:39
requested changes applied
Original issue reported on code.google.com by [email protected]
on 22 Nov 2010 at 12:21
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
Original issue reported on code.google.com by [email protected]
on 9 Dec 2010 at 7:47
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.
Original issue reported on code.google.com by [email protected]
on 26 Oct 2010 at 4:43
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
Original issue reported on code.google.com by [email protected]
on 26 Oct 2010 at 4:53
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.
Original issue reported on code.google.com by [email protected]
on 26 Oct 2010 at 5:20
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.
Original issue reported on code.google.com by [email protected]
on 3 Dec 2010 at 10:07
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
Original issue reported on code.google.com by [email protected]
on 18 Nov 2010 at 7:49
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.
Original issue reported on code.google.com by [email protected]
on 13 Nov 2010 at 8:06
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
Original issue reported on code.google.com by [email protected]
on 20 Apr 2011 at 11:10
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.
Original issue reported on code.google.com by [email protected]
on 16 Apr 2010 at 2:54
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.
Original issue reported on code.google.com by [email protected]
on 24 Nov 2010 at 10:07
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!
Original issue reported on code.google.com by [email protected]
on 18 Apr 2010 at 10:20
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.
Original issue reported on code.google.com by [email protected]
on 16 Apr 2010 at 2:49
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.
Original issue reported on code.google.com by [email protected]
on 26 Oct 2010 at 5:19
Build of MS VS 2008:
\main.cpp(33) : error C3861: strtoll: identifier not found
Original issue reported on code.google.com by [email protected]
on 4 Dec 2010 at 9:11
Most of the mistakes were in whitespaces. We can switch on testMemVal and
testMemModel now.
Original issue reported on code.google.com by [email protected]
on 10 Nov 2010 at 6:55
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
Original issue reported on code.google.com by [email protected]
on 24 Nov 2010 at 2:32
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.
Original issue reported on code.google.com by [email protected]
on 19 Nov 2010 at 10:21
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.
Original issue reported on code.google.com by [email protected]
on 12 Nov 2010 at 11:33
64BitPortability flag was removed.
After the review, I'll merge this branch into:
/trunk
Original issue reported on code.google.com by [email protected]
on 21 Dec 2010 at 9:08
*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.
Original issue reported on code.google.com by [email protected]
on 26 Oct 2010 at 5:56
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.
Original issue reported on code.google.com by [email protected]
on 24 Mar 2010 at 8:53
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.
Original issue reported on code.google.com by [email protected]
on 26 Oct 2010 at 5:22
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
Original issue reported on code.google.com by [email protected]
on 27 Oct 2010 at 9:35
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
Original issue reported on code.google.com by [email protected]
on 24 Nov 2010 at 2:46
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
Original issue reported on code.google.com by [email protected]
on 9 Dec 2010 at 7:49
Attachments:
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)
Original issue reported on code.google.com by [email protected]
on 15 Nov 2010 at 8:28
Now MDSP works correctly. It executes all the operations from the
simple_test.bin.
After the review, I'll merge this branch into:
/trunk
Original issue reported on code.google.com by [email protected]
on 14 Nov 2010 at 10:44
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.
Original issue reported on code.google.com by [email protected]
on 3 Dec 2010 at 6:07
A some test information.
Original issue reported on code.google.com by [email protected]
on 5 Oct 2009 at 1:56
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).
Original issue reported on code.google.com by [email protected]
on 26 Oct 2010 at 5:02
1) Made log methods constant.
2) Made log methods to accept variable amount of arguments
Original issue reported on code.google.com by [email protected]
on 8 Nov 2010 at 12:51
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.
Original issue reported on code.google.com by [email protected]
on 26 Oct 2010 at 5:09
i`ve changed printing methods in the core class
ps some explanation of variable arguments might be usefull
Original issue reported on code.google.com by [email protected]
on 28 Nov 2010 at 11:26
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.
Original issue reported on code.google.com by [email protected]
on 26 Oct 2010 at 5:18
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.
Original issue reported on code.google.com by [email protected]
on 4 Dec 2010 at 9:22
Purpose of code changes on this branch:
To avoid compiler warnings.
After the review, I'll merge this branch into:
/trunk
Original issue reported on code.google.com by [email protected]
on 14 Dec 2010 at 9:17
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.
Original issue reported on code.google.com by [email protected]
on 10 Nov 2010 at 2:50
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
Original issue reported on code.google.com by [email protected]
on 2 Dec 2010 at 6:00
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.
Original issue reported on code.google.com by [email protected]
on 15 Nov 2010 at 8:46
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
Original issue reported on code.google.com by [email protected]
on 2 Dec 2010 at 7:08
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.
Original issue reported on code.google.com by [email protected]
on 26 Oct 2010 at 5:21
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.