Re: [fpc-devel] Windows for AArch64
J. Gareth Moreton via fpc-devel schrieb am Sa., 25. Mai 2024, 22:18: > Indeed - I'm not giving up! I installed Clang via LLVM. Which of the EXE > files is actually the assembler? It's not entirely clear (no "clang-as", > for example). (Although I trust it works!) > Simply check what FPC calls. ;) I've got some ideas as to how to start debugging. I will solve this > puzzle! > There is a tool that converts DWARF to CodeView, you can use that to debug with WinDBG. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Windows for AArch64
J. Gareth Moreton via fpc-devel schrieb am Sa., 25. Mai 2024, 10:49: > Thought I'd give a small update. > > I was distracted over the past month with work, the arm-linux blocking > bug and a couple of merge requests which were much easier to develop! > I'm now having a solid bash at getting Windows on ARM64 working. It's > proving harder than anticipated because I can't install common helper > tools like Cygwin because there isn't a native AArch64 version available > (and x64 is not supported for emulation, it seems... only x86), and > Microsoft Visual Studio (which contains a working assembler) absolutely > refuses to install because Windows 10 on ARM64 is not supported, only > Windows 11 (and my Raspberry Pi is not "ready" to upgrade to Windows 11). > Emulation of x86_64 requires Windows 11 ;) You should be able to install clang natively, then you can use that assembler. After all that's the one we need to cooperate with anyway... > I did manage to get the make process to complete with the options that > Sven listed, but despite all of the packages building, the resultant > "ppca64" executable immediately exited with no messages or anything, > even if I specified "ppca64 -i" to display supported information. I'm > not sure if this is due to the bugs regarding exceptions and case > blocks, or some other reason. > It's very likely the case blocks, cause the compiler contains quite a lot of them. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] {$i ascdef.inc} / stdcall
Martin Frb via fpc-devel schrieb am Mo.,
6. Mai 2024, 14:11:
> Maybe of interest?
>
> The include file {$i ascdef.inc} is used from unit Windows with
> {$calling stdcall}
> in effect.
>
> Most functions in it therefore don't have "stdcall". But some do. Is
> that known/wanted/...?
>
> Similar in some other includes.
>
The majority of Windows functions indeed is stdcall, so the "$calling" is
correct as it simplifies things (though it might be cleaner to move it from
an include to the unit itself). Those functions that have an additional
"stdcall" modifier don't hurt.
The important point is that those few functions that really are "cdecl" are
marked as such.
Please note that "stdcall" does not matter on non-i386 as it's simply
mapped to the platform default there.
Regards,
Sven
>
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] apple properties // Re: Help/Guidance please: Dwarf support for properties
Martin Frb via fpc-devel schrieb am Fr., 3. Mai 2024, 12:13: > In case it goes ahead, I am trying to thing of what would be needed > Can anyone think of any feature for Pascal properties that is not > covered by the below? > A property can be marked "default". Currently only array properties, but there is still the idea to implement "hoisting" of sub members through single properties. Properties of type interface or class can have an "implements" clause that redirects the implementation of an interface implemented by the class (note: class type properties are not yet supported by FPC, but are on the ToDo list for Delphi compatibility). Oxygene introduced per setter/getter visibility and since I had need of this here and then in the past I might still be inclined to implement that in the future, so this might not only be for C# then. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Windows for AArch64
Am 29.04.2024 um 08:42 schrieb J. Gareth Moreton via fpc-devel: Aah, partially answered. It's not supported in 3.2.2, but there is better support for it in the trunk. You had me worried there for a moment that someone regenerated the makefiles with an older version of fpcmake... ^^' Anyway, aside from using main you need to make sure that you have a current version of clang installed and preferrably in PATH, because FPC uses it as assembler. You then call make like this (adding parallelisation options as desired of course): make all OS_TARGET=win64 CPU_TARGET=aarch64 BINUTILSPREFIX= (note that there is a space between the last "=" and the end of the command line) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Free Pascal for Windows aarch64 Bug Bounties
J. Gareth Moreton via fpc-devel schrieb am Sa., 27. Apr. 2024, 10:00: > You've piqued my interest. I currently only have the ability to develop > on aarch64-linux (Raspberry Pi 400), but I'm curious to know if I can get a > version of Windows to run on it, even if the performance will be very bad. > In a Pi 4 it runs relatively well. I've done it both natively and as a KVM. Check the WoRProject ( https://worproject.com/ ). A Pi 5 would be even better though there you currently might need to use KVM as the native drivers are still a work in progress. > So far I've tried to reproduce the issues on aarch64-linux without any > success. 40203 makes sense because it may be a specific issue with Windows > exception handling, but 40198 is a mystery because it's more closely tied > with code generation. Can you verify that the problem illustrated on 40198 > still occurs on the trunk? (I've confirmed that if there are more than 10 > case statements, the code generator attempts to use a jump table unless > optimisations are turned off) > It's a Windows specific issue, cause the PE format has slightly different relocation requirements than the ELF format. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Operator overloading question: Impossible to overload assignment for equal types. Why?
Bart via fpc-devel schrieb am Do., 25. Apr. 2024, 11:48: > > > Then declare a Copy management operator in the record. Unlike an > assignment operator these *must* be part of the record, thus the same rules > are applied for the same type everywhere unlike for operator overloads. See > also https://wiki.freepascal.org/management_operators > > So, I would have to declare something like this? > > class operator TArr.Copy(constref aSrc: TArr; var aDst: TArr); > begin > aDst.A := Copy(aSrc.A); > end; > > And then in my example: > > R1.A := [1,2,3]; > R2 := R1; > --> R2.A will be (1,2,3), and changing that will not affect R1.A anymore > Correct. > Sounds like a nice feature to have (in 3.4). > Management operators are already part of 3.2.x ( https://wiki.freepascal.org/FPC_New_Features_3.2.0#Management_operators_for_record_types ). Or did I misunderstand your remark? 樂 > I'll write some tests to get familiar with this and if I don't forget > I'll write a simple example in the wiki (there's a ToDo for that > currently). > Please do. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Operator overloading question: Impossible to overload assignment for equal types. Why?
Bart via fpc-devel schrieb am Mi., 24. Apr. 2024, 11:59: > Overloading the := (assignment) operator for equal types is forbidden. > Out of curiosity I would like to know why that is? > If there exists a built-in operator then overloading that operator is forbidden to avoid confusion when what operator might be used (operators can after all be declared *anywhere* and thus they might sometimes be used and sometimes not depending on which unit is used). > When you have e.g. a record definition containing a dynamic array, not > being able to overload the assignment operator is just a PITA. > Then declare a Copy management operator in the record. Unlike an assignment operator these *must* be part of the record, thus the same rules are applied for the same type everywhere unlike for operator overloads. See also https://wiki.freepascal.org/management_operators Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Modifiers...
Am 29.01.2024 um 21:56 schrieb Michael Van Canneyt via fpc-devel: I didn't say I cannot think of a legitimate use. I said it does not make sense to me, as in "I don't understand what people try to accomplish with this modifier". Unfortunately I still don't understand after your explanation what adding 'final' is supposed to accomplish. It may well be legitimate, but I have currently no opinion as I don't understand it. Maybe an actual code example would be more enlightening. That way I can also add it to the docs once I understand the intended use myself. It took me a while to find a suitable example, but now I've got one that's sounds useful. Assume you have a class TCleanup that deals with cleaning up some stuff with a virtual (maybe abstract) method named DoCleanup: === code begin === type TCleanup = class public procedure DoCleanup; virtual; end; === code end === Now assume there's a child class that does some very specific stuff in its DoCleanup method that relies on the order and where a user may only customize it a specific part: === code begin === type TWhateverCleanup = class private procedure Step1; procedure Step2; procedure Step3; protected procedure DoCustomCleanup; virtual; public procedure DoCleanup; override; end; procedure TWhateverCleanup.DoCleanup; begin Step1; Step2; DoCustomCleanup; Step3; end; === code end === Now as the class is now someone that inherits from TWhateverCleanup might override DoCleanup, but adding something in front of or after the DoCleanup call would be wrong. The ability to declare the method DoCleanup as final makes it clear to someone who inherits from the class, that no, you should not modify that, use a different way (in this case DoCustomCleanup) to customize its behavior. And when I came upon this example I noticed that we use a similar scheme inside the compiler: The tdef and tsym descendants have a virtual ppuwrite method. These classes have platform specific implementations so that e.g. the m68k tparavarsym descendant can write the register location for the syscall calling convention to the PPU. However due to how the writing to a PPU is implemented it's a bad idea to override the platform independant ppuwrite method, call inherited and then write the custom stuff. This had already led to problems in the past. Thus Jonas had introduced a new virtual ppuwrite_platform method that is supposed to be implemented by the platform specific descendants and made the platform independant ppuwrite implementations in the specific tdef and tsym implementations final so that no one that inherits from the tdef/tsym descendants gets the idea to mess inside that method again. I've learned - during my research - that this is called "safe design". Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Modifiers...
Am 29.01.2024 um 21:18 schrieb Michael Van Canneyt via fpc-devel:
On Mon, 29 Jan 2024, Sven Barth via fpc-devel wrote:
Am 28.01.2024 um 12:14 schrieb Michael Van Canneyt via fpc-devel:
2)
Is there, or has there once been?
(found in the synedit highlighter)
final
final comes after virtual/dynamic. Its supposed to stop you from
overriding
a method. Which is a bit strange because then you should not declare it
virtual to begin with.
A person that overrides virtual methods does not always have control
over whether the method had been declared as virtual.
Hm. That makes no sense at all to me ?
You normally add override only when you know the base class has virtual.
Otherwise, don't add virtual. The compiler will tell you if it was
possible
or not.
But that's the point: you *have* to add override. It will *always* be a
virtual method ("reintroduce" doesn't count, because that's essentially
the same as using a method with a completly different name). It's not in
the control of the user. With "final" the user has that control.
Especially in application code (*not* library code) this can be useful,
especially if the compiler generates different code in both cases (as
said the compiler doesn't need to go through the VMT then if called with
the real class type which can be important in performance relevant code).
Languages like C++, Java and C# all have these functionality as well and
only because *you* can't think of a legitimate use for it, doesn't mean
that no one can.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Modifiers...
Am 28.01.2024 um 12:14 schrieb Michael Van Canneyt via fpc-devel: 2) Is there, or has there once been? (found in the synedit highlighter) final final comes after virtual/dynamic. Its supposed to stop you from overriding a method. Which is a bit strange because then you should not declare it virtual to begin with. A person that overrides virtual methods does not always have control over whether the method had been declared as virtual. With "final" the user can tell the compiler that this method won't be overriden anymore and thus the compiler can change virtual method calls to direct method calls (assuming the compiler knows the class type involved for sure). It's similar to the WPO devirtualisation pass the compiler supports just without the need to compile the code twice. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Modifiers...
Am 24.01.2024 um 23:29 schrieb Martin Frb via fpc-devel: https://www.freepascal.org/docs-html/ref/refsu3.html Is this list complete/correct? 1) It lists bitpacked, but program foo; var bitpacked: integer; begin end; gives an error. I thought modifiers can be used as var names? "bitpacked" is not a modifier, but a keyword. 2) Is there, or has there once been? (found in the synedit highlighter) final As Michael wrote this can be used with methods to stop the virtual inheritance chain. On the JVM platform it can also be used with fields which can then only be initialized inside the constructor. automated As Michael wrote, not supported by FPC, but by Delphi. optional The "optional" keyword is in the context of Objective Pascal, just like "required" is (in contrast to "requires" which is used inside "package" files). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] WordBool or SmallInt ?
Martin Frb via fpc-devel schrieb am Fr., 29. Dez. 2023, 20:38: > fpc 3.2.3 > The below prog prints 3 times: 11, -1 (signed values) > > https://www.freepascal.org/docs-html/current/ref/refsu4.html#x26-250003.1.1 > > Free Pascal also supports the ByteBool, WordBool, LongBool and QWordBool > types. > These are of type Byte, Word, Longint or Int64, > > > Besides the fact that a "QWordBool" should be "Int64", they all seem to be > treated as signed. > The prefix refers to the width, not whether they are signed or not. > Yet at least the first two of them are documented as unsigned. > Internally they are handled as signed, but in the end it doesn't matter, because the only thing that counts for them is whether they're "0" aka "False" or "not 0" aka "True" (though that doesn't mean that all bits need to set, just that any bit needs to be 1). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Accidental file inclusion in repository
Am 29.11.2023 um 09:36 schrieb J. Gareth Moreton via fpc-devel: Hi everyone, I hate to point fingers, but there's a 0-byte file named "HEAD" in the repository, which causes git to throw a tantrum sometimes - it was introduced in the following commit: commit a4c324ee237674950e4675894df386519b75a130 Author: Rika Ichinose Date: Fri Apr 14 09:24:55 2023 +0300 Fill* for x64, physically sharing half of the code with FillChar. Florian has removed that file. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Build error, main branch, compiler/options.pas 889:33
drichards--- via fpc-devel schrieb am Sa., 11. Nov. 2023, 08:22: > I am getting an incorrect type error at line 889 column 33 in > compiler/options.pas. This is the , following the parameter More to the > function Copy. More is defined as a String. I do not understand why the > function Copy would have a problem with a String as its first parameter. > This is my first attempt to build the compiler. Am I making a newbie > mistake > here? > I am building on a Raspberry Pi, Bullseye, 64-bit with 8GB of RAM > and a 1T drive. How are you building the compiler? Regards, Sven > > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Maybe room for better documentation? open array as var param
Michael Van Canneyt via fpc-devel schrieb
am Do., 20. Juli 2023, 19:24:
>
>
> On Thu, 20 Jul 2023, Martin Frb via fpc-devel wrote:
>
> > For const param, it is well documented that the value (that includes the
> > variable that is passed) must not be changed.
> >
> > But for "var param"?
> >
> > Well maybe, but not explicit
> > https://www.freepascal.org/docs-html/ref/refsu68.html#x184-20800014.4.5
> > >> Open parameters can be passed by value, by reference or as a
> > constant parameter. In the latter cases the procedure receives a pointer
> > to the actual array.
> >
> > So a user with sufficient experience could detect that if a pointer is
> > received, then the value which is pointed to must not be changed.
> >
> > Maybe that should be mentioned more explicitly.
> > And maybe it should additionally also be mentioned on
> > https://www.freepascal.org/docs-html/ref/refsu65.html
> >
> >
> > Because the below may be unexpected to quite a few users.
> >
> > It will (at least on my test on windows / of course depends on mem
> > manager) print numbers starting at 300.
> > Even so 200++ has been assigned.
> >
> > But (with sufficient luck or lack of luck) "y" will re-use the memory of
> > "x". And "a" will then change "y" which may not be expected.
> >
> >
> > program Project1;
> > {$mode objfpc}
> >
> > var x,y: array of integer;
> > i: Integer;
> >
> > procedure foo(var a: array of integer);
> > var
> > j: Integer;
> > begin
> > x := nil;
> > SetLength(y, 10);
> > for j := 0 to 9 do y[j] := 200+j;
> >
> > for j := 0 to 9 do a[j] := 300+j;
> > end;
> >
> > begin
> > SetLength(x, 10);
> > for i := 0 to 9 do x[i] := 100+i;
> > foo(x);
> > for i := 0 to 9 do writeln(y[i]);
> > readln;
> > end.
>
> It's IMO probably better to outright forbid passing open array by
> reference.
>
There are valid use cases for that. E.g. multiply a slice of a dynamic
array by two or whatever. And forbidding var would solve nothing, see
below.
> printing length(a) after x:=Nil; gives 10, which is simply wrong.
>
That is true for many cases where you modify the global variable that has
been passed on by reference, e.g. with constant parameters: the compiler
will more often than not pass a reference then, because it's more optional
and the function can't modify it anyway, but if you change the global that
was passed in you get what you deserve... (that's true no matter if it's an
open array, a string or a primitive type).
Regards,
Sven
>
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Ordinal expression expected" awkwardness
J. Gareth Moreton via fpc-devel schrieb am Mi., 19. Juli 2023, 19:53: > Hi everyone, > > So I've come across a bit of awkwardness with the compiler. I'm not > sure if it's a well-defined rule that I've overlooked, but in a > for-loop, you can't use a 64-bit control variable when compiling for > i386-win32 (and presumably other 32-bit platforms), but you can under > x86_64-win64. In my case, the upper bound is a 64-bit variable (of type > TConstExprInt... a record type in the compiler source), so downsizing is > not ideal (although I will likely put in code that will error out if the > upper bound is too large due to the risk of an malicious inputs causing > said bound to equal 2^63 - 1 or 2^64 - 1). > > My example aside, should it be that there's a situation where pure Free > Pascal code can build on a 64-bit compiler but not a 32-bit compiler? > IFpermitting 64-bit control variables is too difficult for 32-bit > systems, should they be forbidden entirely or at least throw a warning? > > Kit > > P.S. As the title implies, trying to use a QWord or Int64 as a for-loop > control variable under i386-win32 causes an "Ordinal expression > expected" error, but compiles without incident on x86_64-win64. > It is indeed by design that not every integer type is a suitable index variable for a for-loop. In this case that a 64-bit variable can't be used on a platform with less than 64-bit width. The same is probably also true for 32-bit variables on platforms with less width (e.g. i8086, AVR, Z80). Cross platform code needs to cater for this accordingly. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] DW_AT_external and other additions to FPC generated dwarf
Martin Frb via fpc-devel schrieb am So.,
26. März 2023, 16:50:
> It also would fall short, if ever Fpc did what Delphi did:
> {$ZEROBASEDSTRINGS }
> Though, maybe that is a "wont ever happen".
>
FPC supports that directive since at least 3.2.0 (though apparently it was
forgotten to be documented in the New Features page).
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is this supposed to work (generic)?
Am 26.03.2023 um 13:30 schrieb Martin Frb via fpc-devel: 3.2.3 and 3.3.1 on Win 64bit Trying a generic linked list. So the specialized class must have an entry for the "next" element. And that entry is of the same type as the class itself. Now at first, this seems to be not possible using generics, because specialize does not allow to pass in the "partially done" class. (the 2 commented lines produce "Error: Illegal expression") Only it does work, if the class is forward declared. So is it supposed to work? And if it is in the last case, then what about the other two cases? program Project1; type generic GenLinkedList = class Data: D; Next: T; end; //TBar = specialize GenLinkedList; //TFoo = class(specialize GenLinkedList); TSome = class; TSome = class(specialize GenLinkedList); begin end. Btw, it is the same, if the linked list uses actual pointer. generic GenLinkedList = class type PT = ^T; public Data: D; NextPtr: PT; end; The correct way to declare a generic linked list using classes is the following: === code begin === type generic TGenLinkedList = class Data: D; Next: specialize TGenLinkedList; end; TSome = specialize TGenLinkedList; === code end === Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Inconsistency in generics ?
Martin Frb via fpc-devel schrieb am Fr., 3. März 2023, 12:55: > To me the below behaviour appears inconsistent. > But before I file a bug, I want to double check, if maybe this is > intention > > Tested with 3.2.3 and 3.3.1 > > Apparently > - when the generic TGen is compiled, it does check if a type "TRec1" and > "TRec2" is in scope at all. > - it verifies that the generic itself compiles with that type > - **but** then it allows that type to be replaced by another, if the > specialized param contains such another type > > So if the specialized class, can have a type of it's own choosing for > "TRec1" then why insist that a random other type of that name exists > when the generic is declared. > (And why reject "TRec2" as it too could be available at the time of > specialization?) > All identifiers must be known when declaring a generic. In this case Trec1 is known thanks to the global type. Trec2 is not known (neither in its parent (at declaration time TBase1) nor globally) , so that will fail. When you specialize with TBase2 you change the parent thus a completely new scoping situation arises and Trec1 will no longer be the global Trec1, but that of TBase2. Considering how generics are implemented this is both as expected and as designed. Not to mention that using the generic parameter as parent is *not* officially considered a feature. It's simply not forbidden. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Curious about the effect of all the new optimizations....
J. Gareth Moreton via fpc-devel schrieb am Mi., 1. März 2023, 12:25: > My peephole optimisations mostly save only a handful of cycles each time > which probably won't add up to much for a relatively short test. The > most major optimisation I can think of, although I'm not quite sure when > it was merged, is the method of replacing divisions by a constant with > an equivalent reciprocal multiplication. You'll see the biggest savings > there. There's other difficulties like processors being intelligent > with caching and out of order execution, for example, that are > disguising some inefficiencies. And some seek only to reduce code size > with no loss of speed. > > What are your timings like when compiling with COREAVX or COREAVX2? A > couple of recent peephole optimizations make use of BMI1 and BMI2. > > I can't remember the proverb that Florian used, but it essentially boils > down to very small changes, individually not amounting to much, but > which accumulate into a noticable difference when in large numbers. > It's a German proverb: "Mühsam ernährt sich das Eichhörnchen" Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Additional generic type constraints
Kostas Michalopoulos via fpc-devel schrieb am Mi., 22. Feb. 2023, 10:37: > > Because Delphi doesn't have them and when constraints were implemented > > they were implemented for Delphi compatibility. > > Can they be added? The original announcement ~13 years ago mentioned > that those could be added at some point. "object" and "operator X" would > be quite useful for me. > Some additional constraints might be added. However I have none of them planned currently and enough other things to do. > I tried to use constraints at some point in my code but they proven too > limited in functionality - the biggest issue i faced was that i couldn't > use a specialization with a forward declared class (which is the entire > point of the forward declaration). For example i have a generic > collection that only works on TSerializable subclasses so i gave it that > constraint, but in another unit i need to define a specialization for it > before it was defined (so the class was available with a forward class > declaration) since that specialization also needs to be used by the > class itself. In general it seems like having constrained generic work > with a tree structure of derived types that use the generic itself is > impossible. > > Wouldn't storing a list of "specializations to confirm later in this > unit" work (with later being when the class is actually defined in the > unit)? The language already has forward declarations for a bunch of > other things. > Forward declarations can not be used for constraints, because a specialization of the generic might be used before the forward declared type is fully defined and the compiler *must* be able to check whether the parameter in question is compatible at the time the specialization is declared. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Additional generic type constraints
Hairy Pixels via fpc-devel schrieb am So., 19. Feb. 2023, 03:54: > As a follow up to my other question, why doesn’t FPC support more types > for generic type constraints, like Pointer, Integer, String etc...? > Especially since we have implicit function specialization now allowing the > user to constrain the types more precision would help. > Because Delphi doesn't have them and when constraints were implemented they were implemented for Delphi compatibility. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Question on constref
Ondrej Pokorny via fpc-devel schrieb am Do., 2. Feb. 2023, 12:09: > Delphi cannot do it. FPC rocks! > > The only disadvantage is that you get a FreeAndNil copy for every type > you pass into the parameter (?) > > Do we want to change it in SysUtils? :) > As you might have noticed you need to add a modeswitch to enable this and this modeswitch is there for a reason (namely that this could lead to wrong code being used). So by default no one would benefit from this addition and probably not even know that it's there. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Question on constref
Ondrej Pokorny via fpc-devel schrieb am Do., 2. Feb. 2023, 10:06: > On 02.02.2023 07:42, Sven Barth via fpc-devel wrote: > > The case when you *need* a constant reference. Case in point: the > > passing of TGuid in IInterface.QueryInterface. Delphi code relies on > > it being a reference, but “const” does not guarantee that for all > > platforms. > > Maybe I am missing something, could you please explain why > IInterface.QueryInterface needs constref? > This isn't about Delphi, but about Windows (and XPCOM): there the IID parameter is declared as "REFIID" which is essentially a pointer. On x86 with stdcall this is not a problem, because there "const TGUID" will be passed as reference, same on x86_64 and also ARM64. However on ARM this is *not* the case (and which is how that issue was discovered). So to avoid having to add a cast to a PGUID to every QueryInterface call we instead decided to introduce "constref" which results in fewer modifications for existing code. Maybe somebody knows a real use case? > There are cases were you really need a reference and want it to be const. Or were you want to avoid a copy *for sure* (e.g. Embedded targets). Only because you can't see a reason for it doesn't mean that it doesn't exist. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Question on constref
Adriaan van Os via fpc-devel schrieb am Do., 2. Feb. 2023, 09:57: > Sven Barth wrote: > > Adriaan van Os via fpc-devel > <mailto:fpc-devel@lists.freepascal.org>> schrieb am Do., 2. Feb. 2023, > > 02:47: > > > > Sven Barth via fpc-devel wrote: > > > > > There is no full documentation for that parameter modifier > (someone > > > might want to file a bug report for that), but the documentation > for > > > “const” ( > > > > > > https://www.freepascal.org/docs-html/current/ref/refsu67.html#x183-20700014.4.4 > > > > > ) contains this: > > > > > > === doc begin === > > > > > > Contrary to Delphi, no assumptions should be made about how const > > > parameters are passed to the underlying routine. In particular, > the > > > assumption that parameters with large size are passed by > > reference is > > > not correct. For this the constref parameter type should be used, > > which > > > is available as of version 2.5.1 of the compiler. > > > > > > === doc end === > > > > On debate, see FPC issue 17442. > > > > > > There is no debate planned for this in the near future. So even if this > > might change some time in the future it does not *now* and very likely > > also not for 3.4.0. Not to mention that things wouldn't change for most > > platforms anyway, because they only have the platform ABI available and > > that *must not* change for compatibility with C code. > > "Will not change" and "ABI" are non arguments. They do not address the > questions put forward here: > > - under what circumstances (and in what compiler mode) does FPC pass large > (say 1 MB or 1 GB) > "const" parameters by value (which is extremely inefficient) ? > - for what reasons ? > > As long as these questions are not addressed and cleared and documented > "const" parameters are not > a useable in actual code. > We do not document these on purpose, because they're mainly dictated by the platform ABI (on the majority of targets FPC supports simply the C ABI is used). The main part of "const" is that you can't (easily) modify the value and that reference counting isn't done when passing the value around. Whether it's passed by-value or by-reference is irrelevant for that. If you need pass-by-reference then use those modifiers that are intended for them, namely "var", "out" and "constref". Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Question on constref
Adriaan van Os via fpc-devel schrieb am Do., 2. Feb. 2023, 02:47: > Sven Barth via fpc-devel wrote: > > > There is no full documentation for that parameter modifier (someone > > might want to file a bug report for that), but the documentation for > > “const” ( > > > https://www.freepascal.org/docs-html/current/ref/refsu67.html#x183-20700014.4.4 > > ) contains this: > > > > === doc begin === > > > > Contrary to Delphi, no assumptions should be made about how const > > parameters are passed to the underlying routine. In particular, the > > assumption that parameters with large size are passed by reference is > > not correct. For this the constref parameter type should be used, which > > is available as of version 2.5.1 of the compiler. > > > > === doc end === > > On debate, see FPC issue 17442. > There is no debate planned for this in the near future. So even if this might change some time in the future it does not *now* and very likely also not for 3.4.0. Not to mention that things wouldn't change for most platforms anyway, because they only have the platform ABI available and that *must not* change for compatibility with C code. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Question on constref
Am 02.02.2023 um 02:09 schrieb Hairy Pixels: On Feb 2, 2023, at 4:38 AM, Sven Barth wrote: Which types are passed by-value or by-reference when using const is determined by the size of the record and the types of the fields based on whatever the corresponding ABI defines (e.g. the x86_64 Sys V ABI is rather explicit about some field combinations). The compiler will however not switch between passing a specific type once by-value and another time by-reference. So if the compiler is making the choice using const which is more efficient then we should be using const always I would think? What problem does constref solve then? The case when you *need* a constant reference. Case in point: the passing of TGuid in IInterface.QueryInterface. Delphi code relies on it being a reference, but “const” does not guarantee that for all platforms. You go on to show this: === doc begin === Contrary to Delphi, no assumptions should be made about how const parameters are passed to the underlying routine. In particular, the assumption that parameters with large size are passed by reference is not correct. For this the constref parameter type should be used, which is available as of version 2.5.1 of the compiler. === doc end === Is there anytime a large record should be passed by value if the function is not altering the it? This is why I started using constref, i.e. "In particular, the assumption that parameters with large size are passed by reference is not correct” which makes me think if I have a record of say 64k if I don’t use constref it could be passed by value to a function which is called in a tight loop. I doubt that records larger than say 4 register widths are ever passed by-value. But I definitely can't exclude it, cause I don't know every ABI of every platform by heart. So if you want details there then study the ABIs of the platforms you use. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Question on constref
Am 01.02.2023 um 11:30 schrieb Bart via fpc-devel: I thought that constref would be OK for that (the word constref suggests to me tah the paramter will be treated (by me) to be a constant, and that it shall be passed by reference in all cases, whereas with a const parameter the compiler decides upon the best way to pass it: by value or by reference). I tried to find documentation for constref, but all I could find was: https://wiki.freepascal.org/FPC_New_Features_2.6.0#Constref_parameter_modifier There it says: "Note that in general, it should only be used for interfacing with external code or when writing assembler routines." “constref” is guaranteed to pass the parameter by reference. And the compiler will ensure that it can't be modified as reasonably possible (as with “const” there are ways to circumvent this, e.g. by passing around a pointer to the parameter, but the general cases are covered). (B.t.w.: Where can I find the official documentation on constref?) There is no full documentation for that parameter modifier (someone might want to file a bug report for that), but the documentation for “const” ( https://www.freepascal.org/docs-html/current/ref/refsu67.html#x183-20700014.4.4 ) contains this: === doc begin === Contrary to Delphi, no assumptions should be made about how const parameters are passed to the underlying routine. In particular, the assumption that parameters with large size are passed by reference is not correct. For this the constref parameter type should be used, which is available as of version 2.5.1 of the compiler. === doc end === Regards, Sven___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Question on constref
Am 01.02.2023 um 15:40 schrieb Hairy Pixels via fpc-devel: On Feb 1, 2023, at 8:27 PM, Michael Van Canneyt via fpc-devel wrote: That's exactly what Adriaan is saying. With const the compiler can choose. With constref, you force it not to copy. But this is not so efficient for small parameter sizes. So const will always pass records that are over a certain size by references? That’s good to know since “const” is more pleasant to look at it than constref. :) Which types are passed by-value or by-reference when using const is determined by the size of the record and the types of the fields based on whatever the corresponding ABI defines (e.g. the x86_64 Sys V ABI is rather explicit about some field combinations). The compiler will however not switch between passing a specific type once by-value and another time by-reference. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why: "Can't take the address of constant expressions" here?
Am 13.01.2023 um 01:05 schrieb Bart via fpc-devel: The issue is indeed the conversion from UnicodeString to WideString which is not allowed for a var/out parameter. That the compiler doesn't use the error “Call by var for arg no. 3 has to match exactly: Got "UnicodeString" expected "WideString"” is due to Ansi2WideMoveProc() being a function pointer. The code that determines that error is not called in that case, instead the other is caused essentially as a last resort. Thanks for explaining. You can report a bug with the following sample to hopefully improve this: Reported as issue #40106 Thank you. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why: "Can't take the address of constant expressions" here?
Am 11.01.2023 um 23:58 schrieb Bart via fpc-devel:
Given the following program (an excerpt form a test program for a
bugreport about the fpwidestring unit):
===
program test;
{$codepage utf8}
{$mode objfpc}
{$h+}
uses
FpWideString;
var
WSource: WideString = 'source';
USource: UnicodeString = 'source';
WDest: WideString = '' ;
UDest: UnicodeString = '';
ASource: AnsiString = 'source';
ADest: AnsiString = '';
P: array[0..99] of AnsiChar;
begin
with WideStringManager do
begin
writeln(1);
Wide2AnsiMoveProc(pwidechar(WSource),RawByteString(ADest),
CP_UTF8, Length(WSource));
writeln(2);
Ansi2WideMoveProc(PChar(ASource), CP_UTF8, UDest,
Length(ASource)); //<< test.lpr(24,53) Error: Can't take the address
of constant expressions (caret behind UDest)
end.
C:\Users\Bart\LazarusProjecten\bugs\Console\fpwidestring>fpc test.lpr
Free Pascal Compiler version 3.3.1 [2022/10/11] for i386
Copyright (c) 1993-2022 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling test.lpr
test.lpr(24,53) Error: Can't take the address of constant expressions
...
UDest is of the wrong type here, it compiles fine with WDest (WideString).
I just don't understand the "Can't take the address of constant expressions"
I would have expected something like "Call by var for arg no. 3 has to
match exactly: Got "UnicodeString" expected "WideString""
The issue is indeed the conversion from UnicodeString to WideString
which is not allowed for a var/out parameter. That the compiler doesn't
use the error “Call by var for arg no. 3 has to match exactly: Got
"UnicodeString" expected "WideString"” is due to Ansi2WideMoveProc()
being a function pointer. The code that determines that error is not
called in that case, instead the other is caused essentially as a last
resort.
You can report a bug with the following sample to hopefully improve this:
=== code begin ===
program tunicode;
var
Str: UnicodeString = 'Foobar';
procedure Test(var aArg: WideString);
begin
end;
var
Func: procedure(var aArg: WideString) = Nil;
begin
Test(Str);
Func(Str);
end.
=== code end ===
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode RTL for FPC
Michael Van Canneyt via fpc-devel schrieb am Sa., 7. Jan. 2023, 12:46: > > > On Sat, 7 Jan 2023, Mattias Gaertner via fpc-devel wrote: > > > On Fri, 6 Jan 2023 18:05:43 +0100 (CET) > > Michael Van Canneyt via fpc-devel > > wrote: > > > >> [...] > >> For those that wish to help in testing: > >> > >> - Update your git clone > > > > I used a fresh clone. > > > >> - switch to branch unicodertl. > > > > I used git checkout unicodertl > > > >> - in the toplevel FPC directory, do a > >> > >> make all > > > > I get: > > > > Compiling .../packages/fcl-process/src/process.pp > > Compiling .../packages/fcl-process/src/pipes.pp > > process.inc(94,23) Error: Incompatible type for arg no. 1: Got "PChar", > > expected "PWideChar" > > Lesson: > Always run a toplevel "make all" after even the smallest (no matter how > insignificant) change in RTL. > That's my usual modus operandi when working on the RTL or some compiler feature: first make sure that make inside the rtl directory works and then ensure that it also works in the top level. There have often enough been subtle errors further down the line (good candidate, especially when working with generics, is the rtl-generics package ). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Make file questions (Makefile.fpc, fpmake.pp, etc)
Wayne Sherman schrieb am Mi., 4. Jan. 2023, 01:13: > On Tue, Jan 3, 2023 at 12:17 AM Sven Barth wrote: > >> 1) How do I generate the fpmake.pp file? Or is it created by manual > coding? > > > > This is created manually and is *the* source for how to build a package. > > > >> 2) Does "Makefile" automatically get generated during a build or do I > >> have to manually run FPCMake? > > > > You need to run fpcmake manually. > > Got it. So after moving files and/or directories around in > packages/some-package/ one has to: > 1) Edit fpmake.pp to make sure it has the correct paths and files > 2) Fix up any examples or lazarus project files with the correct > paths. (if needed) > 3) Run fpcmake -w -Tall from base package directory to regenerate > Makefile > There is no need for 3 if all you do is change something inside the fpmake.pp files and move files around. You only need to really work with fpcmake when you change something in the rtl directory (as that still uses that) or if a new target is added. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Make file questions (Makefile.fpc, fpmake.pp, etc)
Wayne Sherman via fpc-devel schrieb am Di., 3. Jan. 2023, 07:36: > Each package directory (./fpc-source/packages/some-package/) typically > has these files: >fpmake.pp (where does this come from?) >Makefile (this is generated by FPCMake?) >Makefile.fpc (config file for FPCMake to create Makefile?) > > Some package directories also have: >Makefile.fpc.fpcmake (?) > > Some questions please: > 1) How do I generate the fpmake.pp file? Or is it created by manual > coding? > This is created manually and is *the* source for how to build a package. 2) Does "Makefile" automatically get generated during a build or do I > have to manually run FPCMake? > You need to run fpcmake manually. 3) What is "Makefile.fpc.fpcmake" used for and how is it created? > This is the old, manually created build file. It mainly exists as reference to check whether the fpmake.pp was created correctly. The new Makefile.fpc is a general file shared by all packages that simply invokes fpmake (when converted to a Makefile). 4) Can "fpmake" completely build fpc and all the packages without using > "make"? > In theory yes, Joost has implemented and tested that, but we don't use that. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] threads vs widestringmanager / crash
Am 20.12.2022 um 15:08 schrieb Martin: Ok, I don't know too much about the whole initialization But on the off chance of triggering some ideas, I throw in a couple of my thoughts On 19/12/2022 07:42, Sven Barth wrote: Am 07.07.2018 um 15:04 schrieb Martin: So (guessing) the original issue may be due to the debugger. The debugger interrupts the target early on. And that does create a thread in the target. If such an external thread happens, would fcp execute the code in question? This is likely to be the cause, cause the EXEC_TLS_CALLBACK is executed by Windows for every thread that is started for an application. And if the debugger triggers the start of a thread... Maybe, maybe not always? But, yes at least in the case that I documented in 2018: https://lists.freepascal.org/pipermail/fpc-devel/2018-July/039374.html Yet in the system unit: initialization . if not Assigned(CurrentTM.BeginThread) then begin InitHeap; InitSystemThreads; end; SysInitExceptions; initunicodestringmanager; InitWin32Widestrings; So the WS-Mgr is only assigned after InitSystemThreads => which sets up RelocateThreadVar => which can call InitThread. So order may need to be changed there (if that is possible). Of course, the case where EXEC_TLS_CALLBACK calls InitThread remains. A lot of the WS-Mgr init is assigning pointers to the correct procedure. So if InitThread sees that this has not been done yet, InitThread could call those. Even if 2 threads (main and the early thread) both assign values to the pointer, they assign the same value, and so that should not do harm. Of course the thread init must not change the value, once it was set by the main thread, in case usercode assigned a diff value (so maybe in ThreadInit, use Interlocked) This may mean to break "InitWin32Widestrings" into 2 parts, because it also prepares some tables. But those are not needed for "GetStandardCodePageProc" So if the setting of the codepage related proc pointers are moved to a separate init-method, then that can be called (if needed) by InitThread. -- Or maybe if EXEC_TLS_CALLBACK calls InitThread, it can do the (partial) init of WidestringMgr before? (if the order in the initialization section can be changed to do the same?) -- I am not sure if this code needs to worry about any of the other WS-Mgr functions. Any thread that early is not started by Pascal code (neither user, nor rtl). It will be a thread working some kernel proc. And that shouldn't access the WS-Mgr? Please stop focusing on the WideString manager. That is simply a symptom. The real cause is that a thread is created where there shouldn't be one and under normal circumstance there indeed will be none: - if the initialization is executed as part of an application then there won't be any other thread, because the system initialization doesn't create one - if the initialization is executed as part of a library then there won't be any other thread, because the initialization is run during the DLL_PROCESS_ATTACH call of the entry point which Windows executes with the global loader lock held, thus no thread can enter the entry point (which is also why there are some things you shouldn't do in a unit initialization) The only cause for a thread to exist at that point is if another process calls CreateRemoteThread(Ex)() to create a thread in the process that is just initializing (Note: DebugBreakProcess() internally uses CreateRemoteThread(Ex)()). This means that the thread can interfere at *any* point of the initialization simply depending on the behavior of the Windows scheduler (as you hinted at in your other mail from today). So the only logical solution is to stop the offending thread from executing or not to have it call InitThread() while the initialization section of the System unit is still running. The former might have unintended consequences (e.g. not being able to debug the unit initialization) while the later might work in most cases as long as that remote thread doesn't need to execute code that relies on InitThread(). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] threads vs widestringmanager / crash
Ondrej Pokorny via fpc-devel schrieb am
Mo., 19. Dez. 2022, 08:30:
> On 19.12.2022 07:42, Sven Barth via fpc-devel wrote:
> > The RTL assumes that it does not have to deal with threads during the
> > initialization of the System unit. So even if the symptom of the crash
> > is fixed in that location it isn't said that something else might
> > crash or that in the future code might be added that crashes...
>
> Is it possible to acknowledge that the current RTLs assumption is wrong
> and it has to deal with threads during the System initialization?
> (Because obviously the assumption is wrong, otherwise there was no crash.)
>
The RTL needs to make some assumptions, because it is the one that sets up
the synchronization primitives and under normal circumstances this
assumption *is* true. As you mentioned in the other mail the crash depends
upon execution speed and thus it could very well happen during
initialization of the heap as well.
> That means not to fix the symptom with checking
> "Assigned(WideStringManager.GetStandardCodePageProc)" but acknowledge
> that the OS can start a thread before System initialization is done and
> create a mechanism to postpone thread initialization until System is
> fully initialized.
>
> Something like:
>
> procedure InitThread(stklen:SizeUInt);
>begin
> // new code begin
> while not SystemInitialized do
>Sleep(10);
> // new code end
> {$ifndef FPUNONE}
> SysResetFPU;
> {$endif}
>
It will probably come to something like this.
Though we should first check what it means for the user if the debugger
thread is hold in place.
Regards,
Sven
>
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] threads vs widestringmanager / crash
Am 07.07.2018 um 15:04 schrieb Martin: So (guessing) the original issue may be due to the debugger. The debugger interrupts the target early on. And that does create a thread in the target. If such an external thread happens, would fcp execute the code in question? This is likely to be the cause, cause the EXEC_TLS_CALLBACK is executed by Windows for every thread that is started for an application. And if the debugger triggers the start of a thread... Could/Should there be a nil check at the location of the crash? The RTL assumes that it does not have to deal with threads during the initialization of the System unit. So even if the symptom of the crash is fixed in that location it isn't said that something else might crash or that in the future code might be added that crashes... Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Progress on pure functions
Am 16.12.2022 um 02:02 schrieb J. Gareth Moreton via fpc-devel: The purity analysis process is very dependent on the node tree being as clean as possible, and so depends on a fair few merge requests that have not yet been approved. I'm guessing Florian and Jonas and others are somewhat busy, what with being December and all. - https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/232 - strips unnecessary typeconv nodes (this helps a lot with constant propagation). - https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/342 - strips excess nothing nodes. I didn't say that you shouldn't clean up the tree for your purity analysis (that sounds so wrong :P ), I simply asked what you meant with “share the same field” and if it is what I think it is then it's a bad idea and you shouldn't “share the same field” but introduce your own. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Progress on pure functions
Am 14.12.2022 um 12:15 schrieb J. Gareth Moreton via fpc-devel: To better explain how purity analysis currently works (I'm sure there's a better name than "purity analysis"), it takes a copy of the unoptimised node tree (this is the same as the tree used for inline, and for a space saving, they share the same field), adds explicit definitions for the formal parameters so they equal the constants passed in, and then tries to collapse the node tree down to a single assignment to the result. This is done by running the following operations in this order: What do you mean with “share the same field”? A pure function might still be called and inlined like a normal function and for that you shouldn't transform the node tree needlessly as that might influence the debugging experience. So you should have two different copies, one for inlining and one for pure related transformations. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Progress on pure functions
J. Gareth Moreton via fpc-devel schrieb am
Di., 13. Dez. 2022, 22:09:
> The next big milestone that I want to achieve is to make this a pure
> function:
>
> procedure int_str_unsigned(l:longword;out s:shortstring); pure;
> var
>m1 : longword;
>pcstart,
>pc2start,
>pc,pc2 : pchar;
>hs : string[32];
>overflow : longint;
> begin
>pc2start:=@s[1];
>pc2:=pc2start;
>pcstart:=pchar(@hs[0]);
>pc:=pcstart;
>repeat
> inc(pc);
> m1:=l div 10;
> pc^:=char(l-(m1*10)+byte('0'));
> l:=m1;
>until l=0;
>overflow:=(pc-pcstart)-high(s);
>if overflow>0 then
> inc(pcstart,overflow);
>while (pc>pcstart) do
> begin
>pc2^:=pc^;
>inc(pc2);
>dec(pc);
> end;
>s[0]:=char(pc2-pc2start);
> end;
>
> This is essentially the core internal function that drives IntToStr and
> similar functions. The challenges here include:
>
> - A repeat...until loop with no obvious termination sequence.
> - Using a pointer to access an array offset of a local variable.
> - Writing characters (and the length field) one at a time to a shortstring.
>
> The reason for wishing to make IntToStr a pure function is that for a
> given input, the output will never change, and it's perfectly feasible
> for some other function to call IntToStr as part of a string generation
> routine and which would otherwise itself be a pure function (if a pure
> function wishes to call another function, it must also be determined to
> be pure... see pure1b.pp for the recursive example where the actual
> parameter isn't even a constant, but is nonetheless deterministic).
>
Wouldn't it make more sense to ensure that the Str() and Val() intrinsic
work correctly inside "pure" functions? After all the compiler can then
simply evaluate the inlinen nodes and does not have to "interpret" a ton of
other code as well.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Sorting tests
Ondrej Pokorny via fpc-devel schrieb am Di., 29. Nov. 2022, 11:39: > Am 29.11.2022 um 11:08 schrieb Sven Barth via fpc-devel: > > J. Gareth Moreton via fpc-devel schrieb > am Di., 29. Nov. 2022, 10:09: > >> Surely that's a bug in the comparison functions that should be fixed and >> not something that can be blamed on introsort. If a comparison function >> is faulty, then pretty nuch any sorting algorithm can be considered to >> have unpredictable behaviour. >> > > This *can* be blamed on IntroSort, because Stability (order of equal > elements is kept) is an attribute of sorting algorithms and IntroSort is > *not* considered stable while QuickSort *can* be stable depending on the > implementation and ours *is*. > > If for two elements [a, b] the comparison function returns > a > then the problem is not in stability or any other feature of the sorting > algorithm but in the comparison function indeed. Or am I missing something? > For such a comparison function the issue is indeed in the comparison function, but Nikolay also mentioned "a ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Sorting tests
J. Gareth Moreton via fpc-devel schrieb am Di., 29. Nov. 2022, 10:09: > Surely that's a bug in the comparison functions that should be fixed and > not something that can be blamed on introsort. If a comparison function > is faulty, then pretty nuch any sorting algorithm can be considered to > have unpredictable behaviour. > This *can* be blamed on IntroSort, because Stability (order of equal elements is kept) is an attribute of sorting algorithms and IntroSort is *not* considered stable while QuickSort *can* be stable depending on the implementation and ours *is*. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Sorting tests
Stefan Glienke via fpc-devel schrieb am Mo., 28. Nov. 2022, 12:39: > In Delphi that would be the > https://docwiki.embarcadero.com/Libraries/Alexandria/en/System.GetTypeKind > intrinsic - I could not find that one in the 3.2.0 feature list. > That one is also supported since 3.2.0, though it seems I forgot to add it to the New Features List... Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Sorting tests
J. Gareth Moreton via fpc-devel schrieb am Mo., 28. Nov. 2022, 11:01: > Just want to clarify something... if a type is managed, can it be safely > typecast to a pointer in all instances and on all platforms? (The > purpose being so if I wanted to swap two items, so there's no overall > change in the reference counters, I can simply swap the pointers... > there's no dereferencing involved!) > No, managed does not automatically mean that it's a Pointer based type. Records with management operators, Variants and Windows WideString are managed as well. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Sorting tests
Stefan Glienke via fpc-devel schrieb am Mo., 28. Nov. 2022, 00:20: > Probably not unless FPC has something similar to > > https://docwiki.embarcadero.com/Libraries/Alexandria/en/System.IsManagedType > (that function among a few others is compiletime evaluated). > It's supported since 3.2.0: https://wiki.freepascal.org/FPC_New_Features_3.2 Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] An interesting thought... AI
J. Gareth Moreton schrieb am Do., 10. Nov. 2022, 23:26: > Funny how you mention "black box" because recently there was a news > article about scientists increasingly not understanding why machine > learning is working the way it is with apparent patterns of emergent > behaviour. > That and similar articles about this are why I mentioned this ;) Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] An interesting thought... AI
Am 10.11.2022 um 19:10 schrieb J. Gareth Moreton via fpc-devel: Hi everyone, This has been something that has been on my mind for a while now, but with my increasingly more complex optimisations being developed for the Free Pascal Compiler and the code becoming an ever bigger spiderweb of conditions, it got me to start wondering... might compiler optimisation be a candidate for AI? Often I try to hand-optimise assembly language to get the same output in fewer cycles (and fewer bytes too if possible), and then see if I can program the compiler to match it. I can't hope to catch every possible optimisation though, and I wonder if using an AI in some way to develop more efficient machine code has ever been a serious contender for research. I have heard of stories like the Deepmind AI finding a faster way to multiply matrices, so it seems logical that it can improve instruction processes. You still need to feed the model with the necessary rules and with necessary training data of both correct and incorrect approaches. But even then *I* wouldn't want to have any of that black box mambo jumbo in FPC, cause when a bug occurs in the optimizations due to some decision the model made... well... tough luck. With the current approach you need to bash your head a bit against the next wall to find the location of the issue, but with a machine learning approach (let's not call it AI, cause there's nothing “intelligent” about that) you can't even do that. You can only fiddle with what you fed into the model and hope for the best (and wonder why it now fails at a completely different area). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Policy regarding SHL/SHR under x86
J. Gareth Moreton via fpc-devel schrieb am Mo., 24. Okt. 2022, 13:52: > That's useful - thank you. Michael Van Canneyt mentioend he updated the > documentation for this - where is this usually located? It's not here, > for example: https://www.freepascal.org/docs-html/ref/refsu45.html That is for the last released version, in this case 3.2.2. A snapshot of the documentation for the development version is available at https://www.freepascal.org/daily/daily.html, so the one you want is here: https://www.freepascal.org/daily/doc/ref/refsu46.html Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compile error with actual FPC main and Lazarus main
J. Gareth Moreton via fpc-devel schrieb am Mi., 28. Sep. 2022, 19:44: > Granted I do think the compiler raising an internal exception is rather > unclean... possibly not as bad as in internal error but still something > undesirable. > Well, if you want to hunt down these issues, be my guest; we're hunting them for quite some time already. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] M1 and Mac system support?
Richard Hyman via fpc-devel schrieb am Do., 22. Sep. 2022, 09:00: > > 1. Does FPC compile natively for the ARM Macs, specifically an M1? Docs I > found do not directly answer this question (he's thinking about purchasing > an M1 Mac mini). > This is supported since 3.2.2. 2. Does FPC provide any support for interfacing to the system? > Aside from interfacing through the C API FPC can also interact with Objective C objects. > a. Can an FPC compiled app be run from the terminal with recognition of > input parameters (standard I/O). E.G. run something such as "myApp > /../myInputFile.txt /../myOutputFile.txt", and have the app parse $1 and > $2 for the input and output files? > You can access parameter values using the ParamStr functions and then you need to open the files with the file APilI of your choice. > If FPC supports standard I/O, how is it accomplished within the app? > FPC supports the standard Pascal I/O using Assign, Read, Write and friends, an imperative style FileOpen, FileRead, FileWrite API as well as the TStream based API. > b. Does FPC support Mac system APIs? This is a general question since API > support in any one of several areas (beyond graphics for example) would be > beneficial. > Since FPC can interact with the system as mentioned above, it does. A unit with various converted API headers is provided. Just look at what Lazarus can do. It's a native macOS application and without interfacing with the macOS API this wouldn't be possible. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Insufficient Dwarf info for Interfaces
Am 15.09.2022 um 14:32 schrieb Martin Frb via fpc-devel: https://gitlab.com/freepascal.org/fpc/source/-/issues/39904 On top of adding the functions in the interface to the dwarf info, it would be great if the compiler could also add some sort of link to the underlaying TObject. So the debugger could (if available) show the user the object/instance that implements the interface. I am not sure how that would best be done (i.e. maybe add some internal field, maybe there is some dwarf tag that can be used, maybe a dwarf extension) From what I understand, this would require the offset between the interface table and the class (i.e. the value that is subtracted from "self" in the interface's method). If for a debug build the compiler could write that value in front of the interface, then it could point the debugger to it You are aware that an interface can be implemented by multiple different class types and that the offsets for each class that implements a specific interface will be different depending on the amount of interfaces a class implements? So if you have a given interface neither you nor the compiler will know what is on the other side. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Smart-linking on linux/x86-64
Joost van der Sluis via fpc-devel schrieb am Di., 5. Juli 2022, 22:37: > > > > Op 05-07-2022 om 08:39 schreef Sven Barth via fpc-devel: > > Joost van der Sluis via fpc-devel > <mailto:fpc-devel@lists.freepascal.org>> schrieb am Di., 5. Juli 2022, > > 00:17: > > Any suggestions? Is it possible to place every fde in it's own > section > > to solve this? > > > > > > The problem is that *something* would need to reference the debug > > sections otherwise they are stripped as well. But as soon as they're > > referenced whatever code or data *they* reference is kept as well. > > One of the better solutions might be to write these references as weak > > symbols (on systems that support this) so at least the data/function > > isn't kept around. > > Or the section of the data/function would have to contain a reference to > > its corresponding debug entry so that it is kept around as long as the > > function/data is kept around... > > How does GCC do this? > > Apperently GCC does the exact same thing as fpc does on Windows. Replace > the addresses with 0, and mixup the function-names. > > (The link between the CFI and actual code consists of local labels. They > do not reference the global labels/sections. I guess that is why the > code is removed, as it's global label is not referenced) > > I can adapt fpc so that it does the same on Linux also. So I think I'll > leave it this way. > I think many people would be glad if you'd solve the issue of smart linking with debug information when an external linker is used. :) Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Smart-linking on linux/x86-64
Joost van der Sluis via fpc-devel schrieb am Di., 5. Juli 2022, 00:17: > > But my real issue is this: on Windows, using the internal linker, this > procedure is also omitted *with* Dwarf debug-data. As you implied. > > The problem is, though, that the CFI-information (the FDE) is not > omitted. This is 'solved' in the internal linker by replacing the > address with 0. Gdb doesn't mind and I've adapted FpDebug so that it > allows this too, but this is still invalid, imho. > > But as the FDE is written now, as 'one block', without any sections, I > don't see how the linker could omit the corresponding FDE. > > Any suggestions? Is it possible to place every fde in it's own section > to solve this? > The problem is that *something* would need to reference the debug sections otherwise they are stripped as well. But as soon as they're referenced whatever code or data *they* reference is kept as well. One of the better solutions might be to write these references as weak symbols (on systems that support this) so at least the data/function isn't kept around. Or the section of the data/function would have to contain a reference to its corresponding debug entry so that it is kept around as long as the function/data is kept around... How does GCC do this? Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Smart-linking on linux/x86-64
Am 04.07.2022 um 19:52 schrieb Joost van der Sluis via fpc-devel: Hi all, I have a very small application, see below. One procedure is not called at all. But when I compile with ppcx64 -XX -CX testcfi.pp The P$TESTCFI_$$_NEVERCALLES symbol is still in the executable. On Windows (internal linker) this code is omitted from the executable, but not on Linux. Does anyone know why? I can't reproduce this with main. But considering that you named the test file “testcfi”: do you by chance play around with DWARF data? Cause DWARF doesn't support smartlinking on non-Windows, at least not in the way FPC generates it... Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Test suite error wrong PPU
Hairy Pixels schrieb am Fr., 24. Juni 2022, 03:45: > > > > On Jun 23, 2022, at 11:52 PM, Sven Barth > wrote: > > > > As you can see at the end (see below) it falls back to 3.2.2 at the end. > What commands did you execute to build FPC itself? > > > > I have no idea what it did that. I’ve done this many times so I’m confused > as to what changed. > > I used a modified ppcaarch64.lpi file to build the compiler (from the > compiler sources itself) which I see uses 3.2.2 but then in the next lines > of output you can see where I use the newly built compiler to run a program > and it’s 3.3.1. > > lazbuild > /Users/ryanjoseph/Developer/fpc-gitlab/compiler/ryan_ppcaarch64.lpi > Hint: (lazarus) Build Project: nothing to do. > Free Pascal Compiler version 3.2.2 [2021/05/16] for aarch64 > Copyright (c) 1993-2021 by Florian Klaempfl and others > (1002) Target OS: Darwin for AArch64 > (3104) Compiling pp.pas > (3104) Compiling pgenutil.pas > (9009) Assembling pgenutil > (9009) Assembling pp > (9015) Linking /Users/ryanjoseph/Developer/fpc-gitlab/compiler/aarch64/pp > (1008) 4179 lines compiled, 0.7 sec > /Users/ryanjoseph/Developer/fpc-gitlab/compiler/aarch64/pp -vbr -gw > -godwarfcpp > -o/Users/ryanjoseph/Developer/Projects/FPC/compiler_gitlab/tests/bin/test > -XR/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk > -Fu/Users/ryanjoseph/Developer/fpc-gitlab/rtl/units/aarch64-darwin > -FU/Users/ryanjoseph/Developer/Projects/FPC/compiler_gitlab/output > /Users/ryanjoseph/Developer/Projects/FPC/compiler_gitlab/tests/various/undefined_proc_var.pp > Free Pascal Compiler version 3.3.1 [2022/06/12] for aarch64 > It is not recommended to use the Lazarus project to build a compiler that is then used to run the testsuite. Please do a complete, ordinary build of FPC before running the testsuite. To do this execute the following in the main directory: make FPMAKEOPT="-T -j Where you replace "" with the amount of threads you want to use. If that finishes successfully then and only then you execute the testsuite with the compiler in compiler/ppca64. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Test suite error wrong PPU
Hairy Pixels via fpc-devel schrieb am Do., 23. Juni 2022, 04:08: > I usually solve this by deleting the units folder but for some reason > after pulling from main it simply won’t build. Can anyone explain why the > PPU version is wrong? It’s all building from the same source directory so > the PPU version in ppu.pas should be the same. Before I tried this I did > build the RTL using the same compiler. > > The current version of the PPU is 208/16 and I’m not even sure what > version it’s looking for, it just says 208 is invalid. > As you can see at the end (see below) it falls back to 3.2.2 at the end. What commands did you execute to build FPC itself? > /Applications/Xcode.app/Contents/Developer/usr/bin/make -C fpmkunit > bootstrap FPC=/usr/local/lib/fpc/3.2.2/ppca64 > /usr/local/lib/fpc/3.2.2/ppca64 src/fpmkunit.pp > -Fu../../rtl/units/aarch64-darwin -FUunits_bs/aarch64-darwin > -Fu../paszlib/src -Fu../hash/src -Fi../paszlib/src > -Fi../fcl-process/src/unix -Fu../fcl-process/src > -Fi../fcl-process/src/darwin -Fi../fcl-process/src/dummy -Fu../libtar/src > -Fd -n > PPU Loading > /Users/ryanjoseph/Developer/fpc-gitlab/rtl/units/aarch64-darwin/system.ppu > PPU Invalid Version 208 > Fatal: Can't find unit system used by fpmkunit > Fatal: Compilation aborted > make[5]: *** [bootstrap] Error 1 > make[4]: *** [fpmake] Error 2 > make[3]: *** [packages-stamp.aarch64-darwin] Error 2 > make[2]: *** [tstunits] Error 2 > make[1]: *** [allexectests] Error 2 > make: *** [full] Error 2 > tests$ > Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] get and putin $modeswitch isooi
Am 03.06.2022 um 14:32 schrieb Marco van de Voort via fpc-devel: There was a question about $modeswitch ISOIO on stack overflow, and specially why get() and put() are not part of it. The documentation about this switch seems very sparse. As far as I can see it is mostly the lookahead and switching reset and read/write handlers to their ISO variants. Does anybody know? Or is it simply because get/put support is newer? Put and Get are not part of modeswitch ISOIO, because they're not intrinsics and are instead provided by the ISO7185 unit which is only used for modeswitch ISO. As that unit also contains functionality that's not covered by the ISOIO modeswitch (some types, Round functions) it's not used for that modeswitch, but only together with the mode. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generic keywords mode switch
Hairy Pixels schrieb am Mo., 13. Juni 2022, 05:30:
> Me and Sven had planned this a couple years ago and I finally got around
> to it this weekend since it was pretty trivial. The reason for this being
> we wanted a way to disable the generic keywords in ObjFPC mode. The
> solution is to decouple the keywords from the ObjFPC mode and put them
> under a mode switch.
>
> Basically now the generic and specialize keywords are enabled via the
> generickeywords mode switch, which is implicitly enabled in ObjFPC mode and
> can be disabled using {$modeswitch generickeywords-}. Technically they can
> be enabled in Delphi mode also although maybe this should be illegal.
>
> I ran all the tests which still pass but I'm very nervous about this
> introducing regressions so it will need a good review. :)
>
> https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/240
This won't be added until I've implemented the backwards compatible type
overloading in non-Delphi modes.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] DEBUG_NODE_XML broken
Am 27.05.2022 um 04:41 schrieb J. Gareth Moreton via fpc-devel:
Hi everyone,
Building the compiler with -dDEBUG_NODE_XML got broken recently:
C:/lazarus/fpc/3.2.0/bin/x86_64-win64/ppcx64.exe -Ur -Xs -O2 -n
-Fux86_64 -Fusystems
-FuC:/Users/garet/Documents/programming/fpc-opts/rtl/units/x86_64-win64
-Fix86_64 -FEx86_64/bin/x86_64-win64 -FUx86_64/units/x86_64-win64
-dRELEASE -dDEBUG_NODE_XML -dx86_64 -dGDB -Fux86 -Fix86
-oC:/Users/garet/Documents/programming/fpc-opts/compiler/ppc1.exe pp.pas
procdefutil.pas(819,37) Error: identifier idents no member "defoptions"
procdefutil.pas(1563) Fatal: There were 1 errors compiling module,
stopping
Fatal: Compilation aborted
I suspect it was one of the patches that Sven recently approved.
Still, the fix is relatively simple, as the culprit code is the
following:
procedure print_procinfo(pi:tcgprocinfo);
begin
{ Print the node to tree.log }
if paraprintnodetree <> 0 then
pi.printproc('after parsing');
{$ifdef DEBUG_NODE_XML}
{ Methods of generic classes don't get any code generated,
so output
the node tree here }
if (df_generic in procdef.defoptions) then // <-- Error line
pi.XMLPrintProc(True);
{$endif DEBUG_NODE_XML}
end;
The faulty line of code should instead be "if (df_generic in
pi.procdef.defoptions) then".
Should have tested that one... *rolls eyes* anyway, should be fixed now
in 0c9b622a742063d1496cb47ff9b18db2480fbe31. :)
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Functors
Am 26.12.2021 um 02:16 schrieb Blaise--- via fpc-devel:
Important design points:
1) Applying round brackets to instances does not collide with the
existing syntax;
2) Naturally, helpers are able to turn helpees into functors;
3) Operator () cannot be applied to types -- that would clash with
explicit type conversions;
4) Explicit empty argument lists are required -- unorthogonal to
routines and procedural variables, but clarity must win here;
5) {$modeswitch Closures} is required (modeswitch_closures.patch from
https://lists.freepascal.org/pipermail/fpc-devel/2021-December/044261.html)
-- functors are closure-adjacent in the area of functional programming.
The parts that are currently missing:
1) Implicit conversion from functors to method pointers -- should be
fairly trivial to implement;
2) Support for generics -- should be straightforward as well;
3) The OPERATOR keyword instead of PROCEDURE/FUNCTION for methods
Invoke -- should we choose to require it -- would be somewhat more
complicated.
Rejected. I've finally managed to integrate your support for function
references, more is currently not required.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] $modeswitch Closures
Am 25.12.2021 um 20:22 schrieb Blaise--- via fpc-devel:
The attached modeswitch_closures.patch introduces {$modeswitch
Closures}; it is included in {$mode Delphi}.
There is a distinction between anonymous routines (defined in-place,
without a name) and closures (capture the context they are invoked
with). The switch encompasses both, but goes for the shorter and
catchier name.
Rejected. First of a modeswitch only patch won't be done, but also this
was now split into AnonymousFunctions and FunctionReferences.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Initialising method pointers with class methods
Am 24.12.2021 um 02:27 schrieb Blaise--- via fpc-devel:
DCC allows the subj (provided that the class type is known at compile
time), FPC does not.
The attached init_methptr_with_classmeth.patch implements this feature.
---8<---
type C = class
class procedure Foo;
end;
class procedure C.Foo; begin end;
type CC = class of C;
type H = class helper for C end;
type T = procedure of object;
//var aC: C = nil;
//var aCC: CC = nil;
// Still rejected:
//var ViaInstance: T = aC.Foo;
//var ViaClassRef: T = aCC.Foo;
const ViaClass: T = C.Foo;
// NB: This needs metaclass_meth_to_procvar-2.patch
// from
https://lists.freepascal.org/pipermail/fpc-devel/2021-December/044249.html
// Otherwise: AV in FPC
var ViaMetaclass: T = CC.Foo;
// TODO: Currently, ICE 2021122302 -- needs to be fixed elsewhere.
// See
https://lists.freepascal.org/pipermail/fpc-devel/2021-December/044251.html
//var ViaHelper: T = H.Foo;
procedure Report(const s: string; const X: T);
var Status: Boolean;
begin
Status := (TMethod(X).Code = @C.Foo) and (TMethod(X).Data =
Pointer(C));
writeln(s, ': ', Status)
end;
begin
Report('via class', ViaClass);
Report('via metaclass', ViaMetaclass)
end.
---8<---
Proposed new error message for parser_e_no_procvarobj_const:
Cannot initialize a method pointer: Self pointer is not known at
compile time
In order to initialize a method pointer with a method, the value
of the Self pointer for calling that method at run time must be known
at compile time. Thus, a method pointer can be initialized either with
NIL, or with a class method that is accessed via a class type or a
class reference type.
Accepted.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Assigning class methods, accessed via a class reference type, to procvars
Am 22.12.2021 um 19:16 schrieb Blaise--- via fpc-devel: 1) The attached metaclass_meth_to_procvar-1.patch fixes the internal error reported for: [ICE] Assigning class methods, accessed via a class reference type, to incompatible procvars ---8<--- type C = class class procedure NonStatic; class procedure Static; static; end; class procedure C.NonStatic; begin end; class procedure C.Static; begin end; type CC = class of C; var IncompatWNonStatic: procedure; var IncompatWStatic: procedure of object; begin IncompatWNonStatic := CC.NonStatic; // ICE 200301042 IncompatWStatic := CC.Static // ICE 200301042 end. ---8<--- 2) The attached metaclass_meth_to_procvar-2.patch fixes the invalid codegen produced for: [BadCG] Assigning class non-static methods, accessed via a class reference type, to method pointers ---8<--- type C = class class procedure Foo; end; class procedure C.Foo; begin end; type CC = class of C; var Z: procedure of object; begin Z := CC.Foo; writeln( TMethod(Z).Code = @C.Foo ); // "FALSE" writeln( TMethod(Z).Data = Pointer(C) ); // "FALSE" end. ---8<--- Both accepted. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Assigning instance methods, accessed via a type, to method pointers
Am 23.12.2021 um 19:13 schrieb Blaise--- via fpc-devel: Subj silently produces invalid codegen: ---8<--- var Z: procedure of object; type R = record procedure Foo; end; procedure R.Foo; begin end; type O = object procedure Foo; end; procedure O.Foo; begin end; type C = class procedure Foo; class procedure ClassCtx; end; procedure C.Foo; begin end; class procedure C.ClassCtx; begin Z := Foo; // BadCG: .Code = C.Foo; .Data = C end; type CC = class of C; var aCC: CC = nil; type H = class helper for C procedure Bar; class procedure ClassCtx2; end; procedure H.Bar; begin end; class procedure H.ClassCtx2; begin Z := Bar; // BadCG: .Code = H.Bar; .Data = C end; begin Z := R.Foo; // BadCG: GARBAGE Z := O.Foo; // BadCG: GARBAGE Z := C.Foo; // BadCG: .Code = C.Foo; .Data = C Z := CC.Foo; // BadCG: GARBAGE Z := aCC.Foo; // BadCG: .Code = C.Foo; .Data = aCC // Currently allowed, and we get the fix for this for free. // Such qualification may become rejected; // see https://lists.freepascal.org/pipermail/fpc-devel/2021-December/044251.html Z := H.Bar; // BadCG: GARBAGE end. ---8<--- The attached methptr_to_instancemeth_via_type.patch catches all these cases and reports the proper error: Error: Only class methods, class properties and class variables can be referred with class references Accepted. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Parsing procedural type and method directives
Am 21.12.2021 um 21:37 schrieb Blaise--- via fpc-devel: 1) The following three routines: pdecsub.pas!parse_parameter_dec pdecvar.pas!maybe_parse_proc_directives ptype.pas!read_named_type\procvar_dec create a dummy typesym for the procdef, for the sole purpose of invoking parse_var_proc_directives, which merely extracts that procdef. The attached parse_proctype_directives-1.patch replaces these hacks with calls to the new routine parse_proctype_directives that takes a procvardef directly. 2) Now, there remain three callers of the old parse_var_proc_directives: pdecl.pas!consts_dec x2 pdecl.pas!types_dec pgenutil.pas!generate_specialization_phase2 and all of them have procvardefs readily available. The attached parse_proctype_directives-2.patch drops parse_var_proc_directives in favour of parse_proctype_directives. P.S. It seems that the cases localvarsym and paravarsym @ parse_var_proc_directives were unreachable. 3) The attached consts_dec.patch refactors consts_dec: skipequal -> skip_initialiser, with better locality; deduplicates: calls to check_proc_directive & parse_proctype_directives; checks of current_settings; indexations of current_asmdata.asmlists; elucidates comments. 4) The attached pdflags.patch removes the line pdflags:=pdflags+[pd_body,pd_implemen]; from pgenutil.pas!generate_specialization_phase2. The variable pdflags is not used after that statement; thus, it is confusing: makes the code look like some related logic is missing. 5) The attached parse_objrec_proc_directives.patch changes parse_object_proc_directives & parse_record_proc_directives to take tprocdef instead of tabstractprocdef. All accepted. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Thoughts: Make FillChar etc. an intrinsic for specialised performance potential
Stefan Glienke via fpc-devel schrieb am Di., 19. Apr. 2022, 12:38: > If you want to zero small records more efficiently it might be better > using Default(t) for that and looking at optimizing the code the compiler > generates for that as it seems it produces an empty temp variable which it > assigns instead of simply zeroing the record variable where default() is > being assigned to. > This was an explicit design choice I made, because it pays of as soon as a second such assignment for the same type is made. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Incompatible assignments but no compile error (char array and shortstring)
Am 16.04.2022 um 22:35 schrieb Wayne Sherman via fpc-devel:
Tested with fpc 3.3.1 trunk (as of 2022-Mar-12) and 3.2.2 stable.
Ubuntu 20.04 64-bit
Good compile time error checking is one of the wonderful things about
Pascal. But some char array and shortstring assignments which are not
size compatible do not produce a compile error as expected. Please
see below.
{$mode objfpc}{$H+}
type
TCharArray8= packed array[0..7] of Char;
TCharArray9= packed array[0..8] of Char;
TShortString8 = string[8];
const
StringConst8 = '12345678';
StringConst9 = '123456789';
CharArrayConst8a: TCharArray8 = '12345678';
CharArrayConst8b: TCharArray8 = StringConst8;
CharArrayConst8c: TCharArray8 = ('1','2','3','4','5','6','7','8');
//CharArrayConst8d: TCharArray8 = '123456789'; //compile error as expected
//CharArrayConst8e: TCharArray8 = StringConst9; //compile error as expected
//CharArrayConst8f: TCharArray8 =
('1','2','3','4','5','6','7','8','9'); //compile error as expected
ShortStringConst8a: TShortString8 = '12345678';
ShortStringConst8b: TShortString8 = StringConst8;
ShortStringConst8c: TShortString8 = '123456789'; //did not get
expected compile error (bug?)
ShortStringConst8d: TShortString8 = StringConst9; //did not get
expected compile error (bug?)
var
CharArrayVar8: TCharArray8;
CharArrayVar9: TCharArray9;
ShortStringVar8: TShortString8;
begin
CharArrayVar8 := '12345678';
CharArrayVar8 := StringConst8;
CharArrayVar8 := ['1','2','3','4','5','6','7','8']; //requires fpc 3.3.1
CharArrayVar8 := CharArrayConst8c;
//CharArrayVar8 := ['1','2','3','4','5','6','7','8','9']; //compile
error as expected
CharArrayVar8 := '123456789'; //did not get expected compile error (bug?)
CharArrayVar8 := StringConst9; //did not get expected compile error (bug?)
CharArrayVar8 := ShortStringVar8;
ShortStringVar8 := CharArrayVar8;
ShortStringVar8 := '12345678';
ShortStringVar8 := CharArrayConst8a;
ShortStringVar8 := TCharArray8(['1','2','3','4','5','6','7','8']);
//requires fpc 3.3.1
ShortStringVar8 := '123456789'; //did not get expected compile error (bug?)
ShortStringVar8 := CharArrayVar9; //did not get expected compile error (bug?)
ShortStringVar8 :=
TCharArray9(['1','2','3','4','5','6','7','8','9']); //did not get
expected compile error (bug?) (requires fpc 3.3.1)
end;
Should I open a couple of bug reports?
For ShortString types it is by design that they're truncated implicitely
(the most that current Delphi versions do is issue a warning). However
the assignments to the static char array should be checked.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Thoughts: Make FillChar etc. an intrinsic for specialised performance potential
Florian Klämpfl via fpc-devel schrieb am Sa., 16. Apr. 2022, 21:00: > > > > Am 16.04.2022 um 01:26 schrieb J. Gareth Moreton via fpc-devel < > fpc-devel@lists.freepascal.org>: > > > > Hi everyone, > > > > This is something that sprung to mind when thinking about code speed and > the like, and one thing that cropped up is the initialisation of large > variables such as arrays or records. A common means of doing this is, say: > > > > FillChar(MyVar, SizeOf(MyVar), 0); > > > > To keep things as general-purpose as possible, this usually results in a > function call that decides the best course of action, and for very large > blocks of data whose size may not be deterministic (e.g. a file buffer), > this is the best approach - the overhead is relatively small and it quickly > uses fast block-move instructions. > > > > However, for small-to-mid-sized variables of known size, this can lead > to some inefficiencies, first by not taking into account that the size of > the variable is known, but also because the initialisation value is zero, > more often that not, and the variable is probably aligned on the stack (so > the checks to make sure a pointer is aligned are unnecessary). > > > > I did a proof of concept on x86_64-win64 with the following record: > > > > type > > TTestRecord = record > > Field1: Byte; > > Field2, Field3, Field4: Integer; > > end; > > > > SizeOf(TTestRecord) is 16 and all the fields are on 4-byte boundaries. > Nothing particularly special. > > > > I then declared a variable of this time and filled the fields with > random values, and then ran two different methods to clear their memory. > To get a good speed average, I ran each method 1,000,000,000 times in a > for-loop. The first method was: > > > > FillChar(TestRecord, SizeOf(TestRecord), 0); > > > > The second method was inline assembly language (which I've called 'the > intrinsic'): > > > > asm > > PXOR XMM0, XMM0 > > MOVDQU [RIP+TestRecord], XMM0 > > end;2 > > > > It's not perfect because the presence of inline assembly prevents the > use of register variables (although TestRecord is always on the stack > regardless), but the performance hit is barely noticeable in this case, and > if the assembly language were inserted by the compiler, the register > variable problem won't arise. > > > > These are my results: > > > > FillChar time: 2.398 ns > > > > Field1 = 0 > > Field2 = 0 > > Field3 = 0 > > Field4 = 0 > > > > Intrinsic time: 1.336 ns > > > > Field1 = 0 > > Field2 = 0 > > Field3 = 0 > > Field4 = 0 > > > > Sure, it's on the order of nanoseconds, but the intrinsic is almost > twice as fast. > > > > In terms of size - FillChar call = 20 bytes: > > > > 488d0d22080200 lea 0x20822(%rip),%rcx# 0x100022010 > > 4531c0 xor%r8d,%r8d > > ba1000 mov$0x10,%edx > > e8150a callq 0x12210 > > > > > The intrinsic = 12 bytes: > > > > 660fefc0 pxor %xmm0,%xmm0 > > f30f7f05bd050200 movdqu %xmm0,0x205bd(%rip)# 0x100022010 > > > > For a 32-byte record instead, an extra 8-byte MOVDQU instruction would > be required, so the 2 would be equal size, but with the bonus that the > intrinsic doesn't have a function call and will probably help optimisation > in the rest of the procedure by freeing up the registers used to pass > parameters (%rcx, %rdx and %r8 in this case; although the intrinsic will > require an MM register in this x86_64 example, they tend to not be used as > often). Also, the peephole optimizer can remove redundant PXOR XMM0, XMM0 > calls, which will help as well if there are multiple FillChar calls. > > > > I'm not proposing a total rewrite, and I would say that in the default > case, it should just fall back to the in-built System functions, but the > relevant compiler nodes could be overridden on specific platforms to > generate smaller, more optimised code when the sizes and values are known > at compile time. > > > > Now, in this example, it is still faster to simply set the fields > manually one-by-one (clocks in at around 1.2 ns), possibly due to the > unaligned write (MOVDQU) and internal SSE state switching adding some > overhead, but there's nothing to stop the compiler from inserting code in > place of the FillChar call to do just that if it thinks it's the fastest > method. Then again, one has to be a little bit careful because FillChar > and the intrinsic will also set the filler bytes between Field1 and Field2 > to 0, whereas manually assigning 0 to the fields won't (so they aren't > strictly equivalent and might only be allowed if there are no filler bytes > or when compiling under -O4, but the latter may still be dangerous when > typecasting is concerned), and extra care would have to be taken when > unions are concerned (sorry, 'union' that's a C term - what's the official > Pascal term again?). > > > > Actual Pascal calls to FillChar would not change in any way and so > theoretically it
Re: [fpc-devel] Thoughts: Make FillChar etc. an intrinsic for specialised performance potential
J. Gareth Moreton via fpc-devel schrieb am Sa., 16. Apr. 2022, 01:33: > Actual Pascal calls to FillChar would not change in any way and so > theoretically it won't break existing code. The only drawback is that > the intrinsic and the internal System functions would have to be named > the same so constructs such as "FuncPtr := @FillChar;" as well as > calling FillChar from assembler routines stilll work, and the compiler > would have to know how to differentiate between the two. > Intrinsic symbols do not participate in overload selection and you can't have both an intrinsic and a function symbol in the same unit. The construct you showed thus *will* fail. Note: this is not necessarily an argument against doing this, cause with 3.2.0 we did the same with Insert and Delete when they were extended to support dynamic arrays as well, but it needs to be kept in mind. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Thoughts: Make FillChar etc. an intrinsic for specialised performance potential
Benito van der Zander via fpc-devel schrieb am Sa., 16. Apr. 2022, 15:43: > Hi, > > it could always inline it. > > For small sizes do that mov and for large sizes do rep stosb on x86. It is > very fast nowadays. Faster than FillChar on my Intel laptop. (except for > mid sizes like 128 bytes) > FillChar is on most platforms an assembly function and FPC *never* inlines assembly functions. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problems with MM types (__m128 etc).
Am 06.04.2022 um 20:32 schrieb J. Gareth Moreton via fpc-devel: Another problem... I've tried to declare an ADDPD intrinsic as follows: function x86_addpd(r0, r1: __m128d): __m128d; [INTERNPROC: fpc_in_x86_addpd]; I thought using __m128d instead of __m128 was fairly logical since ADDPD works with Doubles, not Singles, but this can cause problems. For example, with the following setup: function Special(z1, z2 : __m128d): __m128d; vectorcall; begin Special := x86_addpd(z1, z2); end; I get the following: Error: Incompatible types: got "__m128" expected "__m128d" (the file location is between the closing bracket and the semicolon of "Special := x86_addpd(z1, z2);" - it seems that it's hard-coded to expect __m128 (error occurs even if vectorcall is not specified). I know there's still some work to do and things to work out with the vector types and intrinsics. I will admit that personally I don't like Microsoft Visual C++'s approach of forcing the use of the MM types because it feels inflexible and unfriendly, especially as you might, for example, want to declare and use something like the following? type TVector4 = packed record X, Y, Z, W: Single; end align 16; Pascal simply is a strongly typed language. Vector intrinsics are no reason to weaken this. Thus you need to declare operator overloads that hide the nitty, gritty details of assigning a TVector4 to a __m128, e.g.: type TVector4 = packed record X, Y, Z, W: Single; class operator := (const aArg: TVector4): __m128; class operator := (const aArg: __m128): TVector4; end; Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Questions about cross-compiling (z80)
BogDan schrieb am Sa., 12. Feb. 2022, 13:23: > Hi, > > > On Saturday, February 12, 2022, 11:23:40 AM GMT+2, Sven Barth < > pascaldra...@googlemail.com> wrote: > > > BogDan via fpc-devel schrieb am Sa., 12. > Feb. 2022, 10:18: > > Also, everything that is not used by the application it should be > stripped by the linker (if it has one). Again I'd like to highlight that > I'm new to fpc, last time I used pascal it was over 20 years ago :) . > > The linker can only remove stuff that isn't used. And due to the cross > platform nature of FPC manager approaches are used to make the easier > maintainable which also results in a negative impact there. > > But anyway: did you build FPC and the RTL with the -CX option and compile > your application with -XX? > > Regards, > Sven > > > > > I'm compiling my app with -CX -XX flags. > I just tried to buld fpc and RTL with -CX but it fails with the followings: > ... > make[3]: Entering directory '/home/taipan/work/z80/fpc/rtl/zxspectrum' > /bin/mkdir -p /home/taipan/work/z80/fpc/rtl/units/z80-zxspectrum > /home/taipan/work/z80/fpc/compiler/ppcrossz80 -Tzxspectrum -Pz80 -Ur -Xs > -O2 -n -Fi../inc -Fi../z80 > -FE. -FU/home/taipan/work/z80/fpc/rtl/units/z80-zxspectrum > -Fl/usr/lib/gcc/x86_64-linux-gnu/11 -dz > 80 -dRELEASE -O-1 -Us -Sg system.pp > genmath.inc(366,16) Fatal: Code segment too large > Fatal: Compilation aborted > I don't see -CX listed there. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Questions about cross-compiling (z80)
BogDan via fpc-devel schrieb am Sa., 12. Feb. 2022, 10:18: > Also, everything that is not used by the application it should be stripped > by the linker (if it has one). Again I'd like to highlight that I'm new to > fpc, last time I used pascal it was over 20 years ago :) . > The linker can only remove stuff that isn't used. And due to the cross platform nature of FPC manager approaches are used to make the easier maintainable which also results in a negative impact there. But anyway: did you build FPC and the RTL with the -CX option and compile your application with -XX? Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Questions about cross-compiling (z80)
BogDan schrieb am Fr., 11. Feb. 2022, 22:20: > Hi, > > > Thanks a lot for your quick reply. > > Adding ihxutil to path fixed the problem. > But the size problem is stil there, a simple 2 lines of code "begin; > end." generates over 32k of code. That code should not generate more than > 8 bytes of code. > Are there any flags that I need to use to make the code smaller? > The System unit initialization is larger than 8 Byte. A program does not begin with "begin". Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Questions about cross-compiling (z80)
Tomas Hajny via fpc-devel schrieb am Fr., 11. Feb. 2022, 17:24: > On 2022-02-11 14:14, Sven Barth via fpc-devel wrote: > > BogDan via fpc-devel schrieb am Fr., > > 11. Feb. 2022, 11:09: > > . > . > >> It seems is an IHX format not tzx > >> Also the result for a simple hello world is way too big (over 20k) ! > >> I assume that I'm passing wrong params to ppcrossz80. What params > >> should I use? Where I can find more info on this matter? > > > > You need to make sure that the ihxutil built in > > utils/ihxutil/-/ is available in PATH, so that the > > compiler will do the conversion. > > @Sven: Sorry for a silly question, but shouldn't the compiler emit some > error message if the tool isn't available? > It wasn't me who implemented it. But at least a warning or note might be good, cause the output *is* usable after all. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Questions about cross-compiling (z80)
BogDan via fpc-devel schrieb am Fr., 11. Feb. 2022, 11:09: > Hello, > > According to https://wiki.freepascal.org/Z80 fpc is able to compile > pascal code for z80. > Sadly I'm a newbie on fpc, therefore I have a few questions: > > 1. I changed a bit the build script from > https://wiki.freepascal.org/Z80#Building and I managed to build fpc, and > when I built a simple hello world file, the resulted tzx file seems wrong: > ./ppcrossz80 -n -Tzxspectrum -PZ80 > -Fu/path/to/fpc/lib/fpc/3.3.1/units/z80-zxspectrum/rtl -viwn -CX -XX > test.pas > > $ cat test.tzx > :105CF800314CEA0188E0214DE6373FED423E000293 > :105D0800032BBD20FABC20F7FD2288E0F31100FE2A > :105D180021FDFD7AED477D121C20FC141236C321AB > > > It seems is an IHX format not tzx > Also the result for a simple hello world is way too big (over 20k) ! > I assume that I'm passing wrong params to ppcrossz80. What params should I > use? Where I can find more info on this matter? > You need to make sure that the ihxutil built in utils/ihxutil/-/ is available in PATH, so that the compiler will do the conversion. > 2. Is it possible to add z80 cross compilation target to FP IDE? The FP > IDe shows me a few targets, but z80 is not there. > The text mode IDE can only ever compile for one CPU platform, so you need to build it for Z80. Though I don't know right now whether this is enabled. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Current state of atari port
Am 11.02.2022 um 03:59 schrieb Karoly Balogh: Hi, On Thu, 10 Feb 2022, Sven Barth via fpc-devel wrote: Thorsten Otto via fpc-devel schrieb am Do., 10. Feb. 2022, 15:47: Cause in the variant you mentioned where would the allocated memory be stored? I'm not that familiar with ObjectGEM yet, but i think the allocated pointer is stored in some list in the base class. And how does one work with the created instance? How does one release it? Do you have an example for that? Remember, this is for GUI stuff. In some cases the code actually uses the new return pointer, for example when you want to interact with the recently added GUI element, but sometimes you can just "fire and forget" it, like injecting an icon. In this case the constructor of the object adds it to some globally maintained object tree, so it's not lost or remain dangling. Then you can access it from there with various utility functions. I've seen that now as well now that I was able to look at the code. This is something quite specific, and I actually wonder if it's a corner case we don't handle or PurePascal's implementation is less restrictive. It's a valid usecase so I say we should support that as well. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Current state of atari port
Am 10.02.2022 um 19:22 schrieb Thorsten Otto via fpc-devel: On Donnerstag, 10. Februar 2022 19:13:15 CET Sven Barth via fpc-devel wrote: > And how does one work with the created instance? How does one release it? Do > you have an example for that? Maybe some examples of ObjectGEM itself, like https://github.com/th-otto/texel/tree/master/ogem/demo/zeit <https://github.com/th-otto/texel/tree/master/ogem/demo/zeit> I'm quite sure the buttons get properly destroyed when you destroy the dialog, but don't ask me where ;) I've now looked at the original Texel code and it does indeed register the new instance in the passed in parent instance (inside TControl.Init()). So there would only be a memory leak if there wouldn't be a parent, but that is rejected with a FAIL anyway. So we should fix that NEW() handling then, cause that is indeed a valid usecase... (Obviously it's upon to user to handle this correctly then, but that's the case with normal allocations as well, so... *shrugs*) Regards, Sven___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Current state of atari port
Thorsten Otto via fpc-devel schrieb am Do., 10. Feb. 2022, 15:47: > On Donnerstag, 10. Februar 2022 14:21:54 CET Sven Barth via fpc-devel > wrote: > > > Anything else does not make sense. > > > > > > Cause in the variant you mentioned where would the allocated memory be > > > stored? > > > > I'm not that familiar with ObjectGEM yet, but i think the allocated > pointer is stored in some list in the base class. > > And how does one work with the created instance? How does one release it? Do you have an example for that? Regards, Sven > > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Current state of atari port
Thorsten Otto via fpc-devel schrieb am Do., 10. Feb. 2022, 13:00: > - when constructing objects, ObjectGEM uses contructs like > > new(PGroupBox, init(...) > > Such constructs are not supported by FreePascal, you have to assign the > result to some variable (i think that is also an incompatibility to > TurboPascal) > Assuming PGroupbox is declared as a pointer type to some object type it must either be GroupBoxPtr := New(PGroupbox, init(...)) Or New(GroupBoxPtr, init(...)) Anything else does not make sense. Cause in the variant you mentioned where would the allocated memory be stored? And yes, FPC is TP compatible here. - in a few places i got some strange warnings. For example the code > > var tg,mo,jr: word; > > tsetdate(((jr-1980) shl 9) or (mo shl 5) or tg); > > Gives: > > Hint: (4035) Mixing signed expressions and longwords gives a 64bit result > > > > I have no idea why calculations with word (16bit) should give a 64bit > result? > As the m68k port is a 32-bit one all (intermediate) calculations will be done in the native width (which is 32-bit). And if you have a signed/unsigned conflict it will escalate to the next width (which is 64-bit). > > - ObjectGEM uses the type "integer" for all vdi/aes parameters. Since > that might be some implementation specific size, i started to replace it in > a few places by "smallint", and doing a "type smallint = integer;" because > PurePascal does not know that type. That turned out to be not so a good > idea: although the types are identical, using "smallint" in the interface > part and "integer" in the implementation is happily accepted by FreePascal, > but PurePascal complains about a mismatch. > As long as you don't use mode Delphi or mode ObjFPC "Integer" is an alias to "SmallInt". And as you don't need any Object Pascal functionality in those units you don't need to enable it. And for users of the unit it's not relevant. They either need to use the correct type or the compiler will enforce the type conversion when calling functions anyway. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Questions regarding m68k-atari target
Thorsten Otto via fpc-devel schrieb am Mo., 7. Feb. 2022, 13:00: > In the long term, it would be nice to have some automatic selection of the > correct libraries. Otherwise it will not be possible to produce 68k > binaries with a compiler that was compiled for 68020, since that will still > pull in 68020 code from the libraries. > > A FPC compiled for 68020 can generate 68000 code just fine and the other way round (assuming of course that it was compiled without bugs ;) ). It's just that you need to provide it with the correctly compiled units. You can supply those in the fpc.cfg and with $fpcsubarch you can get the name of the currently selected processor to use in a path name (the MS-DOS target makes use of this for example). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Questions regarding m68k-atari target
Am 29.01.2022 um 09:24 schrieb Thorsten Otto via fpc-devel: On Freitag, 28. Januar 2022 20:21:03 CET Karoly Balogh wrote: > a fixed GAS/LD support would be nice, of > course. Yes, but currently i'm a bit lost here. Since that combination currently does not support "smart linking", i guess i'll stick to vasm for now. There are other parts that should be improved, and seem more important to me (like ARGV support, completing the GEMDOS/BIOS/XBIOS interface etc) Currently i'm trying to figure out whats wrong with readln() (used eg. when getting the help screen). On both TOS anfd MiNT, i have to press "return" three times. But can't find where readln(textfile) (without any extra arguments) is implemented. All i can find is some declaration in inc/system.fpd, and the procedure fpc_readln_end in inc/text.inc. Is that actually the function which is called? And how does that magic work? I expect there some problem with expecting CR/LF also when reading from console (although the win32 platform does not seem to suffer from this) Read(Ln) and Write(Ln) are compiler intrinsics as such you won't find them as-is in the sources. To find out what code is generated for it it's best to check the generated assembly code. In case of ReadLn it's indeed fpc_readln_end that does the main job. Regards, Sven___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Questions regarding m68k-atari target
Am 28.01.2022 um 18:04 schrieb Thorsten Otto via fpc-devel: The error number comes from def_system_macro, when it is invoked with an empty name. The crash seems to happen in system.o, during initalization. The external name of the procedure is 'SYSTEM_$$_RECORDRTTI$POINTER$POINTER$TRTTIPROC' (where does that come from?) system.o is rather large (~150k of code), although the source is quite small, so that seems to be some inlined code? The size of the System.pp is only a small part, cause most of the content of the System unit comes from include files located in rtl/atari, rtl/inc and rtl/m68k (including the function you mentioned which is System.RecordRtti located in rtl/inc/rtti.inc) Regards, Sven___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Questions regarding m68k-atari target
Thorsten Otto via fpc-devel schrieb am Di., 25. Jan. 2022, 14:45: > >If I'm not mistaken, GCC for > > >Atari used to have some tool like this? Brownout, maybe? > > > > Yes, but i never used that "brown" tool. For one, i don't like its > confusing naming convention (depending on gcc version, it is "brown", > "extrabrown", "superbrown" etc). But more importantly, it needs an extra > tool to be run after linking, which requires Makefiles to be changed for > all projects that use it. That rules out most unix packages, where the > Makefiles are generated by autoconf, Cmake or similar. Also the whole > toolchain requires a script to be run on the mintlib (atari c-library) > headers, which fails almost everytime something in mintlib changes. And > they did not even manage to provide a gem library, or even a math library. > The compiler can call additional tools without problems. It does so for example for MSX-DOS to convert the generated binary into the correct format. > > An alternative could be to use my mintelf toolchain, which is also > available on my site. This is based on the same sources as the normal > toolchain, but can be used as dropin replacement (just using a different > target, or BINUTILSPREFIX in our case). It will generate working > executables in the same way, but uses elf object format for compiling and > linking, thus making all the features of that format available. For fpc > that would mean however you have to tell it somehow that it can use elf > features like sections, even when using gas. I will give it a try at the > weekend, i think fpc can be tricked by using -Avasm, but then replacing the > symlinks to the assembler. > Once you've tested that it works the way to go is to add an additional assembler for Atari that has the features enabled or to add an option to enable the features for the default one. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Questions regarding m68k-atari target
Thorsten Otto via fpc-devel schrieb am Di., 25. Jan. 2022, 13:03: > On Dienstag, 25. Januar 2022 12:22:33 CET Karoly Balogh wrote: > > > Hi, > > > > > > On Tue, 25 Jan 2022, Thorsten Otto via fpc-devel wrote: > > > > Yes, a.out support (which is used on Atari) has been dropped in 2.31. > > > > But i've added it back in, and cross-binutils of 2.34 can be found at > > > > http://tho-otto.de/crossmint.php#binutils > > > > > > Won't really help. As you found out already, section smartlinking won't > > > work with a.out. It never worked in any version of binutils on any > > > platform. Actually I went the vasm/vlink route, because the AS/LD > versions > > > I found online at the time I worked on the port, crashed hard on me on > > > EmuTOS/Hatari, and vasm/vlink just worked. Plus the vasm/vlink combo > > > supported section-based smartlinking. This is something actually I > > > requested from Frank Wille to be added to vlink, and he was nice enough > to > > > add it for us. It's used on Amiga, Atari, and the Sinclair QL. Just for > > > reference without some kind of smartlinking, we'd end up having a > 300K-ish > > > hello world... Instead of 25K-ish... So yeah. > > > > > > (We do support individual .o/.a based smartlinking too, that should work > > > for Atari as well, but you'll literally end up growing roots, it's so > > > slow, I promise. So it just wasn't practical...) > > > > > > > That does not mean that the section based linking will work. I'll have > > > > to check whether that can somehow be supported. > > > > > > I based on my experience with customized binutils, recommend against > > > fighting with this. I'd much rather just generate an ELF binary, where > all > > > the shiny features are available and tested, then convert it with some > > > tool to a native binary for the target. Actually we have several > platforms > > > which do this or something similar already. If I'm not mistaken, GCC for > > > Atari used to have some tool like this? Brownout, maybe? > > > > > > > Yes, but when i use gas, i think fpc won't generate the required > section > > > > directives? > > > > > > This is intentional. FPC knows that GAS for Atari uses a.out (or used at > > > the time, when I wired this together), and avoids generation sections, > > > because they just didn't work (they didn't even compile back then). > > > > > > Anyway, all of this is 2017-18 wisdom, or so. I haven't looked into your > > > updated binutils yet, so feel free to correct me regarding it, if > > > something which hasn't been supported before now is. :) > > > > > > Cheers, > > > -- > > > Charlie > Can it be that you forgot to write some reply here, Thorsten? Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Questions regarding m68k-atari target
Thorsten Otto via fpc-devel schrieb am Di., 25. Jan. 2022, 10:54: > > the prefix $CPU-$OS is just the default prefix for every cross > > > compiling, if you need an other, you can supply it with e.g. > > > -XPm68k-atari-mint- > > > > Yes, found that already. But there is also at least one assembler file > that is directly compiled from the Makefile (prt0.as), and that is also > compiled by that $CPU-OS-as assembler (also when you otherwise use vasm). > So i wonder a bit why that works on your build server. I also noted that, > when using vasm/vlink, those are also executed using that prefix, so the > actual assembler that is invoked is m68k-atari-vasmm68k_std. > For the makefiles you need to set BINUTILSPREFIX=m68k-atari-mint- then. This will be used both for assembly files and passed on to the compiler using -XP. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC
Mattias Gaertner via fpc-devel schrieb am Fr., 14. Jan. 2022, 10:01: > On Fri, 14 Jan 2022 07:32:59 +0100 > Sven Barth via fpc-devel wrote: > > >[...] > > Just FYI what Delphi writes in their documentation ( > > > https://docwiki.embarcadero.com/RADStudio/Sydney/en/Simple_Types_(Delphi)#Real_Types > > ): > > > > On i386 Windows Extended is 80-bit, on x86_64 Linux, i386 macOS and > > i386 iOS simulator it's 128-bit and on all other platforms (which > > includes x86_64 Windows) it's 64-bit. > > > > So Delphi went the same way as we did. > > The 128-bit is only 80bit precision, right? > > With ppcx64 on Linux I get sizeof(extended)=10. > I meant regarding Windows x86_64. We don't support 128-bit floating point type at all. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC
Am 14.01.2022 um 05:20 schrieb Ben Grasset via fpc-devel: On Thu, Jan 13, 2022 at 9:20 AM Travis Siegel via fpc-devel wrote: I wasn't aware of the whole MS not supporting the FPU thing, that was the missing puzzle piece. It's not a realistic concern in actuality. There's a reason almost every other compiler just continues to generate x87 FPU instructions on x64 Windows when appropriate the same way they do for whatever other platforms are supported. Just FYI what Delphi writes in their documentation ( https://docwiki.embarcadero.com/RADStudio/Sydney/en/Simple_Types_(Delphi)#Real_Types ): On i386 Windows Extended is 80-bit, on x86_64 Linux, i386 macOS and i386 iOS simulator it's 128-bit and on all other platforms (which includes x86_64 Windows) it's 64-bit. So Delphi went the same way as we did. Regards, Sven___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC
Am 14.01.2022 um 03:15 schrieb Ben Grasset via fpc-devel:
On Thu, Jan 13, 2022 at 9:48 AM Nikolay Nikolov via fpc-devel
wrote:
What do other win64 compilers do? Do they generate x87 FPU code
for 64-bit Windows?
Yes. Given the following:
#include
long double do_three(long double x, long double y, long double z) {
return (((x * x) / y) + z);
}
int main () {
printf("%d\n", sizeof(long double));
printf("%.19Lf\n", do_three(9.4567575785454772685L,
2.1211991522332311497L, 16.1216453784376343456L));
}
GCC 11.2 produces this assembly with "gcc -O3 -march=native -S
test.c" on 64-bit Windows 10:
do_three:
.seh_endprologue
fldt (%rdx)
fldt (%r8)
fldt (%r9)
fxch %st(2)
movq %rcx, %rax
fmul %st(0), %st
fdivp %st, %st(1)
faddp %st, %st(1)
fstpt (%rcx)
ret
.seh_endproc
and Clang 13.0 produces this with the same command line arguments passed:
do_three: # @do_three
# %bb.0:
movq %rcx, %rax
fldt (%rdx)
fldt (%r8)
fldt (%r9)
fxch %st(2)
fmul %st, %st(0)
fdivp %st, %st(1)
faddp %st, %st(1)
fstpt (%rcx)
retq
Running the program prints this with both compilers:
16
58.2818846964779790909
So the answer to Mattias's question about C compilers from before is
"they just directly support it on Windows".
For MSVC it's different:
=== code begin ===
; Function compile flags: /Ogtpy
; File C:\Users\Sven\source\repos\floattest\main.cpp
; COMDAT ?do_three@@YA@Z
_TEXT SEGMENT
x$ = 8
y$ = 16
z$ = 24
?do_three@@YA@Z PROC ; do_three, COMDAT
; 4 : return (((x * x) / y) + z);
0 f2 0f 59 c0 mulsd xmm0, xmm0
4 f2 0f 5e c1 divsd xmm0, xmm1
8 f2 0f 58 c2 addsd xmm0, xmm2
; 5 : }
c c3 ret 0
?do_three@@YA@Z ENDP ; do_three
_TEXT ENDS
=== code end ===
=== output begin ===
8
58.2818846964779808673
=== output end ===
(though to be fair it does the same on 32-bit as well)
Regards,
Sven___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC
Am 12.01.2022 um 19:26 schrieb Martin Frb via fpc-devel: On 12/01/2022 18:48, Sven Barth via fpc-devel wrote: [2] From the users view "random", in that the user can not predict all the factors that will affect the selection. Currently the user must be prepared for the latter. No, it is deterministic, it's simply different from a native x86_64-linux compilation or one from Win32 as mentioned above and that is bad. You completely missed the point. I was NOT comparing Win vs Linux I wrote And this is not comparing the behaviour between the Linux and Windows exe (both 64 bit). I agree that different behaviour must be expected. This is the behaviour between compiling the same code, with the same compiler, several times for the same target win-64. Note the 2nd line. - The exact same pascal code - The exact same 32-bit ppcx64.exe - the exact same target: Only compiling to 64-bit Windows exe Changing only compiler options (e.g. optimizations), could possible trigger a behavioural change in the resulting exe. Because some calculation changed between being compiled to run-time or compile-time. No, at least not in the general case if the optimizations are bug free. The only optimizations that might lead to behavior difference with the above mentioned points are those of -O4 (cause those might make use of undefined behavior) or $FASTMATH and both are true for any platform. => ok, I have not deep enough insight into the optimizer, maybe constant-propagation is 100% independent of any option passed to the compiler. Maybe constant-propagation will be the same at a levels of optimization But, also none functional changes such as const c = extended(1.234567997807) var a, b: extended; begin a := c; ... b := c + a; changed to b:= c+c; This is still the same code. There is no reason for a user to assume the result should change. But, depending on the code in between, I have seen cases were "c+a" was done run-time. While "c+c" should be compile time. So, maybe it's not byte by byte the same pascal code. But from a functional point of view, it is the same code. When compiling from a target supporting Extended to one only supporting Double there isn't a loss of precision when calculating values at compile time. The other way around however, there *is* and that is the more crucial problem. Regards, Sven___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC
Martin Frb via fpc-devel schrieb am Mi., 12. Jan. 2022, 18:06: > On 12/01/2022 17:31, Tomas Hajny via fpc-devel wrote: > > On 2022-01-12 16:03, Martin Frb via fpc-devel wrote: > >> > >> > >> But, if any change to the code (not even necessarily a functional > >> change) would allow the compiler to do those calculations at compile > >> time, then the value changes. And the entire behaviour of the app may > >> change. > >> Possible, this could even be a change just in optimization settings > >> (or upgrading FPC), allowing the compiler to to propagate constants... > >> > >> So does that mean, any code (that is to be compiled for Win-64bit) is > >> considered "unstable" if it contains "extended" ? > > > > Not necessarily - when targetting Win64, the user needs to be prepared > > for the lower precision. However, imagine that that the user compiles > > his source code for target x86_64-linux. The resulting binary and its > > output will be exactly the same if the source code is compiled (with > > the same options, etc.) on Linux or if it is compiled on Windows using > > a Win32 hosted compiler, but it will differ if using a Win64 hosted > > compiler. From compiler support point of view, this is an issue. > > Ok. So a question of priority. (E.g., reducing maintenance on tests?) > No, it's a question of unnecessary support we want. We already had users that complained that their code compiled from Win64 to x86_64-linux behaved differently than if compiled from Win32 or from x86_64-linux. We don't want to promote (and support) a compiler that doesn't produce the same code as the other two variants. > >> when targetting Win64, the user needs to be prepared for the lower > precision > Yes, but It is one thing to be prepared for: > - One (exactly one) "lower precision", and all behaviour (on that > platform [1]) to be always according to that specific precision. > > [1] on that platform, with that exact revision of the compiler. > But with any compile options, and independent of none functional > changes to the users code. > > It is another thing to be prepared for > - A random[2] "precision" that will change depending on compiler options > and/or seemingly unrelated changes in the user's code > > [2] From the users view "random", in that the user can not predict all > the factors that will affect the selection. > > > Currently the user must be prepared for the latter. > No, it is deterministic, it's simply different from a native x86_64-linux compilation or one from Win32 as mentioned above and that is bad. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Assembler file option (-a)
Christo Crause via fpc-devel schrieb am Fr., 31. Dez. 2021, 16:58: > On Fri, Dec 31, 2021 at 4:41 PM Marco Borsari via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > >> Hi, >> on Linux with FPC 3.2.2 the executable size of programs compiled with >> fpc -On -a (tried with n 2 or 4) >> is smaller than when the assembler files are deleted (-a omitted). >> Does it is an expected behaviour? >> > > Using any of the -a options (not sure about -a5?) to output assembly also > automatically switches to an external linker (for targets with internal > linkers). Differences in the executables are thus attributable to > differences in generated output between the internal and external linkers. > The internal ELF linker isn't enabled by default. But using -a switches to the external assembler instead of the internal one and there the same point holds true that slightly different binary files are generated. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC
Ben Grasset via fpc-devel schrieb am So., 19. Dez. 2021, 08:33: > To be very clear, to me, this is absolutely nothing more than just a > matter of building the compiler completely normally. It takes like two > minutes all-in. I don't really get why the person who uploads the 32-bit > Windows builds currently doesn't just also upload 64-bit ones. They could > even just use the native 64-bit builds Lazarus already includes. Anyways, > yeah. I'd like to actually make this happen, next time around. > There is already a combined 32-/64-bit download available since 3.2.2. We *won't* provide a pure, native 64-bit download for Win64, because the x86_64-win64 is not suitable for other x86_64 targets or for compiling a i386 or i8064 cross compiler due to the missing Extended support. Until FPC provides the necessary code to emulate 80-bit floating point we simply avoid this potential headache by not providing it. As this has been discussed ad nauseam already, this decision is not up for discussion. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Attn: Sven Can not use "specialize" to resolve forward declaration
Martin Frb via fpc-devel schrieb am Do., 9. Dez. 2021, 00:15: > https://gitlab.com/freepascal.org/fpc/source/-/issues/39459 > You wrote > >> No, this can not and this will never work. When a generic parameter has > a constraint that constraint *must* be adhered to and a forward > declaration is *not* a valid type for such a constraint (except for > *class* / TObject constraints). > > Using TObject for just any class is nice here. > > What to use for interface? > https://gitlab.com/freepascal.org/fpc/source/-/issues/39459#note_758496897 > > Sorry replied on the wrong issue. > > > How can I restrain a generic param, so it must be an interface, but leave > open the exact type, so I can later use a forward declaration? > For interfaces you can use IInterface/IUnknown though that will work only for COM interfaces. For raw interfaces there is no solution currently. In my opinion you should rethink your code structure however. I don't know right now what would be better, but as it is now it feels bad. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI status in 3.2.0 and 3.2.2
Gennady Agranov via fpc-devel schrieb am Sa., 18. Sep. 2021, 01:11: > Hi, > > I have Delphi RTTI code that takes record's type info, finds method and > calls it... > > The code does not seem to work in 3.2.0 (SEGV) > > Should it work? > > Should I try 3.2.2 or there are other ways to call record method in FPC? > No, this is not yet supported, but it's a work in progress, but it will arrive the earliest with 3.4 which is not yet planned. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Undefined symbol during linking - any suggestions?
Am 08.09.2021 um 06:33 schrieb Gennady Agranov via fpc-devel: Hi, linker complains about undefined symbol .Lj3016 I checked *.s files and found that one file has no label .Lj3016 but has following line: leaq .Lj3016(%rip),%rdx Am I correct that that this *.s file should also have a label? Yes. Can you show more of what the surrounding code is doing (you should compile with -al so that the code lines are contained there as well if you haven't done so already) and what optimization options are you using for compilation? Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size
Bart via fpc-devel schrieb am Di., 24. Aug. 2021, 06:31: > On Mon, Aug 23, 2021 at 3:35 PM Yuriy Sydorov via fpc-devel > wrote: > > > Just move common.dll from SysWOW64 to system32. The file is placed > wrongly > > by some installer. > > If I understand Tomas correctly then that would not make any > difference: wether or not that specific common.dll is in system2 or > syswow64, Windows just makes fpc believe it is in system32 anyway, AND > fpc decides this is the wrong common.dll and aborts. > Wrong. If it would be a 64-bit DLL in System32 of a x86_64 system then there would be no problem. However a 64-bit DLL in the SysWOW64 directory (thus the 32-bit System32 directory) *is* a problem. Same for a 32-bit DLL in the System32 directory of a x86_64 system. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size
Am 23.08.2021 um 19:33 schrieb Bart via fpc-devel: On Mon, Aug 23, 2021 at 7:16 PM Bart wrote: I tried to build with only the path to the starting compiler in %PATH%: PATH /devel/fpc/3.2.2/bin/i386-Win32 make clean make all OPT=... That failed on make clean: That error goes away if I add C:\Windows to the path. However, then I get the same build error: Compiling .\oracle\src\oraoci.pp oraoci.pp(1437) Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size oraoci.pp(1437) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted (Even if I adjust the path to C:\devel\fpc\3.2.2\bin\i386-win32) So, why then does fpc find the (wrong) common.dll in c:\windows\system32? It seems I'm stuck with a machine with which I cannot build fpc anymore. FPC finds the wrong library, because some stupid installer decided to place the 64-bit DLL in the 32-bit library folder which is simply *wrong*. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Build failure in Fedora 35 due to glibc 2.34 code hardening
Am 08.08.2021 um 10:06 schrieb Florian Klämpfl via fpc-devel:
Am 07.08.2021 um 16:59 schrieb Mattia Verga via fpc-devel
:
Fedora has recently moved to using glibc 2.34. That caused Free Pascal
Compiler to stop building with the following output:
/usr/bin/ld:
/builddir/build/BUILD/fpcbuild-3.2.2/fpcsrc/rtl/units/powerpc64-linux/si_c.o:(.data.n_TC_$SI_C_$$_START_ADDRESSES+0x10):
undefined reference to `__libc_csu_init'
/usr/bin/ld:
/builddir/build/BUILD/fpcbuild-3.2.2/fpcsrc/rtl/units/powerpc64-linux/si_c.o:(.data.n_TC_$SI_C_$$_START_ADDRESSES+0x18):
undefined reference to `__libc_csu_fini'
Error: Error while linking
One of the guys responsible for glibc in Fedora gave this explanation:
It's related to startup code hardening in glibc. In general, it's
not forward-compatible to call internal glibc functions this way.
__libc_csu_init and __libc_csu_fini where never part of any header file.
It's not clear to me why fpc needs to replace the startup code. They
could supply a C main function and call Pascall code from that.
Or
compile the main program in such a way that it has a compatible
interface with the C main program.
This is not what we want. We just want to initialize glibc from *our* startup
code for various reasons. And if a library is written properly, this must be
possible.
Written properly for C perhaps, but not for anything else... *rolls eyes*
Anyway, it feels as if the startup code situation on Linux is a bit of a
wild west, cause e.g. x86_64 and i386 don't use the libc_csu_{init/fini}
functions at all and i386 does not even use libc_start_main if I see
that correctly... Most non-x86 platforms seem to make use of them however.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
