Martin Frb schrieb am Di., 29. Okt. 2019, 20:08:
> About https://bugs.freepascal.org/view.php?id=34881
>
> First of all, big thanks to Sven for the patch.
> I had a look at it, I also looked through the alternatives again.
>
> First of all the patch would need some tweaking (but that is to be
> e
On Tue, 29 Oct 2019, Ben Grasset wrote:
On Sun, Oct 27, 2019 at 5:27 AM Michael Van Canneyt
wrote:
Saying that the code is 'almost unusably slow' is the kind of statement
that does
not help. I use the code almost daily in production, no complaints about
performance, so clearly it is usable.
About https://bugs.freepascal.org/view.php?id=34881
First of all, big thanks to Sven for the patch.
I had a look at it, I also looked through the alternatives again.
First of all the patch would need some tweaking (but that is to be
expected), but I am not sure it is the best way to go.
Under
On Sun, Oct 27, 2019 at 5:27 AM Michael Van Canneyt
wrote:
> Saying that the code is 'almost unusably slow' is the kind of statement
> that does
> not help. I use the code almost daily in production, no complaints about
> performance, so clearly it is usable.
>
> Instead, demonstrate your claim w
On 29/10/2019 14:24, Michael Van Canneyt wrote:
On Tue, 29 Oct 2019, J. Gareth Moreton wrote:
Please note that only Marco's e-mails are making the list. I don't
see Michael's responses.
That's probably because I am not responding ;-)
Michael.
Yep, just noticed that Marco was responding
Oh, I just noticed you're replying to messages from a few days ago. Oops!
There is no right way of going about optimisation. I'm of the school
that if you can give the compiler a helpful hint, without complicating
the code, then do it.
In one way I compare it to the id Tech (Quake) and Unre
On Tue, 29 Oct 2019, J. Gareth Moreton wrote:
Please note that only Marco's e-mails are making the list. I don't see
Michael's responses.
That's probably because I am not responding ;-)
Michael.___
fpc-devel maillist - fpc-devel@lists.freepasca
Please note that only Marco's e-mails are making the list. I don't see
Michael's responses.
Gareth aka. Kit
On 29/10/2019 13:41, Marco van de Voort wrote:
Op 2019-10-27 om 10:27 schreef Michael Van Canneyt:
Absolutely.
Personally, I don't have any concern for performance in this sense.
Op 2019-10-27 om 10:27 schreef Michael Van Canneyt:
Absolutely.
Personally, I don't have any concern for performance in this sense.
Almost zero.
I invariably favour code simplicity over performance, for sake of
maintenance.
But there is another kick-in-the-open-door statement about perfor
Op 2019-10-27 om 10:46 schreef Florian Klämpfl:
Am 27.10.19 um 10:27 schrieb Michael Van Canneyt:
If you genuinely believe that micro-optimization changes can make a
difference:
Submit patches.
As said: I am against applying them. Why? They clutter code and after
all, they make assumption
Op 2019-10-29 om 12:23 schreef J. Gareth Moreton:
When it comes to testing vectorcall, uComplex isn't the best example
actually because most of the operators are inlined. There are a
number of tests under "tests/test/cg" that test vectorcall and the
System V ABI using a Pascal implementation
When it comes to testing vectorcall, uComplex isn't the best example
actually because most of the operators are inlined. There are a number
of tests under "tests/test/cg" that test vectorcall and the System V ABI
using a Pascal implementation of the opaque __m128 type (the two ABIs
should beha
Op 2019-10-27 om 09:02 schreef Florian Klämpfl:
I guess you're right. It just seems weird because the System V ABI
was designed from the start to use the MM registers fully, so long as
the data is aligned. In effect, it had vectorcall wrapped into its
design from the start. Granted, vectorc
Thanks George,
As Florian stated, my work on the optimiser overhaul has been rejected
because of how intertwined it is, along with some elements of 'code
smell', but there's plenty to salvage and he hasn't slammed the door on
the concept. I'm still learning to use git and patches, especially
> Oh yeah, conflict resolution is the thing nobody really gets right, but TGit is> a bit less wrong.> I've pretty much resigned myself to Ctrl-F ">"... I use Intellij IDEA as VCS client (both git and svn supported).Patches, partial commits and conflicts resolution (automatic for many cases) are
Hello,
Would it be possible to add a macro definition (in trunk) to indicate
that attributes are supported ?
E.g. FPC_HAS_CUSTOMATTRIBUTES
Thanks.___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/
16 matches
Mail list logo