Re: [fpc-pascal] FP IDE sources

[Florian Klämpfl via fpc-pascal]

Am 14.03.2024 um 11:04 schrieb Michael Van Canneyt via fpc-pascal:



On Thu, 14 Mar 2024, Karoly Balogh via fpc-pascal wrote:


Hi,

On Thu, 14 Mar 2024, Guillermo Martínez Jiménez via fpc-pascal wrote:


I thought "packages" were libraries not applications, as there is an
"utils" directory with programs.


I agree, I'm also not very fond of the IDE being in packages, but most of
the team considers it a legacy piece of code (which it is, no argument
there), and at least this way it doesn't need constant special treatment,
unlike when it was in the root folder of the repo under "ide". It's less
"in the way".


Still, it is more logical to place it under utils, with the rest of the
programs.

The argument about the time to compile seems simply false to me:

If you consider the FPC toplevel 'make all' as the only command to
issue, then you may win some time, although I doubt it will be that much.

But 99% of the time, you don't need to recompile the utilities.


I do always a make all as it takes only a few more seconds than a make 
cycle and then I am sure everything builds.




I certainly do not:
I usually do a make cycle followed by a compilation of the rtl/packages 
with debug info.


So if we moved the IDE to utils where it logically belongs, I would 
actually be winning time, contrary to the argument for having it in 
packages.


As I moved it, my thinking was that it is not really a utility but a 
package (in particular in the sense of the installer). And having 
executables is also the case for other packages.




To me it therefore seems a better idea to move the IDE to utils, and to 
have a

toplevel make command that does the same as 'make all' simply without the
utilities. Or have a 'NOUTILS=1' define.

It increases build time if one want to test that everything builds with 
no real gain and being not a utility?

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Floating point question

[Florian Klämpfl via fpc-pascal]

> Am 16.02.2024 um 15:34 schrieb Bernd Oppolzer via fpc-pascal 
> :
> 
> Am 16.02.2024 um 08:32 schrieb Florian Klämpfl via fpc-pascal:
>> Am 16.02.2024 um 08:23 schrieb Ern Aldo via fpc-pascal 
>>  <mailto:fpc-pascal@lists.freepascal.org>:
>>> 
>>>  Compile-time math needs to be as correct as possible. RUN-time math can 
>>> worry about performance.
>> So you are saying when constant propagation is on, an expression should have 
>> a different result than with constant propagation off?
> I don't know exactly, what you mean by constant propagation.
> 
> But IMO, given this (sort of fictive) Pascal code snippet:
> 
> 
> const Xconst : single = 1440.0; 
> 
> var y1, y2 : real; 
> 
> y1 := 33.0 / 1440.0; 
> 
> y2 :=  33.0 / Xconst;
> 
> the division in the first assignment (to y1) should be done at maximum 
> precision, that is, 
> both constants should be converted by the compiler to the maximum available 
> precision and 
> the division should be done (best at compile time) using this precision. 
> 
Constant folding is an optimization technique, so the first expression could be 
also evaluated at run time in case of a simple compiler (constant folding is 
not something which is mandatory) which means that we have to use always full 
precision (what full means depends on the host and target platform thought) for 
real operations. So either: always full precision with the result all 
operations get bloated or some approach to assign a precision to real constants.

It gets even more hairy if more advanced optimization techniques are involved:

Consider

var
   y1,y2 : single;

 y1 := 1440.0
 y2 := 33.0 / y1;

When constant propagation and constant folding are on (both are optimizations), 
y2 can be calculated at compile time and everything reduced to one assignment 
to y2. So with your proposal the value of y2 would differ depending on the 
optimization level.
> in the second case, if the compiler supports constants of the reduced type 
> (which I believe it does, 
> 
> no matter how the syntax is), I find it acceptable if the computation is done 
> using single precision, 
> because that's what the developer calls for.
> 
> So probably the answer to your question is: yes.
> 
> Kind regards
> 
> Bernd
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Floating point question

[Florian Klämpfl via fpc-pascal]

> Am 16.02.2024 um 08:23 schrieb Ern Aldo via fpc-pascal 
> :
> 
>  Compile-time math needs to be as correct as possible. RUN-time math can 
> worry about performance.

So you are saying when constant propagation is on, an expression should have a 
different result than with constant propagation off?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Floating point question

[Florian Klämpfl via fpc-pascal]

On 09.02.24 15:00, greim--- via fpc-pascal wrote:

Hi,

my test with Borland Pascal 7.0 running in dosemu2 running 80x87 code.
The compiler throws an error message for calculating HH and II with 
explicit type conversion.

The results of FF and GG are the same!
Even on 16 bit system!

I think this behavior is right!


The x87 fpu behavior is completely flawed as its precision is not 
dependent on the instruction used but the state of the fpu.


Overall, the intermediate float precision is a very difficult topic. The 
famous Goldberg article 
(https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html) does 
not suggest to use the highest possible precision after all. And an 
additional interesting read: 
https://randomascii.wordpress.com/2012/03/21/intermediate-floating-point-precision/


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Floating point question

[Florian Klämpfl via fpc-pascal]

Am 04.02.2024 um 18:54 schrieb James Richters:

I can understand storing the constant in the lowest precision that doesn't 
cause data loss, thus making thing more efficient, but the actual calculation 
done by the compiler should be done at maximum precision and only the final 
result stored in the lowest required precision.
This calculation is only carried out buy the compiler once, during compilation, 
not by the executing program.

The calculation should be done completely using extended, and if the result of 
the entire calculation is a 2, then store it as a byte, if it's 1.23 then store 
it as a single, and if it's 1.2324241511343 store it as Extended.   The problem 
is the 33/1440 is being stored as a single and IS LOSING DATA, the division 
should have been detected and therefore the lowest precision that doesn't cause 
data loss is NOT a single.

In all cases in our example, we should not be getting different values for the 
same constant.   The implementation not the right way of doing it.  It's not 
doing what is required by the statement:

"New behaviour: floating point constants are now considered to be of the lowest 
precision which doesn't cause data loss"

The "New behaviour"  has a DEFINATE bug in it, because we are experiencing data 
loss.


You are understand the statement wrong: it says nothing about 
operations/expressions, only constants.



The correct way to implement this is to have the compiler ALWAYS evaluate 
everything at highest precision, THEN after all computations are complete 
evaluate the final answer to store in the constant and reduce the precision of 
only the constant if it's justified.   If it was done this way then it would 
always give the expected result.


This is plainly wrong. Simply because it would mean that we have to carry out also all calculations with variables 
always with the highest precision. And this is not how things are supposed to be done in any reasonable programming 
language. The legacy x87 fpu doing so causes already enough headache.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Floating point question

[Florian Klämpfl via fpc-pascal]

Am 04.02.2024 um 18:25 schrieb James Richters via fpc-pascal:

I agree with Aadrian 100%
  
"New behaviour: floating point constants are now considered to be of the lowest precision which doesn't cause data loss"


We are getting data loss So it's doing it WRONG.

So we are all living with a stupid way of doing things so some Delphi code 
won't have warnings?

Who came up with this???

The old way was CORRECT,   instead of changing it for everyone making it wrong 
for most users, a compiler directive should have been needed to get rid of the 
warnings, or ONLY applied in Mode Delphi.  Not to make everything incorrect for 
everyone unless you add a directive. The problem with this that no one is 
expecting to need to add a directive to do things right.

Consider this:
  
Var

   MyVariable : Extended;

MyVariable := 8427 + 33 / 1440.0;

Since I am storing the result in an Extended, I DO NOT EXPECT the 33/1440 to be 
a SINGLE, that is NUTS!!


No need to yell.

This is how reasonable programing languages work. The result type depends only on the type of the involved 
variables/expressions. *Never* the variable it is assigned to.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Floating point question

[Florian Klämpfl via fpc-pascal]

> Am 04.02.2024 um 13:50 schrieb Adriaan van Os via fpc-pascal 
> :
> 
> Jonas Maebe via fpc-pascal wrote:
>> On 03/02/2024 18:42, James Richters via fpc-pascal wrote:
>>> Constants are also evaluated wrong,you don’t know what that constant is 
>>> going to be used for, so all steps of evaluating a constant MUST be done in 
>>> extended by the compiler, or the answer is just wrong.
>> See https://wiki.freepascal.org/User_Changes_2.2.0#Floating_point_constants 
>> and https://www.freepascal.org/daily/doc/prog/progsu19.html
> 
> I think this discussion shows that the 2.2 compiler change was a bad idea 
> (for modes other than Delphi).

The result with the old code was that all floating point operations involving 
constants were carried out in full precision (normally double or extended) 
which is something unexpected and results in slow code.

Example:

const
  c2 = 2;
var
  s1, s2 : single;

…
s1:=s2/c2;

generated an expensive double division for no good reason.

OTOH:

const
  c2 : single = 2;
var
  s1, s2 : single;

…
s1:=s2/c2;

generated a single division.


 There is still the -CF option as a workaround to get the old behavior.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] What's in Hello World

[Florian Klämpfl via fpc-pascal]

> Am 07.01.2024 um 13:21 schrieb Ingemar Ragnemalm via fpc-pascal 
> :
> 
> Just for comparison, I fired up Think Pascal and made Hello world!
> 
> Plain Hello world, closes so quickly that you don't have time to see it: 4625 
> bytes.
> 
> Including ShowText and while not Button do; 4639 bytes.
> 
> Yes, less than 5k! Progress?
> 
https://github.com/chainq/amiga-tiny-hello-p

244 bytes with FPC.___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] What's in Hello World

[Florian Klämpfl via fpc-pascal]

> Am 06.01.2024 um 20:05 schrieb Matthew Phillips via fpc-pascal 
> :
> 
> I compiled the Hello World program from the docs and noticed that it's
> 435k. Compared to a lot of newer languages, like Golang, that's not bad
> at all.
> 
> I then compiled the equivalent C program with gcc which came out at
> 33k. So I'm just curious, where does the difference comes from?
> Could it be that fpc is including some parts that are not being used in
> this simple of a program or is more going on?

https://wiki.freepascal.org/Size_Matters

> 
> Like I said, purely a curiosity, not intended as a criticism. Cheers.
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
> 

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] aligned?

[Florian Klämpfl via fpc-pascal]

> Am 30.01.2023 um 14:03 schrieb Mattias Gaertner via fpc-pascal 
> :
> 
> Hi,
> 
> What does the fpc built-in function aligned?
> 
> For example in FloatToStrFIntl:
> 
>  Str(Double(Extended(Aligned(Value))):precision+7, Result);

It tells the compiler that the argument is properly aligned according to its 
type.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FreePascal and the OrangePi

[Florian Klämpfl via fpc-pascal]

> Am 22.10.2022 um 00:19 schrieb Terry A. Haimann via fpc-pascal 
> :
> 
> Dumb ?
> 
> What download should I use to install the latest version of FreePascal
> on the OrangePi 4 LTS, I am running Debian 3.0.6 Bullseye.
> 
> The Orange Pi 4 LTS is an SBC running an ARM Processor.
> Rockchip 3399 SOC
> 
> http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/orange-pi-4-LTS.html

Do you run an aarch64 or arm bistro? Best is, to post the output of cat 
/proc/cpuinfo
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] $modeswitch declared before $mode fails without warning

[Florian Klämpfl via fpc-pascal]

Am 18.09.22 um 14:22 schrieb Hairy Pixels via fpc-pascal:

One more thing today working with closures. Declaring the modeswitch before the 
mode does not actually enable the feature and gives no warning. What happens 
then is basic syntax fails and you’re totally confused as to why.

Shouldn’t this be illegal or give a warning at least?

{$modeswitch functionreferences}
{$modeswitch anonymousfunctions}
{$mode objfpc}


This is in general the case that $mode overrides all previously set 
switches i.e. it simply sets the switches as defined by the given mode 
so I am not sure if this is really worth a warning.




program test;
var
   p: reference to procedure;
begin
end.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Strange "division by zero" error using variants

[Florian Klämpfl via fpc-pascal]

Am 24.05.22 um 19:28 schrieb Thomas Kurz via fpc-pascal:

Dear all,

please consider the following code:


program Project1;

{$booleval off}

var
   v1, v2: variant;
   a: boolean;
   b: integer;

begin
   a := true;
   b := 0;
   // this works as expected:
   if a and (b > 0) and ((0+1) mod b = 0) then Writeln ('ok');

   v1 := true;
   v2 := 0;
   // this gives a "division by zero":
   if v1 and (v2 > 0) and ((0+1) mod v2 = 0) then Writeln ('ok');
end.


The "variant" variant results in a "division by zero". Obviously, it tries to evaluate the 
modulo-expression even though this shouldn't happen because complete boolean evaluation is disabled and the 
"if"-result is already known to be false after checking "v2>0".

Can anyone explain this strange behavior?


When compiling the and expressions, the compiler does not know (in this 
example it could, but in general it cannot) what the variants contain so 
just the variant and-operator is executed which does not/cannot 
distinguish between the logical and bitwise and variant.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Broken code with PEEPHOLE & REGVAR

[Florian Klämpfl via fpc-pascal]

> Am 13.03.2022 um 16:26 schrieb Peter via fpc-pascal 
> :
> 
> On 12/03/2022 11:33, Florian Klämpfl via fpc-pascal wrote:
>> 
>>> Am 12.03.2022 um 12:05 schrieb Peter via fpc-pascal 
>>> :
>>> 
>>> Its looking like it was fixed in main somewhere between
>>> 
>>> 31cd3df724 Jan, 2021
>>> &
>>> 837b433a28 Apr, 2021
>> Can you bisect it by any chance? See 
>> https://wiki.freepascal.org/FPC_git#bisect.27ing
>> ___
>> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
>> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
> 
> 
> 
> Hi Florian,
> 
> The problem was fixed with commit 503fc85d
>   2021-04-06 florian  * patch by J. Gareth Moreton: handle register 
> allocations correctly in MovMov2Mov 3, resolves #38703
> 
> https://gitlab.com/freepascal.org/fpc/source/-/issues/38703

Thanks for tracking this down! I have cherry picked the commit to fixes.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Broken code with PEEPHOLE & REGVAR

[Florian Klämpfl via fpc-pascal]

> Am 12.03.2022 um 12:05 schrieb Peter via fpc-pascal 
> :
> 
> Its looking like it was fixed in main somewhere between
> 
> 31cd3df724 Jan, 2021
> &
> 837b433a28 Apr, 2021

Can you bisect it by any chance? See 
https://wiki.freepascal.org/FPC_git#bisect.27ing
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] bug or feature?

[Florian Klämpfl via fpc-pascal]

Am 13.02.2022 um 10:25 schrieb Sven Barth via fpc-pascal:
Michael Van Canneyt via fpc-pascal mailto:fpc-pascal@lists.freepascal.org>> schrieb am 
So., 13. Feb. 2022, 09:47:




On Sun, 13 Feb 2022, Mattias Gaertner via fpc-pascal wrote:

 > On Sat, 12 Feb 2022 12:14:14 +0100 (CET)
 > Michael Van Canneyt via fpc-pascal mailto:fpc-pascal@lists.freepascal.org>>
 > wrote:
 >
 >> On Sat, 12 Feb 2022, Mattias Gaertner via fpc-pascal wrote:
 >>
 >> > Hi,
 >> >
 >> > This can't be right, can it?
 >> >
 >> > type
 >> >  TBird = class
 >> >    procedure Fly;
 >> >  end;
 >> >  TEagle = TBird; // alias
 >> >
 >> > procedure TEagle.Fly;
 >> > begin
 >> > end;
 >>
 >> Personally, I would not allow this.
 >> But Delphi compiles and runs it...
 >
 > ... and Delphi's class completion no longer works in the unit giving a
 > useless error "expected ';' but '.' found". So it is one of those
 > Delphi "features" compiling but not usable.

I'm all for forbidding this in objfpc mode.


Then file a bug report for it. Cause it's definitely going to be one of the low priority things cause it's going to be 
annoying to fix...


I thought (famous last words), checking the typesyms of the tobjectdef would be 
enough but who knows what else will bit :)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] target mipsel-embedded

[Florian Klämpfl via fpc-pascal]

> Am 29.11.2021 um 09:39 schrieb Michael Ring via fpc-pascal 
> :
> 
> Startup Code and Modules for chips had a license that Florian was not happy 
> with. So those parts are missing.

Also the files where huge due to the I/O capabilities of those microcontrollers 
IIRC.

> 
> I have not built mipsel for pic for a while but if you need a working 
> solution then I check if things compile with latest fpc and update my gitlab.
> 
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FreePascal and MySQL 8.0

[Florian Klämpfl via fpc-pascal]

> Am 19.09.2021 um 10:46 schrieb Michael Van Canneyt via fpc-pascal 
> :
> 
> 
> 
> On Sun, 19 Sep 2021, Florian Klämpfl via fpc-pascal wrote:
> 
>> 
>> 
>>> Am 19.09.2021 um 10:16 schrieb Michael Van Canneyt via fpc-pascal 
>>> :
>>> On Sat, 18 Sep 2021, Florian Klämpfl via fpc-pascal wrote:
>>>> Am 18.09.21 um 17:34 schrieb Michael Van Canneyt via fpc-pascal:
>>>>> On Sat, 18 Sep 2021, Terry A. Haimann via fpc-pascal wrote:
>>>>>> I just upgraded to a new laptop and see that MariaDB is using MySQL 8.0
>>>>>> . I also see there is no connector in my Free Pascal install for MySQL
>>>>>> 8.0.  I do see that there is an open ticket to create a connector.  Is
>>>>>> there an Alpha or Beta version of the connector available that I can
>>>>>> try?
>>>>> Trunk contains the mysql 8.0 connector.
>>>>> You should be able to simply copy the files and use the units with 3.2.x
>>>> Shall we merge it to fixes?
>>> Yes, definitely.
>> 
>> Hmm, it is inter winded with fcl-db changes should merge them as well?
> 
> There should be a change in mysql (the library headers) and a change in
> fcl-db (the new connector class) ?
> 

Ah, I see it is already merged. I wondered already why it is not in the 
eligibile.log ...___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FreePascal and MySQL 8.0

[Florian Klämpfl via fpc-pascal]

> Am 19.09.2021 um 10:16 schrieb Michael Van Canneyt via fpc-pascal 
> :
> 
> 
> 
> On Sat, 18 Sep 2021, Florian Klämpfl via fpc-pascal wrote:
> 
>> Am 18.09.21 um 17:34 schrieb Michael Van Canneyt via fpc-pascal:
>>> On Sat, 18 Sep 2021, Terry A. Haimann via fpc-pascal wrote:
>>>> I just upgraded to a new laptop and see that MariaDB is using MySQL 8.0
>>>> . I also see there is no connector in my Free Pascal install for MySQL
>>>> 8.0.  I do see that there is an open ticket to create a connector.  Is
>>>> there an Alpha or Beta version of the connector available that I can
>>>> try?
>>> Trunk contains the mysql 8.0 connector.
>>> You should be able to simply copy the files and use the units with 3.2.x
>> 
>> Shall we merge it to fixes?
> 
> Yes, definitely.

Hmm, it is inter winded with fcl-db changes should merge them as well?

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FreePascal and MySQL 8.0

[Florian Klämpfl via fpc-pascal]

Am 18.09.21 um 17:34 schrieb Michael Van Canneyt via fpc-pascal:



On Sat, 18 Sep 2021, Terry A. Haimann via fpc-pascal wrote:


I just upgraded to a new laptop and see that MariaDB is using MySQL 8.0
. I also see there is no connector in my Free Pascal install for MySQL
8.0.  I do see that there is an open ticket to create a connector.  Is
there an Alpha or Beta version of the connector available that I can
try?


Trunk contains the mysql 8.0 connector.
You should be able to simply copy the files and use the units with 3.2.x



Shall we merge it to fixes?

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC & Lazarus moving to gitlab

[Florian Klämpfl via fpc-pascal]

There is a third conversion of the FPF repository meanwhile (from June): 
https://gitlab.com/freepascal.org/fpc/testconversion3 
 Please check and report 
any problems, this is most likely the last chance to get things fixed before 
the final conversion.___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Will the size of an executable depend on the uses clause

[Florian Klämpfl via fpc-pascal]

> Am 16.06.2021 um 18:07 schrieb Dennis Lee Bieber via fpc-pascal 
> :
> 
> On Wed, 16 Jun 2021 13:15:10 +0200 (CEST), Michael Van Canneyt via
> fpc-pascal 
> declaimed the following:
> 
>> ~$ ldd /usr/bin/ls
>>  linux-vdso.so.1 (0x7ffc3f9c1000)
>>  libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 
>> (0x7f45b7132000)
>>  libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f45b6f4)
>>  libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 
>> (0x7f45b6eb)
>>  libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f45b6eaa000)
>>  /lib64/ld-linux-x86-64.so.2 (0x7f45b718f000)
>>  libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
>> (0x7f45b6e87000)
>> ~$ ls -lh /lib/x86_64-linux-gnu/libselinux.so.1 
>> /lib/x86_64-linux-gnu/libc-2.31.so /lib/x86_64-linux-gnu/libpcre2-8.so.0.9.0 
>> /lib/x86_64-linux-gnu/libdl-2.31.so  
>> /lib/x86_64-linux-gnu/libpthread-2.31.so 
>> -rwxr-xr-x 1 root root 2.0M Dec 16 11:04 /lib/x86_64-linux-gnu/libc-2.31.so
>> -rw-r--r-- 1 root root  19K Dec 16 11:04 /lib/x86_64-linux-gnu/libdl-2.31.so
>> -rw-r--r-- 1 root root 571K Dec  7  2019 
>> /lib/x86_64-linux-gnu/libpcre2-8.so.0.9.0
>> -rwxr-xr-x 1 root root 154K Dec 16 11:04 
>> /lib/x86_64-linux-gnu/libpthread-2.31.so
>> -rw-r--r-- 1 root root 160K Feb 26  2020 
>> /lib/x86_64-linux-gnu/libselinux.so.1
>> 
>> Total size of code needed to run the application: close to 3 Mb.
>> 
>> Comparison is different because of all kinds of memory sharing techniques,
>> but in general, the code size of an FPC binary is not too bad.
>> 
> 
>   Being Shared Object files, there should be, at most, only one copy of
> the library mapped into memory, and every executable referencing the shared
> object will get mapped into the same memory space.

This still results in pulling in all static data etc. of the libraries. 
https://dl.acm.org/doi/10.1145/3136014.3136031 

shows that the FPC approach is memory wise more efficient.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to find where my app consumes CPU?

[Florian Klämpfl via fpc-pascal]

> Am 19.05.2021 um 19:00 schrieb Bo Berglund via fpc-pascal 
> :
> 
> On Wed, 19 May 2021 16:02:00 +0200, Bo Berglund via fpc-pascal
>  wrote:
> 
>> The "other" items might be hidden inside other used classes such as the 
>> Indy10
>> components I use to implement the TCP/IP communications.
>> But when searching for sleep through the complete project sources I came up
>> empty-handed.
>> Something else must be going on.
>> 
>> I have a thread to handle the measuring sequence server and this uses timers
>> (TFpTimer) in order to check if it is time to run a task, but when idling no
>> task is running so no task execution thread spins off either...
> 
> So now I am down to the timers...
> I am using TFPTimer timers in the scheduler to handle various things, some of
> them are just one-shots to delay an action for some predetarmined time.
> These are only executing as one-shots.
> But the schedule timer restarts itself with an interval of 60 s.
> Another timer is used to handle a message queue between parts of the system. 
> It
> runs at a shorter time, like a second or so. Restarts itself too.
> But it runs only if scheduling is active.
> 
> I have no idea how TFpTimers work internally, maybe these cause extra CPU 
> cycles
> while waiting for the time they should fire?
> I could switch off the scheduling timer, but it made no difference.
> The other timers running for other purposes I canot disable.
> An these fire more often.
> 
> Right now the server is running at 10% when doing nothing, not even checking
> schedules...
> After I did a service restart it drops to about 5%

Even it’s a service, running it with gprof enabled should be possible, no?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Separate release cycle for RTL and compiler proposal

[Florian Klämpfl via fpc-pascal]

> Am 19.04.2021 um 07:52 schrieb Karoly Balogh via fpc-pascal 
> :
> 
> Hi,
> 
> On Mon, 19 Apr 2021, Sven Barth via fpc-pascal wrote:
> 
>>> Am 18.04.2021 um 23:29 schrieb Zamrony P. Juhara via fpc-pascal:
>>> 
>>> I would like to propose to separate RTL release  from compiler release
>>> so that RTL bug fixes and features can be released with shorter release
>>> cycle. Is that possible?
>> 
>> No, the RTL and the compiler are tightly coupled.
>> 
>> What might be possible are further packages like the FCL and
>> interfaceing units, but the core RTL itself definitely not.
> 
> I think the need comes from the fact that the release cycle for the
> compiler is horribly long, which I tend to agree with. But I think this
> comes from the fact that the release for Tier 1 platforms is still mostly
> prepared manually.

I think the point is more to get a release where everything works and is 
tested. Running make into is no problem but the quality of the resulting 
installer might be less than that we currently have.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Separate release cycle for RTL and compiler proposal

[Florian Klämpfl via fpc-pascal]

> Am 19.04.2021 um 11:36 schrieb Michael Van Canneyt via fpc-pascal 
> :
> 
> 
> 
> On Mon, 19 Apr 2021, Jonas Maebe via fpc-pascal wrote:
> 
>> On 19/04/2021 11:28, Michael Van Canneyt via fpc-pascal wrote:
>>> On Mon, 19 Apr 2021, Jonas Maebe via fpc-pascal wrote:
 On 19/04/2021 09:28, Michael Van Canneyt via fpc-pascal wrote:
> 
> 
> From what you say, both problems are related to the tool you use. Are
> there no other tools that can be used ?
 
 The wrapping problem is unrelated to the tool, but to the console mode
 focus of our installation files. Such a manually formatted text file is
 simply unsuitable for a GUI installer.
>>> But if the tool didn't wordwrap, all would be OK, no ?
>> 
>> It's not the tool, it doesn't touch the files. It's the GUI of the
>> installer application, which shows a plain window that happens to be
>> slightly too narrow relative to our chosen line length (depending on the
>> kind of characters on the line, as it uses a proportional font).
> 
> So it's the MacOS installer window that does the wrapping ?
> being used to Inno Setup I automatically assumed the tool also does the
> GUI...
> 
> That explains it. Thanks.
> 

But couldn’t we just wrap ourself in all installers if needed? This should be a 
no brainer, no?

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Background info on Generics in FPC

[Florian Klämpfl via fpc-pascal]

> Am 17.04.2021 um 21:07 schrieb Graeme Geldenhuys via fpc-pascal 
> :
> 
> Hi
> 
> I'm looking at the wiki and official FPC language documentation. What was
> the reason for the decision to make the FPC syntax so verbose regarding
> Generics?

Same reason why we have 

a : array[0..10] of integer;

instead of

a : integer[0..10];

After all, using the keywords generic and specialize felt more pascalish to us.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Version 3.2.2 changes

[Florian Klämpfl via fpc-pascal]

> Am 08.04.2021 um 21:27 schrieb Jonas Maebe via fpc-pascal 
> :
> 
> On 08/04/2021 21:07, Peter via fpc-pascal wrote:
>> Does anyone have a link to useful list of changes or bug fixes for 3.2.2?
> 
> Unfortunately, no. In theory you could see it on
> https://bugs.freepascal.org/changelog_page.php (for the 3.2.1 version),
> but the "fix version" of most bug reports does not get updated when
> fixes are backported. I used to spend days on going through all merges
> and updating the merge revisions and fix versions when a release was
> nearing, but I no longer have time for that.

As this is most likely pretty useful, I am willing to work on it. Anybody else?

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Pascal Ardiono (avr) library

[Florian Klämpfl via fpc-pascal]

>>> 
>>> And then, afterwards, once code has been generated for the whole 'block', 
>>> the register-allocator fills in the registers. And store/restores them when 
>>> needed. This can be done using an algorithm that uses a tree to 'peel-down' 
>>> (is this English?) all the solutions. Just like is done with a 
>>> regular-expression parser.
>>> 
>>> Just dreaming. I don't have the time to work on it, and I don't even know 
>>> how it works at the moment. But that would seem to be the ideal solution to 
>>> me.
>> But this is how it is basically currently done?
> 
> But why do you need to redo the code generation? At the moment the real 
> registers are assigned, you do know if you need the y register for some 
> specific task, no?

Well, thinking about it, maybe yes with some hacky approach. The issue is: only 
after register allocation it is known if temps. for spilling are needed. If any 
local data is used (local vars, temps, temps for spilling etc) then a frame 
pointer is needed, and if spilling temps are needed is only known when register 
allocation is complete.___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Pascal Ardiono (avr) library

[Florian Klämpfl via fpc-pascal]

> Am 04.04.2021 um 15:36 schrieb Joost van der Sluis via fpc-pascal 
> :
> 
> 
> 
> Op 04-04-2021 om 13:33 schreef Florian Klämpfl via fpc-pascal:
>>> Am 04.04.2021 um 12:50 schrieb Joost van der Sluis via fpc-pascal 
>>> :
>>> 
>>> Isn't it at least a good practice to store self at Y. So we have Z free for 
>>> other calculations and can access members directly using ldd (),y+().
>>> 
>>> But maybe that's difficult?
>> Using Y might be indeed difficult as the compiler knows only after register 
>> allocation that it does not need Y for other purposes. It would basically 
>> require the ability to redo code generation.
> 
> In my head I've been thinking a lot about another register-allocator:
> 
> During the code-generation the code-generation only asks the 
> register-allocator 'I need a register now that cas capabilities X,Y and Z). 
> Or: give me the same register as I used last time.
> 
> And then, afterwards, once code has been generated for the whole 'block', the 
> register-allocator fills in the registers. And store/restores them when 
> needed. This can be done using an algorithm that uses a tree to 'peel-down' 
> (is this English?) all the solutions. Just like is done with a 
> regular-expression parser.
> 
> Just dreaming. I don't have the time to work on it, and I don't even know how 
> it works at the moment. But that would seem to be the ideal solution to me.

But this is how it is basically currently done?

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Pascal Ardiono (avr) library

[Florian Klämpfl via fpc-pascal]

> Am 04.04.2021 um 12:50 schrieb Joost van der Sluis via fpc-pascal 
> :
> 
> Isn't it at least a good practice to store self at Y. So we have Z free for 
> other calculations and can access members directly using ldd (),y+().
> 
> But maybe that's difficult?

Using Y might be indeed difficult as the compiler knows only after register 
allocation that it does not need Y for other purposes. It would basically 
require the ability to redo code generation.

But tracking the use of Z is indeed something I would like to implement already 
for a longer time.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Pascal Ardiono (avr) library

[Florian Klämpfl via fpc-pascal]

> Am 03.04.2021 um 19:49 schrieb Joost van der Sluis via fpc-pascal 
> :
> 
> Hi all,
> 
> During some spare free time I've ported parts of the Arduino AVR library to 
> Free Pascal. So now it is possible to use things like 'DigitalWrite' and 
> 'Delay'.
> 
> More info here: 
> https://lazarussupport.com/introducing-pasduino-the-pascal-avr-arduino-library/

You write that the assembler is far from ideal. Did you notice any problems in 
particular? Because in general it’s not that bad as long as one keeps in mind 
that one is working on a 8 bit systems where e.g. 32 bit integers hurt.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Is RV32I instruction set for RISC-V (embedded) supported?

[Florian Klämpfl via fpc-pascal]

> Am 10.03.2021 um 10:28 schrieb Bernd Mueller via fpc-pascal 
> :
> 
> On 3/5/21 6:22 PM, Florian Klämpfl via fpc-pascal wrote:
> 
>> It is not expected that it works as RiscV support is still work in
>> progress, but it should work ;) I'll look into it.
> 
> Thank you. For me, the compiler for RV32I/RV32IMAC works already pretty
> well.

Yes, the mul problem should be fixed meanwhile.

> 
> Regards, Bernd.
> 
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Cannot write datetime field on sqlite3 database on ARM

[Florian Klämpfl via fpc-pascal]

> Am 10.03.2021 um 04:59 schrieb Toru Takubo via fpc-pascal 
> :
> 
>> Can you please post the output of -va of the arm compiler and provide some 
>> information about the arm system you are using?
> 
> The output message with -va option can be downloaded from below.
> 
> http://support.e-parcel.ne.jp/downloads/tmp/fpc-va.txt
[0.016] (3101) Macro defined: CPUARMV4
[0.016] (3101) Macro defined: FPUFPA
I am not sure how this happened but you are compiling for an ancient arm 
architecture, this is not going to work. FPA uses a different floating point 
format so this explains the problems.

> 
> Target machine is Raspberry Pi OS on Raspberry Pi 3 Model B V1.2.
> 
> # uname -a
> Linux raspberrypi 5.4.51-v7+ #1327 SMP Thu Jul 23 10:58:46 BST 2020 armv7l 
> GNU/Linux
> 
> Best Regards,
> 
> Toru
> 
> 
> 
> 
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Cannot write datetime field on sqlite3 database on ARM

[Florian Klämpfl via fpc-pascal]

Am 09.03.21 um 01:47 schrieb Toru Takubo via fpc-pascal:

On 2021/03/08 16:54, Michael Van Canneyt via fpc-pascal wrote:



On Mon, 8 Mar 2021, Toru Takubo via fpc-pascal wrote:


Hi,

I am developing my app on Windows and building apps for other
platforms by using cross compiler. Now I have a problem only
occurred on Linux ARM.

The problem is that it cannot write datetime field on sqlite3
database. It can read/write other fields like int, varchar
or blob, but always write zero in datetime (maybe float as well)
field.

Does anyone have an idea about this issue? I am not sure it is
fpc issue, but better to report bug?


It sounds like a floating point problem. As you probably know, a 
TDateTime

type is actually a double type. Did you try with a float value ?

The DB explorer tools probably just use strings to read/write from the
database, so they will not be bothere by such things, but FPC stores 
dataset

values in 'native' formats in memory.

I don't know what to advise to further investigate the issue, One 
thing to
try would be to test whether normal float arithmetic or date 
arithmetic works.

If not, then the compiler people will need to give more advice.



I created a simple test code, and ran on linux-i386 and linux-arm.


Can you please post the output of -va of the arm compiler and provide 
some information about the arm system you are using?

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Unicode chars losing information

[Florian Klämpfl via fpc-pascal]

> Am 09.03.2021 um 10:06 schrieb Michael Van Canneyt via fpc-pascal 
> :
> 
> 
> 
>> On Tue, 9 Mar 2021, Graeme Geldenhuys via fpc-pascal wrote:
>> 
>>> On 09/03/2021 1:44 am, Tomas Hajny via fpc-pascal wrote:
>>> UnicodeString may be used in a program simply because the included unit has 
>>> it used in its interface. That may be the case even if there's no use of 
>>> characters outside of US ASCII at all.
>> 
>> So FPC rather goes with the fact that data may be *silently* lost during
>> encoding conversions? That doesn't seem like a safe default behaviour to
>> me.
> 
> No, we give the programmer a choice: * Not use unicode conversion at all.
> * Use the C library to handle conversion (cwstring).
> * Use FPC native code to handle conversion (fpwidestring).
> * Some other means.
> 
> Since the compiler cannot reliably detect that a choice was made, it also 
> cannot make the choice for you, because the choice also cannot be undone by 
> the compiler.
> 
> This mechanism implies the programmer *has* to make that choice.
> 
> This is not different from the threading driver mechanism, for which Lazarus 
> adds
> some {$IFDEF } mechanisms in the program uses clause.
> 
> But, I have been thinking about this. What we can do to alleviate this is the 
> following:
> 
> Use the -FaNNN option of the command line.
> 
> This option will insert NNN implicitly in the uses clause of the program.
> 
> So, we can add -Fafpwidestring
> or
> -Facwstring
> 
> in the default generated fpc.cfg config file for selected platforms (mac, 
> linux
> i386,64-bit, *bsd). The result will be that a widestring driver unit will be 
> inserted by default for those platforms.
> 
> By using the necessary IFDEF mechanism in the config file, we can avoid
> inserting it for windows (which does not need it) or the smaller embedded 
> platforms
> (which cannot handle it).
> 
> People that don't need/want this can remove the config setting from the file. 
> All the others leave it as-is and will get their desired conversion mechanisms
> 'for free'.
> 
> This way a default choice is made for you on those platforms, but you can 
> still 100% control
> it.

I am very much against this because this means that a default FPC executable 
would link against libc. And this is far too much only because a few people 
complain because they didn’t read the docs.

> 
> Michael.
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Is RV32I instruction set for RISC-V (embedded) supported?

[Florian Klämpfl via fpc-pascal]

Am 06.03.21 um 13:56 schrieb Bernd Mueller via fpc-pascal:

I saw your changes in revision 48881, downloaded latest trunk, compiled
with
make crosszipinstall CPU_TARGET=riscv32 OS_TARGET=embedded SUBARCH=rv32i

but the problem remains:

make[4]: Entering directory '/home/bernd/fpc/fpc331/48882/src/rtl/embedded'
/bin/mkdir -p /home/bernd/fpc/fpc331/48882/src/rtl/units/riscv32-embedded
/home/bernd/fpc/fpc331/48882/src/compiler/ppcrossrv32 -Ur -Cprv32i
-Tembedded -Priscv32 -XPriscv32-embedded- -Ur -Xs -O2 -n -Fi../inc
-Fi../riscv32 -FE.
-FU/home/bernd/fpc/fpc331/48882/src/rtl/units/riscv32-embedded
-Fl/home/bernd/riscv/riscv_2008/lib/gcc/riscv64-unknown-elf/10.1.0/rv64imafdc/lp64d 


-driscv32 -dRELEASE -al  -Us -Sg system.pp @system.cfg
/home/bernd/fpc/fpc331/48882/src/rtl/units/riscv32-embedded/system.s:
Assembler messages:
/home/bernd/fpc/fpc331/48882/src/rtl/units/riscv32-embedded/system.s:39578:
Error: unrecognized opcode `mul x11,x11,x10'
...
system.pp(311) Error: Error while assembling exitcode 1
system.pp(311) Fatal: There were 2 errors compiling module, stopping

The compiler still seems to produce mul opcodes.



Yes, it is not finished yet :)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Is RV32I instruction set for RISC-V (embedded) supported?

[Florian Klämpfl via fpc-pascal]

Am 05.03.21 um 10:41 schrieb Bernd Mueller via fpc-pascal:

Hello,

I would like to use fpc to program a FPGA softcore RISC-V cpu. The
softcore has the RV32I instruction set implemented.

I modified the Makefile in rtl/embedded, so that the known SUBARCH
rv32imac replaces the option -Cprv32imac with now -Cprv32i.  But this
leads to the following error message, when I try to compile the
crosscompiler/rtl:

/home/bernd/fpc/fpc331/48875/src/compiler/ppcrossrv32 -Ur -Cprv32i
-Tembedded -Priscv32 -XPriscv32-embedded- -Ur -Xs -O2 -n -Fi../inc
-Fi../riscv32 -FE.
-FU/home/bernd/fpc/fpc331/48875/src/rtl/units/riscv32-embedded
-Fl/home/bernd/riscv/riscv_2008/lib/gcc/riscv64-unknown-elf/10.1.0/rv64imafdc/lp64d 


-driscv32 -dRELEASE -al  -Us -Sg system.pp @system.cfg
/home/bernd/fpc/fpc331/48875/src/rtl/units/riscv32-embedded/system.s:
Assembler messages:
/home/bernd/fpc/fpc331/48875/src/rtl/units/riscv32-embedded/system.s:39578:
Error: unrecognized opcode `mul x11,x11,x10'

Is this expected, since RV32I is not supported, or should this work?


It is not expected that it works as RiscV support is still work in 
progress, but it should work ;) I'll look into it.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] 50 Years of Pascal

[Florian Klämpfl via fpc-pascal]

Am 24.02.21 um 17:50 schrieb Liam Proven via fpc-pascal:

I thought this might interest folks. Apologies if I am late to the party.

https://cacm.acm.org/magazines/2021/3/250705-50-years-of-pascal/fulltext



I didn't know, thanks for the heads up :-)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Windows Defender considers fp.exe a malicious program

[Florian Klämpfl via fpc-pascal]

> I've also noticed that if you have any timing routines in your code, it tends 
> to get flagged by virus scanners.  No clue why, but I've run afoul of that 
> issue more than once.
> 
Debugger detection?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Compilation speed on Apple M1

[Florian Klämpfl via fpc-pascal]

> Am 22.11.2020 um 11:45 schrieb Michael Van Canneyt via fpc-pascal 
> :
> 
> 
> 
>> On Sun, 22 Nov 2020, Florian Klämpfl via fpc-pascal wrote:
>> 
>>> Am 21.11.2020 um 12:54 schrieb Tobias Giesen via fpc-pascal:
>>> Hello,
>>> first and foremost, many thanks to the creators and contributors of FPC
>>> and Lazarus, who enabled me to release my product natively for Apple
>>> Silicon only one day after receiving an M1 Mac. Fantastic work! FPC and
>>> Lazarus both run natively and work very well.
>>> According to Geekbench, the single core performance on the new Mac is
>>> around 1.8x as fast as my Intel Mac. Multicore is also much faster. I
>>> wonder why I don't see the speed increase in compiling though. Yes I am
>>> using different FPC and XCode versions, but I wonder what else could
>>> have an influence? My project is very large and not divided into
>>> packages, so I frequently need to recompile the whole project.
>>> I would be most grateful for any performance tips.
>> 
>> In r47526, I implemented support of the prefetch intrinsic on aarch64. On my 
>> Raspi4 it reduced make cycle time by 25 % (!). I would be very interested to 
>> get numbers for the M1.
> 
> 25% ?!

Yes. I were also baffled and tested several times but numbers didn‘t change. 
This is why I would like to see numbers from others.

> 
> Well... If the compiler can make such a difference,

This are the big low hanging fruits, their are only a few :) In particular the 
compiler benefits a lot from this as it iterates linked lists a lot.

> should we still bother with micro-optimizations in code then ?

I am always against micro-optimising code, this should do the compiler though 
prefetch is also a matter of inserting the intrinsic in your code. FPC can do 
this automatically but so far it is disabled as it is overall not beneficial.

> 
> Michael.___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Compilation speed on Apple M1

[Florian Klämpfl via fpc-pascal]

Am 21.11.2020 um 12:54 schrieb Tobias Giesen via fpc-pascal:

Hello,

first and foremost, many thanks to the creators and contributors of FPC
and Lazarus, who enabled me to release my product natively for Apple
Silicon only one day after receiving an M1 Mac. Fantastic work! FPC and
Lazarus both run natively and work very well.

According to Geekbench, the single core performance on the new Mac is
around 1.8x as fast as my Intel Mac. Multicore is also much faster. I
wonder why I don't see the speed increase in compiling though. Yes I am
using different FPC and XCode versions, but I wonder what else could
have an influence? My project is very large and not divided into
packages, so I frequently need to recompile the whole project.

I would be most grateful for any performance tips.


In r47526, I implemented support of the prefetch intrinsic on aarch64. On my Raspi4 it reduced make cycle time by 25 % 
(!). I would be very interested to get numbers for the M1.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Compilation speed on Apple M1

[Florian Klämpfl via fpc-pascal]

Am 21.11.20 um 17:29 schrieb Ryan Joseph via fpc-pascal:




On Nov 21, 2020, at 9:23 AM, Florian Klämpfl via fpc-pascal 
 wrote:

All. FPC typically uses several ten MBs and accesses it rather randomly.


Wow 10-100 MB is enough to limit speed due to memory access times? I understand 
there is some limit to how much memory can be accessed per X period of time but 
I thought it was measured in GB before getting penalties. Shows what I know. :)


L1 cache is typically only a few ten kB, L2 several hundred kB, L3 
several MB.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Compilation speed on Apple M1

[Florian Klämpfl via fpc-pascal]

Am 21.11.20 um 17:22 schrieb Ryan Joseph via fpc-pascal:



What are the plans for the native code generator if it's being outperformed by 
the LLVM backend?


Only the generated code is a little bit faster. The compiler using LLVM 
is ~10 times slower.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Compilation speed on Apple M1

[Florian Klämpfl via fpc-pascal]

Am 21.11.20 um 17:07 schrieb Ryan Joseph via fpc-pascal:




On Nov 21, 2020, at 6:15 AM, Florian Klämpfl via fpc-pascal 
 wrote:

Large parts of FPC are memory throughput limited so I suspect the M1 is not 
that much better in this regard, not to mention that most likely the AAarch 
code generator is worse than the x86 one. x86 received a lot of work in this 
field.


What does that mean exactly to be "memory throughput limited"? What part of the 
compilation process does this affect exactly?



All. FPC typically uses several ten MBs and accesses it rather randomly.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Compilation speed on Apple M1

[Florian Klämpfl via fpc-pascal]

Am 21.11.2020 um 12:54 schrieb Tobias Giesen via fpc-pascal:


According to Geekbench, the single core performance on the new Mac is
around 1.8x as fast as my Intel Mac. Multicore is also much faster. I
wonder why I don't see the speed increase in compiling though. Yes I am
using different FPC and XCode versions, but I wonder what else could
have an influence? My project is very large and not divided into
packages, so I frequently need to recompile the whole project.


Large parts of FPC are memory throughput limited so I suspect the M1 is not that much better in this regard, not to 
mention that most likely the AAarch code generator is worse than the x86 one. x86 received a lot of work in this field.


Maybe it's possible that you build using an LLVM compiler the FPC with native backend. As I do not use macOS, I have no 
clue how to do this though.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal