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

Re: [fpc-pascal] Worse performance with 64bit binary

[Florian Klämpfl]

Am 25.07.20 um 16:49 schrieb Gabor Boros:

Hi All,

I cannot show the real application but attached a simple example.
If compile with 3.2.0 "ppc386.exe -O3 test.pas" the execution time of 
the resulting example binary is 0.4s, and 2.2s if compile with 
"ppcx64.exe -O3 test.pas". Any idea why?


Missed optimization. I fixed it in trunk.

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

Re: [fpc-pascal] FPC for Win64

[Florian Klämpfl]

Am 05.07.20 um 09:04 schrieb Jonas Maebe:

On 2020-07-02 22:30, Evert van Dijken via fpc-pascal wrote:

I like to use the 64 bits FPC compiler, but I cannot find any 
documentation how to use it. I see a WIN32 compiler and a WIN64 cross 
compiler. How it works is a mystery for me. Can I still use the 
debugger and the development environment?


You should install both fpc-3.2.0.i386-win32.exe and 
fpc-3.2.0.i386-win32.cross.x86_64-win64.exe. The fact that that the 
Win64 compiler is a cross-compiler should not affect you at all in terms 
of using it. You can indeed still use the debugger. I don't know whether 
a version of the textmode IDE is included for targeting Win64.


No. But at least at libgdb I got the debugger never working, so it made 
no sense to me.

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

Re: [fpc-pascal] Question about compiling FPC trunk after revision 44849

[Florian Klämpfl]

Am 29.04.20 um 21:12 schrieb Marco van de Voort:


Op 2020-04-29 om 19:50 schreef Jonas Maebe:


Yes, but you cannot use "clean" and "all" in the same make invocation.
This was in fact never supported, and did not work on all platforms 
either.


So simply split it:

make -j 9 clean
make -j 9 all install

Does "clean" have a valid return value of make, or is it better ignored?


I run all of my scripts with set -e, so it should work.

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

Re: [fpc-pascal] Wiki Image Database Corruption

[Florian Klämpfl]

Am 12.04.20 um 03:28 schrieb Trev:


I've been trying to attract the attention of someone/anyone with virtual 
access to the Wiki webserver to fix the corrupted image database since 
January.


I've tried (in order):

* Wiki Feedback page: https://wiki.freepascal.org/Site_Feedback
* Forums: https://forum.lazarus.freepascal.org/index.php/topic,48428.0.html
* Bugtracker: https://bugs.freepascal.org/view.php?id=36784

all to no avail. This mailing list was suggested as the last chance saloon.


I fear the problem is nobody knows what to do :( Nevertheless, the 
mailing lists are not the last but the best resort ;)


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

Re: [fpc-pascal] Error format question

[Florian Klämpfl]

Am 11.04.20 um 08:11 schrieb Ryan Joseph via fpc-pascal:

Sorry to ask this yet again but I keep forgetting or remembering wrong. I 
thought this was a one time error that was fixed but I'm still getting 
different error formats with the trunk (as of today) vs 3.0.4.

Can anyone please confirm which it the correct format I should rely on?


Ryans-MacBook-Pro-2:~ ryanjoseph$ fpc -vbr 
/Users/ryanjoseph/Developer/Projects/FPC/Various/stratch_pad.pas
Free Pascal Compiler version 3.0.4 [2018/09/30] for x86_64
Copyright (c) 1993-2017 by Florian Klaempfl and others
Target OS: Darwin for x86_64
Compiling /Users/ryanjoseph/Developer/Projects/FPC/Various/stratch_pad.pas
/Users/ryanjoseph/Developer/Projects/FPC/Various/stratch_pad.pas:6: error: 1: Identifier 
not found "f"
/Users/ryanjoseph/Developer/Projects/FPC/Various/stratch_pad.pas:7: error: 4: 
There were 1 errors compiling module, stopping
error: Compilation aborted
Ryans-MacBook-Pro-2:~ ryanjoseph$ /usr/local/lib/fpc/3.3.1/ppcx64 -vbr 
/Users/ryanjoseph/Developer/Projects/FPC/Various/stratch_pad.pas
Free Pascal Compiler version 3.3.1 [2020/04/11] for x86_64
Copyright (c) 1993-2020 by Florian Klaempfl and others
Target OS: Darwin for x86_64
Compiling /Users/ryanjoseph/Developer/Projects/FPC/Various/stratch_pad.pas
/Users/ryanjoseph/Developer/Projects/FPC/Various/stratch_pad.pas:6:1: error: Identifier 
not found "f"
/Users/ryanjoseph/Developer/Projects/FPC/Various/stratch_pad.pas:7:4: error: 
There were 1 errors compiling module, stopping
error: Compilation aborted


I fixed this for trunk. You can very easily test and see what gcc 
outputs to verify what's correct.

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

Re: [fpc-pascal] [OT] inline procedures in TP 7.0

[Florian Klämpfl]

Am 17.02.20 um 12:31 schrieb Anton Shepelev via fpc-pascal:

Florian Klampfl to Anton Shepelev:


What about the other registers -- does Turbo Pascal take
care of them, perhaps enveloping each expansion of an
inline procedure into a POPs and PUSHes?


No.


Thank you for the reply, Florian.  Does that mean that I
must take utmost care to preserve every single register when
using inline procedures and functions?



No. The other way round, except sp and bp, you do not have to take care 
of any register.

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

Re: [fpc-pascal] fpmmap arm-linux issue

[Florian Klämpfl]

Am 01.02.20 um 18:13 schrieb je...@j-software.dk:
Agreed, the rtl should definitely divide by pagesize if MMAP2 is 
defined. I've run into this discrepancy before on ARM at work


I have fixed it meanwhile.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] [OT] inline procedures in TP 7.0

[Florian Klämpfl]

Am 16.02.20 um 22:28 schrieb Anton Shepelev via fpc-pascal:


But which registers shall be preserved by inline proceudres
and functions?


IIRC (it is 25 years ago :)): sp and bp


 In this example from the manual, the SP
register is not preserved within the statement:


It is reset to it's value before the parameters were pushed.



 function LongMul(X, Y: Integer): Longint;
 inline (
 $5A/{POP  AX}
 $58/{POP  DX}
 $F7/$EA);   {IMUL DX}

Does it mean it shall reset SP to a position before the
parameters? 


Yes. TP calling conventions means the callee (in this case the inline 
code) clears the stack (remove parameters).



What about the other registers -- does Turbo
Pascal take care of them, perhaps enveloping each expansion
of an inline procedure into a POPs and PUSHes?



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

Re: [fpc-pascal] Best start point for adding new FPC target

[Florian Klämpfl]

Am 28.01.20 um 20:40 schrieb Yuriy Sydorov:

On 28.01.2020 21:14, Fabio Luis Girardi via fpc-pascal wrote:
Em ter., 28 de jan. de 2020 às 16:04, Yuriy Sydorov > escreveu:


    You need to add support of a new CPU to the existing freebsd 
target. The target would be arm-freebsd, since armhf is

    not
    treated as a separate CPU by FPC. You need to create arm startup 
files in the rtl/freebsd/arm folder.



Yes, I know. But to add this new CPU support for the FPC/FreeBSD, it 
is better I start with files of rtl/freebsd/i386 or rtl/freebsd/x86_64 
or use another start point, like rtl/netbsd/arm ?


The primary goal of a startup code is to get pointers to the command 
line parameters and the environment block. If arm-freebsd uses the stack 
to pass these pointers (the same way as i386-freebsd), then you need 
just to convert the i386 startup assembly to the arm assembly.

For start you need only the prt0.as file.



I strongly recommend to create pascal startup files for newly added targets.

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

Re: [fpc-pascal] Error format changes between compilers

[Florian Klämpfl]

Am 30.12.2019 um 17:08 schrieb Ryan Joseph via fpc-pascal:

Notice how the format of the error changes between ppcrossx64 (built for iPhone 
simulator) and ppcx64. Is this a bug? It broke my regex for capturing errors 
and that's why I'm asking btw.


The old syntax was wrong, some days ago I fixed it, see also the different 
dates of your compilers.




Ryans-MacBook-Pro-2:fpc-git ryanjoseph$ /usr/local/lib/fpc/3.3.1/ppcrossx64 
-Tiphonesim -vbr 
/Users/ryanjoseph/Developer/Projects/FPC/CocoaTouchExamples/test.pas
Free Pascal Compiler version 3.3.1 [2019/12/28] for x86_64
Copyright (c) 1993-2019 by Florian Klaempfl and others
Target OS: Darwin/iPhoneSim for x86_64
Compiling /Users/ryanjoseph/Developer/Projects/FPC/CocoaTouchExamples/test.pas
/Users/ryanjoseph/Developer/Projects/FPC/CocoaTouchExamples/test.pas:4:2: error: Syntax error, 
"BEGIN" expected but "identifier F" found
error: Compilation aborted


Ryans-MacBook-Pro-2:output ryanjoseph$ /usr/local/lib/fpc/3.3.1/ppcx64 -vbr 
/Users/ryanjoseph/Developer/Projects/FPC/CocoaTouchExamples/test.pas
Free Pascal Compiler version 3.3.1 [2019/11/26] for x86_64
Copyright (c) 1993-2019 by Florian Klaempfl and others
Target OS: Darwin for x86_64
Compiling /Users/ryanjoseph/Developer/Projects/FPC/CocoaTouchExamples/test.pas
/Users/ryanjoseph/Developer/Projects/FPC/CocoaTouchExamples/test.pas:4: error: 2: Syntax error, 
"BEGIN" expected but "identifier F" found
error: Compilation aborted
Ryans-MacBook-Pro-2:output ryanjoseph$

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] Two possible generics bugs

[Florian Klämpfl]

Am 30.11.19 um 18:51 schrieb Sven Barth via fpc-pascal:

Am 28.11.2019 um 16:14 schrieb Ryan Joseph via fpc-pascal:

{$mode objfpc}

program test;
uses
   FGL;

// Type identifier expected
// Internal error 2019112401
generic function CopyList(source: specialize 
FGL.TFPGObjectList): specialize FGL.TFPGObjectList;

begin
end;

begin
end.

What option did you use to compile it? What platform did you use? Cause 
I can't reproduce the internal error...


r43612 | florian | 2019-11-29 23:13:17 +0100 (Fr, 29. Nov 2019) | 1 Zeile

  * better error recovery, resolves #36377

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

Re: [fpc-pascal] get_caller_frame

[Florian Klämpfl]

Am 20.11.19 um 07:56 schrieb Sven Barth via fpc-pascal:
Ryan Joseph via fpc-pascal > schrieb am Mi., 20. Nov. 2019, 
04:36:


I came across get_caller_frame  in some unrelated code and I was
just curious about this so I wanted to ask.

What does get_caller_frame return exactly? Is this a pointer to a
stack frame that could be copied to the heap? I'm still interested
in how we could add some form of coroutine like behaviors to pascal
and so I was wondering if we could copy/restore the current stack
pointer so that SetJmp and LongJmp would not blow things up.


It returns the address of the caller's frame pointer. See also 
https://www.freepascal.org/docs-html/rtl/system/get_caller_frame.html


It's mainly used in context of raising exceptions with the help of a 
second function. See here: 
https://freepascal.org/docs-html/current/ref/refse112.html#x227-24900017.1


For the record: the reliability of this function is limited, in 
particular in combination with optimization.


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

Re: [fpc-pascal] FPC_CURRENCY_IS_INT64

[Florian Klämpfl]

Am 14.10.19 um 19:40 schrieb LacaK:

So it is safe to assume that in memory is Currency always stored as 
Int64 on Win32, Win64?


Yes. To get it's value, divide it by 1
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] ppc64le ABI problem

[Florian Klämpfl]

Am 27. August 2019 15:03:46 schrieb tobiasgie...@gmail.com:

> Hello,
>
> yes I will send you a minimal program to call XGetWindowProperty.
>
> Cheers,
> Tobias
>
> 
>
> On Tue, 27 Aug 2019 11:35:01 +0200
> Pierre Muller  wrote:
>
>> Hi,
>>
>>
>> the testsuite results show no difference,
>> this probably means that we have no test that checks
>> GCC compatibility for more than 8 parameters...
>>
>>
>> Tobias, could you send us a small source that allows to check this?

I think we should extend tcalext with a test for more parameters.


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

Re: [fpc-pascal] ppc64le ABI problem

[Florian Klämpfl]

Am 26. August 2019 14:08:39 schrieb Sven Barth via fpc-pascal 
:

> Florian Klämpfl  schrieb am Mo., 26. Aug. 2019,
> 14:01:
>
>> Am 26. August 2019 00:59:16 schrieb tobiasgie...@gmail.com:
>>
>>> Hello,
>>>
>>>
>>>
>>>
>>> while examining a crash when running Lazarus on ppc64le, I found the
>>> following issue in function calls.
>>>
>>>
>>>
>>>
>>> Calls to functions with more than eight parameters seem to be
>>> implemented differently from how gcc does it in a C program.
>>>
>>>
>>>
>>>
>>> gcc uses the memory location 96(r1) for the ninth parameter, but FPC
>>> uses 112(r1).
>>>
>>>
>>>
>>>
>>> Therefore, calls to XGetWindowProperty crash. This function has 12
>>> parameters. gcc puts the four last ones into  96(r1), 104(r1), 112(r1),
>> 120(r1),
>>> and FPC into 112(r1), 120(r1), 128(r1), 136(r1).
>>>
>>>
>>>
>>>
>>> What can be done about this?
>>
>> Try to change the 48 in fpc/compiler/powerpc64/cpupara.pas line to 32 as a
>> temporary test.
>
> Line 302 in case anyone is wondering (thankfully that's the only "48" in
> that fike (plus its preceeding comment) ^^')

Indeed :-) If it works, it must be made dependent on the target ABI.


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

Re: [fpc-pascal] ppc64le ABI problem

[Florian Klämpfl]

Am 26. August 2019 00:59:16 schrieb tobiasgie...@gmail.com:

> Hello,
>
>
> while examining a crash when running Lazarus on ppc64le, I found the
> following issue in function calls.
>
>
> Calls to functions with more than eight parameters seem to be
> implemented differently from how gcc does it in a C program.
>
>
> gcc uses the memory location 96(r1) for the ninth parameter, but FPC
> uses 112(r1).
>
>
> Therefore, calls to XGetWindowProperty crash. This function has 12
> parameters. gcc puts the four last ones into  96(r1), 104(r1), 112(r1), 
> 120(r1),
> and FPC into 112(r1), 120(r1), 128(r1), 136(r1).
>
>
> What can be done about this?

Try to change the 48 in fpc/compiler/powerpc64/cpupara.pas line to 32 as a 
temporary test.

>
>
> I also noticed that the "file" command in Linux mentioned an additional
> property of the linked C program I wrote for testing:
> "for GNU/Linux 3.10.0"
>
>
> The FPC program did not have this tag.
>
>
> The complete "file" outputs are:
>
>
> a.out: ELF 64-bit LSB shared object, 64-bit PowerPC or cisco 7500, version
> 1 (SYSV), dynamically linked, interpreter /lib64/ld64.so.2,
> BuildID[sha1]=6c5d2b5c7408e74eeda95fbf8d120fe8de0f2f30, for GNU/Linux
> 3.10.0, with debug_info, not stripped
>
>
> minimalxcrash: ELF 64-bit LSB executable, 64-bit PowerPC or cisco 7500,
> version 1 (SYSV), dynamically linked, interpreter /lib64/ld64.so.2, with
> debug_info, not stripped
>
>
> Hoping my find will be useful,
> Best wishes,
> Tobias Giesen
>
>
> ___
> 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] server up?

[Florian Klämpfl]

Am 15.06.2019 um 15:19 schrieb Ryan Joseph:
> Is the fpc-devel server back up yet? I’m not seeing new messages getting 
> posted.

Just tested, works.

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

Re: [fpc-pascal] mode switch madness

[Florian Klämpfl]

Am 14.04.2019 um 04:07 schrieb Ben Grasset:
> I dunno about setting them globally, but generally I do find modeswitches 
> rather annoying, as the combination of
> features is pretty arbitrary, and they mostly just *disallow* things that 
> couldn't break the code of people who weren't
> using those features to begin with if they were allowed.

It helps a lot to force a certain programming style.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] *.rst vs *.rsj

[Florian Klämpfl]

Am 06.03.19 um 22:09 schrieb Graeme Geldenhuys:

Hi,

Somewhere after FPC 2.6.4 the FPC compiler changed to generating JSON
based *.rsj files for resource strings.

1.  What was the benefit of doing that? After all, FPC always prides
itself in not breaking backward compatibility (Florian and others have
said that many times), yet now FPC has done just that.


You had the same discussion years ago with Jonas, conclusion: 
http://lists.freepascal.org/pipermail/fpc-pascal/2016-July/048264.html

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

Re: [fpc-pascal] "crtbegin.o" not found

[Florian Klämpfl]

Am 03.01.19 um 18:31 schrieb Bart:

I put it on my user page on the wiki:
http://wiki.lazarus.freepascal.org/User:Bart#Notes_for_myself

Maybe there's an appropriate page it can gi into.


I added it to the explanation of the compiler error.

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

Re: [fpc-pascal] Rest in peace Martin Schreiber

[Florian Klämpfl]

Am 27.12.2018 um 00:49 schrieb Graeme Geldenhuys:
> Hi everybody,
> 
> Today I became aware of very sad news. Martin Schreiber, author of the
> MSEide+MSEgui project, has unexpected succumbed of cardiac arrest on 29
> November 2018. 

Sad to hear. All the best to his family and friends.

Rest in peace Martin.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Building trunk

[Florian Klämpfl]

Am 25.11.2018 um 14:30 schrieb Colin Western:
> What generates the header? Is it fpc, an external linker or the loader?
> 

Can you please run the following C program:

#include 
#include 

int main()
{
  printf("AT_PHDR: %lx\n",getauxval(AT_PHDR));
  printf("AT_PHNUM: %lx\n",getauxval(AT_PHNUM));
}

and include also the relevant part of an objdump?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Building trunk

[Florian Klämpfl]

Am 25.11.2018 um 13:58 schrieb Jonas Maebe:
> On 25/11/18 13:51, Florian Klämpfl wrote:
>> I am not aware that somewhere a fixed offset is applied. All info is read 
>> from the auxiliary data and the header.
> 
> You can have a load address offset in case there is a PT_PHDR. 

Yes.

> From http://www.gabriel.urdhr.fr/2015/01/22/elf-linking/ :
> 
> // Simplified code from the GNU dynamic linker source code:
> for (ph = phdr; ph < [phnum]; ++ph)
>   if (ph->p_type == PT_PHDR)
>     main_map->l_addr = (ElfW(Addr)) phdr - ph->p_vaddr;
> 
> There doesn't seem to be one in Colin's program though.

Indeed. The program header itself seems to be wrong/interpreted wrong.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Building trunk

[Florian Klämpfl]

Am 25.11.2018 um 13:51 schrieb Florian Klämpfl:
> Am 25.11.2018 um 13:06 schrieb C Western:
>>>>> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
>>>>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>>>> That gives the same value as shown above, even after applying the patch. 
>>>> Single stepping the code indicates that both
>>>> variables are assigned: (Some lines deleted).
>>> This is pretty strange then. This code is pretty simple and in general, tls 
>>> initialization should be done regardless if
>>> FPC uses it for threadvars or not. What version of Fedora are you using?
>>> ___
>>> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
>>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>>
>> Fedora 29 (64 bit). Did you see my other message in the thread about a 
>> different offset in program header when compiled
>> under Fedora and Ubuntu? (It works on Ubuntu). It is though an offset needs 
>> to be applied to find the program header,
>> but I can't see where to find it.
> 
> I am not aware that somewhere a fixed offset is applied. All info is read 
> from the auxiliary data and the header.
> 

You mean the offset field in the header? I cannot imaging how the offset in the 
header could influence the header itself?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Building trunk

[Florian Klämpfl]

Am 25.11.2018 um 13:06 schrieb C Western:
 fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>>> That gives the same value as shown above, even after applying the patch. 
>>> Single stepping the code indicates that both
>>> variables are assigned: (Some lines deleted).
>> This is pretty strange then. This code is pretty simple and in general, tls 
>> initialization should be done regardless if
>> FPC uses it for threadvars or not. What version of Fedora are you using?
>> ___
>> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
> 
> Fedora 29 (64 bit). Did you see my other message in the thread about a 
> different offset in program header when compiled
> under Fedora and Ubuntu? (It works on Ubuntu). It is though an offset needs 
> to be applied to find the program header,
> but I can't see where to find it.

I am not aware that somewhere a fixed offset is applied. All info is read from 
the auxiliary data and the header.

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

Re: [fpc-pascal] Building trunk

[Florian Klämpfl]

Am 25.11.2018 um 12:20 schrieb C Western:
> On 24/11/2018 22:21, Florian Klämpfl wrote:
>> Am 24.11.2018 um 10:08 schrieb C Western:
>>> On 23/11/2018 09:50, Sven Barth via fpc-pascal wrote:
>>>> Am Fr., 23. Nov. 2018, 10:26 hat C Western >>> <mailto:l...@c-m-w.me.uk>> geschrieben:
>>>>
>>>>  I haven't been able to build trunk i386 fpc for a couple of weeks. Is
>>>>  this supposed to be working, or have I misconfigured something? (I
>>>>  don't
>>>>  think I have changed anything.) The output is below. I don't think
>>>>  it is
>>>>  significant, but I am building on a 64 bit system, but with a 32 bit
>>>>  starting compiler. (The 64 bit build with the 64 bit starting
>>>>  compiler
>>>>  works fine.)
>>>>
>>>>
>>>> We have i386 trunk building on at least one x86_64-linux machine, so it 
>>>> can't be a principal problem. :/
>>>> Could you check whether it's FPC itself that segfaults or something else 
>>>> and if the former try to retrieve a
>>>> stacktrace, please?
>>>>
>>>> Regards,
>>>> Sven
>>>>
>>>> ___
>>>> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
>>>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>>> Looks like the ppc1 compiler crashes during setup:
>>>
>>> gdb) run
>>> Starting program: /home/me/fpc/trunk/fpcsrc/compiler/ppc1
>>>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x08068760 in INITTLS () at system.pp:543
>>> 543        case phdr^.p_type of
>>> (gdb) bt
>>> #0  0x08068760 in INITTLS () at system.pp:543
>>> #1  0x082a63fb in _FPC_PROC_START () at ./i386/si_prc.inc:105
>>> (gdb) p phdr
>>> $1 = (PPHDR) 0x8048034
>>> (gdb) p phdr^
>>> Cannot access memory at address 0x8048034
>> Can you please check what value phdr has at the crash location after 
>> applying the following patch?
>>
>> diff --git a/rtl/linux/system.pp b/rtl/linux/system.pp
>> index 0d7ed2b152..74b4592ace 100644
>> --- a/rtl/linux/system.pp
>> +++ b/rtl/linux/system.pp
>> @@ -525,6 +525,8 @@ procedure InitTLS; [public,alias:'FPC_INITTLS'];
>>   while assigned(auxp^) do
>>     inc(auxp);
>>   inc(auxp);
>> +    phdr:=nil;
>> +    phnum:=0;
>>   { now we are at the auxillary vector }
>>   while assigned(auxp^) do
>>     begin
>> ___
>> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
> 
> That gives the same value as shown above, even after applying the patch. 
> Single stepping the code indicates that both
> variables are assigned: (Some lines deleted).

This is pretty strange then. This code is pretty simple and in general, tls 
initialization should be done regardless if
FPC uses it for threadvars or not. What version of Fedora are you using?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Building trunk

[Florian Klämpfl]

Am 24.11.2018 um 10:08 schrieb C Western:
> On 23/11/2018 09:50, Sven Barth via fpc-pascal wrote:
>> Am Fr., 23. Nov. 2018, 10:26 hat C Western > > geschrieben:
>>
>>     I haven't been able to build trunk i386 fpc for a couple of weeks. Is
>>     this supposed to be working, or have I misconfigured something? (I
>>     don't
>>     think I have changed anything.) The output is below. I don't think
>>     it is
>>     significant, but I am building on a 64 bit system, but with a 32 bit
>>     starting compiler. (The 64 bit build with the 64 bit starting
>>     compiler
>>     works fine.)
>>
>>
>> We have i386 trunk building on at least one x86_64-linux machine, so it 
>> can't be a principal problem. :/
>> Could you check whether it's FPC itself that segfaults or something else and 
>> if the former try to retrieve a
>> stacktrace, please?
>>
>> Regards,
>> Sven
>>
>> ___
>> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
> 
> Looks like the ppc1 compiler crashes during setup:
> 
> gdb) run
> Starting program: /home/me/fpc/trunk/fpcsrc/compiler/ppc1
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x08068760 in INITTLS () at system.pp:543
> 543        case phdr^.p_type of
> (gdb) bt
> #0  0x08068760 in INITTLS () at system.pp:543
> #1  0x082a63fb in _FPC_PROC_START () at ./i386/si_prc.inc:105
> (gdb) p phdr
> $1 = (PPHDR) 0x8048034
> (gdb) p phdr^
> Cannot access memory at address 0x8048034

Can you please check what value phdr has at the crash location after applying 
the following patch?

diff --git a/rtl/linux/system.pp b/rtl/linux/system.pp
index 0d7ed2b152..74b4592ace 100644
--- a/rtl/linux/system.pp
+++ b/rtl/linux/system.pp
@@ -525,6 +525,8 @@ procedure InitTLS; [public,alias:'FPC_INITTLS'];
 while assigned(auxp^) do
   inc(auxp);
 inc(auxp);
+phdr:=nil;
+phnum:=0;
 { now we are at the auxillary vector }
 while assigned(auxp^) do
   begin
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Constants in generics

[Florian Klämpfl]

Am 10.11.2018 um 13:20 schrieb Ryan Joseph:
>>>
 - the compiler contains already a type called tgenericdef
>>>
>>> I think I changed that name in the last commit. Btw I made all those types 
>>> because I didn’t want to populate the main types like ttypesym with extra 
>>> bytes but I don’t know what’s best practice in the codebase.
>>
>> Priority is:
>> 1. maintainability
>> 2. portability
>> 3. speed
>>
>> Keep also ppu storing/loading in mind.
> 
> Thus far on the compiler I haven’t encountered PPU's at all so I just assumed 
> they were part of the code generator and I didn’t need to worry about them. 
> How are they relevant here? Honestly I barely know what the PPU’s are and how 
> the compiler uses them.
> 

If you "export" a generic taking a const from a unit, this info has to be 
stored in the ppu.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Constants in generics

[Florian Klämpfl]

Am 09.11.2018 um 03:13 schrieb Ryan Joseph:
> 
> 
>> On Nov 9, 2018, at 4:28 AM, Florian Klämpfl  wrote:
>>
>> I like the idea of const in generics, but it needs serious cleanup when it's 
>> working:
>> - commit messages like "first commit" are useless
> 
> Those are for github so I could share but I need to learn SVN (again) 
> eventually.

This does not prevent you from creating proper commits, especially as the patch 
series from github could be easily
applied later on to fpc's main repository.

> 
>> - the compiler contains already a type called tgenericdef
> 
> I think I changed that name in the last commit. Btw I made all those types 
> because I didn’t want to populate the main types like ttypesym with extra 
> bytes but I don’t know what’s best practice in the codebase.

Priority is:
1. maintainability
2. portability
3. speed

Keep also ppu storing/loading in mind.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Constants in generics

[Florian Klämpfl]

Am 09.11.2018 um 05:20 schrieb Ryan Joseph:
> 
> 
>> On Nov 9, 2018, at 4:28 AM, Florian Klämpfl  wrote:
>>
>> I like the idea of const in generics, but it needs serious cleanup when it's 
>> working:
> 
> Question: should other consts besides integers be allowed? I don’t think it 
> makes sense personally to use strings, floats or sets but maybe I’m wrong.

I would allow them for orthogonality reasons.

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

Re: [fpc-pascal] Constants in generics

[Florian Klämpfl]

Am 06.11.2018 um 08:13 schrieb Ryan Joseph:
> I implemented a first draft of constants (integers) in generics. My reason 
> was specifically that I wanted a way to add methods to static arrays and 
> generic records is the only way to accomplish this AFAIK.
> 
> If I fix this up will it be considered as a patch? 
> I wanted to present the idea first before I spent any more time. Here’s what 
> I has so far (on GitHub).

I like the idea of const in generics, but it needs serious cleanup when it's 
working:
- commit messages like "first commit" are useless
- do not commit meta files like .gitignore with a functional commit
- follow the indention style of the surrounding code
- the compiler contains already a type called tgenericdef
- do not change the lazarus project files best practice is, to make a local 
copy for your own work (like ppcx64_ryan.lpi)
- create tests: succeeding as well as failing one
- do not use c style operators in the compiler, use inc/dec instead of += and -=
- replace comments like // note: ryan by comments like: "check for const 
generic paramters"
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Vote for Source Forge project of the month

[Florian Klämpfl]

FPC is again a candidate for the project of the month at Source Forge. In case 
somebody wants to support FPC in this
voting, here is the link: 
https://sourceforge.net/blog/community-choice-project-month-vote-december-2018/
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Order of Precedence: FPC/Delphi vs Java

[Florian Klämpfl]

Am 03.10.2018 um 12:06 schrieb Florian Klämpfl:
> really stored with extended precision representing exactly the
> value 51009.9.

This was sloopy wording by myself: the representation is not exact for extended 
either, but it must be actually the best
possible presentation with extended precision.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Order of Precedence: FPC/Delphi vs Java

[Florian Klämpfl]

Am 03.10.2018 um 11:28 schrieb mailingli...@geldenhuys.co.uk:
> 
> graeme.geldenhuys@UKCM-L500737 C:\devel\tests\OperatorPrecedence
>> fpc -Criot TestOperatorPrecedence.pas
> Free Pascal Compiler version 3.0.2 [2017/02/13] for i386
> Copyright (c) 1993-2017 by Florian Klaempfl and others
> Target OS: Win32 for i386
> Compiling TestOperatorPrecedence.pas
> TestOperatorPrecedence.pas(10,3) Note: Local variable "a" is assigned but 
> never used
> Linking TestOperatorPrecedence.exe
> 36 lines compiled, 0.1 sec, 35232 bytes code, 2436 bytes data
> 1 note(s) issued
> 
> graeme.geldenhuys@UKCM-L500737 C:\devel\tests\OperatorPrecedence
>> TestOperatorPrecedence.exe
>  5.10099001E+004
>  5.10099001E+004
>  5.10099001E+004
> ---
> -3.5527136788005009E-015
> -3.5527136788005009E-015
> -3.5527136788005009E-015
>  0.E+000
>  0.E+000
> 
> 
> Sorry, but this makes no sense to me.

In 32 Bit by default the x87 CPU is used. The x87 FPU uses extended for 
calculations and intermediate results (this is
basically a difference with respect to all other FPUs having any significance 
during the last >20 years) by default.
There are no instructions to force operations with single/double precisions, 
there is only a status which allows to
switch to another precision, see below.

b * c / d calculated with extended precision differs from the plain double 
value of c.

To get the same results with the x87 FPU, add

uses
  math;

..

  SetPrecisionMode(pmDouble);

to your program.

Or:

change all variables to extended, so the constants are really stored with 
extended precision representing exactly the
value 51009.9.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Order of Precedence: FPC/Delphi vs Java

[Florian Klämpfl]

Am 03.10.2018 um 10:40 schrieb mailingli...@geldenhuys.co.uk:
> I have this simple little test. My expected answer for all the calculations 
> are 0 (zero), but both FPC and Delphi give
> different results. Java is the only one that seems consistent regarding the 
> results.

Compile/run on the same architecture, use the same data types (and not extended 
for Object Pascal and double for Java).

With 3.0.4 x86_64-win64 I get (on i386-win32 you get this if you use the same 
data types and compile with -Cfsse2):

 5.10099001E+004
 5.10099001E+004
 5.10099001E+004
---
 0.E+000
 0.E+000
 0.E+000
 0.E+000
 0.E+000

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

Re: [fpc-pascal] Branch table

[Florian Klämpfl]

Am 26.08.2018 um 11:43 schrieb Giuliano Colla:
> Il 23/08/2018 11:34, Marco Borsari via fpc-pascal ha scritto:
> 
>> It would be for the Wirth optimization in the access of an array,
>> when the index is 0 or 1, allowing the elimination of a multiplication.
> 
> I'm afraid that this sort of optimization is rather outdated, and doesn't 
> take into account a number of factors which
> make modern processors behave quite differently from old times ones.

Multiplication is much less expensive then a jmp in most cases on today's CPUs.

It is even the other way round, it is often useful to replace an if statement 
by a multiplication like:

if a>b then
  Inc(c,d);

can be replaced on modern CPUs by

Inc(c,d*ord(a>b));
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Branch table

[Florian Klämpfl]

Am 21.08.2018 um 11:42 schrieb Marco Borsari via fpc-pascal:
> Il 20/08/2018 17:32, Giuliano Colla ha scritto:
> 
>> On the Intel architecture you cannot perform pointer arithmetic as if a
>> pointer were just a number.
>> A pointer is composed of two parts: a "selector" and an "offset", which
>> must be handled separately.
> 
> Ah, I saw, 32 bit segmentation is quite complicated.
> Thank you twice, Marco

I still miss the point of a hand coded branch table ...

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

Re: [fpc-pascal] Docs: portability differences between Borland/FPC

[Florian Klämpfl]

Am 19.08.2018 um 15:08 schrieb Martok:



But I don't actually want to debate that here, just collect information for 
users.



Well, you have to as you give people the wrong impression that they can control what happens if they suppress/ignore run 
time errors.

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

Re: [fpc-pascal] Docs: portability differences between Borland/FPC

[Florian Klämpfl]

Am 19.08.2018 um 14:44 schrieb Martok:



as soon as [something changes], Delphi shows exactly the same behavior as FPC.


But that's kind of the point of this collection: sometimes the rules intersect,
but for most cases, they don't.
Please note again: in general, there are no defined rules for FPC as soon as range check errors would occur. For FPC, 
you are just documenting random *behavior* which might change even with the next minor release.

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

Re: [fpc-pascal] Docs: portability differences between Borland/FPC

[Florian Klämpfl]

Am 19.08.2018 um 01:49 schrieb Martok:

Am 18.08.2018 um 23:39 schrieb Florian Klämpfl:

This is plainly wrong, at least for the older delphis, the host type in delphi 
will be Byte (or even Shortint).


It is actually shortint ...

Correct, I was thinking of the default PackEnum. Which of course has absolutely
nothing to do with that example.

Fixed, thanks.



Not really, you have also to fix the comments below because as soon as the range is 0..127 and the test is against 127, 
Delphi shows exactly the same behavior as FPC.

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

Re: [fpc-pascal] Docs: portability differences between Borland/FPC

[Florian Klämpfl]

Am 18.08.2018 um 23:26 schrieb Florian Klämpfl:

Am 18.08.2018 um 22:59 schrieb Martok:

Hi all,

There is the old "Porting TP" document at <https://www.freepascal.org/port.var>, but it is rather incomplete (and 
probably on an
older language level). It also covers mostly syntactic differences - things a programmer will notice because of the 
error messages.


Since #34140 was again someone tripping over an obscure difference between what is documented for the Borland 
compilers and what
is not actually documented in FPC (there's a reason #16006 has so many dupes), I've started writing up some of these 
things that

I could think of right away on the wiki, for now as a draft under my user 
namespace:
<http://wiki.freepascal.org/User:Martok/Portability_Issues>


"For example in Delphi, Percentile above is a Subrange of the Host Type Integer, so it could contain any value of a 
32bit Integer."


This is plainly wrong, at least for the older delphis, the host type in delphi will be Byte (or even Shortint). 


It is actually shortint ...
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Docs: portability differences between Borland/FPC

[Florian Klämpfl]

Am 18.08.2018 um 22:59 schrieb Martok:

Hi all,

There is the old "Porting TP" document at 
, but it is rather incomplete (and probably on an
older language level). It also covers mostly syntactic differences - things a 
programmer will notice because of the error messages.

Since #34140 was again someone tripping over an obscure difference between what 
is documented for the Borland compilers and what
is not actually documented in FPC (there's a reason #16006 has so many dupes), 
I've started writing up some of these things that
I could think of right away on the wiki, for now as a draft under my user 
namespace:



"For example in Delphi, Percentile above is a Subrange of the Host Type Integer, so it could contain any value of a 
32bit Integer."


This is plainly wrong, at least for the older delphis, the host type in delphi will be Byte (or even Shortint). Please 
note also, that Delphi shows exactly the same behavior as FPC if you replace 99 by 255.

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

Re: [fpc-pascal] Loss of precision when using math.Max()

[Florian Klämpfl]

Am 13.07.2018 um 16:36 schrieb Martok:

Am 12.07.2018 um 23:38 schrieb Florian Klämpfl:

This will result in different results for runtime and compile time calculated 
expressions => bad idea.


Aye, doing the same at runtime and compile time would be the sane idea.

Still, the Delphi(32) compiler always works with Extended precision at compile
time. See
<http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Declared_Constants#True_Constants>:
"If constantExpression is a real, its type is Extended" - that type then 
propagates.


Yes, this is for sure x87 inheritance. On x87 it is in practice always the case that operations are carried out with 
extended precision.





The other links were about intermediates of runtime calculations, so this change
is correct:

I have added support for the directive $EXCESSPRECISION: it forces that all 
binary float operations are executed with
the highest available precision available for the currently selected FPU

On that commit, am I blind or is this the same expression twice?
<https://github.com/graemeg/freepascal/blob/340c0b3b/compiler/nadd.pas#L159>




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

Re: [fpc-pascal] Loss of precision when using math.Max()

[Florian Klämpfl]

Am 10.07.2018 um 19:35 schrieb Martok:

I seem to remember that this was once documented somewhere for Delphi. Can't
seem to find it though, so maybe it was a 3rd-party book? There is
no hint of it
in the FPC documentation, anyway.

As already noted, it is not necessary in DelphiAh sorry, I was wrong: 
misremembered Integer const evaluation, where you should

cast the first part of the expression to Int64 if you want your expression to be
evaluated as that instead of Integer. Completely different issue.


The fix for #25121 doesn't seem like the best solution. The reported issue was
with explicit casts, I think the truncation should rather be in
ttypeconvnode.{typecheck_int_to_real, typecheck_real_to_real,
typecheck_real_to_currency} ?

That would give bestreal-precision back to const evaluation *unless* the
programmer explicitly casts to a lower precision? 


This will result in different results for runtime and compile time calculated 
expressions => bad idea.


During Codegen, casting down
happens anyway because of the storage requirements.



I have added support for the directive $EXCESSPRECISION: it forces that all binary float operations are executed with 
the highest available precision available for the currently selected FPU.

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

Re: [fpc-pascal] Loss of precision when using math.Max()

[Florian Klämpfl]

Am 03.07.2018 um 22:11 schrieb g...@wolfgang-ehrhardt.de:


Zitat von Florian Klämpfl :


 But actually, I just found out that we have something like this already for 
years:

{$minfpconstprec 64}


OK, then two questions remain: Why does is occur/apply only for (newer?) 3.1.1 
versions?


I dug a little bit deeper, the reason is:
https://bugs.freepascal.org/view.php?id=25121


And why is there no option to select the maximum precision for the target FPU?
E.g. if extended has 10 bytes (no only an alias for double with 64-bit), it
should be possible to select {$minfpconstprec 80} or {$minfpconstprec max}.



From the FPC sources:

  { adding support for 80 bit here is tricky, since we can't really }
  { check whether the target cpu+OS actually supports it}

(comment not by me). I am not sure, if this is still valid, it is >10 years old.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Loss of precision when using math.Max()

[Florian Klämpfl]

Am 03.07.2018 um 21:43 schrieb g...@wolfgang-ehrhardt.de:


Zitat von Florian Klämpfl :



So you want float constants being evaluated always with full precision (which would be required for consistency) 
causing any floating point expression containing a constant being evaluated with full precision as well?


Yes, at least as default or selectable per option (like FASTMATH etc),
and AFAIK it is default for all compilers I know except 3.1.1.


I am not sure if people like this, this means for example that

single2:=single1/3.0;

results in two type conversions and a double division (which is more expensive than a single one). But actually, I just 
found out that we have something like this already for years:


{$minfpconstprec 64}
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Loss of precision when using math.Max()

[Florian Klämpfl]

Am 03.07.2018 um 20:33 schrieb g...@wolfgang-ehrhardt.de:


Zitat von Florian Klämpfl :


In pascal, the rule applies that *the resulting type of an operation
does not depend on the type a value is assigned too*. So: 1.0 fits
perfectly into a single, 3.0 as well, they are single constants (you
didn't tell the compiler otherwise). Nobody wants that unnecessarily
larger types are used. So for the compiler this is a single division
and later on the result is converted into extended. The result for
integer is indeed a little bit strange, here probably the default
rule applies that any /-operand is converted to the best available
real type if it is not a real type, thus the result differs.
Question is, if the compiler should look the operand types and
choose more carefully the types, but I tend more to say no.


In any case there two facts.
1. The constants are evaluated at compile time, so there is no
speed penalty.


So you want float constants being evaluated always with full precision (which would be required for consistency) causing 
any floating point expression containing a constant being evaluated with full precision as well? Or how do you want to 
change rules to overcome the mentioned fact? I see only rules which require additional exceptions or causing full 
precision calculations always. The fact that the result type of an operations depends only on the operands, is not 
changeable, doing so will end in devil's kitchen.



2. This is a regression from 3.0.4 (here the 32-bit version works as
expected for both double and extended, and same for 64-bit except that
here extended=double) and to 3.1.1 (both under Win7/64).


This was probably changed for consistency. I tried to find the commit which 
changes this, but I cannot currently find it.






Is there a definite statement, that is will remain so.


Insert type casts for the constants to get proper results on all
archs, see below.

This is problematic because for portable code because not all compilers
support type casts here.


(Delphi works as expected).


The reason why delphi behaves different is probably due to it's
roots in being x87 only: x87 does all calculations with extended
precision.

This is also as expected for 64-Bit Delphis using SSE.



As said, (very strong) roots in x87.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Loss of precision when using math.Max()

[Florian Klämpfl]

Am 03.07.2018 um 19:42 schrieb g...@wolfgang-ehrhardt.de:


Zitat von Vojtěch Čihák :

will not give any warning even if correct result is 2.5.
It is simply absurd because it is not about shooting your own foot. Compiler is not a crystal ball, it does what you 
tell him.
If you need floating point, use floating point types and floating point division (my example) and if you need signed 
results, use


Really?

There are other source of loss of precision (in the trunk version) and the 
compiler does
not what I tell him. Example:

const
   d1: double = 1.0/3.0;
   d2: double = 1/3;
   x1: extended = 1.0/3.0;
   x2: extended = 1/3;
   s1: single   = 1.0/3.0;
   s2: single   = 1/3;
begin
   writeln(s1:30:10,  s2:30:10);
   writeln(d1:30:16,  d2:30:16);
   writeln(x1:30:16,  x2:30:16);
end.

and the result

   0.333433  0.333433
     0.333432674408    0.
     0.333432674408    0.

The single result is expected. But the  double and extended constants d1, x1 are
evaluated as single, even if I told the compiler to use the floating point 
quotient 1.0/3.0.


In pascal, the rule applies that *the resulting type of an operation does not depend on the type a value is assigned 
too*. So: 1.0 fits perfectly into a single, 3.0 as well, they are single constants (you didn't tell the compiler 
otherwise). Nobody wants that unnecessarily larger types are used. So for the compiler this is a single division and 
later on the result is converted into extended. The result for integer is indeed a little bit strange, here probably the 
default rule applies that any /-operand is converted to the best available real type if it is not a real type, thus the 
result differs. Question is, if the compiler should look the operand types and choose more carefully the types, but I 
tend more to say no.




If I use the integer quotient the values are as expected. This is against intuition 


True, but intuition is bad in programming :)


and gives
no warning. And even if I can adapt to this and live with this quirk: 


What is exactly the quirk?


Is there a definite
statement, that is will remain so. 


Insert type casts for the constants to get proper results on all archs, see 
below.


(Delphi works as expected).


The reason why delphi behaves different is probably due to it's roots in being x87 only: x87 does all calculations with 
extended precision. You get similar trouble if you do multiple single operations in one statement and on x87, the result 
is normally different from all other FPUs because x87 does not round in between. This is different from most other FPU 
implementations. This can be fixed only with the price doing on all non-x87 FPUs floating point operations unnecessarily 
precise.

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

Re: [fpc-pascal] Loss of precision when using math.Max()

[Florian Klämpfl]

Am 03.07.2018 um 14:33 schrieb Wolf:


Maybe we do get some views from the key authors of Free Pascal.


Not from me. These topics have been discussed zillion times.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] how to get rid of hints

[Florian Klämpfl]

Am 25.06.2018 um 09:19 schrieb Mattias Gaertner:

Hi,

How to get rid of hint 6068?

With fpc 3.1.1 using some units like fgl the compiler emits:

.../fpc/rtl/objpas/fgl.pp(899,1) Hint: "inherited" not yet supported
inside inline procedure/function
.../fpc/rtl/objpas/fgl.pp(899,1) Hint: Inlining disabled

There is no clue, what of my code triggers it.

How to get rid of the hint?


Put
#ifndef VER3_0
-vm6068
#endif
into your fpc.cfg.



I can't use -vm6068, because that is not supported by older fpc. Also
shutting down down an otherwise useful hint entirely is not my favored
thing to do.

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



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

Re: [fpc-pascal] Proper preprocessor?

[Florian Klämpfl]

Am 23.06.2018 um 04:30 schrieb Ryan Joseph:




On Jun 23, 2018, at 3:13 AM, Florian Klämpfl  wrote:

{$macro on}

{$define TypeStr:=specialize _TypeStr}

begin
  Writeln(TypeStr);
end.


;)


You have a good sense of humor about it at least. :)

So you can in fact print types, albeit with a more verbose syntax and by using 
another meta-programming tactic, e.g. generics.



Nobody said meta-programming is bad. But the right approach should be used.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Proper preprocessor?

[Florian Klämpfl]

Am 22.06.2018 um 08:01 schrieb Michael Van Canneyt:



On Fri, 22 Jun 2018, Ryan Joseph wrote:





On Jun 22, 2018, at 12:21 PM, Michael Van Canneyt  
wrote:

'Nice' is not an argument.

If someone else assumes that assert() works as expected - i.e. throws an exception, then your macro will mess up his 
code, leading to

unpredictable results.

From my - admittedly subjective - point of view, your examples only serve to demonstrate why we should definitely not 
support macros...


For any example I can give it’s easy to extrapolate into some scenario where it would be a disaster. I get that. The 
reason I ever wanted to make a macro was for personal use to give some project specific meaning to some construct or a 
quick hack. Frameworks like Apple uses,  often use macros to document parts of code in a way which otherwise isn’t 
part of the language and no suitable for comments. I’m not saying this is how we all should program. I don’t suggest 
people go out and start using macros in place of functions.


Btw why was the $define:= syntax ever introduced in the first place? adding a parameter to the syntax is a minor 
extension but it sounds like

Pascal programers here really don’t like it in general.


A good and just question. We most likely didn't realize the consequences. Meanwhile we're older, more experienced and we 
now know what impact seemingly good ideas can have...


Well, I think we (the people who decided to implement it) thought about the consequences. The chances to mess around 
with the currently implemented macro support is far less than with macros with parameters and concat operations. And the 
impact is limited imo.


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

Re: [fpc-pascal] Proper preprocessor?

[Florian Klämpfl]

Am 22.06.2018 um 22:07 schrieb Sven Barth via fpc-pascal:

Am 22.06.2018 um 10:12 schrieb Ryan Joseph:



On Jun 22, 2018, at 12:24 PM, Sven Barth via fpc-pascal 
 wrote:

If $Assertions is set to Off the complete Assert() line will be absent from the 
compiled code.


Good to know thanks.


Here’s an example of something I’ve seen for debugging. I think that was kind of cool you could print types like that 
and I’m not sure how that would work in Pascal if at all. Maybe some RTTI magic perhaps.


{$define typestr(t):='#t: '+IntToStr(sizeof(#t))}

program macro_test;
uses
SysUtils;

type
MyRecord = record
    x, y, z: single;
end;

begin
writeln(typestr(MyRecord)); // MyRecord: 12
end.

In trunk that can be done rather nicely:

=== code begin ===

program ttest;

{$mode objfpc}

uses
   TypInfo;

type
   TMyRecord = record
     x, y, z: Single;
   end;

generic function TypeStr: String;
var
   ti: PTypeInfo;
begin
   ti := PTypeInfo(TypeInfo(T));
   WriteStr(Result, ti^.Name, ': ', SizeOf(T));
end;

begin
   Writeln(specialize TypeStr);
end.

=== code end ===


Or even

program ttest;

{$mode objfpc}

uses
  TypInfo;

type
  TMyRecord = record
x, y, z: Single;
  end;

generic function _TypeStr: String;
var
  ti: PTypeInfo;
begin
  ti := PTypeInfo(TypeInfo(T));
  WriteStr(Result, ti^.Name, ': ', SizeOf(T));
end;

{$macro on}

{$define TypeStr:=specialize _TypeStr}

begin
  Writeln(TypeStr);
end.


;)

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

Re: [fpc-pascal] math with infinity and NaN

[Florian Klämpfl]

Am 20.06.2018 um 10:59 schrieb Adriaan van Os:

James Richters wrote:



I’ve been updating my old programs to use the MATH unit in freepascal and while testing things I came across a runtime 
error 217  Invalid floating point operation.  Here is my test program


I suggest to file a bug report. It is very unfortunate that the Math unit 
doesn't conform to IEEE-758.



Please read the standard, exceptions are part of it.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] math with infinity and NaN

[Florian Klämpfl]

Am 19.06.2018 um 23:50 schrieb James Richters:
I’ve been updating my old programs to use the MATH unit in freepascal and while testing things I came across a runtime 
error 217  Invalid floating point operation.  Here is my test program


Uses math;

var

    variable1:double;

    variable2:double;

Begin

variable1:= Infinity;

variable2:= -1*Infinity;

Writeln(variable1,' ',Variable2,' ',Variable1+Variable2);

End.

My output is:

Running "i:\programming\test\testmath.exe "

An unhandled exception occurred at $004015F6:

EInvalidOp: Invalid floating point operation

   $004015F6  main,  line 8 of i:/programming/test/testmath.pas

     +Inf -Inf

According to the link here: https://en.wikipedia.org/wiki/NaN

NaN should be produced:


No. The invalid operation is not masked by default. If you do so, FPC just 
write Nan.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal