TARGET_x64_SYSV define

[andersmelander]

A new compiler define, TARGET_x64_SYSV, has been added to GR32_Compiler.inc (currently only in the TARGET_x64_SYSV branch).
The symbol is defined when both FPC and CPUX86_64 are defined but MSWINDOWS is not defined and is mutually exclusive to the TARGET_x86 and TARGET_x64 defines.

The primary purpose, right now, is to enable @CuriousKit to add support for FPC targeting [some x64 architecture other than Windows (see next msg)] the Raspberry Pi running Arch Linux ARM on the ARM64/Aarch64 architecture.

[CuriousKit]

Almost. TARGET_x64_SYSV is for non-Windows x86-64 machines like Linux and Intel-based MacOSX. For the AArch64 architecture, I'll request a TARGET_AARCH64 or TARGET_ARM64 or some such. I want to be doubly sure that at least some of the test suite can run under FPC though to make sure I don't screw things up!

P.S. Thank you though!

[andersmelander]

Since TARGET_x64_SYSV is mutually exclusive to TARGET_x86 and TARGET_x64, enabling the symbol is bound to break the existing code.
At present only two functions has TARGET_x64_SYSV implementations. All other assembler functions will fall into one of the following categories:

• They will test for TARGET_x86 and then default back to a x64 implementation, most likely failing at run time.
• They will test for TARGET_x86 and TARGET_x64 and fail at compile time if neither is defined.

Normally we would just handle a new or unknown architecture with the all-or-nothing define PUREPASCAL. Most likely, only a subset of functions will get TARGET_x64_SYSV implementations so how do we handle the situation with partial TARGET_x64_SYSV and partial PUREPASCAL?

• We could change all {$ifdef PUREPASCAL} to {$if defined(PUREPASCAL) or defined(TARGET_x64_SYSV)} (except where there actually was support for TARGET_x64_SYSV).
• We could add {$ifdef TARGET_x64_SYSV} {$define PUREPASCAL} {$endif} to all units (except those that contained TARGET_x64_SYSV implementations).

Suggestions?

Regardless I will need to change the recent TARGET_* handling in GR32_Math so it doesn't fail with "Missing target" at compile time:

graphics32/Source/GR32_Math.pas

Lines 261 to 275 in 5e73183

	function FixedFloor(A: TFixed): Integer; {$IFDEF FPC} assembler; nostackframe; {$ENDIF}
	asm
	{$if defined(TARGET_x86)}
	SAR EAX, 16
	{$elseif defined(TARGET_x64)}
	MOV EAX, ECX
	SAR EAX, 16
	{$else}
	{$error 'Missing target'}
	{$ifend}
	end;

[CuriousKit]

Most likely, any function that has a TARGET_x64 assembly version will need a separate TARGET_x64_SYSV implementation because of different registers being used to pass parameters. In the FixedFloor example above, a TARGET_x64_SYSV version would be:

         MOV     EAX, EDI 
         SAR     EAX, 16 

• In general, under the System V ABI, integer parameters are passed through RDI, RSI, RDX, RCX, R8 and R9 in that order. RBX, RSP, RBP, R12, R13, R14 and R15 must be preserved.
• Under the Microsoft x64 ABI, Integer parameters are passed through RCX, RDX, R8 and R9 in that order. The same registers must be preserved as with the System V ABI, but in addition, so must RDI and RSI.
• There are some special rules with the mixing of floating-point parameters and integer parameters that are different between the two ABIs. Additionally, the System V ABI supports vectorisation, while the Microsoft x64 ABI does not unless it uses the vectorcall calling convention (FPC does support this... it was actually one of the first merge requests I made for the compiler).

[andersmelander]

I just pushed a proposed solution to the TARGET_x86/TARGET_x64/TARGET_x64_SYSV/PUREPASCAL problem: 8881f53
For some reason Github isn't displaying automatically here although the link works the other way.

Anyway, I'm too busy to explain the code right now. I'll try to find time later.

[andersmelander]

First of all, here's the commit msg (so I don't have to repeat that):

Refactored GR32_Math PUREPASCAL and the various asm implementation into separate pure abstract classes.

Base class is PUREPASCAL, all methods are static class methods. Derived classes only override the functions that they have implementations for.
Outside function calls are directed to the correct implementation via class alias and existing binding system.
The extra indirection (function->method) should be eliminated via inlining but Delphi appear to have problems with that in some cases.

So, first of all, the classes of course aren't pure abstract; They're just abstract. Muscle memory got me there.

The main nice thing about the solution is that is solves the problem of a given target (mainly looking at TARGET_x64_SYSV here) being mutually exclusive to PUREPASCAL and only implementing a subset of the possible functions. Getting rid of all the inline {$IFDEF} has also improved code readability immensely.
The method resolution, deciding which implementation to compile into the code, happens at compile-time without any run-time overhead, via inheritance scoping. Since all methods are non-virtual, static class methods, there's no VMT dispatch and no self instance references.

Unfortunately there are also a few downsides:

• Due to the way I have organized the methods (by class, then method), the different implementations of a function are no longer located right next to each other.
  This is a minor issue but it means that it will become more difficult to ensure that the different implementations stay in sync with each other since it's more difficult to view them all at once and compare them.
  That said, many x86/x64 functions only differ in the register prologue/epilogue and these functions can be moved to the common base class I have declared for that purpose: GR32Math_x86x64.

• Delphi can't handle non-virtual methods being overloaded in derived classes.
  For example, the SinCos method has 3 overloads:

    GR32Math_Pascal = class abstract
    [...]
    class procedure SinCos(const Theta: TFloat; out Sin, Cos: TFloat); overload; static;
    class procedure SinCos(const Theta, Radius: TFloat; out Sin, Cos: TFloat); overload; static;
    class procedure SinCos(const Theta, ScaleX, ScaleY: TFloat; out Sin, Cos: TFloat); overload; static;

  If we override one or more of these in a derived class, then we get an "E2251 Ambiguous overloaded call" error even though I would have thought the compiler would just use scoping to resolve that ambiguity. One might think that we could solve this with the "reintroduce" directive, but that only works for virtual methods.
  Another minor problem with overloads is that in some cases (e.g. the binding system) we need to be able to get the address of an overloaded method. While it is possible to do, you have to jump through a few hoops to get there.
  The solution has been to not use overloads but instead give the methods unique names. For example SinCos1, SinCos2, SinCos3.

• Since the main API for all these functions are the existing simple, non-class, procedures and functions, those has been rewritten to instead just forward to the corresponding class methods. This add an extra layer of indirection, which means extra call overhead. In order to eliminate this overhead all the functions have been declared "inline".
  Unfortunately there's no guarantee that the functions actually will be inlined. For example Delphi refuses to inline functions unless their implementing unit is included in the interface section of the unit where they are used. While this might not be a practical problem for the GR32_Math unit, it can be a blocking problem for other units where we might wish to adapt this technique.
  It might also impact non-expert users who most like don't understand the rules of inlining (although they will probably include everything in the implementation section anyway).

Although I think, from the POW of implementing TARGET_x64_SYSV and others like it, that the benefits of this solution outweighs the problems, I am very reluctant to just merge a radical change like this into master before there's substantial benefit from doing so. The primary target of Graphics32 still is Windows so we can't do anything that cripples that target.
We also need some practical experience from working with it before final judgment can be passed. It might look good but be sh*t to work with and maintain.

So for now, if the proposed solution is accepted by @CuriousKit (and take your time with it - no rush), I will merge it into the TARGET_x64_SYSV branch but then the changes will stay there, meaning the TARGET_x64_SYSV branch will also not get merged into master for the foreseeable future.

[CuriousKit]

This seems like a pretty sound solution with your class system. It also alleviates the pressure of having to write an assembly version of every function, especially if it's known that the compiler produces the most optimal version already. I'll have a closer study of it over the coming days, but we may need the input of other maintainers before something this drastic is approved.