win31 would be more confusing
W dniu 2020-04-22 o 22:21, Bart via fpc-devel pisze:
"Moved the common interface part of the win33 and win64 System units
to the syswinh.inc include file."
--
GM Systems
ul. K.Marksa 9
58-260 Bielawa
tel. +48 694 178 276
http://www.gmsystems.pl/
Am 22.04.2020 um 22:21 schrieb Bart via fpc-devel:
Hi,
Please don't feel offended, but this typo just made me smile:
(And a smile is what we need in these harsh times)
Revision 44996
"Moved the common interface part of the win33 and win64 System units
to the syswinh.inc include file."
Lol... I
Congrats to the FPC team for being a bit above the rest ;)
--
Alexander Grotewohl
https://dcclost.com
From: fpc-devel on behalf of Bart via
fpc-devel
Sent: Wednesday, April 22, 2020 4:21:03 PM
To: fpc-devel
Cc: Bart
Subject: [fpc-devel] FPC now supports Windo
Hi,
Please don't feel offended, but this typo just made me smile:
(And a smile is what we need in these harsh times)
Revision 44996
"Moved the common interface part of the win33 and win64 System units
to the syswinh.inc include file."
--
Bart
___
fpc-
Am 21.04.2020 um 10:57 schrieb bla...@blaise.ru:
I have questions/suggestions WRT Jonas' SVN r42342:
https://github.com/graemeg/freepascal/commit/40d31e34116efffa239b6dc94373fcfccedfa646
Yay, a life sign! :D
Regards,
Sven
___
fpc-devel maillist -
A global property inside the System unit I don't think would be wise
because anything could set it and it wouldn't be threadsafe (for a
single-thread example, two different units might set it to what they
require, but one may get its value overwritten and have a smaller
alignment than asked - y
On 2020-04-22 15:45, J. Gareth Moreton wrote:
.
.
A global option, like a preprocessor directive or command line option,
feels a bit dangerous and can easily introduce unexpected bugs if it's
left out, so an explicit optional parameter (e.g.
GetMem(AlignedVector, 4096, 64);) would feel like the
I'm not totally certain what the design intentions are with new language
features - back in the 90s, a friend told me Pascal (actually Delphi
2.0) has the simplicity of Visual Basic but the power of Visual C++.
I'm not sure how true that is, but it's what's inspired me. Going by
that, I would
Whether they be new functions or just an optional parameter, I do agree
that they should be compatible with FreeMem rather than requiring their
own function - Microsoft's non-portable _aligned_malloc requires calling
a specialised 'free' function, but the C11 and C++17 standards, despite
having
same.. lol
--
Alexander Grotewohl
https://dcclost.com
From: fpc-devel on behalf of Michael
Ring via fpc-devel
Sent: Wednesday, April 22, 2020 8:21:55 AM
To: fpc-devel@lists.freepascal.org
Cc: Michael Ring
Subject: Re: [fpc-devel] Possible error in generated co
Arg...
I feel completely stupid!
Thank you for the Hint Jonas, using pxBuffer^ did the trick!
Michael
Am 22.04.20 um 11:15 schrieb Jonas Maebe:
On 22/04/2020 00:09, Michael Ring via fpc-devel wrote:
function memset(pxBuffer:pointer; value : byte; count : Tsiz
We don't have to follow other languages exactly. For example, I prefer
"TM128" or "M128" over the C-like "_m128".
Personally, I like the way you've named the intrinsics because it's very
clear which instruction an intrinstic maps to, and which architecture it
belongs to. The operand order ca
On Wed, 22 Apr 2020, Tomas Hajny wrote:
On 2020-04-21 20:47, J. Gareth Moreton wrote:
Hi,
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 alignme
Possibly, but it can become wasteful, especially on systems that might
be strapped for memory.
Generally, you only want a coarser alignment for specialised
applications, such as for certain instruction sets (e.g. AVX) and memory
paging. The mechanics behind the regular GetMem is more than ade
On 2020-04-21 20:47, J. Gareth Moreton wrote:
Hi,
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.
Wouldn't it be bette
On 22/04/2020 00:09, Michael Ring via fpc-devel wrote:
> function memset(pxBuffer:pointer; value : byte; count : Tsize):pointer;
> cdecl;
> begin
> FillChar(pxBuffer,count,value);
> Result := pxBuffer;
> end;
You need pxBuffer^ instead of pxBuffer (you want to fill the block to
which pxBuffer
On Wed, 22 Apr 2020, Bart via fpc-devel wrote:
Hi,
Isn't this kind of a recursive definition?
This modifier allows you to specify the calling conventions for the
Windows platform: the compiler will then select the correct calling
convention depending on the Windows architecture (cdecl on win
Hi,
Isn't this kind of a recursive definition?
This modifier allows you to specify the calling conventions for the
Windows platform: the compiler will then select the correct calling
convention depending on the Windows architecture (cdecl on windows CE
or winapi on all other Windows platforms)
I
The information you see is coming straight out of the debugger (Segger
Ozone),
and perhaps I should have said this in the first post,
the pointer that is fed in the Fillchar procedure is complete nonsense,
it points into the stack area which means im my case that fillchar
overwrites the stack
On 21/04/2020 22:56, Jonas Maebe wrote:
> What happens in that case, is
>
> tclassalias ttypesym contains a reference to toriginalclass' tobjectdef,
> and that tobjectdef's typesym be to toriginalclass' typesym. And in the
> unit symtable holding that typesym, we will find the vmtdef we need
> (be
20 matches
Mail list logo