Re: [fpc-devel] CaptureBacktrace

[Adriaan van Os via fpc-devel]

Also, there is no symbol information (on MacOS). Is this because of the 
separate .dSYM file ?


But if I call backtrace_symbols in stead of DUmp_Stack, I do get symbol names 


Regards,

Adriaan van Os


main program
0   Test0x00011560 
P$MBTESTBACKTRACE2_$$_WRITEBACKTRACE + 144
1   Test0x0001177d PASCALMAIN + 61
2   Test0x00023515 FPC_SYSTEMMAIN + 69
3   Test0x000114c5 start + 53


theDepth = 6

0   Test0x00011560 
P$MBTESTBACKTRACE2_$$_WRITEBACKTRACE + 144
1   Test0x000116ee 
P$MBTESTBACKTRACE2_$$_STACKME$SMALLINT + 110
2   Test0x000117ac PASCALMAIN + 108
3   Test0x00023515 FPC_SYSTEMMAIN + 69
4   Test0x000114c5 start + 53

theDepth = 5

0   Test0x00011560 
P$MBTESTBACKTRACE2_$$_WRITEBACKTRACE + 144
1   Test0x000116ee 
P$MBTESTBACKTRACE2_$$_STACKME$SMALLINT + 110
2   Test0x00011733 
P$MBTESTBACKTRACE2_$$_STACKME$SMALLINT + 179
3   Test0x000117ac PASCALMAIN + 108
4   Test0x00023515 FPC_SYSTEMMAIN + 69
5   Test0x000114c5 start + 53

theDepth = 4

0   Test0x00011560 
P$MBTESTBACKTRACE2_$$_WRITEBACKTRACE + 144
1   Test0x000116ee 
P$MBTESTBACKTRACE2_$$_STACKME$SMALLINT + 110
2   Test0x00011733 
P$MBTESTBACKTRACE2_$$_STACKME$SMALLINT + 179
3   Test0x00011733 
P$MBTESTBACKTRACE2_$$_STACKME$SMALLINT + 179
4   Test0x000117ac PASCALMAIN + 108
5   Test0x00023515 FPC_SYSTEMMAIN + 69
6   Test0x000114c5 start + 53

theDepth = 3

0   Test0x00011560 
P$MBTESTBACKTRACE2_$$_WRITEBACKTRACE + 144
1   Test0x000116ee 
P$MBTESTBACKTRACE2_$$_STACKME$SMALLINT + 110
2   Test0x00011733 
P$MBTESTBACKTRACE2_$$_STACKME$SMALLINT + 179
3   Test0x00011733 
P$MBTESTBACKTRACE2_$$_STACKME$SMALLINT + 179
4   Test0x00011733 
P$MBTESTBACKTRACE2_$$_STACKME$SMALLINT + 179
5   Test0x000117ac PASCALMAIN + 108
6   Test0x00023515 FPC_SYSTEMMAIN + 69
7   Test0x000114c5 start + 53

theDepth = 2

0   Test0x00011560 
P$MBTESTBACKTRACE2_$$_WRITEBACKTRACE + 144
1   Test0x000116ee 
P$MBTESTBACKTRACE2_$$_STACKME$SMALLINT + 110
2   Test0x00011733 
P$MBTESTBACKTRACE2_$$_STACKME$SMALLINT + 179
3   Test0x00011733 
P$MBTESTBACKTRACE2_$$_STACKME$SMALLINT + 179
4   Test0x00011733 
P$MBTESTBACKTRACE2_$$_STACKME$SMALLINT + 179
5   Test0x00011733 
P$MBTESTBACKTRACE2_$$_STACKME$SMALLINT + 179
6   Test0x000117ac PASCALMAIN + 108
7   Test0x00023515 FPC_SYSTEMMAIN + 69
8   Test0x000114c5 start + 53

theDepth = 1

0   Test0x00011560 
P$MBTESTBACKTRACE2_$$_WRITEBACKTRACE + 144
1   Test0x000116ee 
P$MBTESTBACKTRACE2_$$_STACKME$SMALLINT + 110
2   Test0x00011733 
P$MBTESTBACKTRACE2_$$_STACKME$SMALLINT + 179
3   Test0x00011733 
P$MBTESTBACKTRACE2_$$_STACKME$SMALLINT + 179
4   Test0x00011733 
P$MBTESTBACKTRACE2_$$_STACKME$SMALLINT + 179
5   Test0x00011733 
P$MBTESTBACKTRACE2_$$_STACKME$SMALLINT + 179
6   Test0x00011733 
P$MBTESTBACKTRACE2_$$_STACKME$SMALLINT + 179
7   Test0x000117ac PASCALMAIN + 108
8   Test0x00023515 FPC_SYSTEMMAIN + 69
9   Test0x000114c5 start + 53
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] CaptureBacktrace

[Adriaan van Os via fpc-devel]

Karoly Balogh via fpc-devel wrote:

Hi,

On Fri, 4 Oct 2024, Adriaan van Os via fpc-devel wrote:


My question now is if there is a reason why FPC doesn't call backtrace (see
man backtrace) on Linux and Unix (including MacOS) platforms ?


It seems this is a relatively recent addition to libc, which means, after
2000. :)


program TestBacktrace;

procedure StackMe
( theDepth : integer);
begin
  writeln
( 'theDepth = ', theDepth);
  Dump_Stack
( stdout, 0);
  writeln;
  if theDepth > 1
then StackMe
   ( theDepth - 1)
end;

begin
  writeln
( 'main program');
  writeln;
  StackMe
( 6)
end.


prints


main program

theDepth = 6

theDepth = 5

theDepth = 4
  $00011680

theDepth = 3
  $00011680
  $000116C5

theDepth = 2
  $00011680
  $000116C5
  $000116C5

theDepth = 1
  $00011680
  $000116C5
  $000116C5
  $000116C5


So, how should I call Dump_Stack ?

Also, there is no symbol information (on MacOS). Is this because of the 
separate .dSYM file ?

Regards,

Adriaan van Os
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] CaptureBacktrace

[Adriaan van Os via fpc-devel]

It looks like the FPC RTL function CaptureBacktrace uses a system call if 
FPC_SYSTEM_HAS_CAPTUREBACKTRACE is true and a custom routine if it is false. The define 
FPC_SYSTEM_HAS_CAPTUREBACKTRACE seems to be true for Windows with Structured Exception Handling 
(FPC_USE_WIN64_SEH) where RtlCaptureStackBackTrace is called instead of the FPC built-in routine.


My question now is if there is a reason why FPC doesn't call backtrace (see man backtrace) on Linux 
and Unix (including MacOS) platforms ?


Another question is whether and how NSException.callStackReturnAddresses and 
NSException.callStackSymbols can be used here (on MacOS) ?


Regards,

Adriaan van Os



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Freeze of fixes for 3.2.4 by 9th June

[Adriaan van Os via fpc-devel]

Florian Klämpfl via fpc-devel wrote:

To get finally forward with the 3.2.4 release, fixes will be frozen by 9th 
June, so if there are some last second cherry picks needed, now it’s time to 
speak up :)


0038492: $setc regression;

Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Compiler for MacOS

[Adriaan van Os via fpc-devel]

Jonas Maebe via fpc-devel wrote:

On 07/02/2024 15:35, Adriaan van Os via fpc-devel wrote:
Unfortunately, there are some issues that make FPC at the moment 
unuseable on MacOS


... for people who use macpas mode.


Indeed. But that raises the question why SetExceptionMask was added to macpas.pp, as the problem is 
not compiler-mode specific but target-specific <http://bugs.freepascal.org/view.php?id=11516 > .


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Compiler for MacOS

[Adriaan van Os via fpc-devel]

Unfortunately, there are some issues that make FPC at the moment unuseable on 
MacOS

0038492: $setc regression; there is no released compiler download (I know of) 
that has this fixed
[number ? ] darwin-aarch64 crash with cthreads, also reported on the mailing 
list

I request either a fix of the darwin-aarch64 crash or some feedback or write access to the compiler 
sources (under my new email address adri...@adriaan.biz) to fix the issue myself. The only other 
option I see is to fork the compiler and to make it available for download on my website.


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Wrong debug info when using clang backend

[Adriaan van Os via fpc-devel]

Jonas Maebe via fpc-devel wrote:

On 14/12/2023 08:41, Adriaan van Os via fpc-devel wrote:

Jonas Maebe via fpc-devel wrote:

I'd rather not introduce directives that are specific to clang, and 
especially none only apply to the next loop. We don't have a single 
directive yet that works like this.


The latter is a good point and that's why I would suggest to make 
their Pascal equivalents valid, not for the next for-loop, but 
until-otherwise. Then, a loop can be explicitely targeted with {$push 
...} and {$pop}.


I don't think that makes much sense. Most of the time, the loops in a 
single source file will be quite different and need different explicit 
unroll instructions, if any. There is a reason why they only apply to 
the next loop in clang.


It's just that directives don't work very well in that context, and 
hence my initial suggestion to use attributes instead. I'm by no means 
married to that proposal, but I don't think directives are a good 
approach either.


GNU Pascal has attributes <https://www.gnu-pascal.de/gpc/attribute.html>. They 
are fine for me.

Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Wrong debug info when using clang backend

[Adriaan van Os via fpc-devel]

Jonas Maebe via fpc-devel wrote:

I'd rather not introduce directives that are specific to clang, and 
especially none only apply to the next loop. We don't have a single 
directive yet that works like this.


The latter is a good point and that's why I would suggest to make their Pascal equivalents valid, 
not for the next for-loop, but until-otherwise. Then, a loop can be explicitely targeted with 
{$push ...} and {$pop}.


Regards,

Adriaan van Os
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Wrong debug info when using clang backend

[Adriaan van Os via fpc-devel]

Michael Van Canneyt via fpc-devel wrote:


Maybe a single {$PRAGMA XYZ} directive can be introduced to control this
kind of stuff, with a fixed list of XYZ. Backends can intepret the XYZ 
pragmas as they see fit.


Yes, a {$pragma} directive is fine for me. It seems absurd to ignore code improvement capabilities 
that we get for free with the llvm back-end.


Regards,

Adriaan van Os

{$pragma vectorize ON}
{$pragma vectorize OFF}
{$pragma vectorize WIDTH=n}
{$pragma vectorize TYPE=FIXED}
{$pragma vectorize TYPE=SCALABLE}
{$pragma vectorize PREDICATE=ON}
{$pragma vectorize PREDICATE=OFF}

For a description, see 
<https://llvm.org/docs/Vectorizers.html#command-line-flags>. And

{$pragma unroll ON}
{$pragma unroll OFF}
{$pragma unroll FULL}
{$pragma unroll COUNT=n}

For a description, see 
<https://llvm.org/docs/Vectorizers.html#command-line-flags>. And
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Wrong debug info when using clang backend

[Adriaan van Os via fpc-devel]

Jonas Maebe via fpc-devel wrote:

On 09/12/2023 10:07, Adriaan van Os via fpc-devel wrote:

Another question. Is there a way to put pragmas in fpc source code to 
be passed to CLang, eg. those mentioned here 
<https://llvm.org/docs/Vectorizers.html> ? That would gain a lot, at 
little cost.


No. However, FPC command line parameters (e.g. -O, -Cp) and 
directives/modifiers (e.g. inline, const, constref, ...) get translated 
into LLVM directives wherever possible.


So if/when we would get FPC equivalents of such directives, I could 
translate those to LLVM IR as well.


Then I suggest the following (and I can prepare a patch to the code and docs if 
it were to be accepted)

$vectorize ON}
{$vectorize OFF}
{$vectorize WIDTH=VALUE}
{$vectorize TYPE=FIXED}
{$vectorize TYPE=SCALABLE}
{$vectorize PREDICATE=ON}
{$vectorize PREDICATE=OFF}

For a description, see 
<https://llvm.org/docs/Vectorizers.html#command-line-flags>. And

{$unroll ON}
{$unroll OFF}
{$unroll FULL}
{$unroll COUNT=VALUE}

For a description, see 
<https://clang.llvm.org/docs/LanguageExtensions.html#extensions-for-loop-hint-optimizations>.


LLVM equivalents of these compiler switches will be passed (by Jonas) to Clang 
as IR methadata.

Also, I suggest

-Cl   Pass xxx to Clang as pragma on the command-line.

Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Wrong debug info when using clang backend

[Adriaan van Os via fpc-devel]

Jonas,

It's indeed easier, and it also supports some preprocessing that llc 
doesn't (I don't remember what exactly llc didn't support, perhaps 
comments). It's also faster since you call one tool rather than 2 or 3.


Another question. Is there a way to put pragmas in fpc source code to be passed to CLang, eg. those 
mentioned here <https://llvm.org/docs/Vectorizers.html> ? That would gain a lot, at little cost.


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Wrong debug info when using clang backend

[Adriaan van Os via fpc-devel]

Jonas Maebe via fpc-devel wrote:
Because of this reason, FPC only uses llvm.dbg.addr. But clang still 
uses llvm.dbg.declare, and when I change FPC to use that one, the 
debug info for the variables in your test program is correct. So I'll 
change FPC to also use llvm.dbg.declare.


Done.


Just out of curiosity: Clang is by fpc used as a driver program, as it is asier to call it than 
tools like llc, opt and llvm-linker ?


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Interesting short article about optimisation

[Adriaan van Os via fpc-devel]

J. Gareth Moreton via fpc-devel wrote:
I just stumbled across this article about micro-architecture-specific 
optimisations in ARM: 
https://www.phoronix.com/news/ARM64-Linux-No-Uarch-Opts


They briefly mention x86_64, and I agree it's good to avoid 
micro-architecture-specific optimisations and now it makes me wonder 
where the line is drawn, like the recent introduction of the optimizer 
hint regarding LEA instructions being slow on some middle-aged CPUs.


I agree that kind of optimization shouldn't be in a kernel. Whether it should be in a compiler is 
another question.


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Bug #38492

[Adriaan van Os via fpc-devel]

Unfortunately, bug  #38492 makes fpc-3.2.0 and 3.2.2 (for me) unusable. On the other hand, the 
fpc-3.0.4 installer refuses to install on recent versions of MacOS. So, what to do ?


1. help with a fpc-3.2.4 release for MacOS (intel and arm64) ?
2. hack the fpc-3.0.4 installer ? ?
3. put an unofficial fpc-3.2.x release on my website ?

Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Bug #38492

[Adriaan van Os via fpc-devel]

Martin Frb via fpc-devel wrote:

On 10/11/2023 10:49, Adriaan van Os via fpc-devel wrote:
Sorry, but I am looking for a diff for fpc bug #38492. Mantis says 
"'Fixed in Revision: 38492" which looks like a mistake, as 38492 is 
the bug number. Also gitlab reports fix #11ef1d17 which is instead a 
register allocation fix.


Is the fix already in fpc-3.2 fixes ?


searching the log messages:


ff3f812d979e57b49463224a814c64e027670d2d

*   * fix conversion of true/false macro definitions to boolean values
(mantis #38492)
   o since the macro lookups are recursive, "mac" will usually be nil
 afterwards (unless we found an undefined macro)

git-svn-id: trunk@49160 -


And (if this is the correct commit) you can check if this file is in 
fixes (newly added)


\tests\webtbs\tw38492.pp


Thanks.

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Bug #38492

[Adriaan van Os via fpc-devel]

Sorry, but I am looking for a diff for fpc bug #38492. Mantis says "'Fixed in Revision: 38492" 
which looks like a mistake, as 38492 is the bug number. Also gitlab reports fix #11ef1d17 which is 
instead a register allocation fix.


Is the fix already in fpc-3.2 fixes ?

Regards,

Adriaan van Os
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] linkframework ImageKit

[Adriaan van Os via fpc-devel]

ImageKit.pas in the MacOS Cocoa headers has

{$linkframework ImageKit}

but this produces an linking error as ImageKit is a subframework of 
Quartz.framework.

Not sure where to report this.

Regards,

Adriaan van Os


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Unicode RTL

[Adriaan van Os via fpc-devel]

Michael Van Canneyt via fpc-devel wrote:


Hello,

I have just completed phase one of the "Unicode RTL" effort.


I object to the name "Unicode" RTL. Where people talk about what they call "Unicode" they usually 
mean UCS-16 or UTF-16 or UTF-16-mishandled-as-UCS16.


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Curious about the effect of all the new optimizations....

[Adriaan van Os via fpc-devel]

Bart via fpc-devel wrote:

On Wed, Mar 1, 2023 at 11:33 AM Martin Frb via fpc-devel
 wrote:


So for a while now fpc 3.3.1 receives new optimizations => which is
great / big fan of it.

And hence I thought, lets see how much of an impact they have. And in my
test, they had none :(


Optimizations beyond O2 (or even O1) most of the times do not make a
difference for the average user.


I disagree here. It depends on what you are doing.


There is much randomness in the performance of an application caused
by things you cannot control, which have more influence on the
performance of the application
I watched a video about this not so long ago (it was about
optimization levels in gcc), which explained all this, but I'm unable
to find that again and unanble to reproduce what was being said there.


That may have been "-Performance Matters- by Emery Berger". By I find it a 
nonsense video.

Regards,

Adriaan van Os
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC 3.3.1 crash when getting interface from object

[Adriaan van Os via fpc-devel]

Martin Frb via fpc-devel wrote:
I don't currently have many details. (The code in question has been 
working on older 3.3.1, and still works on 3.2.3 and before)


I included various details, but in the end it may be a peephole issues 
in "GetInterfaceByStr"

==> So probably skip ahead to the asm code below.


I am having weird problems with GetInterface too, that seem to depend and the surrounding code. 
That is, with trivial changes of the code, GetInterface works or crashes.


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Question on constref

[Adriaan van Os via fpc-devel]

Sven Barth wrote:
Adriaan van Os via fpc-devel <mailto:fpc-devel@lists.freepascal.org>> schrieb am Do., 2. Feb. 2023, 
02:47:


Sven Barth via fpc-devel wrote:

 > There is no full documentation for that parameter modifier (someone
 > might want to file a bug report for that), but the documentation for
 > “const” (
 >

https://www.freepascal.org/docs-html/current/ref/refsu67.html#x183-20700014.4.4

 > ) contains this:
 >
 > === doc begin ===
 >
 > Contrary to Delphi, no assumptions should be made about how const
 > parameters are passed to the underlying routine. In particular, the
 > assumption that parameters with large size are passed by
reference is
 > not correct. For this the constref parameter type should be used,
which
 > is available as of version 2.5.1 of the compiler.
 >
 > === doc end ===

On debate, see FPC issue 17442.


There is no debate planned for this in the near future. So even if this 
might change some time in the future it does not *now* and very likely 
also not for 3.4.0. Not to mention that things wouldn't change for most 
platforms anyway, because they only have the platform ABI available and 
that *must not* change for compatibility with C code. 


"Will not change" and "ABI" are non arguments. They do not address the 
questions put forward here:

- under what circumstances (and in what compiler mode) does FPC pass large (say 1 MB or 1 GB) 
"const" parameters by value (which is extremely inefficient) ?

- for what reasons ?

As long as these questions are not addressed and cleared and documented "const" parameters are not 
a useable in actual code.


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Question on constref

[Adriaan van Os via fpc-devel]

Sven Barth via fpc-devel wrote:

I doubt that records larger than say 4 register widths are ever passed 
by-value. But I definitely can't exclude it, cause I don't know every 
ABI of every platform by heart. So if you want details there then study 
the ABIs of the platforms you use.


I doubt that any ABI would say something about Pascal "const" rather than C "const". So, that 
argument doesn't hold. The only reason I can possibly think of (for "const" to pass large 
parameters by value and thus violating the rule that "const" chooses the most efficient method) is 
compatibility with Delphi in delphi compiler mode. If that's true, which I don't know, it should be 
documented. Otherwise, "const" will continue to puzzle programmers - and in a year we will have the 
same discussion again.


Regards,

Adriaan van Os
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Question on constref

[Adriaan van Os via fpc-devel]

Hairy Pixels via fpc-devel wrote:



On Feb 2, 2023, at 4:38 AM, Sven Barth  wrote:

Which types are passed by-value or by-reference when using const is determined 
by the size of the record and the types of the fields based on whatever the 
corresponding ABI defines (e.g. the x86_64 Sys V ABI is rather explicit about 
some field combinations). The compiler will however not switch between passing 
a specific type once by-value and another time by-reference.


So if the compiler is making the choice using const which is more efficient 
then we should be using const always I would think? What problem does constref 
solve then?

You go on to show this:

=== doc begin ===

Contrary to Delphi, no assumptions should be made about how const parameters are passed to the underlying routine. In particular, the assumption that parameters with large size are passed by reference is not correct. For this the constref parameter type should be used, which is available as of version 2.5.1 of the compiler. 


=== doc end ===

Is there anytime a large record should be passed by value if the function is not 
altering the it? This is why I started using constref, i.e. "In particular, the 
assumption that parameters with large size are passed by reference is not correct” 
which makes me think if I have a record of say 64k if I don’t use constref it could 
be passed by value to a function which is called in a tight loop.


Yes, to me this notion in the docs lacks all logic. How could copying large parameters ever be 
efficient ? It invites developers to use constref for a purpose it wasn't meant for. For a debate, 
see FPC Issue 17442. Jonas Maebe writes there


"We are adding support for a "constref" parameter to the compiler that 
will
allow you to specify that a parameter is const and must be passed by
reference, but I would strongly suggest to use it only for compatibility
with external APIs (that e.g. use "const struct *" parameters) and very
sparingly for optimization, because in many cases you may well slow down
your code rather than speeding it up."

but also

"Maybe another developer believes that for non-cdecl, we could modify 
the
behaviour of const so that very large records are passed by reference,
which is why I leave this bug open."

If my memory is correct, that this was changed for macpas mode (passing very large records by 
reference) but can't find it back in the bug database.


Regards,

Adraan van Os



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Question on constref

[Adriaan van Os via fpc-devel]

Sven Barth via fpc-devel wrote:

There is no full documentation for that parameter modifier (someone 
might want to file a bug report for that), but the documentation for 
“const” ( 
https://www.freepascal.org/docs-html/current/ref/refsu67.html#x183-20700014.4.4 
) contains this:


=== doc begin ===

Contrary to Delphi, no assumptions should be made about how const 
parameters are passed to the underlying routine. In particular, the 
assumption that parameters with large size are passed by reference is 
not correct. For this the constref parameter type should be used, which 
is available as of version 2.5.1 of the compiler.


=== doc end ===


On debate, see FPC issue 17442.

Regards,

Adriaan van Os
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Question on constref

[Adriaan van Os via fpc-devel]

Hairy Pixels via fpc-devel wrote:



On Feb 1, 2023, at 5:56 PM, Adriaan van Os via fpc-devel 
 wrote:

"A const parameter is be passed by reference or (for small-sized parameters) by 
value, whatever is most efficient. A constref parameter is guaranteed to be passed by 
reference in all cases. The latter is therefore typically used for interfacing with 
external code or when writing assembler routines."


I’ve been confused by constref versus const. I use constref when passing large 
records as parameters so I know it will not make needless copies but why 
doesn’t const function this way too? If the parameter is constant why would it 
ever make sense for the compiler to copy the entire record when it knows the 
function can’t change it?


Because, if e.g. the byte-size of a parameter is such that it fits into a CPU register, then 
passing the parameter itself is more efficient than passing a reference to it. For large byte-size 
parameters, const and constref function the same. The difference is with small byte-size parameters.


Regards,

Adriaan van Os
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Question on constref

[Adriaan van Os via fpc-devel]

Bart via fpc-devel wrote:


"Note that in general, it should only be used for interfacing with
external code or when writing assembler routines."


That is wrong. It should read

"A const parameter is be passed by reference or (for small-sized parameters) by value, whatever is 
most efficient. A constref parameter is guaranteed to be passed by reference in all cases. The 
latter is therefore typically used for interfacing with external code or when writing assembler 
routines."


In your case, constref is the right choice, although const would be fine also (as your 
datastructure is larger than a small number of bytes).


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Unicode RTL for FPC

[Adriaan van Os via fpc-devel]

Michael Van Canneyt via fpc-devel wrote:





Seems my warning to prevent heart attacks was on its place but maybe not
entirely effective :-)

Relax, no-one will force you to use UTF16.

But there are people that do not have the luxury of choice, and we should
be kind to them too.


OK. It reminds me of the Turbo assembler, which had a mode to be compatible with the bugs in the 
Microsoft assembler 😃 😃 .


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Unicode RTL for FPC

[Adriaan van Os via fpc-devel]

Michael Van Canneyt via fpc-devel wrote:


- String = UnicodeString, Char=WideChar


UnicodeString ? ? I don't know what that is supposed to be. We have UCS-2, UCS-4, UTF-16 and UTF-8 
Some marketing people, not understanding anything about computers, talk about "Unicode" to mean 
"UTF-16-treated-as-UCS-2".


For me, UTF-16 is the dumbest thing ever invented in computing. So I shiver at the thought of a 
"Unicode" RTL.


We really should use UTF-8, as most open source projects do.

Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Happy New Year!

[Adriaan van Os via fpc-devel]

J. Gareth Moreton via fpc-devel wrote:

Happy New Year everybody!  Free Pascal lives on!


I wish you Happy New Optimizations 😃

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Minor doc error about "const param"

[Adriaan van Os via fpc-devel]

Michael Van Canneyt via fpc-devel wrote:
I will probably have to rephrase the documentation to 'The compiler will 
not allow you to modify the parameter value by assigning something 
directly to it."


Neither would the compiler allow (I hope) the const parameter to be passed as a 
var parameter.

Regards,

Adriaan van Os


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Finally fixed that MOVZX/SX optimisation!

[Adriaan van Os]

J. Gareth Moreton wrote:

Long story short, the patch /finally/ works and a full run of the 
regression suite on i386-win32 and x86_64-win64, including the two new 
tests, show no new failures.


Great work ! Can you give an overview of vector-code in FPC, both automatic compiler optimizations 
and explicit user coding ?


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] vm_kernel_page_size

[Adriaan van Os]

   Undefined symbols for architecture x86_64:
  "_vm_kernel_page_size", referenced from:
  _SYSTEM_$$_DARWIN_INIT_PAGE_SIZE in system.o


Reported as <https://bugs.freepascal.org/view.php?id=36653>
Regards,

Adriaan van Os
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] vm_kernel_page_size

[Adriaan van Os]

rtl/darwin/sysmach.inc has

	vm_kernel_page_size: vm_size_t; cvar; weakexternal; //__OSX_AVAILABLE_STARTING(__MAC_10_9, 
__IPHONE_7_0)


so vm_kernel_page_siz is marked weakexternal. I still get an error

Undefined symbols for architecture x86_64:
  "_vm_kernel_page_size", referenced from:
  _SYSTEM_$$_DARWIN_INIT_PAGE_SIZE in system.o

when building a cross-compiler for Android on OSX 10.8.5, using fpc-3.0.4 and 
the command

	make clean crossall crossinstall OS_TARGET=android CPU_TARGET=arm INSTALL_PREFIX=/usr/local 
BINUTILSPREFIX=arm-linux-androideabi-


The build error disappears when I comment out the reference to vm_kernel_page_size in 
darwin_init_page_size


 procedure darwin_init_page_size;
begin
{
  if (@vm_kernel_page_size<>nil) and (vm_kernel_page_size>vm_page_size) then
darwin_page_size:=vm_kernel_page_size
  else
}
darwin_page_size:=vm_page_size;
end;

Is this a bug ? Caused by @vm_kernel_page_size ?

Regards,

Adriaan van Os
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Android 64-bit

[Adriaan van Os]

Yuriy Sydorov wrote:


Support for aarch64-android and x86_64-android targets are present in FPC 3.2 
and trunk. The support is stable, on par with 32-bit android targets.


OK, thanks for the various replies.

Regards,

Adriaan van Os
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Android 64-bit

[Adriaan van Os]

Florian Klämpfl wrote:

Am 25.01.20 um 14:40 schrieb Sven Barth via fpc-devel:

mips64 are supported with 3.2 and newer.


FPC has no mips64 support yet :(


As far as I know, 32-bit and 64-bit MPIS support was removed in the Android Native Deveopment Kit 
version r17. So, that doesn't seem to be an issue for Android.


I meant ARM and x86 64 native executables for Android. Some time ago, I can't remember exactly 
when, compiling for 64-bit Android wasn't supported yet (or at least not for ARM) and my 
understanding then was that this was under development.


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Android 64-bit

[Adriaan van Os]

Any news on the 64-bit compiler for Android ? What is the current status ?

Regards,

Adriaan van Os
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] LLVM code generator

[Adriaan van Os]

Jonas Maebe wrote:

On 2018-12-02 11:26, Jonas Maebe wrote:

The LLVM version of the code generator has been significantly improved 
in the mean time:


Good work !

Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

[Adriaan van Os]

Simon Kissel wrote:

Hi Adriaan,

In case you aren't just trolling and the subject really is of
interest to you, I would recommend reading the discussion
thread in full. That works much better than treating this
like a write-only system.


In case you are just trolling, I recommend reading a book on programming, learning to write better 
code.


Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

[Adriaan van Os]

Simon Kissel wrote:


This isn't about FPC's code not scaling with N cores, it does.
It is about it being slow as soon as threads are used *at all*,


N cores being near N times faster than "not using threads at all".


due to TLS stuff and exception handling. It's slow in a linear
fashion, so to say...


You didn't answer any of my questions. The goal is to get the code faster, isn't it. Or are you 
writing an academic thesis on compilers ?


Regards,

Adriaan van Os
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

[Adriaan van Os]

Simon Kissel wrote:


We know about a couple of bottlenecks (fpc_pushexceptaddr /
RelocateThreadVar etc) which explain FPC's terrible multi-threading
performance, but in general, FPC's code generator really is quite
a mess, which we learned the hard way a couple of years when we
did optimization work on the ARM target.


I find the phrase. "FPC's terrible multi-threading performance" unjust. When I do multi-threading 
with FPC, I get a near N speed improvement (on i386 and x86_64) where N is the number of cores, 
including hyper-threaded cores 


What about taking another way, having a precise look at the source code ? Did you profile it ? What 
sort of work does the code do ? How are the threads synchronized ? What data structures are used ?


I don't take "the compiler is so bad" without an answer to these questions.

Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] targetandroid

[Adriaan van Os]

It's this bug
<http://bug-binutils.gnu.narkive.com/Cd0LBSs7/bug-binutils-19311-new-arm-linux-as-build-on-mac-os-x-with-xcode7-fails-to-assemble-code-from>


There is an optimization bug in the LLVM C compiler that ships with Xcode 7. This "major leap in 
technology" as Apple would call it, produces a faulty assembler for Android on systems that have 
that C compiler installed. There is a work-around in the bug report 
<https://sourceware.org/bugzilla/show_bug.cgi?id=19311> that solves the issue. The fpc ppcrossarm 
compiler for Android builds now, even on systems with Xcode 7.


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] targetandroid

[Adriaan van Os]

It's this bug
<http://bug-binutils.gnu.narkive.com/Cd0LBSs7/bug-binutils-19311-new-arm-linux-as-build-on-mac-os-x-with-xcode7-fails-to-assemble-code-from>

Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] targetandroid

[Adriaan van Os]

Jonas Maebe wrote:

On 17/06/18 21:47, Adriaan van Os wrote:

But why would arm-linux-androideabi-as behave differently on OS X 
10.12.6 with Xcode 8.3.3 than on OS X 10.10 ? ? Or could it be that 
the assembly files produced by ppcrossarm are different ?


If you add CROSSOPT="-a", the generated assembler files won't be deleted 
and you can compare them.


Nope, the assembler files are the same. So, the bug is in not in fpc but in the assembler or in 
configuring the assembler. WIll investigate that.


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] targetandroid

[Adriaan van Os]

Jonas Maebe wrote:

On 17/06/18 18:00, Adriaan van Os wrote:

What I suspect is that, when building the rtl for android, fpcrossarm 
calls the installed clang assembler rather than the (separately built) 
arm-linux-androideabi-as.


That would surprise me. With -vx, you can see which external tools the 
compiler invokes and with which command lines.


Indeed

/Applications/Xcode.app/Contents/Developer/usr/bin/make -C android all
/bin/mkdir -p /Users/dev1/fpc-android/fpc-3.0.4/rtl/units/arm-android
arm-linux-androideabi-as  -o 
/Users/dev1/fpc-android/fpc-3.0.4/rtl/units/arm-android/prt0.o arm/prt0.as
arm-linux-androideabi-as  -o /Users/dev1/fpc-android/fpc-3.0.4/rtl/units/arm-android/dllprt0.o 
arm/dllprt0.as
/Users/dev1/fpc-android/fpc-3.0.4/compiler/ppcrossarm -Ur -Tandroid -Parm -XParm-linux-androideabi- 
-Xr -Ur -Xs -O2 -n -Fi../inc -Fi../arm -Fi../unix -Fiarm -Fi../linux -Fi../linux/arm -FE. 
-FU/Users/dev1/fpc-android/fpc-3.0.4/rtl/units/arm-android -vx -darm -dRELEASE -Us -Sg 
../linux/system.pp
Executing "/usr/local/bin/arm-linux-androideabi-as" with command line "-mfpu=softvfp -o 
/Users/dev1/fpc-android/fpc-3.0.4/rtl/units/arm-android/system.o 
/Users/dev1/fpc-android/fpc-3.0.4/rtl/units/arm-android/system.s"

/Users/dev1/fpc-android/fpc-3.0.4/rtl/units/arm-android/system.s: Assembler 
messages:
/Users/dev1/fpc-android/fpc-3.0.4/rtl/units/arm-android/system.s:84: Error: invalid constant (7f) 
after fixup
/Users/dev1/fpc-android/fpc-3.0.4/rtl/units/arm-android/system.s:99: Error: invalid constant (7f) 
after fixup
/Users/dev1/fpc-android/fpc-3.0.4/rtl/units/arm-android/system.s:114: Error: invalid constant (ff) 
after fixup


But why would arm-linux-androideabi-as behave differently on OS X 10.12.6 with Xcode 8.3.3 than on 
OS X 10.10 ? ? Or could it be that the assembly files produced by ppcrossarm are different ?


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] targetandroid

[Adriaan van Os]

Another issue is the following:

/Users/dev1/fpc-android/fpc-3.0.4/compiler/ppcrossarm -Ur -Tandroid -Parm -XParm-linux-androideabi- 
-Xr -Ur -Xs -O2 -n -Fi../inc -Fi../arm -Fi../unix -Fiarm -Fi../linux -Fi../linux/arm -FE. 
-FU/Users/dev1/fpc-android/fpc-3.0.4/rtl/units/arm-android -darm -dRELEASE -Us -Sg ../linux/system.pp

/Users/dev1/fpc-android/fpc-3.0.4/rtl/units/arm-android/system.s: Assembler 
messages:
/Users/dev1/fpc-android/fpc-3.0.4/rtl/units/arm-android/system.s:84: Error: invalid constant (7f) 
after fixup


This happens when building ppcrossarm on OS X 10.12 or 10.13, not on 10.10 (but this information is 
inexact, it could rather depend on the version of Xcode installed).


What I suspect is that, when building the rtl for android, fpcrossarm calls the installed clang 
assembler rather than the (separately built) arm-linux-androideabi-as. The remedy then would be to 
specifically instruct fpc what assember (and linker) are to be used.


The make command issued is

sudo make clean crossall crossinstall OS_TARGET=android CPU_TARGET=arm INSTALL_PREFIX=/usr/local 
BINUTILSPREFIX=arm-linux-androideabi-


The built binutils for Android are in /usr/local/bin

[P20:/usr/local/bin] adriaan% ls arm-linux-androideabi*
arm-linux-androideabi-addr2line	arm-linux-androideabi-c++filt	arm-linux-androideabi-nm 
arm-linux-androideabi-ranlib	arm-linux-androideabi-strings
arm-linux-androideabi-ar	arm-linux-androideabi-gprof	arm-linux-androideabi-objcopy 
arm-linux-androideabi-readelf	arm-linux-androideabi-strip
arm-linux-androideabi-as	arm-linux-androideabi-ld	arm-linux-androideabi-objdump 
arm-linux-androideabi-size


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] targetandroid

[Adriaan van Os]

Jonas Maebe wrote:

Apple's "as" is extremely outdated and contains many bugs. I have not 
tested darwin-as anymore recently, so it is quite possible that it no 
longer works. If you do not wish to use clang as assembler (note that 
you do not have to use the one provided by Apple; you can use a newer 
version from Fink/MacPorts/Brew or a self-compiled one), you could try 
adding more workarounds to Tx86AppleGNUAssembler in 
compiler/x86/agx86att.pas


This seems to be a darwin-as issue indeed as building with the clang assembler does work. Thanks 
for the reply.


Regards,

Adriaan van Os
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] targetandroid

[Adriaan van Os]

Karoly Balogh (Charlie/SGR) wrote:

Hi,

On Wed, 13 Jun 2018, Adriaan van Os wrote:


Yuriy Sydorov wrote:

No special version is needed, use 3.0.4 release sources or trunk
sources.

I have fpc-3.0.4 installed on OS X 10.6.8. In a separate 3.0.4 sources folder,
I issue

make clean crossall crossinstall OS-TARGET=android CPU_TARGET=arm
OPT=-Aas-darwin

and get, after the cleaning stuff, the following error


Not all combinations of assemblers and platforms are supported and work.
as-darwin is for native OSX and iOS development using clang. For Android
(as it's just a special flavor of Linux), you probably have to use the
cross GNU binutils supplied with the Android development kit, or some kind
of cross-GNU binutils for ARM (supporting EABIv5 maybe?).

BTW, it's enough if you have your android cross-tools in the path and
specify BINUTILSPREFIX=arm-android- or whatever prefix as/ld/etc has for
Android...


I don't think so. When building a cross compiler, the target assembler is needed only when 
compiling runtime-library code with the new compiler, at the end. And the error happens quite at 
the begiinning of the process, where 32-bit or 64-bit x86 code is created for the new 
cross-compiler (which runs as a 32-bit or 64-bit x86 binary).



An additional idea would be to specify the CPU type explicitly as well,
because arm has a huge range of CPU subarchitectures which is a constant
source of confusion on arm-linux, but I don't think that's the issue here.


I appreciate the reply, but I don't think this has anything to do with it,, for the same reasons as 
above.


Regards,

Adriaan van Os
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] targetandroid

[Adriaan van Os]

Yuriy Sydorov wrote:

On 6/4/2018 2:51 PM, Adriaan van Os wrote:

Yuriy Sydorov wrote:
No special version is needed, use 3.0.4 release sources or trunk 
sources.


I have fpc-3.0.4 installed on OS X 10.6.8. In a separate 3.0.4 sources folder, 
I issue

make clean crossall crossinstall OS-TARGET=android CPU_TARGET=arm 
OPT=-Aas-darwin

and get, after the cleaning stuff, the following error

make -C /Users/adriaan/fpc-android/fpc-3.0.4/rtl 'OPT=-Aas-darwin  ' all
make -C darwin all
/bin/mkdir -p /Users/adriaan/fpc-android/fpc-3.0.4/rtl/units/x86_64-darwin
/usr/local/bin/ppcx64 -dNOMOUSE -Ur -dFPC_USE_LIBC -Ur -Xs -O2 -n -Fi../inc -Fi../x86_64 -Fi../unix 
-Fi../bsd -Fi../bsd/x86_64 -Fi../darwin/x86_64 -FE. 
-FU/Users/adriaan/fpc-android/fpc-3.0.4/rtl/units/x86_64-darwin -Aas-darwin -dx86_64 -dRELEASE -Us 
-Sg ../bsd/system.pp
/Users/adriaan/fpc-android/fpc-3.0.4/rtl/units/x86_64-darwin/system.s:4141:suffix or operands 
invalid for `fcomip'
/Users/adriaan/fpc-android/fpc-3.0.4/rtl/units/x86_64-darwin/system.s:4148:suffix or operands 
invalid for `fcomip'

system.pp(361) Error: Error while assembling exitcode 1
system.pp(361) Fatal: There were 2 errors compiling module, stopping
Fatal: Compilation aborted

This seems to be a 32-bit/64-bit issue. What is the required make command to 
prevent this ?

Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] targetandroid

[Adriaan van Os]

Yuriy Sydorov wrote:

No special version is needed, use 3.0.4 release sources or trunk sources.
arm64 and x86_64 are not supported yet for android. I plan to add 
support for these CPUs later.


Thanks, armv8 is required for Google Play from August 2019 on
<https://android-developers.googleblog.com/2017/12/improving-app-security-and-performance.html>

Regards,

Adriaan van Os
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] targetandroid

[Adriaan van Os]

Yuriy Sydorov wrote:

The android target was merged to the main FPC sources years ago. Use FPC 
3.0.4 sources or trunk to build a crosscompiler for arm-android.


3.0.4 or the special 3.0.3 version ? Does this support armv8 ? ppca64 (3.0.3) -i doesn't list 
Android as a target platform.


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] targetandroid

[Adriaan van Os]

In the past - which was 2013, time flies by - I built an FPC cross-compiler on Mac OS X from the 
FPC targetandroid branch sources. Together with Android binutils (and a linker patch) this worked 
well to build for Android on Mac OS X. As far as I remember, that same compiler could then be used 
for iOS ARM also.


What is the status now ? Can I use a from-the-shelf 3.0.2, 3.0.3 or 3.0.4 compiler for the same 
purpose ?


Thanks,

Adriaan van Os
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Vectorization

[Adriaan van Os]

J. Gareth Moreton wrote:

Hi everyone,

After a lot of work, I have implemented 'vectorcall' into Win64, and made a patch for Lazarus to recognise 
the keyword in the IDE and highlight it accordingly.


Thanks !

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Data alignment feature

[Adriaan van Os]

Jonas Maebe wrote:


That is implicit. The compiler always has aligned local variables to
their declared alignment. There's only an issue if the ABI stack
alignment is smaller than the variable's alignment, as the compiler
currently does not have support to realign the stack to a custom
alignment on entry.


Yes, that's the issue I hinted on.

Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Data alignment feature

[Adriaan van Os]

J. Gareth Moreton wrote:

Florian has implemented a fix recently that allows for better memory alignment using $codealign - true 
though, I do think we need something to guarantee aligned memory from a function akin to GetMem, since one 
way or another, there is a performance penalty in using dynamic arrays over raw pointers (although it's not 
too bad).


I have many objections against the built-in dynamic arrays and never use them.

For Florian's fix though, any local variables are given the correct alignment on the stack, even if the 
stack is unaligned beforehand.


That's good news. Can you give a small code example ? And I would suggest  to add test-programs 
(checking the addeess of aligned global, heap and stack variables) to the fpc test-suite,


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Data alignment feature

[Adriaan van Os]

J. Gareth Moreton wrote:
Oh right.  I see that you've opted to stick with the $codealign compiler directive.  True, no new feature 
should be required, and TM128 shouldn't need to be redeclared by a third-party programmer.


In this case, I think this bug/feature report can be closed now: 
https://bugs.freepascal.org/view.php?
id=32780 - unless you want the 'align' suffix.


I think two questions need to be answered, as there is more than just global 
variables

1. What is the status of alignment of the stack ?
2. I do think we need an alignment option in the FPC memory manager. Or at least a runtime-function 
that gets aligned memory, like 
<http://pubs.opengroup.org/onlinepubs/009695399/functions/posix_memalign.html>


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Vectorization

[Adriaan van Os]

J. Gareth Moreton wrote:

Hey Adriaan,

I dare ask - did the patch help out your issue at all?  I did supply it to Florian as well, although he has 
his own work in progress for vectorization, so whether my code is compatible or not waits to be seen.


Didn't get to it yet. Svn needs fpc 3.0.4 to build, which isn't the production compiler on my 
development system. On another OS X, I tried to checkout svn, but it was (on that system) extremely 
slow. After two multi-hour sessions, I postponed it to later. But I am very interested in the 
patch, so I will follow up later.


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Vectorization

[Adriaan van Os]

J. Gareth Moreton wrote:

I created a Wiki page to plan things out: 
http://wiki.lazarus.freepascal.org/Vectorization


Note that Intel compilers can optimize for different processor architectures (and different vector 
size), as follows 
<https://software.intel.com/en-us/articles/performance-tools-for-software-developers-intel-compiler-options-for-sse-generation-and-processor-specific-optimizations>


Intel high-performance libraries use runtime-dispatching, e.g. for IPP
<https://software.intel.com/en-us/node/722780>

Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Vectorization

[Adriaan van Os]

J. Gareth Moreton wrote:

- There is no desire to include MOVUPS instructions because, while they will work for unaligned memory, are 
much slower than MOVAPS, but MOVAPS will cause a segmentation fault if the memory is not aligned.


Memory should be aligned when using vector code. And developers should know that. The objective of 
vectorization is speed, not to be nice to developers that don't know what they are doing. So, if 
they get a crash, it's their fault. Maybe, the compiler can issue a warning if data used in vector 
code is not aligned.


See e.g. Section 5.3 DATA ALIGNMENT of the Intel® 64 and IA-32 Architectures Optimization Reference 
Manual (where movaps and palignr are used for SSE3 optimized code).


I suggest an FPC runtime function to get an aligned block of memory on the heap. I use 
posix_memalign, but note that Mac OS X has a severe bug where posix_memalign with size 0 causes 
memory corruption ! For size 0, malloc can be used (or a nil pointer returned).


Note that 64-bit AVX-512 <https://software.intel.com/en-us/node/523777>  instructions require 
64-byte alignment.


Regards,

Adriaan van Os
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Vectorization

[Adriaan van Os]

J. Gareth Moreton wrote:

I created a Wiki page to plan things out: 
http://wiki.lazarus.freepascal.org/Vectorization


As a side bar, note what Intel writes about Optimization in the Intel Math Kernel Library Developer 
Reference

<https://software.intel.com/en-us/mkl-developer-reference-c-performance-enhancements>

Performance Enhancements

The Intel Math Kernel Library has been optimized by exploiting both processor and system features 
and capabilities. Special care has been given to those routines that most profit from 
cache-management techniques. These especially include matrix-matrix operation routines such as dgemm().


In addition, code optimization techniques have been applied to minimize dependencies of scheduling 
integer and floating-point units on the results within the processor.


The major optimization techniques used throughout the library include:

• Loop unrolling to minimize loop management costs

• Blocking of data to improve data reuse opportunities

• Copying to reduce chances of data eviction from cache

• Data prefetching to help hide memory latency

• Multiple simultaneous operations (for example, dot products in dgemm) to 
eliminate stalls due to
arithmetic unit pipelines

• Use of hardware features such as the SIMD arithmetic units, where appropriate

Regards,

Adriaan van Os
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Vectorization

[Adriaan van Os]

J. Gareth Moreton wrote:
I guess fixing that might be a good 
starting point. There's also the issue of 
memory alignment causing crashes.


I (and others I think) would much welcome the fix. WIth regard to memory aligment, you would have 
to test what is already fixed in the current (svn) compiler (and what not) as the report is from 
some time ago.


Regards,

Adriaan van Os
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Vectorization

[Adriaan van Os]

J. Gareth Moreton wrote:

Hi everyone,

Since I'm masochistic in my desire to understand and improve the Free Pascal Compiler, I would like to add 
some vectorisation support in its optimisation cycle, since that is one thing that many other compilers 
attempt to do these days.  But before I begin, does FPC support any kind of vectorisation already?  If it 
does I haven't been able to find it yet, and I don't want to end up reinventing the wheel.


See e.g. <https://bugs.freepascal.org/view.php?id=27870>

Regards,

Adriaan van Os
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Free Pascal/Delphi compatibility cross-tests

[Adriaan van Os]

Dmitriy Pomerantsev wrote:

Hello everyone.



1. Difference in implementation.
  For example, in Delphi, Exponent has a bias "For single precision floating-point 
values, the bias is 127." 
(http://docwiki.embarcadero.com/Libraries/Tokyo/en/System.SysUtils.TsingleHelper.Exponent),
 Free Pascal does not 
(http://www.freepascal.org/docs-html/rtl/sysutils/tsinglehelper.exponent.html).


This is certainly not true. The single floatomg-point format is determined by the IEEE-754 
standard. And that format has indeed a bias of 127 
<https://en.wikipedia.org/wiki/Single-precision_floating-point_format> for any compiler.


Or did you mean the Exponent function-return, not the internal format ? Then, my comment above is 
wrong. Anyway, I feel that compilers should follow the IEE-754 and ISO/IEC 10967 
<https://en.wikipedia.org/wiki/ISO/IEC_10967> standards.


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Free Pascal/Delphi compatibility cross-tests

[Adriaan van Os]

Dmitriy Pomerantsev wrote:

Hello everyone.



1. Difference in implementation.
  For example, in Delphi, Exponent has a bias "For single precision floating-point 
values, the bias is 127." 
(http://docwiki.embarcadero.com/Libraries/Tokyo/en/System.SysUtils.TsingleHelper.Exponent),
 Free Pascal does not 
(http://www.freepascal.org/docs-html/rtl/sysutils/tsinglehelper.exponent.html).


This is certainly not true. The single floatomg-point format is determined by the IEEE-754 
standard. And that format has indeed a bias of 127 
 for any compiler.


Regards,

Adriaian van Os
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Staticaly link C/C++ library (.lib) into FreePascal on Windows

[Adriaan van Os]

LacaK wrote:

Hi,

I have C/C++ librarby (".lib" for Windows and ".a" for Linux) from Intel 
IPP package (they distribute ".lib" and also ".dll" for Windows and ".a" 
for Linux)


Note that you can download my ipp FPC interfaces here <http://adriaan.biz/intel/ipp.pas.zip>. I do 
link with statically with success on Mac OS X.


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] resources on non-windows platform

[Adriaan van Os]

Paul Ishenin wrote:

21.11.2016 21:13, Anton Kavalenka wrote:
Is not the time came for own resource compiler for limited type of 
resources (BITMAP, CURSOR, MANIFEST, VERSIONINFO)?

It should not be a problem for a very limited syntax.


I have a Version.r file that does things like

#define __version_hi_num__  2
#define __version_mid_num__ 0
#define __version_lo_num__  5

I can include the defines in an .rc file

#include "Version.r"

The .rc file can be compiled to a .res with windres on various platforms, either cross or native. 
Note that when running windres, you can specify the preprocessor to use, e.g. gcc. The .res can 
then be linked into the application using fpc.


On Mac OS X, I can

#include "Version.r"

in a MacOS .r file. The .r can compiled with Rez to a flat resource file or into a resource fork. 
Also, I can use the version defines in a Mac OS X plist using sed and the output of a small C program


#include 

int main( void )
{
  printf( "s|__CFBundleExecutable__|"__product__"|g\n");
  printf( "s|__CFBundleGetInfoString__|"__product__" "__version_description__", 
"__written_by__"|g\n");

  printf( "s|__CFBundleIdentifier__|"__product_identifier__"|g\n");
  printf( "s|__CFBundleName__|"__product__"|g\n");
  return 0;
}

So, for me it works for all the platforms I need. Of course, the .rc would use the version defines 
differently than the MacOS version info or the plist, but that needs to be setup only once.


Yes, this is very much like C, I don't like that either, but it does work.

Regards,

Adriaan van Os
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Managed types and reference counts revisited

[Adriaan van Os]

Jonas Maebe wrote:


Adriaan van Os wrote on Wed, 17 Aug 2016:

Either I am looking wrong (and missing the point) or the text at 
<http://www.freepascal.org/docs-html/ref/refse91.html> (a follow-up on 
<http://bugs.freepascal.org/view.php?id=26874>) is incorrect.


Doesn't the call to DoIt1(y,7) in procedure Test3 cause the reference 
count to be increased (from 0 to 1) and then decreased (from 1 to 0 
and thus disposed) ? And doesn't DoIt1 use value parameters ?


Yes.

Therefore, doesn't the comment on  the const case (on the top of the 
page) belong to the value-parameter (aka "nothing") case ?


It actually applies to both.

I would say, If const parameters, like var parameters, do nothing, 
there is no reference count decrease, therefore no dispose of classes 
(implementing an interface) even when the reference count is 0 ?


It's about when you pass reference counted non-lvalues to parameters, 
e.g. the result of a function or the expression "ClassInstance as 
InterfaceType". In that case, the compiler will create a temp (on the 
caller side) to store that function/expression result, which results the 
reference count of the interface instance to be increased. After the 
function call to which this interface instance has been passed as 
parameter returns, the reference count will be decreased again because 
the temp gets freed. If the reference count becomes 0 at that point, the 
instance gets freed too. As a result, in this case even with a "const" 
parameter you still have an interface instance that gets freed at some 
point after the call (since otherwise there would be a memory/reference 
count leak).


Passing a class instance directly to a const interface parameter does 
not result in the creation of a temp and hence does not result in 
reference count increases/decreases. In case of a value parameter, there 
is reference count on the callee side regardless of what you passed in.


Thanks for the clarification. I suggest the doc page 
<http://www.freepascal.org/docs-html/ref/refse91.html> to be changed accordingly.


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Managed types and reference counts revisited

[Adriaan van Os]

Thanks for the clarification. I suggest the doc page 
<http://www.freepascal.org/docs-html/ref/refse91.html> to be changed accordingly.


And also the test program there.

Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Managed types and reference counts revisited

[Adriaan van Os]

Either I am looking wrong (and missing the point) or the text at 
<http://www.freepascal.org/docs-html/ref/refse91.html> (a follow-up on 
<http://bugs.freepascal.org/view.php?id=26874>) is incorrect.


Doesn't the call to DoIt1(y,7) in procedure Test3 cause the reference count to be increased (from 0 
to 1) and then decreased (from 1 to 0 and thus disposed) ? And doesn't DoIt1 use value parameters ? 
Therefore, doesn't the comment on  the const case (on the top of the page) belong to the 
value-parameter (aka "nothing") case ? I would say, If const parameters, like var parameters, do 
nothing, there is no reference count decrease, therefore no dispose of classes (implementing an 
interface) even when the reference count is 0 ?


Regards,

Adriaan van Os
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] RTTI

[Adriaan van Os]

Jonas Maebe wrote:
* LLVM does not support the Borland "register" calling convention, so 
i386 support will be impossible until someone adds that to LLVM


Unless it would be an LLVM-specific i386 target without the register calling 
convention ?

Regards,

Adriaan van Os
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Enable LLVM?

[Adriaan van Os]

Jonas Maebe wrote:

Den wrote:

Ah, thanks for giving me a heads up Jonas. I'll have to wait and see
where it goes then. Do you have a page/blog where I can keep up to date
with your progress/roadmap of it? :)


No, just the svn commit log. The status right now is that the system 
unit for Darwin/x86-64 can be mostly compiled and "assembled" (i.e., the 
generated LLVM IR can be successfully parsed by llc -- although since it 
doesn't get completely to the end, I may not have seen all errors for 
code coming before that yet) other than

a) RTTI
b) inline assembler
c) get_frame
d) trampolines for interface methods


Ehw, trampolines. They requires executable stacks. Is there a possibility to pass activation frames 
instead or apply lambda/lifting ?


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] ref count issue with out param

[Adriaan van Os]

Martin Frb wrote:

But "out" param have no such documentation.


Also see the thread "Reference counting interface objects" from October 2014 and PR 26874 
<http://bugs.freepascal.org/view.php?id=26874>


Regards,

Adriaan van Os
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] bitwise shift oddity a << b

[Adriaan van Os]

Jonas Maebe wrote:

No, it does not. It only depends on the type. Shifting an uint32_t with 
value 1 right by 32 bits is undefined. Shifting an uint64_t with value 1 
right by 32 bits is 0.


As I said, this is absurd, as so many other de-facto bad habits in computing. There should be no 
difference between shifting a value (of any type) right by N bits or shifting the same value (of 
the same type) N-times right by 1 bit. That is not a matter of type but of simple logic.


But, of course, I understand that CPUs implement it wrong and that the compilers writers want to be 
compatible with the CPU doing it wrong. That is probably the most practical solution. But that 
doesn't make it less ludicrous.


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] bitwise shift oddity a << b

[Adriaan van Os]

Jonas Maebe wrote:

I would propose to document it as "undefined behaviour", just like C 
does (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf , 
section 4.5.7). The reason is that the behaviour can differ depending on 


Section 6.5.7. But in that standard the behaviour is undefined also when "the value of the right 
operand is greater than or equal to the width of the promoted left operand", which I think is a bit 
too simplistic (since, if we start talking about the maximum number of bits that can "legally" be 
shifted, then that number depends on the actual value of the left operand, but on the other hand if 
we accept that bits get lost, then there is no reason to limit the number of bits that can be shifted)


In other words - if we allow a 1-bit shift to be always correct (independent of the value of the 
left operand) then N 1-bit shifts are always correct too (for any N >= 0). And then, introducing a 
difference between shifting N bits and shifting Nx1 bits is absurd.


Not much thought went into that C-standard (nor in anything related to C).

Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] bitwise shift oddity a << b

[Adriaan van Os]

Jonas Maebe wrote:

Martin Frb wrote:

What is supposed to happen if the 2nd argument is negative?


I would propose to document it as "undefined behaviour", just like C 
does (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf , 
section 4.5.7). The reason is that the behaviour can differ depending on 


Section 6.5.7. But in that standard the behaviour is undefined also when "the value of the right 
operand is greater than or equal to the width of the promoted left operand", which I think is a bit 
too simplistic (since, if we start talking about the maximum number of bits that can "legally" be 
shifted, then that number depends on the actual value of the left operand, but on the other hand if 
we accept that bits get lost, then there is no reason to limit the number of bits that can be shifted)


the cpu, so if you want to guarantee consistent behaviour on all 
platforms, you can no longer just emit a shift left/right instruction 
and have to add all kinds of checks.


Maybe we should support emitting range checks for the right operand 
though (to give an error if it falls outside the range of shift values 
whose behaviour is defined).


The right operand of a bitwise shift is a count, a real-world number of bits. A negative number 
doesn' t make sense and must regarded as an error. So yes, emitting range checking is the right 
idea. We should do better in Pascal than in C .


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] bitwise shift oddity a << b

[Adriaan van Os]

Martin Frb wrote:

What is supposed to happen if the 2nd argument is negative?


Also see <http://bugs.freepascal.org/view.php?id=17710>.

Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] BOOL

[Adriaan van Os]

Michael Schnell wrote:

Now, in C (which does not feature a native boolean type, but boolean 
operators) a *decent* boolean decision is e.g. "if (a)". But the silly C 
programmer did "if (a ==TRUE). Now the boolean variable "a" imported 
from Delphi was presumed as FALSE instead of TRUE.


An interesting example ! It clearly shows the dangers of a language that isn't strictly typed and 
thus doesn't have implicit type conversions.


Regards,

Adriaan van Os
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] BOOL

[Adriaan van Os]

Marco van de Voort wrote:

For variant bools it is definitely -1. There is a comment about that too
somewhere.


I found
<http://blogs.msdn.com/b/oldnewthing/archive/2004/12/22/329884.aspx>
<http://msdn.microsoft.com/en-us/library/windows/desktop/ms221627(v=vs.85).aspx>

Yet another type, VARIANT_BOOL ...

Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] BOOL

[Adriaan van Os]

Michael Van Canneyt wrote:
Well, true is -1 and false 0 :) I wonder if we should forbid it in fpc 
mode ...


We should. IMHO ByteBool is unsigned so >=0...


I suggest to change the internal value of TRUE to 1 for all boolean types, except in mode delphi. 
Then "for b:= false to true" works as one would except.


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] BOOL sorry

[Adriaan van Os]

Sorry for the multiple posts, my email program indicated "failure" on send.

Regards,

Adriaan van Os
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] BOOL

[Adriaan van Os]

Marco van de Voort wrote:

In our previous episode, Adriaan van Os said:

reveals 0 for False and -1 for True, where I had expected 0 for False and
1 f
according to <http://msdn.microsoft.com/en-us/library/eke1xt9y.aspx> the
same
respectively in Visual Studio 2013.


There is a C (99?) bool type, and a winapi (and much older) BOOL type. Two
different libraries, two different headers, two different cases :-)

In old SDKs, BOOL was defined in windef.h, but can't seem to quickly find
that in my current 8.1 (that was seriously mangled due to the winrt
additions). 


WIndef.h in the v7.0 WinSDK clearly defines

#ifdef TRUE
#undef TRUE
#endif
#define TRUE  1



Afaik BOOL was implemented for winapi benefit, and the boolean* types for
pascal booleans (0,1)

More importantly, TRUE is generally defined as !FALSE, and vice versa (your
URL mentiones that too), and thus not as succ(TRUE).  So even if the values
are successive, that doesn't mean it is ordinal other than being an integer
derived value in older compilers.


Well, not true = false and not false = true, that still holds. Which is not the 
same as
not(ord(b))=ord(not(b)) which does not hold.



So, there doesn't seem to be a WIndows compatibilty reason to use -1 for
True
Delphi has -1 for True, but then it would apply to mode Delphi only).


IMHO using the for loop on a non pascal boolean type is simply wrong. At the
very least the assumption that the false and true are successive, and maybe
even using BOOL as loopvar in the first place.


The compiler accepts it.

Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] BOOL

[Adriaan van Os]

Marco van de Voort wrote:

In our previous episode, Adriaan van Os said:

reveals 0 for False and -1 for True, where I had expected 0 for False and
1 f
according to <http://msdn.microsoft.com/en-us/library/eke1xt9y.aspx> the
same
respectively in Visual Studio 2013.


There is a C (99?) bool type, and a winapi (and much older) BOOL type. Two
different libraries, two different headers, two different cases :-)

In old SDKs, BOOL was defined in windef.h, but can't seem to quickly find
that in my current 8.1 (that was seriously mangled due to the winrt
additions). 


WIndef.h in the v7.0 WinSDK clearly defines

#ifdef TRUE
#undef TRUE
#endif
#define TRUE  1



Afaik BOOL was implemented for winapi benefit, and the boolean* types for
pascal booleans (0,1)

More importantly, TRUE is generally defined as !FALSE, and vice versa (your
URL mentiones that too), and thus not as succ(TRUE).  So even if the values
are successive, that doesn't mean it is ordinal other than being an integer
derived value in older compilers.


Well, not true = false and not false = true, that still holds. Which is not the 
same as
not(ord(b))=ord(not(b)) which does not hold.



So, there doesn't seem to be a WIndows compatibilty reason to use -1 for
True
Delphi has -1 for True, but then it would apply to mode Delphi only).


IMHO using the for loop on a non pascal boolean type is simply wrong. At the
very least the assumption that the false and true are successive, and maybe
even using BOOL as loopvar in the first place.


The compiler accepts it.

Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] BOOL

[Adriaan van Os]

Marco van de Voort wrote:

In our previous episode, Adriaan van Os said:

reveals 0 for False and -1 for True, where I had expected 0 for False and
1 f
according to <http://msdn.microsoft.com/en-us/library/eke1xt9y.aspx> the
same
respectively in Visual Studio 2013.


There is a C (99?) bool type, and a winapi (and much older) BOOL type. Two
different libraries, two different headers, two different cases :-)

In old SDKs, BOOL was defined in windef.h, but can't seem to quickly find
that in my current 8.1 (that was seriously mangled due to the winrt
additions). 


WIndef.h in the v7.0 WinSDK clearly defines

#ifdef TRUE
#undef TRUE
#endif
#define TRUE  1



Afaik BOOL was implemented for winapi benefit, and the boolean* types for
pascal booleans (0,1)

More importantly, TRUE is generally defined as !FALSE, and vice versa (your
URL mentiones that too), and thus not as succ(TRUE).  So even if the values
are successive, that doesn't mean it is ordinal other than being an integer
derived value in older compilers.


Well, not true = false and not false = true, that still holds. Which is not the 
same as
not(ord(b))=ord(not(b)) which does not hold.



So, there doesn't seem to be a WIndows compatibilty reason to use -1 for
True
Delphi has -1 for True, but then it would apply to mode Delphi only).


IMHO using the for loop on a non pascal boolean type is simply wrong. At the
very least the assumption that the false and true are successive, and maybe
even using BOOL as loopvar in the first place.


The compiler accepts it.

Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] BOOL

[Adriaan van Os]

While doing some Win32 programming I ran into a for loop that didn't work

var b: bool;
for b := False to True do ...

whereas

var b: bool;
for b := False downto True do ...

did work. The reason seems to be the internal value of False and True for BOOL, 
as

program testbool;
uses Windows;
var b: BOOL;
begin
  b := False;
  writeln
( 'Ord( BOOL) for False = ', Ord( b));
  b := True;
  writeln
( 'Ord( BOOL) for True  = ', Ord( b))
end.

reveals 0 for False and -1 for True, where I had expected 0 for False and 1 for True. Also, 
according to <http://msdn.microsoft.com/en-us/library/eke1xt9y.aspx> the same test reveals 0 and 1 
respectively in Visual Studio 2013.


So, there doesn't seem to be a WIndows compatibilty reason to use -1 for True (unless maybe if 
Delphi has -1 for True, but then it would apply to mode Delphi only).


Regards,

Adriaan van Os
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Windows DirectX9

[Adriaan van Os]

Michael Thompson wrote:
Ah, think I might know what the issue is.  Near as I can make out, 
PilotLogic do not provide individual download for each of the modules.  
It's one big fat half gig download :-(  *Everything* is in that download.


I did download that one big half gig, but still could not locate DirectX in it.


http://sourceforge.net/p/lazarusvideoutilities/code/HEAD/tree/trunk/Packages/


Never mind, that link works, thanks.

Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Windows DirectX9

[Adriaan van Os]

Michael Thompson wrote:
The most up-to-date/maintained version ships with Pilot Logic's 
CodeTyphon.   Pilot Logic derived their version from the port by forum 
user TheBlackSheep, and in turn TheBlackSheep derived his version from 
the one listed above.  


Thanks for the hint, but I couldn't find DirectX in the Pilot Logic's 
CodeTyphon downloads.

Sven Barth wrote

Currently everyone gets the full package of packages even if they aren't 
needed. So it's more useful to have a repository where everyone can download 
those packages he needs. Other languages have similar approaches (e.g. Python 
and Ruby if I remember correctly).


How does this work ? Does one assemble a package, put it on a server and then 
submit the URL ?

Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] _wcsicmp solved

[Adriaan van Os]

Is there an RTL or package equivalent for _wcsicmp et all 
<http://msdn.microsoft.com/en-us/library/k59z8dwe.aspx> or should the libc declaration be added to 
the application ? Or is there another recommendation to compare wide (so-called Unicode) strings 
case-insensitive ?


Sorry, I found WideCompareText after sending my message.

Regards,

Adriaan van Os


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] _wcsicmp

[Adriaan van Os]

Is there an RTL or package equivalent for _wcsicmp et all 
<http://msdn.microsoft.com/en-us/library/k59z8dwe.aspx> or should the libc declaration be added to 
the application ? Or is there another recommendation to compare wide (so-called Unicode) strings 
case-insensitive ?


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Windows DirectX9

[Adriaan van Os]

Sven Barth wrote:

 > Is there a fixed policy to include packages like these with FPC (or 
not) ? The license is Mozilla Public License 1.1.


The policy is that we'd like to reduce the amount of packages we ship 
with FPC directly. For this there is a package repository which can be 
accessed using fppkg. Currently there is only a lnet package, but if you 
take a look at the wiki entry for fppkg you might be able to add a new 
package description file for the DirectX headers so that we can add it 
there.


So, these "extra" packages are not in svn trunk ? But on separate servers ? But how are they synced 
with compiler changes ? Who creates and maintains them ?


I will note that DirectX Pascal bindings do seem to be distributed with Delphi.

Regards,

Adriaan van Os
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Windows DirectX9

[Adriaan van Os]

Looking on the internet for DirectShow Pascal bindings, I came across 
<http://code.google.com/p/dspack/source/browse/#svn%2Ftrunk%2Fsrc%2FDirectX9>. With a few 
modifications, this does compile with fpc-2.6.4, e.g.


adriaan% fpc -MDelphi -Twin32 DirectShow9.pas
Free Pascal Compiler version 2.6.4 [2014/02/26] for i386
Copyright (c) 1993-2014 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling DirectShow9.pas
Compiling DirectDraw.pas
Compiling DirectSound.pas
Compiling DXTypes.pas
Compiling Direct3D9.pas
53273 lines compiled, 2.3 sec

Is there a fixed policy to include packages like these with FPC (or not) ? The license is Mozilla 
Public License 1.1.


Regards,

Adriaan van Os
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] RTL: high CPU load in heap manager

[Adriaan van Os]

Jonas Maebe wrote:

On 10/11/14 18:47, Karoly Balogh (Charlie/SGR) wrote:

We were profiling our code, and one RTL function regularly popped up in
close to the top in the profiling list.

It's remove_freed_fixed_chunks(). Can someone explain to me under what
condition this code is triggered very often and/or could take long to
execute (there's a loop in there)?


This was reported earlier too, but I couldn't reproduce it:
http://bugs.freepascal.org/view.php?id=18079 (especially comment 47405
by Sergei).


I suggest to use cmem and compare the results.

I will also note that malloc uses mremap <http://man7.org/linux/man-pages/man2/mremap.2.html> on 
Linux only, rather than physically moving bytes around. This makes a very efficient realloc 
possible (on Linux only).


The Mach kernel of Mac OS X has vm_remap, but Apple is not smart enough to use it (as of OS X 
10.8.5, the source code for malloc in OS X 10.9 is unknown).


Windows neither has a mremap nor a realloc, which implies that on every resize a new block  has to 
be allocated, with all bytes physically moved to the new location, see 
<http://www.mgroeber.de/misc/windows_heap.html>. This makes realloc on Windows (with the system 
heap manager) extremely ineffcient.


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Masm

[Adriaan van Os]

Tomas Hajny wrote:

On Fri, November 7, 2014 14:35, Adriaan van Os wrote:
 .
 .

I still have to investigate the internal error 200602232.


Have you tried Pierre's suggestion of testing it with the external linker


Yes, that was the first I tried. No success. I am now experimenting with LINK.EXE, but it looks 
like it requires a compiler hack (something like _imp_dllname_procname rather than 
$dll$dllname$procname for imports).



(-Xe)? However, the Sergei's note about incomaptible use of sections
between MS VCC and FPC should be probably also of interest.


Problems are there to be solved, not to scare away. Some of it may be related to debug info, which 
isn't available anyway and can be stripped, as FPC doesn't write PDB.




BTW, it's better to mention that you're not subscribed to this list in
your questions sent here.


I didn't know that I am not suscribed .

Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Masm

[Adriaan van Os]

Dmitry Boyarintsev wrote:
On Fri, Nov 7, 2014 at 12:55 PM, Adriaan van Os <mailto:f...@microbizz.nl>> wrote:


(to my astonishment Xcode even installs nasm).

Just in case, you find this interesting:


I saw that and wondered if nasm can be used with FPC on Mac OS X. What is the status of -Amacho, by 
the way ?


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Masm

[Adriaan van Os]

I can not make anything of the Visual C++ produced .obj with the Microsoft provides docs. If that 
isn't typically Microsoft ... How to corrupt any standard by "slightly modifying" it  I will 
look further to dig up some meaningful info.


Amusingly, Microsofts own SDK dumpbin tool says

Microsoft (R) COFF/PE Dumper Version 9.00.30729.01
Copyright (C) Microsoft Corporation.  All rights reserved.

File Type: ANONYMOUS OBJECT

ANON OBJECT HEADER VALUES
   1 version
 14C machine (x86)
545CC084 time date stamp Fri Nov 07 04:52:20 2014
 ClassID: {0CB3FE38-D9A5-4DAB-AC9B-D6B6222653C2}
3F5F size
   0 flags

It perfectly well understands FPC generated .o files, but not Visual C++ generated .obj files. 
Unbelievable.


However, objconv <http://www.agner.org/optimize/#objconv> sheds some light on 
the issue

Whole program optimization intermediate file for MS compiler. 
Undocumented

and indeed the Debug version of the same .obj file has a normal COFF header, is recognized by the 
FPC linker (and produces FPC internal error 200602232).


Anyway, I think the workaround for the "Illegal Coff Magic" linker error is to recompile with 
Visual C++ turning whole-program-optimization off. It suggest to document this somewhere. Or to 
improve the error message in compiler/ogcoff.pas for "Whole program optimization intermediate file 
for MS compiler. Undocumented" files.


I still have to investigate the internal error 200602232.

Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Masm

[Adriaan van Os]

Florian Klaempfl wrote:

Am 07.11.2014 10:35, schrieb Adriaan van Os:

Anybody with hands-on experience compiling with FPC for MASM, including
the RTL ? The FPC compiler option is there. 


NASM ist probably supported better and should be able to generate a lot
of different object file types.


Thanks for the hint. Compiling Pascal code with -Anasmwin32 works fine, both with the internal 
linker and GNU LD. The advantage over MASM is that it can be used cross (to my astonishment Xcode 
even installs nasm).


Next, I will try to combine this with LLD or LINK.EXE.

Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Masm

[Adriaan van Os]

Sergei Gorelkin wrote:

Your header looks like a BigObjHeader


Ah, that's interesting, thanks.

This means that the object is prepared to handle relocation that are 
not in

the 4-byte
range... A feature that Free Pascal indeed does not support IIRC...

   There is probably an option somewhere to use normal 32-bit 
relocation type
objects in you Visual C++ configuration, unless you really need those 
64-bit

relocations...

Even if this issue is resolved, linking together binutils-compatible and 
VC-compatible COFF files is next to impossible, due to significant 
differences in processing of COMDAT sections, debug information, section 
naming, etc.


Still it would be useful (and not very difficult, see 
<http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140915/235411.html>) to add BIGOBJ 
support to the FPC linker. BIGOBJ COFF files could be produced by other compilers than MS-VC, e.g. 
LLVM.


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Masm

[Adriaan van Os]

But  if the formats are the same, what is the cause of the error 
message " Illegal COFF Magic" when trying to statically link with FPC a 
VCC produced .obj or .lib ?


I found the COFF docs here <http://wiki.osdev.org/COFF> and here
<http://msdn.microsoft.com/en-us/gg463119.aspx>

the Visual C++ produced .obj has a header that starts with

00 00 FF FF 01 00  4C 01 

The FPC .o has a header that starts with

4C 01 

which indicates a standard COFF header (as checked by compiler/ogcoff.pas).

I can not make anything of the Visual C++ produced .obj with the Microsoft provides docs. If that 
isn't typically Microsoft ... How to corrupt any standard by "slightly modifying" it  I will 
look further to dig up some meaningful info.


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Masm

[Adriaan van Os]

Marco van de Voort wrote:

In our previous episode, Adriaan van Os said:
It is rather unfortunate that fpc can only link OMF, not COFF on Windows (I read on some previous 
posts that it is the other way round, but according to 
<http://stackoverflow.com/questions/966597/whats-the-difference-between-the-omf-and-coff-format> 
and <http://www.iecc.com/linker/linker03.html> that doesn't seem to be the case).


Easiest is to check the files with cygwin "file", and then you'll see:

C:\pp32\units\i386-win32\ptc>file ptc.o
ptc.o: MS Windows COFF Intel 80386 object file

FPC is COFF, and I don't see anything in the referenced links saying
otherwise. The stackoverflow link is quite old.

The first link seems to indicate that VSS can generate both omf and coff, so
let it generate COFF ?


Well, according to <http://msdn.microsoft.com/en-us/library/s0ksfwcf.aspx>

omf
Generates object module file format (OMF) type of object module. /omf implies /c; ML.exe does not 
support linking OMF objects.

Not available in ml64.exe.

So, COFF seems to be the standard for VCC. When I run mingw-objdump I get "file format pe-i386" for 
both a VCC .obj and an FPC .o.


But  if the formats are the same, what is the cause of the error message " Illegal COFF Magic" 
when trying to statically link with FPC a VCC produced .obj or .lib ?


Regards,

Adriaan van Os
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Masm

[Adriaan van Os]

Anybody with hands-on experience compiling with FPC for MASM, including the RTL ? The FPC compiler 
option is there. The advantageis that ML.EXE can produce both COFF and OMF, so that VCC code can be 
statically linked with FPC code, using the Microsoft linker. Or at least in theory 


It is rather unfortunate that fpc can only link OMF, not COFF on Windows (I read on some previous 
posts that it is the other way round, but according to 
<http://stackoverflow.com/questions/966597/whats-the-difference-between-the-omf-and-coff-format> 
and <http://www.iecc.com/linker/linker03.html> that doesn't seem to be the case).


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Reference counting interface objects

[Adriaan van Os]

Jonas Maebe wrote:


No, it won't:
1) if the external code expects it to be "out" and you declare it as 
"var": the caller will decrease the reference count and the ppEvent that 
you get will have as initial value "nil". You can just assign to it like 
normal.
2) if the external code expects it to be "var" and you declare it as 
"out": the caller will not do anything and hence the ppEvent will not be 
nil. However, assignments to the "out" parameter still cause its 
reference count to be decreased. After all, you can assign multiple 
times to an "out" parameter, so the compiler cannot assume it's already 
nil. The only problem that could happen here is if you would explicitly 
write your code in a way that behaves differently depending on whether 
the initial value is nil (e.g., assigning something to it only in one 
branch of an if-statement, and then later checking whether it's "still" 
nil to determine whether you have to assign something else to it).


Sorry, but the above explanation flabberghasts me.

case 1.

MF binding declaration

 function GetEvent
( dwFlags   : DWORD;
  out ppEvent   : IMFMediaEvent): HResult; stdcall;

Pascal code is the caller and Windows MF is the callee.

theResult := theSession.GetEvent
  ( 0, theEvent);

 The compiler sees the out parameter and (as you explained)

* OUT: the reference count of the value that's passed in is decreased by 1, and the variable that's passed into the procedure is initialized to "empty" (nil, but that's an implementation detail) 


This produces the following assembly

# [195] theResult := theSession.GetEvent
leal-24(%ebp),%eax
callFPC_INTF_DECR_REF
leal-24(%ebp),%eax
pushl   %eax
pushl   $0
pushl   -8(%ebp)
movl-8(%ebp),%edx
testl   %edx,%edx
jne .Lj260
movl$210,%eax
callFPC_HANDLEERROR
.Lj260:
movl(%edx),%eax
call*12(%eax)
movl%eax,-16(%ebp)

where FPC_INTF_DECR_REF is found in rtl/inc/objpas.inc

procedure fpc_intf_decr_ref(var i: pointer);[public,alias: 
'FPC_INTF_DECR_REF']; compilerproc;
  begin
if assigned(i) then
  begin
IUnknown(i)._Release;
i:=nil;
  end;
  end;

So, before Windows returns a new value for ppEvent, the compiler emits a call to _Release, 
preventing a memory leak for our Pascal theEvent parameter.


case 2.

MF binding declaration

 function GetEvent
( dwFlags   : DWORD;
  var ppEvent   : IMFMediaEvent): HResult; stdcall;

Pascal code is the caller and Windows MF is the callee.

theResult := theSession.GetEvent
  ( 0, theEvent);

The compiler sees the out parameter and (as you explained)

* VAR: nothing happens to the reference count. A reference to the original variable is passed in, and changing it or reading it has exactly the same effect as changing/reading the original variable. 


This produces the following assembly

# [195] theResult := theSession.GetEvent
leal-24(%ebp),%eax
pushl   %eax
pushl   $0
pushl   -8(%ebp)
movl-8(%ebp),%edx
testl   %edx,%edx
jne .Lj260
movl$210,%eax
callFPC_HANDLEERROR

So, Windows returns a new value for ppEvent, the compiler does not emit a call to _Release, and our 
Pascal theEvent parameter leaks (except if you assume that Windows MF behaves different for both 
cases, i.c. if NIL is passed or not. This is highly unlikely, because the declaration in 
Mfobjects.idl is


HRESULT GetEvent(
[in] DWORD dwFlags,
[out] IMFMediaEvent** ppEvent
);

which ignores the input value 
<http://msdn.microsoft.com/en-us/library/hh916383.aspx>.

Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Reference counting interface objects

[Adriaan van Os]

Jonas Maebe wrote:


On 16 Oct 2014, at 12:35, Adriaan van Os wrote:

Now, it seems (correct me if I am wrong) that theEvent doesn't need to 
be manually released, because it has been declared as an OUT parameter 
rather than a VAR parameter. So, if this is true, this information is 
crucial when writing interface bindings.


Nothing ever needs to be manually released, regardless of whether it's a 
VAR or OUT parameter. That's the whole point of automatic reference 
counting)


I agree for pure Pascal code, where a parameter can be OUT or VAR and automatic release will work 
in both cases. However, I disagree for interfacing with external interfaces. It must be clear for 
the bindings-writer that VAR in the bindings instead of (what should have been) OUT can cause a 
memory leak. This is tricky enough that it deserves an explanation in the manual. For example, I 
think (from Windows MediaFoundation)


type
IMFMediaEventGenerator = interface( IUnknown) ...

 function GetEvent( dwFlags: DWORD; OUT ppEvent: IMFMediaEvent): 
HResult; stdcall;

is correct, whereas

 function GetEvent( dwFlags: DWORD; VAR ppEvent: IMFMediaEvent): 
HResult; stdcall;

will leak memory.



Regarding the effects of the various qualifiers:
* nothing (value): the reference count of the parameter is increased (I 
forgot whether it's the caller or callee that does it) on entry and 
decreased on exit
* OUT: the reference count of the value that's passed in is decreased by 
1, and the variable that's passed into the procedure is initialized to 
"empty" (nil, but that's an implementation detail)
* VAR: nothing happens to the reference count. A reference to the 
original variable is passed in, and changing it or reading it has 
exactly the same effect as changing/reading the original variable.
* CONST: this is the only tricky one. Again nothing happens to the 
reference count, but because you can pass non-lvalues here. In 
particular, you can pass a class implementing an interface rather than 
the interface itself, which can cause the class to be freed 
unexpectedly. See the example at 
http://docwiki.embarcadero.com/RADStudio/XE7/en/Using_Reference_Counting . 
The same can happen with functions returning a class instance passed to 
a function expecting a CONST interface parameter. There is an open bug 
report about adding a warning for it: 
http://bugs.freepascal.org/view.php?id=19503


Thanks for the explanation. This clarifies things.

Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel