Copying a Procedure to RAM

General discussions about working with the Astrobe IDE and programming ARM Cortex-M0, M3, M4 and M7 microcontrollers.
Post Reply
gray
Posts: 143
Joined: Tue Feb 12, 2019 2:59 am
Location: Mauritius

Copying a Procedure to RAM

Post by gray » Sun Mar 31, 2024 11:04 am

What is the best way to copy a procedure, eg. from Flash memory to RAM?

For example:

Code: Select all

MODULE M;
  PROCEDURE p0;
  END p0;
  
  PROCEDURE p1;
  END P1;
END M.
Getting the procedure's starting address is straight forward, but how to detect its ending address? Scanning for 'pop' is not safe, as any relevant constants in code memory at the end of the procedure can be missed.

Here's my current approach, which relies on the existence of 'p1', which works for my current use case (I have verified that 'p1' follows 'p0' in code memory):

Code: Select all

  IMPORT SYSTEM;
  CONST RamAddr = 020040000H;
  TYPE P = PROCEDURE;
  VAR p0ram: P;
  
  PROCEDURE copyProc;
    VAR addrBegin, addrNext, p0RamAddr : INTEGER;
  BEGIN
    addrBegin := SYSTEM.ADR(p0); addrNext := SYSTEM.ADR(p1);
    p0RamAddr := RamAddr;
    SYSTEM.COPY(addrBegin, RamAddr, (addrNext - addrBegin) DIV 4);
    p0ram := SYSTEM.VAL(P, p0RamAddr)
  END copyProc;
Is there a better way? Scanning for 'push{... lr}'?

cfbsoftware
Site Admin
Posts: 525
Joined: Fri Dec 31, 2010 12:30 pm
Contact:

Re: Copying a Procedure to RAM

Post by cfbsoftware » Mon Apr 01, 2024 9:53 pm

I can't think of a general way to copy the executable code of a procedure to RAM that would be both useful and reliable in the current implementation of Astrobe for Cortex-M.

Note that Astrobe for RISC5 supports the dynamic loading of modules (but not isolated procedures) into RAM.

What is the actual problem that you are trying to solve?

gray
Posts: 143
Joined: Tue Feb 12, 2019 2:59 am
Location: Mauritius

Re: Copying a Procedure to RAM

Post by gray » Thu Apr 04, 2024 9:43 am

This is for the RP2040. I am aware that Astrobe for Cortex-M0 does not yet officially support this MCU.

Background, concepts, solution approach, as well as measurements and results related to my use case are described here: https://oberon-rtk.org/examples/codeloading/

In a nutshell, interrupt handlers can profit of running from SRAM, since loading code from Flash memory is rather slow. The code will get cached in on-chip SRAM during the first loading, but if already the first execution performance counts, or if the interrupt handling code might have been evicted from the cache, it should be installed, and executed from, SRAM. The test program demonstrates that.

Thoughts and feedback welcome.

Post Reply