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

[Christo Crause]

I'm busy adding EEPROM access to the code generator for AVR.  Although the
general code required is relatively straight forward, the problem I ran
into is that the EEPROM access registers are not at the same addresses for
the different controllers.  The register names and addresses are included
in the respective controller units, so the addresses are available in the
automatically loaded controller unit at compile time.

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?

Regards,
Christo

On Sun, Oct 4, 2020 at 1:49 PM Christo Crause <christo.crause at gmail.com>
wrote:

> The AVR architecture uses different address spaces with potentially
> different access methods [1].  Currently constant data (messages, bitmaps
> etc.) are stored in flash and copied to RAM by the start-up code.  Data
> access makes use of the LD* instructions (and ST* if the data is
> writeable).  Accessing e.g. read-only data directly from flash saves RAM
> space - this can be done byt informing the linker to locate the data in the
> progmem section.  While one can use the section modifier to inform the
> linker to place data in specific address spaces it still require user
> supplied access code.  This leads to code and maintenance duplication for
> the user to cater for different memory spaces, with associated code bloat.
>
> The xtensa architecture has several address reagions that can be used for
> different purposes [2]. One example would be to place time critical
> interrupt code in the IRAM address space.  The DRAM space can also be used
> to store constant data which can be accessed from an interrupt routine.
> Several other address spaces are available for specific use cases [3].
>
> FPC can use the section modifier to specify which address space should be
> used for data.  It is however very limited in that the code generator is
> not aware of the potentially different address spaces that can be
> specified, hence it is up to the user to provide the correct access code
> (for AVR).  The section modifier also takes a user supplied string, which
> currently isn't checked for sensible or allowed values.  I want to propose
> a unified mechanism for specifying both data and instruction address spaces
> using the same syntax for functions/procedures and variables, together with
> implementing the necessary access functionality as required (mainly AVR)
> for the compiler to generate the appropriate code without further user
> involvement.
>
> The first proposal is to extend the section modifier to accept predefined
> (target specific) keywords (flash, eeprom, iram, dram, rtc_noinit and
> others), e.g.:
> // AVR const data in flash
> const
>   smileyGlyph: array[0..6] of byte = (19, 35, 64, 92, 64, 35, 19); section
> flash;  // keep data in flash, read using spm (or LD* for newer AVRs)
>
> // AVR Read/write access to data stored in EEPROM
> var
>   restartCount: byte; section eeprom; // If one needs a fixed location,
> perhaps use in combination with absolute?
>
> // Xtensa interrupt handler user code
> procedure encoderPulse; section iram;
>
> // Xtensa code that executes after wakeup from deep sleep
> procedure afterDeepSleep; section rtc_iram;
>
> // Xtensa variable that retains value after deep sleep:
> var
>   oldState: uint32; section rtc_slow_data;
>
> The alternative is to skip the section modifier and simply use the various
> keywords (flash, iram etc.) as modifiers.  Not sure if there is any
> advantage of this compared to the first proposal.
>
> Critique, improvements and other use cases to consider would be
> appreciated.
>
> [1]
> https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html#AVR-Named-Address-Spaces
> [2]
> https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/general-notes.html#memory-layout
> [3]
> https://github.com/espressif/esp-idf/blob/7b7c641076ef4c5dff7b994170d445bbb46f81ab/components/xtensa/include/esp_attr.h#L21
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20201231/0c468ca8/attachment.htm>