[fpc-devel] freebsd alive again

2022-06-21 Thread Marco van de Voort via fpc-devel

Fyi,

Last weekend I got FreeBSD working again, integrating a patch from the 
ports maintainer.


Both fixes and trunk should work again, but

- ld.bfd must be installed.

- for bootstrapping, ld must also be symlinked to ld.bfd, at least till 
a new release is done.



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


Re: [fpc-devel] get and putin $modeswitch isooi

2022-06-20 Thread Marco van de Voort via fpc-devel



On 20-6-2022 22:10, Sven Barth via fpc-devel wrote:
Put and Get are not part of modeswitch ISOIO, because they're not 
intrinsics and are instead provided by the ISO7185 unit which is only 
used for modeswitch ISO. As that unit also contains functionality 
that's not covered by the ISOIO modeswitch (some types, Round 
functions) it's not used for that modeswitch, but only together with 
the mode. 


I relayed your answer.

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


Re: [fpc-devel] ConvUtils: question regarding Delphi compatibility. How to proceed?

2022-06-19 Thread Marco van de Voort via fpc-devel


On 19-6-2022 12:09, Bart via fpc-devel wrote:

It feels a bit counter-intuïtive to me though.
IMO it should simply not be allowed to call RegisterConversionType()
with either of the TConversionProc parameters being nil, since that
makes no sense to me, and it will inevitably lead to exceptions later
on in the code.


Agreed.  This is not really a much used unit where extreme bug 
compatibility pays off. Better keep it straightforward.



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


Re: [fpc-devel] ConvUtils: ConvTypeToFamily and ConvFamilyToDescription conundrums

2022-06-08 Thread Marco van de Voort via fpc-devel


On 8-6-2022 15:14, Bart via fpc-devel wrote:

Changing our TConvType to word will potentially break existing programs though.


I doubt that there are mission critical convutils programs out there, 
given the fact that it took 10+ years  to find out the temperature 
conversion didn't work :-)


Usage is low, risk is small, I say, go ahead.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


[fpc-devel] get and putin $modeswitch isooi

2022-06-03 Thread Marco van de Voort via fpc-devel


There was a question about $modeswitch ISOIO  on stack overflow, and 
specially why get() and put() are not part of it.


The documentation about this switch seems very sparse. As far as I can 
see it is mostly the lookahead and switching reset and read/write 
handlers to their ISO variants.


Does anybody know? Or is it simply because get/put support is newer?

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


Re: [fpc-devel] Unable to find resource

2022-04-22 Thread Marco van de Voort via fpc-devel



On 22-4-2022 09:12, Marc Weustink via fpc-devel wrote:


On a project I'm working on I needed to refactor some units. After I 
finished, I got a linking error about a duplicate resource. Maybe 
accidentally a stale one got linked, so I removed 2 occurrences.

And now the compiler complains it cannot find the resource.



Debug: parsing parameter '.\lib\x86_64-win64\x_service.res'
Debug: parsing parameter 'C:\Users\marc\x\x_service.res'


Well that is duplicate obviously.

Maybe you did some manual cmdline build that left a .res in the working 
dir , and your project has a stale {$R *.res} in the .dpr ?

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


Re: [fpc-devel] Package build failure under i386-win32

2022-04-03 Thread Marco van de Voort via fpc-devel


On 3-4-2022 15:44, J. Gareth Moreton via fpc-devel wrote:

Hi everyone,

It seems at some point, something was introduced to the compiler that 
causes a package to fail to build (specifically 
packages\chm\src\chmwriter.pas) with an assembler-level range check 
error.  If you run "make all" under i386-win32 with "-CriotR -a" 
options, the error is triggered.  It only occurs under -CriotR and, 
notably, it does NOT occur when -a is omitted.




Note that that file changed last week:
*54c95288f868a762f1caa9d8e62fa6f193237cf2 
* 
marcoonthegit Sat Mar 26 15:00:15 2022

___
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

2022-01-14 Thread Marco van de Voort via fpc-devel


On 14-1-2022 16:33, Ben Grasset via fpc-devel wrote:
On Fri, Jan 14, 2022 at 1:27 AM Sven Barth via fpc-devel 
 wrote:


(though to be fair it does the same on 32-bit as well)


Yeah, MSVC (for some reason) universally defines "long double" as 
exactly an alias for regular 64-bit double, whereas GCC and Clang 
(more correctly IMO) define it as an 80-bit type equivalent to FPC's 
traditional "extended". So even on 32-bit with MSVC you have to 
hand-write assembly to make use of x87 FPU instructions.


Did you test a windows gcc (win64 SEH) or a SJLJ "posix" (basically 
unported Unix)  gcc ?


___
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

2022-01-12 Thread Marco van de Voort via fpc-devel


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.


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


Re: [fpc-devel] Attn: J. Gareth // 3.3.1 opt = slower // Fwd: [Lazarus] Faster than popcnt

2022-01-04 Thread Marco van de Voort via fpc-devel


On 4-1-2022 17:15, J. Gareth Moreton via fpc-devel wrote:

I neglected to include -Cpcoreavx, that was my bad.  I'll try again.

According to Intel® 64 and IA-32 Architectures Software Developer’s 
Manual, Vol 2B, Page 4-391.  The zero flag is set if the source is 
zero, and cleared otherwise.  Regarding an undefined result, I got 
confused with the BSF and BSR commands, sorry.  I guess I was more 
tired than I thought!  POPCNT returns zero for a zero input.


Ok, that's what I thought.

I played a bit by adding code alignments to loops in the SSE code, but 
it only seems to slow the core loop rather than accelerate it (align 
before the branch location and/or branch target)


Did you have any thoughts about moving up the NOT instruction ?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Attn: J. Gareth // 3.3.1 opt = slower // Fwd: [Lazarus] Faster than popcnt

2022-01-04 Thread Marco van de Voort via fpc-devel

On 4-1-2022 16:31, Martin Frb via fpc-devel wrote:


Weird as mine is inlined with -Cpcoreavx -O4, with no special 
handling for 0. But that does put some things on shaky ground. Maybe 
zero the result before hand?


Same here.


I looked up popcnt and found nothing about not setting if zero. (E.g. 
https://www.felixcloutier.com/x86/popcnt )


I meanwhile also ran on my Ryzen 4800H laptop and updated the version on 
the web with the stats. The stats for the  long string are about as fast 
as on my i7-3770 (laptop vs desktop memory bandwidth? The ryzen should 
be faster in any way?!?), but the short one (40 bytes) is significantly 
faster. What I don't get is why the assembler version seems 
systematically faster even for the short code. The generated asm is 
nearly the same.


Also notable is that on this machine with popcnt (-Cpcoreavx), the 
popcnt version is as fast as the add function within error margins, so 
probably popcnt instruction is faster(lower latency) and thus less of a 
bottleneck on this machine.  Note that the POP() function is half the 
size, so that makes it better for newer machines.


-

Note that I test on Windows, so it might be that the "two times load" is 
a difference somehow due to different codegeneration on windows





About UTF8LengthFast()

Well, before I get to this, I noted something weird.

2 runs, compiled with the same compiler ( 3.2.3 ), and the same 
settings, with the only difference: -gw3 or not -gw3
=> And the speed differed.  600 (with dwarf)  vs 700 (no dwarf) / 
reproducible.


I also have seen this, while working on the code. And indeed mainly with 
the "fast" one. It also explains why the assembler is always consistent, 
it suffers less from detail code changes when I e.g. update FPC from 
git, and thus different alignment. (assuming that the section starts are 
always aligned)



Alignment. 16 vs 32 bit. Can that make a difference?
According to: 
https://stackoverflow.com/questions/61016077/32-byte-aligned-routine-does-not-fit-the-uops-cache


Seems to be a problem of the Skylake and later archs, which I no longer 
have. The i7 is too old, and the others are AMD.



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


Re: [fpc-devel] Attn: J. Gareth // 3.3.1 opt = slower // Fwd: [Lazarus] Faster than popcnt

2022-01-04 Thread Marco van de Voort via fpc-devel


On 4-1-2022 01:06, J. Gareth Moreton via fpc-devel wrote:

Prepare for a lot of technical rambling!

This is just an analysis of the compilation of utf8lentest.lpr, not 
any of the System units.  Notably, POPCNT isn't called directly, but 
instead goes through the System unit via "call fpc_popcnt_qword" on 
both 3.2.x and 3.3.1.  A future study of "fpc_popcnt_qword" might 
yield some interesting information.


Did you pass -Cpcoreavx    ?

# [381] Result += PopCnt(qword(nx));
    popcntq    %r10,%r8
    addq    %r8,%rbx



In this situation, one can replace %r11 with %r13 in the 3rd and 4th 
instructions so the massive constant isn't assigned twice:


The large constant(s) should be hoisted out of the loop. This is done in 
the assembler code:


.Lj11:
    movq    (%rcx),%r8
    movq    %r8,%r10
    andq    %rdx,%r10
    notq    %r8
    shrq    $7,%r10
    shrq    $6,%r8
    andq    %r8,%r10
    subq    %r8,%rax   // subtract from rax=length(s). Iow 
algorithm is slightly different. don't sum


    // correction but 
directly subtract from length. Saves bytecount from being a live value 
till the end


 popcntq    %r10,%r8
    addq    $8,%rcx
    decq    %r11
    jne    .Lj11

As far as I can see the assembler version is about 25-33% faster for low 
counts (40 bytes) . For larger strings, the SSE2 code kicks in and that 
is a solid factor 2.  (270 vs 538 for the fastest "add", see table in 
the comments of the source)


Note that I use pop/fast because they are simpler and I only use for low 
counts. The SSE2 version is more like the ADD variant.


For actual reduction of pipeline stalls, I'm not quite sure how smart 
the Intel CPU firmware is and if rearranging instructions would 
actually improve throughput or not.  For example, on 3.2.x, there are 
these four instructions that configure parameters and preserve %rax:


I tried for above code on godbolt, attached is the analysis. (both for 
the asm loop, the popcnt loop from my code and the popcnt with the 
movabs removed to test hoisting)


Note my 3.3.1 (from 29 dec) doesn't seem to generate two loads. With my 
limited assembler abilities I'd say it is not the hoisting that makes 
the manual asm loop faster as I first thought, but moving the NOT up to 
where it is.


Also, POPCNT is handled in the System unit and is not inlined, mainly 
because of how an input of zero is handled (the function has to return 
255 in the result, whereas Intel's POPCNT instruction sets the zero 
flag and leaves the result undefined).


Weird as mine is inlined with -Cpcoreavx -O4, with no special handling 
for 0. But that does put some things on shaky ground. Maybe zero the 
result before hand?


manual asm :
--

.Lj47:
add rsi,1
mov r8,qword [rcx]
mov r10,r8
mov rdi,-9187201950435737472
and r10,rdi
shr r10,7
not r8
shr r8,6
and r10,r8
mov r11,r10
popcnt  r8,r10
add rbx,r8
add rcx,8
cmp rsi,r9
jnge.Lj47

llvm-mca: -mcpu=ivybridge

Iterations:100
Instructions:  1200
Total Cycles:  378
Total uOps:1200

Dispatch Width:4
uOps Per Cycle:3.17
IPC:   3.17
Block RThroughput: 3.0

Instruction Info:
[1]: #uOps
[2]: Latency
[3]: RThroughput
[4]: MayLoad
[5]: MayStore
[6]: HasSideEffects (U)

[1][2][3][4][5][6]Instructions:
 1  5 0.50*   mov   r8, qword ptr [rcx]
 1  1 0.33mov   r10, r8
 1  1 0.33and   r10, rdx
 1  1 0.33not   r8
 1  1 0.50shr   r10, 7
 1  1 0.50shr   r8, 6
 1  1 0.33and   r10, r8
 1  1 0.33sub   rax, r8
 1  3 1.00popcntr8, r10
 1  1 0.33add   rcx, 8
 1  1 0.33dec   r11
 1  1 1.00jne   .Lrestqwords

Resources:
[0]   - SBDivider
[1]   - SBFPDivider
[2]   - SBPort0
[3]   - SBPort1
[4]   - SBPort4
[5]   - SBPort5
[6.0] - SBPort23
[6.1] - SBPort23

Resource pressure per iteration:
[0][1][2][3][4][5][6.0]  [6.1]  
 -  - 3.66   3.67- 3.67   0.50   0.50   

Resource pressure by instruction:
[0][1][2][3][4][5][6.0]  [6.1]  Instructions:
 -  -  -  -  -  - 0.50   0.50   mov r8, qword ptr 
[rcx]
 -  - 0.21   0.63- 0.16-  - mov r10, r8
 -  - 0.35   0.61- 0.04-  - and r10, rdx
 -  - 

Re: [fpc-devel] Attn: J. Gareth // 3.3.1 opt = slower // Fwd: [Lazarus] Faster than popcnt

2022-01-03 Thread Marco van de Voort via fpc-devel


On 3-1-2022 12:54, Martin Frb via fpc-devel wrote:



fpc 3.2.3 /   fpc 3.3.1

fst 594   fst 688
fst 578   fst 703
fst 578   fst 687
fst 562   fst 688




Fyi, the latest asm version (+fst/pop/add/naieve) is at

http://www.stack.nl/~marcov/utf8lentest.lpr

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


Re: [fpc-devel] FPC trunk building lazarus trunk fails with compiler AV ?

2021-12-12 Thread Marco van de Voort via fpc-devel


On 12-12-2021 17:21, Yuriy Sydorov via fpc-devel wrote:

On 12.12.2021 16:24, Marco van de Voort via fpc-devel wrote:


On 12-12-2021 15:19, Florian Klämpfl via fpc-devel wrote:


What -Cp/-Cf option do you use?


To compile FPC:

set CPUOPTS=-O2  -Opcoreavx -Cpcoreavx
set CPUOPTS64=-Cfavx

I didn't enter those in Lazarus I think, so that should be pretty 
much default.


Should be fixed now. The AVs have occurred only when targeting the AVX 
FPU.


Ok, got another error, but that turned out to be the result of unit 
baseenc changing packages somewhere in the last few weeks.


After fixing that, everything works again (without changing any of the 
scripts), so THANKS!


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


Re: [fpc-devel] FPC trunk building lazarus trunk fails with compiler AV ?

2021-12-12 Thread Marco van de Voort via fpc-devel


On 12-12-2021 15:19, Florian Klämpfl via fpc-devel wrote:


What -Cp/-Cf option do you use?


To compile FPC:

set CPUOPTS=-O2  -Opcoreavx -Cpcoreavx
set CPUOPTS64=-Cfavx

I didn't enter those in Lazarus I think, so that should be pretty much 
default.

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


Re: [fpc-devel] FPC trunk building lazarus trunk fails with compiler AV ?

2021-12-12 Thread Marco van de Voort via fpc-devel


On 12-12-2021 14:47, Yuriy Sydorov via fpc-devel wrote:



Any pointers?


I've tried to reproduce the AV while building Lazarus on i386-win32 
with -O2 and -O3 options, but it works for me.

What compiler options have you used to build Lazarus?



lazbuild --pcp=c:\repo\lazarusgit\config --build-ide=


I'll send my FPC buildscript and lazarus config dir in private.


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


[fpc-devel] FPC trunk building lazarus trunk fails with compiler AV ?

2021-12-11 Thread Marco van de Voort via fpc-devel


FPC trunk building lazarus trunk fails with compiler AV ?

An old ghost seems to have resurfaced. I didn't build a development 
lazarus for a while (I used a stable one for work), but at least 1-2 
weeks I have this problem:



(3104) Compiling postscriptcanvas.pas
(3104) Compiling printers.pas
(3104) Compiling postscriptunicode.pas
c:\repo\lazarusgit\lcl\postscriptcanvas.pas(707,3) Warning: (6060) Case 
statement does not handle all possible cases
c:\repo\lazarusgit\lcl\postscriptcanvas.pas(722,30) Error: (1026) 
Compilation raised exception internally

Fatal: (1018) Compilation aborted
An unhandled exception occurred at $00499477:
EAccessViolation: Access violation
  $00499477  GET_ALIAS,  line 1214 of rgobj.pas
  $0049C655  INSTR_SPILL_REGISTER,  line 2834 of rgobj.pas
  $0049BDE3  SPILL_REGISTERS,  line 2572 of rgobj.pas
  $004987DF  DO_REGISTER_ALLOCATION,  line 659 of rgobj.pas
  $0048935A  DO_REGISTER_ALLOCATION,  line 903 of cgobj.pas
  $004E2659  GENERATE_CODE_TREE,  line 1616 of psub.pas
  $004E450B  READ_PROC,  line 2840 of psub.pas
  $004E49F9  READ_DECLARATIONS,  line 3072 of psub.pas
  $0043D00A  COMPILE,  line 402 of parser.pas
  $004D44AE  LOADPPU,  line 2276 of fppu.pas
  $005AF153  LOADUNITS,  line 523 of pmodules.pas
  $005AFFA8  PROC_UNIT,  line 983 of pmodules.pas
  $0043D00A  COMPILE,  line 402 of parser.pas
  $00418526  COMPILE,  line 288 of compiler.pas

Compiler AVs in postscript* units have happened before afaik.

Any pointers?

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


Re: [fpc-devel] Preparing 3.2.4, call for merge request and regressions

2021-10-26 Thread Marco van de Voort via fpc-devel


Op 25-10-2021 om 13:06 schreef LacaK via fpc-devel:
The base output  is starting to work somewhat. 
http://www.stack.nl/~marcov/mergelogs32/restset.html
Marco, can I see what commits were already merged ? (and what not - 
iow what is candidate for merging)


I don't really maintain lists of what was merged, only what was 
candidate for merge(*)


Basically, it just finds all eligible revs using the "merging" repo 
script, and then sorts that over categories, with a "rest" category for 
not yet categorized revs, and a "all" category for all revs. Which revs 
are in which categories is maintained by a simple ini file.


All category files are in html (more dense easier to read) and in .txt 
(easier to grep) format.


The main index lists all categories: 
http://www.stack.nl/~marcov/mergelogs32/


with the "rest" set being the last one. You are most probably interested 
in the "Database" subcategory:


http://www.stack.nl/~marcov/mergelogs32/fcl-db.html

http://www.stack.nl/~marcov/mergelogs32/fcl-db.txt

These are _NOT_ yet complete, some fixes to database headers are not in 
them yet. I still have a lot of the revisions from july till now to 
categorize.


but beware,  such files consists out two parts. Revisions that are 
eligible (first part), and revisions that were eligible and categorized, 
but have been merged meanwhile (second part after "(inactive) Revisions 
in this set" header).


I can do three levels of grep on this. Only on the "rest" set, which is 
the common mode, to see which new files in some category (e.g. "fcl-db/" 
) there are.


To resolve conflicts I can also search on all eligible revisions with 
the option to exclude some revision sets that contain very large files 
(very large branches merged in, and makefile regen end up there, because 
they touch many files and often grep while being non relevant.


(*) In theory, you could find out by checking what is eligible of the 
last release branch, and subtracting the eligible of the fixes branch 
from it, but I don't know yet how to do that in git.  It is also not 
perfect, there will be some pollution with e.g. version update commits.


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


Re: [fpc-devel] Preparing 3.2.4, call for merge request and regressions

2021-10-25 Thread Marco van de Voort via fpc-devel


Op 24-10-2021 om 18:13 schreef Marco van de Voort via fpc-devel:


When you have a hash, you can translate it in a "relative" revision 
number by:


git describe  | sed -nr 's/.*-(.*)-.*/\1/p'

It is basically the number of commits after the last annotation tag 
(3.3.1 in case of main).


I have the date field in the revisions, so that is not so much of a 
problem. But due to historic reasons, the program does set logic with 
stringlists of only SVN revs, and only fetches logs and other meta 
data later. So just the order of things has to change completely.


Not fundamental, just a lot of rearranging.

The base output  is starting to work somewhat. 
http://www.stack.nl/~marcov/mergelogs32/restset.html


In some output there is still a 'r' before revs, and the header parts 
(rev/date/author) are not yet nicely folded yet, making the HTML output 
less concise, but that is only makeup, I'll clean this up bit by bit.


More important is getting the actual set logic (show all uncategorized 
commits matching "fcl-pascal/" ) working again.


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


Re: [fpc-devel] Preparing 3.2.4, call for merge request and regressions

2021-10-24 Thread Marco van de Voort via fpc-devel


Op 24-10-2021 om 17:52 schreef Florian Klämpfl via fpc-devel:


This week I've been working on getting the merge logs etc working 
again. Things are showing info again, but sorting is broken (since 
you can't simply sort the revs anymore).


When you have a hash, you can translate it in a "relative" revision 
number by:


git describe  | sed -nr 's/.*-(.*)-.*/\1/p'

It is basically the number of commits after the last annotation tag 
(3.3.1 in case of main).


I have the date field in the revisions, so that is not so much of a 
problem. But due to historic reasons, the program does set logic with 
stringlists of only SVN revs, and only fetches logs and other meta data 
later. So just the order of things has to change completely.


Not fundamental, just a lot of rearranging.


Thx for the merges

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


Re: [fpc-devel] Preparing 3.2.4, call for merge request and regressions

2021-10-24 Thread Marco van de Voort via fpc-devel


Op 24-10-2021 om 14:09 schreef Florian Klämpfl via fpc-devel:



Am 10.10.2021 um 15:55 schrieb Florian Klämpfl via fpc-devel 
:

Reminder :)

So far I have only the second avr merge list from Christo open. Anything else?

Next reminder, meanwhile, I merged the avr stuff.


This week I've been working on getting the merge logs etc working again. 
Things are showing info again, but sorting is broken (since you can't 
simply sort the revs anymore).


Anyway, I grepped on my name, and found these:

622554b59fe19bf0ff1dcf18c1106db960305ef6
84507b49c217cf6cd37023a79c1cff075bb3cb03

___
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

2021-08-29 Thread Marco van de Voort via fpc-devel


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.


___
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

2021-08-25 Thread Marco van de Voort via fpc-devel


Op 8/24/2021 om 4:22 PM schreef Werner Pamler via fpc-devel:

Am 23.08.2021 um 18:14 schrieb Marco van de Voort via fpc-devel:
[...] I notice is that you point lazarus to the ppu's in the FPC 
source tree [...]
Sorry, I don't understand: There is no Lazarus involved in my build 
script. If there is, show me the line and how you would modify it.


Sorry. I'm on holiday, and I only check in occasionally at night. Try 
changing PP= to FPC=

___
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

2021-08-23 Thread Marco van de Voort via fpc-devel


Op 8/23/2021 om 4:20 PM schreef Werner Pamler via fpc-devel:

Am 23.08.2021 um 14:06 schrieb Marco van de Voort via fpc-devel:

Op 8/23/2021 om 1:36 PM schreef Werner Pamler via fpc-devel:
make install all OPT=%OPTIONS% INSTALL_PREFIX=%FPC_DEST_DIR% 
PP=%BOOTSTRAP_COMPILER%
Shouldn't this (install all) be the other way around? Classically one 
builds it before one installs it.


It does not make a difference. Now I found out that when I delete the 
units directory manually before calling the batch, everything works 
correctly, even with the OPT parameter. I thought that the "clean" 
does this?


I looked again, and the only thing atypical that I notice is that you 
point lazarus to the ppu's in the FPC source tree, while maybe via 
fpc.cfg also the installed tree is included. Though  I don't understand 
why that would cause problems.

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


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

2021-08-23 Thread Marco van de Voort via fpc-devel


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.

___
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

2021-08-23 Thread Marco van de Voort via fpc-devel


Op 8/23/2021 om 1:36 PM schreef Werner Pamler via fpc-devel:


make install all OPT=%OPTIONS% INSTALL_PREFIX=%FPC_DEST_DIR% 
PP=%BOOTSTRAP_COMPILER%


Shouldn't this (install all) be the other way around? Classically one 
builds it before one installs it.


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


[fpc-devel] chm docs 3.2.2 regenerated.

2021-07-24 Thread Marco van de Voort via fpc-devel

l.s.

It turned out that FPC 3.2.2's latex CHMs (ref/user/prog) missed TOC, 
and in Ref.chm's case index. This might trip up some IDE search 
algorithms, and direct access using CHM viewers.


The problem was due to one of the encoding related changes, which now 
has been worked around.


The new docs are on ftp as /fpc/dist/3.2.2/docs/doc-chm.zip

The original archive has been renamed doc-chmorg.zip


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


Re: [fpc-devel] Anyone an idea were/how to look for the missing merge in 3.0.2

2021-07-01 Thread Marco van de Voort via fpc-devel


Op 2021-07-01 om 01:35 schreef J. Gareth Moreton via fpc-devel:

Actually, remind me... what revision number is 3.2.0 based off?


r39628  mid august 2018


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


Re: [fpc-devel] Attn. Marco: typo in r49563

2021-06-26 Thread Marco van de Voort via fpc-devel


Op 2021-06-26 om 21:21 schreef Bart via fpc-devel:


You made a typo in the comment:
// extended colosr (from lazarus Graphics)
Should be
// extended colors (from lazarus Graphics)



Done


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


Re: [fpc-devel] mantis 0038496 custom variants and documentation

2021-05-30 Thread Marco van de Voort via fpc-devel


Op 2021-05-30 om 13:02 schreef Sven Barth via fpc-devel:




I think it is allowed to change the result type of the variant passed 
in binaryop(), but am not 100% sure, and also not sure if there are 
other things to keep an eye for (e.g. finalization of the existing 
value).


Does anybody know open source custom variant examples other than 
fmtbcd ?


The only one I'm aware of that makes use of BinaryOp is Python4Delphi 
( 
https://github.com/pyscripter/python4delphi/blob/master/Source/VarPyth.pas 
). mORMot derives its TSynInvokeableVariantType and thus its 
TDocVariant from TInvokableVariantType, but does not override the 
operator methods.


I think I saw this one before in March. I also remember the conclusion: 
this should be fixed in LefPromotion(), but FPC doesn't implement 
calling that method :-)

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


[fpc-devel] mantis 0038496 custom variants and documentation

2021-05-29 Thread Marco van de Voort via fpc-devel
Before the 3.2.2 release I looked into mantis 0038496 and now I come 
back to it.


I noticed that custom variants are completely undocumented, is this know 
(IOW should I file a bug?). What I wanted to look up are the rules for 
implementing binaryop, since that is where the problem is.


The bug is for the following code:

{$ifdef fpc}
 {$mode delphi}
{$else}
 {$apptype console}
{$endif}

uses variants,fmtbcd;
var
  fBCD1: TBcd;
  V1, V2, V3:Variant;
  L1: Integer;
begin
  L1:=123;
  fBCD1:=1234.345;

  V1:=123;
  V2:=VarFmtBCDCreate(fBCD1);
  V3:=V1 + V2;
  writeln(v3);
  readln;
end.

The addition finally ends up in  TFMTBcdFactory.BinaryOp which is 
declared as follows


procedure TFMTBcdFactory.BinaryOp(var Left: TVarData; const Right: 
TVarData; const Operation: TVarOp);


i.e.  not a 3 operand action, but a two operand.  This probably means 
that in the case of v3:=v1+v2 this is encoded as v1:=v1,v2,add, 
modifying V1.


The fmtbcd binaryop code however says that the left type (integer)  is 
not either double or a a FMTBCD custom variant and thus throws an exception.


I think it is allowed to change the result type of the variant passed in 
binaryop(), but am not 100% sure, and also not sure if there are other 
things to keep an eye for (e.g. finalization of the existing value).


Does anybody know open source custom variant examples other than fmtbcd ?






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


[fpc-devel] FPC 3.2.2 released

2021-05-21 Thread Marco van de Voort via fpc-devel

Hello,

Finally, the Free Pascal 3.2.2 release is available from our servers and 
from sourceforge.


Changes that may break backwards compatibility will be documented at:
http://wiki.freepascal.org/User_Changes_3.2.2

For an overview of what is new see the summary below

The website has been updated for the major targets and work is still 
being done for the rest.


All downloads are available at the main FTP server and sourceforge.

https://sourceforge.net/projects/freepascal/files/

ftp://ftp.freepascal.org/pub/fpc/dist/3.2.2/

Enjoy!

The Free Pascal Compiler Team



    Free Pascal Compiler

    Version 3.2.2

**

Free Pascal 3.2.2 is a minor release of the 3.2.x fixes branch. As such, it
contains mostly fixes of bugs discovered in the previous version, plus some
updates for included packages. In this case a new target was also backported
from trunk.

Please also see https://wiki.freepascal.org/User_Changes_3.2.2 for a list
of changes that may affect the behaviour of previously working code, and
how to cope with these changes.

The main highlights of this version:

Platforms:
  * New platform: aarch64-darwin
  * A new 32/64-bit combined installer for Windows.

Utilities:
  * fpcres provides support for compiling resources from *.rc files

Packages:
  * fcl-db extended with support for MySQL 8.0
  * fcl-passrc updates
  * pas2js updates
  * fpdoc updates
  * fcl-base includes new support for logging to StdOut and StdErr
  * rtl-extra includes improvements for Sockets

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


Re: [fpc-devel] Defer keyword

2021-05-06 Thread Marco van de Voort via fpc-devel


Op 2021-05-06 om 17:38 schreef Ryan Joseph via fpc-devel:

Something which annoys me about Pascal is cleanup in which a function exits in multiple 
places but there is no formal way to free memory which may be used in the current scope. 
I say ultimately Pascal needs some opt-in automatic reference counting for TObject but 
the "defer" keyword would be helpful alternative to what we have now, which is 
nothing.

The concept is very easy to understand and should be easy to implement by simply making a 
"defer" statement node which is added to a list and then called during function 
finalization like the other ref counted objects (dynamic array, interfaces etc).


But those types have refcounting built-in and always active. Things like 
defer don't, which makes that all objects gets refcounting overhead in 
case somebody needs it for "defer".


Contrary to Pascal both the language you reference have garbage 
collectors, so their objects are already managed anyway,




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


Re: [fpc-devel] FreeBSD PowerPC64 Port

2021-04-19 Thread Marco van de Voort via fpc-devel

Op 2021-04-18 om 11:40 schreef Florian Klämpfl via fpc-devel:

Am 18.04.2021 um 00:45 schrieb Curtis Hamilton via fpc-devel 
:

Is there any interest in porting FPC to Freebsd/PowerPC64?

I'm looking for some help with port FPC to FreeBSD on PowerPC.  Any assistance 
would be appreciated.


Interest in FreeBSD is apparently very little in the last years within the FPC 
universe, considering the half backend support even for x86-64.


Half backend support? Did you mean _LLVM_ backend support? There is 
none, save some work I did in Berlin.



Even more after the main FPC FreeBSD  port contributor Marco switched years ago 
to windows.


No, it was my remote shell account changing from FreeBSD on own hosted 
systems to a linux account on a commercial shared server. I mostly 
booted own systems under Windows since I left college (which, 
admittedly, in my case was fairly late)


But the real kicker was the LLVM migration that necessitates things in 
startup that I'm not capable off. Even less so with toolchains that 
randomly seem to drop sections instead of reporting an error.


I'm told that with FreeBSD13, the last lifeline, ld.bfd will be gone, 
and the last somewhat workable version(11) goes out of support in September.


If somebody can provide a base system (iow simple binaries and simple 
libc linked binaries) working on LLVM basis,  it should be easy to pick 
it up again though. Even with the old port, people often helped me with 
the startup code (Pierre with 64-bit, Florian and Jonas with 32-bit PIC 
iirc)



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


Re: [fpc-devel] Fpc on Windows, how to specify foreign chars in -oExeName commandline

2021-03-27 Thread Marco van de Voort via fpc-devel


Op 2021-03-27 om 19:11 schreef Martin Frb via fpc-devel:

On 27/03/2021 18:55, Marco van de Voort via fpc-devel wrote:


Op 2021-03-27 om 18:38 schreef Martin via fpc-devel:

On Linux I can do
fpc -oTestäあProg  MyProg.pas

On Windows the Japanese char does not seem to be possible?


Did you select a 1-byte Japanese encoding on Windows?


Probably not. I try to have my German ä and the Japanese char, both in 
the name at the same time. (And maybe add some Arabic too).


So then you don't just want Japanese chars, you want full unicode, and 
preferably as one byte system. Do you know lazarus ? ( :-) ). Try to 
build the compiler in lazarus with the default utf8 code set in the 
resources screen, and then rebuild in a "cmd /w" prompt.


Disclaimer: all from theory, I never tried. Requires Win10 1905+

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


Re: [fpc-devel] Fpc on Windows, how to specify foreign chars in -oExeName commandline

2021-03-27 Thread Marco van de Voort via fpc-devel


Op 2021-03-27 om 18:38 schreef Martin via fpc-devel:

On Linux I can do
fpc -oTestäあProg  MyProg.pas

On Windows the Japanese char does not seem to be possible?


Did you select a 1-byte Japanese encoding on Windows?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC 3.2.2-RC1 released!

2021-03-26 Thread Marco van de Voort via fpc-devel


Op 2021-03-24 om 17:26 schreef Bart via fpc-devel:

 e placed the first release candidate of the Free Pascal Compiler

version 3.2.2 on our ftp servers.

I seem to mis the win32->wince crosscompiler at
ftp://ftp.freepascal.org/pub/fpc/beta/3.2.2-rc1/i386-win32/ ?


That was a TBD, since I didn't know if there were special prerequisites 
for it, but I just tried to generate it, and it seemed to go fine.



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


Re: [fpc-devel] FPC 3.2.2-RC1 released!

2021-03-25 Thread Marco van de Voort via fpc-devel


Op 2021-03-24 om 22:14 schreef Martin Frb via fpc-devel:


Just run the testsuite. I got a few errors.

Though I did build fpc from svn myself, therefore it might be a 
problem in my setup

Below output is 64 bit Ubuntu Linux.

Is this of interest?
If yes, what info will be needed?


Current know failures for linux/x86_64 are e.g.: 
(https://www.freepascal.org/testsuite/cgi-bin/testsuite.cgi?run1id=56==568619=1=1=Show%2FCompare)



id  filenameresult
4835 
 
	test/opt/tdfa11.pp 
 
	Failed to compile
4846 
 
	test/opt/tdfa8.pp 
 
	Failed, compilation successful
3305 
 
	test/packages/webtbs/tw14265.pp 
 
	Failed to compile
5630 
 
	test/tarray15.pp 
 
	Failed to run
2893 
 
	test/timplements4a.pp 
 
	Failed to run
2894 
 
	test/timplements4b.pp 
 
	Failed to run
5896 
 
	test/treadonlydata.pp 
 
	Failed to run
2460 
 
	test/tset6.pp 
 
	Failed to compile
5991 
 
	webtbs/tw14315b.pp 
 
	Failed to run
5223 
 
	webtbs/tw29893.pp 
 
	Failed to compile
2456 
 
	webtbf/tw3930a.pp 
 
	Failed, compilation successful



Which are 11 too, so I guess those are known ones.


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


Re: [fpc-devel] FPC 3.2.2-RC1 released!

2021-03-24 Thread Marco van de Voort via fpc-devel


Op 2021-03-24 om 12:20 schreef Pierre Muller via fpc-devel:



We have placed the first release candidate of the Free Pascal Compiler
version 3.2.2 on our ftp servers.

You can help improve the upcoming 3.2.2 release by downloading and
testing this release. If you want you can report what you have done 
here:

http://wiki.freepascal.org/Testers_3.2.2 or in the maillist.

Changes that may break backwards compatibility will be documented at:
http://wiki.freepascal.org/User_Changes_3.2.2

Downloads are available at the main FTP server and

ftp://freepascal.stack.nl/pub/mirrors/fpc/beta/3.2.2-rc1/


You need to open that directory to world!


That mirror doesn't exist anymore. Please use

ftp://ftp.freepascal.org/pub/fpc/beta/3.2.2-rc1/


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


[fpc-devel] FPC 3.2.2-RC1 release, now with working link!

2021-03-24 Thread Marco van de Voort via fpc-devel

Hello,

We have placed the first release candidate of the Free Pascal Compiler
version 3.2.2 on our ftp servers.

You can help improve the upcoming 3.2.2 release by downloading and
testing this release. If you want you can report what you have done here:
http://wiki.freepascal.org/Testers_3.2.2 or in the maillist.

Changes that may break backwards compatibility will be documented at:
http://wiki.freepascal.org/User_Changes_3.2.2

Downloads are available on the main FTP server at

ftp://ftp.freepascal.org/pub/fpc/beta/3.2.2-rc1/

The evaluation time frame for this release is at least two weeks, so 
bugreports within that period will be looked at before the final release 
is branched.


Enjoy!

The Free Pascal Compiler Team


    Free Pascal Compiler

    Version 3.2.2

** 



Free Pascal 3.2.2 is a minor release of the 3.2.x fixes branch. As such, 
it contains

mostly fixes for bugs discovered in the previous version, plus some updates
for included packages. In this case a target was also backported from 
trunk.


There are currently no known changes which might result in 
incompatibility to

the previous version 3.2.0.

The main highlights of this version:

Platforms:
  * New platform: aarch64-darwin
  * A new 32/64-bit combined installer for Windows.

Utilities:
  * fpcres provides support for compiling resources from *.rc files

Packages:
  * fcl-db extended with support for MySQL 8.0
  * fcl-passrc updates
  * pas2js updates
  * fpdoc updates
  * fcl-base includes new support for logging to StdOut and StdErr
  * rtl-extra includes improvements for Sockets

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


[fpc-devel] FPC 3.2.2-RC1 released!

2021-03-24 Thread Marco van de Voort via fpc-devel

Hello,

We have placed the first release candidate of the Free Pascal Compiler
version 3.2.2 on our ftp servers.

You can help improve the upcoming 3.2.2 release by downloading and
testing this release. If you want you can report what you have done here:
http://wiki.freepascal.org/Testers_3.2.2 or in the maillist.

Changes that may break backwards compatibility will be documented at:
http://wiki.freepascal.org/User_Changes_3.2.2

Downloads are available at the main FTP server and

ftp://freepascal.stack.nl/pub/mirrors/fpc/beta/3.2.2-rc1/

The evaluation time frame for this release is at least two weeks, so 
bugreports within that period will be looked at before the final release 
is branched.


Enjoy!

The Free Pascal Compiler Team


    Free Pascal Compiler

    Version 3.2.2

** 



Free Pascal 3.2.2 is a minor release of the 3.2.x fixes branch. As such, 
it contains

mostly fixes for bugs discovered in the previous version, plus some updates
for included packages. In this case a target was also backported from 
trunk.


There are currently no known changes which might result in 
incompatibility to

the previous version 3.2.0.

The main highlights of this version:

Platforms:
  * New platform: aarch64-darwin
  * A new 32/64-bit combined installer for Windows.

Utilities:
  * fpcres provides support for compiling resources from *.rc files

Packages:
  * fcl-db extended with support for MySQL 8.0
  * fcl-passrc updates
  * pas2js updates
  * fpdoc updates
  * fcl-base includes new support for logging to StdOut and StdErr
  * rtl-extra includes improvements for Sockets

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

2020-12-10 Thread Marco van de Voort via fpc-devel


Op 2020-12-10 om 21:57 schreef Sven Barth via fpc-devel:

Am 10.12.2020 um 20:54 schrieb Bart via fpc-devel:

No fpc in your linux vm ? I'm shocked... ;-)

Well, no trunk ;-)
On Windows I know how to easily switch between using compilers.
3.2.0 is in path and I have some batch files to change that for 3.0.4
and trunk respectively (only in the current console session).
I never had the courage to figure out how to do that on linux (in such
a way it does not interfere with my normal setup).
I use a script to change symlinks that are inside a directory that's 
in PATH.



In the past I used the -V parameter a lot.

 -V  Append '-' to the used compiler binary name (e.g. for version)

This allows to make symlinks like   e.g. ppcx64-3.0  to 
/usr/local/lib/fpc/3.0.4/ppcx64  and then compile with fpc -V3.0 etc.


Of course this meant that the fpc.cfg had to be carefully crafted with 
$FPCVERSION


The biggest drawback is that it only goes for the compiler not for the 
other binaries. AND it requires a parameter, but for a quick check with 
an old/release compiler that is enough.



___
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

2020-11-25 Thread Marco van de Voort via fpc-devel


Op 2020-11-25 om 18:10 schreef J. Gareth Moreton via fpc-devel:


That's the only useful stuff I found.  Sorry to sound like such a 
novice.  I have never come across this error before and am not sure 
how to resolve it without breaking something critical.


Easiest: do an install of the relevant oracle stuff on a scratch 
machine/VM, collect DLLs and put them in a directory.


Add that directory to the front of the %PATH% in the build script., and 
that dll will be found and not the system one.



(

All my path changing scripts have the same structure:


@echo off

if "%OLDPATH%" neq "" goto :nosave
set OLDPATH=%PATH%
:nosave
SET PATH=%OLDPATH%
PATH c:\pp32\bin\i386-win32;%PATH%

This allows to undo the change by just SET PATH=%OLDPATH%, and if I 
first use cygwin and then FPC, that they are not both in the path as the 
same time


)


___
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

2020-11-24 Thread Marco van de Voort via fpc-devel


Op 2020-11-25 om 00:37 schreef J. Gareth Moreton via fpc-devel:



This might be my own configuration, but can people check that 
i386-win32 works properly? I tried to build it to test one of my new 
optimisations, but got a failure when building the trunk (without my 
optimisations).


Building using "make all install OS_TARGET=win32 CPU_TARGET=i386 
FPC=C:\FPC\3.2.0\bin\i386-win32\fpc.exe" (since my machine is 64-bit 
Windows)


Compiles fine here (but I build with parallel options, and I don't have 
that dll).


Note that you seem to be building win32, but on a win64 system 
c:\windows\system32 is 64-bit ? It could be that the windows\system32 
part that you see is virtualized, but you could see if you check the 
type of that DLL.



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


Re: [fpc-devel] Github hosting of FPC utilities and [stable] sources

2020-10-22 Thread Marco van de Voort via fpc-devel


Op 22/10/2020 om 10:01 schreef Kevin Lyda via fpc-devel:

svn checkout https://svn.freepascal.org/svn/fpc/trunk fpc-svn  8.80s
user 7.43s system 49% cpu 32.790 total
du -sh *
626M fpc-git
728M fpc-svn


To compare sizes you need to specify the SVN version. Older versions 
iirc didn't compress pristines.



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


Re: [fpc-devel] Support for FreeBSD PowerPC

2020-10-18 Thread Marco van de Voort via fpc-devel


Op 2020-10-18 om 23:03 schreef Jonas Maebe via fpc-devel:



I’ve been able to create a cross compiler using the guidance and some
additional information.  But I’ve been unable to create the proper FPC
startup code (prt0.as) needed.

Any help would be appreciated.

I believe these files are generally created by disassembling the
system's crt1.o (objdump -d) and then changing the call(s) to the libc
intialisation code with calls to the FPC RTL intialisation code.
Afaik mostly gcc -S.  Trunk SVN also contains an untested and incomplete 
attempt at translating the C startup files to pascal.

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


Re: [fpc-devel] declaration of GetCharacterPlacementW(

2020-10-05 Thread Marco van de Voort via fpc-devel


Op 05/10/2020 om 01:31 schreef Martin via fpc-devel:
function GetCharacterPlacementW(DC: HDC; p2: LPWSTR; p3, p4: BOOL; var 
p5: TGCPResults; p6: DWORD): DWORD; external 'gdi32' name 
'GetCharacterPlacementW';


Why are p3 and p4 Bool? They should be both int?

https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-getcharacterplacementw 


The var parameter generation suggests it is old, original API generation

Maybe the type changed in MSDN over time. Some things got flipped when 
the win9x and winnt winapi implementations were synchronized.


Please file a bug, and I'll add a correct overload (with int and without 
VAR param etc), and move this declaration to legacy


___
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

2020-09-27 Thread Marco van de Voort via fpc-devel


Op 2020-09-27 om 18:21 schreef Florian Klämpfl via fpc-devel:




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.


Or just block forbidden combinations wrt crossbuilding in the build 
system, rather than the release versions.

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


[fpc-devel] doc snapshot.

2020-09-10 Thread Marco van de Voort via fpc-devel

L.s.


To test the documentation generator fpdoc, I regenerated CHM 
documentation for the fixes (3.2.1) branch.


The documentation is generated with trunk fpdoc as of today, IOW with 
all the fcl-passrc modifications due to pas2js, which is the main reason 
for the test.


Location: http://www.stack.nl/~marcov/help/doc-chm202009.zip

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


Re: [fpc-devel] Merge request for 3.2 fixes

2020-07-25 Thread Marco van de Voort


Op 2020-07-25 om 21:51 schreef Benito van der Zander:



I looked in my repo, and they are in the list of regexpr fixes to merge.

http://www.stack.nl/~marcov/mergelogs32/regexr.html

If Michael "Ok"s them, I'll merge them/.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] [fpc-announce] FPC 3.2.0 released!

2020-07-04 Thread Marco van de Voort


Op 2020-07-03 om 19:18 schreef Keith Bowes via fpc-devel:

 Another thing was the Card function, which
I thought would be easy to do, as surely the code keeps track of how
many elements there are in a set, but if it does, I couldn't find it.


(Just a bit of fun, doesn't really answer your question, since obviously 
you'd need it in a ISO compatible mode. Also note that 3.2.0 branched 
over an year ago)


But 3.2.0 supports generic functions, and 3.0.0 already supported popcnt 
(https://www.freepascal.org/docs-html/rtl/system/popcnt.html).


But the syntax will be CARD(variable), and there are some minor 
things wrong with it: (anyone?)


- needs set type to be defined as type to reuse.

- what to do with a small registerable set, need const ref, but const 
[ref] is not yet supported in delphi mode?)


- and alignment requirements for the pointer walking.

- assumes unused bits in the last byte are 0. If that is unsure one 
could use the result of the AND 7 to make an and mask to mask out the 
unnecessary bits.



{$mode delphi}
{$pointermath on}

Function CARD(const a: T): Integer;
Var bits,dwords,rest,i : Integer;
    p: pbyte;
begin
  result:=0;
  p:=@a;
  bits:=(high(t)+1) ;
  dwords:=bits div 32;
  rest:=(bits mod 32); // bytes
  if (rest and 7)>0 then // round rest bits (and 7) up to whole byte (8)
    rest:=rest+8;
  rest:=rest shr 3; // bits -> bytes.
  for i:=0 to dwords-1 do
    begin
  result:=result +popcnt({unaligned?} pdword(p)^);
  inc(pdword(p));
    end;
  for i:=0 to rest-1 do
    begin
  result:=result +popcnt({unaligned?} pbyte(p)^);
  inc(p);
    end;
end;

Type TSettype = set of 0..80;

Var t : TSettype;
    i : Integer;
Begin
  t:=[];
  for i:=0 to 5 do
    Include(t,i*13);
  Writeln(CARD(t));
End.

I'll probably get back into it eventually, but I might have to redo what
I've already done, because conflicts in the Makefiles are pretty much a
certainty.  Personally, I'm nut sure why the Makefiles are included in
SVN; they should be generated `fpcmake -r` before compilation (or being
packed into a source tarball) to avoid this kind of thing.


But that would cause a bootstrap requirement on fpcmake, instead just 
the compiler. Note that recently, the generation date has been removed 
from the generate file to reduce conflicts.



Anyway, it'll be nice if we can get some more ISO 10206 features.  Some
have been popping up here and there over the years (string slices, the
** operator, WriteStr/ReadStr, etc), but a lot of useful features are
missing and seemingly have no equivalent in Borland's proprietary
dialect.


And of course schemata are the proverbial elephant in the room.


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


[fpc-devel] FPC 3.2.0 CHM docs updated.

2020-06-27 Thread Marco van de Voort

L.s.

Some problems with html and derived (CHM) documentation have come to light.

One of them was that images not generated by latex were not included in 
the documentation, specially the textmode IDE screenshots in the user 
manual.


This now has been fixed. Since documentation isn't branched in SVN, a 
handful of very minor fixes in SVN might be included too.


If you cache CHM docs for release purposes (lazarus, fpcdeluxe etc), 
please redownload.  The original archive has been renamed to 
doc-chmorig.zip in case somebody needs it.


Greetings

FPC core

p.s. the online html docs had the same problem, and also the railroad 
diagrams in the ref manual were corrupt, this was independently fixed by 
Michael.



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


[fpc-devel] HEADS UP: fixes updated to 3.2.1

2020-06-20 Thread Marco van de Voort


Now FPC 3.2.0 has been released, the version of the fixes branch has 
been updated to 3.2.1. If you maintain scripts to compile/install the 
fixes branch, they might need adjustment


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


[fpc-devel] FPC 3.2.0 released!

2020-06-20 Thread Marco van de Voort

Hello,

Finally, the Free Pascal 3.2.0 release is available from our servers and 
from sourceforge.


Changes that may break backwards compatibility will be documented at:
http://wiki.freepascal.org/User_Changes_3.2.0.

For an overview of what is new see

https://wiki.freepascal.org/FPC_New_Features_3.2

The website has been update for the major targets and work is still 
being done for the rest.


All downloads are available at the main FTP server and sourceforge.

https://sourceforge.net/projects/freepascal/files/

ftp://ftp.freepascal.org/pub/fpc/dist/3.2.0/

Enjoy!

The Free Pascal Compiler Team



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


Re: [fpc-devel] JWA 64-bit struct packing

2020-05-14 Thread Marco van de Voort


Op 2020-05-14 om 17:03 schreef Henry Vermaak via fpc-devel:

The original headers only did 32-bit. Over the years some 64-bit
corrections have been added. This process is ongoing, so please make
sure you use the newest version.

Grepping for align|packrecords give exactly the same results in trunk,
afaics.  jwawindows.pas explicitly sets align 4.


jwawindows.pas
    {$ALIGN 4}
{$ALIGN 4}
jwawinldap.pas
{$ALIGN ON}
jwawinsock2.pas
{$ALIGN 4}
jwaws2atm.pas
{$ALIGN ON}
jwaws2spi.pas
{$ALIGN OFF}
{$ALIGN ON}

But yeah, that looks bad.




I'm a bit loath to try to fix this with big, overarching $packrecords,
because the winapi actually sometimes uses packrecords C and sometimes
packrecords 8.

So why is rtl/win*/* full of packrecords c?  These pages say that the
Windows API expect 8:

https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers#controlling-structure-packing
https://docs.microsoft.com/en-gb/cpp/build/reference/zp-struct-member-alignment


Those are probably the exceptions then. But jwa* is delphi compat, so 
can't use $PUSH/$POP, so changing defaults is less useful, since it will 
be undone at the first exception



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


Re: [fpc-devel] JWA 64-bit struct packing

2020-05-14 Thread Marco van de Voort


Op 2020-05-14 om 15:53 schreef Henry Vermaak via fpc-devel:

I'm having some crashes and errors from 64-bit Windows builds that use
the JWA units.  I've tracked it down to record alignment (the 32-bit
version works fine, so it's the first place I looked).  I notice that
there's no {$packrecords c} anywhere (or alternatively {$align 8} for
64-bit).  Am I missing something?  I'm having trouble believing that
no one has found this before.


The original headers only did 32-bit. Over the years some 64-bit 
corrections have been added. This process is ongoing, so please make 
sure you use the newest version.


I'm a bit loath to try to fix this with big, overarching $packrecords, 
because the winapi actually sometimes uses packrecords C and sometimes 
packrecords 8.


Similar attempts in the normal windows headers were cumbersome, so we 
are dealing with it on a case by case basis.


If you have problems with certain structures, AND you have tested with 
trunk or FPC 3.2.0rc1, please file a bug.


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


Re: [fpc-devel] r45217 breaks Lazarus compile

2020-05-05 Thread Marco van de Voort


Op 2020-05-05 om 11:08 schreef Sven Barth via fpc-devel:


ForDebugging is just one of the purposes, and TThread.NameThread is
double, since it is a property of a thread, what else would you
give a name.


As Marco said,


? huh ?

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


Re: [fpc-devel] FPC and Z80

2020-04-27 Thread Marco van de Voort

Op 2020-04-27 om 21:24 schreef Florian Klämpfl:
Well, for 6502 working 16-bit ptr indirect via volatile zp memory 
locations needs to be implemented anyway :-)


Does that CPU have no hardware stack at all, or only limited (128/256 
bytes or so?)


It has a full stack but too little registers to use it efficiently for 
local variables: it has 3 8 bit registers pair plus accumulator (so 7 
8 bit registers), 


Then you need a parallel software stack for parameters and local vars, 
and keep the hw stack for return addresses only.


But like with the c=64 without 16-bit regs you probably need some form 
of indirect addressing via zeropage base pointers to access that stack( 
if>8bit).  IIRC the 6502 had very little free ZPs, but a lot more if you 
can reuse the locations used by the interpreter (e.g. backup/restore if 
you want to be able to return to basic)


two of them can be used as pairs for indirect addressing, so this 
makes life very hard


That is already more than the 6502 has.  Afaik the instruction pointer 
is the only 16-bit one. But if an basic interpreter can do it, so can a 
compiled program?



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


Re: [fpc-devel] FPC and Z80

2020-04-27 Thread Marco van de Voort


Op 2020-04-27 om 18:28 schreef Florian Klaempfl:



I have no idea, but quickly read through some docs, and it seems the
GameBoy CPU doesn't have IX/IY registers, which seems to be very 
useful to
implement some of the more complex references handling, according to 
what
Nikolay wrote earlier. 


Yes. IX and IY are the key for the FPC Z80 port. Without them it's 
getting really difficult. And I suspect we need to work without a 
normal stack but allocate local variables globally, so basically no 
recursion will be possible.


Well, for 6502 working 16-bit ptr indirect via volatile zp memory 
locations needs to be implemented anyway :-)


Does that CPU have no hardware stack at all, or only limited (128/256 
bytes or so?)



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


Re: [fpc-devel] New feature announcement: constant parameters for generics

2020-04-26 Thread Marco van de Voort


Op 2020-04-26 om 11:48 schreef Sven Barth via fpc-devel:


Jeppe had provided a potential usecase on the core mailing list in 
October '18. His example is not useable as-is, but to give you an idea:


 As the compiler can inline all this, the writing of maintainable, 
hardware agnostic frameworks for embedded controllers becomes easier.


(Actually you'd probably want to use atomic RMW operations, because 
otherwise a write from a thread or interrupt routine could be 
overwritten, even if it was not on bits that clash)


A further example could be to determine the size of a hash table: 
Determining that at compile time instead of runtime might allow for 
better code. At the same time the user of that code would still be 
able to influence it.


Yup. My Genlight sorted stringlist could also use it for tuning. To 
workaround the classic tstringlist ordered insertion limit, it uses an 
(dyn) array of small arrays to store the strings, which postpones the 
inevitable with about a magnitude 10-20.


The constant would be the size of the deeper array, now a weighted value 
1024.


Larger (e.g. 4096) means less memory overhead, faster iteration, but 
with slower (random) insertion performance, which can be perfectly fine 
if your datasource is mostly in order + few mutations.



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


Re: [fpc-devel] New feature announcement: constant parameters for generics

2020-04-26 Thread Marco van de Voort


Op 2020-04-26 om 11:02 schreef Michael Van Canneyt:


As the original author, can you say something about the intended use 
of this feature ?


It was meant for a pretty narrow use of array types. If I knew how 
much work it would be to implement I probably would have not done it. 
:P I personally wanted it for static array lists that had methods 
like Add/Delete.


Fixed-length arrays are the only practical use I can think of.


Valuetype sets of enum>256 elements.  Type T is the enum, const is 
ord(high(enum) div 32)+1


De const is then a high bound of the array, type T is only used to 
implement the operators and methods.



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


[fpc-devel] FPC 3.2.0RC1 released!

2020-03-29 Thread Marco van de Voort

Hello,

We have placed the first release candidate of the Free Pascal Compiler
version 3.2.0 on our ftp servers.

You can help improve the upcoming 3.2.0 release by downloading and
testing this release. If you want you can report what you have done here:
http://wiki.freepascal.org/Testers_3.2.0 or in the maillist.

Changes that may break backwards compatibility will be documented at:
http://wiki.freepascal.org/User_Changes_3.2.0

Downloads are available at the main FTP server,

ftp://ftp.freepascal.org/pub/fpc/beta/3.2.0-rc1/

Enjoy!

The Free Pascal Compiler Team

For an overview of what is new see

https://wiki.freepascal.org/FPC_New_Features_3.2

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


Re: [fpc-devel] Request for LEB128 discussion again

2020-03-19 Thread Marco van de Voort


Op 2020-03-19 om 17:00 schreef J. Gareth Moreton:

Hi everyone,

How is everyone doing? Noticed it's a bit quiet on this mailing list, 
so I hope everyone is still alive!


This one has some slightly selfish connotations, because I'm having a 
lot of problems with disk full errors on my development platform when 
working with FPC (and running "make distclean" on my FPC source 
directory freed up nearly 700 MB of storage).


(don't forget to once a year or so to svn cleanup the repos, this 
vacuums pristines)


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


Re: [fpc-devel] Typo in docs (TArray)

2020-02-23 Thread Marco van de Voort


Op 2020-02-23 om 14:55 schreef Bart via fpc-devel:

On Sun, Feb 23, 2020 at 2:08 PM Marco van de Voort
 wrote:


Docs are mostly unversioned, so there is only "trunk" atm. I corrected
it in SVN

Finding where is what in
https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/?root=docs isn't
always that easy.


I just open the relevant unit's xml, and then do a search for a phrase.

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


Re: [fpc-devel] Typo in docs (TArray)

2020-02-23 Thread Marco van de Voort

Op 2020-02-23 om 13:56 schreef Bart via fpc-devel:

https://www.freepascal.org/docs-html/rtl/sysutils/tarray.html
"it is not needed in Free Pascal, where 2 array types are equal if
they element types are equal"

"they" should be "their"

I was unable to find the trunk version of this, so I'm unsure whether
this might already be fixed.


Docs are mostly unversioned, so there is only "trunk" atm. I corrected 
it in SVN


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


Re: [fpc-devel] Linux Binary - Socket Output affected by SystemCtl, HELP!

2020-01-29 Thread Marco van de Voort


Op 29/01/2020 om 16:07 schreef Ozz Nixon via fpc-devel:

1. My code does not directly interact with any environment variables.


Unit cwstring and clocale might do on startup. This might influence e.g. 
widestring/unicodestring<-> ansistring conversions and back.



2. I am using version 2.6.4 to compile the daemon.

That makes encoding debugging quite more difficult, as 2.6.4 behaves 
differently from 3.0.x in that regard.




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


Re: [fpc-devel] Linux Binary - Socket Output affected by SystemCtl, HELP!

2020-01-29 Thread Marco van de Voort


Op 29/01/2020 om 14:54 schreef Ozz Nixon via fpc-devel:

Would/Could, LANG/LOCALE affect socket output?

* I personally do not touch environment variables - so I am not sure 
what to ever try. The "client" (Telnet) I have tried Terminal.App, 
iTerm2, Putty.exe, Telnet.exe, xTerm-256, fTelnet, etc. all clients on 
all 3 OSes render '?' from the daemon if systemctl starts it, again, 
if I just start the fpc binary from a shell'd session, ./program - it 
works fine on all 3 OSes that previously show '?'. I have tcpdump'd 
the socket, it sends '?' when ran under systemctl, however, sends the 
8bit character when ran manually on the command line.



Afaik the unicode manager (cwstring)initializes using those 
environmentvariables


Note the best way to check is to use a binary client that dumps data as 
hex, or wireshark.


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


Re: [fpc-devel] Linux Binary - Socket Output affected by SystemCtl, HELP!

2020-01-29 Thread Marco van de Voort


Op 29/01/2020 om 14:23 schreef Ozz Nixon via fpc-devel:
I am not sure how this is occurring, however, my socket daemon on 
Linux - is launched by hand ./program is able to send to the socket:


Socket.Write(#218+#196+#191);

And the terminal (any) will display the single highbit characters.

If systemctl start myprogram... that same call sends '???'. Same 
binary, not recompiled or anything. Then I do systemctl stop 
myprogram, and ./program connect to it, and I get the single highbit 
characters again.


I have googled everything I could think of for FPC and SYSTEMCTL, to 
see if either have documented this - without success. Since you guys 
know what the compiler is producing, and all these tricks you guys do 
for UTF8, CP437, etc... I decided to give up and ask you guys - any 
idea what is going on?


* The other challenge is, this just started a week ago. the 
myprogram.service file has not been modified, nothing for the OS had 
been modified, I just noticed one day - the code I use for UTF8 auto 
detection was showing  ... and then ran my 8bit test, and noticed 
ever character 0x80+ displays as '?'.



LANG or LOCALE environment variables ?

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


Re: [fpc-devel] TEncoding.Default and default encoding for TStrings.LoadFrom*()

2019-12-26 Thread Marco van de Voort

Op 12/26/2019 om 9:12 PM schreef Ondrej Pokorny:


In Delphi TEncoding.ANSI and TEncoding.Default are actually different. 
See:
http://docwiki.embarcadero.com/Libraries/Rio/en/System.SysUtils.TEncoding.Default 

http://docwiki.embarcadero.com/Libraries/Rio/en/System.SysUtils.TEncoding.ANSI 



On Windows, they are equal but on POSIX they are different: 
TEncoding.Default is UTF-8 but TEncoding.ANSI is the code page from 
CFLocaleGetIdentifier.


And in FPC it is exactly the same, BUT Lazarus overrides default with 
UTF8 on Windows. As you can see that is NOT compatible with Delphi above.


Worse, since the startup encoding is the encoding to communicate with 
the OS, as soon as



Read the .NET docs about Encoding.Default:
https://docs.microsoft.com/en-us/dotnet/api/system.text.encoding.default?redirectedfrom=MSDN=netframework-4.8#System_Text_Encoding_Default 

on .NET Framework it is ANSI but on .NET Core it is UTF-8 even on 


Yes, totally irrelevant. On Windows ansi means something like 
Windows-1252 and  -A apis, and the only unicode api is -W and UTF8. .NET 
is as relevant as Linux in this matter; other application API.


With all the information from the docs, I am more and more convinced 
that TEncoding.SystemEncoding is superfluous and TEncoding.Default 
should take over its meaning: TEncoding.Default should reflect changes 
in DefaultSystemCodePage. Whereas TEncoding.ANSI should stay a fixed 
ANSI code page. With it there is no need for TEncoding.SystemEncoding.
The defaultsystemencoding changes the meaning of the codepage for the 
application libraries (read: the pascal parts), NOT for the delphi api.




With this change, in the current Lazarus UTF-8 solution, 
TEncoding.Default will be UTF-8. In the future Unicode and 
Delphi-compatible FPC/Lazarus, TEncoding.Default will get the Delphi 
meaning (ANSI/UTF-8). IMO the concept is very sensible.

Delphi is UTF-16. UTF-8 is only used for document formats, not for APIs.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] inline... and philosophy

2019-12-16 Thread Marco van de Voort


Op 2019-11-21 om 22:56 schreef Sven Barth via fpc-devel:
In the meantime I've managed to fix the dynamic package support that 
had experienced a bit of bit rot in the last years. Though I've 
currently only tested Win32 and Win64 (x86_64-linux as well as 
*-darwin *should* work as well). And as before only compile time 
packages are supported.


(I noticed I hadn't replied to this msg).  Indeed quite sizable. I also 
don't like the subdivision in many packages.


Could it be that still simply too many symbols are exported ?


For those that are interested, the sizes of the binaries for chmls are 
as follows:


=== output win32 begin ===

2633984 rtl.dll
414820 rtl.objpas.dll
247060 rtl.extra.dll
364625 rtl.generics.dll
389888 fcl.res.dll
788664 fcl.base.dll
962560 fcl.xml.dll
953676 chm.dll
68694 chmls.exe


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


Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

2019-12-10 Thread Marco van de Voort

Op 2019-12-08 om 22:08 schreef Ryan Joseph via fpc-devel:

On Dec 8, 2019, at 2:30 PM, Sven Barth via fpc-devel 
 wrote:

And no, your patch WILL NOT allow that. We've consciously decided AGAINST 
implementing varargs functions in Pascal (see 
https://wiki.freepascal.org/User_Changes_2.6.0#Array_of_const_parameters_and_cdecl_routines
 ) and we DO NOT WANT to support this.

Sorry to interject but I'm just curious why this hardline stance was taken.

Are the valist implementations for gcc,LLVM and msvc the same ?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] certain divisions in single precision only

2019-12-08 Thread Marco van de Voort


Op 2019-12-08 om 18:46 schreef Jonas Maebe:

-i386 delphi was available).
Actually, back then I thought I fixed the (dynamic) behaviour at least
in a Delphi-compatible way: https://bugs.freepascal.org/view.php?id=7179

I don't remember anymore on what test this assumption was based though.

Afaik Delphi x64 doesn't do single math at all, and converts each 
load/store from single to double, and only operates on doubles



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


[fpc-devel] freebsd 12.1

2019-12-02 Thread Marco van de Voort
I did some investigations on the FreeBSD problems yesterday, with some 
results:


FreeBSD 12.1 x86_64:

1 starting compiler 3.0.4 might misalign sections. Linker LLD simply silently 
fails to reads objects with non aligned sections. (32-bit? 64-bit? both?) -> 
always use BFD with starting compiler.
2 Don Alfredo: compile works with -dFPC_USE_LIBC: true but needs ld.bfd 
(because of (1)?  tbt)
-> FPC stat record definition doesn't change in that case. Maybe only 
syscall nr changed but not record definition? TBD/TBT
3 "old syscalls" I replaced lseek, mmap and ftruncate with newer variants (300 something) 
that seem to omit the zeroed registers. Result remains the same "can't find ../"
I used a defined FREEBSDNEWSYSCALL for this (not committed yet, I don't 
have internet atm, this goes out via mobile)
-> sounds like canocalization problem (fexpand). I see getcwd output in truss but 
they all return "0".  Seems getcwd does a lot of calls to the same directory.
-> disable getcwd usage and do it the old way tbt
4 tried truss but there are very few syscalls in the output. I don't trust the 
result very much. I see that it calls stat11, so stat syscall number is also 
old.


issues to be resolved:
- syscall port still doesn't work
- compiler needs parameter to force compiler to use ld.bfd or just ld. (or 
lld?) So probably setting name of linker in general. I don't like to use 
platform specific environment variables, as FreeBSD suggests.
-


0. edit compiler/targets/t_bsd.pas. Go to method TLinkerBSD.setdefaultinfo and set 
"linkerprogram" to "ld.bfd"
1. install binutils
2. execute EXPORT PATH=/usr/local/bin:$PATH-> this puts ld.bfd in 
/usr/local/bin before the one in /usr/bin and can be used to overcome the 3.0.4 
bootstrap problems.
3  make with OPT=-dFPC_USE_LIBC

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


Re: [fpc-devel] When will the next version of FPC be released?

2019-11-30 Thread Marco van de Voort


Op 2019-11-30 om 09:29 schreef Gabor Boros:

2019. 05. 30. 9:05 keltezéssel, Michael Van Canneyt írta:

I would not count on it before september, and even that is "iffy".


Any news/update in this subject?

The fixes_3_2 branch created more than a year ago and the latest 
stable (3.0.4) released 2 years ago.



Not much movement. My hope for a christmas holiday release is mostly gone.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] vmul commutative optimization?

2019-11-17 Thread Marco van de Voort


Op 2019-11-17 om 15:49 schreef Florian Klämpfl:


This was an easy one :) Fixed in r43509


Thanks, here is an harder one:

https://bugs.freepascal.org/view.php?id=36324

(  :-) )

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


Re: [fpc-devel] vmul commutative optimization?

2019-11-15 Thread Marco van de Voort


Op 14/11/2019 om 01:14 schreef J. Gareth Moreton:



I guess that means testing with VS?


Testing with Visual Studio or even GCC under Windows is a good idea if 
you want to be sure how particular record types are transferred.  The 
example given in that article has two fields of type __m128, even 
though it looks like only one of the four vector elements are used 
initially.  Regardless, under the default Microsoft calling 
convention, that would be passed by reference, just like a record of 
two Doubles.  A (packed) record of two Singles would be passed by 
value in an integer register, just to cause trouble with conversions!


To be clear: I meant if  2 single 64-bit vectors are registered in XMM 
instead of integer fields with vectorcall


It was more meant as a research point, I don't need it anymore. After 
realizing that I either need autovectorizing or intrinsics I simply 
started doing a simple translation to assembler, a naive 1:1 translation 
(but then with complex as two singles in an XMM). Bit of fiddling to 
define multiplying with j in xmm assembler (Doing NOT on one of both 
singles), but otherwise simple.


I got the first stage (the radix funtions for the radices that I use, 
4,5,10) and got things working, and both speed and instruction count 
divided by 3.  (not entirely 100% logical, since the asm version has 
relatively more complex instructions).


Under vectorcall, a record of two Singles would be treated as a 
Homogeneous Float Aggregate and pass the two fields in XMM0 and XMM1


Afaik FPC doesn't do that yet. It passed in an int  register. Pity. as 
_m64 register it would have been nice for complex-with-singles.


, and the same thing happens with an unaligned record of two Doubles.  
If a record of two Doubles is aligned to a 16-byte boundary though, or 
is otherwise a union with a __m128 type (with the two Doubles aliased 
to the lower and upper 64 bits respectively), then it can be passed in 
its entirety through XMM0.


Some things are a little bit messy and opaque with __m128 though, and 
just making an aligned array of 4 Singles or 2 Doubles doesn't always 
work - it needs to be typecast through __m128 in some way - but I 
think that's mostly because C++ wasn't really designed with alignment 
in mind.  In Free Pascal, you have to make a bit of a messy union to 
ensure everything works; for example:


I already use that union copied from your patch, but then changed to 
singles. But doesn't do much.


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


Re: [fpc-devel] vmul commutative optimization?

2019-11-13 Thread Marco van de Voort


Op 2019-11-12 om 20:46 schreef J. Gareth Moreton:


The Microsoft ABI is a bit restrictive when it comes to record types; 
as described here 
, 
"Structs and unions of size 8, 16, 32, or 64 bits, and __m64 types, 
are passed as if they were integers of the same size." So 
unfortunately, a single-precision complex number is treated as a 
64-bit structure and passed as an integer.  The System V ABI, on the 
other hand, would pass the two entries through the lower 64 bits of 
XMM0.  Vectorcall, theoretically, should put the two components into 
XMM0 and XMM1, because the complex type would be considered a 
"homogeneous vector aggregate" (with floats as 1-dimensional vectors).


I've found refs like 
https://devblogs.microsoft.com/cppblog/introducing-vector-calling-convention/#comments 
so the question is if partial vectors (and specially 2 single 8-byte, 
since there are various special SSE opcodes to deal with them) are one 
register or not. The references I found usually talk about "vector types 
like _m128 and _m256), but don't really specify an exhaustive list.



I guess that means testing with VS?


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


Re: [fpc-devel] vmul commutative optimization?

2019-11-12 Thread Marco van de Voort


Op 12/11/2019 om 16:08 schreef J. Gareth Moreton:
It's true.  With VMULSS, only the first parameter (third parameter 
under Intel notation) can be an address (source: Intel(R) 64 and IA-32 
Architectures Software Development Manual, Volume 2B, Page 4-154).


I'll see if I can work in that optimisation for the commutative 
operations (+ and *) at some point from the node side.


Thanks.

Another tidbit I noticed while playing with  (elements of) the complex 
patch is that if I set the elementsize to double (re:double;im:double) 
that with vectorcall loads all data into registers.


However if I make it single, (iow the tcomplex is 8-byte), the records 
are loaded into integer registers, and the compiler stores them to the 
stack and then reloads them.


This matters less for me since it won't vectorize anyway (see inline and 
philosophy thread) I'll change this routine to assembler I think, 
accepting a pointer and load and store from that thread.


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


[fpc-devel] vmul commutative optimization?

2019-11-12 Thread Marco van de Voort

I compiled some bits with avx, and noticed that when you do

asingle:=someconstant*othersingle;

then that generates something like

    vmovss    TC_$FFTS_$$_C31(%rip),%xmm2
    vmulss    %xmm0,%xmm2,%xmm0

while if you do

asingle:=othersingle*someconstant;

it generates

    vmulss    TC_$FFTS_$$_C32(%rip),%xmm2,%xmm2


I assume the reason is that only the first param can be an address, and 
the second a register. But the compiler isn't smart enough to exchange them.


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


Re: [fpc-devel] inline... and philosophy

2019-11-11 Thread Marco van de Voort


Op 10/11/2019 om 16:02 schreef J. Gareth Moreton:
This message chain has proven to be a lot more educational and 
insightful than I would have given it credit for.  Thanks everybody!


I know a lot of the time, the size of binaries is just an illusion, 
along with unfair comparisons with GCC (a behemoth with corporate 
support) and Microsoft Visual C++ that often hides the size of 
binaries behind a redistributable library.  I don't ever seek to make 
binaries smaller at the expense of speed, but if I see a potential 
saving that could be done automatically, I dive for it!


Keep in mind that the size differences (if more than a few percent) are 
usually not really compiler efficiency related, but more due to other 
reasons like framework architecture(RTTI, class registration), 
redistributable libraries (MSVCRT,QT) etc. Winapi binaries can be quite 
tight on FPC too. LCL is simply a bit more high level. Not just higher 
level than winapi but higher level than MFC too.


(and btw, if you are serious about these scenarios, drop all 
optimization work immediately, and start working on packages :-)


I did try to start simple with the 'uComplex' unit, but concerns were 
raised because I changed the formal parameters to 'const' and aligned 
the complex type on x86-64 platforms so it can take advantage of XMM 
registers better (which, given proper optimisation, would result in 
both smaller code size and higher speed).  While I made sure that the 
interfaces would not change for Pascal code, assembler code that calls 
the functions (if it exists) might need to be changed slightly 
(something Florian raised).  I'm not quite sure what the rules are 
when it comes fo updating packages, other than the obvious one of not 
breaking old code.



I tested the ucomplex with my ffts testcase yesterday btw. I saw no 
differences but it turned out that


- I work with a "single" based complex record ->  record is 8 byte, so 
doesn't really benefit from vectorcall.


- the fft unit doesn't have procedures with value parameters that are 
not inlined anyway.


- no vectorization whatsoever, so no add a complex in one step. Probably 
needs either vectorizer or intrinsics.


The only other thing I noticed is that it seems that the compiler only 
uses XMM0, occasionally XMM1  and extremely rarely XMM2. Seems there is 
no register variables for XMM floating point?




I like working on optimisation because I have a morbid fascination 
with the lowest level of the CPU and I feel well-suited for it, 
although there are still some things I'm learning about it.


There is nothing wrong with that.  But it is wise to lot lose track of 
magnitudes.

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


Re: [fpc-devel] inline... and philosophy

2019-11-10 Thread Marco van de Voort


Op 09/11/2019 om 15:51 schreef J. Gareth Moreton:


Competitions aside, there are times where space is a premium, whether 
it be from distributing an application on a DVD, bandwidth or data 
limits (even some first world countries are still on dial-up in 
places, or are otherwise monopolised by a single, bad-quality 
provider), the smaller capacity of solid-state hard drives (especially 
on some laptops) and can otherwise be a money saver sometimes.


Maybe. But what the faq warnes against is in using these kind of 
scenarios to retroactive justify old dos era sentiments.  Even small 
SSDs are huge compared to FPC binaries, and the possible gains are 
really not that high. Constrained pipes usually already employ 
compression, and a few percent really doesn't save that much anyway.


It is not a bad thing to dive into binary sizes, but keep it to the 
point, and try to quantify savings in larger programs (e.g. the compiler 
or lazarus). Get a feel for what changes are worth it and what not, but 
be warned, there is much less to gain than people think.


(and btw, if you are serious about these scenarios, drop all 
optimization work immediately, and start working on packages :-)




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


Re: [fpc-devel] inline... and philosophy

2019-11-10 Thread Marco van de Voort


Op 10/11/2019 om 11:17 schreef Marģers . via fpc-devel

 Most processors have a fairly large uop cache (up to 2048 for the newest

generations iirc), so this would only be for the first iteration? Do you
have a reference (agner fog page or so) or more explanation for this
that describes this?)

I have to revoke my statement. Don't have evidence to back up. Code, that lead 
me to thous conclusions, has been discarded.
  I have read most whats published in agner's fog page. There nothing to 
pinpoint as reference.
No prob. Was just interested, I had to do some sse/avx code the last 
years, and hadn't heard of this.

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


Re: [fpc-devel] Attn Michael: r 43417 (ordinal bithelpers)

2019-11-09 Thread Marco van de Voort


Op 2019-11-09 om 18:29 schreef Florian Klämpfl:


And you don't call this unix only docompile.sh not cumbersome with the 
compiler parameters in some configuration file?




I definitely want to help to integrate the tests somehow in the daily 
testrun, but I will not use the slow testsuite.


As said, this is one of the void arguments, on a modern CPU it takes 
<1 min.



I hope that is not a unix only figure :-)
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Attn Michael: r 43417 (ordinal bithelpers)

2019-11-09 Thread Marco van de Voort


Op 2019-11-09 om 18:28 schreef Jonas Maebe:

That's why I proposed to add support for running only the tests specific
to the RTL and/or specific units.

A tagging system for tests in the .pp tests might be the best? 
Occasionally some central admin would have to be updated (automatically) 
and committed. This could even be a byproduct of some nightly run. Then 
just run enable the drive to run the testsuite for certain tags? (RTL or 
a specific unit).


This means that tests adding won't really change, but partial runs 
become possible.


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


Re: [fpc-devel] inline... and philosophy

2019-11-09 Thread Marco van de Voort


Op 2019-11-09 om 02:24 schreef Marģers . via fpc-devel:
  
3) it changes code location (code cross page boundaries). For my particular cpu there are 64 byte code page. If loop can fit in it, speed is twice as it overlaps even one byte over page boundary. Jumping forward is ok (as expected code flow is always forward). And there is lager page few kb - calling outside - small penalty.


Most processors have a fairly large uop cache (up to 2048 for the newest 
generations iirc), so this would only be for the first iteration? Do you 
have a reference (agner fog page or so) or more explanation for this 
that describes this?)



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


Re: [fpc-devel] inline... and philosophy

2019-11-09 Thread Marco van de Voort


Op 2019-11-08 om 23:37 schreef J. Gareth Moreton:
It is a good point.  With my C++ programs, I tend to compile with 
everything statically linked and self-contained, since it tends to be 
smaller than a dynamically-linked program plus the redistributable 
combined (and the risk of "DLL Hell" means you can't just install the 
redistributable in the System directory). Granted, it's useful if you 
are shipping a lot of small utilities together.  Admittedly, FPC might 
benefit from the dynamically-linked redistributable.  A workplace that 
I was once doing a contract for turned down my request to have FPC 
installed because there were too many EXE files to add to their 
exceptions list (the company dealt with financial data, so they were 
extra-paranoid about what gets installed on their workstations).


Did you btw read the size matters wikipedia entry? It has some hints 
about common pitfalls? (like measuring too small binaries, or pure 
winapi ones vs one with a framework behind it)


https://wiki.freepascal.org/Size_Matters

Does smart linking strip out elements of the RTL that aren't used? 
Granted, I'm trying to think of an example off the top of my head - I 
was going to say "WriteLn", but I can see the internal functions using 
them for stack traces and exception handling.


Yes. It simply starts with the entrypoint(s) and starts marking 
reachable symbols. I tried to summarize this a bit in this post:


https://stackoverflow.com/questions/4519726/delphi-which-are-the-downsides-of-having-unused-units-listed-in-the-uses-clause/4519894#4519894



I do hope I'm not a person who people wish to avoid... I've gotten too 
passionate for my own good a couple of times.  I do want to learn 
everything I can when it comes to the inner workings of a binary 
(admittedly I'm currently locked to Intel platforms, but that may 
change in future).  The warning of 'blobing' as a reason against 
inlining single-use functions was never something I was introduced to 
or was really documented anywhere, so I didn't really know any 
better.  I'm still guessing what is meant by 'blobing', but hopefully 
I can learn soon enough.


Don't worry too much. Just remain constructive and it will all sort out.



Seeking to reduce binary size (without sacrificing speed) and make as 
many optimisations as possible may be a fool's errand because the 
returns don't justify the costs, but I personally enjoy the challenge 
and puzzle-solving element of it.  I just hope I haven't scared off 
the administrators when I argued with Florian on my jump optimisations 
(the aforementioned inline/blobing issue).


Start with asking why you feel the need to do it, and how much would be 
enough.

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


Re: [fpc-devel] Question on updating FPC packages

2019-10-31 Thread Marco van de Voort


Op 2019-10-30 om 23:02 schreef Florian Klämpfl:


Yes. And manually adding inline is only as good as the knowledge of 
the user doing so. If somebody implements it right (I did not, I used 
the easiest approach and used an existing function to estimate the 
complexity of a subroutine). The compiler can just count the number of 
the generate instructions or even calculate the length of the 
procedure and then decide to keep the node tree for inlining.


Well, it depends of course of what happens when. Would you really count 
final instructions or cycles after all optimization and peephole passes ?



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


Re: [fpc-devel] Question on updating FPC packages

2019-10-29 Thread Marco van de Voort


Op 2019-10-27 om 10:27 schreef Michael Van Canneyt:



Absolutely.

Personally, I don't have any concern for performance in this sense. 
Almost zero.
I invariably favour code simplicity over performance, for sake of 
maintenance.


But there is another kick-in-the-open-door statement about performance: 
That the most performance is gained in a relative small part of the code.


To tackle that you need tools to force the compiler to behave a certain 
way that might not (yet?) be doable on the compiler side. IMHO it is 
unfair to deem this all microoptimization just because it doesn't hurt you.




For good reason: for the kind of code which I create daily, the kind of
micro-optimizations that you seem to refer to, are utterly insignificant,
and I expect the compiler to handle them. If it currently does not, 
then I

think the compiler, rather than the code, must be improved.


Just the vectorizing will probably more than double the performance. 
Just look at the asm that I posted and imagine reducing it to one 
instruction.


And while set FFT unit is not yet a performance bottle neck  for us now, 
it has been marked as a relative large factor of the measurement time. 
(iirc it is about 1ms for a 400 sample array on somewhat older hardware)


And what is exactly needed might change at any given moment. If a new 
camera comes out, if processing can keep up you can process more samples 
which in turn reduces errors and improves the measurement nearly 
automatically


Doing the same purely algorithmically usually means  weeks-months of 
hard maths trying to improve signal quality, and after that validating 
that for umpteen products and customers etc etc. Believe me, 
"Microoptimization" then sounds very tempting.


If Gareth can get this running enough to show that the FFT reduces 
instructions, I can just stuff it in a DLL, and have it lying on a shelf 
to insert into the Delphi app when needed. Which would be great.


Code should not entirely disregard optimization, but then it should be 
on a

higher level: don't use bubble sort when you can use a better sort. No
amount of micro-optimization will make bubble sort outperform quickort.


(

Interesting example, I'm not really a hardcore algorithms man, but I can 
think of some potential problems with that statement:


1 that only goes for N->Infinity and that computers don't have infinite 
resources. If quicksort uses more memory (e.g. to track state) it might 
not apply in certain circumstances.


2   if your swap() function is extremely expensive, sorting an already 
sorted array is more expensive with quicksort because it is a non stable 
sort.


3 the non recursive bubble sort might be easier to unroll and then 
optimize by the compiler in cases of sorting a fixed number of items. 
(e.g. ordering the elements of a short vector)


)

Anyway, besides the fun, the "algorithms" mantra is only a first order 
guideline, not an absolute truth.


Saying that the code is 'almost unusably slow' is the kind of 
statement that does

not help. I use the code almost daily in production, no complaints about
performance, so clearly it is usable.


True. Claims should be proven, and with code that does something (not 
with simply a loop around a single operation)


But that is why I brought up the FFT unit. It is possible that that is 
such a case.



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


Re: [fpc-devel] Question on updating FPC packages

2019-10-29 Thread Marco van de Voort


Op 2019-10-27 om 10:46 schreef Florian Klämpfl:

Am 27.10.19 um 10:27 schrieb Michael Van Canneyt:
If you genuinely believe that micro-optimization changes can make a 
difference:


Submit patches. 


As said: I am against applying them. Why? They clutter code and after 
all, they make assumptions about the current target which not might be 
always valid. And time testing them is much better spent in improving 
the compiler and then all code benefits. Another point: for example 
explicit inline increases normally code size (not always but often), 
so it is against the use of -Os. Applying inline manually on umpteen 
subroutines makes no sense. Better improve auto inlining.


Auto inlining is also no panacea.   It only works with heuristics, and 
is thus only as good as a formula of the heuristic.


Changing calling conventions, vectorizing, loops all complicates that, 
and it will never be perfect, and a change here will lead to a problem 
there etc.


If you know a routine can evaluate to one instruction in most cases, I 
don't see anything wrong with just marking it as such.



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


Re: [fpc-devel] Question on updating FPC packages

2019-10-29 Thread Marco van de Voort


Op 2019-10-29 om 12:23 schreef J. Gareth Moreton:
When it comes to testing vectorcall, uComplex isn't the best example 
actually because most of the operators are inlined.  There are a 
number of tests under "tests/test/cg" that test vectorcall and the 
System V ABI using a Pascal implementation of the opaque __m128 type 
(the two ABIs should behave exactly the same when dealing with simple 
vectors).


The last time I checked it didn't vector anything at all. So only the 
native vectorizing of the record of two singles would be nice.


Last time I checked in 2017, complexadd inlined looked something like this:

    leal    32(%eax),%edx
    leal    8(%eax),%ecx
    vmovss    (%ecx),%xmm0
    vaddss    (%edx),%xmm0,%xmm0
    vmovss    %xmm0,-8(%ebp)
    vmovss    4(%ecx),%xmm0
    vaddss    4(%edx),%xmm0,%xmm0
    vmovss    %xmm0,-4(%ebp)

And I realize quite some rearrangements must be done.



If anything though, the example function you gave (I'll need to 
double-check what ComplexScl does though, if it isn't a simple 
multiplication) 


It is simple multiplication of both real and imaginary with a scalar (as 
opposed to complex*complex which has more terms).


would be a pretty solid and heavy-duty test of the compiler attempting 
to vectorise the code - in an ideal world, individual calls to 
ComplexAdd and ComplexSub (which are simple + and - operations in 
uComplex) will compile into a single line of assembly language (ADDPD 
and SUBPD respectively).  Nevertheless, one could disable the inlining 
to see how well the compiler handles the function chaining, since with 
aligned data, the result from XMM0 should be easily transposed in one 
go to another XMM register if not just left alone as parameter data 
for the next function.



Yes, it is just a somewhat realworld codebase to play with. It is MPL even.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Question on updating FPC packages

2019-10-29 Thread Marco van de Voort


Op 2019-10-27 om 09:02 schreef Florian Klämpfl:
I guess you're right.  It just seems weird because the System V ABI 
was designed from the start to use the MM registers fully, so long as 
the data is aligned.  In effect, it had vectorcall wrapped into its 
design from the start.  Granted, vectorcall has some advantages and 
can deal with relatively complex aggregates that the System V ABI 
cannot handle (for example, a record type that contains a normal 
vector and information relating to bump mapping).


I just hoped that making updates to uComplex, while ensuring existing 
Pascal code still compiles, would help take advantage of modern ABI 
designs.


Is there currently any example which shows that vectorcall has any 
advantage with FPC? Else I would propose first to make FPC able to 
take advantage of it and then talk about if we really add vectorcall. 
Currently I fear, FPC gets only into trouble when using vectorcall as 
it tries first to push everything into one xmm register and then 
splits this again in the callee.


Nils Haeck's FFT unit might be interesting. (same guy as nativejpg unit 
iirc, http://www.simdesign.nl)


It is a D7 language level unit that uses a complex record and simple 
procedures as options. It should be easy to transpose to ucomplex. It is 
quite hll and switchable between single and double. (I use it in single 
mode, but to test vectorcall, obviously double mode would be best?)


And it has routines that do a variety of complex operations.

procedure FFT_5(var Z: array of TComplex); // usage of open array is to 
make things generic. Could be solved differently.


var
  T1, T2, T3, T4, T5: TComplex;
  M1, M2, M3, M4, M5: TComplex;
  S1, S2, S3, S4, S5: TComplex;
begin
  T1 := ComplexAdd(Z[1], Z[4]);
  T2 := ComplexAdd(Z[2], Z[3]);
  T3 := ComplexSub(Z[1], Z[4]);
  T4 := ComplexSub(Z[3], Z[2]);

  T5   := ComplexAdd(T1, T2);
  Z[0] := ComplexAdd(Z[0], T5);
  M1   := ComplexScl(c51, T5);
  M2   := ComplexScl(c52, ComplexSub(T1, T2));

  M3.Re := -c53 * (T3.Im + T4.Im);  // replace by 
i*add(t3,t4).scale(c53-i*c53) ?

  M3.Im :=  c53 * (T3.Re + T4.Re);
  M4.Re := -c54 * T4.Im;
  M4.Im :=  c54 * T4.Re;
  M5.Re := -c55 * T3.Im;
  M5.Im :=  c55 * T3.Re;

  S3 := ComplexSub(M3, M4);
  S5 := ComplexAdd(M3, M5);;
  S1 := ComplexAdd(Z[0], M1);
  S2 := ComplexAdd(S1, M2);
  S4 := ComplexSub(S1, M2);

  Z[1] := ComplexAdd(S2, S3);
  Z[2] := ComplexAdd(S4, S5);
  Z[3] := ComplexSub(S4, S5);
  Z[4] := ComplexSub(S2, S3);
end;

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


[fpc-devel] invoke

2019-10-22 Thread Marco van de Voort


https://forum.lazarus.freepascal.org/index.php/topic,47147.0/topicseen.html

might be of interest to you despite the title :-) It is about 
invoke/tvirtualinterface


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


Re: [fpc-devel] Language semantic suggesion regarding static methods

2019-10-22 Thread Marco van de Voort


Op 2019-10-22 om 01:19 schreef J. Gareth Moreton:


For backward compatibility, I would suggest keeping the 'static' 
directive for class methods so existing code doesn't break, but maybe 
mark it as deprecated.



We need less dialectal variety, not more. The ambiguity of having two 
forms in code bases is worse then any benefit the change could every have.


People with established code habits and/or Delphi usage will stick with 
old, and new users might adopt the new if promoted enough. Result: chaos.



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


Re: [fpc-devel] objfpc generics how to generate self type reference ?

2019-09-03 Thread Marco van de Voort


Op 2019-09-03 om 13:11 schreef Mattias Gaertner via fpc-devel:



Inside the generic the templates are normal types:

   TIteratorType = specialize THashmapIterator;

Btw, mode objfpc allows shortcut THashmapIterator without <> as
shortcut for "specialize THashmapIterator";


It works, thanks. I'm sure I tried it, but probably some editing mishap 
obscured the result.


This is better than reworking to nested classes because it is backwards 
compat. (though gvector does use nested class as iterator)


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


Re: [fpc-devel] for .. in documentation and classes based iterators.

2019-09-03 Thread Marco van de Voort


Op 2019-09-03 om 12:59 schreef Michael Van Canneyt:


"5. Any type for which an enumerator operator is defined. The 
enumerator operator must return a structured type that implements the 
IEnumerator interface. The type of the control variable’s type must 
equal the type of the enumerator’s GetCurrent return value type."


but maybe that could be said more explicitly?


What should be said more explicitly ?
What does the delphi duck typing method getenumerator():TIterator; do 
with the iterator if it is of a classtype (not interface)? Where does it 
fit in the 5 cases outlined in the documentation article? Probably 5, 
but that only talks about the enumerator operator.

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


[fpc-devel] for .. in documentation and classes based iterators.

2019-09-03 Thread Marco van de Voort


I did an initial patch to add for..in iterator support in fcl-stl 
ghashmap (https://bugs.freepascal.org/view.php?id=35940)


I've looked at the docs of for..in, and it doesn't seem to name the 
delphi getenumerator() method in its options. I assume it is equal to 
point 5, the enumerator operator, because a for..in this way doesn't 
cause a memory leak.


"5. Any type for which an enumerator operator is defined. The enumerator 
operator must return a structured type that implements the IEnumerator 
interface. The type of the control variable’s type must equal the type 
of the enumerator’s GetCurrent return value type."


but maybe that could be said more explicitly?

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


[fpc-devel] objfpc generics how to generate self type reference ?

2019-09-03 Thread Marco van de Voort
I'm trying to let an iterator implement the enumerator pattern and 
return itself, but for that I need to use the type of the generic:


 generic THashmapIterator=class
 public
      type PValue=^TValue;

    // make type alias

  TIteratorType = generic THashmapIteratorTValue, T, TTable>;


  var
   Fh,Fp:SizeUInt;
   FData:TTable;
   function Next:boolean;inline;
   function MoveNext:boolean;inline;
   function Prev:boolean;inline;
   function GetData:T;inline;
   function GetKey:TKey;inline;
   function GetValue:TValue;inline;
   function GetMutable:PValue;inline;
   procedure SetValue(value:TValue);inline;
   function getenumerator : TIteratorType ;
   property Data:T read GetData;
   property Key:TKey read GetKey;
   property Value:TValue read GetValue write SetValue;
   property MutableValue:PValue read GetMutable;
   property Current : T read GetData;
   end;

 function THashmapIterator.getenumerator : 
TIteratorType ;


     begin

    result:=self;

 end;

but the I can't find a TIteratorType definition that is accepted. Can 
some of the objfpc generics buffs reveal the secret how to do this?


Do I need to nest the iterators first, like in Delphi, and if so will 
($modeswitch advancedrecords} allow this?





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


Re: [fpc-devel] TFIeld.lookup problem

2019-07-20 Thread Marco van de Voort


Op 2019-07-20 om 16:04 schreef Michael Van Canneyt:


Why is this field deprecated and not published? It really 
complicates dual maintenance of apps with database fields.


Because it is redundant. The fieldkind property is what you need. 
Set fieldKind=fkLookup


As said, it causes annoying problems with dual maintenance of forms 
for no particular reason (since the property is still there, public). 
Is it so hard to make it published (stored false if need be?).



(that came out a bit more whiny then I meant it :-)


No, it is not.

But dual maintenance was never a target. 


Deliberately frustrating it can't be the object either.


Easy porting, yes.

It makes it unnecessary hard for e.g. example code for shared component 
packages. So can we please change it? Just say the word, and I'll do it.

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


Re: [fpc-devel] TFIeld.lookup problem

2019-07-20 Thread Marco van de Voort


Op 2019-07-20 om 14:40 schreef Michael Van Canneyt:


Why is this field deprecated and not published? It really complicates 
dual maintenance of apps with database fields.


Because it is redundant. The fieldkind property is what you need. Set 
fieldKind=fkLookup


As said, it causes annoying problems with dual maintenance of forms for 
no particular reason (since the property is still there, public). Is it 
so hard to make it published (stored false if need be?).




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


[fpc-devel] TFIeld.lookup problem

2019-07-20 Thread Marco van de Voort


Why is this field deprecated and not published? It really complicates 
dual maintenance of apps with database fields.


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


  1   2   3   4   5   6   7   8   9   10   >