Compiling Objective-C code for the Epiphany

[CocoaGeek]

[GreggChandler]

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?

[olajep]

[olajep]

[olajep]

[olajep]

[GreggChandler]

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]

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?

[CocoaGeek]

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.

[GreggChandler]

@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)