Another point to bring up...
I could easily write a cross-platform complex number library that is
designed to take advantage of vector registers whenever possible for the
absolute best performance, but there comes a problem of having multiple
libraries that do the same thing and not really sti
On Sun, 27 Oct 2019, Sven Barth via fpc-devel wrote:
Michael Van Canneyt schrieb am So., 27. Okt. 2019,
10:58:
Best of all would IMHO be to abolish or even totally ignore 'inline'.
It is a hint, after all. The compiler is not forced to inline, even
when the modifier is there.
That would
Michael Van Canneyt schrieb am So., 27. Okt. 2019,
10:58:
> Best of all would IMHO be to abolish or even totally ignore 'inline'.
> It is a hint, after all. The compiler is not forced to inline, even
> when the modifier is there.
>
That would be a bit problematic: auto inlining needs to first pa
Hi,
if it helps I can build ppcrossavr until 43318 revision.
IMHO, the 43319 rev. commit broke AVR build somehow.
regards,
--
Dimitrios Chr. Ioannidis
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-b
Hi,
tried to build a ppcrossavr with :
"make.exe clean crossall crossinstall CPU_TARGET=avr
OS_TARGET=embedded SUBARCH=avr5
INSTALL_PREFIX=G:\Programming\dimitris\tools\fpc-trunk
CROSSBINDIR=G:\Programming\dimitris\tools\avr8-gnu-toolchain\bin
CROSSOPT="-g -gw2 -O1 -dDEBUG" BINUTILSPREFI
On Sun, 27 Oct 2019, Martok wrote:
Am 27.10.2019 um 17:48 schrieb Florian Klämpfl:
I guess the main difference is whether one prefers side-by-side
diffs or udiffs.
In particular partial commits as well as conflict resolution work much
better with TortoiseGit for me.
Oh yeah, conflict res
Am 27.10.2019 um 17:48 schrieb Florian Klämpfl:
>> I guess the main difference is whether one prefers side-by-side
>> diffs or udiffs.
>
> In particular partial commits as well as conflict resolution work much
> better with TortoiseGit for me.
Oh yeah, conflict resolution is the thing nobody rea
Hi,
I use TortoiseHg and then a Mercurial to Git converter...
Unfortunately the linux distributions do not want to maintain it and
most ship with an outdated TortoiseHg in their package management
Best,
Benito
On 27.10.19 17:48, Florian Klämpfl wrote:
Am 27.10.19 um 15:32 schrieb Martok:
co
Am 27.10.19 um 15:32 schrieb Martok:
cover one single topic. Today, using e.g. TortoiseGit on Windows (sorry,
on Linux there is no tool which comes close) such patches can be
re-arranged without too much hazzle.
Just plain ol' git-gui can also do it. SmartGit is cross-platform and also
pretty n
> cover one single topic. Today, using e.g. TortoiseGit on Windows (sorry,
> on Linux there is no tool which comes close) such patches can be
> re-arranged without too much hazzle.
Just plain ol' git-gui can also do it. SmartGit is cross-platform and also
pretty nice. I guess the main difference
On 27/10/2019 13:16, C Western wrote:
> I have a project that triggers Internal error 200609171 when compiled
> for 64 bit Mac with -gw3 set. It works fine on other platforms, or if a
> different debug mode is set. The error is triggered on the first var in
> the implementation section. I would cre
More than anything, we would need a code sample that would reliably
reproduce the bug. Granted we can look at the source code to see what
200609171 eludes to, but it would be largely guesswork on how it's
triggered. If you're able to narrow down the code sample enough to put
into a report, an
I have a project that triggers Internal error 200609171 when compiled
for 64 bit Mac with -gw3 set. It works fine on other platforms, or if a
different debug mode is set. The error is triggered on the first var in
the implementation section. I would create a bug report, only it is not
obvious h
Originally my patch just added the "vectorcall" calling convention to
the functions; the "const" modifier was suggested by a third party and
seemed sensible enough. I weighed up the fact that it wouldn't change
how to you call the function in Pascal code and accepted it. The patch
should be e
On Sun, 27 Oct 2019, J. Gareth Moreton wrote:
I was more referring to the use of correct types, use const when
possible etc.
Change classes to advanced records where appropriate, that kind of thing.
Michael.
Which is why I hoped my patches for uComplex were permissible, since it
adds 'c
I was more referring to the use of correct types, use const when
possible etc.
Change classes to advanced records where appropriate, that kind of thing.
Michael.
Which is why I hoped my patches for uComplex were permissible, since it
adds 'const' to make the compilation more efficient and s
Ideally, you should specify 'vectorcall' either when interfacing with
third-party libraries, when the code can be vectorised by the compiler,
or when doing it yourself in assembly language. For example, if I
wanted to write the cmod function in x86_64 assembler (Intel notation):
function cmod
The following passes everything through XMM0:
#include
#include
doubleMod(__m128dz)
{
returnsqrt((z[0]*z[0])+(z[1]*z[1]));
}
intmain()
{
__m128dz;
z[0] = 0; z[1] = 1;
doubled = Mod(z);
}
I will admit that it's very fiddly to get right. All of my attempts to
map an anonymous struct to __m128d
On Sun, 27 Oct 2019, Florian Klämpfl wrote:
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 assumptions
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 assumptions about the current target which not might be
alw
On Sat, 26 Oct 2019, Ben Grasset wrote:
On Sat, Oct 26, 2019 at 1:31 PM Florian Klämpfl
wrote:
This is imo a waste of time and clutters only code. It is much more
beneficial to
improve the compiler to avoid a copying of the variable if it can prove
that it is not needed (or to improve auto
Am 23.10.19 um 22:36 schrieb J. Gareth Moreton:
So I did a bit of reading after finding the "mpx-linux64-abi.pdf"
document. As I suspected, the System V ABI is like vectorcall when it
comes to using the XMM registers... only the types __m128, __float128
and __Decimal128 use the "SSEUP" class a
Am 27.10.19 um 01:07 schrieb Ben Grasset:
FPC doesn't do so currently, and as far as I can tell probably
won't in the foreseeable future.
Yes, people write only lengthy mails on fpc-devel instead of writing code.
___
fpc-devel maillist - fpc-devel@l
Am 27.10.19 um 07:32 schrieb J. Gareth Moreton:
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, vectorca
24 matches
Mail list logo
