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 » Wed May 24, 2017 2:08 pm

@GreggChandler, you don't have to be sorry! You were very helpful and brought me much further along than I would have gone otherwise.

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.
CocoaGeek
 
Posts: 29
Joined: Thu Apr 13, 2017 3:56 am

Re: Compiling Objective-C code for the Epiphany

Postby GreggChandler » Fri May 26, 2017 5:04 am

You're welcome.
GreggChandler
 
Posts: 66
Joined: Sun Feb 12, 2017 1:56 am

Re: Compiling Objective-C code for the Epiphany

Postby GreggChandler » Sat May 27, 2017 11:13 pm

@CocoaGeek, it is probably best to let sleeping dogs lie, however, my recent parallella programming has surfaced a new, (at least new to me,) way for Epiphany applications to hang. Interestingly, it could explain your experience that the simulator worked, but the cores don't. Let me explain.

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.
GreggChandler
 
Posts: 66
Joined: Sun Feb 12, 2017 1:56 am

Re: Compiling Objective-C code for the Epiphany

Postby CocoaGeek » Wed May 31, 2017 1:59 pm

Sure thing @GreggChandler, I'll give that a try :)
CocoaGeek
 
Posts: 29
Joined: Thu Apr 13, 2017 3:56 am

Previous

Return to Programming Q & A

Who is online

Users browsing this forum: No registered users and 10 guests

cron