Disabling GP-addressing in generated source code

[Altera_Forum]

Hi Everybody, 

 I would like to share some thougts about the way to control when the compiler uses GP-addressing to address global data structures.  This is resulted also from a talk with Monkeyboy, that I thanks for having enlightened me :-)  Baically, my knownledge is the following:  - small data that is generated into the .sdata / .sbss section will use GP-addressing  - I can disable GP addressing for the entire compilation unit using the compiler option -G0  - if I want to remove GP addressing from a small data, I have to DECLARE the data putting it in some different section, like for exeample the ".data" section, something like  <div class='quotetop'>QUOTE </div>  --- Quote Start ---  extern volatile int mickey __attribute__ ((section (".data")));[/b]  --- Quote End ---    What I do not like in this method is that I have to put into the declaration (that stays for example inside a .h) the fact that the item will be allocated inside the ".data" section. I do not like it because the resulting object file will not contain any allocation in the data segment for that variable...     I also tried the following piece of code:  <div class='quotetop'>QUOTE </div>  --- Quote Start ---  extern volatile int mydata __attribute__ ((section (".data")));  void goofy(void)  {   mydata++;  }    volatile int mydata __attribute__ ((section (".sdata")));  void mickey(void)  {   mydata++;  } [/b]  --- Quote End ---    ...that is,   1) declaring a variable mydata putting it in .data (no GP-relative addressing 2) using mydata into goofy (generating absolute code (the same ontained with -G0)) 3) REDEFINING mydata to be put in .sdata (the compiler should give a warning because of the section that has changed?????) 4) using mydata into mickey (generating GP-relative code)  As the result, I obtain the following assembler (I only quoted the most interesting parts)  <div class='quotetop'>QUOTE </div>  --- Quote Start ---  .section .text  .align 2    .global goofy  .type goofy, @function goofy:  addi sp, sp, -4  stw fp, 0(sp)  mov fp, sp  movhi r3, %hiadj(mydata)  addi r3, r3, %lo(mydata)  movhi r2, %hiadj(mydata)  addi r2, r2, %lo(mydata)  ldw r2, 0(r2)  addi r2, r2, 1  stw r2, 0(r3)  ldw fp, 0(sp)  addi sp, sp, 4  ret   .size goofy, .-goofy  .align 2    .global mickey  .type mickey, @function mickey:  addi sp, sp, -4  stw fp, 0(sp)  mov fp, sp  ldw r2, %gprel(mydata)(gp)  addi r2, r2, 1  stw r2, %gprel(mydata)(gp)  ldw fp, 0(sp)  addi sp, sp, 4  ret   .size mickey, .-mickey    .global mydata  .section .sdata,"aws",@progbits  .align 2  .type mydata, @object  .size mydata, 4 mydata:  .zero 4  .section .debug_frame,"",@progbits[/b]  --- Quote End ---    That is,  - goofy IS NOT using GP-relative addressing - mickey IS using GP-relative addressing - the compiler does not complain about the mismatch of the sections!   What I would like to have is: - the possibility to DEFINE a data structure putting it in some section (as it is now) - the possibility to DECLARE a data structure without saying in which section it will be allocated, but just saying "hey, I want to disable GP-addressing"  Questions:  1- is it possible to DECLARE a data structure without saying in which section it will be allocated, but just saying "hey, I want to disable GP-addressing"?  2- Why the compiler do not give a warning about the conflicting sections?  3- it seems that generating GP-relative code is related ONLY to the section where the compiler HOPES the variable will be allocated to. So in some sense having __attribute__ ((section (".data"))) after a data declaration is a sufficent answer to question 1?   ok, that&#39;s all for now,  Paolo

[Altera_Forum]

Paolo, 

 The -G0 option should be sufficient. With the -G0 option, the compiler will not place any data in the .sdata/.sbss sections and will not generate gp-relative data access.  Do yourself a favor and avoid using section attributes -- unless you have no choice -- you&#39;ll save yourself some future headaches ;-)  Regards, --Scott

[Altera_Forum]

Hi Smcnutt, 

 I&#39;m using the -G0 since a while, and it works fine. However, the code generated is slower than what it could really be... It&#39;s just a matter of obtaining optimized code by the compiler :-)  bye  PJ

[Altera_Forum]

I would need to run a few experiment to be certain, however I believe that the decleration: 

 extern volatile int mickey __attribute__ ((section (".data")));  really is the decleration that you are looking for, i.e. it says: "access mickey as if it were in the .data section", which for Nios II just means "don&#39;t use gp addressing". If mickey was actually linked to be in the .sdata the code would still work it just wouldn&#39;t use the gp (as desired).  Obviously this isn&#39;t exactly self documenting code, but I believe it does what you&#39;re asking for.

[Altera_Forum]

--- Quote Start ---  originally posted by monkeyboy@May 20 2005, 05:17 AM really is the decleration that you are looking for, i.e. it says: "access mickey as if it were in the .data section", which for nios ii just means "don&#39;t use gp addressing". if mickey was actually linked to be in the .sdata the code would still work it just wouldn&#39;t use the gp (as desired).  obviously this isn&#39;t exactly self documenting code, but i believe it does what you&#39;re asking for.  --- Quote End ---   Hi Monkeyboy,  I think that is the way to go too.  about the self documentation of the code, I can still put a# define to mask that dummy section attribute...  Thanks a lot,  PJ

[Altera_Forum]

Hi, 

 A problem I had with the GP is that I want to put some variables fixed into an OnChip memory block. So if the gap between the main memory and the on chip memory is too big, the variable can not be accesses with the gp and a linker error occurs.  Can the compiler itself be adjusted to detect for himself if it is possible to use the gp and otherwise use the slower method of accessing?   Stefaan

[Altera_Forum]

I don&#39;t think so... currently the only thing you can do is to disable GP-addressing for -that- particular variable... 

 In general if you put some data in some address different from .sdata it is highly probable that the GP addressing will not work...  PJ

[Altera_Forum]

The compiler assumes that all data in the sdata and sbss sections can be reached using the GP register. The compiler otherwise treats these sections the same as the data and bss sections. 

 So if you declare global variables as being in a different section (different memory) the compiler won&#39;t use GP relative addressing which will be safe but potentially slower.  Are you using your own linker script? If so then you need to ensure that the _gp linker variable (which sets up the value of gp) is within range of the .sbss and .sdata sections.  ps. It would be possible to perform the gprel optimisations at link time but this would be a lot more work so isn&#39;t near the top of the list yet.

[Altera_Forum]

Hi wombat, 

 I&#39;m basically using Altera Generated linker script, with little modifications that do not influence this problem.  I&#39;m now quite happy with the solution where the user should explicitly disable GP addressing inside the include files when declaring a data structure that goes far away from the GP. In general these GP-disabling kind of pragma will be added only when the compiler fails, (and of course when data have to be shared among different processors).  bye  PJ