Christo Crause via fpc-devel <fpc-devel@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@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.cra...@gmail.com >> > <mailto:christo.cra...@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 >
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
