I would like to offer support for the relatively new AVR 8-bit
subarchitecture avrxmega3 which includes the following series: megaAVR 0,
tinyAVR 0 and 1. This adds 35 new controllers to FPC's repertoire. The
current state can be viewed in a git branch (
https://github.com/ccrause/freepascal/tree/
Hi everyone,
So I'm still focused on x86 for the moment, and I'm still looking for
ways to both increase the speed of the compiler and also find new
optimisations. Currently I'm building a few more principles of my "Deep
Optimizer" into OptPass1MOV that are showing promise - I should have a
p
Seems fair.
The main thing that I'm wary of is memory alignment. SSE works best
with structures that are aligned to a 16-byte boundary - attempting to
call MOVAPS with a structure that isn't aligned will trigger an access
violation, while MOVUPS is considerably slower on older processors.
T
Am 18.01.2020 um 18:52 schrieb J. Gareth Moreton:
I think more than anything I would like to see a degree of "ease of
use" for the SIMD intrinsics, since modifying __m128 data in C/C++ is
not that straightforward. Just as a straightforward example, what
might be the best way to ensure these
Am 18.01.20 um 19:29 schrieb J. Gareth Moreton:
I personally would have thought the compiler would be smart enough to
promote a 128-bit array to an XMM register when among intrinstics or
just passing the structure as a whole from one place to another, but
utilise memory movement or the scalar S
I personally would have thought the compiler would be smart enough to
promote a 128-bit array to an XMM register when among intrinstics or
just passing the structure as a whole from one place to another, but
utilise memory movement or the scalar SSE commands when modifying
individual fields. I
Am 18.01.20 um 18:52 schrieb J. Gareth Moreton:
I think more than anything I would like to see a degree of "ease of use"
for the SIMD intrinsics, since modifying __m128 data in C/C++ is not
that straightforward.
... because there exist in general no instructions to do so, e.g. you
cannot ac
I think more than anything I would like to see a degree of "ease of use"
for the SIMD intrinsics, since modifying __m128 data in C/C++ is not
that straightforward. Just as a straightforward example, what might be
the best way to ensure these following record types are compatible with
the __m12
Am 18.01.2020 um 13:18 schrieb Florian Klämpfl:
Am 18.01.20 um 12:53 schrieb Sven Barth via fpc-devel:
Am 18.01.2020 um 12:46 schrieb Florian Klämpfl:
Am 16.01.20 um 23:22 schrieb J. Gareth Moreton:
Hey everyone,
Maybe I'm being a bit pedantic with this, but must we abide by
C/C++ standards
Am 18.01.20 um 12:53 schrieb Sven Barth via fpc-devel:
Am 18.01.2020 um 12:46 schrieb Florian Klämpfl:
Am 16.01.20 um 23:22 schrieb J. Gareth Moreton:
Hey everyone,
Maybe I'm being a bit pedantic with this, but must we abide by C/C++
standards and go by the name __m128 etc. for the 128-bit da
Am 18.01.2020 um 12:46 schrieb Florian Klämpfl:
Am 16.01.20 um 23:22 schrieb J. Gareth Moreton:
Hey everyone,
Maybe I'm being a bit pedantic with this, but must we abide by C/C++
standards and go by the name __m128 etc. for the 128-bit data type?
They can be added additionally. After some t
Am 16.01.2020 um 23:22 schrieb J. Gareth Moreton:
Hey everyone,
Maybe I'm being a bit pedantic with this, but must we abide by C/C++
standards and go by the name __m128 etc. for the 128-bit data type?
Being as how Pascal tended to go for more readable and BASIC-inspired
names like Integer an
Am 16.01.20 um 23:22 schrieb J. Gareth Moreton:
Hey everyone,
Maybe I'm being a bit pedantic with this, but must we abide by C/C++
standards and go by the name __m128 etc. for the 128-bit data type?
They can be added additionally. After some thinking, I came to the
conclusion we should firs
13 matches
Mail list logo
