Parallella Community

Hi parallella community.

This few lines program behaves very unexpected:

https://github.com/joseluisquiroga/para ... _prog_16.c

I would like some feedback:

Do you get the same results? (value 0xddd at the end)
Is it just my parallela board?
Can you explain the behaviour?

Thanks.

JLQ.

You are expecting a deterministic memory ordering, which the Epiphany architecture only guarantees within a single core. As soon as you go off-core, but especially if you go off-chip (i.e. shared memory), the memory ordering is relaxed. Reads following writes to off-core destinations happen in a non-deterministic order. (I don't know if this applies for on-core transactions through a global address, though.)

Your assembly code does not match your source code (incomplete), the build instructions and the used linker script are missing. Since you muck around with the startup code, I simply assume that ".data" and/or ".bss" are not allocated within local memory, and the behaviour you see is permitted by the Epiphany.

Thank you sebraa for taking the time to answer.

Some observations:

1) The build script generates the code16.s file at the end using the e-objdump program see file

https://github.com/joseluisquiroga/para ... 6/build.sh

from the just compiled elf file. It has to be a match (unless the e-objdump is broken). This file is the build script. It is not missing.

2) As you can see the .bss section (just look at the address '1c4' for val2) is in core memory. See file (line 99)

https://github.com/joseluisquiroga/para ... 6/code16.s

That means that variable 'val2' is local core memory.

3) Since the shared mem variable (off core variable) called 'shdmem' is assigned only once at the end of the program with the value of an in core variable (val2) it can only have either the value zero which is the initialization value in the host program in line 63. See file:

https://github.com/joseluisquiroga/para ... /prog_16.c

Or the value that val2 had at the moment of the assignation in line 40 in the epiphany program. See file:

https://github.com/joseluisquiroga/para ... _prog_16.c

That is: Either there was enough time for it to be assigned or not, before it is read in the host program.

4) aux is a variable in the stack (,[fp,+0x3]) which is the one assigned several times in the eprog. The stack register sp is initialized in the start assembler program to local memory. See file (lines 13 and 14):

https://github.com/joseluisquiroga/para ... /e_start.s

So it is all local in core memory (not off core, not off chip) the one that is been assigned for line 20 to 39 of the eprog. Only up to line 40 off chip (shdmem variable) memory is assigned and it must either have the value of val2 or zero. Only if I read zero in the host (which never happens in my running tries) I did not give enough time, otherwise it must have the value that val2 was assigned in line 33.

5) The program is just a modification of the helloworld example so you can build it and run it using the script files:

https://github.com/joseluisquiroga/para ... 6/build.sh
and
https://github.com/joseluisquiroga/para ... -16/run.sh

===================

I would like some feedback:

Do you get the same result 0xddd?

Thanks again.

Thank you sebraa for taking the time to answer.

Some observations:

1) The build script generates the code16.s file at the end using the e-objdump program see file

https://github.com/joseluisquiroga/para ... 6/build.sh

from the just compiled elf file. It has to be a match (unless the e-objdump is broken). This file is the build script. It is not missing.

2) As you can see the .bss section (just look at the address '1c4' for val2) is in core memory. See file (line 99)

https://github.com/joseluisquiroga/para ... 6/code16.s

That means that variable 'val2' is local core memory.

3) Since the shared mem variable (off core variable) called 'shdmem' is assigned only once at the end of the program with the value of an in core variable (val2) it can only have either the value zero which is the initialization value in the host program in line 63. See file:

https://github.com/joseluisquiroga/para ... /prog_16.c

Or the value that val2 had at the moment of the assignation in line 40 in the epiphany program. See file:

https://github.com/joseluisquiroga/para ... _prog_16.c

That is: Either there was enough time for it to be assigned or not, before it is read in the host program.

4) aux is a variable in the stack (,[fp,+0x3]) which is the one assigned several times in the eprog. The stack register sp is initialized in the start assembler program to local memory. See file (lines 13 and 14):

https://github.com/joseluisquiroga/para ... /e_start.s

So it is all local in core memory (not off core, not off chip) the one that is been assigned for line 20 to 39 of the eprog. Only up to line 40 off chip (shdmem variable) memory is assigned and it must either have the value of val2 or zero. Only if I read zero in the host (which never happens in my running tries) I did not give enough time, otherwise it must have the value that val2 was assigned in line 33.

5) The program is just a modification of the helloworld example so you can build it and run it using the script files:

https://github.com/joseluisquiroga/para ... 6/build.sh
and
https://github.com/joseluisquiroga/para ... -16/run.sh

===================

I would like some feedback:

Do you get the same result 0xddd?

Thanks again.

JLQ.

The problem persists even in the same memory bank:

https://github.com/joseluisquiroga/para ... lq-test-17

I initialized the sp to the end of the first memory bank but no luck. Seems a CPU problem ....

JLQ.

MY MISTAKE AFTER ALL ...

Sorry every one that looked at this post.

Thank you sebraa for your time.

Look at my mistake:

https://github.com/joseluisquiroga/para ... -test-16ok

What was happening was that the initial branch (addr zero, SYNC interrupt) was not been executed (it was not declared as "ax" section) so the sp was NOT been initialized by my asm code in "normal_start" resulting in a shared mem addr for the stack.... so aux var was in shared mem ..... I forgot I had that mistake in my early tests and reused old code to do some simple ones ...

Sorry every one again.

That is what happens when you "muck around" with the start code...

JLQ.