Re: [fpc-devel] Attn Michael: r 43417 (ordinal bithelpers)

2019-11-10 Thread thaddy
On 2019-11-08 22:33, Bart via fpc-devel wrote: Hi, > 2. A rather more serious issue. Compile time errors occur with e.g. ANativeInt.SetBit(High(TNativeIntBitIndex)) in modes tp (32-bit), fpc (32-bit), objfpc (32+64-bit) and delphi (32+64-bit) Range check error while evaluating constants

Re: [fpc-devel] inline... and philosophy

2019-11-10 Thread Sven Barth via fpc-devel
Am 10.11.2019 um 15:47 schrieb Marco van de Voort: (and btw, if you are serious about these scenarios, drop all optimization work immediately, and start working on packages :-) I don't know if that would help much, cause especially on Windows every application would probably provide its own set

Re: [fpc-devel] inline... and philosophy

2019-11-10 Thread Florian Klämpfl
Am 10.11.19 um 18:01 schrieb J. Gareth Moreton: Fair enough - thank you. This is a bit of a micro-optimisation for the compiler in regards to what I've just done, but I've noticed that, a couple of times, commands to the effect of the following appear: tasmlabel(symbol).decrefs; if

Re: [fpc-devel] inline... and philosophy

2019-11-10 Thread J. Gareth Moreton
Fair enough - thank you. This is a bit of a micro-optimisation for the compiler in regards to what I've just done, but I've noticed that, a couple of times, commands to the effect of the following appear: tasmlabel(symbol).decrefs; if tasmlabel(symbol).getrefs = 0 then ... That is...

Re: [fpc-devel] inline... and philosophy

2019-11-10 Thread Florian Klämpfl
Am 10.11.19 um 17:42 schrieb J. Gareth Moreton: Some of the "condition_in" functions need expanding though, and I don't yet have an answer if it's okay to do operator overloading in the compiler source (so I can do things like "if (jmp1.cond in jmp2.cond) then", for example, instead of the

Re: [fpc-devel] inline... and philosophy

2019-11-10 Thread J. Gareth Moreton
That seems fair, yep.  Currently, vectorcall, and the more intricate parts of the System V ABI, is only really beneficial when interfacing with third-party libraries or when programming in assembly language. Sorry if I've given you a headache with my stubbornness and passion.  I'll try to

Re: [fpc-devel] Capturing addresses

2019-11-10 Thread Marco Borsari via fpc-devel
Il 10/11/2019 14:36, Jonas Maebe ha scritto: Hi, Does anyone know what the accepted/excepted behaviour is regarding the capture of addresses of var/out/const-by-address/constref parameters? For example: var g: longint; p: plongint; procedure test(var l: longint); begin p:=@l; end;

Re: [fpc-devel] inline... and philosophy

2019-11-10 Thread Florian Klämpfl
Am 10.11.19 um 16:02 schrieb J. Gareth Moreton: This message chain has proven to be a lot more educational and insightful than I would have given it credit for.  Thanks everybody! I know a lot of the time, the size of binaries is just an illusion, along with unfair comparisons with GCC (a

Re: [fpc-devel] inline... and philosophy

2019-11-10 Thread Michael Van Canneyt
On Sun, 10 Nov 2019, J. Gareth Moreton wrote: This message chain has proven to be a lot more educational and insightful than I would have given it credit for.  Thanks everybody! I know a lot of the time, the size of binaries is just an illusion, along with unfair comparisons with GCC (a

Re: [fpc-devel] inline... and philosophy

2019-11-10 Thread J. Gareth Moreton
This message chain has proven to be a lot more educational and insightful than I would have given it credit for.  Thanks everybody! I know a lot of the time, the size of binaries is just an illusion, along with unfair comparisons with GCC (a behemoth with corporate support) and Microsoft

Re: [fpc-devel] inline... and philosophy

2019-11-10 Thread Marco van de Voort
Op 09/11/2019 om 15:51 schreef J. Gareth Moreton: Competitions aside, there are times where space is a premium, whether it be from distributing an application on a DVD, bandwidth or data limits (even some first world countries are still on dial-up in places, or are otherwise monopolised by

Re: [fpc-devel] Capturing addresses

2019-11-10 Thread Martin Frb
On 10/11/2019 15:05, Jonas Maebe wrote: On 10/11/2019 14:58, Martin Frb wrote: So I am trying to understand what the difference (in terms of safety) is? (except that the none "var param" is always unsafe, the "var param" is only sometimes unsafe)? If you are talking about the safety of

Re: [fpc-devel] Capturing addresses

2019-11-10 Thread Jonas Maebe
On 10/11/2019 14:58, Martin Frb wrote: > So I am trying to understand what the difference (in terms of safety) > is? (except that the none "var param" is always unsafe, the "var param" > is only sometimes unsafe)? If you are talking about the safety of accesses after the capturing routine has

Re: [fpc-devel] inline... and philosophy

2019-11-10 Thread Marco van de Voort
Op 10/11/2019 om 11:17 schreef Marģers . via fpc-devel  Most processors have a fairly large uop cache (up to 2048 for the newest generations iirc), so this would only be for the first iteration? Do you have a reference (agner fog page or so) or more explanation for this that describes this?)

Re: [fpc-devel] Capturing addresses

2019-11-10 Thread Martin Frb
On 10/11/2019 14:36, Jonas Maebe wrote: For example: var g: longint; p: plongint; procedure test(var l: longint); begin p:=@l; end; begin test(g); end. After test() executes, p now contains the address of g (the '@' operator does not return the address of g's address on the

Re: [fpc-devel] inline... and philosophy

2019-11-10 Thread Mattias Gaertner via fpc-devel
On Sun, 10 Nov 2019 02:23:03 + "J. Gareth Moreton" wrote: > Does the smart linker strip out LCL components that are not used, or > must everything that's registered in a package or unit be included? If you mean with "registered" the RegsiterClass or RegisterComponents functions: If it is

[fpc-devel] Capturing addresses

2019-11-10 Thread Jonas Maebe
Hi, Does anyone know what the accepted/excepted behaviour is regarding the capture of addresses of var/out/const-by-address/constref parameters? For example: var g: longint; p: plongint; procedure test(var l: longint); begin p:=@l; end; begin test(g); end. After test() executes, p

Re: [fpc-devel] Attn Michael: r 43417 (ordinal bithelpers)

2019-11-10 Thread Florian Klämpfl
Am 10.11.19 um 11:45 schrieb Jonas Maebe: On 2019-11-10 10:54, Michael Van Canneyt wrote: It's not just the waste of time, it's also the origanization of the sources. See my mail to Florian. I have 1 application that has all the tests. It's easy to navigate & whatnot. The nice thing about

Re: [fpc-devel] Attn Michael: r 43417 (ordinal bithelpers)

2019-11-10 Thread Florian Klämpfl
Am 10.11.19 um 10:54 schrieb Michael Van Canneyt: On Sat, 9 Nov 2019, Jonas Maebe wrote: On 09/11/2019 20:17, Michael Van Canneyt wrote: On Sat, 9 Nov 2019, Jonas Maebe wrote: I definitely want to help to integrate the tests somehow in the daily testrun, but I will not use the slow

Re: [fpc-devel] Attn Michael: r 43417 (ordinal bithelpers)

2019-11-10 Thread Jonas Maebe
On 2019-11-10 10:54, Michael Van Canneyt wrote: It's not just the waste of time, it's also the origanization of the sources. See my mail to Florian. I have 1 application that has all the tests. It's easy to navigate & whatnot. The nice thing about your punit-based tests is that they can just

Re: [fpc-devel] inline... and philosophy

2019-11-10 Thread Marģers . via fpc-devel
> Op 2019-11-09 om 02:24 schreef Marģers . via fpc-devel: > > > > 3) it changes code location (code cross page boundaries). For my particular > > cpu there are 64 byte code page. If loop can fit in it, speed is twice as > > it overlaps even one byte over page boundary. Jumping forward is ok (as

Re: [fpc-devel] Attn Michael: r 43417 (ordinal bithelpers)

2019-11-10 Thread Michael Van Canneyt
On Sat, 9 Nov 2019, Jonas Maebe wrote: On 09/11/2019 20:17, Michael Van Canneyt wrote: On Sat, 9 Nov 2019, Jonas Maebe wrote: I definitely want to help to integrate the tests somehow in the daily testrun, but I will not use the slow testsuite. With parallel compilation, it will be

Re: [fpc-devel] Attn Michael: r 43417 (ordinal bithelpers)

2019-11-10 Thread Michael Van Canneyt
On Sat, 9 Nov 2019, Jonas Maebe wrote: On 09/11/2019 20:17, Michael Van Canneyt wrote: home:~/fpc> time make clean all PP=ppcx64-3.0.4 > out /usr/bin/ld: warning: x86_64/bin/x86_64-linux/link.res contains output sections; did you forget -T? 119.139u 11.763s 1:47.32 121.9% 0+0k

Re: [fpc-devel] inline... and philosophy

2019-11-10 Thread Sven Barth via fpc-devel
J. Gareth Moreton schrieb am So., 10. Nov. 2019, 03:23: > Does the smart linker strip out LCL components that are not used, or must > everything that's registered in a package or unit be included? Granted, > since forms are being read from a resource file, I doubt it can really be > tied into