Compiling Objective-C code for the Epiphany

[CocoaGeek]

[jar]

In C code, you mark the routines with the attribute section. I don't speak Objective-C so I'm not sure.

But if you are executing out of DRAM, performance will tank. DRAM routines are best suited for large, one-time initialization calls because it is about 1000x slower. Executing out of another core's SRAM would be preferable if you just don't have the space.

[CocoaGeek]

Thanks for the input jar. You are right, I should drop done to bare C to conserve performances. I wish each of the Epiphany had more memory

[GreggChandler]

[GreggChandler]

The attached file is my modification of "fast.ldf". It predates any changes Ola may have made for you. In my case, my C++ libraries have been archived with "e-ar". Search for "ESX_LIB_RO" in "fastesx.ldf". You can probably remove the "EXCLUDE_FILE" part of the script. "esxecore.a" is the name of my library. The command specifies that both .text and .rodata for object files from the esxecore.a library should be loaded with EXTERNAL_DRAM_0 with the exception of the specified exception files. I based my changes on the NEW_LIB_RO and NEW_LIB_WR specification one sees below it. Note, you may want to rename the .txt to .ldf. The web site would not allow me to upload as .ldf. I don't know if the ESX_LIB_WR specification works.

fastesx.txt

Modified fast.ldf script

(16.31 KiB) Downloaded 1446 times

[CocoaGeek]

[CocoaGeek]

[GreggChandler]

My guess, and it is only a guess, is that the .bss segment is causing your problem. You can examine your link map, and determine which code, data, and uninitialized variables are being loaded in the various parts of the address space. If the change was correctly made, and it appears to have been in the file you supplied, then the code should have been correctly moved to the external segment. The data should have been moved as well. That is the first step. The next step is to determine which segment(s) is/are causing your overflow. I don't know if objective C generates CTOR's, DTOR's, etc. (Adding " .bss" after the ".data" specification for your LLK_LIB_WR specification would help determine if .bss is the problem.)

Although I have written objective C code, it has been a while, and I never examined the generated object code too closely. (It was for the iPad/iPhone, and the Apple ecosystem kept me too far from the actual code.) I remember strings with object stuff in them. Loading them in external memory would be important. Hopefully they are part of .rodata.

I tried moving my .bss segment to external memory, and my C++ program wouldn't run. I believe that is because C++ may have assumed that the uninitialized data segment was actually initialized to zero. (What is the irony of that? In the old days, it really was uninitialized!) I assume objective C would be similar.

Examining the link map, one can see where objects and symbols are defined to bracket the segment--presumably so that it can be initialized. (Look for __bss_start.) 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.

e-size -A myfile.elf will produce a good summary of program components, their load addresses, and their sizes. It would be interesting to see what it reports.

Another option would be to move all .bss data to the external segment, however, I suspect that would be too slow. I suspect splitting the .bss is your best bet. I'll keep looking for the CRT* source code.

Yet another option is that your main program, as distinct from your library, is generating the overflow. The tools should reveal the real cause.

Interesting commentary on this topic, and something else to try.

[GreggChandler]

Did you try making your changes to the "legacy.ldf" linker script?

[GreggChandler]

The attached version of legacyesx.ldf (.txt) successfully links a SINGLE CORE application that runs out of external memory--code, text, bss, .... The original legacy.ldf partitions external memory per core. My modified one does not. I do not know how the new lib handles memory allocation, et. al., in such a case, however, my simple hello program does run. It does not contain your library modifications.

legacyesx.txt

(16.39 KiB) Downloaded 1440 times