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 yo
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 genera
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 each:
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: i
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
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 sho
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
A
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. Th
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.
*
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 ;)
__
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 on
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 w
> 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
far
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,
> 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 p
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 V
> 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 pr
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
sep
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 preproces
> 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 Vi
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 C+
> 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 portab
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
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 al
24 matches
Mail list logo
