[email protected], 2016/05/12
Issue with the -msmall16 option, e-gcc 4.8.2

1/ Reformatted my SD card with the 2015.1 Zynq 7020 headless image (from late March 2016)
2/ Copied build.sh + run.sh + src/e_dbg3.c on the Parallella
3/ compared e-objdump throughputs => e_emem_config and the dest offset from e_read() are broken with option -msmall16
Could not test with the 2016.3 image - the network config changed or I dunno what, my SSH/putty/Suzanne Matthews method is KO too.
Since I use e_read() / e_write() only once in the DEVICE code, I'll probably patch the input parameters and that's all -- -msmall16 avoids the superfluous movt rX, 0x0 :D

parallella@parallella:~$ cat build.sh

!/bin/bash

set -e

ESDK=${EPIPHANY_HOME}
ELIBS="-L ${ESDK}/tools/host/lib"
EINCS="-I ${ESDK}/tools/host/include"
ELDF=${ESDK}/bsps/current/internal.ldf

SCRIPT=$(readlink -f "$0")
EXEPATH=$(dirname "$SCRIPT")
cd $EXEPATH

CROSS_PREFIX=
case $(uname -p) in
arm*)
# Use native arm compiler (no cross prefix)
CROSS_PREFIX=
;;
*)
# Use cross compiler
CROSS_PREFIX="arm-linux-gnueabihf-"
;;
esac

Build HOST side application

${CROSS_PREFIX}gcc -Ofast src/$1.c -o Debug/$1.elf ${EINCS} ${ELIBS} -le-hal -le-loader -lpthread

Build DEVICE side program

e-gcc -T ${ELDF} -Ofast $2 $3 $4 $5 $6 $7 $8 $9 src/e_$1.c -o Debug/e_$1.elf -le-lib

Convert ebinary to SREC file

e-objcopy --srec-forceS3 --output-target srec Debug/e_$1.elf Debug/e_$1.srec

parallella@parallella:~$ cat run.sh

!/bin/bash

set -e

cd Debug

./$1.elf $2 $3 $4 $5 $6 $7 $8 $9

parallella@parallella:$ ./build.sh dbg3
parallella@parallella:$ ./run.sh dbg3
Eternity II running under Parallella :)

(... works fine, 16 eCore shake hands as for Paralle2 1st version)

parallella@parallella:~$ e-objdump -d Debug/e_dbg3.elf > ok

parallella@parallella:$ ./build.sh dbg3 -msmall16
parallella@parallella:$ ./run.sh dbg3
Eternity II running under Parallella :)

(... KO, 0 eCore ending)

parallella@parallella:~$ e-objdump -d Debug/e_dbg3.elf > ko

parallella@parallella:~$ diff ok ko
244,254c244,254
< 758: 10d6 lsl r0,r4,0x6
< 75a: 3116 lsl r1,r4,0x8
< 75c: 243a sub r1,r1,r0
< 75e: 080b 0002 mov r0,0x40
< 762: 000b 1012 movt r0,0x100
< 766: 241a add r1,r1,r0
< 768: 355c 0400 str r1,[sp,+0x2]
< 76c: 0a0b 0002 mov r0,0x50
< 770: 3803 mov r1,0xc0
< 772: 8f0b 2092 mov r12,0x978

< 776: 35dc 0400 str r1,[sp,+0x3]

758: 3116 lsl r1,r4,0x8
75a: 10d6 lsl r0,r4,0x6
75c: 043a sub r0,r1,r0
75e: 280b 0002 mov r1,0x40
762: 200b 1012 movt r1,0x100
766: 009a add r0,r0,r1
768: 155c 0400 str r0,[sp,+0x2]
76c: 8f0b 2092 mov r12,0x978
770: 1803 mov r0,0xc0
772: 15dc 0400 str r0,[sp,+0x3]
776: 200b 0602 mov r1,0x6000
256,275c256,273
< 77c: 200b 0602 mov r1,0x6000
< 780: 6003 mov r3,0x0
< 782: 800b 3002 movt r12,0x0
< 786: 000b 1002 movt r0,0x0
< 78a: 115f 0402 jalr r12
< 78e: 01a2 nop
< 790: 000b 0002 mov r0,0x0
< 794: 080b 1002 movt r0,0x40
< 798: 101a add r0,r4,r0
< 79a: 200b 0002 mov r1,0x0
< 79e: 0056 lsl r0,r0,0x2
< 7a0: 200b 1402 movt r1,0x4000
< 7a4: 2054 str r1,[r0]
< 7a6: 77cc 2400 ldr fp,[sp,+0x7]
< 7aa: 10e2 mov r0,r4
< 7ac: 974c 0400 ldr r4,[sp,+0x6]
< 7b0: d6cc 2400 ldr lr,[sp,+0x5]
< 7b4: b41b 2403 add sp,sp,24
< 7b8: 194f 0402 rts

< 7bc: 0000 beq 7bc <_main+0x8c>

77c: 6003 mov r3,0x0
77e: 800b 3002 movt r12,0x0
782: 004b 0002 mov r0,0x2
786: 115f 0402 jalr r12
78a: 01a2 nop
78c: 000b 0002 mov r0,0x0
790: 080b 1002 movt r0,0x40
794: 101a add r0,r4,r0
796: 200b 0002 mov r1,0x0
79a: 0056 lsl r0,r0,0x2
79c: 200b 1402 movt r1,0x4000
7a0: 2054 str r1,[r0]
7a2: 77cc 2400 ldr fp,[sp,+0x7]
7a6: 10e2 mov r0,r4
7a8: 974c 0400 ldr r4,[sp,+0x6]
7ac: d6cc 2400 ldr lr,[sp,+0x5]
7b0: b41b 2403 add sp,sp,24
7b4: 194f 0402 rts
parallella@parallella:~$

parallella@parallella:~$ cat src/e_dbg3.c

include <e-lib.h> //mandatory even for a minimalist design -- e_get_coreid(), e_read(), e_write()

define uint8_t unsigned char //avoid stdint.h

define uint16_t unsigned short

define uint32_t unsigned int

define uint64_t unsigned long long

define int64_t long long

define CORE_N 16

pragma pack(4)

//to DEVICE
typedef struct S_input {
int64_t tuile2do;
int bordertuile2do;
signed char tdam[180];
}Sinput;
//from DEVICE
typedef struct S_output {
int64_t globaltsolN[80];
int globalres;
int align8;
}Soutput;
//shared MEMORY
typedef struct S_io {
int tcmd[CORE_N];
Sinput tin [CORE_N];
Soutput tout[CORE_N];
}Sio;

define CMD_LEN (CORE_N * sizeof(uint)) //ARM handling Epiphany tasks: start, end

define CMD_INIT 0x80000000 //host init

define CMD_DONE 0x40000000 //eCore did the job properly (probably ; some bug might crush this word but it's highly improbable)

//ARM <-> Epiphany

define SHARED_RAM 0x01000000

define SHARED_IN 0x6000

define SHARED_OUT (SHARED_IN + sizeof(Sinput))

//volatile Sinput in;
//volatile Soutput out;
volatile Sinput in SECTION(".data_bank3");//0x6000
volatile Soutput out SECTION(".data_bank3");//0x6000 + sizeof(Sinput)

//#######################################

int main(void) {
e_coreid_t coreid;
int row, col, cmdI;
int cmd;// address of shared memory
int src;// address of shared memory source

coreid=e_get_coreid();//query the coreID from hardware
row=(coreid>>6) - 32;//dirty but OK for MY 16-core Epiphany
col=(coreid&15) - 8;
cmdI=(row<<2) + col;

src=SHARED_RAM + CMD_LEN + (cmdI * sizeof(Sinput));
//e_read((unsigned int *)&e_emem_config, (void *)&in, 0, 0, (void *)src, sizeof(Sinput));
e_read((unsigned int *)&e_emem_config, (void *)SHARED_IN, 0, 0, (void *)src, sizeof(Sinput));

cmd=SHARED_RAM + (cmdI *4);
asm("nop");
*(int *)cmd=CMD_DONE;
return cmdI;
}

my gcc-explorer output of e_dbg3.c: not handling the SECTION directive

-T /home/ylav/dev/parallella/epiphany-libs-2015.1/bsps/current/internal.ldf -Ofast -mfp-mode=int -msmall16 -le-lib

   str r4,[sp],#-6
    mov r0, %low(_e_get_coreid)
    str lr,[sp,#5]
    str fp,[sp,#7]
    movt r0, %high(_e_get_coreid)
    jalr r0
    mov r1,#15
    lsr r4,r0,#6
    add r4,r4,#-32
    and r0,r0,r1
    add r0,r0,#-8
    lsl r4,r4,#2
    add r4,r4,r0
    lsl r1,r4,#8
    lsl r0,r4,#6
    sub r0,r1,r0
    mov r1, %low(#16777280)
    movt r1, %high(#16777280)
    add r0,r0,r1
    str r0,[sp,#2]
    mov ip, %low(_e_read)
    mov r0,#192
    str r0,[sp,#3]
    mov r1,#24576
    mov r2,#0
    mov r3,#0
    movt ip, %high(_e_read)
    mov r0,_e_emem_config
    jalr ip

; 62 "/tmp/gcc-explorer-compiler116412-10341-wxbyvm/example.c" 1
nop
; 0 "" 2
mov r0, %low(#4194304)
movt r0, %high(#4194304)
add r0,r4,r0
mov r1, %low(#1073741824)
lsl r0,r0,#2
movt r1, %high(#1073741824)
str r1,[r0]
ldr fp,[sp,#7]
mov r0,r4
ldr r4,[sp,#6]
ldr lr,[sp,#5]
add sp,sp,#24
rts

If e_phnum equals PN_XNUM, the program should seek to the first section header, read its sh_info field, and use that as the actual, 32-bit e_phnum value.

Documented here: http://linux.die.net/man/5/elf

UPDATE: it turns out this issue only exists in the default epiphany-gcc branch, epiphany-gcc-4.7 and epiphany-gcc-4.8 works fine.

issue resolved. ticket can be closed.

gcc, gdb and binutils all have this file and they should be identical. however, binutils fails to build because a new value was added to an enumeration in it, LDPO_PIE.

a simple diff reveals a minor addition.

~/epiphany-sdk$ diff gcc/include/plugin-api.h gdb/include/plugin-api.h
~/epiphany-sdk$ diff gcc/include/plugin-api.h binutils/include/plugin-api.h
69c69,70
<   LDPO_DYN

---
>   LDPO_DYN,
>   LDPO_PIE

of course srcw/include/plugin-api.h points to gcc's copy

A bunch of other targets do it.

Now the global reentrant structure (_impure_data) takes up 1096 bytes.

Need to read code and check implications before doing it.

We might also want to make atexit0 global.

And there is a flag to make atexit() not use dynamic memory.

Ok so I was trying to compile a port of code I did yesterday. It compiles fine for the ARM Host, but when I tryed to compile to Epiphany, it gets me an error:

linaro-nano:~/minerwork/test> ./build.sh
Compiling helpers
Compiling aes_helper
Compiling blake
src/sph/blake.c: In function ‘blake64’:
src/sph/blake.c:937:1: error: unable to generate reloads for:
 }
 ^
(insn 109 2365 2362 8 (parallel [
            (set (reg:CC 66 cc1)
                (compare:CC (reg:SI 2204 [ T0 ])
                    (const_int -1024 [0xfffffc00])))
            (set (reg:SI 1 r1 [2444])
                (plus:SI (reg:SI 2204 [ T0 ])
                    (const_int 1024 [0x400])))
        ]) src/sph/blake.c:929 63 {*sub_f_add_imm}
     (expr_list:REG_DEAD (reg:SI 2204 [ T0 ])
        (nil)))
src/sph/blake.c:937:1: internal compiler error: in find_reloads, at reload.c:3879
0x255d01 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
    /home/linaro/work/esdk/toolchain/srcw/gcc/rtl-error.c:109
0x2485d7 find_reloads(rtx_def*, int, int, int, short*)
    /home/linaro/work/esdk/toolchain/srcw/gcc/reload.c:3879
0x25291b calculate_needs_all_insns
    /home/linaro/work/esdk/toolchain/srcw/gcc/reload1.c:1520
0x253fad reload(rtx_def*, int)
    /home/linaro/work/esdk/toolchain/srcw/gcc/reload1.c:941
0x1d0561 do_reload
    /home/linaro/work/esdk/toolchain/srcw/gcc/ira.c:4679
0x1d0561 rest_of_handle_reload
    /home/linaro/work/esdk/toolchain/srcw/gcc/ira.c:4779
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <[email protected]> for instructions.

So I pushed all codes to racerxdl/e_x11 so tests can be done.

I didnt made the blake code, but works fine on x86 and ARM CPUs. Also I dont know what exactly is causing that internal error. Normally I would not add a Issue here to not bother you with that problems. But since its a compiler related stuff, I think its good to show you whats happening.

Lucas

Mac build doesn't work for me.
Initial error message was:
ld: 255 duplicate symbols for architecture x86_64

After following suggestions by user rsneekes the toolchain builds OK.
The SDK however stopped with this message:
make: arm-linux-gnueabihf-g++: No such file or directory

After applying the changes made by jeremeybennett this changed to:
/bin/sh: -Wall: command not found

Please check this forum discussion for details:
http://forums.parallella.org/viewtopic.php?f=13&t=966

Thanks,
Sukandar

OS X 10.9.2
XCode 5.1.1

i get a bunch of errors of undeclared variables and implicit function declarations when compiling srcw/binutils/dwarf.c

it turns out that srcw/include/dwarf2.h points gcc/include/dwarf2.h
changing this to point to binutils/include/dwarf2.h fixes all but three errors:

dwarf.o: In function `get_TAG_name':
/home/gravis/epiphany-sdk/srcw/binutils/dwarf.c:662: undefined reference to `get_DW_TAG_name'
dwarf.o: In function `get_AT_name':
/home/gravis/epiphany-sdk/srcw/binutils/dwarf.c:1867: undefined reference to `get_DW_AT_name'
dwarf.o: In function `get_FORM_name':
/home/gravis/epiphany-sdk/srcw/binutils/dwarf.c:678: undefined reference to `get_DW_FORM_name'

i'm betting changing the symbolic link to point to the binutils version breaks gcc but that comes after building binutils. :)

note: building binutils independently works fine.

unisrc isn't working out for us any more.

For starters, it's fragile because depending on in which order we pass in the component dirs to symlink-all we get different header versions. And then things start to break because component B wasn't compatible with component A's headers. So you might end up with having to patch component B (this had to be done for gcc-4.9).

Also, as of gdb-7.8 and binutils-2.25 both upstream branches have both the 'gdb' and 'binutils' directories in them (with different versions of course) so we'd have to patch symlink-all.sh to omit directories etc. It's just messy.

Initialize bss section in loader, not in epiphany_start.

Eliminates a group of potential races among cores.

Hello,

I've started looking into the Epiphany SDK however after investigation of the code I was disappointed to discover that the SDK requires installation into /opt/adapteva. As such, installation of the SDK requires root access.

In the documentation, there is one main environment variable, EPIPHANY_BUILD_HOME, which:

• has the epiphany-sdk ($EPIPHANY_BUILD_HOME/sdk);
• contains downloaded source code (e.g. $EPIPHANY_BUILD_HOME/gcc, $EPIPHANY_BUILD_HOME/unisrc-2015.1); and
• is where the SDK is installed to ($EPIPHANY_BUILD_HOME/esdk.2015.1).

As mentioned, there are sections in the scripts that essentially hard-code /opt/adapteva and this layout.

I have already started on removing this restriction whilst keeping backwards compatibility, however I would like to make it completely customisable.

There are a number of environment variables already defined that are either duplicates or not being used. This is what I'd like to change them to (square brackets suggest defaults to keep current behaviour):

• ESDK - location of the epiphany-sdk.git checkout [/opt/adapteva/sdk]
• EPIPHANY_HOME - prefix in which to install the SDK ($EPIPHANY_HOME/esdk.2015.1) [/opt/adapteva]
• EPIPHANY_BUILD_HOME - path to download source code repos ($EPIPHANY_BUILD_HOME/gcc, $EPIPHANY_BUILD_HOME/unisrc-2015.1) [/opt/adapteva]

I'm still working on getting this into place (modifying the $basedir variable in the scripts), however this will be rather intrusive to the build scripts.

What do you think?

I attempt to build 2015.1 according to the instructions:

git clone https://github.com/adapteva/epiphany-sdk sdk
export EPIPHANY_BUILD_HOME=pwd
sdk/download-toolchain.sh
/sdk/build-epiphany-sdk.sh -C -R -a x86_64

The build fails. The log shows that the build failure is in building run, and that many symbols in run are duplicates. Example fragments from the log:

/home/marty/projects/adapteva/libtool: compile: gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_LOCALE_H=1 -DHAVE_WCHAR_H=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_STDINT_H=1 -DHAVE_VA_COPY=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_HOST_CORE2=1 -DHAVE_LONG_LONG=1 -DHAVE_INTMAX_T=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_DENORMS=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 -DHAVE_LDOUBLE_IEEE_EXT_LITTLE=1 -DLT_OBJDIR=".libs/" -DHAVE_ATTRIBUTE_MODE=1 -DHAVE_ALLOCA_H=1 -I. -I/home/marty/projects/adapteva/2015.1/unisrc-2015.1/mpfr -I/home/marty/projects/adapteva/2015.1/builds/bd-x86_64-2015.1/./gmp -g -O2 -MT exceptions.lo -MD -MP -MF .deps/exceptions.Tpo -c /home/marty/projects/adapteva/2015.1/unisrc-2015.1/mpfr/exceptions.c -o exceptions.o
2015.1/unisrc-2015.1/sim/epiphany/../common/cgen-ops.h:331: multiple definition of SUBWORDSIUQI' libsim.a(cgen-utils.o):/home/marty/projects/adapteva/2015.1/unisrc-2015.1/sim/epiphany/../common/cgen-ops.h:331: first defined here libsim.a(epiphany.o): In functionSUBWORDDIQI':
/home/marty/projects/adapteva/2015.1/unisrc-2015.1/sim/epiphany/../common/cgen-ops.h:338: multiple definition of `SUBWORDDIQI'
libsim.a(cgen-utils.o):/home/marty/projects/adapteva/2015.1/unisrc-2015.1/sim/epiphany/../common/cgen-ops.h:338: first defined here

...

Makefile:12507: recipe for target 'all-sim' failed
make: *** [all-sim] Error 2

Sometimes you know that the epiphany can't receive any interrupts while your program is running (e.g. because all interrupts are masked, as is the default).

In these cases I believe it is unnecessary to disable and reenable interrupts around arithmode switches, and doing so sometimes costs noticeable performance in cases where floating point and integer arithmetic is mixed.

Therefore, it would be useful to have a flag to choose whether or not interrupts should be disabled when switching arithmode.

e-readelf -s foo.o

reports

...
    36: 00000000   110 NOTYPE  GLOBAL DEFAULT    1 _foo
...

but it should report (?)

...
    36: 00000000   110 FUNC  GLOBAL DEFAULT    1 _foo
...

It copies the header, but not the actual .so file ...

Happens when there is no BSS data.

https://github.com/adapteva/epiphany-newlib/blob/epiphany-newlib-1.20-software-cache/libgloss/epiphany/crt0.S#L79

Should be bgte

This was fixed previous but seems to have gotten unfixed. if you compile the archived version of binutils there is no issue but if you git clone it, it will cry.

/home/gravis/epiphany-sdk/srcw/bfd/doc/bfd.texinfo:325: unknown command colophon' /home/gravis/epiphany-sdk/srcw/bfd/doc/bfd.texinfo:336: unknown commandcygnus'
Makefile:421: recipe for target 'bfd.info' failed

I looked it up and colophon and cygnus are from texinfo 4.x while the world has moved on to texinfo 5.x

To reproduce:

$ ./sdk/build-epiphany-sdk.sh -C -R -a x86_64

< BIG SNIP >

Building Epiphany multicore simulator...
Error: Epiphany multicore simulator build failed.
Build failed. See /home/marty/projects/adapteva/2015.1/logs/2015.1/build-2015-07-28-2052.log for details.
The toolchain build failed!

Here's a fragment from the log:

sim/epiphany/../../opcodes -pthread -lrt -fPIC -fvisibility=hidden -c -o nrun.o -MT nrun.o -MMD -MP -MF .deps/nrun.Tpo /home/marty/projects/adapteva/2015.1/gdb-multicore-sim/sim/epiphany/../common/nrun.c
In file included from /home/marty/projects/adapteva/2015.1/gdb-multicore-sim/sim/epiphany/esim/esim.c:53:
/home/marty/projects/adapteva/2015.1/gdb-multicore-sim/sim/epiphany/esim/esim-int.h: In function es_cas8': /home/marty/projects/adapteva/2015.1/gdb-multicore-sim/sim/epiphany/esim/esim-int.h:61: warning: implicit declaration of function__sync_val_compare_and_swap'
/home/marty/projects/adapteva/2015.1/gdb-multicore-sim/sim/epiphany/esim/esim-int.h: In function es_atomic_incr8': /home/marty/projects/adapteva/2015.1/gdb-multicore-sim/sim/epiphany/esim/esim-int.h:74: warning: implicit declaration of function__sync_fetch_and_add'
/home/marty/projects/adapteva/2015.1/gdb-multicore-sim/sim/epiphany/esim/esim-int.h: At top level:
/home/marty/projects/adapteva/2015.1/gdb-multicore-sim/sim/epiphany/esim/esim-int.h:114: error: redefinition of typedef 'sim_cpu'
/home/marty/projects/adapteva/2015.1/gdb-multicore-sim/sim/epiphany/../common/sim-base.h:79: error: previous declaration of 'sim_cpu' was here
/home/marty/projects/adapteva/2015.1/gdb-multicore-sim/sim/epiphany/esim/esim-int.h:175: error: redefinition of typedef 'es_state'
/home/marty/projects/adapteva/2015.1/gdb-multicore-sim/sim/epiphany/esim/esim.h:57: error: previous declaration of 'es_state' was here
/home/marty/projects/adapteva/2015.1/gdb-multicore-sim/sim/epiphany/esim/esim.h:77: warning: 'es_initialized' declared inline after being called
/home/marty/projects/adapteva/2015.1/gdb-multicore-sim/sim/epiphany/esim/esim.h:77: warning: previous declaration of 'es_initialized' was here
Makefile:579: recipe for target 'esim/esim.o' failed

[dma_message_read]$ export EPIPHANY_HOME=/home/cib/cross/esdk.5.13.07.10/
[dma_message_read]$ ./build.sh
/tools/e-gnu/bin/../libexec/gcc/epiphany-elf/4.8.2/cc1: error while loading shared libraries: libmpc.so.2: cannot open shared object file: No such file or directory

When setting integer arithmetic mode, the CONFIG register is set to 0x00080000.

If instead it was set to 0x00080001 IALU2 operations would have 1 less cycle of latency with no downside (because integer arithmetic operations never require rounding).

I believe the only change required is the following diff, but I'm not familiar enough with either gcc or the epiphany code within gcc to be certain there aren't other places that need changing.

--- a/gcc/config/epiphany/epiphany.c
+++ b/gcc/config/epiphany/epiphany.c
@@ -2618,7 +2618,7 @@ emit_set_fp_mode (int entity, int mode, HARD_REG_SET regs_
     {
       gcc_assert (mode >= 0 && mode <= 2);
       if (mode == 1)
-       emit_move_insn (MACHINE_FUNCTION (cfun)->or_mask, GEN_INT(0x00080000));
+       emit_move_insn (MACHINE_FUNCTION (cfun)->or_mask, GEN_INT(0x00080001));
       return;
     }
   else if (entity == EPIPHANY_MSW_ENTITY_CONFIG)

Cheers,
Mike

By default, gcc only allows 30 registers to be used in an inline asm block. Especially when using hardware loops it's nice to be able to replace fairly large blocks of code with asm, and I find the 30 register limit a pain given the epiphany has plenty of registers. This is made worse because read/write registers count twice against this limit!

I've done limited testing, but this change seems to work for me:
MichaelBell/epiphany-gcc@0dc1a94

I can submit a pull request if you want, but would like someone with more gcc experience to do a bit of verification first!

Deadlock if core0 calls e_barrier_init() after some other core calls e_barrier()

Force user to have bar_array in .bss

Then we can eliminate this:
https://github.com/adapteva/epiphany-libs/blob/2015.1/src/e-lib/src/e_mutex_barrier_init.c#L38
which can overwrite flag set here:
https://github.com/adapteva/epiphany-libs/blob/2015.1/src/e-lib/src/e_mutex_barrier.c#L99
and then core0 gets stuck here:
https://github.com/adapteva/epiphany-libs/blob/2015.1/src/e-lib/src/e_mutex_barrier.c#L87

Depends on #54

Unlikely to happen on hw for "normal programs" (e.g., SIMD)

The build-epiphany-sdk.sh script writes in to /opt/ and so requires sudo rights (or permissions in /opt/ need to be changed before the build script is run). It would be nicer (and safer) to have the whole script run to completion with the rights of the user who invokes it.

just tried to compile and build-toolchain.sh ended in failure.

relevant part of the log.

/home/gravis/epiphany-sdk/bld-epiphany/gcc/../gas/as-new: unrecognized option '--64'
Makefile:3845: recipe for target 'build/version.o' failed
make[1]: *** [build/version.o] Error 1

full log: http://adaptivetime.com/build-2014-05-18-0120.log.7z

my build script: http://pastebin.com/CtgsgmZu

my system:
Linux base 3.12-0.bpo.1-amd64 #1 SMP Debian 3.12.9-1~bpo70+1 (2014-02-07) x86_64 GNU/Linux
gcc-4.8.real (Debian 4.8.2-21) 4.8.2
GNU assembler (GNU Binutils for Debian) 2.24.51.20140425
flex 2.5.39
bison (GNU Bison) 3.0.2

Hi! I believe I have stumbled upon a bug in your GCC backend:

#define FUNNY_NUMBER1  268440163

/*
 * When compiled with -Os, -Og or -O0 and sz==0, I will set the ARITHMODE flags
 * of the config register from an unitilialized gp register.
 */
unsigned
hash(char *ptr, unsigned sz, unsigned hash)
{
    while (sz--) {
        hash = hash*FUNNY_NUMBER1 + *ptr++;
    }
    return hash;
}

The issue is easily spotted in the assembly output:

kalle ~/repro> e-gcc -Og -S -c gcc.c && cat gcc.s
    .file   "gcc.c"
    .section .text
    .balign 4
    .global _hash
_hash:
    mov r3,r0
    mov r0,r2
    mov r17, %low(#268440163)
    movt r17, %high(#268440163)
    b .L2
.L3:
    mov r1, %low(#524288)
    movt r1, %high(#524288)
    movfs r16,config
    gid
    movfs r18,config
    orr r18,r18,r1
    movts config,r18
    gie
    gid
    movfs r19,config
    orr r19,r19,r1
    movts config,r19
    gie
    imul r0, r0, r17
    ldrb r1,[r3]
    add r0,r0,r1
    mov r1,r2
    add r3,r3,#1
.L2:
    add r2,r1,#-1
    sub r19,r1,#0
    bne .L3
    mov r1, %low(#-917506)
    movt r1, %high(#-917506)
    gid
    movfs r3,config
    eor r3,r3,r16
    and r3,r3,r1
    eor r3,r3,r16
    movts config,r3
    gie
    gid
    movfs r19,config
    eor r19,r19,r16
    and r19,r19,r1
    eor r19,r19,r16
    movts config,r19
    gie
    rts
    .size   _hash, .-_hash
    .ident  "GCC: (Epiphany toolchain 2015.1) 4.8.2 20130729 (prerelease)"

Control will flow from _hash to .L2, never take the branch to .L3, thus never saving config to r16, and proceed to restore ARITHMODE from r16 (that remains unitinialized) before returning.

You might ask, what's the issue? Well, consider that this function might set ARITHMODE to 010. The next time any function attempts integer multiplication, it will assert config bit 19, assuming that it results in an ARITHMODE of 100. In this case, though, that results in an ARITHMODE of 110, which on my E16G301 causes the "FPU/IALU2" pipeline to perform floating-point math.

1. installation script should create bsps/current not bsps/bsp as I can infer from the build
2. add ARCH=armv7l and change the following in the build.sh and run.sh
   ELIBS=${ESDK}/tools/host.${ARCH}/lib
   EINCS=${ESDK}/tools/host.${ARCH}/include

ELIBS=${ESDK}/tools/host/lib:${LD_LIBRARY_PATH}
ELIBS=${ESDK}/tools/host.${ARCH}/lib:${LD_LIBRARY_PATH}

1. remind user to add env variable, such as, to make hello_world run
   export EPIPHANY_HDF=/opt/adapteva/esdk/bsps/current/zed_E16G3_512mb.hdf

Attempting to obtain gcc (and other tools) via git fails on Fedora 22 using git 2.4.3:

to reproduce:

$ git clone https://github.com/adapteva/epiphany-sdk sdk
$ ./sdk/build-epiphany-sdk.sh -C -R -a x86_64

from the log file

Fetching gcc
fatal: No remote repository specified. Please, specify either a URL or a
remote name from which new revisions should be fetched.
ERROR (versions): Failed to fetch gcc

similarly for binutils, console output:

Fetching binutils
Checking out epiphany-binutils-esdk-2015.1
Pulling latest version of epiphany-binutils-esdk-2015.1
ERROR (versions): Failed to pull epiphany-binutils-esdk-2015.1 of binutils

this repeats for all of the cloned directories. It appears that some of the logic around checking out or pulling the correct revision is failing, reporting that the right version couldn't be checked out or pulled, when it had been.

If the cloning is done manually, the same problem crops up later when fetching the epiphany library and parallella-linux repositories

Toolchain is compilable on Mac OSX.
latest tested version by me(8171c73)

The SDK is not compilable due to multiple issues in the build scripts:
ln does not have -T option, it need to be removed
target directory should not exist when the ln is called. mkdir is not required before ln.
cp does not have -D option, also need to be removed

makefiles referes to the "gcc" as compiler for the sdk components. it should be the arm-parallella-host-gcc or the e-gcc. without specifying the gcc it will be the host(osx) default compiler.

The exit from "main" running on the Epiphany core ends with a "trap" instruction, causing the Epiphany core to enter a debug state. The debug state blocks all interrupts from happening, making launching successive kernels awkward.

We should consider using some other safe method for indicating exit from program.

The current workaround is to put an infinite loop or idle statement at the end of "main" to prevent exit.

This works, but I think we better change the linker flags instead.

e-run --e-coreid 0x800 --e-cols 1 --e-rows 1 --memory-region 0x81000000,0x02000000  ./bin/complex_numbers.elf

typedef struct {
int x ;
int y;
.
.
.
} e_t;
e_t p[N];
host code copies the struct from epiphany and prints it
looks like p[1].x=1; will cause p[1].y to be 1
i'm thinking alignment/ packing differences from host compiler to epiphany compiler

Hi Joern,

Could you please take a look at this?

Thanks,
Ola

With ESDK-2014.11 (e-gcc 4.8):

#include <math.h>
void test(int a, float *b, int n)
{
    if (n < 10) {
        *b = a*fminf(0.0,1.0*a);
    }
}

$ e-gcc -c -Ofast -mno-soft-cmpsf bug.c 
bug.c: In function ‘test’:
bug.c:9:1: error: unrecognizable insn:
 }
 ^
(insn 22 21 23 4 (set (reg:SF 92 [ D.2031 ])
        (if_then_else:SF (ungt:SF (reg:CC_FP 67 cc2)
                (const_int 0 [0]))
            (reg:SF 97)
            (reg:SF 92 [ D.2031 ]))) bug.c:7 -1
     (nil))
bug.c:9:1: internal compiler error: in extract_insn, at recog.c:2154
0x7ac31a _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
    /home/esim/esdk-src/unisrc-2014.11/gcc/rtl-error.c:109
0x7ac349 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
    /home/esim/esdk-src/unisrc-2014.11/gcc/rtl-error.c:117
0x783364 extract_insn(rtx_def*)
    /home/esim/esdk-src/unisrc-2014.11/gcc/recog.c:2154
0x690f83 instantiate_virtual_regs_in_insn
    /home/esim/esdk-src/unisrc-2014.11/gcc/function.c:1561
0x690f83 instantiate_virtual_regs
    /home/esim/esdk-src/unisrc-2014.11/gcc/function.c:1928
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <[email protected]> for instructions.

build-toolchain.sh fails when building on a Parallella board. Please see details in the forum post:

http://forums.parallella.org/viewtopic.php?f=13&t=471#p3787

If I run a ./build-epiphany-sdk.sh job more than once I get errors like this:

fatal: destination path 'parallella-linux' already exists and is not an empty directory.

This error is thrown by git when cloning the parallella-linux repository. I have fixed this in the shell script in a quick 'n' dirty way (by moving the old copy of parallella-linux if it exists, around line 243 of the script), but it would make the script quicker and cleaner to check whether the repos have been pulled and update them, rather than cloning each time (or alternatively use git submodules).

This:

volatile register unsigned reg_val;

causes every use of the value to go through the stack.

relevant fragment of machine code with volatile:

42: 0512 movfs r0,status
44: 15dc 0400 str r0,[sp,+0x3]
48: 15cc 0400 ldr r0,[sp,+0x3]

with volatile deleted:

42: 0512 movfs r0,status

e_init(char *hdf) misbehaves if the EPIPHANY_HOME environment variable is not set.

Looking in epiphany-hal.c, we see the fetch of hdf_env_var_name (set to "EPIPHANY_HDF") is guarded, whereas the following fetch of esdk_path (set to "EPIPHANY_HOME") is not. If esdk_env is NULL, strncpy() is called on a NULL src argument, a case which is not even mentioned in the strncpy man pages.

A secondary issue is the strncat used to build the platform.hdf path. Its n argument is too large and can potentially lead to a buffer overflow.

See https://parallella.org/forums/viewtopic.php?f=13&t=2544&p=14462#p14462 for proposed fixes.

Hi,

I removed /opt/adapteva, and have built esdk from latest and greatest (2015.1, native build), and have updated all the paths. Most of the examples are working (from root), but I do get some error messages:

root@linaro-nano:/home/linaro/epiphany-examples/apps/hello-world# ./build.sh && ./run.sh
hello_world.elf: ee_write_esys(): ESYS mmap failure.
hello_world.elf: e_reset_system(): Failed

0: Message from eCore 0x8ca ( 3, 2): "Hello World from core 0x8ca!"
1: Message from eCore 0x84b ( 1, 3): "Hello World from core 0x84b!"
2: Message from eCore 0x84b ( 1, 3): "Hello World from core 0x84b!"
3: Message from eCore 0x888 ( 2, 0): "Hello World from core 0x888!"
4: Message from eCore 0x849 ( 1, 1): "Hello World from core 0x849!"
5: Message from eCore 0x88b ( 2, 3): "Hello World from core 0x88b!"
6: Message from eCore 0x88b ( 2, 3): "Hello World from core 0x88b!"
7: Message from eCore 0x8ca ( 3, 2): "Hello World from core 0x8ca!"
8: Message from eCore 0x80a ( 0, 2): "Hello World from core 0x80a!"
9: Message from eCore 0x808 ( 0, 0): "Hello World from core 0x808!"
10: Message from eCore 0x8c8 ( 3, 0): "Hello World from core 0x8c8!"
11: Message from eCore 0x8c9 ( 3, 1): "Hello World from core 0x8c9!"
12: Message from eCore 0x88a ( 2, 2): "Hello World from core 0x88a!"
13: Message from eCore 0x88b ( 2, 3): "Hello World from core 0x88b!"
14: Message from eCore 0x8cb ( 3, 3): "Hello World from core 0x8cb!"
15: Message from eCore 0x84a ( 1, 2): "Hello World from core 0x84a!"
16: Message from eCore 0x88a ( 2, 2): "Hello World from core 0x88a!"
17: Message from eCore 0x84b ( 1, 3): "Hello World from core 0x84b!"
18: Message from eCore 0x848 ( 1, 0): "Hello World from core 0x848!"
19: Message from eCore 0x8ca ( 3, 2): "Hello World from core 0x8ca!"
hello_world.elf: ee_read_esys(): ESYS mmap failure.
hello_world.elf: ee_read_esys(): ESYS mmap failure.
hello_world.elf: ee_read_esys(): ESYS mmap failure.
hello_world.elf: ee_write_esys(): ESYS mmap failure.
hello_world.elf: ee_write_esys(): ESYS mmap failure.
hello_world.elf: ee_write_esys(): ESYS mmap failure.
$

Some other examples works (eprime), but some dont (fft2d, matmul-16 - they are stuck and do nothing).

All with these messages:

root@linaro-nano:/home/linaro/epiphany-examples/apps/matmul-16# ./run.sh

Calculating: C[512][512] = A[512][512] * B[512][512]
matmul.elf: ee_write_esys(): ESYS mmap failure.
matmul.elf: e_reset_system(): Failed

stuck for minutes

^C

GCC emits the instruction pair...

mov r#, 0x####
movt r#, 0x####

for loading a 32-bit value into a register. When the compile-time value is less than 16-bits, the movt instruction is unnecessary since the mov (immediate) instruction will load the full value and zero the high bits.

For example, I find this pattern a lot in compiled code:

mov r#, 0x####
movt r#, 0x0

The emitted code for the movt is larger than necessary and performance takes a small hit.

In pages 93 and 95 of the Epiphany SDK Reference (http://adapteva.com/docs/epiphany_sdk_ref.pdf) the signature for e_read() is described as:

void *e_read(void *remote, void *dst, unsigned row, unsigned col,
const void *src, size_t bytes);

The position of dst is wrong, it actually goes after src:

void *e_read(void *remote, unsigned row, unsigned col,
const void *src, void *dst, size_t bytes);

I haven't used e_write() yet, but I guess it has the same problem.

Please accept my pull request to resolve C++ linkage issues with e-lib as discussed on the forum.

Unless I'm missing something, the epiphany simulator is not helpful to developers because it will segfault when trying to write to external memory that should be on it's host. e.g. 0x8e00aac0

I think this would be a apt use of the POSIX shared memory mechanism. It may even be possible to create a linker script to build host applications without modification on a non-Parallella system that could use the shared memory.

I compiled the Lazarus environment incl. FPC on a headless Parallella board with the image 01/30/2015. I want to access the functions of the Epiphany SDK via the dynamically loaded libraries libehal.so and libe-loader.so. So I converted the headers and implement the sample program of the third chronicle.
All the used functions of libe-hal.so are successful. But calling a function of the libe-loader.so gives a crash of the program with the following message:
symbol lookup error: /opt/adapteva/esdk/tools/host/lib/libe-loader.so: undefined symbol: e_alloc.
Obviously the second library needs the first one, but cannot or do not load the functions.
How can I resolve this conflict?
I do not have static libraries in order to write a wrapper with all exported functions in one library.

Thanks in advance
Alex

The XML parser does not allow tabs/newlines to separate attributes. Thus:

The sixth attribute of chip will be reported as \n\t core_memory_size rather than just core_memory_size.

The workaround is to keep all attributes on the same line. Not an urgent issue, since the standard XML files are not affected, and there is a trivial workaround. Filed for the record.

Building a toolchain from scratch is very slow. It would be nice to have something like the -j option in Make to run several jobs in parallel. Things like cloning repositories could easily be done in parallel, even if the compile cycles cannot.

I noticed that there is an issue in the install-sdk.sh script. It appears that the BRANCH variable is set to master, when in fact it needs to be set to 2014.08.rc. The master branch of epiphany-libs does not appear to have e-clear-shmtable directory. This caused the install stage of the esdk building to fail for me.

I would also like to note that after I made this correction, it appears that the sys-include folder in esdk.DevBuild/tools/e-gnu/epiphany-elf/ was not created causing another error from cp, I generated it on my own and the install took.

If you can make this correction, I would really appreciate it.

In function ‘e_reset_system’:
" e_write(&dev, 0, 0, E_REG_LINK_MODE_CFG, &data, sizeof(int));"
should be:
" e_write(&dev, 0, 0, E_REG_LINKCFG, &data, sizeof(int));"
in line with updated version of 'epiphany-hal-data.h'

(Issue raised in forum - ack'd by Andreas - but I think I should have raised a bug in the first place. tery)

The github repo seems to be missing a few files compared to the recommended instructions in the forum from Feb 2014 - ( link - ftp://ftp.parallella.org/esdk/old/esdk.5.13.07.10_linux_x86_64_armv7l.tgz from thread - http://forums.parallella.org/viewtopic.php?f=13&t=935 ). Are there plans to have a more direct eclipse download link?

Building the sdk on a "standard Debian Desktop installation" (Wheezy).
The cross compile packages gcc-arm-linux-gnueabihf and g++-arm-linux-gnueabihf do not appear as part of the basic Debian repositories. Instructions on how to include them for Synaptec or apt-get would be appreciated.

Perhaps the Fedora and Ubuntu instructions should also be tested and updated. The packages appear to be available in the Ubuntu 14.04 repositories - but perhaps Debian are a bit more careful?

• The debugstatus register is not understood. Presumably, what epiphany.cpu calls debug is equivalent to what the manual calls debugstatus.
• The fstatus register is not understood. Probably what epiphany.cpu calls hstatus.
• The multicast register is not understood. Probably what epiphany.cpu calls meshmulticast.
• The debugcmd and resetcore registers are not understood.
• The cmeshroute, xmeshroute, and rmeshroute registers are not understood.

Similar to issue #12
e-lib/include/e-regs.h also has a full enum list of register names, but these have not been updated/are inconsistent with the epiphany-hal-data.h version.

Should only be one version of the reg enums and names.
Is this an unnecessary/dangerous duplication?

build-toolchain.sh currently deletes the destination installation directory. this is a bad behavior as some files may be kept, like if were installing to /usr which is the location Debian/Emdebian installs cross-compilers. a better behavior is that of the typical make install and make uninstall.

please fix this, it took a long time to restore my system to proper working order after it tried to delete all of /usr.