Compiling Objective-C code for the Epiphany

Discussion about Parallella (and Epiphany) Software Development

Moderators: amylaar, jeremybennett, simoncook

Re: Compiling Objective-C code for the Epiphany

Postby CocoaGeek » Fri May 12, 2017 3:16 am

Yes, e-run is the simulator and it will "run" on it, but not on the actual hardware. Here's the output of e-size:

Code: Select all
test.e32  :
section                  size         addr
ivt_reset                   4            0
workgroup_cfg              40           40
ext_mem_cfg                 8           80
loader_cfg                 16           88
.reserved_crt0             12          256
.shared_dram               16   2399141888
NEW_LIB_RO              81764   2382364672
NEW_LIB_WR               2364   2382446436
GNU_C_BUILTIN_LIB_RO    10184   2382448800
.init                      36   2382458984
.text                  134572   2382459024
.fini                      26   2382593596
.ctors                    116   2382593624
.dtors                     12   2382593740
.jcr                        4   2382593752
.data                   60240   2382593760
.rodata                 17328   2382654000
.bss                     4928   2382671328
.comment                   40            0
Total                  311710
CocoaGeek
 
Posts: 23
Joined: Thu Apr 13, 2017 3:56 am

Re: Compiling Objective-C code for the Epiphany

Postby GreggChandler » Fri May 12, 2017 4:54 am

When I built code that ran from the "fixed" legacy.ldf, I did not end up with anything in .shared_dram like you did. I imagine it to be attributed code or data. Make sure that you don't conflict with the "heap". My recollection is that legacy.ldf partitions the heap per core and puts it in 0x8fxxxxxx--just like it partitions 0x8exxxxxx for code per core. I would also reiterate that you verify malloc() actually does what you want/expect, i.e. allocate from the heap located there.

I never did find a version of elf32-epiphany.c that included asserts, or that even had 796 lines. Have you made changes to GCC, or was the assert failure in the objective C code? Did rebuilding from scratch really fix that error?
GreggChandler
 
Posts: 48
Joined: Sun Feb 12, 2017 1:56 am

Re: Compiling Objective-C code for the Epiphany

Postby olajep » Fri May 12, 2017 4:15 pm

GreggChandler wrote:If this is the case, then the next thing to do would be modify the run-time initialization code to support initialization of the external bss segment. I looked for the crt* source on my micro sever, and haven't found it yet. I am sure that the source is on GitHub, but I haven't found it there yet either. Without examining the source, this is all speculation.

Here:
https://github.com/adapteva/epiphany-ne ... any/crt0.S

But crt0 will not clear .bss because the e-hal host loader will tell it not to via loader flags.
e_load clears core SRAM but will not explicitly clear .bss so if it's placed in external memory it will not be cleared. :( . Oversight from my side. Bug in e-hal.
https://github.com/adapteva/epiphany-li ... der.c#L130

As things are now .bss must to be cleared at load time, or you'll have a race condition in programs that use more than one core.
A different alternative would be to add a workgroup barrier in crt0 just before main is called.

// Ola
_start = 266470723;
olajep
 
Posts: 92
Joined: Mon Dec 17, 2012 3:24 am
Location: Sweden

Re: Compiling Objective-C code for the Epiphany

Postby olajep » Fri May 12, 2017 4:28 pm

CocoaGeek wrote:
Code: Select all
/opt/adapteva/esdk.2016.11/tools/e-gnu.x86_64/lib/gcc/epiphany-elf/5.4.0/../../../../epiphany-elf/bin/ld: BFD (Epiphany toolchain 2016.11) 2.27 assertion fail /home/jlv/Stuff/epiphany-sdk/unisrc-2016.11/bfd/elf32-epiphany.c:796
/opt/adapteva/esdk.2016.11/tools/e-gnu.x86_64/lib/gcc/epiphany-elf/5.4.0/../../../../epiphany-elf/bin/ld: final link failed: Nonrepresentable section on output


This assert:

https://github.com/adapteva/epiphany-bi ... any.c#L796
Code: Select all
  /* We assume our chache manager is in .cacheman */
  cacheman = bfd_get_section_by_name (output_bfd, ".cacheman");
  BFD_ASSERT (cacheman != NULL);

The binutils part of software caching assumes there is a ".cacheman" section in the linker script
But you should only hit this with -fpic or -fsoftware-cache (-fsoftware-cache toggles -fpic)

Please post the exact sha of your binutils head
Code: Select all
cd [ESDKBUILDROOT]/binutils
git rev-parse HEAD


Do you have this commit in your tree?
https://github.com/adapteva/epiphany-bi ... 2420c985d8
_start = 266470723;
olajep
 
Posts: 92
Joined: Mon Dec 17, 2012 3:24 am
Location: Sweden

Re: Compiling Objective-C code for the Epiphany

Postby olajep » Fri May 12, 2017 4:31 pm

CocoaGeek wrote:Same error when my library is compiled with -fPIC than without.

Use -fpic (small caps)
_start = 266470723;
olajep
 
Posts: 92
Joined: Mon Dec 17, 2012 3:24 am
Location: Sweden

Re: Compiling Objective-C code for the Epiphany

Postby olajep » Fri May 12, 2017 4:36 pm

GreggChandler wrote:If it links but doesn't run, I would start to look at how malloc() and friends work. The specs stuff can impact this. I don't know what the "new lib" does here, as I do my own memory allocation. Obviously heap is important. I believe legacy puts the heap in external memory. Perhaps I broke that?

... also try moving NEW_LIB_RW to INTERNAL_RAM

Code: Select all
-   NEW_LIB_WR           . : {lib_a-*.o(.data)                                  } > EXTERNAL_DRAM_0
+   NEW_LIB_WR           . : {lib_a-*.o(.data)                                  } > INTERNAL_RAM
_start = 266470723;
olajep
 
Posts: 92
Joined: Mon Dec 17, 2012 3:24 am
Location: Sweden

Re: Compiling Objective-C code for the Epiphany

Postby GreggChandler » Fri May 12, 2017 5:10 pm

I actually made no explicit changes to the heap stuff, however, when I wrote a simple C program to return a malloc() and used legacy.ldf, the returned value was to nonexistent memory. Since other parts of the legacy.ldf were clearly broke, I assume this might have been broken too. I don't have the objective C compiler to try. I can only try with C/C++.

The thing to do is examine malloc() and friends to see how they find their memory pool. I successfully use NEW_LIB in external memory with the fast.ldf, although again, I don't use malloc() or new. I guess one of the questions I have not seen addressed is when "nosys.specs" should be used? A cursory google implies this is related to stuff such as memory allocation, ie. when no system calls are available.

The thing to do with legacy.ldf to avoid the race conditioned mentioned by Ola, is to erase the .bss based upon the partitioning as defined within legacy. There are also compiler flags to prevent GCC from putting data explicitly initialized to zero in the .bss, although I believe that the default is to put zeroed memory in the .bss. Although I have not crawled around inside GCC, my research indicates this to be the case, although Ola or someone else could have modified the default. Will need to try it out.
GreggChandler
 
Posts: 48
Joined: Sun Feb 12, 2017 1:56 am

Re: Compiling Objective-C code for the Epiphany

Postby GreggChandler » Fri May 12, 2017 10:22 pm

I am not sure that a workgroup barrier is the way to solve the .bss initialization problem. I am not within SSH of my parallella, however, I assume that the ldf's all define symbols that reference the .bss beginning and ending, or base and size. If not, they should or could be made to. In the e-size output above, the .elf obviously knows the size and location of the .bss. Then, crt0 or one of it's friends, could be modified to zero the .bss based upon those symbolic references. I suspect that is how other architectures accomplish this--although, perhaps the loader does the job rather than crt--in which case the loader refers to those same symbols. Either way is elegant and extensible. With this co-processor architecture, either would be defensible.

It is also important to remember that it does not appear that the legacy.ldf functions as the others do. I have not studied the others as closely, however, legacy does appear to partition the external shared memory based upon the switches I documented previously. Although this means that different .elf files are required for each core, it does provide for flexibility. Alternatively, one could generate position independent code with position independent offsets from the text base addresses, and have a single .elf loadable at each of the partitioned load addresses. This is not as flexible as the current architecture, and hard codes some of the load assumptions in the loader--which is probably not a good idea/architecture. I haven't really found any documentation for legacy.ldf, so perhaps I have totally misunderstood. However, it appears to have been well thought out based upon my understanding.

I have also assumed, perhaps incorrectly, that CocoaGeek is first trying to make his application work in external memory before trying to use the cache manager. Solve one problem at a time: compiler, linker, loader, execution. It really won't be 1000x slower in external memory, only probably about 150x or less based upon my measurements. Once it is up and limping, it would make sense to optimize.

The assertion referenced above by Ola is not the file I previously found on GitHub. Are there multiple versions of elf32-epiphany.c floating around on GitHub?
GreggChandler
 
Posts: 48
Joined: Sun Feb 12, 2017 1:56 am

Re: Compiling Objective-C code for the Epiphany

Postby CocoaGeek » Sat May 13, 2017 4:41 pm

Thanks again @greggchandler and @olajep for the renewed help, but I'm out of my depth here, and I also just don't have the time to go down this rabbit hole :(

Originally, since the Epiphany cores are more like general purpose processors I thought I could reuse some of my code, so to have a shared dev environment between the host CPU and the cores, but I know realize that I should treat the Epiphany more like 16 microprocessors and as such stick to raw C and keep things simple and memory efficient. :oops:
CocoaGeek
 
Posts: 23
Joined: Thu Apr 13, 2017 3:56 am

Re: Compiling Objective-C code for the Epiphany

Postby GreggChandler » Thu May 18, 2017 1:44 am

@CocoaGeek, I am sorry to have contributed to your waste of time. We did make some progress, however, I "suspect/guess" that you may be running into problems with the weak memory model implemented by the Epiphany. If you hadn't yet, you probably would have eventually--unless your code was specifically designed to accommodate the weak model.

I don't have any experience with the simulator, but my question would have been whether or not the simulator emulates the weak memory model--and I don't know the answer to that. I have also run into bugs with the elink, but those don't seem to characterize your problem. I don't know if/how the simulator emulates the elink. The data sheet lists some of the chip bugs, but I don't know if the data sheet is up to date. The bugs are probably listed somewhere on GitHub. I have been able to get my code running without the simulator.

I suspect that you are correct, and that Adapteva is repositioning this architecture more as a GPU rather than general cores--although that is how it was presented to me initially--general purpose cores--and the documentation doesn't discourage this view. I believe the main difference is in software. In my case, I built foundation classes so that I can run normal C/C++ code on the Epiphany, and treat the ARM cores as heterogeneous components of the system. I abstracted away most of the eSDK. Obviously, the eSDK doesn't ship with that kind of support. I implemented my own allocation of external memory, and don't use the heap at all, ie. malloc(), free(), new() and delete()--which is a bit limiting, but it works for me--having written bare metal code before. (Perhaps I should provide malloc()/free()/... via my library?) My Epiphany code ends up with the ARM args, etc., I have a printf, ... So, my apps are very Unix'y. That is much broader support than what some in this forum consider a "programming model". My ARM and Epiphany cores co-operate.

To my surprise, the crt code does exactly what I suggested it should, which should not cause "race conditions"--and certainly not so with an application such as the one you described. It does appear to understand where/what the bss is. That is good news. Unfortunately, moving the NEW_LIB into core memory would not resolve such issues as .bss data would likely be generated by your Objective C code as well. Sigh ...

I wish you the best in your future endeavors, and again, I am sorry we couldn't get your application up and running. Does your code run on a Raspberry Pi? (grin)
GreggChandler
 
Posts: 48
Joined: Sun Feb 12, 2017 1:56 am

PreviousNext

Return to Programming Q & A

Who is online

Users browsing this forum: No registered users and 1 guest