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