[fpc-devel] Policy on platform-specific compiler code

[Jonas Maebe]

On 16/10/2020 10:14, J. Gareth Moreton via fpc-devel wrote:

> Before I go optimising the wrong thing, I have a question to ask. 
> What's the policy on platform-specific assembly language in the
> compiler, or any code designed to run on a specific (source) platform
> (and using a more generic implementation otherwise via $ifdef)?  I ask
> because I have a faster algorithm for "calc_divconst_magic_unsigned" in
> 'compiler/cgutils.pas', but it's only able to work because it can take
> advantage of the x86 DIV instruction using RDX:RAX (or EDX:EAX) as a
> double-wide dividend. It is somewhat faster than what currently exists
> because of the lack of a loop whose iteration count is proportional to
> log2(d), where d is the desired divisor (in other words, it's slower the
> bigger the divisor is, whereas my algorithm is constant speed).

In general, there should be no assembly language in the compiler. Ialso
 don't think that's worth it in this case. Unless (or maybe "even if")
your code contains nothing but divisions by constants, I doubt this code
has a significant effect on the total compile time.

> Speaking of "calc_divconst_magic_unsigned", exactly what is the function
> doing? I'm guessing it's something akin to Newton-Raphson division, but
> there's no comments on documentation explaining which algorithm is being
> used (although I can appreciate what "magic_add" is just from my own
> experiences).

The theory is explained in
https://dominoweb.draco.res.ibm.com/6005bbbc96b898df852578dc005be861.html

> On a related note, its partner function,
> "calc_divconst_magic_signed", uses 'assert' rather than an internal
> error, which is a bit against the code guidelines, right?

I don't think asserts are enabled in the compiler, so it indeed won't
work and should be an internalerror. The code was probably translated
from C.


Jonas