Re: [fpc-pascal] Are there any drawbacks to "reference to"?
On Mon, 6 Jun 2022 08:26:47 +0700, Hairy Pixels via fpc-pascal wrote: >First off I didnt see Anthonys original email, just like Sven says he >doesnt see mine. >Whats going on here? Im using a Gmail account because my personal domain was >getting >rejected for some reason, is Anthony on Gmail also? We need to get this fixed >I think. You can interface this discussion via GMane news mirror I use a dedicated news reader and it has these advantages: - Does not pollute my regular email account with lots of messages - Keeps a threaded local archive of the discussions for easy reference - Any such blockades you describe are non-existent Point your news reader to news.gmane.io and subscribe to: gmane.comp.compilers.free-pascal.general gmane.comp.ide.lazarus.general gmane.comp.compilers.free-pascal.devel -- Bo Berglund Developer in Sweden ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Are there any drawbacks to "reference to"?
> On Jun 6, 2022, at 8:26 AM, Hairy Pixels wrote: > > I think what the compiler needs to do is internally support a variant record > type and switch to the correct function type at runtime. Something like this: > > TCallback = record > kind: byte; > case byte of > 0: (proc: procedure); > 1: (ref: reference to procedure); > 2: (nested: procedure is nested); > 3: (obj: procedure of object); > end; I found Anthony's email in the archive where he explain this optimization very nicely but he missed another aspect of it. Take for example this code: type TCallback = reference to procedure; procedure CallMe(callback: TCallback); begin callback(); end; var i: integer = 1; begin CallMe(procedure begin writeln(‘hello ‘, i); end); end; Here state needs to be captured but the structure capturing it doesn’t need to be a heap allocated interface backed class because it never leaves the calling scope. FPC already has an existing closure type for nested functions which is far more efficient and could be implemented if there was this variant structure behind the scenes which could accept it. So the optimization has two components: 1) If there is no anonymous function then obviously no state needs to be captured and the function reference should be either a function pointer or a “of object” pointer. 2) If the there is captured state but that closures never leaves the calling scope then it can be optimized as a “is nested” function pointer. Unlike most of my feature requests this one actually affects performance and should seriously be considered. It’s nothing crazy like constant propagation for inlining function pointers but it does require a new dynamic type be introduced to the compiler which can wrap up these variant function pointers and dispatch the correct one at runtime. Needless to say if it’s within my ability I will elect myself to implement this if it’s permitted by the compiler team. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Are there any drawbacks to "reference to"?
> On Jun 6, 2022, at 8:26 AM, Hairy Pixels wrote: > > First off I didn’t see Anthony’s original email, just like Sven says he > doesn’t see mine. What’s going on here? I’m using a Gmail account because my > personal domain was getting rejected for some reason, is Anthony on Gmail > also? We need to get this fixed I think. Bo Berglund, I just saw your message on the mail list archive also but I’m not getting here. Ok the mail list is totally broken for me but I don’t know how news.gmane.io works (my news reader is for RSS and I have no idea what this is). I’ll research it later because I don’t think I can use this thing anymore. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
