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

[Christo Crause]

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/20201004/ae2cf250/attachment.htm>