[fpc-devel] Proposal for implementing named address space support

Florian Klämpfl florian at freepascal.org
Fri Jan 1 14:59:41 CET 2021


Am 31.12.20 um 21:35 schrieb Christo Crause via fpc-devel:
> On Thu, Dec 31, 2020 at 9:42 PM Jonas Maebe via fpc-devel 
> <fpc-devel at lists.freepascal.org <mailto:fpc-devel at lists.freepascal.org>> 
> wrote:
> 
>     On 31/12/2020 20:32, Christo Crause via fpc-devel wrote:
> 
>      > For example I do not know how to generate the equivalent to the
>      > following user assembler code:
>      >   lds r0, EECR
>      > where EECR is defined as follows in a different unit:
>      > var EECR: byte absolute $1F;
>      >
>      > The following line illustrates what I'm attempting to do:
>      >   list.concat(taicpu.op_reg_ref(A_LDS,tmpreg,tmpref));
>      > where tempref should reference the EECR symbol in another unit.
>      >
>      > How do I build such a reference in the code generator so that the
>      > reference can resolve to the appropriate address?
> 
>     While possible, the code generator is the wrong abstraction level for
>     this. Can't you generate a load node for that variable instead? What
>     triggers this code generation?
> 
> Jonas,
> 
> Thank you for your help.  I'm trying to implement compiler support for 
> different address spaces (flash and eeprom memory at the moment), mostly 
> relevant to embedded and freertos type targets.  My current approach is 
> to check for specific section names of references in the code generator 
> and then generate the appropriate access code in tavr.g_concatcopy 
> tavr.a_load_ref_reg and so forth.  Example code I want to support:
> 
> program store_restarts;
> var
>    numrestarts: byte; section '.eeprom';
> begin
>    numrestarts := 42;
> end;
> 
> Reading from section .progmem closely follows the semantics of accessing 
> general RAM so it was relatively easy to extend the existing code 
> generator for that.  EEPROM access requires more code (not a problem) 
> but also controller specific register addresses (here is my problem,  
> the information sits in a different unit).  I haven't thought of 
> modifying or creating a the load node since I'm much more familiar with 
> the code generator side of the compiler (but still no expert...).
> 
> Any further hints or examples in the compiler I can study to tackle this 
> via a load node would be appreciated.

- you need to get the value of EECR: I would try with 
symtable.searchsym_in_module
- for ideas how a load node could generate code for a variable access as 
above, I would take the various generate_threadvar_access methods as 
example.

Is your current code somewhere available?


More information about the fpc-devel mailing list