blob: a14780f559b519ba57b90ecc1f727218326d5f55 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
|
*************************************************************************
Benchmarks for RISCV Processor
-------------------------------------------------------------------------
The benchmarks make use of the RISCV C compiler toolchain. You will need
to include a bmark.mk makefile fragment in each benchmark directory. The
fragment should include the object files and a rule to actually link
these object files into an executable. There are a couple important
points to make about the toolchain.
+ The toolchain sets the stack pointer to memory address 0x20000 so your
main memory _must_ be larger than 0x20000 bytes or else the stack will
get wrapped around and overwrite program data.
+ The stack grows down from 0x20000 and your program is loaded at 0x1000.
If you have a very large program and have lots of very big arrays
declared on the stack your stack could overwrite your program. Be aware.
+ You cannot use standard clib functions (like memcopy or strcat). You
cannot use system calls and thus cannot use printf.
+ You cannot access the simulated command line - ie you cannot use argc
and argv within main.
+ You may have to increase the timeout check in your test harness to
allow longer programs to run (you can do this from the command line
option +max-cycles with the standard test harness)
+ The compiler loads the program at 0x1000. It does not insert exception
setup code. So if you are careful with what C you use it will only
generate code in the riscv lab1 subset. If you use multiplies, shorts,
and chars it could generate mul, lh, and lb instructions. Be aware.
+ You can write assembly in C - you need to do this to write tohost to 1
to indicate when the benchmark is done. Look at the example
benchmarks to see how this is done. You can find more information
about how to write assembly in C here:
http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html
+ If you look at the example benchmarks you will see that I have two
important macros HOST_DEBUG and VERIFY. Use HOST_DEBUG to compile the
benchmark on your host workstation (ie use standard gcc on Athena/Linux
box) and then debug the benchmark. Since you are using standard gcc you
can use printf's to make sure that your benchmark actually works before
trying it out on your RISCV processor.
+ Debugging C compiled code on the RISCV processor is a real pain. It is
hard to associate the assembly with the C code and there is no
debugger. So if you encounter a bug in your processor when running a C
benchmark you can try to debug it, but you might have better luck
adding more assembly tests to your test suite.
+ To avoid having the compiler try and use a global pointer (ie using
register 28 to point to a space where small global variables are
stored) you need to use the -G 0 command line option.
|
