Re: [fpc-devel] FPC now supports Windows 33-bit

2020-04-22 Thread Michał Gawrycki via fpc-devel
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/

Re: [fpc-devel] FPC now supports Windows 33-bit

2020-04-22 Thread Sven Barth via fpc-devel
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

Re: [fpc-devel] FPC now supports Windows 33-bit

2020-04-22 Thread Alexander Grotewohl
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

[fpc-devel] FPC now supports Windows 33-bit

2020-04-22 Thread 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." -- Bart ___ fpc-

Re: [fpc-devel] Refactoring tobjectdef.vmt_def

2020-04-22 Thread Sven Barth via fpc-devel
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 -

Re: [fpc-devel] State of SSE/AVX intrinsics

2020-04-22 Thread J. Gareth Moreton
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

Re: [fpc-devel] State of SSE/AVX intrinsics

2020-04-22 Thread Tomas Hajny
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

Re: [fpc-devel] State of SSE/AVX intrinsics

2020-04-22 Thread J. Gareth Moreton
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

Re: [fpc-devel] State of SSE/AVX intrinsics

2020-04-22 Thread J. Gareth Moreton
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

Re: [fpc-devel] Possible error in generated code for arm?

2020-04-22 Thread Alexander Grotewohl
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

Re: [fpc-devel] Possible error in generated code for arm?

2020-04-22 Thread Michael Ring via fpc-devel
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

Re: [fpc-devel] Future development plans

2020-04-22 Thread J. Gareth Moreton
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

Re: [fpc-devel] State of SSE/AVX intrinsics

2020-04-22 Thread Michael Van Canneyt
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

Re: [fpc-devel] State of SSE/AVX intrinsics

2020-04-22 Thread J. Gareth Moreton
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

Re: [fpc-devel] State of SSE/AVX intrinsics

2020-04-22 Thread Tomas Hajny
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

Re: [fpc-devel] Possible error in generated code for arm?

2020-04-22 Thread Jonas Maebe
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

Re: [fpc-devel] Winapi modifier: docs r1689

2020-04-22 Thread Michael Van Canneyt
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

[fpc-devel] Winapi modifier: docs r1689

2020-04-22 Thread Bart via fpc-devel
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

Re: [fpc-devel] Possible error in generated code for arm?

2020-04-22 Thread Michael Ring via fpc-devel
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

Re: [fpc-devel] Refactoring tobjectdef.vmt_def

2020-04-22 Thread Jonas Maebe
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