Re: [fpc-pascal] Are there any drawbacks to "reference to"?
Michael Van Canneyt schrieb am Mo., 20. Juni 2022, 08:04: > > > On Mon, 20 Jun 2022, Sven Barth via fpc-pascal wrote: > > > Am 20.06.2022 um 03:37 schrieb Hairy Pixels: > >> > >>> On Jun 19, 2022, at 10:04 PM, Sven Barth > > > wrote: > >>> > >>> As you can see the allocation only happens once and not all the time. > >>> What might be worse however is the optimization behavior as in this > > example the compiler wouldn't optimize the counter variable into a > regvar > > with enabled optimizations (however in case of a nested function the > compiler > > wouldn't do this either if the function isn't inlined). > >>> > >> > >> I’m saying if the OUTER method is in a tight loop (Foo in this example) > > you’re in trouble because it now contains an allocation which is > unexpected. > > > > In that case we're in the same territory as always: ensure that you know > > what your code does. It's the same reason why adding character by > > character to a managed String is slower then allocating the string once > > and then setting the characters. And I think it's very seldom that > > someone uses a function reference that does not leave the scope of the > > surrounding function. > > Does this not depend on the callback declaration ? > > Type >FuncRef = reference to procedure(a : integer); > > Procedure DoSomething(f : FuncRef); > begin > end; > > Procedure UseSomething; > > begin >For I:=X to SomeLimit do > DoSomething(Whatever) > end; > > Does the declaration of DoSomething (which uses reference to) not > ensure that an interface is created in UseSomething ? Yes, in your example this is the case, but look at mine again: it's unnecessary to create the capture object here and in theory the compiler could convert it to an ordinary nested function variable. But that 's all theoretical, because right now such an optimization doesn't exist. I tried to find your original mail, to look for the answer myself, > but I don't find it offhand. > Either in fpc-pascal or fpc-announce from end of May. > It may be a good idea to add the explanation you gave in the announcement > mail to the wiki (and link to it in the user changes in trunk page) There won't be a "User Changes Trunk" entry because nothing existing broke with this new feature. There will however be a "New Features Trunk" entry that will point to the announcement mail. There will be no documentation by me in the wiki. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Calling undefined function pointers in generics
Hairy Pixels schrieb am Mo., 20. Juni 2022, 03:38: > NOTE: I’m replying to this and CC’ing Sven so hopefully he can see it. > > > On Jun 19, 2022, at 10:05 AM, Hairy Pixels wrote: > > > > This code snippet will give a compiler error "Syntax error, ";" expected > but "(“ found”. It’s an unspecialized generic type so I would think it > should compile and only attempt to validate the parameters when the > function is specialized. > > > > generic procedure Perform(func: T); > > begin > > func(1); > > end; > Please report a bug. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Calling undefined function pointers in generics
> On Jun 20, 2022, at 7:12 PM, Sven Barth wrote: > > Please report a bug. > Done. https://gitlab.com/freepascal.org/fpc/source/-/issues/39794. I may actually try to fix this myself since I may know what the problem is. And on that note did you notice I made a PR for your idea of a generic keywords mode switch? It’s been at least a couple years but I believe this is what you wanted. If not please leave some notes in the PR and I can fix it. https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/240 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 Mon, 20 Jun 2022, Sven Barth wrote: Michael Van Canneyt schrieb am Mo., 20. Juni 2022, 08:04: On Mon, 20 Jun 2022, Sven Barth via fpc-pascal wrote: Am 20.06.2022 um 03:37 schrieb Hairy Pixels: On Jun 19, 2022, at 10:04 PM, Sven Barth wrote: As you can see the allocation only happens once and not all the time. What might be worse however is the optimization behavior as in this example the compiler wouldn't optimize the counter variable into a regvar with enabled optimizations (however in case of a nested function the compiler wouldn't do this either if the function isn't inlined). I’m saying if the OUTER method is in a tight loop (Foo in this example) you’re in trouble because it now contains an allocation which is unexpected. In that case we're in the same territory as always: ensure that you know what your code does. It's the same reason why adding character by character to a managed String is slower then allocating the string once and then setting the characters. And I think it's very seldom that someone uses a function reference that does not leave the scope of the surrounding function. Does this not depend on the callback declaration ? Type FuncRef = reference to procedure(a : integer); Procedure DoSomething(f : FuncRef); begin end; Procedure UseSomething; begin For I:=X to SomeLimit do DoSomething(Whatever) end; Does the declaration of DoSomething (which uses reference to) not ensure that an interface is created in UseSomething ? Yes, in your example this is the case, but look at mine again: it's unnecessary to create the capture object here and in theory the compiler could convert it to an ordinary nested function variable. My point is that if someone creates an API where he/she uses "reference to procedure" then the consumer of the API is stuck with the creation of an interface. So it's not always a choice whether an interface will be used or not. My conclusion is then that 'reference to' should be used sparingly in public APIs as they are (relatively) expensive. Unless I missed/misunderstod something of course... Michael.___ 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 20, 2022, at 12:44 PM, Sven Barth wrote: > > If the compiler can proove that the function reference never leaves the scope > (that means no assignment to global variables, out/var parameters, the Result > variable, passing on to some other function or conversion to pointer (and I'm > sure there are others)) and the function reference isn't used as an interface > then and only then the compiler could reduce this to something else. But > that's an optimization for another day and in my opinion such a rarlely used > usecase that it's simply not worth it. Maybe it’s off topic but it’s all very strange to me that FPC is making you think in advance what the caller of the function pointer will provide. In every other language I’ve used you simply declare a function pointer type and you can give it anything you want, a nested function, global function, method or anonymous function and the compiler figures out how to call it for you. The function reference seems like it could almost fulfill that role but it comes with this extra baggage which isn’t always needed and hence the calls for optimizing it way. Having said that, if nothing changes I think the only time you will ever use the reference type is if you know it needs to survive beyond the calling scope, i.e a thread in most cases. 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"?
Can anyone explain why this works? TProc is a normal function pointer so how
did it capture gVar? My understanding is that only nested proc vars could do
this.
{$mode objfpc}
{$modeswitch anonymousfunctions}
program anonymous_functions;
type
TProc = procedure;
procedure Call(proc: TProc);
begin
proc;
end;
var
gVar: integer;
begin
Call(procedure
begin
writeln(gVar);
end);
end.
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 Mon, 20 Jun 2022, Hairy Pixels via fpc-pascal wrote: On Jun 20, 2022, at 12:44 PM, Sven Barth wrote: If the compiler can proove that the function reference never leaves the scope (that means no assignment to global variables, out/var parameters, the Result variable, passing on to some other function or conversion to pointer (and I'm sure there are others)) and the function reference isn't used as an interface then and only then the compiler could reduce this to something else. But that's an optimization for another day and in my opinion such a rarlely used usecase that it's simply not worth it. Maybe it’s off topic but it’s all very strange to me that FPC is making you think in advance what the caller of the function pointer will provide. In every other language I’ve used you simply declare a function pointer type and you can give it anything you want, a nested function, global function, method or anonymous function and the compiler figures out how to call it for you. The function reference seems like it could almost fulfill that role but it comes with this extra baggage which isn’t always needed and hence the calls for optimizing it way. Having said that, if nothing changes I think the only time you will ever use the reference type is if you know it needs to survive beyond the calling scope, i.e a thread in most cases. Unless I misunderstood your meaning, not really: It allows you to run callbacks without having to declare variables globally: Function DoSomething : String; var L : TStringList; begin L:=TstringList.Create; SomeCallBack(procedure(s : string) begin L.Add(S); end ); Result:=L.Text; L.free; end. With a regular procedure or procedure of object, you'd need to define L outside of DoSomething. Michael.___ 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 20, 2022, at 8:30 PM, Michael Van Canneyt via fpc-pascal > wrote: > > My point is that if someone creates an API where he/she uses "reference to > procedure" then the consumer of the API is stuck with the creation of an > interface. > > So it's not always a choice whether an interface will be used or not. > > My conclusion is then that 'reference to' should be used sparingly in public > APIs as they are (relatively) expensive. I just responded with basically this same point. It’s tempting to use a reference because it accepts all function types but it has this baggage. If you’re making an API and want the caller to be able to user nested, global or methods than you need to either duplicate code or use reference to and take the penalty hit. My opinion is the compiler needs a new type which wraps these all up and lets us just think about function pointers and not what the programmer is going to supply at the time of calling. If that won’t happen then the references should be strictly limited to instances where you need the call to survive past the calling scope and share state. If you don’t need to share state then I think you could even pass a nested proc var to a thread and it would be called later the same as a reference but the state is captured would be static. 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 20, 2022, at 8:39 PM, Michael Van Canneyt via fpc-pascal > wrote: > > It allows you to run callbacks without having to declare variables globally: > > Function DoSomething : String; > > var > L : TStringList; > > begin > L:=TstringList.Create; > SomeCallBack(procedure(s : string) > begin > L.Add(S); > end > ); > Result:=L.Text; > L.free; > end. > > With a regular procedure or procedure of object, you'd need to define L > outside of DoSomething. I think you could use “is nested” and it would work also but see my other email with my example of a plain procedure which seems to capture for some reason. 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"?
Hairy Pixels schrieb am Mo., 20. Juni 2022, 15:32: > Can anyone explain why this works? TProc is a normal function pointer so > how did it capture gVar? My understanding is that only nested proc vars > could do this. > Globals don't need to be captured, because they're reachable from any scope. Regards, Sven ___ 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"?
Hairy Pixels schrieb am Mo., 20. Juni 2022, 15:30: > > > > On Jun 20, 2022, at 12:44 PM, Sven Barth > wrote: > > > > If the compiler can proove that the function reference never leaves the > scope (that means no assignment to global variables, out/var parameters, > the Result variable, passing on to some other function or conversion to > pointer (and I'm sure there are others)) and the function reference isn't > used as an interface then and only then the compiler could reduce this to > something else. But that's an optimization for another day and in my > opinion such a rarlely used usecase that it's simply not worth it. > > Maybe it’s off topic but it’s all very strange to me that FPC is making > you think in advance what the caller of the function pointer will provide. > In every other language I’ve used you simply declare a function pointer > type and you can give it anything you want, a nested function, global > function, method or anonymous function and the compiler figures out how to > call it for you. > Then you've never used C++... > The function reference seems like it could almost fulfill that role but it > comes with this extra baggage which isn’t always needed and hence the calls > for optimizing it way. > > Having said that, if nothing changes I think the only time you will ever > use the reference type is if you know it needs to survive beyond the > calling scope, i.e a thread in most cases. > You misjudge how function references are used in common Delphi code. There is nearly no case where optimizing it away would work. Thus it is simply not important to optimize this. Regards, Sven > ___ 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"?
Michael Van Canneyt via fpc-pascal schrieb am Mo., 20. Juni 2022, 15:41: > > > On Mon, 20 Jun 2022, Sven Barth wrote: > > > Michael Van Canneyt schrieb am Mo., 20. Juni > 2022, > > 08:04: > > > >> > >> > >> On Mon, 20 Jun 2022, Sven Barth via fpc-pascal wrote: > >> > >>> Am 20.06.2022 um 03:37 schrieb Hairy Pixels: > > > On Jun 19, 2022, at 10:04 PM, Sven Barth < > pascaldra...@googlemail.com> > >> > >>> wrote: > > > > As you can see the allocation only happens once and not all the time. > > What might be worse however is the optimization behavior as in this > >>> example the compiler wouldn't optimize the counter variable into a > >> regvar > >>> with enabled optimizations (however in case of a nested function the > >> compiler > >>> wouldn't do this either if the function isn't inlined). > > > > I’m saying if the OUTER method is in a tight loop (Foo in this > example) > >>> you’re in trouble because it now contains an allocation which is > >> unexpected. > >>> > >>> In that case we're in the same territory as always: ensure that you > know > >>> what your code does. It's the same reason why adding character by > >>> character to a managed String is slower then allocating the string once > >>> and then setting the characters. And I think it's very seldom that > >>> someone uses a function reference that does not leave the scope of the > >>> surrounding function. > >> > >> Does this not depend on the callback declaration ? > >> > >> Type > >>FuncRef = reference to procedure(a : integer); > >> > >> Procedure DoSomething(f : FuncRef); > >> begin > >> end; > >> > >> Procedure UseSomething; > >> > >> begin > >>For I:=X to SomeLimit do > >> DoSomething(Whatever) > >> end; > >> > >> Does the declaration of DoSomething (which uses reference to) not > >> ensure that an interface is created in UseSomething ? > > > > > > Yes, in your example this is the case, but look at mine again: it's > > unnecessary to create the capture object here and in theory the compiler > > could convert it to an ordinary nested function variable. > > My point is that if someone creates an API where he/she uses > "reference to procedure" then the consumer of the API is stuck > with the creation of an interface. > > So it's not always a choice whether an interface will be used or not. > > My conclusion is then that 'reference to' should be used sparingly in > public APIs > as they are (relatively) expensive. > > Unless I missed/misunderstod something of course... > No, you're essentially right here. Though the passing onto the function itself is only an adjustment of the reference count and the creation of the capturer amortizes with the amount of different anonymous functions you have inside a function (the more the less is the cost per anonymous function). Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Calling undefined function pointers in generics
Hairy Pixels schrieb am Mo., 20. Juni 2022, 15:12: > > > > On Jun 20, 2022, at 7:12 PM, Sven Barth > wrote: > > > > Please report a bug. > > > > Done. https://gitlab.com/freepascal.org/fpc/source/-/issues/39794. I may > actually try to fix this myself since I may know what the problem is. > > And on that note did you notice I made a PR for your idea of a generic > keywords mode switch? It’s been at least a couple years but I believe this > is what you wanted. If not please leave some notes in the PR and I can fix > it. > > https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/240 I did reply to your mail on fpc-devel, but maybe you didn't see it for the same reason I don't see your mail, so here again: I won't apply this before backwards compatible type overloading isn't working in non-Delphi modes as well. Regards, Sven ___ 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 Mon, 20 Jun 2022 20:32:44 +0700 Hairy Pixels via fpc-pascal wrote: > Can anyone explain why this works? TProc is a normal function pointer > so how did it capture gVar? gVar is global. No need to capture it. Only stack vars needs capture. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Cross-compiler for ARM64 on Windows available?
Hi, I have developed a DLL for x64 Windows and compiled with fpc 3.2.2. I would like to compile the same code for ARM64 running Windows. I need this to support the MS Surface devices. Even though the platform list of the Lazarus Wiki https://wiki.freepascal.org/Platform_list lists "Windows for ARM64" under "Supported targets for AArch64" I did neither find a suitable cross-compiler for download, nor did I find any hints on how to compile for this platform in the documentation. Is there a release plan for an fpc version for ARM64 on Windows? When can I expect a suitable compiler to come? Best regards, Wolfgang ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Cross-compiler for ARM64 on Windows available?
Am 20.06.2022 um 12:34 schrieb Wolfgang Hubert via fpc-pascal: Hi, I have developed a DLL for x64 Windows and compiled with fpc 3.2.2. I would like to compile the same code for ARM64 running Windows. I need this to support the MS Surface devices. Even though the platform list of the Lazarus Wiki https://wiki.freepascal.org/Platform_list lists "Windows for ARM64" under "Supported targets for AArch64" I did neither find a suitable cross-compiler for download, nor did I find any hints on how to compile for this platform in the documentation. Is there a release plan for an fpc version for ARM64 on Windows? When can I expect a suitable compiler to come? Windows on AArch64 is currently only supported in main thus you need to compile it yourself (see also https://lists.freepascal.org/pipermail/fpc-announce/2020-April/000614.html ). Also there are still some errors for which the origins haven't been found yet, so your mileage may vary... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Cross-compiler for ARM64 on Windows available?
Le 20/06/2022 à 23:53, Sven Barth via fpc-pascal a écrit : Am 20.06.2022 um 12:34 schrieb Wolfgang Hubert via fpc-pascal: Hi, I have developed a DLL for x64 Windows and compiled with fpc 3.2.2. I would like to compile the same code for ARM64 running Windows. I need this to support the MS Surface devices. Even though the platform list of the Lazarus Wiki https://wiki.freepascal.org/Platform_list lists "Windows for ARM64" under "Supported targets for AArch64" I did neither find a suitable cross-compiler for download, nor did I find any hints on how to compile for this platform in the documentation. Is there a release plan for an fpc version for ARM64 on Windows? When can I expect a suitable compiler to come? Windows on AArch64 is currently only supported in main thus you need to compile it yourself (see also https://lists.freepascal.org/pipermail/fpc-announce/2020-April/000614.html ). Also there are still some errors for which the origins haven't been found yet, so your mileage may vary... You might also try this "completely untested" cross-installer: ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/aarch64-win64/fpc-3.3.1.aarch64-win64.built.on.x86_64-linux.tar.gz See: ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/aarch64-win64/README-fpc-3.3.1.aarch64-win64.built.on.x86_64-linux Pierre ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
