Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

[Blaise]

On 08.12.2019 22:30, Sven Barth wrote:

there is no official way to access such parameters


1) At the time of providing that answer on Stack Overflow, Barry Kelly worked as a DCC 
developer. While it is not truly official, it is pretty close, and satisfies my criterion 
of "fully conforming to the ABI and particularities of the compiler".
2) That statement of yours is factually incorrect. Again.


there is no stock implementation in Delphi for *any* platform


You remind me of a certain Rudy from the old EMBT forums. It is one thing to 
not know something due to the lack of experience (with DCC), but to keep 
insisting despite being repeatedly told otherwise takes an admirable amount of 
self-confidence :P
--8<--
procedure Foo; cdecl; varargs;
var Z: TVarArgList;
begin
VarArgStart(Z);
writeln( VarArgGetValue(Z, Integer) );
writeln( VarArgGetValue(Z, PChar) );
VarArgEnd(Z)
end;
begin   {$AppType Console}
Foo(42, 'You know nothing')
end.
--8<--


But only on i386-win32 and x86_64-win64. On Sys V ABI x86_64 targets there is 
no way around it, because the arguments are passed in registers, not in the 
stack area.


Two mistakes on your part:
1) Much like SysV x64 ABI, Windows/x64 ABI does use registers for that.
2) Yet the non-stock solution still works, because DCC does support VARARGS 
(which I keep telling you, but you keep arguing pointlessly), so it spills the 
registers on the stack.


your patch WILL NOT allow that
we DO NOT WANT to support this


1) There is really no need to shout.
2) One reason I intended to allow that with my patch is compatibility with DCC. 
And I have only brought it up because your understanding of what DCC actually 
allows appears consistently to be lacking.
Should the team reject that aspect of my patch, I am not going to throw a hissy 
fit and angrily fork into NewNewPascal :)


And if I use the procvardef parser, I, like Jonas, would need to prohibit "OF OBJECT" and 
"IS NESTED".


The code of procvar_dec as it is currently does not forbid it. So that will 
need to be improved anyway.


Jonas prohibits them only when type constructor is used in a named type 
definition. That is one of the bugs I mentioned in the first email.




it's part of the specification (and I'm not arguing that!)


You said, verbatim:

from the user's point of view an anonymous function variable is essentially a 
procvar as well


The specification dictates that /your/ user should change his mental model from 
procvar to interface reference :)
And since "method reference types are interface types" is not only an 
implementation detail but now a part of the specification, I feel that parsing them as 
interfaces makes perfect sense.
Anyhow, for the second time I am asking you to stop reviewing code that has not 
been submitted. I would rather have feedback on 
https://lists.freepascal.org/pipermail/fpc-devel/2019-December/042264.html , 
which is kinda blocking me, and we have the subject issue blocking 3.2.

@Jonas: Has the team decided on the amended syntax for C-block references? I am 
ready to start implementing whichever.

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

Re: [fpc-devel] certain divisions in single precision only

[Florian Klämpfl]

Am 08.12.19 um 22:16 schrieb Marco van de Voort:


Op 2019-12-08 om 18:46 schreef Jonas Maebe:

-i386 delphi was available).
Actually, back then I thought I fixed the (dynamic) behaviour at least
in a Delphi-compatible way: https://bugs.freepascal.org/view.php?id=7179

I don't remember anymore on what test this assumption was based though.

Afaik Delphi x64 doesn't do single math at all, and converts each 
load/store from single to double, and only operates on doubles




Yes. It basically mimics the i386 behavior: doing all operations with 
the highest available precision.

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

Re: [fpc-devel] certain divisions in single precision only

[Marco van de Voort]

Op 2019-12-08 om 18:46 schreef Jonas Maebe:

-i386 delphi was available).
Actually, back then I thought I fixed the (dynamic) behaviour at least
in a Delphi-compatible way: https://bugs.freepascal.org/view.php?id=7179

I don't remember anymore on what test this assumption was based though.

Afaik Delphi x64 doesn't do single math at all, and converts each 
load/store from single to double, and only operates on doubles



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

Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

[Ryan Joseph via fpc-devel]

> On Dec 8, 2019, at 2:30 PM, Sven Barth via fpc-devel 
>  wrote:
> 
> And no, your patch WILL NOT allow that. We've consciously decided AGAINST 
> implementing varargs functions in Pascal (see 
> https://wiki.freepascal.org/User_Changes_2.6.0#Array_of_const_parameters_and_cdecl_routines
>  ) and we DO NOT WANT to support this.

Sorry to interject but I'm just curious why this hardline stance was taken.

Regards,
Ryan Joseph

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

Re: [fpc-devel] certain divisions in single precision only

[Martok]

Am 08.12.2019 um 18:41 schrieb Florian Klämpfl:

> As the delphi behavior is very i386/x86-64 specific, FPC deviates from 
> it (not to mention that the non-i386 behavior was implemented years 
> before a non-i386 delphi was available).

Jup, that's what I meant with "made runtime and compile time evaluation the
same". Without that change, cross and native compilers would have different
constant evaluation, which is obviously not good either.

Best,
Sebastian

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

Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

[Sven Barth via fpc-devel]

Am 07.12.2019 um 22:46 schrieb bla...@blaise.ru:

On 07.12.2019 21:39, Sven Barth wrote:
I'm arguing that there is no builtin way to *access* the parameters 
passed in such a way.


You are arguing that /now/, but it is not what you said earlier. You 
said, verbatim:
one can not access VarArgs parameters inside a Delphi function 
(without resorting to assembly)

Like I said, this is factually incorrect.


I had forgotten about pointers to the stack area which I got reminded 
off when I found the link I sent. But that doesn't change that there is 
no official way to access such parameters.





there are hacks


A custom va_list implementation, fully conforming to the ABI and 
particularities of the compiler, is not necessarily a hack. (In the 
sense that is not of questionable design, implementation quality, and 
maintainability.)



but this is not guaranteed to work on every platform.


Where did that requirement of "every platform" suddenly come from? One 
needs to roll out their own va_list implementations only for the 
platforms A) that he targets, and B) on which the stock implementation 
is not provided.


It's to show the restriction of the approach that is shown in the link. 
While it works on i386-win32 and probably also x86_64-win64 it would 
fail on e.g. x86_64-linux (or any other x86_64 platform following the 
Sys V ABI). I give you point A, but B is moot as there is no stock 
implementation in Delphi for *any* platform.





an anonymous function with varargs modifier will not be allowed anyway


Right. FTR, my patch will eventually allow exactly that, and so does 
DCC already.
Or are you still not aware of the latter? For the fourth time: VARARGS 
is allowed and works with DCC, on both sides, without BASM or ugly 
hacks, on more than one platform :) Some of them even have stock 
implementations of va_list, FPC should take a hint.


But only on i386-win32 and x86_64-win64. On Sys V ABI x86_64 targets 
there is no way around it, because the arguments are passed in 
registers, not in the stack area. That's why GCC implements the va[ist 
functionality using compiler intrinsics instead of macros as is the case 
on Windows.


And no, your patch WILL NOT allow that. We've consciously decided 
AGAINST implementing varargs functions in Pascal (see 
https://wiki.freepascal.org/User_Changes_2.6.0#Array_of_const_parameters_and_cdecl_routines 
) and we DO NOT WANT to support this.


So what will be allowed is this:

=== code begin ===

type
  TSomeProc = reference to procedure(aFmt: PChar); cdecl; varargs;

=== code end ===

but not this:

=== code begin ===

var
  proc: TSomeProc;
begin
  proc := procedure(aFmt: PChar) cdecl varargs
    begin
  { do something with aFmt and the variadic arguments }
    end;
end.

=== code end ===

Just as it is for procedure and method variables.

And yes, it makes sense to allow it for one, but to deny it for another, 
because as TSomeProc is an interface it can be used to interface (no pun 
intended) with external code that provides such an interface as well 
(e.g. delegates in COM/WinRT, though I have yet so see a varargs 
function there...).


For Pascal code there is "array of const" which is better anyway, cause 
all values contain type information about the passed value. And it works 
cross platform (which for FPC *is* important).




You need procvar specific functionality, because you need to restrict 
the available modifiers to those available for procvars.


And if I use the procvardef parser, I, like Jonas, would need to 
prohibit "OF OBJECT" and "IS NESTED". One extra work for another.


The code of procvar_dec as it is currently does not forbid it. So that 
will need to be improved anyway.





You extend tprocvardef.create with a doregister parameter
you convert the procvar to an interface method and then free the no 
longer required procvardef.


Right. The unnecessary work I am currently avoiding.
Since I have not yet submitted that part for review, let us avoid 
premature pointless discussion.


you're parsing something that's in essence a fancy procedure/method 
variable which is completely independant of it being implemented by 
an interface


"Completely independent"?
You do realise that method reference types "being <...> interface[s]" 
is pretty much a part of the specification?

--8<--
type M = reference to procedure (const N: Integer);
type C = class (TInterfacedObject, M)
procedure Invoke(const N: Integer); virtual; abstract;
end;
end.
--8<--

Yes, it's part of the specification (and I'm not arguing that!), but for 
the parser itself it is simply an implementation detail. Just like 
method pointers are implemented using a record that contains both a 
CodePointer and a data Pointer.


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] certain divisions in single precision only

[Jonas Maebe]

On 08/12/2019 18:41, Florian Klämpfl wrote:
> As the delphi behavior is very i386/x86-64 specific, FPC deviates from
> it (not to mention that the non-i386 behavior was implemented years
> before a non-i386 delphi was available).

Actually, back then I thought I fixed the (dynamic) behaviour at least
in a Delphi-compatible way: https://bugs.freepascal.org/view.php?id=7179

I don't remember anymore on what test this assumption was based though.


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

Re: [fpc-devel] certain divisions in single precision only

[Florian Klämpfl]

Am 08.12.19 um 18:17 schrieb Martok:

Indeed, this is by design. See
https://wiki.freepascal.org/User_Changes_2.2.0#Floating_point_constants for
how to explicitly specify a different precision.


That was long before the change Tomas discovered.

The gotcha here is about your fix to
, which together with the one you
linked made runtime and compile time evaluation the same, at the expense of
specifically breaking Delphi compat.

 From the current Delphi Reference:


In Delphi, intermediate results of Single precision floating-point
expressions are always implicitly stored as Extended on x86.

By default, all x64 arithmetic operations and expressions involving only
Single precision floating-point values retain high precision by storing
intermediate results as Double precision values.


But since then, FPC sees Single / Int2Single = Single, with no high precision
intermediates.


As the delphi behavior is very i386/x86-64 specific, FPC deviates from 
it (not to mention that the non-i386 behavior was implemented years 
before a non-i386 delphi was available).

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

Re: [fpc-devel] certain divisions in single precision only

[Martok]

> Indeed, this is by design. See 
> https://wiki.freepascal.org/User_Changes_2.2.0#Floating_point_constants for
> how to explicitly specify a different precision.

That was long before the change Tomas discovered.

The gotcha here is about your fix to
, which together with the one you
linked made runtime and compile time evaluation the same, at the expense of
specifically breaking Delphi compat.

From the current Delphi Reference:

> In Delphi, intermediate results of Single precision floating-point
> expressions are always implicitly stored as Extended on x86.
> 
> By default, all x64 arithmetic operations and expressions involving only
> Single precision floating-point values retain high precision by storing
> intermediate results as Double precision values.

But since then, FPC sees Single / Int2Single = Single, with no high precision
intermediates.
There was either a bug or a thread here about the code that broke and some
issues with explicit casts also not helping, but I can't seem to locate either.


Best,

Sebastian

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

Re: [fpc-devel] certain divisions in single precision only

[Jonas Maebe]

On 06/12/2019 14:43, Tomas L. via fpc-devel wrote:
> When a floating point constant which fits into single precision is
> divided by integer variable, the result is assumed to be a
> single-precision number. 

Indeed, this is by design. See
https://wiki.freepascal.org/User_Changes_2.2.0#Floating_point_constants
for how to explicitly specify a different precision.


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

[fpc-devel] certain divisions in single precision only

[Tomas L. via fpc-devel]

Dear fpc developers,

Let me submit a divison bug:

When a floating point constant which fits into single precision is divided
by integer variable, the result is assumed to be a single-precision
number.

program div5;
var  five:integer=5;
begin
writeln(1.0/five);
writeln(1.0/five-1/five);
end.

versions where problem spotted:
3.0.4 [2019/10/27] for x86_64 on windows
3.0.4+dfsg-18ubuntu2 [2018/08/29] for x86_64

older version with no problem:
fpc 2.6.4 i386-win32 is OK

Thanks

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