placing hot spot functions in on-chip ram

Sebastian Huber sebastian.huber at
Fri Apr 12 07:03:08 UTC 2013

Hello Jeffrey,

On 04/12/2013 12:38 AM, Hill, Jeff wrote:
> Hello Sebastian,
> Just a quick note to identify my current direction so that you will have an opportunity to provide some comments.
> Today I had a closer look at techniques for placing certain Nios2 hotspot functions in on-chip ram. I see only two options for implementing this cleanly.
> 1) Move code using its section name in the linker script
>    o Mark the C function with a section attribute. The function shouldn't contain rwdata or bss variables.
>    o Mark the assembler code with a section attribute. Such code shouldn't contain rwdata or bss variables.
> 2) Place all hot spot functions in separate object files, and manipulate the location of object files in the linker script
>    o The entire object file shouldn't contain any rwdata or bss variables.

a third option is to add a hotspot section to the linker command file for code. 
  We have this in the basic linker command files for ARM and PowerPC:

	.fast_text : {
		bsp_section_fast_text_begin = .;
		bsp_section_fast_text_end = .;
	bsp_section_fast_text_size = bsp_section_fast_text_end - 
	bsp_section_fast_text_load_begin = LOADADDR (.fast_text);
	bsp_section_fast_text_load_end = bsp_section_fast_text_load_begin + 

Now you can do two things:

1. Use a section attribute (compile time option):

#define BSP_FAST_TEXT_SECTION __attribute__((section(".bsp_fast_text")))

2. Rename the .text section of selected object files to .bsp_fast_text (link 
time option).  Attached is an example script.

In general such optimizations are highly application dependent.  In the example 
script the modules are determined by run-time traces obtained with a hardware 
tracer from Lauterbach.

I don't think we should use the attributes approach in the cpukit, because in 
this case we must ensure that every linker command file can cope with these 

> Until today I have been gravitating towards option 2. However now I have bumped into a nasty bug in the gnu ld where the linker script parsing code will find a short object file name in its input stream, but will not find a long name such as "libscorecpu_a-nios2-iic-low-level.o". Since the file name characters are chopped off somewhere in ld, maybe at about 10 characters from the right hand side of the above name, then it's difficult to work around this issue with wild cards; I end up with file name ambiguities, and too much goes in the tightly coupled code section.
> Furthermore, I see that with option 1 we have another benefit being that some rwdata or bss can be in the object file as long as it isn't in the function. Of course the BSS and RWDATA can't be in on-chip ram if we are to survive a reset without reloading everything from flash.
> Therefore, my current plan is to make a Nios2 private macro for the C source code gnu section name attribute. This implies that we can initially place only Nios2 specific codes in on-chip ram of course.
> Another option would be to just fix the gnu ld program, but finding the exact location of this bug in the source initially appears to be a time consuming task. Perhaps this is even a bug originating from Altera, I don't know.
> Open to your suggestions.
> Jeff

Did you try out the latest GNU Binutils (not the release, the CVS head)?  They 
support now Nios II and it works well for me.

Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
-------------- next part --------------
A non-text attachment was scrubbed...
Type: application/x-shellscript
Size: 867 bytes
Desc: not available
URL: <>

More information about the users mailing list