Hello together!
I'm happy to announce initial support for the Windows on ARM64 target,
aka aarch64-win64.
Simple programs work already and the compiler is at least able to
display its help message (when trying to compiler something it silently
crashes, I've not yet found out why that is the
Hi
I think another related idea is adding some "attribute" to dynamic arrays types
to force them to be aligned to 32/64 bytes.
Precisely for this purpose, I am forced to maintain my own FPC fork.
-- Regards,
Denis Golovan
___
fpc-devel maillist -
In that instance, I think it's because TIntArray is not a record type
(it's essentially a smart pointer) and so RECORDMIN doesn't apply to
it. I do agree though that having an 'align' attribute of some kind
will make life a lot easier since you don't have to play around with
multiple
I did suggest it once - https://bugs.freepascal.org/view.php?id=32780 -
it would make things useful and allow for cleaner typecasting with the
internal __m128 type etc. It was assigned, but appears to have stalled.
There might be some portability issues with it, although I think the
feature
I have questions/suggestions WRT Jonas' SVN r42342:
https://github.com/graemeg/freepascal/commit/40d31e34116efffa239b6dc94373fcfccedfa646
1) Why was `typesym.owner` used instead of `owner`? Beside efficiency, this
hurts understandability: is it possible for a typedef to reside in a symtable
> I did suggest it once - https://bugs.freepascal.org/view.php?id=32780 -
> it would make things useful and allow for cleaner typecasting with the
> internal __m128 type etc. It was assigned, but appears to have stalled.
Yeap. That's right it's a long awaited feature.
> There might be some
> From tests/test/cg/tvectorcall1.pp
>
> {$PUSH}
> {$CODEALIGN RECORDMIN=16}
> {$PACKRECORDS C}
> type
> TM128 = record
> case Byte of
> 0: (M128_F32: array[0..3] of Single);
> 1: (M128_F64: array[0..1] of Double);
> end;
> {$POP}
>
> (This declaration mimics how __m128 is defined in Microsoft
Trunk now builds without issues for armv6m, armv7m and armv7em, here's
the patch to add the license and the renames to make the interrupts
cmsis compatible.
http://temp.michael-ring.org/cmsis_plus_license.patch
Michael
Am 20.04.20 um 23:11 schrieb Michael Ring via fpc-devel:
Am 20.04.20 um
From tests/test/cg/tvectorcall1.pp
{$PUSH}
{$CODEALIGN RECORDMIN=16}
{$PACKRECORDS C}
type
TM128 = record
case Byte of
0: (M128_F32: array[0..3] of Single);
1: (M128_F64: array[0..1] of Double);
end;
{$POP}
(This declaration mimics how __m128 is defined in Microsoft Visual
> One thing to be slightly aware of with
> dynamic pointers and alignment. For V: atray
> of Integer etc, make sure you check the
> alignment of V[0], not V. V points to an
> internal structure that is largely opaque,
> while V[0] points to the actual data, which I
> imagine is what you want to
denisgolovan via fpc-devel schrieb am Di.,
21. Apr. 2020, 13:32:
>
>
> > One thing to be slightly aware of with
> > dynamic pointers and alignment. For V: atray
> > of Integer etc, make sure you check the
> > alignment of V[0], not V. V points to an
> > internal structure that is largely opaque,
The value stored at V is the pointer to V[0],
not the zeroth element's data, hence why your
comparison always returns true. In assembly
language, you'd have to effectively do:
MOV RDX, [RSP] { or wherever V's service data
is stored }
VMOVAPS YMM0, [RDX]
Passing RSP (V) into VMOVAPS directly
> I think Gareth meant the address of V instead (Pointer(@V)).
>
> Regards,
> Sven
Hm. I have no idea why anyone would take pointer to pointer :)
BTW, Sven, what's your opinion on dynamic arrays alignment problem?
I don't have any viable solution besides maintaining my own compiler fork so
> In that instance, I think it's because TIntArray is not a record type
> (it's essentially a smart pointer) and so RECORDMIN doesn't apply to
> it. I do agree though that having an 'align' attribute of some kind
> will make life a lot easier since you don't have to play around with
> multiple
One thing to be slightly aware of with
dynamic pointers and alignment. For V: atray
of Integer etc, make sure you check the
alignment of V[0], not V. V points to an
internal structure that is largely opaque,
while V[0] points to the actual data, which I
imagine is what you want to pass into
denisgolovan schrieb am Di., 21. Apr. 2020, 14:58:
> > I think Gareth meant the address of V instead (Pointer(@V)).
> >
> > Regards,
> > Sven
>
> Hm. I have no idea why anyone would take pointer to pointer :)
>
Because they might have forgotten that dynamic arrays behave different from
static
I made a bit of a big post with "Future development plans" where I
mentioned 'aligned allocation', especially since C11 has the feature and
Microsoft have their own non-portable set of functions. Hopefully it
will spawn some discussion.
Sorry to keep going back to the dynamic array issue.
Hi everyone,
I hope this doesn't become a monthly podcast for me or something, but
during my bursts of motivation, inspiration and creativity, I start to
plan and research things. There are a few things I'd like to develop
for FPC, mostly together because there's a lot of interdependency.
I have the following code in a unit (I need to provide a memset function
to be able to link to freertos):
function memset(pxBuffer:pointer; value : byte; count : Tsize):pointer;
cdecl;
begin
FillChar(pxBuffer,count,value);
Result := pxBuffer;
end;
When I look at the assembler code
Am 21.04.20 um 14:58 schrieb denisgolovan via fpc-devel:
I think Gareth meant the address of V instead (Pointer(@V)).
Regards,
Sven
Hm. I have no idea why anyone would take pointer to pointer :)
BTW, Sven, what's your opinion on dynamic arrays alignment problem?
It should be fixed/there
On 21/04/2020 10:57, bla...@blaise.ru wrote:
> I have questions/suggestions WRT Jonas' SVN r42342:
> https://github.com/graemeg/freepascal/commit/40d31e34116efffa239b6dc94373fcfccedfa646
>
>
> 1) Why was `typesym.owner` used instead of `owner`? Beside efficiency,
> this hurts understandability:
just as point for consideration, I'm not sure if data alignment will
improve speed on future processors:
https://lemire.me/blog/2012/05/31/data-alignment-for-speed-myth-or-reality/
Food for thought: imagine if we had single (32 bits floating point) values
dynamic arrays with 1 million values
Hi Florian,
As I mentioned in my future development post,
do you think FPC could benefit from
GetMemAligned and ReallocMemAligned routines?
The internal functions could be used to help
control such custom alignment in dynamic
arrays.
We're still waiting on a good language
feature to better
One issue with the current state of the intrinsics is that they don't
really follow the common style among other languages, and there's no
agreed consensus about what path to take yet. To implement the more
common style would be a lot of work though compared to the current
autogenerated way
Can you run gdb on there? When you break inside memset does the pxBuffer
pointer make sense (not 0x0)? Do the other two variables come in correctly?
Do you call memset or does an api in the OS call it? Perhaps it's a pointer to
a pointer on accident?
If you are required to provide memset are
Am 21.04.20 um 08:10 schrieb Sven Barth via fpc-devel:
Hello together!
I'm happy to announce initial support for the Windows on ARM64 target,
aka aarch64-win64.
Glad to hear :) We should in time implement sets with >256 elements else
the systems_* set will not work anymore ;)
26 matches
Mail list logo
