Module Storage (1)

Report any suspected bugs that you find
Locked
gray
Posts: 113
Joined: Tue Feb 12, 2019 2:59 am
Location: Mauritius

Module Storage (1)

Post by gray » Sun Dec 03, 2023 4:19 am

I need to write my own heap memory allocator, and I am studying module Storage, which of course is a good starting point.

I have trouble understanding this part in the module initialisation:

Code: Select all

  IF heapLimit = 0 THEN
    stackLimit := 0
  ELSE
  (* Separate heap / stack *)
    stackLimit := 010000200H
  END;
As far as I understand, 'Heap Limit' (LinkOptions.HeapLimit) in the configuration defines how the memory is shared between the stack and the heap. The stack grows downwards from the its top below the module variables (LinkOptions.StackStart), and the heap grows upwards from the value of 'Heap Start' (LinkOptions.HeapStart).

If the value of 'Heap Limit is set to zero, there's dynamic sharing, else the heap is limited to the value set. With dynamic sharing, the heap can grow up to the current stack pointer at the time of the allocation. The stack can grow down without limitations, even into the heap space. (Without hardware support, it would be performance consuming to keep the stack pointer "in check" upon each procedure call.)

I would have expected that 'stackLimit' be set to 'heapLimit' if 'Heap Limit' is not zero. The constant '010000200H' is not an address within the 32 kB RAM range of my MO STM32F091 (the data range of the STM32F091 is 020000000H to 020008000H).

I am aware that the allocator does not use 'stackLimit', but 'Storage.StackAvailable' will return a wrong value with a non-zero 'Heap Limit' value, given the above assigment of the constant.

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

Re: Module Storage (1)

Post by cfbsoftware » Mon Dec 04, 2023 1:15 am

The code that you referenced is now obsolete and can be removed. It was documented as follows in an example called ExtraRAM:
Illustrates the use of the additional 2kB blocks of SRAM1 and USB RAM present
on LPC134x MCUs with a total of 10kB or more of SRAM

Run the program twice - once using the default settings and once with
the alternative SRAM settings for your MCU and compare the Stack Usage / Heap
Usage for each:

1. Default settings: (Shares the CPU RAM between the stack and the heap)
Heap Start = 010000200H,
Heap Limit = 0H

2. LPC1317/47 (Uses extra 2kB of SRAM1 for the heap)
Heap Start = 020000000H
Heap Limit = 020000800H

3. LPC1345/46/47 (Uses extra 2kB of USB SRAM for the heap)
Heap Start = 020004000H
Heap Limit = 020004800H

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

Re: Module Storage (1)

Post by gray » Mon Dec 04, 2023 9:03 am

I suggest to replace the above quoted code with

Code: Select all

stackLimit := heapLimit;
Or remove it and amend 'Storage.StackAvailable()' accordingly, also removing VAR 'stackLimit' from the module.

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

Re: Module Storage (1)

Post by cfbsoftware » Fri Dec 15, 2023 10:26 pm

We are planning on removing the hard-coded value and replacing it as follows:

Code: Select all

IF heapLimit = 0 THEN 
  stackLimit := heapLimit
ELSE 
  stackLimit := LinkOptions.DataStart + 0200H
END;
This allows the Stack to use all of the remaining contiguous RAM after the Global Data and Interrupt Vectors (including some additional reserved space) have been allocated. The Heap can then be located in an entirely separate area of non-contiguous area of RAM if available on the device.

Naturally, the programmer can modify the source code of the Storage module themselves if this doesn't suit their particular requirements.

Locked