t-crest / patmos-simulator Goto Github PK

TLDR: The test named test24 is a special test that I think we should remove.

test24 is comprised of the files:

• tests/test24.c
• tests/test24.elf
• tests/test24.in

What it does is repeat the first 8 characters sent to it through the UART and nothing else. However, the problem is that tests/test24.elf is committed in git. This is the result of compiling tests/test24.c by hand with patmos-clang.
I think this has no place in the simulator, as the test is not automatically updated if you change the .c file.
Additionally, it means you need to have the compiler installed if you want to modify it or make the compilation part of the testing . It would be a bad idea to need to have the compiler installed during testing as it then introduces a circular dependency between the compiler and simulator.
Lastly, this test doesn't even test anything special, as test22 tests reading from UART and test23 test outputting to UART.

Unless someone has a reason why this test should stay, I will be removing it to simplify the testing setup.

A load instruction is allowed on bundle slot 2 (pipeline 2).

The current cmake setup doesn't specify that we are using c++14. We should do so.

Tried to build the simulator on a DTU Linux machine (after installing described dependencies) I got:

CMake Error at /usr/local/lib/cmake/Boost-1.76.0/BoostConfig.cmake:141 (find_package):
  Could not find a configuration file for package "boost_program_options"
  that exactly matches requested version "1.76.0".

  The following configuration files were considered but not accepted:

    /usr/lib/x86_64-linux-gnu/cmake/boost_program_options-1.71.0/boost_program_options-config.cmake, version: 1.71.0
    /lib/x86_64-linux-gnu/cmake/boost_program_options-1.71.0/boost_program_options-config.cmake, version: 1.71.0

Call Stack (most recent call first):
  /usr/local/lib/cmake/Boost-1.76.0/BoostConfig.cmake:258 (boost_find_component)
  /usr/local/share/cmake-3.14/Modules/FindBoost.cmake:266 (find_package)
  CMakeLists.txt:54 (find_package)

To send input to a program's stdin running on the simulator, we can use piping: echo "some input" | pasim a.out.

Doing this on macos doesn't work. Example program:

#include <stdio.h>
int main() {
	int x ;
	scanf("%d", &x);
	printf("Output: %d\n", x + 2);
	return 0;
}

After compiling with patmos-clang -O2 main.c, and running using echo "2" | pasim a.out, we would expect it to output Output: 4, but instead we get Output: 2.
Clearly scanf is not working correctly.
Running the same program and commands on ubuntu outputs the expected string

The release binary for pasim that we provide prebuilt requires boost-program-options v1.65.1 to be installed on the machine that runs pasim.

This issue is to discuss whether we want to keep this, or change pasim to statically link boost and therefore not require users to have boost installed.

If we keep the status quo, we will have to instruct users to install boost as part of installing pasim, which is more work on their part. However, in the future, we might provide an ubuntu package for pasim, in which case we can make boost a dependency and the user wont have to do it on their own.

Thoughts?

The Patmos simulator pasim produces an error (unaligned memory access) when the function printf() is called and the number of cores is greater than 1.

To reproduce, write a short Hello World program and execute following commands:

$ cat test.c
#include <stdio.h>
int main() {
    printf("Hello world!\n");
    return 0;
}
$ patmos-clang test.c
$ pasim a.out 
Hello world!
$ pasim -N 2 a.out 
[Error] Unaligned memory access: 00000003

00047280<pthread_mutex_init:.LBB163_2:.LBB163_3 + 0x8>:              lwm r2 = [r1 + 0]

Cycle : 48930, PC : 0004728c<pthread_mutex_init:.LBB163_2:.LBB163_3 + 0x14>
Stacktrace:
#0 0x471e4 <pthread_mutex_init>(): $rsp 0x6c8 stack cache size 0x780
   at 0x4728c (base: 0x47244 <pthread_mutex_init:.LBB163_2:.Ltmp1904 + 0xc>, offset: 0x48 <pthread_mutex_init:.LBB163_2:.LBB163_3 + 0x14>)
t-crest/patmos#1 0x25304 <std>(): $rsp 0x6c8 stack cache size 0x7a0
   at 0x253a0 (base: 0x25304 <.LBB46_0:std>, offset: 0x9c <std + 0x9c>)
t-crest/patmos#2 0x24f34 <__sinit>(): $rsp 0x6c8 stack cache size 0x7e0
   at 0x25014 (base: 0x24fb4 <__sinit:.LBB38_2:.Ltmp260 + 0xc>, offset: 0x60 <__sinit:.LBB38_2:.Ltmp260 + 0x6c>)

No error is produced if printf() is removed from the program:

$ cat test.c
#include <stdio.h>
int main() {
    return 0;
}
$ patmos-clang test.c
$ pasim -N 2 a.out
$ echo $?
0

Testing the simulator results in 2 failures on OSX that don't fail on linux. Full build/test logs can be found here.

The errors are:

    Start 69: sim-test-22
69/96 Test #69: sim-test-22 ......................***Failed  Required regular expression not found.Regex=[r1 : 000000fb]  0.04 sec

    Start 71: sim-test-24
71/96 Test #71: sim-test-24 ......................***Failed  Required regular expression not found.Regex=[1234567890]  0.03 sec

The build does issue a warning that is also not present when building on linux:

[ 37%] Building CXX object src/CMakeFiles/patmos-simulator.dir/memory-map.cc.o
/Users/travis/build/Emoun/patmos-simulator/src/memory-map.cc:213:2: warning: "EthMac simulation supported only under Linux" [-W#warnings]
#warning "EthMac simulation supported only under Linux"
 ^
1 warning generated.

Could this be the issue?

When running pasim -h the following is printed regarding the data cache kind:

-D [ --dckind ] arg (=dm)             kind of direct mapped/fully-/set-associ
                                        ative data cache, defaults to lru2
                                        (ideal, no, dm, lru[N], fifo[N])

The (=dm) should signify that a direct mapping is used when the flag is not set, however the description then says defaults to lru2.

Running some tests, it seems to me that direct mapping is indeed the default when the flag is not set.
We should decide which kind should be default and correct the message to fit.

When providing input to a a program's stdin when run through pasim, doing so using pasim's stdin results in errors.

Take the following C program:

#include <stdio.h>
int main(){
  int x;
  scanf("%d", &x);
  printf("%d", x);
}

It simply reads one integer and prints it.
We can use a file as input without error. Say we have a file input.txt containing simply 42, we can run the program:

> patmos-clang main.c
> pasim a.out --in input.txt
42

However, using pasim's stdin to provide the input doesn't print correctly:

> echo 42 | pasim a.out
0

This seems to be a regression cause by f9ec592 but not caught by any tests. The last commit to behave correctly in this case is 1ec0fff.

As reaffirmed in t-crest/patmos#50, the destination register of a load instruction is undefined as long as the load is in flight.
As such, accessing this register within the delay slot is always wrong. pasim should, and luckily does, reflect this.
However, as far as I can tell, there is no test in this repository ensuring this behavior is maintained.

Therefore, the purpose of this issue is to ensure we include such a test into the test suite.

The Patmos simulator pasim hangs when attempting to start a core thread via corethread_create().

Steps to reproduce:

$ cat test.c
#include "libcorethread/corethread.h"
void work(void* arg) {
}
int main() {
    corethread_create(1, &work, NULL);
    return 0;
}
$ patmos-clang test.c libcorethread/corethread.c 
$ pasim -N 2 a.out
^C

Note: the last command does not terminate and needs to be aborted.

Take the following assembly program:

                .word    36;
		addi	r1 = r0, 0;
                brcfnd     x;
                nop;
                nop;
                nop;
                halt;
		nop;
		nop;
		nop;
                .word    24;
x:              addi     r1 = r1, 1337;
		retnd;
		addi     r1  = r1, 1;
		addi     r1  = r1, 2;
		addi     r1  = r1, 3;

When it finishes, should have r1=1337 however gets r1=1343 meaning the final adds are being executed even if they shouldn't.
If we replace retnd with ret (and remove the adds) we get the expected result.

I know this is a niche situation, as in real code you should never have a return without first a call. However, since it works as expected with ret, and the current behavior is definitely wrong, a fix is justified.

Paasm wont compile with "ret" instruction using r30 and r31 on line 49.

The callnd executes the following instruction before calling the function.

Take the following assembly program:

			li      	      	$r0 = 52
main:
			li 			$$r1 = 123
			pmov 			$$p7 = !$$p0
			callnd			test_fn
			pmov 			$$p7 = $$p0 
			brcf    	      	0 ; halt
			nop	
			nop	
			nop	
		
			li $$r0 = 12
test_fn:	   
			li (!$$p7) $$r1 = 0	; Set to 0 only if p7 is false
			li ( $$p7) $$r1 = 1	; Set to 1 only if p7 is true
			retnd

test_fn should only set r1 to 0 if p7 is false. In main we start by setting it to false and after the call we set it to true.

Using pasim on this program will return 1, meaning p7 was true in test_fn. Adding a nop after callnd will result in the correct value being returned. So the error is that the instruction following the no-delay call is being executed as if the call had a delay of 1.

Interestingly, say we add li $$r1 = 34 after the call, then the result is 34, meaning the instruction after a callnd is being executed twice, once before the call and once after returning.

This example again shows the need for running all test on both binary- and elf-format executables since running this program in binary mode will give the correct result but not in elf mode. I can't figure out why this is the case.

This issue might be related to #20.