[fpc-devel] Proposal for implementing named address space support
Sven Barth
pascaldragon at googlemail.com
Tue Jan 19 07:51:59 CET 2021
Christo Crause via fpc-devel <fpc-devel at lists.freepascal.org> schrieb am
Di., 19. Jan. 2021, 05:37:
>
>
> On Sun, Jan 17, 2021 at 3:51 PM Florian Klämpfl via fpc-devel <
> fpc-devel at lists.freepascal.org> wrote:
>
>> Am 08.01.21 um 22:00 schrieb Christo Crause via fpc-devel:
>> > On Sun, Oct 4, 2020 at 1:49 PM Christo Crause <christo.crause at gmail.com
>> > <mailto:christo.crause at gmail.com>> wrote:
>> > var
>> > w: word = $BEEF; section '.eeprom';
>> > b: byte;
>> >
>> > procedure doSomething(constref tmp: word);
>> > begin
>> > b := hi(tmp);
>> > end;
>> >
>> > begin
>> > doSomething(w);
>> > end.
>> >
>> > At the moment there doesn't appear to be a way to do this without
>> > changing or adding something to the compiler. One idea could be to
>> > define new types identifying types in a specific address space, such as
>> > Teepromword. In this case the above example could be written as:
>> > var
>> > w: Teepromword = $BEEF;
>> > b: byte;
>> >
>> > procedure doSomething(constref tmp: word); overload;
>> > begin
>> > b := hi(tmp);
>> > end;
>> >
>> > procedure doSomething(constref tmp: Teepromword); overload;
>> > begin
>> > b := hi(tmp);
>> > end;
>> >
>> > begin
>> > doSomething(w);
>> > end.
>> >
>> > This way the compiler knows how to generate appropriate access based on
>> > the parameter type. It however leads to lots of code duplication.
>> Which
>> > got me thinking about generics - could this be handled internally in
>> the
>> > compiler via generics? It isn't clear to me how to tackle these issues
>> > so any advice would be appreciated.
>>
>> I would simply not allow to use such references as independent pointers.
>> This causes too much bloat. They can be used in assignments and
>> expressions and that's it.
>>
>
> I have given up on that idea. I'm now busy working on Jonas's suggestion
> of section specific pointers (example:
> https://github.com/ccrause/freepascal/wiki/Better-support-for-address-spaces-in-FPC#section-pointer-example
> ).
>
> At the moment it introduces no runtime overhead (other than the required
> access instructions of course),
> but to make it work across units is problematic. I suspect an extra field
> is required to store the section information associated with a pointer type
> (at least the way I've implemented it) in a ppu. If unit A defining such a
> pointer and a procedure using it is as parameter is called from unit B, it
> works if both units are compiled together. If unit A is already compiled
> and unit B is recompiled (symbols loaded from ppu) it doesn't carry the
> section information across and the compiler cannot determine which
> overloaded procedure to call.
>
It isn't that hard. You essentially need to make sure that the necessary
information is written in tpointerdef.ppuwrite and read again in
tpointerdef.ppuload. You also need to increase the PPULongVersion in unit
ppu and adjust the code in the ppudump utility.
Regards,
Sven
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20210119/80089272/attachment.htm>
More information about the fpc-devel
mailing list