[Oberon] Oberon Linker and the memory mapping
skulski at pas.rochester.edu
skulski at pas.rochester.edu
Thu Aug 27 07:50:48 CEST 2015
Chris:
thank you for the pointers to the Astrobe forum. So you have a linker.
The example MODULE ExtraRAM does not show the linker directives. I
wonder what the linker commands look like.
The example MODULE ExtraRAM does not show how the *code* can be placed in
different kinds of memory. Code allocation is less critical with the MCU.
You can propose a "one fits all" allocation strategy because the MCU
memory layout is given in the data sheet. It will not change from
application to application.
However, FPGA is a different beast. The memory layout is not fixed at all.
One cannot mandate ahead of time how the BRAM will be used, because BRAM
is a very precious resource in the FPGA. Sometimes you need it for a FIR,
sometimes you use it for a FIFO, or for a circular buffer (our case). You
cannot take any part of BRAM for granted. The only acceptable option is to
let the FPGA designer configure the memory.
It means that the loader needs to support allocating code to memory
addresses. Does you loader provide for this? Do you have examples?
Regards,
Wojtek
> However, we do have a simple solution used in Astrobe
> that could be used for this sort of thing - assuming you
> don't want too many different levels of control.
> Read my posts with associated example source code on the Astrobe
> forum. This solution requires no change to the Oberon language:
>
> "Using the additional 16 / 32kB of RAM on LPC175x/6x MCUs":
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.astrobe.com_forum_viewtopic.php-3Ff-3D7-26t-3D267&d=BQICAg&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=unvJkEDVBSTlQsbEJHtTJB82MMruaviuED8GT6TBStg&s=eyNW-qM7NL2v-QaGQYntgkNF4T2vQDHHstyX5ObcsMI&e=
>
> and the similar:
>
> "Using the additional 2kB of RAM on LPC131x / LPC134x MCUs"
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.astrobe.com_forum_viewtopic.php-3Ff-3D7-26t-3D408&d=BQICAg&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=unvJkEDVBSTlQsbEJHtTJB82MMruaviuED8GT6TBStg&s=fHikU8NQeCNpTRtNK5OYvCuHooH4uLq3CyVG6Bksuj4&e=
>
> If you wanted more levels of control, we have implemented NEW
> in a similar way to how it is done in Modula-2. i.e.
> calls to NEW are transformed to calls to an underlying 'Storage'
> module which handles the dynamic memory storage allocation scheme.
> You can customise the source code of that to your
> heart's content e.g. allocate records of a particular size
> to one area of memory, allocate larger records to
> another area etc. You are free to make it as complicated
> as you wish.
>
> Regards,
> Chris
More information about the Oberon
mailing list