Statistics: Posted by CocoaGeek — Wed May 31, 2017 1:59 pm
]]>
It is my understanding that you are launching your application with "e-run", and that it runs in the simulator but not on the real cores. Some seem to assume this implies that you have a problem with the "Weak Memory Model". While this may be true, my experience would add two more possible issues. Alignment errors and Trap instructions can also cause the cores to halt.
When someone suggested one of my problems was due to a misaligned memory access, I modified my version of "e-loader" on the host to check for such a condition. I never saw such a condition in my application, and could only check my detection code by purposefully generating an alignment error on the Epiphany--which was more difficult with E-GCC that it was with CC on a PDP 11-45. In any case, I have left the detection code in my foundation libraries, and have expanded upon it. An alignment error generates an interrupt which hangs in the interrupt vector. This means that detection is a bit more complex than simply trapping the interrupt vector, as the interrupt function won't be called. I use some of the core memory/register mapping code which Ola shared with me to monitor the state of the core(s). I doubt alignment is your problem.
For the past week, I have spent quite a bit of time working with NEWLIB. While doing so, I observed that NEWLIB will generate a TRAP 7 instruction under certain conditions. By design, it generates TRAP 7 to have the ARM execute a number of linux files primitives such as open/close, read/write/lseek, and fstat via TRAP 7. I am not familiar with the Objective C library, however, I wonder how it interacts with NEWLIB for stdio. Although I haven't used the simulator, it is my understanding, that the simulator catches and processes the TRAP 7 instructions and correctly interprets them. Per the documentation, and my direct experience, the TRAPs cause the Epiphany core to halt. I believe the intended design is for the ARM to read the registers, execute the function(s), and drop the data into the core before restarting it with the DEBUGCMD register.
One way to determine whether your code is hung because of a trap is to use GDB. In my case, the "infinite" loop detector of my "host monitoring of cores" code popped out the address. Consultation of the link map pointed to "asm_syscall". "asm_syscall" generates the "TRAP 7". In my case, as I had already implemented the necessary file system calls, so I wired them into "asm_syscall" and voila, fopen/fclose/open/close, fread/fwrite/fseek/read/write/lseek, and fstat work. I have a bit more work to do, however, it occurred to me that this also could explain your problem.
All of this prose is just a prefix to my real question: if I back-port some of my detection code to an eSDK version of "e-loader", would you be willing to try it? Of course, I'll test it at my end first with a test C++ application. I can provide you an .elf file or source, although providing all of my file system primitives (which run in external memory) is beyond the scope of my proposal. That would potentially generate quite a bit more work on your end.
Statistics: Posted by GreggChandler — Sat May 27, 2017 11:13 pm
]]>
]]>
I think you are right that the positioning of the Parallella is definitely more towards 'general purpose cores' than GPU style ... if only it had more memory per core
My overall project runs fine on the Parallella's main processor. I was looking for way to speed-it up a little using the Epiphany. I haven't given-up totally, but need a different approach.
Once again, thanks for all you help.
Statistics: Posted by CocoaGeek — Wed May 24, 2017 2:08 pm
]]>
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)
Statistics: Posted by GreggChandler — Thu May 18, 2017 1:44 am
]]>
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.
Statistics: Posted by CocoaGeek — Sat May 13, 2017 4:41 pm
]]>
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?
Statistics: Posted by GreggChandler — Fri May 12, 2017 10:22 pm
]]>
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.
Statistics: Posted by GreggChandler — Fri May 12, 2017 5:10 pm
]]>
]]>
]]>
]]>
]]>
]]>
]]>
]]>