Am 10.11.19 um 16:02 schrieb J. Gareth Moreton:
This message chain has proven to be a lot more educational and
insightful than I would have given it credit for. Thanks everybody!
I know a lot of the time, the size of binaries is just an illusion,
along with unfair comparisons with GCC (a behemoth with corporate
support) and Microsoft Visual C++ that often hides the size of binaries
behind a redistributable library. I don't ever seek to make binaries
smaller at the expense of speed, but if I see a potential saving that
could be done automatically, I dive for it!
On 10/11/2019 14:47, Marco van de Voort wrote:
(and btw, if you are serious about these scenarios, drop all
optimization work immediately, and start working on packages :-)
I did try to start simple with the 'uComplex' unit, but concerns were
raised because I changed the formal parameters to 'const' and aligned
the complex type on x86-64 platforms so it can take advantage of XMM
registers better (which, given proper optimisation, would result in both
smaller code size and higher speed). While I made sure that the
interfaces would not change for Pascal code, assembler code that calls
the functions (if it exists) might need to be changed slightly
(something Florian raised). I'm not quite sure what the rules are when
it comes fo updating packages, other than the obvious one of not
breaking old code.
Currently, there is no real gain by changing the calling conventions.
When we have a vectorizer, we can talk about it.
I like working on optimisation because I have a morbid fascination with
the lowest level of the CPU and I feel well-suited for it, although
there are still some things I'm learning about it.
Gareth aka. Kit
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
