<div dir="ltr"><div dir="ltr" class="gmail_attr">On Sat, Jan 9, 2021 at 3:52 PM Jonas Maebe via fpc-devel <<a href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 08/01/2021 22:00, Christo Crause via fpc-devel wrote:<br>> However I see problems with propagating section information through<br>
> reference type parameters. I'm not sure how to propagate the section<br>
> information of the variable "w" through the parameter<br>
<br>
Can't you use something like the far pointers used on the 8086 target? (<br>
(a regular pointer only contains an offset, a far pointer contains both<br>
a segment and an offset) If so, the main downside is that it would<br>
increase the size of all reference parameters to include room for the<br>
section part of the pointer, unless you add a directive to disable that<br>
(or couple it to the existing farpointers directive).<br></blockquote><div><br></div><div>Thanks for the idea Jonas. This could be a solution as is, but as you mentioned it comes with a parameter size penalty. Using a generic offset for the section (unknown at compile time on the callee side) would require runtime handing of the different access methods to the different address spaces, increasing code size. These two concerns are deal breakers for microcontrollers (at least in my opinion).</div><div><br></div><div>Could your idea not be simplified by allowing the use of the section directive when defining a pointer?</div><div>type</div><div> Peeprom = pointer; section '.eeprom';</div><div><br></div><div>This way when a parameter is defined as e.g. type Peeprom the compiler knows what access code should be generated for the specified section. It would also help with compile time error checking where assigning a regular pointer to a section pointer should not be allowed (unless the user applies a type cast).<br></div></div></div>