Re: [LM-32] Code generation for address loading

2014-02-26 Thread FX MOREL
On Tue, Feb 25, 2014 at 1:08 AM, Anthony Green gr...@moxielogic.com wrote:


 Have you considered doing this through custom GNU linker relaxation
 work?  I would try this before hacking away at the compiler.

 AG



This a very good idea indeed, I wasn't aware of this feature.
I will give it a try based on other relaxations done for other platforms...
Thank you for your input and I will let you know if I have any success

FX


Re: [LM-32] Code generation for address loading

2014-02-24 Thread Anthony Green
FX MOREL fxmorel@gmail.com writes:

 Hi everyone,

 I am developing on a custom design using the LatticeMico32
 architecture and I use gcc 4.5.1 to compile C code for this arch.

 In this architecture, the loading of an address 0x always
 takes two assembly instructions to fetch the address because
 immediates are on 16 bits :
 mvhi r1, 0x
 ori r1, r1, 0x
 ...
 lw r2, r1

 In my situation, nearly all the symbols are located in the same 64kB
 region and their address share the same hi-part, so I am trying to
 minimize the overload of always using two instructions when only one
 is needed.


[additional details deleted]

 Because the symbol mapping phase is done during linking, I have little
 chance to know the future symbol address at code generation but is
 there some way I could make this work ?
 If I affect the symbol to a dedicated section (with the __attribute__
 ((section())) directive ), is there a way to know its section during
 code generation ?

 I understand that I am asking for a very 'dangerous' advice but again,
 this will only be a custom optimization for a custom design.

Have you considered doing this through custom GNU linker relaxation
work?  I would try this before hacking away at the compiler.

AG



 Thank you.

 F-X Morel


[LM-32] Code generation for address loading

2014-02-18 Thread FX MOREL
Hi everyone,

I am developing on a custom design using the LatticeMico32
architecture and I use gcc 4.5.1 to compile C code for this arch.

In this architecture, the loading of an address 0x always
takes two assembly instructions to fetch the address because
immediates are on 16 bits :
mvhi r1, 0x
ori r1, r1, 0x
...
lw r2, r1

In my situation, nearly all the symbols are located in the same 64kB
region and their address share the same hi-part, so I am trying to
minimize the overload of always using two instructions when only one
is needed.

In the C code, regrouping variables in structure will generate code
where memory is accessed through an offset of the base address of the
structure which is only loaded once per function, hence a gain in code
size.
But the extent of this technique is still limited by C code
readability constraints and there is still at least one penalty in
each function to load the first address.

I was imagining something with a fixed register (say r23, declared as
-ffixed in compilation flags) that would be loaded with the addresses'
hi-part at reset (in the same ways that r0 is set to 0) and then each
address loading phase would only consist in one instruction :

  ori r1, r23, 0x

I have tried to play around with machine description file of the lm32
architecture to achieve my goal but I need some kind of constraints or
condition to check where is my symbol before using this shortened
version of address loading (Even if nearly all of the symbols are
located within the same 64kB, some are still located in other memory
regions and I don't want to touch them !)

Because the symbol mapping phase is done during linking, I have little
chance to know the future symbol address at code generation but is
there some way I could make this work ?
If I affect the symbol to a dedicated section (with the __attribute__
((section())) directive ), is there a way to know its section during
code generation ?

I understand that I am asking for a very 'dangerous' advice but again,
this will only be a custom optimization for a custom design.

Thank you.

F-X Morel