How do I place the libaplc library in external memory ?

Discussion about Parallella (and Epiphany) Software Development

Moderators: amylaar, jeremybennett, simoncook

Re: How do I place the libaplc library in external memory ?

Postby Dr.BeauWebber » Wed Jun 12, 2013 6:42 pm

*.o(BUFFER_SPACE)

Thanks, I had not noticed that there was such a .o ....
Ah, this assumes there is a separate .c defining the buffer space - currently the buffer is defined in the hand edited apl output .c, as it was in the example hello_world.c I was copying.
Yes it would be far more convenient to have it in a separate file. I will give that a try.
"May I ask what are the correctly specified 3 or 4 part names for the Parallella and Epiphany, when compiling ?"

When compiling what? If you need this for the APL to C compiler, then why is this important? If you need it for the C to Epiphany compiler, you use e-gcc, so why is this important?

When building the aplc cross-compiler, one needs to input this string when one runs ./configure to build the compiling structure from ./configure.in and ./config.stub
Because I was mis-naming the Parallella vs Epiphany, my string was wrong; thus for cross-compiling on the Parallella for the Epiphany, I had :
$ ./configure CC=e-gcc --host=eIII-parallella-epiphany
and similarly incorrect strings in various places in config.sub, aplcc.in and various .c files

Because the internal changes I made to the compiler and the above files were consistent with this, and I persevered with various strings until configure and ggc accepted something, we ended up with an aplc compiler that works (we have had no problem with the .apl to .c translation). But I am not releasing it in this state.

Thus I need to know the correct (gcc/configure) strings for the architecture etc.
I.e. I was trying to pick-up the correct os with :
Code: Select all
dnl Setup the MACHOS variable that we need
case "$target_os" in
   cygwin*)     MACHOS=CYGWIN;;
   darwin*)     MACHOS="FREEBSD";;
   freebsd*)    MACHOS="FREEBSD";;
   irix*)       MACHOS=SGI;;
   linux*)      MACHOS=LINUX;;
   msdosdjgpp*) MACHOS=DJPC;;
   osf*)        MACHOS=DECALPHA;;
   solaris*)    MACHOS=SUNOS5;;
   sunos4*)     MACHOS=SUNOS4;;
   armv61*)     MACHOS=ARM61;;
dnl for Raspberry Pi Arm
   armv71*)     MACHOS=ARM71;;
dnl for Parallella Host Arm
   epiphany*)   MACHOS=EPIPHANY;;
esac

which needs correcting. Does the Epiphany have something that can be called an OS ? Does newlib function as an os ?
Code: Select all
If you need it for the C to Epiphany compiler, you use e-gcc, so why is this important?

You are right, it does not matter when I am compiling on the Armv7 for the Armv7, config.,sub will automatically generate the correct string.
User avatar
Dr.BeauWebber
 
Posts: 114
Joined: Mon Dec 17, 2012 4:01 am
Location: England

Re: How do I place the libaplc library in external memory ?

Postby ysapir » Wed Jun 12, 2013 8:07 pm

*.o(BUFFER_SPACE)

Thanks, I had not noticed that there was such a .o ....

Ah, this assumes there is a separate .c defining the buffer space - currently the buffer is defined in the hand edited apl output .c, as it was in the example hello_world.c I was copying.
Yes it would be far more convenient to have it in a separate file. I will give that a try.


Technically speaking, the input to the linker is an object (binary) file. It can be generated (compiled) from a C source, assembly source or whatever high-level compiled module. The "*.o" means "all the linker input files that end with a ".o" (which is the standard notation for object files)".

In parentheses you list all the sections from the input file(s) that you want to map to the output section. In our case, the input and output sections have the same name, but it is not necessarily so. What's important is that the section name in the source file (inside the SECTION() attribute) matches the input-section name in the LDF.


When building the aplc cross-compiler, one needs to input this string when one runs ./configure to build the compiling structure from ./configure.in and ./config.stub


So, this aplc cross-compiler takes APL programs and compiles them to C programs that will eventually be compiled to Epiphany executables? Does this cross-compiler runs on the ARM?

If the configure script is for building the cross-compiler itself, then it is either running on the ARM or the x86 (not on Epiphany, anyway - right?). The ARM architecture in the Parallella is "armv7l".
User avatar
ysapir
 
Posts: 393
Joined: Tue Dec 11, 2012 7:05 pm

Re: How do I place the libaplc library in external memory ?

Postby Dr.BeauWebber » Wed Jun 12, 2013 11:28 pm

OK, we may be near the end of this particular topic, I hope so anyway, things looking good.

1) declaring the buffer space in the .ldf file :
I have added a source file :
./src/buffer.c, :
Code: Select all
#include "e_lib.h"
char outbuf[4096] SECTION("BUFFER_SPACE");

I then split the target compiling into two lines, so as to generate a buffer.o file :
Code: Select all
 e-gcc -c   src/buffer.c
 e-gcc  -T ${ELDF} -L $LIBAPLC buffer.o src/$PROGRAM.c -o Debug/$TARGET.elf -laplc -lm  -le-lib

I then edited aplc_external.ldf to refer to the new buffer.o :
Code: Select all
        . = (__BUFFER_LOCATION_);
        BUFFER_SPACE    . : { buffer.o(.data) }  > EXTERNAL_DRAM_1
        . = ( .  + __BUFFER_SIZE_);

and modified the source program so it no longer created the buffer itself :
src/vector_sum_ed3.c
Code: Select all
extern char outbuf[4096] ;
char* pointer = outbuf ;

This now compiled and ran fine.

So, this aplc cross-compiler takes APL programs and compiles them to C programs that will eventually be compiled to Epiphany executables?

Yes, indeed.
Does this cross-compiler runs on the ARM?

Yes, that is working fine - or one can do it in Cygwin on Windows.
If the configure script is for building the cross-compiler itself, then it is either running on the ARM or the x86 (not on Epiphany, anyway - right?).

Yes, I can't see any virtue in building the compilation on the Epiphany - anyway the compilation joins a sequence of processes together with pipes, which we don't yet have.
The ARM architecture in the Parallella is "armv7l".

Thanks, exactly what I need. In part.

I will do the next step in another post.
User avatar
Dr.BeauWebber
 
Posts: 114
Joined: Mon Dec 17, 2012 4:01 am
Location: England

Re: How do I place the libaplc library in external memory ?

Postby Dr.BeauWebber » Wed Jun 12, 2013 11:53 pm

The original title of this thread is
How do I place the libaplc library in external memory ?

Well we did that by using a slightly modified legacy.ldf ; but this put the aplc program into external memory, so it would run very slowly - how do we just put the library in external memory ?

I think we are now ready to answer that; I may not yet have it quite right, but it is now working :
Starting from fast.ldf, we copy it to aplc.ldf, and first make the modifications we made for apl_external.ldf :
Code: Select all
/* Temporary std-out replacement buffer */
__BUFFER_SIZE_        = 4k;   /* for host communication */
__BUFFER_LOCATION_ =   0x8ffff000;

/* __HEAP_SIZE_FOR_CORE_ = 512K; */
__HEAP_SIZE_FOR_CORE_ = 507K;

Add the buffer space declarations :
Code: Select all
        . = (__BUFFER_LOCATION_);
        BUFFER_SPACE    . : { buffer.o(.data) }  > EXTERNAL_DRAM_1
        . = ( .  + __BUFFER_SIZE_);

Now, to get the .o files we explicitly generate them from the library .c files, see below, and refer to them by name in the aplc.ldf file to put them in external memory :
Code: Select all
        APLC_LIB_RO           . : {runio_ex.o runio_f.o runio_fmt.o runio_qq.o runio_util.o  runmem.o runop.o runshape.o runtrans.o  runfun_res.o run_ops.o  fact.o gamma.o binomial.o runtol.o  runmat.o laqrc.o f2cif.o(.text  .rodata)   } > EXTERNAL_DRAM_0
        APLC_LIB_WR           . : {*.o(.data)            } > EXTERNAL_DRAM_0


The new build file buildv11.sh has the following changes :
point to aplc.ldf, and compile the library .c files to .o :
Code: Select all
ELDF=${ESDK}/bsps/current/aplc.ldf

# These next two lines need only be executed the once, to generate the .o files
 e-gcc -c   src/buffer.c
 e-gcc -c -I inc  libC/*.c
 e-gcc  -T ${ELDF} -I inc src/$PROGRAM.c -o Debug/$TARGET.elf  *.o -lm  -le-lib

Compiling the .c library files to ,o is fairly slow (~30s) but only needs be done the once.

After removing the test sprintf lines from the c source aplc program vector_sum_ed3.c, things seem to run fine :
Code: Select all
  0: Message from eCore 0x8ca ( 3, 2): " 1 2 3 4 5 6 7 8 9
 45
"
  1: Message from eCore 0x84b ( 1, 3): " 1 2 3 4 5 6 7 8 9
 45
"

etc.
So do the above changes to the .ldf look OK, or have I got anything wrong ?
User avatar
Dr.BeauWebber
 
Posts: 114
Joined: Mon Dec 17, 2012 4:01 am
Location: England

Previous

Return to Programming Q & A

Who is online

Users browsing this forum: No registered users and 4 guests

cron