[fpc-pascal] IDLE_PRIO with FPC-compiled processes
Hi all Have anybody experienced exceptions "Failed to create new thread" when FPC-compiled process priority changed with schedtool -D [pid]? -- Regards, Denis Golovan ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Extended type under Win64
Hi all I'm trying to get an idea if Extended float is/can actually be 80bit? I have FPC built under Linux x64 and it works fine (co-processor command are actually used). But I haven't found any reliable information about Win64 support. Brief FPC source grepping showed FPC_HAS_TYPE_EXTENDED define, but I haven't managed to find where it is defined. -- Regards, Denis Golovan ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Extended type under Win64
> The Extended type is not available for x86_64-win64. You either need to use > Double or the software floating point support in unit sfpux80 (though that is > only available in 3.2 and newer). So, Linux x64 having hardware Extended support is just an exception? Or maybe it's possible to build a custom x86_64-win64 compiler with that define enabled? > Please note that you'll have the same problem on any non-x86 platform as that > type only exists there (and m68k). Yes. I am perfectly ok with Intel only. -- Regards, Denis Golovan ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Extended type under Win64
> In theory yes, but it's not recommended, because Microsoft does not recommend > it (not to mention that it isn't even remotely tested as much as the normal > Win64 target). > > Regards, > Sven Got it. Thanks for the clarification. -- Regards, Denis Golovan ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Option type
Hi all I am trying to implement Option type in FPC. type generic TOption = record case IsSome:boolean of true: ( some: T ); false: (); end; However fpc just emits errors: Error: Type parameters may require initialization/finalization - cannot be used in variant records Could anybody suggest some sane workaround for the problem? -- Regards, Denis Golovan ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Option type
> You need to use a constraint like: > > type > generic TOption = record > case IsSome:boolean of > true: ( some: T ); > false: (); > end; > > Not sure why though. > > Regards, > Ryan Joseph That would limit supported types to class instances. I'll like to avoid that. Ideally TOption type should allow any type (primitives, strings, objects, class instances, etc). -- Regards, Denis Golovan ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Option type
> You simply can't use managed types in a variant clause and as T could be > a managed type the compiler does not allow it. Well. I thought it should be precisely the case for variant clause to properly handle. Compiler knows IsSome field is used to determine if some contains initialized value. On drop/free it would insert check: if IsSome then finalize(some); > Use Nullable.TNullable. Thanks. It's something close to what I need. -- Regards, Denis Golovan ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Option type
> Well as already discovered type like strings can not go into a "record case" > > But... The above record is anyway of constant size. I.e. the memory for > the field is always included, even if it is not used. > > Since the "false" block is empty, you can do > > type > generic TOption = record > IsSome:boolean; > some: T; > end; > > It is not as expressive to the reader of the code. But it leads to the > same data in memory. Yes. Except that "some" is still initialized with something (some default) and dropped and copied and assigned despite conceptually being empty. -- Regards, Denis Golovan ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Management operators memleaks
Hi all I created a test case for rather unusual behaviour of management operators in fpc 3.3.1. In some specific cases they produce memory leaks. I suspect it's some compiler issue. Could somebody take a look at https://bugs.freepascal.org/view.php?id=38990 ? P.S. Sorry for attaching quite large test case. -- Regards, Denis Golovan ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Management operators memleaks
Could anybody reply? Am I doing something wrong? Are management operators supported or not? -- Regards, Denis Golovan ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Management operators memleaks
> I have not looked at your test case yet, but it *might* be related to > issue #37164 ( https://bugs.freepascal.org/view.php?id=37164 ). Thanks for the point, Sven. Is there something I can do to prioritize the issue? -- Regards, Denis Golovan ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Inactive account on GitLab
Hi all Could anybody look at GitLab MageSlayer account? I can neither login nor change my password. Maybe my mail has not been transferred? -- Regards, Denis Golovan ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Inactive account on GitLab
> FPC's git and issue trackers are hosted on Gitlab itself, we have no > authority to do > user management. Ok. I managed to sign up and login. Does it mean my old issues cannot be linked to my GitLab account? -- Regards, Denis Golovan ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Inactive account on GitLab
> I starred the projects of those bugs (FPC/FPC/Source and > FPC/Lazarus/Lazarus) but my todo list is still empty. > Not a biggie now that I know how to find my bugs, though I'd prefer to > find them with the proper filter (the first one with author_username) > and not with a full text search. Same problem - my todo list is empty. I can find my issues by those "indirect" ways though :) -- Regards, Denis Golovan ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Compiler internals. Changing dynamic arrays format
Hi all I've been maintaining a set of private patches for some quite old FPC revision for some years. The idea behind those patches to ease interoperation between FPC and LuaJIT FFI by pointer tagging for dynamic arrays. For that to happen I was forced to modify "tdynarray" record (increase its size to 32 bytes and always align dynamic arrays to 32 bytes) & change some compiler internals to emit proper offset to "high" and "reference count" fields. Bootstrapping patched compiler is quite an adventure. And that is something I'd like to straight-line and I feel that I need some piece of advice. My first trouble is initialization of dynamic arrays with constant arrays. It looks like simply building one version of compiler just makes a build with old-style array constants and my already patched code. That leads to code/constant data format mismatches and new compiler process just crashes. Looks vanilla makefile builds a several versions of compiler progressing to a final version. It seems that my troubles also can be solved by enabling parts of the patchset progressively. More specifically, I plan to enable array serialization code patch first in cyclelevel 1. Then build next compiler level using compiler 1 with rest code enabled to get cyclelevel 2. Cyclelevel2 build should already contain both all code changes and data constants in new format. And finally build cyclelevel3 build with cyclelevel2 compiler to complete build. Is it the right way to go? And if I get it right - could anyone suggest me how to enable my constants code serialization patches (via conditional defines I guess) at cyclelevel 1 and all patches at cyclelevels 2 and 3? -- Regards, Denis Golovan ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiler internals. Changing dynamic arrays format
> On 2022-04-13 00:34, denisgolovan via fpc-pascal wrote:
> Your comment about conditional defines goes in the right direction -
> basically:
>
> 1) Separate your changes into parts affecting the compiler behaviour
> (e.g. the changes impacting the compiled structures and code, etc.) from
> changes needed because of the changed behaviour (i.e. use of your new
> features within the RTL and/or the compiler, modified versions of code
> working with the newly / differently compiled structures, etc.).
>
> 2) Create a conditional define for your new changes - this new define
> would be enabled within the compiler behaviour affecting changes.
>
> 3) Make your changes resulting from the changed behaviour (either in the
> RTL, or in the compiler) enabled only when the new conditional define is
> enabled.
>
> If you do this, you should be able to use the standard makefiles without
> any changes (e.g. "make compiler_cycle", etc.).
>
> Tomas
Ok. It's good then.
I'd like to know about the actual CYCLELEVEL logic implementation details.
So far I haven't found any explicit conditional define related to cycle levels.
I assume something like:
{$IF not defined(FPC_CYCLELEVEL1) and not defined(FPC_CYCLELEVEL2) and not
defined(FPC_CYCLELEVEL3)}
// previous version compiler builds our sources
def_system_macro('FPC_CYCLELEVEL1');
{$ENDIF}
{$IFDEF FPC_CYCLELEVEL1}
// CYCLELEVEL1 compiler builds our sources
def_system_macro('FPC_CYCLELEVEL2');
{$ENDIF}
{$IFDEF FPC_CYCLELEVEL2}
// CYCLELEVEL2 compiler builds our sources
def_system_macro('FPC_CYCLELEVEL3');
{$ENDIF}
{$IFDEF FPC_CYCLELEVEL3}
// CYCLELEVEL3 compiler builds our sources
def_system_macro('FPC_CYCLELEVEL4');
{$ENDIF}
... somewhere in options.pas should be enough.
Or maybe there is already some existing / more reliable way?
-- Regards,
Denis Golovan
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature announcement: implicit generic function specializations
That seriously improves generic code readability. Definitely worth trying to upgrade. Thanks a lot! 20:15, 20 апреля 2022 г., "Sven Barth via fpc-pascal" :Dear FPC community,The FPC developers are pleased to announce the implementation of a new feature: implicit generic function specializations. This feature was implemented by Ryan Joseph, so thank you very much, Ryan.This feature allows you to use generic routines (functions, procedures, methods) without explicitely specializing them (“<…>” in Delphi modes and “specialize …<…>” in non-Delphi modes) as long as the compiler can determine the correct parameter types for the generic.This feature is enabled with the modeswitch ImplicitFunctionSpecialization and is for now not enabled by default as this has the potential to break existing code.Assume you have the following function:=== code begin ===generic function Add(aArg1, aArg2: T): T;begin Result := aArg1 + aArg2;end;=== code end ===Up to now you could only use this function as follows:=== code begin ===SomeStr := specialize Add('Hello', 'World');SomeInt := specialize Add(2, 5);=== code end ===However with implicit function specializations enabled you can also use it as follows:=== code begin ===SomeStr := Add('Hello', 'World');SomeInt := Add(2, 5);=== code end ===The compiler will automatically determine the type of the generic parameters based on the parameters you pass in (this is always done left to right). Depending on the passed in parameters (especially if you're using constant values like in the example instead of variables) the compiler might however pick a different type than you expected. You can enforce a specific type by either explicitely specializing the method as before or by inserting a type cast. In the example above the compile will specialize the call with the parameters “2, 5” using an 8-bit signed type (Pascal prefers signed types) instead of a LongInt as in the explicit specialization. If you use “LongInt(2), 5” as parameters then the compiler will pick that instead, however with “2, LongInt(5)” it will still pick an 8-bit type, because the parameter types are determined left to right.If there exists a non-generic overload for which the parameters types match exactly, the compiler will pick that instead of specializing something anew. So assume you also have the following function in scope:=== code begin ===function Add(aArg1, aArg2: LongInt): LongInt;begin Result := aArg1 + aArg2;end;=== code end ===In the case of “Add(2, 5)” the compiler will *not* pick the non-generic function, because it determines that an 8-bit type is enough, however if you use “Add(LongInt(2), 5)” the compiler will pick the non-generic function.Aside from simple parameters the compiler also supports arrays and function/method variables:=== code begin ===generic function ArrayFunc(aArg: specialize TArray): T;var e: T;begin Result := Default(T); for e in aArg do Result := Result + e;end;type generic TTest = function(aArg: T): T;generic function Apply(aFunc: specialize TTest; aArg: T): T;begin Result := aFunc(aArg);end;function StrFunc(aArg: String): String;begin Result := UpCase(aArg);end;function NegFunc(aArg: LongInt): LongInt;begin Result := - aArg;end;begin Writeln(ArrayFunc([1, 2, 3])); // will write 6 Writeln(ArrayFunc(['Hello', 'FPC', 'World'])); // will write HelloFPCWorld Writeln(Apply(@StrFunc, 'Foobar')); // will write FOOBAR Writeln(Apply(@NegFunc, 42)); // will write -42end.=== code end ===There are of course a few restrictions for this feature:- all generic parameters must be used in the declaration of the routine (implementation only type parameters are not allowed)- all parameters that have a generic type must not be default parameters, they need to be used in the call or their type must have been fixed by a parameter further left (as currently default values for parameters of a generic type are not supported this is not much of a restriction, but should that change (e.g. Default(T)) then this restriction will apply)- the generic routine must not have constant generic parameters (this might be extended in the future with e.g. static arrays or file types, but for now this restriction stands)- the result type is not taken into account, so if only the result type of a routine is generic then an implicit specialization does not work either- function/method pointers to implicit specializations are not yet supported (pointers to explicit specializations are not yet supported either; once this changes the former will change as well)- the compiler will silently discard generic functions that it can't specialize the *declaration* of; however if the declaration can be specialized correctly, but for whatever reason the *implementation* can not then this will trigger a compilation errorThis feature is by and in itself Delphi compatible however there might be differences in what FPC can implicitely specialize and what Delphi can. Especially if Delphi can specialize something tha
Re: [fpc-pascal] Feature announcement: implicit generic function specializations
> If you want to pass a pointer to ^T in a generic function is there anyway > safe to do this currently? Pascal doesn’t allow ^ types in function arguments > (why?) and generics don’t seems to support pointers either (why?). > > generic TValues = array[0..0] of T; > generic PValues = ^specialize TValues; > > I guess the only thing to do is use a untyped pointer and cast it to the > correct type inside the function declaration? > > For example here is a generic QuickSort function which operates on any array > of T. > > type > generic TComparator = function (left: T; right: T; context: pointer): > integer; > > generic procedure QuickSort(_values: pointer; first, last: LongInt; > comparator: specialize TComparator); > type > TValues = array[0..0] of T; > PValues = ^TValues; > var > pivot,j,i: integer; > temp: T; > values: PValues absolute _values; > > Regards, > Ryan Joseph > Not that pretty, but I use something like: == generic TPtr = record public type P = ^T; public ptr: P; end; generic function Ref(out r: specialize TPtr.P):boolean; == Denis Golovan ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Cache-line alignment for records
> However, the maximum alignment you can specify this way is limited per > target (hardcoded in the compiler). In 3.2.x, it's 16 bytes for most > desktop targets. On 3.3.x, it's 64 bytes for most desktop targets. > > Jonas But it's still not possible to attach alignment to type itself instead of variable, right? -- Regards, Denis Golovan ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Cache-line alignment for records
> It is possible > (https://gitlab.com/freepascal.org/fpc/source/-/blob/main/tests/test/talignrec1.pp), > but it is subject to the same limitations when declaring variables of > those types. > > Jonas Aha. Nice! Does it work recursively? I mean - does it work when aligned record is itself a field within other record? -- Regards, Denis Golovan ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Volatile store usage
Hi all I'd like to get some clarification about "volatile" intrinsic. https://wiki.freepascal.org/FPC_New_Features_Trunk#Support_for_.22volatile.22_intrinsic says just following: Support for "volatile" intrinsic Overview: A volatile intrinsic has been added to indicate to the code generator that a particular load from or store to a memory location must not be removed. ... and states that example is here - https://gitlab.com/freepascal.org/fpc/source/-/blob/main/tests/test/tmt1.pp However I cannot find "store" usage example there. Only "load". Are "volatile" stores supported? I tried following using my rather old 3.3.1 compiler, but none of them compile: volatile(mem):=0; mem:=volatile(0); Any help? -- Regards, Denis Golovan ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Volatile store usage
> On 11/08/2023 18:05, denisgolovan via fpc-pascal wrote: > >> Are "volatile" stores supported? > > They weren't, but I've added support for it now. Aha. Thanks. -- Regards, Denis Golovan ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Barriers semantics
Hi all Now we have "volatile" intrinsic for assignments in place, I'd like to ask for another clarification. Documentation states we have following barriers - ReadBarrier, WriteBarrier, ReadDependencyBarrier, ReadWriteBarrier. I'd like to get an idea how those related to more common / standard terms - Acquire/Release & their combinations? Is it safe to assume that: ReadBarrier - Acquire WriteBarrier - Release ReadWriteBarrier - Acquire+Release ReadDependencyBarrier - which one is that? -- Regards, Denis Golovan ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Barriers semantics
> On 14/08/2023 18:19, denisgolovan via fpc-pascal wrote: > >> Now we have "volatile" intrinsic for assignments in place, I'd like to ask >> for another clarification. > > Just to make sure given your questions below: using volatile in the > context of multithreaded code is completely wrong in 99.9% of the cases, > and when it's not in the best case it's usually just highly inefficient. > volatile in FPC/C++ is unrelated to volatile in Java or C# in that respect. As long as volatile marks data access and but not field attribute - I am very much fine with it. Let Java/C# devs suffer it :) > >> Documentation states we have following barriers - ReadBarrier, WriteBarrier, >> ReadDependencyBarrier, ReadWriteBarrier. >> >> I'd like to get an idea how those related to more common / standard terms - >> Acquire/Release & their combinations? > > Read/Write barriers are terms used in cpu architecture manuals. > Acquire/Release are high level parallel programming terms. > >> Is it safe to assume that: >> >> ReadBarrier - Acquire >> WriteBarrier - Release >> ReadWriteBarrier - Acquire+Release >> ReadDependencyBarrier - which one is that? > > You cannot express a ReadDependencyBarrier in terms of acquire/release. > See e.g. the explanation of "data dependency barrier" at > https://www.sobyte.net/post/2022-08/cpu-cache-and-memory-barriers/ . In > practice, I don't think any currently used cpu architectures still > require such barriers though. Ok. I assume I got it right. This field lacks common terms for some reason. -- Regards, Denis Golovan ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Cmdline parser
Hi all Could anybody suggest some existing command line parser for FPC having following requirements: 1. Crossplatform with stable semantics - Linux/Windows. 2. Short and long values support. 3. Support for "generic parsing". I mean being able to parse from string any unknown set of args as logn as they conform to standard short/long grammar. 4. Must support "--" separator for splitting "rest" of command line for passing as one string further. 5. Support for quoted / escaped string values. 6. Having unit-tests :) 7. MPL/MIT license I'd like to avoid creating another half-baked parser :) Perhaps any existing parser willing to accept patches will do as well. -- Regards, Denis Golovan ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
