Re: [fpc-pascal] Floating point question

[Bernd Oppolzer via fpc-pascal]

See below ...


Am 19.02.2024 um 02:00 schrieb James Richters via fpc-pascal:


>And if you have set the precision, then the calculation will be 
identical to the calculation when you use a variable of the same type 
(if not, it's indeed a bug).


This is what I have been trying to point out.Math with identical 
casting with variables and constants are not the same.


Maybe if I try with a simpler example:

program Const_Vs_Var;

Const

A_const = Byte(1);

B_const = Single(3.5);

Var

A_Var : Byte;

B_Var : Single;

Const_Ans1, Var_Ans1 : Extended;

Begin

A_Var := A_Const;

B_Var := B_Const;

Const_Ans1 := Extended(Byte(A_Const)/Single(B_Const));

Var_Ans1:= Extended(Byte(A_Var)/Single(B_Var));

WRITELN ( ' Const_Ans1 = ', Const_Ans1);

WRITELN ( 'Var_Ans1 = ',Var_Ans1);

End.

Const_Ans1 =2.85714298486709594727E-0001

Var_Ans1 =2.85714285714285714282E-0001

Windows 10 Calculator shows the answer to be

0.28571428571428571428571428571429Which matches up with the way 
variables have done this math, not the way constants have done it.




you don't need a calculator for 2 / 7 or 1 / 3.5. There is a simple rule 
for the decimal representation when dividing by 7:


1 / 7 = 0.142857 ...   repeat ad infinitum
2 / 7 = 0.285714
3 / 7 = 0.428571
4 / 7 = 0.571428
5 / 7 = 0.714285
6 / 7 = 0.857142

you see the pattern? You simply have to rotate the six digits in a 
certain manner ...



I am explicitly casting everything I possibly can.



I don't think you need the cast to extended around the divisions;
the divisions are done at different precision, which makes your problem,
but the cast to extended at the end doesn't help ... it will be done 
anyway,

because the target field is extended.

The problem indeed is that the division is done differently for consts 
and for vars,
and this seems to be the case for Windows only, as another poster 
pointed out.

This seems to be a real bug.

When casting this way

Byte(A_Var)/Single(B_Var)

I would expect the division to be done with single precision, but 
apparently it is done
using extended (or another) precision ... on Windows, not on Linux. And 
this is what

causes your headaches.


Without the :20:20 you can see that the result of each of these is in 
fact extended, but they are VERY different numbers, even though my 
casting is IDENTICAL , and I can’t make it any more the same, the 
results are very different.Math with Variables allows the result of a 
low precision entity, in this case a Byte, divided by a low precision 
entity, in this case a Single, to be calculated and stored in an 
Extended, Math with Constants does not allow this possibility, and 
this is where all the confusion is coming from.Two identical pieces of 
code not producing the same results.


Math with Constants is NOT the same as Math with Variables, and if 
this one thing was fixed, then all the other problems go away.


I am doing:

Const_Ans1 := Extended(Byte(A_Const)/Single(B_Const));

Var_Ans1:= Extended(Byte(A_Var)/Single(B_Var));

Just to make a point, but the code:

Const_Ans1 := A_Const/B_Const;

Var_Ans1:= A_Var/B_Var;

Should also produce identical results without re-casting, because 
A_Const and A_Var are both defined to be a Byte, and B_Const and B_Var 
are both defined to be a Single, and Const_Ans1 and Var_Ans1 are both 
defined to be Extended.


Why are the result different?

As I tried to explain before, if I force all constants to be Extended:

Const_Ans1 := Extended(Extended(A_Const)/Extended(B_Const));

Then I do get the correct results, but this should not be needed, and 
this casting is wrong,because a byte divided by a single should be 
able to be extended without first storing them in extended entities, 
the same as it is with variables.


With variables I do not need to re-cast every single term in an 
expression as Extended to get an Extended answer.


With constants this is the ONLY way I can get an extended answer.

Before the changes to 2.2, all constants WERE at highest precision, so 
the math involving constants never had to bother with considering that 
a low precision number divided by a low precision number could end up 
as an extended, because there were no low precision constants at all. 
But now there are, and that’s really fine, because we often have low 
precision variables, and that’s fine, but the math needs to be done 
the same way whether with constants or variables to produce identical 
results so now math with constants also has to take into consideration 
that math with low precision entities can and often does result in a 
high precision answer.


To demonstrate that a low precision entity divided by a low precision 
entity should always be able to be an Extended, use this example my 
constants as BYTES so there can be no lower precision:


program Const_Vs_Var;

Const

A_const = Byte(2);

B_const = Byte(7);

Var

A_Var : Byte;

B_Var : Byte;

Const_Ans1, Const_Ans2, Var_Ans1 : Extended;

Begin

A_Var := Byte(A_Const);

B_Var := Byte(B_Const);

Re: [fpc-pascal] Floating point question

[Bernd Oppolzer via fpc-pascal]

Am 17.02.2024 um 20:18 schrieb Florian Klämpfl via fpc-pascal:



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.


no problem here; the result of y1 must be the same, no matter if the 
computation is done at compile time or at run time.
the result should always be computed at the best precision available, 
IMO (maybe controlled by a compiler option,

which I personally would set).

y2: the computation could be done using single precision, because the 
second operand says so.
IMO: even if the first operand was a literal constant which cannont be 
represented exactly in a single FP field


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.


if y2 is computed at compile time (which is fine), then the result IMO 
is determined by the way the source code is written.
A possible optimization must not change the meaning of the program, 
given by the source code.
So in this case, the compiler would have to do a single precision 
division (if we could agree on the rules that we discussed so far),
and the meaning of the program may not be changed by optimization 
techniques (that is: optimization may not change the
result to a double or extended precision division ... otherwise the 
optimization is wrong).


BTW: many of the ideas about what a compiler should do come from my 30+ 
years experience with PL/1.
That may be a sort of "deformation professionelle", as the French call 
it, but that's how it is.


Apart from the proper handling of literal FP constants (which is what we 
discuss here, IMO), there is another topic,

which is IMO also part of the debate:

does

 y2 := 33.1 / y1;

require the division to be done at single precision or not?

We have here a literal constant, which is NOT single (33.1) and a single 
variable operand.
I understood from some postings here, that some people want the 
divisions with singles carried out using
single arithmetic, for performance reasons, so I asked for a single 
division here (in my previous postings).
But IMO that's different in the current implementation ... what do 
others think about this?


I, for my part, would find it strange, if the precision of the division 
in this case would depend on the (implicit)

type of the operand, that is:

 y2 := 33.015625 / y1;  { single precision, because constant is single 
- 33 + 1 / 64 }

 y2 := 33.1 / y1;   { extended precision, because constant is extended }

IMO, both of these divisions should be done at single precision, 
controlled by the type of y1.

But this could be controlled by ANOTHER new option, if someone asks for it.

Kind regards

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

Re: [fpc-pascal] Floating point question

[Bernd Oppolzer via fpc-pascal]

Am 17.02.2024 um 16:38 schrieb Bernd Oppolzer:


IMO, a compiler switch that gives all FP constants the best available 
precision would solve the problem -
BTW: WITHOUT forcing expressions where they appear to use this 
precision, if the other parts of the expression

have lower precision.

In fact, when parsing and compiling the expressions, you always can 
break the problem down to TWO operands
that you have to consider, and if one of them is a literal constant, 
it should not force the type of the operation to

a higher precision ... that's what I would do.



Commenting on my own post (this time):

const xs : single = 1440.5;
  xd : double = 1440.5;
  xu = 1440.5;  /* double or single, depending on new 
option */

  z : single = 33.0;

y1 := xs / z;   { single precision }
y2 := xd / z;   { double precision }
y3 := xu / z;   { different result, depending on new option }
y4 := 1440.5 / z;   { single, because z dictates it, independent of 
option }
y5 := 1440.1 / z;   { IMO: single, because z dictates it, independent of 
option }

y6 := 1440.5 / 33.0;   { depending on new option }


This may be in contrast to what's today done in FPC,
but that's how I (personally) would like to have it done.
Maybe the behaviour without the new option set is the same as now.

Not sure about y5.

Kind regards

Bernd





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

Re: [fpc-pascal] Floating point question

[Bernd Oppolzer via fpc-pascal]

Am 17.02.2024 um 14:38 schrieb Michael Van Canneyt via fpc-pascal:


There can be discussion about the rules that the compiler uses when it 
chooses a type, but any given set of rules will always have 
consequences that may or may not be desirable.


Possibly some compiler switches can be invented that modify the 
compiler's

rules for the constant type to use.


If the rules at the moment make this a single:

const xs = 64.015625;   { 64 + 1 / 64 }

because it can be represented correctly (without rounding error) in a 
binary single FP IEEE representation,

and this a double or extended type:

const xd = 64.1;  { no finite representation in binary or hex }

with all the observed effects on computations that the other posters 
here have pointed out


my personal opinion would be:

- never use such (implicitly typed) definitions ... but that's standard 
Pascal, after all

- try to convince the compiler builders that we need a better solution here

IMO, a compiler switch that gives all FP constants the best available 
precision would solve the problem -
BTW: WITHOUT forcing expressions where they appear to use this 
precision, if the other parts of the expression

have lower precision.

In fact, when parsing and compiling the expressions, you always can 
break the problem down to TWO operands
that you have to consider, and if one of them is a literal constant, it 
should not force the type of the operation to

a higher precision ... that's what I would do.

That's why I write all those mails (although I am not an active FPC 
user), because I want all Pascal versions around

to implement a clear and UNDERSTANDABLE language without strange effects.

Kind regards

Bernd


(incidentally, this is one of the reasons the FPC team does not want 
to make
inline variables as Delphi does, since there the type will again be 
determined by

the compiler - just as for constants, leading to ambiguity...)

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] Floating point question

[Bernd Oppolzer via fpc-pascal]

Am 17.02.2024 um 02:12 schrieb Ern Aldo via fpc-pascal:


It is possible math is being done differently by the compiler than by 
programs? For math-related source code, the compiler compiles the 
instructions and writes them to the program file for execution at 
runtime. For compile-time constant calculations that produce run-time 
constant values, one would expect the compiler to compile the 
instructions, execute them during compilation, and write the resulting 
value to the program file for use at runtime. Such instructions are 
discarded, because the program does not need them. If math is being 
compiled differently for program-executed calculations versus 
compiler-executed calculations, then that would be a problem.


I'll try to comment on this using some source code which hopefully does 
conform to FPC,
but I am not sure, because I am not familiar with FPC standards. Please 
look:


Const
   A_const = Integer(8427);
   B_const = Byte(33);
   C_const = Single(1440.5);

y1 := A_const + C_const / B_const;
y2 := 8427 + 1440.5 / 33;

In my understanding, in the first assignment the constants have types, 
which are given to them
by the const declarations. And that's why the computation is done using 
single precision.
This would be OK for me, because the developers decided to do the 
definitions this way,

and so he or she takes responsibility.
If the computation is done at run time or at compile time, DOESN'T MATTER.

In the second case, using literal constants, the compiler should do the 
math using the maximum
precision available (IMO), because one constant (1440.5) has a FP 
representation. It does and should
not matter, that this constant can be stored exactly in a single FP 
field. Here again:

If the computation is done at run time or at compile time, DOESN'T MATTER.

Maybe this is not how FPC works today, but IMO this is how it should be 
done, because we want
(IMO) Pascal to be a clear language which is simple to explain, easy to 
use and easy to implement.


The case would be different, of course, if you do the same casting in 
the y2 case as in the const

declarations.

Kind regards

Bernd

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

Re: [fpc-pascal] Floating point question

[Bernd Oppolzer via fpc-pascal]

Am 16.02.2024 um 15:57 schrieb James Richters via fpc-pascal:

So you are saying when constant propagation is on, an expression should have a 
different result than with constant propagation off?

The result of math when using constants MUST be the same as the result of 
identical math using variables.

There should never be a difference if I did my formula with hard coded 
constants vs variables.

   Const_Ans = 2.0010627116630224
  Const_Ans1 = 2.0010627116630224
Var_Ans1 = 2.

This should not be happening.

James


See my other post;

if the developer explicitly wants reduced precision, then this is what 
happens.

But the reduced precision should not come unexpectedly simply because the
compiler attaches type attributes to constants (which can't be easily 
explained),

and then the outcome of simple decimal arithmetic is incorrect.

So I have to disagree, sorry.

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

Re: [fpc-pascal] Floating point question

[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 
:

 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.

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

Re: [fpc-pascal] Floating point question

[Bernd Oppolzer via fpc-pascal]

My opinions about the solutions below ...


Am 13.02.2024 um 12:07 schrieb Thomas Kurz via fpc-pascal:

But, sorry, because we are talking about compile time math, performance 
(nanoseconds) in this case doesn't count, IMO.



That's what i thought at first, too. But then I started thinking about how to 
deal with it and sumbled upon difficulties very soon:

a) 8427.0 + 33.0 / 1440.0
An easy case: all constants, so do the calculation at highest precision and 
reduce it afterwards, if possible.

I agree; I would say:
all constants, so do the calculation at highest precision and reduce it 
afterwards, if required by the target


b) var_single + 33.0 / 1440.0
Should also be feasable by evaluating the constant expression first, then 
reducing it to single (if possible) and adding the variable in the end.
yes ... first evaluate the constant expression with maximum precision 
(best at compile time), then reduce the result.
The reduction to single must be done in any case, because the var_single 
in the expression dictates it, IMO


c) 8427.0 + var_double / 1440.0
Because of using the double-type variable here, constants should be treated as 
double even at the cost of performance due to not knowing whether the result 
will be assigned to a single or double.

yes


d) 8427.0 + var_single / 1440.0
And this is the one I got to struggle with. And I can imagine this is the 
reason for the decision about how to handle decimal constants.
My first approach would have been to implicitly use single precision values throughout 
the expression. This would mean to lose precision if the result will be assigned to a 
double-precision variable. One could say: "bad luck - if the programmer intended to 
get better precision, he should have used a double-precision variable as in case c". 
But this wouldn't be any better than the current state we have now.

8427.0 + (var_single / 1440.0)

the 1440.0 can be reduced to single, because the other operand is single
and so the whole operation is done using single arithmetic.

If here we had a FP constant instead of var_single, the whole operation 
IMO should be done
with maximum precision and at compile time in the best case. I have no 
problem that this
operation may give a different result with decimal constants than with 
explicitly typed
(reduced) FP variables. This can be easily explained to the users. 
Operations involving
FP variables with reduced precision may give reduced precision results. 
This seems to
be desirable for performance reasons and can be avoided by appropriate 
type casting.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Floating point question

[Bernd Oppolzer via fpc-pascal]

Am 13.02.2024 um 10:54 schrieb Michael Van Canneyt via fpc-pascal:



On Tue, 13 Feb 2024, James Richters via fpc-pascal wrote:

Sorry for the kind of duplicate post, I submitted it yesterday 
morning and I

thought it failed, so I re-did it and tried again.. then after that the
original one showed up.

A thought occurred to me.   Since the complier math is expecting all the
constants would be in full precision, then the compiler math doesn't 
need to

change, it's just that the reduction in precision is just happening too
soon.  It's evaluating and reducing each term of an expression, then the
math is happening, and the answer is not coming out right.

If instead everything was left full precision until after the 
compiler math
(because this is what the compiler math expects), and then the final 
answer
was reduced in precision where possible, then it would work 
flawlessly.  So

the reduction in precision function only needs to run once on the final
answer, not on every term before the calculation.


As Jonas said, this would result in less efficient code, since all the 
math will then be done at full precision, which is slower.


As usual, it is a trade-off between size (=precision) and speed.

Michael.



But, sorry, because we are talking about compile time math, performance 
(nanoseconds) in this case doesn't count, IMO.



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

Re: [fpc-pascal] Floating point question

[Bernd Oppolzer via fpc-pascal]

In this example below, the performance argument does not count IMO,
because the complete computation can be done at compile time.

That's why IMO in all 3 cases the values on the right side should be 
computed with
maximum precision (of course independent of the left side), and in an 
ideal world

it should be done at compile time. But if not: anyway with max precision.
Tagging the FP constants with FP attributes like single, double and 
extended and
then doing arithmetic on them which leads to MATHEMATICAL results which 
are unexpected
is IMO wrong and would not be accepted in most other programming 
languages or compilers.


This is NOT about variables ... they have attributes and there you can 
explain all sort of
strange behaviour. It's about CONSTANT EXPRESSIONS (which can and should 
be evaluated
at compile time, and the result should be the same, no matter if the 
evaluation is done at

compile time or not).

That said:

if you have arithmetic involving a single variable and a FP constant, say

x + 1440.0

you don't need to handle this as an extended arithmetic IMO, if you 
accept my statement above.
You can treat the 1440.0 as a single constant in this case, if you wish. 
It's all about context ...


Kind regards

Bernd


Am 12.02.2024 um 10:44 schrieb Thomas Kurz via fpc-pascal:

I wouldn't say so. Or at least, not generally. Why can't the compiler do what 
the programer intends to do:

var
   s: single;
   d: double;
   e: extended;
   
begin

   s := 8427.0 + 33.0 / 1440.0; // treat all constants all "single"
   d := 8427.0 + 33.0 / 1440.0; // treat all constants all "double"
   e := 8427.0 + 33.0 / 1440.0; // treat all constants all "extended"
end.

Shouldn't this satisfy all the needs? Those caring for precision will work with 
double precision and don't have to take care for a loss in precision. Those 
caring for speed can use the single precision type and be sure that no costly 
conversion to double or extended will take place.




- Original Message -
From: Jonas Maebe via fpc-pascal 
To: fpc-pascal@lists.freepascal.org 
Sent: Sunday, February 11, 2024, 23:29:42
Subject: [fpc-pascal] Floating point question

On 11/02/2024 23:21, Bernd Oppolzer via fpc-pascal wrote:

and this would IMHO be the solution which is the easiest to document and
maybe to implement
and which would satisfy the users.

And generate the slowest code possible on most platforms.


Jonas
___
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

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

Re: [fpc-pascal] Floating point question

[Bernd Oppolzer via fpc-pascal]

Am 11.02.2024 um 17:31 schrieb 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/


Many thanks for the links, I read them with interest; for me - working 
almost every day with IBM systems -
the remarks on the old IBM FP hex format (base 16) are very interesting. 
Today's IBM systems support IEEE as well.


IMO, the question regarding FP constants (not variables) in compilers is 
not yet answered fully. If we have an expression
consisting only of FP constants like in the original coding: should the 
FP constants indeed given different
FP types by the compiler? Or should the FP constants maybe have all the 
same type .. the largest type available?
This would automatically lead to a computation using the maximum 
precision, no matter if it is done at compile time
or at run time ... and this would IMHO be the solution which is the 
easiest to document and maybe to implement

and which would satisfy the users.

Kind regards

Bernd Oppolzer

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

Re: [fpc-pascal] Floating point question

[Bernd Oppolzer via fpc-pascal]

I didn't follow all the discussions on this topic and all the details of 
compiler options of FPC

and Delphi compatibility and so on, but I'd like to comment on this result:

program TESTDBL1 ;

Const
   HH = 8427.02291667;
Var
   AA : Integer;
   BB : Byte;
   CC : Single;
   DD : Single;
   EE : Double;
   FF : Extended;
   GG : Extended;
   


begin
   AA := 8427;
   BB := 33;
   CC := 1440.0;
   DD := AA+BB/CC;
   EE := AA+BB/CC;
   FF := AA+BB/CC;
   GG := 8427+33/1440.0;
   
   WRITELN ( 'DD = ',DD: 20 : 20 ) ;

   WRITELN ( 'EE = ',FF: 20 : 20 ) ;
   WRITELN ( 'FF = ',FF: 20 : 20 ) ;
   WRITELN ( 'GG = ',GG: 20 : 20 ) ;
   WRITELN ( 'HH = ',HH: 20 : 20 ) ;
end.


result:

DD = 8427.02246100
EE = 8427.022916625000
FF = 8427.022916625000
GG = 8427.022460937500
HH = 8427.022916625000


IMO, the computations of AA+BB/CC (right hand side) should be carried 
out the same way, regardless of the type
on the left hand side of the assignment. So I would expect the values in 
DD, EE and FF being the same.


But as it seems, the left hand side (and the type of the target 
variable) HAS AN INFLUENCE on the computation

on the right hand side, and so we get (for example)

DD = 8427.02246100

and

EE = 8427.022916625000

which IMHO is plain wrong.

If all computations of AA+BB/CC would be carried out involving only 
single precision,

all results DD, EE, FF (maybe not GG) should be 8427.0224...
only minor differences because of the different precisions of the target 
variables

(but not as large as the difference between DD and EE above).

This would be OK IMHO;
it would be easy to explain to everyone the reduced precision on these 
computations

as a consequence of the types of the operands involved.

Another question, which should be answered separately:

the compiler apparently assigns types to FP constants.
It does so depending on the fact if a certain decimal representation can 
exactly be represented

in the FP format or not.

1440.0 and 1440.5 can be represented as single precision, so the FP type 
single is assigned
1440.1 cannot, because 0.1 is an unlimited sequence of hex digits, so (I 
guess), the biggest available FP type is assigned

1440.25 probably can, so type single is assigned
1440.3: biggest FP type
1440.375: probably single

and so on

Now: who is supposed to know for any given decimal representation of a 
FP constant, if it can or cannot
be represented in a single precision FP variable? This depends on the 
length of the decimal representation,
among other facts ... and the fraction part has to be a multiple of 
negative powers of 2 etc. etc.


That said: wouldn't it make more sense to give EVERY FP CONSTANT the FP 
type with the best available precision?


If the compiler did this, the problems which arise here could be solved, 
I think.


GG in this case would have the same value as HH, because the computation 
involving the constants
(hopefully done by the compiler) would be done with the best available 
precision.


HTH, kind regards

Bernd


Am 06.02.2024 um 16:23 schrieb James Richters via fpc-pascal:

program TESTDBL1 ;

Const
HH = 8427.02291667;
Var
AA : Integer;
BB : Byte;
CC : Single;
DD : Single;
EE : Double;
FF : Extended;
GG : Extended;



begin
AA := 8427;
BB := 33;
CC := 1440.0;
DD := AA+BB/CC;
EE := AA+BB/CC;
FF := AA+BB/CC;
GG := 8427+33/1440.0;

WRITELN ( 'DD = ',DD: 20 : 20 ) ;

WRITELN ( 'EE = ',FF: 20 : 20 ) ;
WRITELN ( 'FF = ',FF: 20 : 20 ) ;
WRITELN ( 'GG = ',GG: 20 : 20 ) ;
WRITELN ( 'HH = ',HH: 20 : 20 ) ;
end.

When I do the division of a byte by a single and store it in an extended, I
get the division carried out as an extended.
FF, GG, and HH should all be exactly the same if there is not a bug.
But:

DD = 8427.02246100
EE = 8427.022916625000
FF = 8427.022916625000
GG = 8427.022460937500
HH = 8427.022916625000___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Floating point question

[Bernd Oppolzer via fpc-pascal]

To simplify the problem further:

the addition of 12 /24.0 and the subtraction of 0.5 should be removed, IMO,
because both can be done with floats without loss of precision (0.5 can 
be represented exactly in float).


So the problem can be reproduced IMO with this small Pascal program:

program TESTDBL1 ;

var TT : REAL ;

begin (* HAUPTPROGRAMM *)
  TT := 8427 + 33 / 1440.0 ;
  WRITELN ( 'tt=' , TT : 20 : 20 ) ;
end (* HAUPTPROGRAMM *) .

With my compiler, REAL is always DOUBLE, and the computation is carried 
out by a P-Code interpreter

(or call it just-in-time compiler - much like Java), which is written in C.

The result is:

tt=8427.022916667879

and it is the same, no matter if I use this simplified computation or 
the original


tt := (8427 - 0.5) + (12 / 24.0) + (33 / 1440.0);

My value is between the two other values:

tt=8427.022916668000
tt=8427.022916667879
ee=8427.022916625000

The problem now is:

the printout of my value suggest an accuracy which in fact is not there, 
because with double, you can trust
only the first 16 decimal digits ... after that, all is speculative 
a.k.a. wrong. That's why FPC IMO rounds at this

place, prints the 8, and then only zeroes.

The extended format internally has more hex digits and therefore can 
reliably show more decimal digits.

But the last two are wrong, too (the exact value is 6... period).

HTH,
kind regards

Bernd



Am 27.01.2024 um 22:53 schrieb Bart via fpc-pascal:

On Sat, Jan 27, 2024 at 6:23 PM Thomas Kurz via fpc-pascal
  wrote:


Hmmm... I don't think I can understand that. If the precision of "double" were 
that bad, it wouldn't be possible to store dates up to a precision of milliseconds in a 
TDateTime. I have a discrepancy of 40 seconds here.

Consider the following simplified program:

var
   tt: double;
   ee: extended;

begin
   tt := (8427 - Double(0.5)) + (12/ Double(24.0)) +
(33/Double(1440.0)) + (0/Double(86400.0));
   ee := (8427 - Extended(0.5)) + (12/ Extended(24.0)) +
(33/Extended(1440.0)) + (0/Extended(86400.0));
   writeln('tt=',tt:20:20);
   writeln('ee=',ee:20:20);
end.
===

Now see what it outputs:

C:\Users\Bart\LazarusProjecten\ConsoleProjecten>fpc test.pas
Free Pascal Compiler version 3.2.2 [2021/05/15] for i386
...

C:\Users\Bart\LazarusProjecten\ConsoleProjecten>test
tt=8427.022916668000
ee=8427.022916625000

C:\Users\Bart\LazarusProjecten\ConsoleProjecten>fpc -Px86_64 test.pas
Free Pascal Compiler version 3.2.2 [2021/05/15] for x86_64
..

C:\Users\Bart\LazarusProjecten\ConsoleProjecten>test
tt=8427.022916668000
ee=8427.022916668000

On Win64 both values are the same, because there Extended = Double.
On Win32 the Extended version is a bit closer to the exact solution:
8427 - 1/2 + 1/2 + 33/1440 = 8427 + 11/480

Simple as that.

Bart
___
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] case statement

[Bernd Oppolzer via fpc-pascal]

Am 17.12.2023 um 16:36 schrieb Adriaan van Os via fpc-pascal:


As the otherwise-clause is not in ISO-7185 Pascal, it seems more 
plausible that Borland invented the else-clause (without semicolon) 
independently. All other Pascals I have looked at, use an 
otherwise-clause (with an obligatory semicolon). The motivation for 
this, given in IBM Pascal is interesting. The manual says that the 
statement-part of the otherwise-clause can be intentionally "left 
blank" and be used "to prevent possible errors during execution". I 
recall that in ISO-7185 Pascal it is an error if no case discriminator 
matches at runtime. So, the otherwise-clause was seen as a way to get 
around that !


This was one of Niklaus Wirth's mistakes: that the original Pascal 
definition did not tell how the syntax of the "otherwise" part of the 
case statement should be.
I recall that our profs in the computer science classes in the 1970s 
criticized this serious flaw of the language.


So almost every compiler had to find its own solution.

The compilers for the IBM machines were, to some degree, influenced by 
PL/1. There we have:

IF ... THEN ... ELSE
and
SELECT ... WHEN ... OTHER(WISE) ... END

SELECT is much the same as case, although more general; not limited to 
simple expressions;

not even limited to expressions ... there are two flavors of SELECT:

SELECT (expr); WHEN (A) ...; WHEN (B) ...; OTHER ...; END;
SELECT; WHEN (cond1) ...; WHEN (cond2) ...; OTHER ...; END;

PL/1 was first defined in the mid 1960s, so maybe some of the Pascal 
compiler designers may have been influenced (to some degree) by PL/1.
Even C was influenced by PL/1 (because PL/1 was the implementation 
language of the Multics system, and K & R had that experience

and agreed about how things should NOT be done).

BTW: my Stanford compiler uses OTHERWISE (no abbreviation). There is no 
error, if OTHERWISE is omitted and no case label matches;
in this case, simply no action is taken. And: my compiler took some 
inspiration from IBMs Pascal compilers ... and some builtin functions

were inspired by PL/1 functions, indeed.

Kind regards

Bernd



Regards,

Adriaan van Os
___
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] case statement

[Bernd Oppolzer via fpc-pascal]

Am 17.12.2023 um 06:12 schrieb Adriaan van Os via fpc-pascal:


Anyway, the innocent looking case-statement does have some interesting 
aspects.



Indeed.

My Stanford compiler tries to be portable across platforms;
due to its IBM mainframe heritage even on platforms that have "strange" 
character sets like EBCDIC.
When I ported it to ASCII based machines in 2016, I had some trouble 
with case statements based on

character variables and expressions.

See the story here:

http://bernd-oppolzer.de/job9i025.htm


___
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] Does the compiler make prodigious use of use ENTER instruction?

[Bernd Oppolzer via fpc-pascal]

I wrote a comment on the original Microsoft dev blog (for a non-Pascal 
community), maybe it's of interest here, too ...


In normal Pascal procedure calls, such a vector of stack frame addresses 
is not needed. A standard Pascal runtime knows all the time about the 
current stack frame address of – say – the procedure which is currently 
active at static level n. This information is called the DISPLAY VECTOR 
and there is no need to copy the display vector on procedure calls, 
because it is stored at a well-known location inside the runtime. You 
only have to replace the stack frame addresses of the current static 
level, when you enter or leave a procedure (and maybe set the new 
current static level).


What makes things more complicated, are procedure and function 
PARAMETERS (in Pascal), that is: procedures that are passed as 
parameters to other procedures. In this case, it is indeed necessary to 
COPY THE COMPLETE DISPLAY VECTOR, because it is not possible to predict 
what static level the procedure (which is passed as a parameter) has. So 
maybe the ENTER instruction is meant for such use cases.


Some of the old Pascal compilers didn’t allow procedure parameters (or 
implemented them badly) due to these difficulties.
To see, if your (Pascal or Algol) compiler implemented procedure 
parameters correctly, you can use the “Man or Boy” test: 
https://en.wikipedia.org/wiki/Man_or_boy_test



Am 12.12.2023 um 17:48 schrieb Anthony Walter via fpc-pascal:
Iwas reading this article today on the Microsoft website about the 
mysterious x86 ENTER instruction. The article states that it's primary 
purpose is to support Pascal and similar compilers to allow for 
preserving local variables on the stack when using with nested functions.


Here is the article:

https://devblogs.microsoft.com/oldnewthing/20231211-00/?p=109126

Do any of the compiler devs know if Pascal programs for the x86 
instruction set are using ENTER and its second argument to the best 
possible effect? I am curious.


___
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] Does the compiler make prodigious use of use ENTER instruction?

[Bernd Oppolzer via fpc-pascal]

Am 12.12.2023 um 17:51 schrieb Marco van de Voort via fpc-pascal:


Op 12-12-2023 om 17:48 schreef Anthony Walter via fpc-pascal:


Do any of the compiler devs know if Pascal programs for the x86 
instruction set are using ENTER and its second argument to the best 
possible effect? I am curious.


No, and if they do, they don't do in the way they are meant to. These 
are very old instructions and the intended use has a nesting limit (of 
32 levels iiirc).  Because of that limit, modern compilers don't use 
them.



32 static levels is MUCH, IMO.

I have an old compiler here (New Stanford Pascal, originating from 
Pascal P4), which has only 9 static levels.

Dynamic nesting is unlimited, of course.
This was never a problem for me; every seperately compiled module starts 
again at level 2.
The only program which comes close to the 9 level limit is the 26.000 
lines compiler phase 1.


My compiler copies and restores the addresses of all 9 stack frame 
levels, but only when passing procedure and function parameters;
otherwise the addresses of the stack frames are located at certain (well 
known) places which can always be found,
and only individual stack frame addresses have to be set and restored 
when entering or leaving a function.


I had the idea to extend the limit from 9 to 20, but there was no hard 
requirement so far, so I left it at 9.


C, for example, and other "modern" languages, have a static limit of 1.

Kind regards

Bernd



Some forms of enter and leave are use as peephole optimizations.


___
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] Pointer question

[Bernd Oppolzer via fpc-pascal]

FWIW, when I added similar functionality to my Stanford Pascal compiler, 
I chose not to allow arithmetic

of pointers, but instead I added some functions:

PTRADD (p, i) - p is type ANYPTR, i is integer, result is of type ANYPTR
PTRDIFF (p1, p2) - two pointers, the result is integer
ANYPTR is a predefined type, compatible with every (typed pointer)
ADDR (x) is a function (borrowed from PL/1), which returns an ANYPTR ... 
and it is allowed for all types of variables
PTRCAST is the same as PTRADD (p, 0) - and is used to cast pointers 
between incompatible pointers (not type safe)


Kind regards

Bernd


Am 10.08.2023 um 10:52 schrieb Elmar Haneke via fpc-pascal:

1) what does "i := x - x;" do and what is it's purpose and why doesn't "x + x" 
work the same?


Subtracting pointers may be useful if they point to consecutive 
memory. The Result is the number of bytes between both addresses.


Adding pointers is useless, you would get a pointer pointing to some 
address in address space which has no relation to the pointers — 
presumably accessing it would rise an error.


Therefore, it is a good idea to let the compiler prevent such mistakes.


2) I've used pointer equality of course but what does "x > p" do and what is 
its purpose?


It may be useful if pointers do point into a continuous data object, 
e.g. a write-pointer inside a buffer.


Elmar

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

Re: [fpc-pascal] Legitimate use of for and break

[Bernd Oppolzer via fpc-pascal]

Am 18.06.2023 um 03:04 schrieb Hairy Pixels via fpc-pascal:



On Jun 18, 2023, at 1:07 AM, tsie...@softcon.com wrote:

This is interesting, because it's the first time I've ever seen "break" as a 
valid command in pascal, and I've been using pascal since the mid/late 80s.  All kinds of 
dialects too, and I've never seen break as a keyword.  C, Python, Perl, sure, even shell 
scripts, but pascal? Never seen it used before.  Is this a relatively new addition to fpc 
or something?

I don't remember break NOT being in Pascal. How did you exit a loop otherwise, 
goto? Break is common in basically all languages now. Can't think of a language 
I've used without it.

FWIW, when I started to work on New Stanford Pascal 
(http://bernd-oppolzer.de/job9.htm)
in 2011, the very first thing that I did was to add BREAK, CONTINUE and 
RETURN to this compiler.
New Stanford Pascal is an offspring of the Zürich P4 compiler from the 
1970s, directly from

the working group of Niklaus Wirth (who was at Stanford, too, BTW).

The compiler is a self-hosting compiler (like most Pascal compilers, I 
believe) and up to 2011
there were many exits from loops bye putting a label after the loop and 
using GOTO
(because of the absence of BREAK). Similar use of GOTO to implement 
CONTINUE and RETURN.


I got rid of most of these labels (if not all) by adding these three 
keywords. This was easy.
I did many extensions to the compiler later (from 2016 on) and ported 
the compiler to Windows and
Linux etc.; the compiler, which had 6.000 lines in 2011, now has over 
25.000 lines :-)


Kind regards

Bernd


Regards,
Ryan Joseph

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

Re: [fpc-pascal] Converting old pascal written for Pascal/MT+ compiler

[Bernd Oppolzer via fpc-pascal]

Am 04.04.2023 um 08:16 schrieb Jacob Kroon via fpc-pascal:


Thanks for the tip above.

I was able to write a couple of perl-scripts that are able to convert 
my old Pascal sources to something that fpc can parse. Amongst other 
things, the scripts inject the "public name"/"external name" 
annotations so that the program can link.


But I suspect I have a new problem: With the old Pascal/MT+ compiler 
it would appear that local variables declared in functions/procedures 
have a life-time that spans the whole program, like a "static" 
declared variable in C. With fpc, it looks like locally declared 
variables are automatic, put on the stack(?), and so they go out of 
existence once out of scope ?



IMO, this is not a feature of the old PASCAL compiler,
but instead your Pascal programs "by error" depends on the local variables
appearing at the same location on the stack at subsequent calls as before
(if there are no other calls at the same level in between).

The local variables are not initialized when allocated, and so it is 
possible

that they still have the old value that they had when the same function
was left the last time. I know (from the 1970s and 1980s) that some 
weird programs
used this effect. But as soon as another call was entered between the 
two calls
of the procedure, the stack at this location was overwritten, and the 
"clever" use
of the old value of the variable was not possible any more. And: it 
depends on the

stack being initialized to a known default value in the first time.

This said: the initial value of the local variables is UNDEFINED, and 
this is true
for every Pascal compiler. I cannot imagine a compiler which doesn't 
follow this basic rule.


So IMO: you should find the places in your program, where this weird 
technique is used

and not blame the old compiler for this.

Some compilers have an option which initializes every automatic variable 
on every allocation;
some compilers even allow the bit-pattern to be specified (for example: 
0xff).
While this is a performance nightmare, this is very good to run the 
program once during program test,
because it will show if your program depends on such effects or if it 
produces different values,

depending on initialized or uninitialized local variables.

Kind regards

Bernd




The program depends on this feature in the old compiler. I did some 
googling and found that putting local variables in a "const" section 
instead of "var" would make them have a "whole-program" lifetime, but 
then I need to provide them with an initial value.


Do I have any other option besides changing from "var" to "const" 
everywhere, and provide initial values in all declarations ?


Regards
Jacob
___
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] Graphing library

[Bernd Oppolzer via fpc-pascal]

Hi,

I don't know if this can help you, but in the 1980s I worked with a 
library called GKS (graphic kernel system)

which I used to build such graphics like the following example:
http://bernd-oppolzer.de/fdynsb.pdf

This programs that did this were written in Pascal at that time.

It still works today for me (the customer still uses this software),
although is it C today, and GKS is not available any more.
What I did: the original GKS calls are written to files (some sort of 
GKS metafile, but not the
original 1980s format), and then this file format is read by a C program 
GOUTHPGL,
which translates this (proprietary) format to HPGL. The HPGL files are 
either sent to
HP plotters or translated to PDF using public domain software; see the 
file above.

(GOUTHGPL was a Pascal program in the 1990s, too).

IMO, you could easily write the "GKS metafile format" with Pascal;
in fact, it is simply is a sort of logfile of the GKS calls.

Here is an old paper about the GKS system: 
http://nsucgcourse.github.io/lectures/Lecture01/Materials/Graphical%20Kernel%20System.pdf


The translator GOUTHGPL supports only a small subset of GKS; see again 
the example picture above.


If you are interested for more details, you could contact me offline.

Kind regards

Bernd


Am 15.11.2020 um 09:33 schrieb Darius Blaszyk via fpc-pascal:

Hi,

I am looking for a simple to use non-visual graphing library to 
produce x-y plots in a  raster file format (similar to how pyplot 
works). Rather than developing something from scratch or writing a 
wrapper to GNU plot (additional dependency), I was hoping something 
like this already would exist that I could build upon.


Thank you for any tips!

Rgds, Darius

___
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] basic question on begin, end;

[Bernd Oppolzer via fpc-pascal]

Am 25.09.2020 um 22:16 schrieb James Richters via fpc-pascal:


I think that’s a GREAT quote from Niklaus Wirth, and I agree with that 
whole heartedly… programs should be readable by humans… otherwise do 
all your programming in assembly language… the whole POINT of a hi 
level language is to make it readable by humans… not computers.I can’t 
stand trying to muddle through things like C++,it’s just to 
confusing.. trying to follow all those curly braces and figure out 
what this line of code is going to do.. it’s just a mess. yes I can 
manage, but I defiantly prefer the clarity of PASCAL… so I also name 
my variable very clearly instead of using cryptic shorthand.. who 
cares how verbose my variable names are… it doesn’t make the program 
any less efficient.. but very clear function and variable names sure 
make it easier to remember what you were thinking when you have to go 
back and modify code you originally wrote 30 years ago.



...

I admit my code gets a little sloppy with the indents, so after a 
while it sometimes looks like:


if something then
begin
some code here;

some more code;
end;

at least it compiles correctly because the begin and end; are defining 
things… once I get a function or procedure working the way I want it, 
I will then take the time to go back and fix my indents.




Same for me, except that I totally automated the process of fixing the 
indents;
when inserting new code into a program, I don't care much about 
indentation;
instead after compiling successfully, I run a (self-written) Pascal 
program which fixes the
indentation etc.; it also draws boxes around certain comments and 
inserts blank lines,
when necessary. The parts of the program, which are already well-formed, 
remain unchanged.


The program, which fixes the indentation, is in many cases scheduled 
automatically after

a successful compiler run.

This is how a program looks after automated indentation:
https://github.com/StanfordPascal/Pascal/blob/master/PASCAL1.pas

Kind regards

Bernd


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

Re: [fpc-pascal] Illegal counter variable?

[Bernd Oppolzer]

Am 09.09.2019 um 16:11 schrieb James Richters:

I just don't see why having the limitation, there is no technical reason that
the for loop couldn't change that I can see.. especially since it works in TP 
mode.



The original reason why some Pascal implementations had this limitation:

for performance or optimization reasons, the loop control variable was
transferred to a register at the beginning of the loop, and changing the
variable (at its storage location) inside the loop simply had no effect,
because the variable was not fetched from there again during loop 
execution.

Worse: maybe, to make read accesses to the loop control variable valid
inside the loop, they are prepared by storing the control register value
into the loop control variable, thus turning changes to the loop control
variable useless.

Forbidding (write) accesses to the loop control variable allows for many
aggressive optimization strategies around loops.

Maybe today such limitations seem too restrictive.

Kind regards

Bernd

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

Re: [fpc-pascal] += property bug?

[Bernd Oppolzer]

Am 14.08.2019 um 17:41 schrieb wkitt...@windstream.net:

On 8/14/19 10:54 AM, Ryan Joseph wrote:
Seriously? why is i := i + 1 better than i += 1 ? just more typing 
for such a
simple operation. All languages I use have adopted this syntax and 
for good

reason.


good reason?? because someone is too lazy to type 4 more characters? 
yes, i'm counting the readability spaces which could easily be left 
out...


/me tightens belt on asbestos britches...




4 characters in your case, but if you have for example:

CALL_LVL [ LOCAL_CALL ] := CALL_LVL [ LOCAL_CALL ] + 1 ;

and you write instead:

CALL_LVL [ LOCAL_CALL ] += 1;

it's more than 4 chars, and it's easier, when it comes to changes,
and and and ...

This is only a simple example; consider arrays with more indexes and
record components and pointer references ...

BTW: the two statements are not equivalent, if the index expression
contains for example a function call with side effects :-)

PL/1 is another language which has been enhanced to support this
notation some years ago.

Kind regards

Bernd

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

[fpc-pascal] Implementation of variant records

[Bernd Oppolzer]

This question is not directly related to FPC, but it is instead a Pascal 
question in general.


Take this record definition:

type S1 = record
    X : CHAR ( 27 ) ;
    case INTEGER of
  1 :
    ( V : INTEGER ) ;
  2 :
    ( W : REAL ) ;
  3 :
    ( Z : CHAR ( 8 ) ) ;
  end ;

CHAR (n) is an abbreviation for /* packed */ array [1..n] of char
which is accepted by a certain compiler.

Now the question:

X needs 27 bytes, so the variant part of the record starts at offset 27.
But on a certain platform V has alignment 4 (integer), W has alignment 8 
(real).
The compiler decided to put V on offset 28, W on offset 32 and Z (no 
alignment)

on offset 27, so the three variants don't overlay properly.

IMO, the variants in a variant record should always overlay correctly 
(like unions in C),
so the variant part should start at offset 32 in this case, and this is 
where all three

variants should start.

In other words: every record (in classical Pascal) consists of a fixed 
part and a variant
part and a fixed border between the two (that's how it should be, IMO). 
And this border
takes its alignment properties from the highest alignment of the fields 
in the variant part.


What do you think?

Why is this important to me? Because I am working on a WITH extension 
for record definitions,
which allows the integration of the components from other record and 
pointer types into the
current record type namespace, and this has to be fixed, before I can do 
this.


BTW: is there a forum to discuss general Pascal questions not directly 
related to the FPC product?
FPC-Pascal will sure be the largest auditorium available for such 
questions ...


Thank you, kind regards

Bernd

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

Re: [fpc-pascal] Turbo Pascal 3 graphics

[Bernd Oppolzer]

This may be off-topic, but anyway:

I did some graphics programming in the 1990s (for customers of mine),
but with not so much interest on display terminals, but instead on large
plotters (DIN A0 format, for example).
I used a library called GKS at that time (graphics kernel system), which 
was
device independent and supported several "drivers" for different 
plotters and
graphics display stations. But it was only "passive" graphic, used to 
preview
the output which was plotted later. GKS had a Fortran interface, but I 
added

a Pascal interface. This was on the IBM mainframe.

Later (and on other platforms) I had no GKS, but I liked the idea, so I 
built

a library of my own, inspired by GKS. The GKS calls produce a GKS metafile;
this is a readable text file which contains all the graphic elements. 
The GKS
metafile is then translated to HPGL (HP graphics language); this is the 
only
supported "driver" at the moment. For HPGL files, there are very good 
public

domain viewers (for example HPGLVIEW from Cern). You can print or plot the
HPGL files or convert them to PDFs.

So, using this GKS library and the GKS metafile format (and its 
translation to HPGL),

it is still possible to do sort of professional graphics programming using
much the same functions and features that I used in the 1990s. The language
doesn't really matter; it can be C or Pascal.

Example output file: http://bernd-oppolzer.de/fdynsb.pdf

If you want to know more about GKS or the GKS-to-HPGL-translator,
please feel free to contact me offline.

Kind regards

Bernd


Am 07.05.2019 um 22:52 schrieb Kevin Lyda:

Amazingly I still have a number of my high school computer science
projects which were written in Turbo Pascal 3. And a few are almost
not horribly embarrassing.

I'd like to port them to fpc and write up the experience but I know
what the huge issue is: it uses the graphics.bin library which was
brought in with graph.p - a snippet of which is at the bottom of this
email.

It did something like turtle graphics and worked on CGA type systems
which were comically limited. Still, it would be neat to see it run
outside of DOSBox.

So I'm wondering what my options are with FPC graphics. Looking
through the code I used Draw, GotoXY, Palette, Circle and Fillshape -
as well as IO functions like write, read and keypressed.

Any suggestions appreciated, thanks,

Kevin

const
   North = 0;
   East  = 90;
   South = 180;
   West  = 270;

procedure Graphics;   external 'c:\GRAPH.BIN';
procedure GraphMode;  external Graphics[0];
procedure GraphColorMode; external Graphics[3];
procedure HiRes;  external Graphics[6];
procedure HiResColor(Color: Integer); external Graphics[9];
procedure Palette(N: Integer);external Graphics[12];
procedure GraphBackground(Color: Integer);external Graphics[15];
procedure GraphWindow(X1,Y1,X2,Y2: Integer);  external Graphics[18];
procedure Plot(X,Y,Color: Integer);   external Graphics[21];
procedure Draw(X1,Y1,X2,Y2,Color: Integer);   external Graphics[24];

--
Kevin Lyda
Galway, Ireland
___
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] XML - Indent, text content, special char

[Bernd Oppolzer]

Am 30.04.2019 um 02:45 schrieb wkitt...@windstream.net:

On 4/29/19 1:27 PM, Gabor Boros wrote:
Is this not a bug? Lost of formatting is not disturb me but text 
between > and < is the data/text content of a node.


are you saying that you are trying to use fixed-width fields that are 
space-padded in XML files???





There is nothing wrong with that,
in fact I am aware of a typesetting system which uses XML as input,
and if you enclose your input text between certain tags ( or 
)

you expect that the blanks between those tags are preserved.

The W3C standards, IMO, don't tell anything about what a certain parser
etc. should do to XML content (IMO, not much), there are not many 
restrictions

(<, of course, should be ) ... attributes are different, of course.

Kind regards

Bernd


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

Re: [fpc-pascal] Can FPC optimize: if (s[i]='a') or ...

[Bernd Oppolzer]

Am 15.04.2019 um 08:29 schrieb Tomas Hajny:

On Mon, April 15, 2019 07:52, Bernd Oppolzer wrote:
  .
  .

On Samstag, 13. April 2019 22:30:55 CEST Alexey Tor. wrote:

  .
  .

Can FPC optimize it so it only reads s[i] once (to register), not 3
times?

  .
  .

True for New Stanford Pascal:

  .
  .

I fail to see how is this related to FPC or the question of the original
poster (who was explicitly asking about FPC). Could we stay on topic,
please?

Tomas
(one of FPC mailing list moderators)



well, I was hoping for an answer out of the FPC community
what FPC does to the different codings, so that the users can
get some guidelines out of it (for example: common subexpressions
in locigal expressions are not eliminated, so it is better to use the IN 
syntax -

or maybe the other way round). My mails were meant to motivate this :-)

but so far only suggestions how to optimize at the source code level.

(and of course: because FPC is sort of inspiration for my work,
I would like to see what FPC does in this cases and to compare it
with what I have)

Sorry about that ...

Best regards

Bernd


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

Re: [fpc-pascal] Can FPC optimize: if (s[i]='a') or ...

[Bernd Oppolzer]

Am 15.04.2019 um 03:35 schrieb wkitt...@windstream.net:

On 4/14/19 7:28 AM, Rainer Stratmann wrote:

On Samstag, 13. April 2019 22:30:55 CEST Alexey Tor. wrote:

E.g. i have a loop which test each s[i] char for several cases: 'a',
'b', 'c'.

for i:= 1 to length(s) do

if (s[i]='a') or (s[i]='b') or (s[i]='c') then ...

Can FPC optimize it so it only reads s[i] once (to register), not 3 
times?


You can optimise by yourself.

var
  c : char;
  l : longint;

begin
  l := length( s );
  for i := 1 to l do
   c := s[ i ];
   if ( c = 'a' ) or ( c = 'b' ) or ( c = 'c' ) then ...



this looks like it will read three times like the original instead of 
once like using the IN set operation... it is still stepping through 
each one of the comparison steps instead of just doing a set match...





True for New Stanford Pascal:

 23   1N   1)    for I := 1 to LENGTH ( S ) do
 24   2N   1)  begin
 25   2N   1)    C := S [ I ] ;
 26   2N   1)    if ( C = 'a' ) or ( C = 'b' ) or ( C = 'c' 
) then
 27   2N   1)  WRITELN ( I , '-tes Zeichen ist a, b 
oder c' ) ;

 28   2N   1)  end (* for *)

Lines without @@ = P-Code
Lines with @@ = IBM 370 Machine Code (Assembler notation)
as documented by Stage 2 (PASCAL2.PAS) when the A+ switch is set

 LOC  26 
 0250:   LOD  C,1,424
 0250:   LDC  C,'a'
 0250:   EQU  C
@@ 0250:   CLI   424(13),97  --- compare storage location with 'a'
 0254:   LOD  C,1,424
@@ 0254:   LA    2,1
@@ 0258:   BC    8,*+6
@@ 025C:   SR    2,2
 025E:   LDC  C,'b'
 025E:   EQU  C
@@ 025E:   CLI   424(13),98  --- compare storage location with 'b'
 0262:   IOR  B
@@ 0262:   LA    3,1
@@ 0266:   BC    8,*+6
@@ 026A:   SR    3,3
@@ 026C:   OR    2,3
 026E:   LOD  C,1,424
 026E:   LDC  C,'c'
 026E:   EQU  C
@@ 026E:   CLI   424(13),99  --- compare storage location with 'c'
 0272:   IOR  B
@@ 0272:   LA    3,1
@@ 0276:   BC    8,*+6
@@ 027A:   SR    3,3
@@ 027C:   OR    2,3
 027E:   FJP  L16
@@ 027E:   BC    8,L16


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

Re: [fpc-pascal] Can FPC optimize: if (s[i]='a') or ...

[Bernd Oppolzer]

Am 13.04.2019 um 21:55 schrieb Ralf Quint:

On 4/13/2019 12:30 PM, Alexey Tor. wrote:
E.g. i have a loop which test each s[i] char for several cases: 'a', 
'b', 'c'.


for i:= 1 to length(s) do

if (s[i]='a') or (s[i]='b') or (s[i]='c') then ...

Can FPC optimize it so it only reads s[i] once (to register), not 3 
times?



How about writing it in Pascal, something like

if s[i] in ['a'..'c'] then

or in case of no-sequential characters/values

if s[i] in ['a', 'b', 'c'] then...


Ralf



I'd like to second that ... the benefit that the optimizer may get
when IN is used ...

I would like to show you what my New Stanford Pascal compiler does;
it does not eliminate the common expressions s[i], but evaluates
them 3 times, given the original coding. But when the IN expression is used
(this coding: if s[i] in ['a', 'b', 'c'] then...)
it does a very good job. Because the three constants in the set are a
close range without holes in it, it checks in fact the range.

This is how it looks in IBM 370 ASSEMBLY language:

@@ 01AE:   SR    3,3      -- clear register 3
@@ 01B0:   IC    3,404(13,2)      -- insert character s[i] into 
register 3 (register 2 has index i, 404/13 is the address of s)
@@ 01B4:   AH    3,=H'-97'      -- subtract constant 'a' - should be 
EBCDIC 'a', but is ASCII 'a', because I tested on the PC :-)

@@ 01B8:   CL    3,=F'2'      -- check, if register 3 is between 0 and 2
@@ 01BC:   BC    2,L12      -- branch, if not

This is the result after the second step of the translation;
the first step is the translation to P-Code. The P-Code looks like this
(the Index I is on top of the stack at the beginning, the address of
S at the second position):

 01AE:   DEC  I,1  -- dec top of stack
 01AE:   IXA  1      -- use top of stack as index for 
address at second position
 01AE:   IND  C,0      -- replace top of stack (= address) 
with content of type char

 01AE:   ORD  -- convert to integer (does nothing)
 01B4:   LCA  S,C32'abc'  -- load character set constant
 01B4:   SLD  32,432  -- convert to binary set 
representation

 01B4:   INN  -- implement IN on elements on stack
 01BC:   FJP  L12  -- jump false

On the IBM mainframe, this P-Code is translated to what you see above.
On the other platforms (Windows, Linux, ...), the P-Code is interpreted -
a version of the compiler which generates native code on these platforms
has still to be done. But anyway: the language is fully portable, the 
results

are the same. (The P-Code is portable, the 370 implementation is of course
NOT portable - hence the problem when testing the 370 translation on the 
PC).


The optimization (implementing IN as a range check in this case) is
in fact done in stage 2, that is: in the P-Code to 370 translator.
The credits for this very fine compiler technology (which is about
40 years old) does not belong to me, but to many other people who
worked on this in the 1975 to 1990 era. I only did some extensions
to it in the last few years and ported the compiler to Windows and
Linux etc.

More information:

http://bernd-oppolzer.de/job9.htm
https://www.facebook.com/StanfordPascal

Kind regards

Bernd


___
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

[Bernd Oppolzer]

Am 07.10.2018 um 00:46 schrieb Graeme Geldenhuys:

On 06/10/18 20:15, Santiago A. wrote:

places, so can't use Currency data type.

6 decimals, no currency that's a problem ;-)

Yeah, tell me about it.


you must specify : "Discount will be applied to each item".
64bits is a lot of precision, but don't be overconfident, even in such
case errors can skyrocket with divisions with small divisors and/or a
lot of operations. Comparing to zero is always dangerous, you'd better
round the number to 6 decimals before comparing.

The product I work on is Royalties and Licensing across the globe for
very large and medium sized companies. A single contract can span
millions to billions of accounting lines, then you have to calculate
royalties on all those and make sure afterwards that adding them all up
still equals the original amounts. A huge pain and very lengthy process.

If it was up to me, I would have opted to converted all amounts to
integers as early as possible, do the calculations and then divide by
the correct amount to get the decimals required for reporting purposes.
But then, this product was developed long before I joined the company,
and changing it now would be a mammoth task. So for now, I've got to
work with what I've got - as most of us has to do. ;-)


Regards,
   Graeme



I examined the rounding problem with floating point arithmetic on 
different platforms
in the 1995 time frame, when I had to find a solution for a customer of 
mine (a large
insurance company) for the following problem: the insurance math package 
should
yield the same results for computations using double float values, 
although the computation
is done (using C) on very different platforms (for example Intel and IBM 
mainframe),
where the floating point formats are not compatible. The source of the 
problem, BTW,
is the binary or hexadecimal coding of the mantissa of the floating 
point values,
which doesn't matter when doing scientific calculations, but which is a 
problem,

when dealing with commercial problems and decimal rounding.

With some help from a math specialist, I found a solution (a rounding 
function
for floating point values) which produces the same (decimal) results in 
most cases,

no matter what the platform and the floating point representation is.

I then built this function (converted to Pascal) into the runtime of my
New Stanford Pascal compiler, so that every FP value is implicitly 
rounded before

output (that is: before WRITE or WRITELN) to the number of decimal places
requested by this WRITE or WRITELN. This way, the output results of
WRITE and WRITELN of FP values after certain computations were the
same on all platforms (again: IBM mainframe and Windows PC, for example),
which was not the case before my extension.

The story is documented in more detail here (including the
Pascal source code of the rounding function):

http://bernd-oppolzer.de/job9i032.htm

Have fun!

Another option: there are some libraries which support BCD arithmetic
(binary coded decimals) ... and even platforms which support decimal 
arithmetic

directly; but this will probably be no option for you.

Kind regards

Bernd
___
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

[Bernd Oppolzer]

Some corrections, see below ...


Am 03.10.2018 um 11:54 schrieb Bernd Oppolzer:

The explanation for the results is as follows:

the first three codings do the multiplication first, then the division.
the last two first division, then multiplication. That makes the 
difference.


When division is done first, you get an intermediate result of 1.0 
exactly.


This is correct, because the same two input values go into the division.
1.0 can be represented correctly as FP value.

The subsequent multiplication yields 51009.9 exactly, so the 
difference is zero.


Wording needs improvement; the value is not 51009.9 exactly, but it is the
nearest machine number, which is the same as the other operand (the same
number multiplied by 1.0) of the subtraction, so the result will be zero.


No risk for rounding errors.

When the multiplication is done first, you get a very large result 
which cannot

be stored exactly in the machine representation. When divided by 51009.9,
the result differs by a little epsilon from 1.0, so the difference is 
shown


Should be:
the result may differ by a little epsilon from the original machine 
representation

of 51009.9; this epsilon may be shown instead of zero.


as the final result.

Depending on the FP representation chosen, you will see the difference 
or not.

When I tested the program with my New Stanford Pascal compiler, I saw the
different computation sequence in the generated code, but I didn't get a
difference. But that's pure luck.

Example:


this is in fact the real P-Code produced by the New Stanford compiler
for the hypothetical stack machine; different for the two cases.



Multiplication first:

 LOC 21
 LOD R,1,416
 LOD R,1,408
 LOD R,1,416
 MPR
 LOD R,1,424
 DVR
 SBR
 STR R,1,432

Division first:

 LOC 23
 LOD R,1,416
 LOD R,1,408
 LOD R,1,416
 LOD R,1,424
 DVR
 MPR
 SBR
 STR R,1,432

The result was zero in both cases.

Kind regards

Bernd



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.


Can anybody explain this, especially the first 3 very small negative 
numbers that Delphi and FPC produces? I know  not all floating point 
values can be stored exactly (or something like that), and when doing 
calculations, it might do a auto data type conversion. But is any of 
that taking place here?


The only positive I can see, is that FPC and Delphi are consistent. :-)

Here is the Object Pascal test:

===[ TestOperatorPrecedence.pas ]=
program TestOperatorPrecedence;

{$IFDEF FPC}
  {$mode objfpc}{$H+}
{$ELSE}
  {$apptype console}
{$ENDIF}

var
  a,b,c,d: double;
  ans: extended;
begin
  a := 1.0;
  b := 51009.9;
  c := 51009.9;
  d := 51009.9;
  writeln(b);
  writeln(c);
  writeln(d);
  writeln('---');

  ans := c - b * c / d;
  writeln(ans);

  ans := c - (b * c) / d;
  writeln(ans);

  ans := c - (b * c / d);
  writeln(ans);

  ans := c - b * (c / d);
  writeln(ans);


  ans := c - (b * (c / d));
  writeln(ans);
end.
==

And the results are:
graeme.geldenhuys@UKCM-L500737 C:\devel\tests\OperatorPrecedence

TestOperatorPrecedence.exe

 5.100990E+0004
 5.100990E+0004
 5.100990E+0004
---
-3.55271367880050E-0015
-3.55271367880050E-0015
-3.55271367880050E-0015
 0.00E+
 0.00E+


And here is the Java equivalent...


===[ TestOperatorPrecedence.java ]
public class TestOperatorPrecedence {

public static void main(String[] args) {
    double b = 51009.9;
    double c = 51009.9;
    double d = 51009.9;
    double ans;

    System.out.println(b);
    System.out.println(c);
    System.out.println(d);
    System.out.println("-");

    ans = c - b * c / d;
    System.out.println(ans);

    ans = c - (b * c) / d;
    System.out.println(ans);

    ans = c - (b * c / d);
    System.out.println(ans);

    ans = c - b * (c / d);
    System.out.println(ans);


    ans = c - (b * (c / d));
    System.out.println(ans);
}
}

==

And the results are:
graeme.geldenhuys@UKCM-L500737 C:\devel\tests\OperatorPrecedence

java TestOperatorPrecedence

51009.9
51009.9
51009.9
-
0.0
0.0
0.0
0.0
0.0



Regards,
  Graeme



___
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


___
fpc-pascal maillist  -  fpc-pascal@lists.freepasca

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

[Bernd Oppolzer]

The explanation for the results is as follows:

the first three codings do the multiplication first, then the division.
the last two first division, then multiplication. That makes the 
difference.


When division is done first, you get an intermediate result of 1.0 exactly.
The subsequent multiplication yields 51009.9 exactly, so the difference 
is zero.

No risk for rounding errors.

When the multiplication is done first, you get a very large result which 
cannot

be stored exactly in the machine representation. When divided by 51009.9,
the result differs by a little epsilon from 1.0, so the difference is shown
as the final result.

Depending on the FP representation chosen, you will see the difference 
or not.

When I tested the program with my New Stanford Pascal compiler, I saw the
different computation sequence in the generated code, but I didn't get a
difference. But that's pure luck.

Example:

Multiplication first:

 LOC 21
 LOD R,1,416
 LOD R,1,408
 LOD R,1,416
 MPR
 LOD R,1,424
 DVR
 SBR
 STR R,1,432

Division first:

 LOC 23
 LOD R,1,416
 LOD R,1,408
 LOD R,1,416
 LOD R,1,424
 DVR
 MPR
 SBR
 STR R,1,432

The result was zero in both cases.

Kind regards

Bernd



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.


Can anybody explain this, especially the first 3 very small negative 
numbers that Delphi and FPC produces? I know  not all floating point 
values can be stored exactly (or something like that), and when doing 
calculations, it might do a auto data type conversion. But is any of 
that taking place here?


The only positive I can see, is that FPC and Delphi are consistent. :-)

Here is the Object Pascal test:

===[ TestOperatorPrecedence.pas ]=
program TestOperatorPrecedence;

{$IFDEF FPC}
  {$mode objfpc}{$H+}
{$ELSE}
  {$apptype console}
{$ENDIF}

var
  a,b,c,d: double;
  ans: extended;
begin
  a := 1.0;
  b := 51009.9;
  c := 51009.9;
  d := 51009.9;
  writeln(b);
  writeln(c);
  writeln(d);
  writeln('---');

  ans := c - b * c / d;
  writeln(ans);

  ans := c - (b * c) / d;
  writeln(ans);

  ans := c - (b * c / d);
  writeln(ans);

  ans := c - b * (c / d);
  writeln(ans);


  ans := c - (b * (c / d));
  writeln(ans);
end.
==

And the results are:
graeme.geldenhuys@UKCM-L500737 C:\devel\tests\OperatorPrecedence

TestOperatorPrecedence.exe

 5.100990E+0004
 5.100990E+0004
 5.100990E+0004
---
-3.55271367880050E-0015
-3.55271367880050E-0015
-3.55271367880050E-0015
 0.00E+
 0.00E+


And here is the Java equivalent...


===[ TestOperatorPrecedence.java ]
public class TestOperatorPrecedence {

public static void main(String[] args) {
    double b = 51009.9;
    double c = 51009.9;
    double d = 51009.9;
    double ans;

    System.out.println(b);
    System.out.println(c);
    System.out.println(d);
    System.out.println("-");

    ans = c - b * c / d;
    System.out.println(ans);

    ans = c - (b * c) / d;
    System.out.println(ans);

    ans = c - (b * c / d);
    System.out.println(ans);

    ans = c - b * (c / d);
    System.out.println(ans);


    ans = c - (b * (c / d));
    System.out.println(ans);
}
}

==

And the results are:
graeme.geldenhuys@UKCM-L500737 C:\devel\tests\OperatorPrecedence

java TestOperatorPrecedence

51009.9
51009.9
51009.9
-
0.0
0.0
0.0
0.0
0.0



Regards,
  Graeme



___
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] round(2.5)=2

[Bernd Oppolzer]

Am 08.06.2018 um 14:47 schrieb Klaus Hartnegg:

Hi,

The round function behaves different than in TurboPascal, and its 
English Wiki page differs from the German page.


When given an argument halfway between to integers, FreePascal rounds 
to the nearest even number, TurboPascal always rounds up (except when 
it is set to mode $N+, but default is $N-).


The German Wiki pages for Round and SetSoundMode (URLs below) contain 
a warning to not use SetRoundMode, because that also affects internal 
calculations, and how numbers are stored in variables when they do not 
fit with full precision.


How serious is this issue compared with using a different rounding 
method?


The german pages suggest to use this function instead:
function round(x: Float): Integer;  { requires unit math for 'float' }
begin
  if x > 0 then
  round := trunc(x + 0.5)
  else
  round := -trunc(-x + 0.5);
end;

That is fine, except that I will likely forget it in some unit, and 
manually inspecting all units is less reliable than when the compiler 
ensures it.




This is not sufficient, IMO, when using float,
look here:

http://bernd-oppolzer.de/job9i032.htm

In Turbo-Pascal the browsing feature (search,symbol) of the IDE can 
show a list of all places where system.round gets called. The 
FreePascal IDE does not show that list (see my other email).


Is there some other reliable(!) way to fix or check this? Maybe a map 
file with all functions that got linked into the executable?


The Wiki pages are
- wiki.freepascal.org/Round
- wiki.freepascal.org/Round/de
- wiki.freepascal.org/SetRoundMode
- wiki.freepascal.org/SetRoundMode/de

If the warning is correct, there should also be a note on
https://www.freepascal.org/docs-html/rtl/math/setroundmode.html

thanks,
Klaus
___
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] Feature announcement: Dynamic array extensions

[Bernd Oppolzer]

Am 03.06.2018 um 18:12 schrieb Sven Barth via fpc-pascal:
Bernd Oppolzer <mailto:bernd.oppol...@t-online.de>> schrieb am So., 3. Juni 2018, 11:56:




Am 02.06.2018 um 15:14 schrieb Sven Barth via fpc-pascal:

Mark Morgan Lloyd mailto:markmll.fpc-pas...@telemetry.co.uk>> schrieb am Sa., 2.
Juni 2018, 10:53:

However as Dennis points out + is also essential for vector
operations.
Perhaps either leaving it to the programmer to define what's
needed
would be the best approach, or alternatively splitting
dynamic arrays
into mathematical vectors and non-mathematical collections.
Or relaxing
the requirement that only predefined operators can be
redefined, so that
something like _ could be used for concatenation.


That needlessly complicates the parser as the compiler still
needs to know them and they also need to be part of its operator
precedence rules. Don't complicate the language for nothing! And
in the end operator overloads are one of the best examples for
syntactic sugar as you can easily achieve the same result with
functions and methods.

Regards,
Sven



This is somehow off topic of course,
but IMO it is strange to use + for string concatenation;
I always have bad feelings about this. This whole thread would
not exist, if FreePascal had gone another direction like PL/1, for
example,
where the string concatenation operator is ||
(and DB2, and - probably - other SQL dialects).


FPC inherited the +-operator for concatenation from the base language: 
Pascal. So there simply was no other route to take (not that anyone 
would have thought to take a different route).



Where does this + for string concat come from?


Ask Wirth, he is the one who invented Pascal...



AFAIK, the Pascal Standard (ISO) does not tell anything about strings
and concatenation. Wirth did not include varying length strings into
the language in the 197x years. Every Pascal compiler which contains
strings and concatenation does this by extending the Pascal Standard
and can choose its own way to do it.

IBMs Pascal/VS uses || for string concatenation (inspired by PL/1, 
probably),

and that's what I implemented in the New Stanford Pascal compiler, too.

The + for concatenation must be an invention of Turbo Pascal or UCSD Pascal
or something like that.


Regards,
Sven



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

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

[Bernd Oppolzer]

Am 02.06.2018 um 15:14 schrieb Sven Barth via fpc-pascal:
Mark Morgan Lloyd > schrieb am Sa., 2. Juni 
2018, 10:53:


However as Dennis points out + is also essential for vector
operations.
Perhaps either leaving it to the programmer to define what's needed
would be the best approach, or alternatively splitting dynamic arrays
into mathematical vectors and non-mathematical collections. Or
relaxing
the requirement that only predefined operators can be redefined,
so that
something like _ could be used for concatenation.


That needlessly complicates the parser as the compiler still needs to 
know them and they also need to be part of its operator precedence 
rules. Don't complicate the language for nothing! And in the end 
operator overloads are one of the best examples for syntactic sugar as 
you can easily achieve the same result with functions and methods.


Regards,
Sven



This is somehow off topic of course,
but IMO it is strange to use + for string concatenation;
I always have bad feelings about this. This whole thread would
not exist, if FreePascal had gone another direction like PL/1, for example,
where the string concatenation operator is ||
(and DB2, and - probably - other SQL dialects).

Where does this + for string concat come from?

(Of course, || has some codepage issues, but that's another story,
and it means logical or in other languages ...)

BTW:

this is (part of) the input for the scanner generator
for the New Stanford Pascal compiler:

SYLPARENT := '(';

SYRPARENT := ')';

SYLBRACK := '[' OR '(.' OR '(/';

SYRBRACK := ']' OR '.)' OR '/)';

SYCOMMA := ',';

SYSEMICOLON  := ';';

SYARROW := '->' OR '@' OR '^';

SYPERIOD := '.';

SYDOTDOT := '..';

SYCOLON := ':';

SYPLUS := '+';

SYMINUS := '-';

SYMULT := '*';

SYSLASH := '/';

SYEQOP := '=';

SYNEOP := '<>';

SYGTOP := '>';

SYLTOP := '<';

SYGEOP := '>=';

SYLEOP := '<=';

SYOROP := '|';

SYANDOP := '&';

SYASSIGN := ':=';

SYCONCAT := '||';

if you want to change the representation of the symbols, you only change 
here.


Kind regards

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

Re: [fpc-pascal] pointerful

[Bernd Oppolzer]

program TESTPT ( OUTPUT ) ;

//
//$A+ ... enable Assembler output
//

type PT = -> PT ;

var PTEST : PT ;

function LQUEUE ( P : PT ) : INTEGER ;

   var L : INTEGER ;

   begin (* LQUEUE *)
 L := 0 ;
 while P <> NIL do
   begin
 P := P -> ;
 L := L + 1
   end (* while *) ;
 LQUEUE := L
   end (* LQUEUE *) ;

begin (* HAUPTPROGRAMM *)
  NEW ( PTEST ) ;
  NEW ( PTEST -> ) ;
  NEW ( PTEST -> -> ) ;
  NEW ( PTEST -> -> -> ) ;
  NEW ( PTEST -> -> -> -> ) ;
  NEW ( PTEST -> -> -> -> -> ) ;
  PTEST -> -> -> -> -> := NIL ;
  WRITELN ( LQUEUE ( PTEST ) ) ;
end (* HAUPTPROGRAMM *) .


the result is:

c:\work\pascal\work>pcint prr=testpt.prr inc=paslibx,pasutils, 
pas=testpt.pas out=testpt.prrlis


PCINT (Build 1.0 Apr  5 2018 07:58:58)

   5

c:\work\pascal\work>


this is the New Stanford Pascal compiler,
a modern variant of Wirth's P4 compiler.

that is:

type
 PINT = -> INT ;
 INT = PINT ;
 PT = -> PT ;

this is all possible in Standard Pascal, IMO,
although not very useful, of course.

Kind regards

Bernd



Am 22.04.2018 um 23:30 schrieb Alexander Grotewohl:

imagine a linked list.. with nothing but the pointers.. lol


On 4/22/2018 1:05 PM, Jonas Maebe wrote:

On 22/04/18 17:00, Mattias Gaertner wrote:


Is this a bug or a feature:

type
   Pint = ^int;
   int = PInt;

?


It's a bug.


Jonas
___
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


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

Re: [fpc-pascal] procedure and function parameters?

[Bernd Oppolzer]

Am 04.03.2018 um 18:45 schrieb Sven Barth via fpc-pascal:

On 04.03.2018 18:06, Bernd Oppolzer wrote:

Are procedure and function parameters allowed in Free Pascal?

When I tried to compile the Man-or-boy example program (Knuth's test),
FPC complained with a syntax error:


c:\work\pascal\work>fpc manorboy.pas
Free Pascal Compiler version 3.0.0 [2015/11/16] for i386
Copyright (c) 1993-2015 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling manorboy.pas
manorboy.pas(41,28) Fatal: Syntax error, "identifier" expected but
"FUNCTION" found
Fatal: Compilation aborted
Error: C:\FPC\3.0.0\bin\i386-win32\ppc386.exe returned an error exitcode


This is the place where the function parameter appears in the
definition of the function A:


function A ( K : INTEGER ; function X1 : INTEGER ; function X2 :
    INTEGER ; function X3 : INTEGER ; function X4 : INTEGER ;
    function X5 : INTEGER ) : INTEGER ;

There is only one solution that currently really will work with that
kind of code: use {$mode iso} at the top of the file to use the ISO
Pascal compatible mode.

In theory it should also be possible to use another mode plus
{$modeswitch nestedprocvars}, but that doesn't play nicely with the call
to A inside of B as the compiler seems to call the X4 parameter while it
shouldn't...

Regards,
Sven



Thanks,

mode iso worked without problems;
the results were as expected.

Kind regards

Bernd

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

[fpc-pascal] procedure and function parameters?

[Bernd Oppolzer]

Are procedure and function parameters allowed in Free Pascal?

When I tried to compile the Man-or-boy example program (Knuth's test),
FPC complained with a syntax error:


c:\work\pascal\work>fpc manorboy.pas
Free Pascal Compiler version 3.0.0 [2015/11/16] for i386
Copyright (c) 1993-2015 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling manorboy.pas
manorboy.pas(41,28) Fatal: Syntax error, "identifier" expected but 
"FUNCTION" found

Fatal: Compilation aborted
Error: C:\FPC\3.0.0\bin\i386-win32\ppc386.exe returned an error exitcode


This is the place where the function parameter appears in the
definition of the function A:


function A ( K : INTEGER ; function X1 : INTEGER ; function X2 :
   INTEGER ; function X3 : INTEGER ; function X4 : INTEGER ;
   function X5 : INTEGER ) : INTEGER ;


   function B : INTEGER ;

  begin (* B *)
    K := K - 1 ;
    B := A ( K , B , X1 , X2 , X3 , X4 ) ;
  end (* B *) ;


   begin (* A *)
 if K <= 0 then
   begin
 A := X4 + X5 ;
   end (* then *)
 else
   begin
 A := B ;
   end (* else *) ;
   end (* A *) ;

Thank you, kind regards

Bernd


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

Re: [fpc-pascal] Scoped enums and inferred types

[Bernd Oppolzer]

Am 21.02.2018 um 16:29 schrieb Ryan Joseph:



On Feb 21, 2018, at 10:13 PM, Michael Van Canneyt  
wrote:

You lose an important type safety if you replace them with constants.

I like enums also but you can imagine when they were proposed the compiler 
teams probably compared them to constants and decided if they were worth it 
bloat or not (much like my suggestion and what Swift decided to do). Ultimately 
it’s just another thing the user can do themselves instead of compiler but if 
you follow that road too far you’re back to assembly (on the other end is 
Java/Swift super high level languages).

Btw did enums exist in the first Pascal specs? I honestly kind of forgot about 
them since I was doing desktop apps from C based API’s that used all constants.


the very first Pascal specifications of the 1970s had enums,
but they were called "scalar types" at that time.

see page 10: http://bernd-oppolzer.de/PascalReport.pdf
(page 18 of the PDF).

Kind regards

Bernd




Regards,
Ryan Joseph

___
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] Freepascal Floating Point Issue

[Bernd Oppolzer]

Am 24.08.2017 um 14:00 schrieb James Richters:


Thanks everyone for the explanation and solutions.  I can work around 
it well enough now that I understand what’s happening, but I’m still 
curious if there is a way to define fixed point variables?  In a C++ 
Project I was helping with recently, they had a way of defining a 
variable as having 2 places before the decimal and 30 places after? 
Since the decimal could never move (float) It ended up being much 
better defined.   It’s like always moving the decimal over 30 places 
to the right, using integer math, then moving it back.  I’m not sure 
if this was something the compiler did, or if maybe they had their own 
functions to do this… I had a difficult time following how things 
worked, but I do remember the fixed point variables.  Anyway I thought 
I would just ask the question in case there is a way to define this in 
FreePascal


It seems to me that if you know you never need more than a fixed 
number of places before and after the decimal, then moving the decimal 
over the maximum number of places, performing integer math, which 
would round to the nearest integer(and cut off the useless garbage), 
then moving the decimal back would mean a fixed amount of precision 
with the benefit that one could do things like exact conditionals and 
get the expected result


James




IBM mainframes have decimal data types involving 31 decimal digits
(maximum); the numbers of digits left and right of the decimal point
may be chosen freely. The types are all compatible and promoted to
floating point, when necessary. The mainframe languages, like PL/1
and COBOL, support them natively, and mainframe C, too:

   int x, y;
   decimal (15,2) amt;
   ...

These decimal data types are supported by the hardware (by
machine instructions). This was an optional feature in the 1960s,
but the modern machines of today all support it.

The decimal data is implemented as BCD data; hex digits are
decimal digits, and a sign half byte is added, that makes 16 bytes
for 31 digits. If shorter numbers are needed, less bytes are allocated
(all lengths from 1 to 16 are supported). All decimal fields have
odd numbers of digits.

I am thinking about adding support for decimal data in one of the
next versions of my Stanford Pascal compiler, which targets this
platform, as well as Windows, Linux, macOS etc.; of course, this
decimal format will need to be emulated on the non-mainframe
platforms.

For some years now, the mainframe also supports floating point
data based on a decimal representation. But I don't have experience
with this so far. Some compilers support this (PL/1).

Kind regards

Bernd

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

Re: [fpc-pascal] Freepascal Floating Point Issue

[Bernd Oppolzer]

Am 24.08.2017 um 15:02 schrieb el es:

On 24/08/17 13:26, Sven Barth via fpc-pascal wrote:
[...]

Note: FPC (and Delphi) has a single fixed point type which is
Currency. AFAIK it uses four digits after the comma and 28 in front
of it.

Regards, Sven


There was a project I remember, that I was told, for some e.g. tax purposes,
4 digits after the decimal point are not enough to round them properly...
That is because, the calculation of e.g. VAT has to work out both ways 
(total=net+VAT and
has to work out in every way, including when a bigger package is split into 
smaller units)
and 4 decimal digits are not always enough to ensure this (and the program had 
to work
internationally with all the different tax rules too) for arbitrarily large 
quantities, prices and tax bands.

I don't remember the exact details (it long time ago and couple of workplaces 
ago), of what they did,
but the team developing it (in D7) was pretty stressed...


When you do calculations of actual values of
on-board securities, you need 8 digits after the decimal point
and more, because the stock quotation already has 6 digits after
the decimal point, and you have to multiply that with the quantity,
which has decimal parts, too.

With decimal arithmetic, rounded multiplication is pretty simple:
you multiply the two items, giving a result with one decimal digit
more as you need, then you round the result.

In PL/1:

   value = round (multiply (quantity, quotation, 15, 3), 2);

gives the rounded value in Euro, no matter how many digits after
the decimal point quantity and quotation had. The multiply function
will take care of the proper scaling and stop after the third digit
which is sufficient to round at the second position.

Kind regards

Bernd



-l.

___
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] Food for thought - language string improvement

[Bernd Oppolzer]

Am 06.07.2017 um 18:32 schrieb Andreas:


For this reason I would be against this implementation. Maybe taking 
away the need for the + sign at the end of the line. The strings are 
concatenated until a semi-colon or other symbol is encountered


This is what the (new) Stanford Pascal compiler does:

program TESTLSTR ( OUTPUT ) ;

var ZEILE : array [ 1 .. 200 ] of CHAR ;
I : INTEGER ;

begin (* HAUPTPROGRAMM *)
  ZEILE := ''
   ''
   ''
   ''
   '' ;
  WRITELN ( ZEILE ) ;
  MEMSET ( ADDR ( ZEILE ) , 'b' , 200 ) ;
  WRITELN ( ZEILE ) ;
  for I := 1 to 200 do
ZEILE [ I ] := '=' ;
  WRITELN ( ZEILE ) ;
end (* HAUPTPROGRAMM *) .

that is: long strings may be concatenated simply by closing
the string constant on one line and reopening it on the next line.

http://bernd-oppolzer.de/job9.htm

HTH, kind regards

Bernd

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

Re: [fpc-pascal] named parameter

[Bernd Oppolzer]

IMO, it's not about named parameters;
furthermore, it is not about readability, but this IMO
is a maintenance issue.

Think about a procedure that has two parameters and a lot of callers
and you want to add a third one.

it would be nice if you could specify a default value for the new
third parameter and don't have to change all the callers that use
only two.

So IMO a sensible extension to the Pascal syntax could be:

if there is a initialization on the procedure declaration, the parameter
is optional.

Example:

procecure P (x : integer; y : boolean; c: char := ' ');

the first two parameters are mandatory, the third is optional.
Calls to P with 2 and 3 parameters are both valid.

Another extension would be:

specify the formal parameter's name on call, that is:

P (y := true, c := '*', x := 25);

which allows for a different sequence of arguments on the procedure call

but this is a different topic and should be discussed seperate from the
default issue.

I guess, that all this will be limited to byvalue parameters ... not for
var parameters ...

Kind regards

Bernd


Am 27.05.2017 um 08:17 schrieb Mr Bee via fpc-pascal:

Hi,

As Pascal mostly well known as a safe, easy to read, and elegant 
language, don't you think Pascal needs named parameter? I mean for ALL 
kind of parameters, not just for Variants. When you have a function 
with many parameters having default values, you know that named 
parameter is desirable. For example:


function f(p1: string = ''; p2: integer = 0; p3: boolean = false);

But you only need to supply the third parameter, you still must supply 
the first and second ones with appropriate default values, like this:


f('', 0, true);

while with named parameter, you can do this:

f(p3 := true);

I believe it would raise Pascal's code readability. I know it has been 
discussed before. I know somehow the parser had been able to read such 
syntax. So, why don't we have the option to enable it for people who 
want it? Kinda a syntax switch mode.


What do you think? :)

--

Regards,


–Mr Bee


___
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] bitwise operations using AND, OR, XOR, NOT

[Bernd Oppolzer]

Am 08.01.2017 um 23:04 schrieb Sven Barth:





This depends on the Pascal compiler you use;
the old Wirth "Standard" yields syntax errors, if you use and etc. on types
other than boolean:


We're here on the FPC mailing list, so I personally only care about the
capabilities of FPC and that definitely supports bitwise operations (and
so do TP and Delphi).

Regards,
Sven



In the meantime I read some articles about the history of FPC and TP and
Delphi and learned that these extensions had been made very early
in this history.

While I mentioned some days before that I don't want to compete with FPC
with my product, which is an extension of Stanford Pascal aka AAEC Pascal
(a Wirth P4 descendant) and which I ported recently to Windows, OS/2 and
Linux, I anyway will continue to add features that I consider useful.

So here we go:

1  LINE #  D/NEST  LVL < STANFORD PASCAL, OPPOLZER VERSION OF
01.2017 >21:55:58  10.01.2017PAGE   1
   --  -- ---  ---

1   ) program TESTAND ( OUTPUT ) ;
2   )
3   ) var X , Y : INTEGER ;
4360D  1) A , B : BOOLEAN ;
5362D  1)
6362D  1) begin (* HAUPTPROGRAMM *)
7   )   X := 0X0E ;
8  1N  1)   Y := 0X1D ;
9  1N  1)   A := FALSE ;
   10  1N  1)   B := TRUE ;
   11  1N  1)   WRITELN ( 'x' , X ) ;
   12  1N  1)   WRITELN ( 'y' , Y ) ;
   13  1N  1)   WRITELN ( 'x and y  ' , X and Y ) ;
   14  1N  1)   WRITELN ( 'x and y  ' , X & Y ) ;
   15  1N  1)   WRITELN ( 'x or y   ' , X or Y ) ;
   16  1N  1)   WRITELN ( 'x or y   ' , X | Y ) ;
   17  1N  1)   WRITELN ( 'x xor y  ' , X XOR Y ) ;
   18  1N  1)   WRITELN ( 'not x' , not X ) ;
   19  1N  1)   WRITELN ( 'not y' , not Y ) ;
   20  1N  1)   WRITELN ( 'a' , a ) ;
   21  1N  1)   WRITELN ( 'b' , b ) ;
   22  1N  1)   WRITELN ( 'a and b  ' , A and B ) ;
   23  1N  1)   WRITELN ( 'a and b  ' , A & B ) ;
   24  1N  1)   WRITELN ( 'a or b   ' , A or B ) ;
   25  1N  1)   WRITELN ( 'a or b   ' , A | B ) ;
   26  1N  1)   WRITELN ( 'a xor b  ' , A XOR B ) ;
   27  1N  1)   WRITELN ( 'not a' , not A ) ;
   28  1N  1)   WRITELN ( 'not b' , not B ) ;
   29  1N  1) end (* HAUPTPROGRAMM *) .

   NO SYNTAX ERROR(S) DETECTED.
   29 LINE(S) READ,0 PROCEDURE(S) COMPILED,
  232 P_INSTRUCTIONS GENERATED,   0.00 SECONDS IN COMPILATION.

and the outcome:


c:\work\herc\pcode>pcint prr=testand.prr inc=passtrx,paslibx,
pas=testand.pas out=testand.prrlis

PCINT (Build 1.0 Jan 10 2017 21:51:56)

x  14
y  29
x and y12
x and y12
x or y 31
x or y 31
x xor y19
not x -15
not y -30
aFALSE
bTRUE
a and b  FALSE
a and b  FALSE
a or b   TRUE
a or b   TRUE
a xor b  TRUE
not aTRUE
not bFALSE

*** Pascal Programm STP ***


More information: http://bernd-oppolzer.de/job9.htm

Kind regards

Bernd


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

Re: [fpc-pascal] C# translatation

[Bernd Oppolzer]

Am 08.01.2017 um 18:22 schrieb Sven Barth:


Am 08.01.2017 17:32 schrieb "Bernd Oppolzer" 
<bernd.oppol...@t-online.de <mailto:bernd.oppol...@t-online.de>>:

>
> Am 08.01.2017 um 11:46 schrieb Sven Barth:
>>
>> On 08.01.2017 10:55, Ryan Joseph wrote:
>>>
>>> I’m going to attempt to translate a perlin noise function (from 
https://gist.github.com/Flafla2/f0260a861be0ebdeef76) but there are a 
few things that stopped me from starting.

>>>
>>> 1) What is & doing in this assignment? I see this many places in 
assignments.

>>>
>>> int h = hash & 15;
>>
>> That's an "and".
>
>
> Please keep in mind that & is a bitwise and in C
> whereas && is a logical and;
> this makes much difference and has to be implemented or converted 
differently

> with Pascal, IMO.
>
> the closest equivalence to bitwise and in Pascal are set 
intersections, IMO.


The closest equivalence to bitwise and in Pascal is bitwise and.
The operators "and", "or", "xor" and "not" are logical or bitwise 
depending on their arguments.


Regards,
Sven




This depends on the Pascal compiler you use;
the old Wirth "Standard" yields syntax errors, if you use and etc. on types
other than boolean:

1  LINE #  D/NEST  LVL < STANFORD PASCAL, OPPOLZER VERSION OF 
01.2017 >18:32:47  08.01.2017PAGE   1

   --  -- ---  ---

1   ) program TESTAND ( OUTPUT ) ;
2   )
3   ) var X , Y : INTEGER ;
4360D  1)
5360D  1) begin (* HAUPTPROGRAMM *)
6   )   X := 12 ;
7  1N  1)   Y := 25 ;
8  1N  1)   WRITELN ( 'x and y' , X and Y ) ;
   E134
9  1N  1) end (* HAUPTPROGRAMM *) .

    1 SYNTAX ERROR(S) DETECTED.
    9 LINE(S) READ,0 PROCEDURE(S) COMPILED,
   17 P_INSTRUCTIONS GENERATED,   0.02 SECONDS IN COMPILATION.

   LAST ERROR/WARNING ON LINE -->   8

   ERROR/WARNING CODES FOR THIS PROGRAM :
    134 : ILLEGAL TYPE OF OPERAND(S).

I agree that bitwise and etc. is a useful extension and will
put it on my to-do list.

Have a nice day.

Kind regards

Bernd

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

Re: [fpc-pascal] C# translatation

[Bernd Oppolzer]

Am 08.01.2017 um 11:46 schrieb Sven Barth:

On 08.01.2017 10:55, Ryan Joseph wrote:

I’m going to attempt to translate a perlin noise function (from 
https://gist.github.com/Flafla2/f0260a861be0ebdeef76) but there are a few 
things that stopped me from starting.

1) What is & doing in this assignment? I see this many places in assignments.

int h = hash & 15;

That's an "and".


Please keep in mind that & is a bitwise and in C
whereas && is a logical and;
this makes much difference and has to be implemented or converted 
differently

with Pascal, IMO.

the closest equivalence to bitwise and in Pascal are set intersections, 
IMO.


If I had to implement that on integers using standard pascal, this would
cause me some headache ...

Kind regards

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

Re: [fpc-pascal] C translation question

[Bernd Oppolzer]

What I wanted to say:

when translating the for loop to Pascal, you are in danger of introducing
logic errors, because the Pascal for loop is kind of restricted compared to
the C for loop (which is in fact simply a while loop with another 
notation).


But if you translate the C for loop to a while loop first, then you can
translate this loop in a straightforward manner to Pascal, and the 
probability

of inserting logic errors is much lower.

Kind regards

Bernd


Am 23.10.2016 um 22:20 schrieb Bernd Oppolzer:

it might help if I translate the C for loop into an equivalent
while loop for you, (and eliminating the ++ construct),
simply mechanically, without knowing anything about the application.

This results in:

int pnpoly (int nvert, float *vertx, float *verty, float testx, float 
testy)

{
  int i, j, c = 0;

  i = 0, j = nvert-1;

  while (i < nvert)
  {
if (((verty [i] > testy) != (verty [j] > testy)) &&
 (testx < (vertx[j] - vertx[i]) * (testy - verty [i])
  / (verty [j] - verty [i]) + vertx [i]))
   c = !c;

j = i;
i = i + 1;
  }

  return c;
}

HTH,

kind regards

Bernd



Am 22.10.2016 um 11:06 schrieb Ryan Joseph:
I’m trying to translate a function from C (taken from 
http://www.ecse.rpi.edu/Homepages/wrf/Research/Short_Notes/pnpoly.html) 
and although I think I got it correctly it’s not behaving 100% 
accurately so I’m not sure if it was my translation or not. The “for” 
statement is pretty confusing to my eyes despite the author of the 
function giving a description of his code.


Does anyone spot any errors with my translation?

int pnpoly(int nvert, float *vertx, float *verty, float testx, float 
testy)

{
   int i, j, c = 0;
   for (i = 0, j = nvert-1; i < nvert; j = i++) {
 if ( ((verty[i]>testy) != (verty[j]>testy)) &&
  (testx < (vertx[j]-vertx[i]) * (testy-verty[i]) / 
(verty[j]-verty[i]) + vertx[i]) )

c = !c;
   }
   return c;
}


function TPolygonHelper.ContainsPoint (point: TPoint): boolean;
var
i, j, c: integer;
begin
i := 0;
j := high(self);
c := 0;
for i := 0 to high(self) do
begin
j := i + 1;
if ((self[i].y > point.y) <> (self[j].y > point.y))
and (point.x < (self[j].x - self[i].x) * (point.y 
- self[i].y) / (self[j].y - self[i].y) + self[i].x) then

c := not c;
end;
result := c <> 0;
end;

Regards,
Ryan Joseph

___
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] C translation question

[Bernd Oppolzer]

it might help if I translate the C for loop into an equivalent
while loop for you, (and eliminating the ++ construct),
simply mechanically, without knowing anything about the application.

This results in:

int pnpoly (int nvert, float *vertx, float *verty, float testx, float testy)
{
  int i, j, c = 0;

  i = 0, j = nvert-1;

  while (i < nvert)
  {
if (((verty [i] > testy) != (verty [j] > testy)) &&
 (testx < (vertx[j] - vertx[i]) * (testy - verty [i])
  / (verty [j] - verty [i]) + vertx [i]))
   c = !c;

j = i;
i = i + 1;
  }

  return c;
}

HTH,

kind regards

Bernd



Am 22.10.2016 um 11:06 schrieb Ryan Joseph:

I’m trying to translate a function from C (taken from 
http://www.ecse.rpi.edu/Homepages/wrf/Research/Short_Notes/pnpoly.html) and 
although I think I got it correctly it’s not behaving 100% accurately so I’m 
not sure if it was my translation or not. The “for” statement is pretty 
confusing to my eyes despite the author of the function giving a description of 
his code.

Does anyone spot any errors with my translation?

int pnpoly(int nvert, float *vertx, float *verty, float testx, float testy)
{
   int i, j, c = 0;
   for (i = 0, j = nvert-1; i < nvert; j = i++) {
 if ( ((verty[i]>testy) != (verty[j]>testy)) &&
  (testx < (vertx[j]-vertx[i]) * (testy-verty[i]) / (verty[j]-verty[i]) + 
vertx[i]) )
c = !c;
   }
   return c;
}


function TPolygonHelper.ContainsPoint (point: TPoint): boolean;
var
i, j, c: integer;
begin
i := 0;
j := high(self);
c := 0;
for i := 0 to high(self) do
begin
j := i + 1;
if ((self[i].y > point.y) <> (self[j].y > point.y))
and (point.x < (self[j].x - self[i].x) 
* (point.y - self[i].y) / (self[j].y - self[i].y) + self[i].x) then
c := not c;
end;
result := c <> 0;
end;

Regards,
Ryan Joseph

___
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] For .. in .. loops with sets and valued enums

[Bernd Oppolzer]

Maybe types should be forbidden at this place completely.

Look at this:


1.) with subrg type - works ok !!

program testin;

type subrg = 1..10;

var i: integer;

begin
  for i in  subrg  do begin
writeln (i)
  end
end.


2.) with subrg type in in-expression - gives syntax error

program testin;

var i: integer;

begin
  for i in  1.. 10 do begin
writeln (i)
  end
end.


3.) with set constant in in-expression - works ok

program testin;

var i: integer;

begin
  for i in [1.. 10] do begin
writeln (i)
  end
end.


Only the 3rd example should be supported, IMO.

Kind regards

Bernd



Am 20.06.2015 um 14:03 schrieb Michael Van Canneyt:



On Sat, 20 Jun 2015, Jonas Maebe wrote:


On 20/06/15 12:01, Michael Van Canneyt wrote:



On Sat, 20 Jun 2015, Jonas Maebe wrote:


On 20/06/15 11:41, Michael Van Canneyt wrote:

But it is a bug that the compiler does not give an error for the set
type. Please report it.


Should it work with any set types at all? (I don't mean set variables,
but set types) Or even with any type? It seems very much like 
something

that was accidentally introduced, like what was reverted with
http://wiki.freepascal.org/User_Changes_2.6.0#.3COrdinal.3E_in_.3CSet_type.3E_is_now_forbidden 



It should definitely work with sets, that was explicitly asked (I am
sure, because I asked). I use it in my code.


Again: set *variables* or set *types*?


Ah sorry, I misunderstood your remark. Variables.
I don't see the point of allowing it on a set type. You can just as 
well use the underlying enum.


Michael.
___
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] with statement using mulltiple objects

[Bernd Oppolzer]

Am 14.09.2014 15:39, schrieb Ched:

Hello All,

My two cents. The with statement is crystal clear for me. If newbies 
prefer to use different manners to code the things, that are free to 
do it. Using some kind of intermediate variable  ? That's make to code 
difficult to understand, need do open begin/end blocks in some 
situations. With make the code very clear, probably helps the compiler 
a lot. Well used, it's 100% safe - I *never* encountered any problems 
with it in 25+ years of intensive programmation.


So, they with statement has at least one aficionados: me. Was the with 
statement present if the first versions designed by Wirth himself ?



WITH was present in the first PASCAL versions,
and it was used in the PASCAL compilers designed by Wirth et al.
written in PASCAL in the late 60s and early 70s.

The possible dangers of using WITH are only very limited, compared
to other languages, for example PL/1, where

- you don't need to declare variables, like in FORTRAN
- you can omit structure qualifiers, if the the structure components 
alone are unique
- if the structure component is A.B.C, you can write A.C, B.C or simply 
C, if it is unique in the program
- if there is both a simple variable C and a structure component A.C (C 
in an outer block),
I guess, A.C will be used, if you write only C (but I am not sure on 
this; hopefully there will be

a compiler warning)
- if you have a combination of vectors and structures, the order of 
structure components
and vector indices is not fixed, that is: A.C(N,M) is the same as 
A(N).C(M) is the same as
A(N,M).C ... regardless of the definition of the structures / vectors A 
and C.


You may read some old articles from Dijkstra and C.A.R. Hoare on this 
topic,
covering PL/1 ... it is very hard to write reliable programs using this 
language,
but it is still in use until today in very large banks and insurance 
companies.

I am using it in my everyday work.

So: I would use the PASCAL WITH statement with care, knowing its problems.
PASCAL is far less dangerous than PL/1.

The other language which I use much is C. There you have other problems that
PASCAL (and PL/1) don't have, that is: vector indices out of range, 
leading to
storage overwrites, and storage leaks, due to heavy use of dynamic 
memory allocation ...
which needs careful testing. Both PASCAL and PL/1 can be used with 
options that
control the vector indices, which is IMHO a great help in the early 
stages of program

development.

Kind regards

Bernd


Cheers, Ched'



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

Re: [fpc-pascal] with statement using mulltiple objects

[Bernd Oppolzer]

The reason why I made these comparisons to PL/1:

PL/1 was designed in the mid 60s, and Wirth of course knew about PL/1,
because he was at IBM at the time, and of course he was aware of the 
problems
and pitfalls of PL/1. By including the WITH statement into PASCAL, he 
probably
wanted to give the coders some possibilities for an abbreviation 
(similar to PL/1,
but avoiding most of the problems). As we look at it today, not all 
problems have been

avoided.

Of course, most inspirations for PASCAL came from ALGOL 60. But ALGOL 60
had no structures, so PL/1 was the natural source of inspiration, at 
that time.


Kind regards

Bernd


Am 14.09.2014 16:30, schrieb Bernd Oppolzer:

The possible dangers of using WITH are only very limited, compared
to other languages, for example PL/1, where

- you don't need to declare variables, like in FORTRAN
- you can omit structure qualifiers, if the the structure components 
alone are unique
- if the structure component is A.B.C, you can write A.C, B.C or 
simply C, if it is unique in the program
- if there is both a simple variable C and a structure component A.C 
(C in an outer block),
I guess, A.C will be used, if you write only C (but I am not sure on 
this; hopefully there will be

a compiler warning)
- if you have a combination of vectors and structures, the order of 
structure components
and vector indices is not fixed, that is: A.C(N,M) is the same as 
A(N).C(M) is the same as
A(N,M).C ... regardless of the definition of the structures / vectors 
A and C.


You may read some old articles from Dijkstra and C.A.R. Hoare on this 
topic,
covering PL/1 ... it is very hard to write reliable programs using 
this language,
but it is still in use until today in very large banks and insurance 
companies.

I am using it in my everyday work.



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

Re: [fpc-pascal] struct definition in C

[Bernd Oppolzer]

Am 23.03.2014 19:54, schrieb Jonas Maebe:

On 23/03/14 19:39, Darius Blaszyk wrote:


What would be the equivalent of the following struct definition in C?

typedef struct MyStruct
{
  unsigned a :6;
  unsigned b :15;
  unsigned c:11;
}MyStruct;

I imagine this is some sort of struct initialization. Is thi spossible
in FPC as well, or what is the best alternative?


It's not an initialization, it's a struct with bitfields. FPC 
currently does not support C-compatible bitfield packing. To get a 
record with equal alignment and size you can declare it as record 
data: cuint; end;, but there is currently no way in FPC to access the 
bitfields in a portable way across platforms.



Jonas


I would like to add that bitfields in C are not at all portable;
it is completely implementation dependant if they are
allocated from right to left in the structure or the other way round etc.;

I do lot of portable development in C, and I never use bitfields for 
that reason;

if I really need to store information in single bits, I use ints or chars
and access the individual bits using logical operations. Of course,
the problem with big-endian / little-endian has to be taken into 
account, too
(not, if you use unsigned chars as the base for the bit strings, and if 
the chars are

eight bits long, which should be the case on all modern architectures).

Kind regards

Bernd

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

Re: [fpc-pascal] DoDirSeparators and special filenames on Windows

[Bernd Oppolzer]

On Windows, too:

C:\cd \backup\\\///\\\sich

C:\backup\sich

Only the first backslash has to be (only one) backslash;
no slash allowed.

Kind regards

Bernd



Am 11.09.2013 19:36, schrieb Reimar Grabowski:

On Wed, 11 Sep 2013 17:37:36 +0200
Jürgen Hestermann juergen.hesterm...@gmx.de wrote:


And double delimiters *are* ambiguous:
Has a (one letter) file name been forgotten or was an additional
delimiter typed (or appended by bad programmed routines)?

Ambiguity is not defined by how the symbol came into being. You just look at 
the symbol as is.
So Mattias statement *is* correct.


I am realy astonished that nobody seems to find anything wrong with this.

user@computer:/tmp$ mkdir hans
user@computer:/tmp$ mkdir hanspete
user@computer:/tmp$ cd hans
user@computer:/tmp/hans$ ls -la
total 12
drwxrwxr-x 3 user user 4096 Sep 11 19:13 .
drwxrwxrwt 9 root root 4096 Sep 11 19:13 ..
drwxrwxr-x 2 user user 4096 Sep 11 19:13 pete

Nothing wrong. All fine and dandy.

IEEE Std 1003.1, 2004 Edition (http://pubs.opengroup.org/onlinepubs/009695399/) 
says:

3.266 Pathname

A character string that is used to identify a file. In the context of IEEE Std 
1003.1-2001, a pathname consists of, at most, {PATH_MAX} bytes, including the 
terminating null byte. It has an optional beginning slash, followed by zero or 
more filenames separated by slashes. A pathname may optionally contain one or 
more trailing slashes. Multiple successive slashes are considered to be the 
same as one slash.

R.

Disclaimer: I know that Linux is not Unix and not Posix.



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

Re: [fpc-pascal] Breaking Pascal source lines

[Bernd Oppolzer]

Am 06.09.2013 15:10, schrieb Mark Morgan Lloyd:
I'm sure there isn't a single right answer to this question, but if 
transferring Pascal source to a system that enforces short lines (e.g. 
78 chars + CRLF) what's the best automatic breaking rule?


One possibility is obviously to break after the rightmost space, but 
is it valid to break after e.g. . (if not followed by a digit), ^ and 
possibly others?


Syntax errors are acceptable. Truncation isn't.


To keep the syntax correct, you can break after every symbol, that is:

not inside identifiers,
not inside numbers (including floating point constants)
not inside quoted strings

but anywhere else

I am using a Pascal pretty print program, that knows
about the syntax (a little) and outputs the source in
lines of 72 chars at most - this limit can be modified via parameter, IIRC.

But: at the moment it accepts only classical Pascal syntax (my extension
of Stanford P4) - no FPC. So it makes not much sense to share it.
But I compiled it with FPC recently, and it ran without problems on 
Windows.


Kind regards

Bernd

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

Re: [fpc-pascal] Breaking Pascal source lines

[Bernd Oppolzer]

Am 06.09.2013 18:16, schrieb Bernd Oppolzer:

To keep the syntax correct, you can break after every symbol, that is:

not inside identifiers,
not inside numbers (including floating point constants)
not inside quoted strings

but anywhere else

I am using a Pascal pretty print program, that knows
about the syntax (a little) and outputs the source in
lines of 72 chars at most - this limit can be modified via parameter, 
IIRC.


But: at the moment it accepts only classical Pascal syntax (my extension
of Stanford P4) - no FPC. So it makes not much sense to share it.
But I compiled it with FPC recently, and it ran without problems on 
Windows.


Kind regards

Bernd



it's not quite correct;
if there are symbols like := that consist of more than one char,
you must not break in the middle.

Kind regards

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

Re: [fpc-pascal] ++ and -- ( and +=, -=, ...)

[Bernd Oppolzer]

Am 31.07.2013 11:33, schrieb Sven Barth:
Technically it would be simple to change that as the corresponding 
code is already available for the above mentioned situation, but it 
would definitely change the semantics if the left side is e.g. an 
array with a function as index accessor (as the function is then only 
called once)...

I believe it would be much better if FPC would do this
(that is, evaluate the left side on assignments like a += b
only once), because the other program languages like
C and PL/1 that provide the same syntax do it the same way.
So people who use other languages too will be less surprised.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] ++ and --

[Bernd Oppolzer]

Am 30.07.2013 18:20, schrieb Mark Morgan Lloyd:


Now specifically to your question - I believe that one of the reasons 
may

be the fact that Pascal does not support unary arithmetic operators in
postfix notation. The fact that C allows using them with both prefix and
postfix notation makes them even more difficult from my point of view
because potentially allowing them only in one of the notations known 
from

other languages would immediately trigger users to ask why only one of
possible notations (common elsewhere) is supported and the other not.


I've got a vague recollection that some of the ++ and -- semantics are 
particularly unpleasant, and that one of the C inventors did his best 
to disown them. At least += etc. are fairly unambiguous: they're 
almost macro expansions and as such they don't mandate any extra 
overloadable operators etc.




FWIW:

the += etc. assignment operators make sense IMO,
because for complex expressions involving array indices etc.
that are to be incremented or decremented, it is no more necessary
to write them twice.

Compared to that, the difference between ++ and += 1
(with ++ you have to put parantheses around the expression to be 
incremented !!)

seems unimportant.

And, if that's a matter for you: the newer PL/1 compilers
support += etc., but don't support ++ and --,

Kind regards

Bernd


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