Re: [fpc-devel] download or compile documentation

[Tomas Hajny via fpc-devel]

On 2024-05-09 10:47, Marģers . via fpc-devel wrote:

On 2024-05-09 09:17, Marģers . via fpc-devel wrote:

Hi,


Is there a way to download human readable format documenation?

Looking documentation of 3.2.2 and it is bad. Errors and errors.


What do you mean with "errors and errors"?


Wrong word usage, decription of function does not mach function.


Well - if you mean that textual description, then you may want to check 
the latest state in the .xml files for the respective units. However, 
note that the description refers the released version and thus may not 
reflect recent changes in trunk.


If your "description" means information about parameters, their type, 
etc., (i.e. definition of the function interface), then note that this 
documentation is always generated from the respective sources (i.e. 
always correct from this point of view), however, it reflects the 
situation valid for the default target on which the documentation was 
generated which may result in certain differencies (e.g. in case that 
certain functions and/or their overloads are only available for certain 
targets, or that certain parameter types differ slightly among the 
targets for whatever reason - we try to avoid this as much as possible, 
but there are cases when this difference has certain impact).


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

Re: [fpc-devel] download or compile documentation

[Tomas Hajny via fpc-devel]

On 2024-05-09 09:17, Marģers . via fpc-devel wrote:


Hi,


Is there a way to download human readable format documenation?

Looking documentation of 3.2.2 and it is bad. Errors and errors.


What do you mean with "errors and errors"?



Wanted to crosschech, maybe it is all fixed meanwhile.


Sources of the docs are available in Git and are "human readable", 
although obviously not as easily as the final output formats.




Failing to compilde documentation by myself. Where to download or how
to compile?


Are you aware of the repository "Documentation" 
(https://gitlab.com/freepascal.org/fpc/documentation) in Gitlab? Have 
you read the included README.md file (there is information on the 
supported targets)?




Simple "make" does not work. It is allways "Target not supported, run
fpcmake". And that is not valid solution.


In order to build the complete docs, you need full sources as well, 
because descriptions of interfaces are directly generated from there. In 
order to do that, the "combined" repository "FPC Build" is used (with 
the approriate make target). However, note that there are some 
prerequisites (also described in the README.md).


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

Re: [fpc-devel] error target i386 -Cp80486

[Tomas Hajny via fpc-devel]

On 2024-04-23 11:50, Marģers . via fpc-devel wrote:

1) does not work
make clean singlezipinstall OS_TARGET=win32 CPU_TARGET=i386
ALLOW_WARNINGS=1 OPT="  -O2 -vxitl -Cp80486 -Op80486"

hangs on
system.inc(421,2) Start reading includefile
C:\Users\Lietotajs\Downloads\fora\a\486\gh\rtl\inc\generic.inc

 .
 .

Indeed. This is clearly an issue related to optimizations. The important 
point missing here is that it happens when compiling with ppc1.exe. I 
just tried building a trunk compiler (make rtl_all compiler_all) with 
"OPT=-O- -Cp80486 -Op80486" and then started another compilation round 
with compiler built this way, but using -O2 this time, in order to make 
sure that it wasn't an optimization bug in the released 3.2.2 compiler. 
The new compilation round (using a non-optimized compiler) hangs at an 
exactly the same place, i.e. it's a bug (probably endless loop?) in the 
optimization code specific to the trunk compiler. @Gareth, could you 
please have a look at it?


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

Re: [fpc-devel] dos go32v2 compile target on target?

[Tomas Hajny via fpc-devel]

On 2024-02-27 11:14, Marģers . via fpc-devel wrote:

Should I be able to compile DOS go32v2 target from DOS itself?

Overcoming some challenges was possible to compile fpc 3.2.2 with
starting compiler version 3.2.2. Version 3.2.0 does not work.

compiling trunk using "make" fall into infinite loop on this command

t:\sv\fpc331\compiler\ppc1.exe -Ur -Xs -O2 -n -Fi../inc -Fi../i386
-FE. -FUt:\sv\fpc331\rtl\units\go32v2 -vx -di386 -dRELEASE -Us -Sg
system.pp

Even thou executing it separately there is no problem.


Building the compiler under GO32v2 is not guaranteed. It might work if 
all the prerequisites are fulfilled, but it may not. What's the 
environment you used (operating system, etc.)?


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

[fpc-devel] HTML e-mails in the list (Was: Re: {$push} and {$pop} on trunk [2024/02/13] for aarach64 doen't work)

[Tomas Hajny via fpc-devel]

On 2024-02-16 10:06, Michael Van Canneyt via fpc-devel wrote:

On Fri, 16 Feb 2024, Hairy Pixels via fpc-devel wrote:


His email looks good to me. Much easier to see code with formatting.

Who doesn't have email clients with HTML support these days? I can't 
imagine how old your system must be to not have this.


I don't have HTML support in my mail program. My mail program is text 
based.


HTML in mail is for 99.99% of cases a waste of bandwidth. I care about
the content of a message, not about the markup.


@Michael - thanks, I'm sure there are others, possibly having HTML 
support but still preferring plain text e-mails for various reasons.


Since I triggered this discussion, I'd like to stop it before it evolves 
to a lengthy discussion about something which is not on topic on this 
list - if somebody feels a necessity to continue, fpc-other is the right 
place. Anyway - the particular message of the original poster was 
broken, possibly as a result of the mailing list processor adding the 
usual footer to it (I cannot check the culprit easily and I don't intend 
to try doing it) resulting in issues even with rather up to date e-mail 
clients supporting HTML. In particular, there was an empty plain text 
section in the e-mail containing just the footer. When responding to it 
with a very up to date mobile e-mail client (obviously supporting HTML 
e-mails), the original message was not quoted, because the client 
preferred the plain text version (which is a very reasonable default, 
especially on a mobile device). When displaying the message in another 
client (open-source webmailer, obviously also supporting HTML e-mails), 
parts of the message were displayed mixed with the footer.


As a moderator of this list, I _recommend_ everybody to use plain-text 
e-mails, or at least to configure the e-mail client to send both 
plain-text and HTML version of the outgoing messages. It isn't a strict 
requirement, but please understand that doing otherwise may result in 
issues.


Thanks

Tomas
(one of FPC mailing list moderators)
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] {$push} and {$pop} on trunk [2024/02/13] for aarach64 doen't work

[Tomas Hajny via fpc-devel]

On 2024-02-13 20:59, Kirill Kranz via fpc-devel wrote:


Hi Kirill,


I have:

 .
 .

I believe that you should create a bug report for this issue if you 
haven't done so yet.


Apart from that, I'd suggest configuring your e-mail client for sending 
a plain text version of your posts to the mailing list (at least in 
parallel to an HTML version, similarly to your other account from which 
you sent your original message which ended up in the moderation queue), 
because the HTML version appeared broken in at least some e-mail clients 
(I tried two and had issues in both of them, although different ones).


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

Re: [fpc-devel] ""make clean" builds ppc1 [[Re: Getting error building fpc for clang 16]]

[Tomas Hajny via fpc-devel]

9. prosince 2023 18:24:10 SEČ, Martin Frb via fpc-devel 
 napsal:
>On 09/12/2023 17:03, Martin Frb via fpc-devel wrote:
>> Anyway, I changed the make
>>  make install INSTALL_PREFIX=/home/m/fpc/$INSTPATH/gw3  OPT=" -Clv16.0 " 
>> LLVM=1
>> 
>> Then next it fails, with the same error on
>>     make clean
>> 
>> Yes, it tries to compile a file while doing "make clean"
>
>Even stranger, if I do  delete the ppc1 before "make clean"
>rm /home/m/fpc/$INSTSRC/source/compiler/ppc*
>
>Then "make clean" will build a new ppc1. Why?

I believe that it might be because the compiler is used in FPC makefiles to 
determine the default target (used if no target is specified on the make 
command line specifically) and this target determines the location of files to 
be cleaned.

Tomas

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

Re: [fpc-devel] fnmatch (linux), where is the external

[Tomas Hajny via fpc-devel]

On 2023-10-17 15:34, robert rozee via fpc-devel wrote:

 .
 .
The problem is that the debs install a version (Makefile.compiled 
files)

that is blind for changes to the compiler.

If you need a custom compiler, you need to compile lazarus yourself 
too,

either clone it yourself with git or use fpcupdelux.



i start out with a clean Linux install, then install the three .deb 
packages.


next i place in /usr/share/fpcsrc/3.2.2/ the following script and run
it as root:

#!/bin/sh
COMPILER=fpc
make clean
make all FPC=$COMPILER OPT="-Fl/usr/local/lib"
make FPC=$COMPILER install INSTALL_PREFIX=/usr/

this script, according to Fred vS, rebuilds: FPC, the FPC RTL, and the
Lazarus LCL. i have every reason to believe that this script does
rebuild everything, but i am open to any additional steps that should
be added to the script to rebuild anything that has been missed out.


No, Lazarus LCL is not rebuilt this way, this is just for FPC and FPC 
RTL.


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

Re: [fpc-devel] fnmatch (linux), where is the external code/symbol located?

[Tomas Hajny via fpc-devel]

On 2023-10-17 13:46, robert rozee via fpc-devel wrote:

Op 17-10-2023 om 13:17 schreef robert rozee via fpc-devel:

Date: Tue, 17 Oct 2023 09:32:16 +0200
From: Marco van de Voort 


(1) installing a new compiler, possibly erasing a release (-Ur) 
compiler

with one that isn't.



(2) modifying LCL source.


reversing the edit, rebuilding the compiler, RTL, etc, and now when 
run lazbuild reports:



This seems to indicate the cause of the state problem is the source
modification rather than the compiler recompile. Which is logical 
since

it invalidates the RTL.


why on earth is it logical??? one of the main functions of the FPC
compiler (tm, the department of duplicate words department) should
surely be the ability to rebuilt itself. if it can NOT rebuild itself
successfully then there is something _really_ wrong down in the
gubbins. i can flip back and forth between working and not working, as
many times as i wish, without any deviation from the outcome.
furthermore, it is my understanding that the compiler is DESIGNED to
be rebuilt by the end user.


Do you realize that neither the LCL nor the Lazarus are "the compiler"? 
It might be better to discuss what is designed for Lazarus / LCL in some 
Lazarus list.




what i am demonstrating is that if an ERROR in the source code is
REMOVED, then the compiler breaks. surely this is very, very wrong?


The compiler doesn't break, it reports an error situation. The compiler 
also provides means for analyzing this situation if needed (-vt and -s 
compiler optionsin this case). Alternatively, you can choose the end 
user approach, but then you should probably follow the documentation 
coming from Lazarus regarding how things should be done.


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

Re: [fpc-devel] LEA instruction speed

[Tomas Hajny via fpc-devel]

On 2023-10-13 17:08, J. Gareth Moreton via fpc-devel wrote:

Interesting!  That's a bug report to send to the maintainers of the
framework.  I'll need to have them fix it before I'd be willing to try
again with its use in FPC.

Removed the reference.  Apologies - I'm rushing a bit.


BTW, it's IMHO questionable whether a benchmark framework restricted to 
just a subset of targets supported for the given architecture should be 
really used within FPC source codes (if that's your potential intention 
anyway). If it was intended for the testsuite, it would immediately fail 
at compile time when checking the testsuite under some other target, 
because the test doesn't specify that its use should be restricted to 
certain targets (it's only restricted for i386 and x86_64 regardless of 
the operating system - that's fine for the original version, but not for 
the benchmark framework).


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

Re: [fpc-devel] LEA instruction speed

[Tomas Hajny via fpc-devel]

On 2023-10-13 16:25, J. Gareth Moreton via fpc-devel wrote:

GetLogicalProcessorInformation returns a Boolean - if false, an error
occurred, and is handled as follows:

DiagnoseAndExit('Failed during call to GetLogicalProcessorInformation:
' + GetLastError.ToString);

GetLastError = 8 indicates "out of memory", which I will say is odd.

Nevertheless, because of such teething problems with the framework,
I'm going to remove it from "blea" for now.  As it stands, please find
attached the test that appears in the merge request:
https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/502


The attached version still contained reference to the framework.

The problem with 32-bit compilation of the framework was due to a 
missing stdcall calling convention in the GetLogicalProcessorInformation 
declaration.


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

Re: [fpc-devel] LEA instruction speed

[Tomas Hajny via fpc-devel]

On 2023-10-13 09:26, Tomas Hajny wrote:

On 2023-10-12 20:02, J. Gareth Moreton via fpc-devel wrote:

So an update.

 .
 .

The latest version of blea.pp doesn't compile with a 32-bit compiler -
line 76 contains an unconditional reference to R8 register, which
obviously doesn't for the 32-bit mode.


BTW, the line shouldn't be necessary at all, because global variables 
should be initialized to 0 on program start anyway as far as I know.


When fixing the problem above, compiling to 32-bit mode and running it, 
the test fails with an error in GetLogicalProcessorInformation (it 
states "8" in place of the error information; I wonder if it isn't 
misinterpreted, because 8 is number of logical CPUs on the machine used 
for running the test).


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

Re: [fpc-devel] LEA instruction speed

[Tomas Hajny via fpc-devel]

On 2023-10-12 20:02, J. Gareth Moreton via fpc-devel wrote:

So an update.

 .
 .

The latest version of blea.pp doesn't compile with a 32-bit compiler - 
line 76 contains an unconditional reference to R8 register, which 
obviously doesn't for the 32-bit mode.


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

Re: [fpc-devel] 47k attachment

[Tomas Hajny via fpc-devel]

On October 13, 2023 03:45:58 +0200, "J. Gareth Moreton via fpc-devel" 
 wrote:


Hi,

>To whom it may concern,
>
>I have a new message for the "LEA instruction speed" chain, but it is 
>currently in holding as it contains a 47k ZIP file (source code only, and a 
>third-party licence agreement).  Can the mailing list maintainer confirm (or 
>deny) that it's okay?

Sure, done.

Just in case anyone wonders if one needs to ask for releasing held messages 
this way - no, the moderation queue is monitored on daily basis and appropriate 
messages are usually released within 24 hours at most. Feel free to remind me 
anyway, but it shouldn't be necessary (at least unless something wrong happens 
on my side and there's a need to involve one of the other people having 
moderation rights).

Tomas
(one of FPC mailing lists moderators)

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

Re: [fpc-devel] LEA instruction speed

[Tomas Hajny via fpc-devel]

On 2023-10-11 04:15, J. Gareth Moreton via fpc-devel wrote:

Sweet, thank you.  Would you be willing to share your modified test's
source? I was worried that if CPUID wasn't present it would cause a
SIGILL.


Sure, attached, but I didn't do anything special - I modified it in a 
way allowing easy disabling of this detection for x86 by disabling 
definition of a conditional symbol added to the source and I was 
prepared to recompile with the functionality disabled on the old AMD DX4 
if needed. However, I didn't need to do so - the AMD DX4 machine simply 
ignored it and chose the branch used in case of missing support for the 
particular CPUID function. I have no idea if this might be due to some 
protection in OS/2 Warp 4 (used for compiling and running the test on 
that machine) potentially masking that exception, or what was the 
reason. Apparently, it should be possible to detect CPUID availability 
(albeit not 100% reliably), see https://wiki.osdev.org/CPUID, but I 
didn't use that.


Tomas




On 11/10/2023 01:47, Tomas Hajny via fpc-devel wrote:

On 2023-10-10 13:24, J. Gareth Moreton via fpc-devel wrote:

I'm all for receiving results for all kinds of processor, as it helps
me to make more informed choices on flags as well as confirming that
Agner Fog''s instruction tables are correct. Also, results for older
processors can be hard to come by sometimes.

Currently, most architectures have a fast LEA, and the default
"Athlon" option lines up with this.  Of the Intel architectures, the
speed slows down on COREAVX onwards (COREI is fine), so I added a new
COREX (for 10th generation Core) option between ZEN2 and ZEN3 to mark
the point where LEA is fast again (its 16-bit version is also fast,
unlike Zen 3).

In the meantime I'll be looking at the benchmarking code that Stefan
provided to see if it can and should be integrated.

Thanks again everyone for the results you're giving.


Alright, fine (I modified your test to include the CPU name as well if 
possible and added an IFDEFed distinction of 32-bits versus 64-bits):


32-bits:
CPU = AMD A9-9425 RADEON R5, 5 COMPUTE CORES 2C+3G
-
   Pascal control case: 0.85 ns/call
 Using LEA instruction: 0.56 ns/call
Using ADD instructions: 0.84 ns/call

64-bits:
CPU = AMD A9-9425 RADEON R5, 5 COMPUTE CORES 2C+3G
-
   Pascal control case: 0.85 ns/call
 Using LEA instruction: 0.56 ns/call
Using ADD instructions: 0.85 ns/call


32-bits:
CPU = AMD Athlon(tm) Processor
--
   Pascal control case: 6.10 ns/call
 Using LEA instruction: 3.40 ns/call
Using ADD instructions: 3.40 ns/call


32-bits:
(AMD DX4 100 MHz - no CPUID name)
   Pascal control case: 123 ns/call
 Using LEA instruction: 72 ns/call
Using ADD instructions: 73 ns/call

Tomas
{ %CPU=i386,x86_64 }
program blea;

{$IF not defined(CPUX86) and not defined(CPUX86_64)}
  {$FATAL This test program requires an Intel x86 or x64 processor }
{$ENDIF}

{$MODE OBJFPC}
{$ASMMODE Intel}

{$DEFINE DETECTCPU}

uses
  SysUtils;
  
type
  TBenchmarkProc = function(const Input, X, Y: LongWord): LongWord;

var
  CPUName: array[0..48] of Char;

{$ifdef CPUX86_64}
function FillBrandName: Boolean; assembler; nostackframe;
asm
  PUSH RBX
  MOV  EAX, $8000
  CPUID
  CMP  EAX, $8004
  JB   @Unavailable
  LEA  R8,  [RIP + CPUName]
  MOV  EAX, $8002
  CPUID
  MOV  [R8], EAX
  MOV  [R8 + 4], EBX
  MOV  [R8 + 8], ECX
  MOV  [R8 + 12], EDX
  MOV  EAX, $8003
  CPUID
  MOV  [R8 + 16], EAX
  MOV  [R8 + 20], EBX
  MOV  [R8 + 24], ECX
  MOV  [R8 + 28], EDX
  MOV  EAX, $8004
  CPUID
  MOV  [R8 + 32], EAX
  MOV  [R8 + 36], EBX
  MOV  [R8 + 40], ECX
  MOV  [R8 + 44], EDX
  MOV  BYTE PTR [R8 + 48], 0
  MOV  AL,  1
  JMP  @ExitBrand
@Unavailable:
  XOR  AL,  AL
@ExitBrand:
  POP  RBX
end;
{$else CPUX86_64}
function FillBrandName: Boolean; assembler; nostackframe;
asm
{$IFDEF DETECTCPU}
  push ebx

  mov eax, $8000
  cpuid
  cmp eax, $8004
  jb @not_supported

  lea esi, CPUName

  mov eax, 8002h
  cpuid
  mov [esi], eax
  mov [esi+4], ebx
  mov [esi+8], ecx
  mov [esi+12], edx

  mov eax, 8003h
  cpuid
  mov [esi+16], eax
  mov [esi+20], ebx
  mov [esi+24], ecx
  mov [esi+28], edx

  mov eax, 8004h
  cpuid
  mov [esi+32], eax
  mov [esi+36], ebx
  mov [esi+40], ecx
  mov [esi+44], edx

  mov eax, 1
  jmp @exit

@not_supported:
  xor eax, eax

@exit:
  pop ebx
{$ELSE DETECTCPU}
  xor eax, eax
{$ENDIF DETECTPU}
end;
{$endif CPUX86_64}

function Checksum_PAS(const Input, X, Y: LongWord): LongWord;
var
  Counter: LongWord;
begin
  Result := Input;
  Counter := Y;
  while (Counter > 0) do
begin
  Result := Result + X + $87654321;
  Result := Result xor Counter;
  Dec(Counter);
end;
end;

function Checksum_ADD(const Input, X, Y: LongWord): LongWord; assembler; 
nostackframe;
asm
@Loop1:
  ADD Input, $87654321
  ADD Input, X
  XOR Input, Y
  DEC Y
  JNZ

Re: [fpc-devel] LEA instruction speed

[Tomas Hajny via fpc-devel]

On 2023-10-10 13:24, J. Gareth Moreton via fpc-devel wrote:

I'm all for receiving results for all kinds of processor, as it helps
me to make more informed choices on flags as well as confirming that
Agner Fog''s instruction tables are correct. Also, results for older
processors can be hard to come by sometimes.

Currently, most architectures have a fast LEA, and the default
"Athlon" option lines up with this.  Of the Intel architectures, the
speed slows down on COREAVX onwards (COREI is fine), so I added a new
COREX (for 10th generation Core) option between ZEN2 and ZEN3 to mark
the point where LEA is fast again (its 16-bit version is also fast,
unlike Zen 3).

In the meantime I'll be looking at the benchmarking code that Stefan
provided to see if it can and should be integrated.

Thanks again everyone for the results you're giving.


Alright, fine (I modified your test to include the CPU name as well if 
possible and added an IFDEFed distinction of 32-bits versus 64-bits):


32-bits:
CPU = AMD A9-9425 RADEON R5, 5 COMPUTE CORES 2C+3G
-
   Pascal control case: 0.85 ns/call
 Using LEA instruction: 0.56 ns/call
Using ADD instructions: 0.84 ns/call

64-bits:
CPU = AMD A9-9425 RADEON R5, 5 COMPUTE CORES 2C+3G
-
   Pascal control case: 0.85 ns/call
 Using LEA instruction: 0.56 ns/call
Using ADD instructions: 0.85 ns/call


32-bits:
CPU = AMD Athlon(tm) Processor
--
   Pascal control case: 6.10 ns/call
 Using LEA instruction: 3.40 ns/call
Using ADD instructions: 3.40 ns/call


32-bits:
(AMD DX4 100 MHz - no CPUID name)
   Pascal control case: 123 ns/call
 Using LEA instruction: 72 ns/call
Using ADD instructions: 73 ns/call

Tomas





On 10/10/2023 11:54, Tomas Hajny via fpc-devel wrote:

On 2023-10-10 12:19, Marco van de Voort via fpc-devel wrote:

Op 10-10-2023 om 11:13 schreef J. Gareth Moreton via fpc-devel:

Thanks Tomas,

Nothing is broken, but the timing measurement isn't precise enough.

Normally I have a much higher iteration count (e.g. 1,000,000), but 
I had reduced it to 10,000 because, coupled with the 1,000 
iterations in the subroutines themselves, would have led to 
1,000,000,000 passes and hence would take in the region of five to 
ten minutes to complete for a 16 MHz 386, for example.  Rika's 
suggestion of running as many iterations as needed until, say, 5 
seconds elapses, would help but the timing measurements would cause 
a lot of latency and will be imprecise on very slow routines.  
Still, let's see if 100,000 gives better results for you.



I had the same problem, and now it is stable  Ryzen 5700X (ZEN3)

   Pascal control case: 0.7 ns/call
 Using LEA instruction: 0.4 ns/call
Using ADD instructions: 0.7 ns/call


Indeed, it's much more consistent now, attached a new log for both 
32-bit and 64-bit versions from the Intel machine with Windows. 
Apparently, ADD is still somewhat faster on such "newer" Intel 
machines (at least if not considering the potential parallelism of LEA 
discussed previously). I can try this version on my AMD machines later 
tonight if considered useful - please, let me know which results would 
be relevant for you in that case (out of the ancient AMD DX4, only 
slightly less ancient AMD Athlon 1 GHz and the still rather reasonable 
AMD A9).


Tomas

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

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

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

Re: [fpc-devel] LEA instruction speed

[Tomas Hajny via fpc-devel]

On 2023-10-10 12:19, Marco van de Voort via fpc-devel wrote:

Op 10-10-2023 om 11:13 schreef J. Gareth Moreton via fpc-devel:

Thanks Tomas,

Nothing is broken, but the timing measurement isn't precise enough.

Normally I have a much higher iteration count (e.g. 1,000,000), but I 
had reduced it to 10,000 because, coupled with the 1,000 iterations in 
the subroutines themselves, would have led to 1,000,000,000 passes and 
hence would take in the region of five to ten minutes to complete for 
a 16 MHz 386, for example.  Rika's suggestion of running as many 
iterations as needed until, say, 5 seconds elapses, would help but the 
timing measurements would cause a lot of latency and will be imprecise 
on very slow routines.  Still, let's see if 100,000 gives better 
results for you.



I had the same problem, and now it is stable  Ryzen 5700X (ZEN3)

   Pascal control case: 0.7 ns/call
 Using LEA instruction: 0.4 ns/call
Using ADD instructions: 0.7 ns/call


Indeed, it's much more consistent now, attached a new log for both 
32-bit and 64-bit versions from the Intel machine with Windows. 
Apparently, ADD is still somewhat faster on such "newer" Intel machines 
(at least if not considering the potential parallelism of LEA discussed 
previously). I can try this version on my AMD machines later tonight if 
considered useful - please, let me know which results would be relevant 
for you in that case (out of the ancient AMD DX4, only slightly less 
ancient AMD Athlon 1 GHz and the still rather reasonable AMD A9).


Tomas
32-bit version, 10 runs in a row using a command shell for cycle:

   Pascal control case: 0.85 ns/call
 Using LEA instruction: 1.11 ns/call
Using ADD instructions: 0.74 ns/call
   Pascal control case: 0.95 ns/call
 Using LEA instruction: 0.95 ns/call
Using ADD instructions: 0.81 ns/call
   Pascal control case: 0.91 ns/call
 Using LEA instruction: 0.98 ns/call
Using ADD instructions: 0.83 ns/call
   Pascal control case: 0.90 ns/call
 Using LEA instruction: 1.12 ns/call
Using ADD instructions: 0.78 ns/call
   Pascal control case: 0.87 ns/call
 Using LEA instruction: 1.03 ns/call
Using ADD instructions: 0.71 ns/call
   Pascal control case: 0.87 ns/call
 Using LEA instruction: 1.03 ns/call
Using ADD instructions: 0.79 ns/call
   Pascal control case: 0.81 ns/call
 Using LEA instruction: 1.20 ns/call
Using ADD instructions: 0.92 ns/call
   Pascal control case: 0.97 ns/call
 Using LEA instruction: 1.01 ns/call
Using ADD instructions: 0.74 ns/call
   Pascal control case: 0.92 ns/call
 Using LEA instruction: 0.99 ns/call
Using ADD instructions: 0.81 ns/call
   Pascal control case: 0.90 ns/call
 Using LEA instruction: 1.00 ns/call
Using ADD instructions: 0.77 ns/call


64-bit version, 10 runs in a row using a command shell for cycle:

CPU = Intel(R) Core(TM) i5-10310U CPU @ 1.70GHz
---
   Pascal control case: 1.04 ns/call
 Using LEA instruction: 1.09 ns/call
Using ADD instructions: 0.82 ns/call
CPU = Intel(R) Core(TM) i5-10310U CPU @ 1.70GHz
---
   Pascal control case: 1.07 ns/call
 Using LEA instruction: 1.07 ns/call
Using ADD instructions: 0.71 ns/call
CPU = Intel(R) Core(TM) i5-10310U CPU @ 1.70GHz
---
   Pascal control case: 0.98 ns/call
 Using LEA instruction: 1.07 ns/call
Using ADD instructions: 0.80 ns/call
CPU = Intel(R) Core(TM) i5-10310U CPU @ 1.70GHz
---
   Pascal control case: 1.11 ns/call
 Using LEA instruction: 1.09 ns/call
Using ADD instructions: 0.75 ns/call
CPU = Intel(R) Core(TM) i5-10310U CPU @ 1.70GHz
---
   Pascal control case: 0.98 ns/call
 Using LEA instruction: 1.02 ns/call
Using ADD instructions: 0.78 ns/call
CPU = Intel(R) Core(TM) i5-10310U CPU @ 1.70GHz
---
   Pascal control case: 1.09 ns/call
 Using LEA instruction: 1.13 ns/call
Using ADD instructions: 0.69 ns/call
CPU = Intel(R) Core(TM) i5-10310U CPU @ 1.70GHz
---
   Pascal control case: 0.98 ns/call
 Using LEA instruction: 1.11 ns/call
Using ADD instructions: 0.81 ns/call
CPU = Intel(R) Core(TM) i5-10310U CPU @ 1.70GHz
---
   Pascal control case: 0.95 ns/call
 Using LEA instruction: 1.07 ns/call
Using ADD instructions: 0.71 ns/call
CPU = Intel(R) Core(TM) i5-10310U CPU @ 1.70GHz
---
   Pascal control case: 1.04 ns/call
 Using LEA instruction: 1.01 ns/call
Using ADD instructions: 0.70 ns/call
CPU = Intel(R) Core(TM) i5-10310U CPU @ 1.70GHz
---
   Pascal control case: 1.05 ns/call
 Using LEA instruction: 0.99 ns/call
Using ADD instructions: 0.71 ns/call
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org

Re: [fpc-devel] LEA instruction speed

[Tomas Hajny via fpc-devel]

On 2023-10-09 20:51, J. Gareth Moreton via fpc-devel wrote:


Hi Kit,


I updated the "blea" test in the merge request so it now displays the
processor brand name on x86_64; however, it is not fetched under i386
because CPUID was not introduced until later 486 processors.  I've
attached it to this e-mail if anyone wants to take a look to ensure I
haven't broken something.


I don't know what's broken, but the results vary so much on a fast 
machine that they are unusable for any measurement from my point of view 
(standard 3.2.2 compiler, compiled with -O4 and running under MS Windows 
this time). Sometimes the ADD version shows 0.0 ns/call, sometimes the 
LEA version shows 0.0 ns/call (32-bits) or 0.1 ns/call (64-bits). See 
the attached results (the CPU is only displayed for the 64-bit 
compilation, but it's obviously the same CPU).


Tomas




On 09/10/2023 18:01, J. Gareth Moreton via fpc-devel wrote:
Thank you very much!  That processor is built on the Excavator 
architecture and lines up with the flag I put in the merge request 
(i.e. it has the "fast LEA" hint).


I honestly didn't expect this much testing feedback, so thank you all!

Gareth aka. Kit

P.S. I'm tempted to extend the test slightly to actually name the CPU 
automatically.


On 09/10/2023 15:40, Jean SUZINEAU via fpc-devel wrote:

My results:
jean@First-Boss:~/temp$ cat /proc/cpuinfo | grep "model name"
model name    : AMD A6-7480 Radeon R5, 8 Compute Cores 2C+6G
jean@First-Boss:~/temp$ /usr/bin/fpc blea.pp
Free Pascal Compiler version 3.2.2 [2021/07/09] for x86_64
Copyright (c) 1993-2021 by Florian Klaempfl and others
Target OS: Linux for x86-64
Compiling blea.pp
Linking blea
95 lines compiled, 0.2 sec
jean@First-Boss:~/temp$ ./blea
   Pascal control case: 5.1 ns/call
 Using LEA instruction: 0.5 ns/call
Using ADD instructions: 0.8 ns/call
jean@First-Boss:~/temp$

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


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


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
32-bit version, 10 runs in a row using a command shell for cycle, LEA before 
ADD (original version):

   Pascal control case: 0.9 ns/call
 Using LEA instruction: 0.0 ns/call
Using ADD instructions: 1.6 ns/call
   Pascal control case: 0.4 ns/call
 Using LEA instruction: 1.5 ns/call
Using ADD instructions: 0.0 ns/call
   Pascal control case: 0.1 ns/call
 Using LEA instruction: 1.6 ns/call
Using ADD instructions: 1.2 ns/call
   Pascal control case: 0.2 ns/call
 Using LEA instruction: 1.8 ns/call
Using ADD instructions: 0.0 ns/call
   Pascal control case: 0.2 ns/call
 Using LEA instruction: 1.0 ns/call
Using ADD instructions: 1.6 ns/call
   Pascal control case: 0.2 ns/call
 Using LEA instruction: 1.6 ns/call
Using ADD instructions: 0.0 ns/call
   Pascal control case: 0.2 ns/call
 Using LEA instruction: 1.8 ns/call
Using ADD instructions: 0.0 ns/call
   Pascal control case: 0.1 ns/call
 Using LEA instruction: 1.6 ns/call
Using ADD instructions: 0.8 ns/call
   Pascal control case: 1.1 ns/call
 Using LEA instruction: 0.1 ns/call
Using ADD instructions: 1.6 ns/call
   Pascal control case: 0.2 ns/call
 Using LEA instruction: 1.5 ns/call
Using ADD instructions: 0.0 ns/call


32-bit version, 10 runs in a row using a command shell for cycle, LEA before 
ADD (original version):

   Pascal control case: 0.9 ns/call
 Using LEA instruction: 0.0 ns/call
Using ADD instructions: 1.6 ns/call
   Pascal control case: 0.4 ns/call
 Using LEA instruction: 1.5 ns/call
Using ADD instructions: 0.0 ns/call
   Pascal control case: 0.1 ns/call
 Using LEA instruction: 1.6 ns/call
Using ADD instructions: 1.2 ns/call
   Pascal control case: 0.2 ns/call
 Using LEA instruction: 1.8 ns/call
Using ADD instructions: 0.0 ns/call
   Pascal control case: 0.2 ns/call
 Using LEA instruction: 1.0 ns/call
Using ADD instructions: 1.6 ns/call
   Pascal control case: 0.2 ns/call
 Using LEA instruction: 1.6 ns/call
Using ADD instructions: 0.0 ns/call
   Pascal control case: 0.2 ns/call
 Using LEA instruction: 1.8 ns/call
Using ADD instructions: 0.0 ns/call
   Pascal control case: 0.1 ns/call
 Using LEA instruction: 1.6 ns/call
Using ADD instructions: 0.8 ns/call
   Pascal control case: 1.1 ns/call
 Using LEA instruction: 0.1 ns/call
Using ADD instructions: 1.6 ns/call
   Pascal control case: 0.2 ns/call
 Using LEA instruction: 1.5 ns/call
Using ADD instructions: 0.0 ns/call


64-bit version, 10 runs in a row using a command shell for cycle, LEA before 
ADD (original version):

CPU = Intel(R) Core(TM) i5-10310U CPU @ 1.70GHz
---
   Pascal control case: 0.6 ns/call
 Using LEA instruction: 

Re: [fpc-devel] LEA instruction speed

[Tomas Hajny via fpc-devel]

On 2023-10-08 13:45, J. Gareth Moreton via fpc-devel wrote:



Sorry, ignore last attachment - I forgot to change a line of assembly
(it was correct for x86_64-win64!!). Here is the corrected version.


Alright, results for this version for AMD A9 9425 under Linux (the same 
trunk compiler as used yesterday):


64-bit version:

   Pascal control case: 5.1 ns/call
 Using LEA instruction: 0.5 ns/call
Using ADD instructions: 0.9 ns/call


32-bit version:

   Pascal control case: 0.9 ns/call
 Using LEA instruction: 0.5 ns/call
Using ADD instructions: 0.9 ns/call

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

Re: [fpc-devel] LEA instruction speed

[Tomas Hajny via fpc-devel]

On 2023-10-07 18:09, J. Gareth Moreton via fpc-devel wrote:

That's interesting; I am interested to see the assembly output for the
Pascal control cases.  As for the 64-bit version, that was my fault
since the assembly language is for Microsoft's ABI rather than the
System V ABI, so it was checking a register with an undefined value. 
Find attached the fixed test.

Kit

P.S. Results on my Intel(R) Core(TM) i7-10750H

   Pascal control case: 2.0 ns/call
 Using LEA instruction: 1.7 ns/call
Using ADD instructions: 1.3 ns/call


OK. My results for the AMD A9 CPU mentioned previously and 32-bit trunk 
compiler (Linux) are:


   Pascal control case: 2.3 ns/call
 Using LEA instruction: 1.2 ns/call
Using ADD instructions: 1.5 ns/call


The same machine, the same operating environment, but a 64-bit trunk 
compiler:


   Pascal control case: 3.6 ns/call
 Using LEA instruction: 0.9 ns/call
Using ADD instructions: 1.3 ns/call


I tried compiling and running the test with all of FPC 2.0.4, 2.2.4, 
2.4.4, 2.6.4, 3.0.4 and 3.2.2 on my Athlon machine and realized that all 
results (for both the assembler and Pascal versions) compiled with 
anything older than 3.2.2 are an order of magnitude faster than with 
3.2.2 (i.e. less than 1 ns/call for the older versions compared to 8 
ns/call with Pascal / 4 ns/call with assembler versions). This means 
that the comparison is obviously spoiled with something unrelated. 
Moreover, I noticed that when compiling with the highest level of 
optimizations, the Pascal version compiled for i386 is as fast or even 
little bit faster than the assembler version. I didn't do that 
previously, thus the longer time for the older compiler version probably 
isn't relevant. From this point of view, it probably doesn't make sense 
to spend time on comparing the generated code.


Tomas




On 07/10/2023 16:51, Tomas Hajny via fpc-devel wrote:

On 2023-10-07 03:57, J. Gareth Moreton via fpc-devel wrote:


Hi Kit,


Do you think this should suffice? Originally it ran for 1,000,000
repetitions but I fear that will take way too long on a 486, so I
reduced it to 10,000.


OK, I tried it now. First of all, after turning on the old machine, I 
realized that it wasn't Intel but AMD 486 DX4 - sorry for my bad 
memory. :-( I compiled and ran the test under OS/2 there (I was too 
lazy to boot it to DOS ;-) ), but I assume that it shouldn't make any 
substantial difference. The ADD and LEA results were basically the 
same there, both around 100 ns / call. The Pascal result was around 
twice as long. Interestingly, the Pascal result for FPC 3.2.2 was 
around 10% longer than the same source compiled with FPC 2.0.3 (the 
assembler versions were obviously the same for both FPC versions; I 
tried compiling it also with FPC 1.0.10 and the assembler versions 
were more than three times slower due to missing support for the 
nostackframe directive).


I tested it under the AMD Athlon 1 GHz machine as well and again, the 
results for LEA and ADD are basically equal (both 3.1 ns/call) and the 
result for Pascal slightly more than twice (7.3 ns/call). However, 
rather surprisingly for me, the overall test run was _much_ longer 
there?! Finally, I tried compiling the test on a 64-bit machine (AMD 
A9-9425) with Linux (compiled for 64-bits with FPC 3.2.3 compiled from 
a fresh 3.2 branch). The Pascal version shows about 4 ns/call, but the 
assembler version runs forever - well, certainly much longer than my 
patience lasts. I haven't tried to analyze the reasons, but that's 
what I get.


Tomas





On 03/10/2023 06:30, Tomas Hajny via fpc-devel wrote:
On October 3, 2023 03:32:34 +0200, "J. Gareth Moreton via fpc-devel" 
 wrote:



Hii Kit,

This is mainly to Florian, but also to anyone else who can answer 
the question - at which point did a complex LEA instruction (using 
all three input operands and some other specific circumstances) get 
slow? Preliminary research suggests the 486 was when it gained 
extra latency, and then Sandy Bridge when it got particularly bad.  
Icy Lake seems to be the architecture where faster LEA instructions 
are reintroduced, but I'm not sure about AMD processors.
I cannot answer your question, but if you prepare a test program, I 
can run it on an Intel 486 DX2 100 Mhz and AMD Athlon 1 GHz machines 
if it helps you in any way (at least I hope the 486 DX2 machine 
should be still able to start ;-) ).


Tomas

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


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

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


___
fpc-devel maillist  - 

Re: [fpc-devel] LEA instruction speed

[Tomas Hajny via fpc-devel]

On 2023-10-07 03:57, J. Gareth Moreton via fpc-devel wrote:


Hi Kit,


Do you think this should suffice? Originally it ran for 1,000,000
repetitions but I fear that will take way too long on a 486, so I
reduced it to 10,000.


OK, I tried it now. First of all, after turning on the old machine, I 
realized that it wasn't Intel but AMD 486 DX4 - sorry for my bad memory. 
:-( I compiled and ran the test under OS/2 there (I was too lazy to boot 
it to DOS ;-) ), but I assume that it shouldn't make any substantial 
difference. The ADD and LEA results were basically the same there, both 
around 100 ns / call. The Pascal result was around twice as long. 
Interestingly, the Pascal result for FPC 3.2.2 was around 10% longer 
than the same source compiled with FPC 2.0.3 (the assembler versions 
were obviously the same for both FPC versions; I tried compiling it also 
with FPC 1.0.10 and the assembler versions were more than three times 
slower due to missing support for the nostackframe directive).


I tested it under the AMD Athlon 1 GHz machine as well and again, the 
results for LEA and ADD are basically equal (both 3.1 ns/call) and the 
result for Pascal slightly more than twice (7.3 ns/call). However, 
rather surprisingly for me, the overall test run was _much_ longer 
there?! Finally, I tried compiling the test on a 64-bit machine (AMD 
A9-9425) with Linux (compiled for 64-bits with FPC 3.2.3 compiled from a 
fresh 3.2 branch). The Pascal version shows about 4 ns/call, but the 
assembler version runs forever - well, certainly much longer than my 
patience lasts. I haven't tried to analyze the reasons, but that's what 
I get.


Tomas





On 03/10/2023 06:30, Tomas Hajny via fpc-devel wrote:
On October 3, 2023 03:32:34 +0200, "J. Gareth Moreton via fpc-devel" 
 wrote:



Hii Kit,

This is mainly to Florian, but also to anyone else who can answer the 
question - at which point did a complex LEA instruction (using all 
three input operands and some other specific circumstances) get 
slow?  Preliminary research suggests the 486 was when it gained extra 
latency, and then Sandy Bridge when it got particularly bad.  Icy 
Lake seems to be the architecture where faster LEA instructions are 
reintroduced, but I'm not sure about AMD processors.
I cannot answer your question, but if you prepare a test program, I 
can run it on an Intel 486 DX2 100 Mhz and AMD Athlon 1 GHz machines 
if it helps you in any way (at least I hope the 486 DX2 machine should 
be still able to start ;-) ).


Tomas

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


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

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

Re: [fpc-devel] LEA instruction speed

[Tomas Hajny via fpc-devel]

On October 3, 2023 03:32:34 +0200, "J. Gareth Moreton via fpc-devel" 
 wrote:


Hii Kit,

>This is mainly to Florian, but also to anyone else who can answer the question 
>- at which point did a complex LEA instruction (using all three input operands 
>and some other specific circumstances) get slow?  Preliminary research 
>suggests the 486 was when it gained extra latency, and then Sandy Bridge when 
>it got particularly bad.  Icy Lake seems to be the architecture where faster 
>LEA instructions are reintroduced, but I'm not sure about AMD processors.

I cannot answer your question, but if you prepare a test program, I can run it 
on an Intel 486 DX2 100 Mhz and AMD Athlon 1 GHz machines if it helps you in 
any way (at least I hope the 486 DX2 machine should be still able to start ;-) 
).

Tomas

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

Re: [fpc-devel] fpc compiler wrong encoding in console output on Windows

[Tomas Hajny via fpc-devel]

On 2023-08-31 18:19, Ondrej Pokorny via fpc-devel wrote:

On 31.08.2023 17:54, Tomas Hajny via fpc-devel wrote:

 .
 .
2) Always use the ansistring version when parsing the comments. 
Obviously, this increases compilation time for directives parsing 
somewhat - we could possibly measure the impact and then decide if the 
increase is important.


That is actually what I started with. Then I saw that there are some
parts of the code that demand ShortString output and decided to keep
both versions.

But basically it is possible to have the 2 ShortString variants use
the new Long variants + check the Length and valid characters (to me

 .
 .

Yes, that's what I meant by option 2 - I realize that most cases need to 
end up in shortstrings anyway.




Or the bigger step would be to make the compiler unicode-ready:

var
  ä: string;

+ file names, paths etc.

Then only the new Long variant would be needed :)


Apparently not only the compiler Unicode-ready, but also the language. 
Looking forward to identifiers looking like characters having specific 
meaning in Pascal, but differing in their Unicode codes (e.g. m-dash). 
Or maybe rather not... I'm sure it would be a good approach to provide 
enough room for compilers of some other languages to finish their 
compilation in time comparable to FPC... ;-)


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

Re: [fpc-devel] fpc compiler wrong encoding in console output on Windows

[Tomas Hajny via fpc-devel]

On 2023-08-31 17:08, Ondrej Pokorny via fpc-devel wrote:
 .
 .

:) We are not at the finish yet. Positive outcome will be when it gets
fixed in the compiler source.


Yes, I know. I checked your patch briefly now and I don't like the fact 
that it basically duplicates the code of the two original TScannerFile 
methods. This isn't very good from maintainability point of view, 
because if somebody changes/fixes some issue in one, (s)he may easily 
forget about the other. I see several potential solutions:


1) Keep the original methods and perform codepage translation only in 
dir_message. I understand that it keeps the current limitation of the 
message length (which may lead to broken UTF-8 string among others), but 
it's questionable whether that really matters, IMHO, or whether it could 
just be documented as a limitation.


2) Always use the ansistring version when parsing the comments. 
Obviously, this increases compilation time for directives parsing 
somewhat - we could possibly measure the impact and then decide if the 
increase is important.


3) Find some smart way how to share the same code for both ansistring 
and shortstring version (preferably without generics ;-) ). I don't know 
if this option is feasible, but it might be a good one if so.


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

Re: [fpc-devel] fpc compiler wrong encoding in console output on Windows

[Tomas Hajny via fpc-devel]

On 2023-08-30 23:38, Ondrej Pokorny via fpc-devel wrote:

Am 30.08.2023 um 20:21 schrieb Ondrej Pokorny via fpc-devel:


 .
 .
Having seen the outputs, I think that the compiler just ignores the 
source file encoding for {$MESSAGE} and {$NOTE}. It reads them always 
as ANSI and then converts them to DOS-whatever.


That would explain why UTF-8 byte stream is encoded into DOS CP.

So the fix should be quite easy - when {$MESSAGE} or {$NOTE} is read 
into a string, set the correct codepage of the string.


I was correct in my assumption and I was able to fix it:
https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/482

On the other hand, when I read the $CODEPAGE docs:
https://www.freepascal.org/docs-html/prog/progsu87.html#x95-940001.3.4
There it is stated that only literal strings follow $CODEPAGE and the
actual code must be in US-ASCII.

But you know: Delphi compatibility :) ...and there is no "illegal
character" compiler error as it is for:

var
  ä: string;

so one would expect {$note ä} to show up correctly.


Indeed. I'm glad that our discussion (although triggered by my mistake 
:-( ) led to a positive outcome at last. :-)


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

Re: [fpc-devel] fpc compiler wrong encoding in console output on Windows

[Tomas Hajny via fpc-devel]

On 2023-08-30 17:23, Ondrej Pokorny via fpc-devel wrote:

 .
 .

Sorry to bother you with something as trivial: is your t2.pas file
really encoded in UTF-8?

Because if I compile an ANSI file with the {$codepage utf8}
declaration, then I get "correct" output. But obviously this is very
wrong.

You can try yourself with the attached files. So maybe this is your 
mistake?


Well, you're right, this was indeed my mistake, shame on me. :-( Then I 
can confirm that the compiler behaviour is indeed wrong (although I have 
no clue why it behaves that way).


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

Re: [fpc-devel] fpc compiler wrong encoding in console output on Windows

[Tomas Hajny via fpc-devel]

On 2023-08-30 17:12, Ondrej Pokorny wrote:

On 30.08.2023 17:04, Tomas Hajny via fpc-devel wrote:



(only sent to Ondrej instead of the list by mistake, resending it to the 
list now)


 .
 .
Interesting, but it doesn't change anything on the fact that my result 
is different (and correct) and I don't think that my configuration is 
special in any way...


Yes, it is strange. Mattias and Zeljko have the same output like me
(Zeljko wrote about it in the Lazarusdev mailing list). So, currently
you are the only one with different result from a group of 4 people
involved in the same test :)


I'm the only one of those 4 not involved in Lazarus. ;-) On the other 
hand, I wasn't involved in the base RTL codepage handling implementation 
for Windows at all, i.e. it isn't like that I implemented something in a 
way only working correctly on my configuration or so.



Could you please change my test program sent earlier by changing 
"WriteLn (GetConsoleCP);" to "WriteLn (GetConsoleOutputCP);" recompile 
and check output of that one (GetConsoleCP is not useful in this 
context, that was my fault :-( ) - just in case?


GetConsoleOutputCP = GetConsoleCP = 850 on my system.


OK. Please, test it also the way I suggested earlier, i.e. from within 
Lazarus by pretending that it's the compiler (Mattias already wrote that 
he ran the program from command line, but I'd like to make sure that 
there's no difference triggered by Lazarus when running the compiler 
from it).


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

Re: [fpc-devel] fpc compiler wrong encoding in console output on Windows

[Tomas Hajny via fpc-devel]

On 2023-08-30 16:32, Ondrej Pokorny via fpc-devel wrote:
 .
 .

If you mean
https://stackoverflow.com/questions/56419639/what-does-beta-use-unicode-utf-8-for-worldwide-language-support-actually-do,
then no, I don't have this option checked. However, even if I had it
checked (I don't), it couldn't make a difference, because I didn't
rely on the output displayed on console, but I actually checked the
codepage of the compiler output by redirecting it to a file and
checking the content of that file as well.

So did I:

See output.txt in the attachment. It is the output from redirection
with "> output.txt". The output is double-encoded on my system (UTF-8
as CP-850) - it means I have to convert it first from CP-850 to ANSI,
then I see correct raw UTF-8 byte stream.


Interesting, but it doesn't change anything on the fact that my result 
is different (and correct) and I don't think that my configuration is 
special in any way...


Could you please change my test program sent earlier by changing 
"WriteLn (GetConsoleCP);" to "WriteLn (GetConsoleOutputCP);" recompile 
and check output of that one (GetConsoleCP is not useful in this 
context, that was my fault :-( ) - just in case?


Do you get a different behaviour if using a stock 3.2.2 compiler (the 
one distributed by the FPC team, not a Lazarus distribution)?


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

Re: [fpc-devel] passing unicode seach paths on windows

[Tomas Hajny via fpc-devel]

On 2023-08-30 13:56, Mattias Gaertner via fpc-devel wrote:

Hi,

How to pass unicode search paths to fpc?

For example when passing a -Fu as UTF8 via a config file "@my.cfg", fpc 
says:

Path: "C:\pascal\...gibberish..." not found

Is there some flag I'm missing or does fpc not support unicode search
paths on windows?

Tested with 3.2.2 and 3.3.1.


First of all, I don't think that the compiler supports reading 
configuration files (search paths or whatever else) in a different 
codepage than the current ACP. Since that won't be UTF-8 on MS Windows, 
this is not supported. As far as I know, -Fc... is used only for source 
files, not for configuration files, and it's probably more appropriate 
that way. It might be possible to add special support for recognizing 
the BOMs and use that for deciding on the format, but nothing like that 
has been implemented yet for the compiler according to my knowledge.


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

Re: [fpc-devel] fpc compiler wrong encoding in console output on Windows

[Tomas Hajny via fpc-devel]

On 2023-08-30 15:26, Ondrej Pokorny via fpc-devel wrote:

On 30.08.2023 13:49, Mattias Gaertner via fpc-devel wrote:

On 30.08.23 12:04, Tomas Hajny via fpc-devel wrote:

On 2023-08-28 15:53, Ondrej Pokorny via fpc-devel wrote:
[...]
Your output is different from mine (using a freshly compiled trunk 
compiler):

Free Pascal Compiler version 3.3.1 [2023/08/29] for i386
Copyright (c) 1993-2023 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling t2.pas
t2.pas(4,2) Note: User defined: ä


Then you don't have default windows setup. Maybe you installed the cp 
65001?


Yes, Tomas, in other words: maybe you enabled "Beta support for UTF-8"
in language options on your Windows?


If you mean 
https://stackoverflow.com/questions/56419639/what-does-beta-use-unicode-utf-8-for-worldwide-language-support-actually-do, 
then no, I don't have this option checked. However, even if I had it 
checked (I don't), it couldn't make a difference, because I didn't rely 
on the output displayed on console, but I actually checked the codepage 
of the compiler output by redirecting it to a file and checking the 
content of that file as well.



 .
 .

(437 is DOS-US, 850 is DOS-Latin-1)

https://en.wikipedia.org/wiki/Code_page_437
https://en.wikipedia.org/wiki/Code_page_850


Thanks, but I'm quite well aware of the codepage stuff... ;-) (including 
ISO, Mac codepages, DBCS codepages, EBCDIC codepages, non-standard / 
custom codepages created in some Central and East European countries for 
better support of their local languages, etc.)


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

Re: [fpc-devel] fpc compiler wrong encoding in console output on Windows

[Tomas Hajny via fpc-devel]

On 2023-08-30 13:49, Mattias Gaertner via fpc-devel wrote:

On 30.08.23 12:04, Tomas Hajny via fpc-devel wrote:

On 2023-08-28 15:53, Ondrej Pokorny via fpc-devel wrote:
[...]
Your output is different from mine (using a freshly compiled trunk 
compiler):

Free Pascal Compiler version 3.3.1 [2023/08/29] for i386
Copyright (c) 1993-2023 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling t2.pas
t2.pas(4,2) Note: User defined: ä


Then you don't have default windows setup. Maybe you installed the cp 
65001?


Default setup of what exactly? I didn't install anything special, but my 
MS Windows installation indeed supports CP 65001. I guess that it may be 
different for different MS Windows versions - specifically, I tested it 
on MS Windows 10 Enterprise version 22H2. However, that shouldn't make a 
difference, because Ondrej stated that he gets compiler output in UTF-8, 
but I also tried redirecting the output to a file and the result is in 
CP852 which is my default "ANSI" codepage (and thus also the default 
console codepage). There's no place where UTF-8 availability might 
change the result in this. However, I _didn't_ test it under Lazarus. I 
suspect that Lazarus messing with the codepages may change the behaviour 
by changing either the system codepage or console codepage to UTF-8 and 
this then results in compiler emitting output in this different codepage 
(i.e. UTF-8).




[...]
However, I run the compiler from regular command line, not from 
Lazarus.


I get the same in cmd.exe and via TProcess.


I.e. you open cmd.exe e.g. via the Windows key+R (rather than by 
shelling from Lazarus)?



[...] What do you get when running the following test program (you can 
simulate the same conditions e.g. by naming the resulting binary 
fpc.exe and configuring Lazarus to use this "compiler"):


uses
  Windows;
begin
  WriteLn (GetACP);
  WriteLn (GetConsoleCP);


ACP is 1252
ConsoleCP 437


Just to be sure - you get this when running the test from Lazarus as a 
"compiler" (as suggested in my note above)?


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

Re: [fpc-devel] fpc compiler wrong encoding in console output on Windows

[Tomas Hajny via fpc-devel]

On 2023-08-28 15:53, Ondrej Pokorny via fpc-devel wrote:


Hello Ondrej,


when compiling a program with fpc on Windows, fpc seems to have the
console output encoding wrong.

Example program (I am using "ä" because I am on german OS, so "ä" is
in my DOS Latin and also in my ANSI codepage):

{$codepage utf8}
program TestNote;
begin
{$note ä}
end.

The console output is:

Free Pascal Compiler version 3.3.1 [2023/08/21] for i386
Copyright (c) 1993-2023 by Florian Klaempfl and others
(1002) Target OS: Win32 for i386
(3104) Compiling TestNote.lpr
p:\programs\_zk\TestNote\TestNote.lpr(6,2) Note: (2025) User defined: 
ä
(9015) Linking 
P:\programs\_zk\TestNote\lib\Debug\i386-win32\TestNote.exe

(1008) 8 lines compiled, 0.1 sec, 78736 bytes code, 2148 bytes data
(1022) 2 hint(s) issued
(1023) 1 note(s) issued

So it looks like the FPC compiler output is raw utf-8 instead of DOS
Latin codepage. Is this wanted?

 .
 .

Your output is different from mine (using a freshly compiled trunk 
compiler):


Free Pascal Compiler version 3.3.1 [2023/08/29] for i386
Copyright (c) 1993-2023 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling t2.pas
t2.pas(4,2) Note: User defined: ä
Linking t2.exe
5 lines compiled, 0.0 sec, 38160 bytes code, 1412 bytes data
1 note(s) issued


However, I run the compiler from regular command line, not from Lazarus. 
What do you get when running the following test program (you can 
simulate the same conditions e.g. by naming the resulting binary fpc.exe 
and configuring Lazarus to use this "compiler"):


uses
 Windows;
begin
 WriteLn (GetACP);
 WriteLn (GetConsoleCP);
end.

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

[fpc-devel] Function for translation "normalized" Unicode strings into strings with composed characters?

[Tomas Hajny via fpc-devel]

Hi *,

Do we have a function in FPC RTL or packages allowing to translate a 
string containing letters followed with standalone combining characters 
(diacritics) into the combined alternatives? I assume that the necessary 
information is available in the UnicodeData unit, thus an alternative 
might be using information from this unit if no readily available 
function is available, but I wouldn't know where exactly this 
information is and how to use it anyway at the moment. :-(


Thanks in advance

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

Re: [fpc-devel] BUG REPORT: Fail to compile when using the out keyword instead of var

[Tomas Hajny via fpc-devel]

On 2023-06-19 09:25, Michael Van Canneyt via fpc-devel wrote:

On Sun, 18 Jun 2023, Dylan Lamb via fpc-devel wrote:


[image: fpcbug.png]



This is not a bug. You're using mode fpc, in which the "out" keyword is 
not

supported. You have 3 possibilities to activate this:

 .
 .

One additional minor comment to the original e-mail - in general, it's 
better to send sample code as text rather than a screenshot, because the 
text version allows reproducing your situation and proposing alternative 
versions more easily, whereas the screenshot requires retyping your test 
program. Obviously, copying the compiler output as simple text is 
possible as well, but that isn't that important here (it would decrease 
the size of your e-mail, which might still make sense in case of a 
message sent to hundreds of people via the mailing list, but the size 
wasn't that big measured by today's e-mail "standards").


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

Re: [fpc-devel] Question on constref

[Tomas Hajny via fpc-devel]

On 2023-02-01 15:40, Hairy Pixels via fpc-devel wrote:
On Feb 1, 2023, at 8:27 PM, Michael Van Canneyt via fpc-devel 
 wrote:


That's exactly what Adriaan is saying. With const the compiler can 
choose.
With constref, you force it not to copy. But this is not so efficient 
for

small parameter sizes.


So const will always pass records that are over a certain size by
references? That’s good to know since “const” is more pleasant to look
at it than constref. :)


As written above, the compiler can choose with const (and the choice may 
differ for different CPUs and other factors), i.e. you shouldn't make 
assumptions / rely on const of particular size to be passed by 
reference.


Tomas
___
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

[Tomas Hajny via fpc-devel]

On 2023-01-13 11:22, Mattias Gaertner via fpc-devel wrote:

On Sun, 8 Jan 2023 08:46:37 +0100 (CET)
Michael Van Canneyt via fpc-devel 
wrote:


[...]
Should have been

make install SUB_TARGET=unicodertl PP=path/to/the/new/compiler


This does not install the new compiler, so I used the compiler/ppcx64
exe directly to compile a program.

I see in the -va output:
[0.008] Hint: Start of reading config file /etc/fpc-unicodertl.cfg
[0.008] Handling option "-dUNICODERTL"
[0.008] Interpreting option "-dUNICODERTL"
[0.008] Macro defined: UNICODERTL
[0.008] Handling option "-Municodestrings"
[0.008] Interpreting option "-Municodestrings"
[0.008] Macro defined: FPC_UNICODESTRINGS
[0.008] Macro defined: UNICODE
[0.008] Hint: End of reading config file /etc/fpc-unicodertl.cfg

But then it uses the wrong unit paths:
[0.012] Using unit path: /usr/lib/fpc/3.3.1/units/x86_64-linux/httpd22/

It should be:

[0.012] Using unit path:
/usr/lib/fpc/3.3.1/units/x86_64-linux-unicodertl/rtl/

My /etc/fpc.cfg contains:

# searchpath for units and other system dependent things
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/*
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/rtl


What does your /etc/fpc-unicodertl.cfg contain? The correct paths should 
be there...


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

Re: [fpc-devel] Just need to double check the size of Integer

[Tomas Hajny via fpc-devel]

On 2022-11-24 14:25, Ondrej Pokorny via fpc-devel wrote:

Am 24.11.2022 um 14:15 schrieb Marco van de Voort via fpc-devel:

On 24-11-2022 14:13, J. Gareth Moreton via fpc-devel wrote:


I just need to double-check something.  Under CPU16, SizeInt and 
SizeUInt are declared as follows:


  SizeInt = Integer;
  SizeUInt = Word;

Is Integer 16-bit in this case?


Yes.


Are you sure? systemh.inc is compiled with {$mode objfpc} (see line
22), so Integer within the system unit is 32-bit.

So to me it looks like a bug.


No, it isn't a bug - systemh.inc is indeed compiled in $MODE OBJFPC 
nowadays, but it defines Integer = SmallInt on line 110. Depending on 
compilation mode used for your sources (containing references to 
Integer), the definition in unit objpas (included automatically for 
modes objfpc and delphi) may override the definition in systemh.inc.


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

Re: [fpc-devel] Just need to double check the size of Integer

[Tomas Hajny via fpc-devel]

On 2022-11-24 14:13, J. Gareth Moreton via fpc-devel wrote:


Hi Kit,


I just need to double-check something.  Under CPU16, SizeInt and
SizeUInt are declared as follows:

  SizeInt = Integer;
  SizeUInt = Word;

Is Integer 16-bit in this case? I always thought Integer was defined
as a signed 32-bit integer under FreePascal.  Or is this a bug with
rtl/inc/systemh.inc and it should be defined as SmallInt instead?


You're wrong. The size of Integer depends on the compilation mode. It is 
16-bit in the TP and FPC modes, but overridden to 32-bit in OBJPAS and 
DELPHI modes.


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

Re: [fpc-devel] Questions about cross-compiling (z80)

[Tomas Hajny via fpc-devel]

On 2022-02-11 14:14, Sven Barth via fpc-devel wrote:

BogDan via fpc-devel  schrieb am Fr.,
11. Feb. 2022, 11:09:


 .
 .

It seems is an IHX format not tzx
Also the result for a simple hello world is way too big (over 20k) !
I assume that I'm passing wrong params to ppcrossz80. What params
should I use? Where I can find more info on this matter?


You need to make sure that the ihxutil built in
utils/ihxutil/-/ is available in PATH, so that the
compiler will do the conversion.


@Sven: Sorry for a silly question, but shouldn't the compiler emit some 
error message if the tool isn't available?




2. Is it possible to add z80 cross compilation target to FP IDE? The
FP IDe shows me a few targets, but z80 is not there.


The text mode IDE can only ever compile for one CPU platform, so you
need to build it for Z80. Though I don't know right now whether this
is enabled.


Just for clarification of the original poster - Sven means building the 
IDE for _compilation_ for Z80 (not that the IDE should run on Z80). 
Nevertheless, even that isn't supported right now at the moment - as of 
now, there's support only for x86 and m68k architectures within this 
IDE. It might be possible to add support for other targets as well, but 
it would require some effort.


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

Re: [fpc-devel] Questions regarding m68k-atari target

[Tomas Hajny via fpc-devel]

On 2022-02-01 06:02, Thorsten Otto via fpc-devel wrote:

On Samstag, 29. Januar 2022 16:03:32 CET Tomas Hajny via fpc-devel
wrote:


does it return individual characters, or does it
return the whole line at once (the latter being the case for other FPC
targets as far as I know)?


Just tried with a small test program, and the behaviour is a bit
strange. Fread(0, count, buf) returns when you either press return, or
the count has been reached. However, if you press return, the return
value does not include the CR, nor is that CR written to the buffer.


Right, I expected something like that based on the described behaviour. 
Is the pressed CR never returned then, or is it returned in a following 
fread call?




The Window ReadFile function behaves totally differently there. It
only returns when you press enter, and the buffer and count includes a
CR/LF.


Indeed, that's what I already mentioned. Moreover, the ReadFile function 
on Windows (and similarly the respective equivalents on various other 
platforms) doesn't even allow the user to enter more characters than the 
buffer length _minus_space_for_the_terminating_end_of_line_marker_ when 
reading from console (not necessarily when reading from standard input - 
if the standard input is redirected and gets input from a file, more 
characters are accepted). In other words, reading characters (pressed 
keys) stops when reaching character 253 and nothing except the Enter key 
is accepted (and the Enter key is then stored as #13 and #10 to the end 
of the buffer as correctly mentioned by you). I'm afraid that the 
observed behaviour of fread suggests that you need to modify the do_read 
implementation for atari to do the same if reading from console - in 
other words, you need to call fread with one less character in "len" in 
that case (and add it to the end of the buffer being returned from 
do_read afterwards).


BTW, be careful about distinction between the standard input handle and 
input from console unless either no redirection of input is possible, or 
the handle of such an input changes to a different value in that case 
(as of now, the implementation of do_isdevice for atari works only with 
the handle number rather than checking what the handle refers to using 
some special API function, but that may not be correct).


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

Re: [fpc-devel] Questions regarding m68k-atari target

[Tomas Hajny via fpc-devel]

On 2022-01-29 15:05, Thorsten Otto via fpc-devel wrote:

On Samstag, 29. Januar 2022 14:55:30 CET Karoly Balogh wrote:


Yes, but changing this is not trivial in platform independent code,


It doesn't have to, if it can be fixed in fpc_readln_end().


Maybe Sven or someone can say more about the Windows analogy, I'm
not familiar there.


Thats something i have to check. Normally win32 should suffer from the
same problem. The C-runtime (MSVCRT) whould handle that, but not the
Windows ReadFile() function. Maybe that is some magic in the console
mode of windows.


This isn't something specific to Atari and Win32, CRLF is equally used 
for several other targets (starting with the first one implemented in 
FPC, which is 32-bit DOS with extender, continuing with the second one, 
OS/2, and several other). The implementation in the previously mentioned 
include file shared for all FPC targets allows any of CR, LF or CRLF as 
end of line. You can see that at the end of fpc_readln_end():


   if (prev=#13) then
 { is there also a #10 after it? }
 begin
   if (TextRec(f).BufPtr^[TextRec(f).BufPos]=#10) then
 { yes, skip that one as well }
 inc(TextRec(f).BufPos);
   exit;
 end;

If there's #13 (CR), the implementation just checks whether #10 follows 
(if so, it skips this character), but it stops reading regardless from 
the result. Again, there's nothing wrong to be "fixed" here.




Also then I don't understand why it still works and



returns after pressing it 3 times


I don't understand that either ;)


I know absolutely nothing about Atari, but if I should guess, I'd 
suggest having a look at how does the function gemdos_fread behave in 
case of console input - does it return individual characters, or does it 
return the whole line at once (the latter being the case for other FPC 
targets as far as I know)? Maybe this is something that needs to be 
handled specifically when reading from devices (i.e. the console in case 
of Atari) in the implementation of do_read in rtl/atari/sysfile.inc? I 
don't know whether there's a reasonable debugging possilibity for Atari, 
but even if there isn't, you can simply compile a program calling 
gemdos_fread directly for the stdInput handle and check the exact 
behaviour this way.


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

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

[Tomas Hajny via fpc-devel]

On 2022-01-13 10:28, Ben Grasset via fpc-devel wrote:

On Thu, Jan 13, 2022 at 3:28 AM Alexander Grotewohl via fpc-devel
 wrote:


32bit on Windows 64-bit uses Wow64.. which has a bit of overhead as
an emulation layer. I believe it's the same one they use for ARM64
too.


It should be kept in mind also that neither 32-bit or 64-bit FPC use
GNU LD for linking on Windows by default, but rather FPC's internal
one, and it's not hard to imagine why that might perform better on
64-bit as well.


My imagination fails here - why?

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

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

[Tomas Hajny via fpc-devel]

On 2022-01-12 16:03, Martin Frb via fpc-devel wrote:

On 12/01/2022 13:55, Tomas Hajny via fpc-devel wrote:



- The problem is *NOT* a native 64 bit "ppcx64.exe"  ?
   => 64 bit compiled targets don't require "extended" from the ppc,
as they themself wont have support for it?


Wrong - applies only to the Win64 target, whereas e.g. 64-bit Linux 
(supported by the same compiler targetting 64-bit code) supports 
extended. This means that compiling source code with this compiler may 
result in a different binary as soon as there's e.g. an extended 
contstant included in the source code, or any compile-time 
calculations in this precision need to be performed.


Ok, I was too unspecific, I indeed just meant a 64-bit Window
ppcx64.exe to compile a 64 bit target Windows app.

But indeed, I did not think about compile-time evaluations.
Those will indeed differ.

Leaving the question if it is in that case actually desired that they
are done in "extended" precision.
Imagine some code (targeted at Win-64) that uses "extended" (which
will at runtime become "double"? Or at least be less precise than
"extended").

Now if that code, does some calculations with those values, and the
code is written so the calculations happen at runtime => then the
calculations are done at lower precision.
This would potentially affect the result. I guess that would be
expected behaviour.

But, if any change to the code (not even necessarily a functional
change) would allow the compiler to do those calculations at compile
time, then the value changes. And the entire behaviour of the app may
change.
Possible, this could even be a change just in optimization settings
(or upgrading FPC), allowing the compiler to to propagate constants...

So does that mean, any code (that is to be compiled for Win-64bit) is
considered "unstable" if it contains "extended" ?


Not necessarily - when targetting Win64, the user needs to be prepared 
for the lower precision. However, imagine that that the user compiles 
his source code for target x86_64-linux. The resulting binary and its 
output will be exactly the same if the source code is compiled (with the 
same options, etc.) on Linux or if it is compiled on Windows using a 
Win32 hosted compiler, but it will differ if using a Win64 hosted 
compiler. From compiler support point of view, this is an issue.


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

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

[Tomas Hajny via fpc-devel]

On 2022-01-12 13:38, Martin Frb via fpc-devel wrote:

On 12/01/2022 11:51, Marco van de Voort via fpc-devel wrote:


On 12-1-2022 11:38, Ben Grasset via fpc-devel wrote:
If it's actually now somehow the case that an offer to provide Win64 
builds would be refused though, I guess maybe I'll look into hosting 
them myself somewhere else? Although again I don't get why it would 
be fine for Linux to have a zillion archives for different 
configurations here: 
https://sourceforge.net/projects/freepascal/files/Linux/3.2.2/


As said, Windows 64-bit is a special case because it doesn't 
support/recommend extended. This makes cross compiling to targets that 
do difficult till we have softfloat support.


Ok, let me throw in my 2 cents here

 .
 .

- The problem is *NOT* a native 64 bit    "ppcx64.exe"  ?
   => 64 bit compiled targets don't require "extended" from the ppc,
as they themself wont have support for it?


Wrong - applies only to the Win64 target, whereas e.g. 64-bit Linux 
(supported by the same compiler targetting 64-bit code) supports 
extended. This means that compiling source code with this compiler may 
result in a different binary as soon as there's e.g. an extended 
contstant included in the source code, or any compile-time calculations 
in this precision need to be performed.




So up to this point, afaik there would be no problem, having those
executables as 64-bit exe?

 .
 .

There would, see above.

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

Re: [fpc-devel] Fix for an annoying error

[Tomas Hajny via fpc-devel]

On 2021-11-30 08:33, J. Gareth Moreton via fpc-devel wrote:


Hi Gareth,


For a while now I've had problems building the i386-win32 compiler
under my 64-bit Windows system because one of the packages fails to
build - this is because it thinks a statically-imported DLL (done
through $linklib) is invalid. Technically it is, but this system DLL
(for me, it is named COMMON.DLL and is in one of my system folders, so
it's not something I can safely modify or replace) is for 64-bit
Windows and is not recognised when building for 32-bit, and the only
'fix' is to comment out the culprit $linklib line in the package
source.

I've submitted a merge request that generates a warning instead of an
error if it detects the DLL is 64-bit for a 32-bit target and vice
versa.  The checks, however, are very strict (it checks the COFF magic
number, which contains a platform target, and the size of the optional
header), and an error is still thrown if the DLL is actually corrupted
or is for an unknown target.

A warning is still thrown because the program that uses it may
malfunction, and might be indicative of a bug or a faulty search path
for the DLL.

https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/91


Semantically, what's the difference between the two cases (a DLL for a 
different architecture, or a broken DLL)? In both cases the compiled 
executable may be used on other machines (with proper version of the 
respective DLL), but it will fail when running it on the machine used 
for compilation, correct? Shouldn't the compiler handle both cases the 
same way (possibly issuing a similar warning if the DLL is not found at 
all)?


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

Re: [fpc-devel] Cross-compiling and warnings from linker

[Tomas Hajny via fpc-devel]

On 2021-11-23 13:17, Sergey Organov via fpc-devel wrote:

Tomas Hajny via fpc-devel
 writes:


On 2021-11-22 16:46, Sergey Organov via fpc-devel wrote:

Jonas Maebe via fpc-devel
 writes:

 .
 .

The compiler will still read only 2 configuration files at most, the
default for given instance of the compiler, and user's one.


The user would still need to remember that the first one depends on the 
installation path (which may not be even known to the compiler on some 
platforms as far as I remember!). The user may not even care/remember 
where the compiler is installed under normal conditions.




I.e., compiler installed in /usr should *not* read
/usr/local/etc/fpc.cfg, only /etc/fpc.cfg. Compiler installed 
elsewhere,

say, in /abc/def/custom, should read /abc/def/custom/etc/fpc.cfg.

The idea of backing to read /etc/fpc.cfg if /abc/def/custom/etc/fpc.cfg
is not found for backward compatibility that I've suggested above now
doesn't look useful to me, as I can't figure a use-case where it would
help.

What is indeed confusing is sharing "system" configuration file between
native and cross- compiler.


Why confusing? There is no "system" configuration file which would 
differ between native compilers and cross-compilers (note that 
cross-compilers may be installed at system-wide level, e.g. to 
/usr/bin/, equally to the native compiler!). There may indeed be a 
system-wide configuration file. Then there may be a user specific 
configuration file (~/.fpc.cfg on *nix machines) and a project specific 
configuration file (./fpc.cfg). Plus there may be a special 
configuration file for specific purpose which may be passed to the 
compiler using the '@' parameter. All of them allow specifying options 
valid for all cases / all compilations, as well as options used only 
under particular conditions (e.g. when compiling for a particular 
target, or a particular CPU). In addition, there are helpers which allow 
specifying certain configuration only once, but with certain parts 
changing value depending on the compilation target ($FPCTARGET). You can 
easily specify -XR valid for a particular target in your system-wide 
configuration file.




I'd suggest that at least -XR (if not the
installation directory itself) change the search path for configuration
file.

 .
 .

You should better read how the FPC option -XR is specified. What is the 
relation between 'Prepend  to all linker search paths' (see FPC help) 
and location of the configuration file?


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

Re: [fpc-devel] Cross-compiling and warnings from linker

[Tomas Hajny via fpc-devel]

On 2021-11-22 16:46, Sergey Organov via fpc-devel wrote:

Jonas Maebe via fpc-devel
 writes:

 .
 .

Yeah, I see. However, this file (/etc/fpc.cfg) is part of installation
of particular version of FPC provided by corresponding Linux
distribution, and is out of control of a person that installs custom
(likely more recent) FPC. That's just yet another reason not to read
/etc/fpc.cfg unless compiler is installed in /usr/, more so as 
different

FPC versions may have incompatible ideas of its meaning.

 .
 .

Yep, backward compatibility could be an issue. A solution could be to
still read /etc/fpc.cfg if /usr/local/etc/fpc.cfg is not found.


There are valid reasons for having a shared configuration for multiple 
installed versions of FPC (the one in /etc may equally serve for FPC 
installed into /usr/bin/ as well as /usr/local/ and other possible 
places), FPC provides means for specifying certain options conditionally 
there. In general, there's no particular reason why a person installing 
FPC should have rights for installation into /usr/local/ but not rights 
for changing configuration in /etc. If some person / user misses such 
rights, there's already the option of placing the configuration file 
into his or her home directory. Yes, /usr/local/etc/ might be added as 
one more location, but the more locations are supported, the bigger risk 
that users get confused due to multiple configuration files with 
different options specified.


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

Re: [fpc-devel] Building a debug version of FPC-main on Windows

[Tomas Hajny via fpc-devel]

On 2021-08-29 16:39, Marco van de Voort via fpc-devel wrote:

Op 8/28/2021 om 10:52 PM schreef Werner Pamler via fpc-devel:

Am 25.08.2021 um 20:53 schrieb Marco van de Voort via fpc-devel:
Sorry. I'm on holiday, and I only check in occasionally at night. Try 
changing PP= to FPC=
Thank you, Marco. Now I did already the second successful build of a 
older clone after an update. This really was the solution. But what is 
the difference between PP= and FPC= ?


As michael says, the make file use both FPC and PP which point
internally to the corresponding binaries (fpc(.exe) and
ppc(.exe)).

What I think is that the FPC binary found in the path  was queried
(and found a ppc binary in the same dir) and overrode your PP=
setting.


BTW, that raises a question whether we shouldn't consider the PP 
environment variable within the fpc binary... Obviously, that wouldn't 
help immediately to people having an older version of the fpc helper not 
supporting this functionality on PATH, but that would change over time. 
Just an idea.


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

Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size

[Tomas Hajny via fpc-devel]

On 2021-08-24 21:32, Bart via fpc-devel wrote:

On Tue, Aug 24, 2021 at 3:05 PM Sven Barth via fpc-devel
 wrote:

Wrong. If it would be a 64-bit DLL in System32 of a x86_64 system then 
there would be no problem. However a 64-bit DLL in the SysWOW64 
directory
(thus the 32-bit System32 directory) *is* a problem. Same for a 32-bit 
DLL in the System32 directory of a x86_64 system.


Even if the dll does not match the description/specs in the source 
code?

(Just curious)

And, being curious: any idea why make clean failed when %PATH% was set
to just C:\fpc\3.2.2\bin\i386-win32 ?


No idea - I just tested on a MS Win machine I have access to and 'make 
clean all' succeeded with PATH containing just the bin\i386-win32 
subdirectory of the 3.2.2 installation. Do you have a complete FPC 
installation, or did you build 3.2.2 yourself?


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

Re: [fpc-devel] Untranslatable (hardcoded) messages

[Tomas Hajny via fpc-devel]

On 2021-08-23 16:20, Marco van de Voort via fpc-devel wrote:

Op 8/23/2021 om 3:11 PM schreef Bart via fpc-devel:

dows trickery - feel free to complain at Microsoft. ;-)
OK, just for my understanding of this:
I cannot see the file there (system32)
FPC looks for it there
Windows just says it's there (and silently redirects to syswow64 
folder)
FPC looks at file, sees it's wrong, tells me the file in system32 is 
wrong.


Does that imply that, when I have a 32-bit program do a FindFirst for
common.dll in the system32 folder, Windows just tells the program that
the file is there?

For compilers this is always more difficult, since the mapping must
match the target system rather than the host binary.


True, but FPC already deals with that difference (and avoids this 
redirection using the respective Win32 API function if cross-compiling 
from Win32 to Win64).


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

Re: [fpc-devel] Untranslatable (hardcoded) messages

[Tomas Hajny via fpc-devel]

On 2021-08-23 15:11, Bart via fpc-devel wrote:

On Mon, Aug 23, 2021 at 3:01 PM Tomas Hajny via fpc-devel
 wrote:


The compiler finds the DLL by looking to C:\Windows\system32. As
mentioned in another e-mail, the fact that this request is redirected 
to

C:\Windows\SysWOW64 instead by the underlying operating system is a MS
Windows trickery - feel free to complain at Microsoft. ;-)


OK, just for my understanding of this:
I cannot see the file there (system32)


You probably cannot see it there if looking there by using a 64-bit 
application. If you use a 32-bit build of some file manager, you'd 
probably see it there as well.




FPC looks for it there
Windows just says it's there (and silently redirects to syswow64 
folder)
FPC looks at file, sees it's wrong, tells me the file in system32 is 
wrong.


Does that imply that, when I have a 32-bit program do a FindFirst for
common.dll in the system32 folder, Windows just tells the program that
the file is there?


Yes, it does.

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

Re: [fpc-devel] Untranslatable (hardcoded) messages

[Tomas Hajny via fpc-devel]

On 2021-08-23 14:37, Bart via fpc-devel wrote:

On Mon, Aug 23, 2021 at 2:28 PM Tomas Hajny via fpc-devel
 wrote:


Does it exist in C:\Windows\SysWOW64\ on your machine?


Yes, there is a common.dll there.
I think that syswow64 is not in my %PATH%, but currently I'm at work
and cannot check.

I also do not know how to examine wether this one is 32 or 64 bit.

(And even that one is 32-bit and the header is wrong, the errormessage
would still be wrong, since it explicitely mentions
C:\Windows\system32).


The compiler finds the DLL by looking to C:\Windows\system32. As 
mentioned in another e-mail, the fact that this request is redirected to 
C:\Windows\SysWOW64 instead by the underlying operating system is a MS 
Windows trickery - feel free to complain at Microsoft. ;-)


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

Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size

[Tomas Hajny via fpc-devel]

On 2021-08-23 14:31, Bart via fpc-devel wrote:

On Mon, Aug 23, 2021 at 1:36 PM Werner Pamler via fpc-devel
 wrote:


> Does anybody have a common.dll in \windows\system32 at all?

I don't have it, neither in system32 nor in SysWOW64.


OK.

Just pulled the current revision of fpc-trunk, and did not observe 
this

error (Win 10, fpc3.2.2 32-bit bootstrap compiler)


I expected as much, since nobody else complained about this error.
AFAIK the syswow64 directory is not in my %PATH%.


The problem is that MS Windows employs a special trickery by which the 
path to c:\windows\system32 (almost surely in your PATH) translates to 
c:\windows\SysWOW64 _for_32-bit_binaries_ (only!). So in reality, that 
directory _is_ in your PATH.




Unfortunately the "OPT=-vut" does not work (no output whatsoever) when
this package is built, so no way to determine where it searches (and
does not find: the errormessage is wrong w.r.t. that) and fails for
32-bit, not where it finds and succeeds for 64-bit and arm-wince.


It doesn't need to find it for 64-bit or arm-wince. As far as I know, it 
works like this: If the referenced DLL is found, the compiler builds the 
import library by scanning the found DLL, thus creating a complete and 
validated file guaranteed to work (on your machine). If the DLL is 
found, but it is not correct (either because it is somehow invalid, or 
because it doesn't contain the symbols / functions etc.), the compiler 
tells you about this issue, because it means that an attempt to run the 
compiled binary would fail with possibly obscure errors (compared to an 
error message stating that a required DLL is missing). If the referenced 
DLL is not found during compilation, the compiler tries to build the 
import library "blindly", just based on assumptions formulated in the 
source code.


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

Re: [fpc-devel] Untranslatable (hardcoded) messages

[Tomas Hajny via fpc-devel]

On 2021-08-23 14:25, Bart via fpc-devel wrote:

On Mon, Aug 23, 2021 at 12:23 PM Tomas Hajny via fpc-devel
 wrote:


Hi *,

Not directly related at all, but while trying to have a look at the
compiler code related to the error message about the DLL header size, 
I
realized that there are quite a few error messages (including this 
one)

hardcoded in ogcoff.pas instead of having these messages in errore.msg
and thus allowing translation, centralized management of these message
texts, etc. It would be probably useful to fix that (I guess that some
volunteer should be able to provide patches for that)...


Also, the message is wrong.
It says the file in that location has the wrong header, but the file
does not even exist in that location.


Does it exist in C:\Windows\SysWOW64\ on your machine?

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

[fpc-devel] Untranslatable (hardcoded) messages (Was: Re: Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size)

[Tomas Hajny via fpc-devel]

Hi *,

Not directly related at all, but while trying to have a look at the 
compiler code related to the error message about the DLL header size, I 
realized that there are quite a few error messages (including this one) 
hardcoded in ogcoff.pas instead of having these messages in errore.msg 
and thus allowing translation, centralized management of these message 
texts, etc. It would be probably useful to fix that (I guess that some 
volunteer should be able to provide patches for that)...


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

Re: [fpc-devel] Using -a or -s option forces change to external assembler

[Tomas Hajny via fpc-devel]

On 2021-08-22 20:43, Jonas Maebe via fpc-devel wrote:

On 22/08/2021 16:48, Christo Crause via fpc-devel wrote:

Would it make sense to implement an alternative interpretation, where
the internal assembler is used if specified/default with just an 
output

writer for the -a case?


The compiler only supports activating a single assembler writer at a
time. I'm not sure it worth reworking that logic just to support 
writing

a text assembler file and then assembling using the internal assembler.


Apart from complicating things, using a different writers for the text 
output and for assembled binary might result in differences (assembled 
output from the text assembler source might not be absolutely equal to 
the result of the internal assembler) which might lead to serious 
confusions. Obviously, we may extend the description of this option in 
the documentation (and also of -s) in order to avoid surprises - feel 
free to create a bug report for the docs.


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

Re: [fpc-devel] Procedural types returning file types

[Tomas Hajny via fpc-devel]

On 2020-12-18 14:06, Sven Barth wrote:
Tomas Hajny via fpc-devel  schrieb am 
Fr.,

18. Dez. 2020, 11:38:


On 2020-12-18 10:01, Blaise--- via fpc-devel wrote:


Hello,

> The patch http://hg.blaise.ru/public/fpc/rev/698389953e49 (attached)
> fixes the following:
> ---8<---
> // EXPECTED: 'Error: Illegal function result type'
> // ACTUAL: gets compiled
> type M = function : file;
>
> begin
> end.
> ---8<---

Sorry for a silly question, but conceptually - why a file (which is
technically a record) shouldn't be allowed if records are allowed and
the result (i.e. the file) may be assigned to another variable of the
type file? Do you have any information why the compiled functionality
wouldn't work correctly?



Because TP and Delphi don't allow it either. In fact FPC doesn't allow 
it
as well for function declarations, but for function and method 
variables a

different code path is used.


I see. IIRC at least TP doesn't allow records as return types and using 
records in assignments either whereas FPC does. However, the reasons for 
disallowing file there may be actually related to the second part of 
your response below.



Sidenote: it also isn't allowed to pass file type parameters by value 
(the

compiler checks this) which is why you always see them with "var" or
"const".


Ah, yes, that indeed has the same reason for which a file shouldn't be 
allowed for return value, thanks for reminding me of this. I believe 
that this is already explicitly specified in the original Pascal 
definition. The reasons are probably conceptual - semantically, 'file' 
in Pascal doesn't mean a record containing some file descriptor and 
other information necessary for working with the file, but the content 
of the file. From this point of view, you could indeed never pass a file 
by value or return it as a return value.


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

Re: [fpc-devel] Procedural types returning file types

[Tomas Hajny via fpc-devel]

On 2020-12-18 10:01, Blaise--- via fpc-devel wrote:


Hello,


The patch http://hg.blaise.ru/public/fpc/rev/698389953e49 (attached)
fixes the following:
---8<---
// EXPECTED: 'Error: Illegal function result type'
// ACTUAL: gets compiled
type M = function : file;

begin
end.
---8<---


Sorry for a silly question, but conceptually - why a file (which is 
technically a record) shouldn't be allowed if records are allowed and 
the result (i.e. the file) may be assigned to another variable of the 
type file? Do you have any information why the compiled functionality 
wouldn't work correctly?


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

Re: [fpc-devel] Explicitly named return values and implicit aliases Result

[Tomas Hajny via fpc-devel]

On 2020-12-16 12:25, Blaise--- via fpc-devel wrote:

On 16.12.2020 12:24, Michael Van Canneyt via fpc-devel wrote:
To be correct: Result is not the name of the result value, it is an 
alias.


I did not dispute that. The important point here is: "an alias" to 
/what/?


You can still use the function name for the result, so "Result" is in 
fact an alias for the function name


Result is not "an alias for the function name" because you cannot use
Result to refer to the function:
---8<---
function Foo: Integer;
var X: function : Integer;
begin
Result(); // ERROR
X := Result; // ERROR
end;
---8<---


It is a _local_ alias for the name of the _currently_executed_ function 
which is valid just within the scope of that function. When invoking the 
function recursively, you refer to _another_ instance of that function 
and thus the alias is not valid at that point in time, because it 
becomes an alias again only when the recurrently called function starts.


Thus it's equivalent to the following example (it compiles due to {$MODE 
TP}; in other modes the local can be replaced with another name with the 
same effects):


{$MODE TP}
 function Foo: Integer;
 var
  X: Integer absolute Foo;
 begin
  X := 123;
 end;
begin
 WriteLn (Foo);
end.



the function name, which is the actual name for the result value.


I can get behind this notion; however, within the function, that name
is overloaded. Thus, we should not say, like Sven did, that Result
aliases the function (name); we should say, like I did, that it
aliases the return value (name).

But, conceptually, I would rather look at the function name resolving
to the return value as a backward-compatible alias, and say that
Result is the true (default) name for the return value. Such notion
fits modern usage.


Modern or not - use of the function name for assignment of the return 
value is part of Pascal definition, isn't it? What's the point of 
changing the "true name"?


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

Re: [fpc-devel] Different handling of try..except depending on OS?

[Tomas Hajny via fpc-devel]

On 2020-12-10 07:34, Sven Barth via fpc-devel wrote:

Am 09.12.2020 um 23:45 schrieb Bart via fpc-devel:
Compiled with fpc 3.2.0 on Windows it will output (both 32 and 64 
bit):

Runtime error 201 at $004015F1
   $004015F1
   $00407307

Compiled with fpc 3.2.0 on linux X86_64 it will output
Except block
Finally block

On Windows you need to include the sysutils unit to execute the except
and finally block.


That is correct, because without the SysUtils unit (which declared the
Exception type) the RTL can't convert the triggered runtime error to
an exception type that can be caught inside the try ... except ... end
block.

 .
 .

Is the current behaviour on "other" (non-MS Windows) targets really 
correct (I checked under OS/2 for both 3.2.0 and trunk and it behaves 
the same way as Linux)? Including SysUtils should result in converting a 
run-time error to an exception. If SysUtils is not included, run-time 
error should be raised regardless from the try..except block (as it does 
under MS Windows, but not on other platforms at the moment), shouldn't 
it? Shouldn't the try..except construct by default (i.e. without using 
SysUtils) catch only explicitly raised exceptions?


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

Re: [fpc-devel] Might need some help with this one

[Tomas Hajny via fpc-devel]

On 2020-11-27 15:34, Bart via fpc-devel wrote:

On Thu, Nov 26, 2020 at 11:10 PM Tomas Hajny via fpc-devel
 wrote:

Typing 'break.exe' in cmd.exe _does_ make a difference here (it 
executes

as expected unlike when typing just 'break'). And obviously running
break.exe using some other 'shell' (e.g. your preferred OFM ;-) ) 
works

as well.


Well, at my machine it did not.
I also called it from a batchfile (as break.exe) to see if I could
catch the errorlevel (I let it crash with a division by zero).
The errorlevel is set, but absolutely no output to screen or pipe.


Understood. Haven't I already mentioned something about MS approach 
towards compatibility here recently? :/


---
D:\TEMP>cmd
Microsoft Windows [Version 10.0.18363.1082]
(c) 2019 Microsoft Corporation. Všechna práva vyhrazena.

D:\TEMP>break

D:\TEMP>break.exe
I am Break

D:\TEMP>.\break
I am Break

D:\TEMP>
===

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

Re: [fpc-devel] Might need some help with this one

[Tomas Hajny via fpc-devel]

On 2020-11-26 20:17, Bart via fpc-devel wrote:

On Thu, Nov 26, 2020 at 6:52 PM Jonas Maebe via fpc-devel
 wrote:


"break" is probably a command that's recognised by the cmd shell.

Yes it is:
C:\Users\Bart>help break
Sets or Clears Extended CTRL+C checking on DOS system

This is present for Compatibility with DOS systems. It has no effect
under Windows.

If Command Extensions are enabled, and running on the Windows
platform, then the BREAK command will enter a hard coded breakpoint
if being debugged by a debugger.


Try to
execute the program as .\break or break.exe


Makes no difference whatsoever.
It does run, because you can set ExitCode and query errorlevel after 
execution.


Typing 'break.exe' in cmd.exe _does_ make a difference here (it executes 
as expected unlike when typing just 'break'). And obviously running 
break.exe using some other 'shell' (e.g. your preferred OFM ;-) ) works 
as well.


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

Re: [fpc-devel] Compiler message colour scheme

[Tomas Hajny via fpc-devel]

On 2020-11-25 14:40, Sven Barth via fpc-devel wrote:
Tomas Hajny via fpc-devel  schrieb am 
Mi.,

25. Nov. 2020, 13:31:

On 2020-11-25 10:31, Nikolai Zhubr via fpc-devel wrote:
> 25.11.2020 1:52, Tomas Hajny via fpc-devel:


 .
 .
How current is your Windows 10? VT100 support was added only two years 
ago

or so.


I have the machine since May and it gets regular fixes (it's managed by 
my employer). The most recent binaries in Windows\System32 are from 
September the 18th and the File Version and Product Version properties 
show 10.0.18362.1049 (and some other .1082). Maybe it's too recent? ;-) 
(Sorry, I couldn't resist, making jokes about MS approach to 
compatibility is way too easy. ;-) ) I don't care too much, I just 
wanted to make sure that the compiler colouring still works on Windows 
after my changes.


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

Re: [fpc-devel] Problems building on i386-win32

[Tomas Hajny via fpc-devel]

On 2020-11-25 09:51, J. Gareth Moreton via fpc-devel wrote:

Aah, typical!  C:\Windows\System32 is supposed to be for 32-bit DLLs,
while C:\Windows\System is 64-bit.  Question is, what can I do to
resolve it?  I'm not even sure what Common.dll is for.


Well, I don't think that it works this way - 32-bit applications cannot 
access the directory with the 64-bit versions as far as I know (they're 
always directed to the 32-bit versions in the background on the 
operating system level). In any case, checking the particular library 
seems to be the best way forward. You should be able to find the DLL 
"Manufacturer" and "Description" information within the binary (either 
using some tools able to extract and display it, or even just looking 
into the file with a binary file viewer).


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

Re: [fpc-devel] Compiler message colour scheme

[Tomas Hajny via fpc-devel]

On 2020-11-25 10:31, Nikolai Zhubr via fpc-devel wrote:

25.11.2020 1:52, Tomas Hajny via fpc-devel:





Hi Nikolai,


No problem, thanks for testing. Unfortunately, it doesn't work for me
under Windows (Win 10 Pro 64-bit) either with the original version or


Have you also checked with this registry trick for win10:

[HKEY_CURRENT_USER\Console]
"VirtualTerminalLevel"=dword:0001

(As per https://superuser.com/a/1300251/109090)

 .
 .

If I read the article correctly, it says that an application may enable 
this processing explicitly using SetConsoleMode, or that it may be 
enabled for all applications / consoles using the mentioned registry 
key. The code added to the compiler contains the mentioned 
SetConsoleMode setting, thus it should be sufficient according to the 
article. However, the call fails (here) with error 87 (invalid 
parameter). And btw, changing the registry key doesn't help (i.e. I 
still get the same error). The same call (SetConsoleMode) performed 
without setting the respective flag (ENABLE_VIRTUAL_TERMINAL_PROCESSING) 
succeeds. I'm willing to have a look at additional hints, but I won't 
perform additional research myself for this.


For anybody interested, the following test program reproduces the 
functionality in the compiler (and provides debug information):


-
{$MODE OBJFPC}
uses
 Windows;
const
  ENABLE_VIRTUAL_TERMINAL_PROCESSING = $0004;
  CachedIsATTY : Boolean = false;
  IsATTYValue : Boolean = false;

function IsATTY(var t : text) : Boolean;
  const dwMode: dword = 0;
  begin
if not(CachedIsATTY) then
  begin
IsATTYValue := false;
if GetConsoleMode(TextRec(t).handle, dwMode) then
begin
  WriteLn ('dwMode = ', dwMode);
  if not (SetConsoleMode(TextRec(t).handle, dwMode)) then
   WriteLn ('SCM0: ', GetLastError);
  dwMode := dwMode or ENABLE_VIRTUAL_TERMINAL_PROCESSING;
  if SetConsoleMode(TextRec(t).handle, dwMode) then
IsATTYValue := true
  else
   WriteLn ('SCM: ', GetLastError);
end
 else
  WriteLn ('GCM: ', GetLastError);
CachedIsATTY:=true;
  end;
Result:=IsATTYValue;
  end;

begin
 WriteLn (IsATTY (Output));
end.
==

I get the following result (regardless from the registry setting):

dwMode = 3
SCM: 87
FALSE

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

Re: [fpc-devel] Compiler message colour scheme

[Tomas Hajny via fpc-devel]

On 2020-11-24 19:17, J. Gareth Moreton via fpc-devel wrote:

Sorry for being a bit slow - I've been doing my own work on x86. I
gave your patch (and new file) a test run on x86_64-win64, and that
seems to work fine.  At least the warning messages in the packages
appear magenta.  I'll give arm-linux a test next.


No problem, thanks for testing. Unfortunately, it doesn't work for me 
under Windows (Win 10 Pro 64-bit) either with the original version or 
with my modifications (i.e. hopefully unrelated to my changes). It could 
be some configuration of the used Windows installation, whatever, no 
idea. I'll probably commit my changes now hoping that I didn't break 
anything for anybody for whom it worked correctly previously. The GO32v2 
version was not compilable in the sent version, fixed now and tested to 
work properly (apparently, coloured output using ANSI escape codes works 
more reliably with 16-bit MS-DOS/PC DOS/... than with 64-bit MS Windows 
10 Pro ;-) ). And BTW, no, it doesn't work under DOSBox, because DOSBox 
supports ANSI escape codes out of the box without signalizing that such 
support is available in a way compatible to the real DOS. I could add a 
specific check for running under DOSBox if somebody wants it (it's just 
a few more lines of code, no difficulties).


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

Re: [fpc-devel] Compiler message colour scheme

[Tomas Hajny via fpc-devel]

On 2020-11-24 01:14, J. Gareth Moreton via fpc-devel wrote:

I'd say thie first port of call is "compiler/comphook.pas", line 258:

procedure WriteColoredOutput(var t: Text;color: TOutputColor;const s :
AnsiString);

It looks like a simple "$if defined".


Yes, and the more platforms are added, the more messy this unit gets. 
:-( I tried to clean it up a bit by moving the platform-specific parts 
to a new unit - see the attachment containing a diff for comphook.pas 
and the new unit. I didn't commit yet because I couldn't test it on the 
other platforms (my new implementation for OS/2 works OK ;-) ). If 
somebody tests is under Linux and WinXX, I'll committ it tomorrow.


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

Re: [fpc-devel] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on

[Tomas Hajny via fpc-devel]

On 2020-09-27 18:27, Nikolay Nikolov via fpc-devel wrote:

On 9/27/20 7:21 PM, Florian Klämpfl via fpc-devel wrote:

Am 27.09.20 um 18:03 schrieb Martin Frb via fpc-devel:

On 27/09/2020 09:34, Sven Barth via fpc-devel wrote:
Ben Grasset via fpc-devel > schrieb am So., 27. Sep. 
2020, 07:50:


    That last quote is absolute BS, to be very frank. There is no
    reason whatsoever not to use a natively-64-bit copy of FPC if
    running a natively-64-bit copy of Windows, and there hasn't been
    for well over half a decade at this point.


Yes, there is a reason: you can not build a i8086 or i386 cross 
compiler with the Win64 compiler (or any non-x86 compiler to be 
fair) due to missing Extended support. Thus the majority of the FPC 
Core team considers the Win64 compiler as inferior and also 
unnecessary cause the 32-bit one works just as well on that 
platform.



Just my 2 cents.

Well, one the one hand, native 64 bit is only really important if it 
can do something that 32 bit can not do. (faster, bigger sources, 
).


On the other hand, not everyone needs a win64 to win32 cross 
compiler. And if they do, a native 32bit compiler can be renamed and 
will happily serve as such a cross compiler. (But that is not a must 
be included / such workarounds may not be wanted, especially since 
they might cause repeated extra work)


So the question here is/are imho about the work it takes to amend the 
release-build process (i.e. update the scripts). And then the amount 
of extra time needed for each release (build and testing).


The thing is: we would distribute a compiler (the x86_64-win64 one) 
which claims to be able to compile to e.g. to x86_64-linux, but it 
would generate programs which might behave differently than natively 
compiled ones as float constants are handled internally different.


And in this particular case, "different" means "less accurate", due to
rounding errors, caused by compile time conversion of 80-bit extended
float constants to 64-bit double precision constants. And "less
accurate" is bad. :)


Sorry for a silly question, but is it really the case that a higher 
precision is good (or that it doesn't matter at least)? I assume that 
performing compile-time calculations in higher precision than 
calculations performed at run-time may still result in differences and, 
in spite of the fact that the calculations are more precise, the 
differences may still lead to confusion of our users (if not something 
worse) - especially if it may not be always clear which part will be 
computed at compile-time and which part at run-time. Is my understanding 
correct? Or is there some solution allowing to achieve specific 
precision with a higher precision library?


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

Re: [fpc-devel] Warning: Unicode constant cast with potential data loss

[Tomas Hajny via fpc-devel]

On 2020-09-17 15:37, Martin via fpc-devel wrote:

FPC 3.2.0

var
  u,u2 : UTF8String;

begin
  u := #$2267'x';
  u2 := #$2267;  // warning


Assigning a WideString to a Utf8String works without warning.

Assigning a WideChar (2nd line) to a Utf8String causes "Warning:
Unicode constant cast with potential data loss"
Apparently it is first converted to a char in the System codepage, and
then to string.

Is that intended?


FWIW, this looks similar to my observation described in number 2 at the 
bottom of 
https://www.mail-archive.com/fpc-pascal@lists.freepascal.org/msg53421.html


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