As well Linux kernel have direct patches from Intel and probably from AMD. FPC
is not in race to outrun some. I have in mind to break one to one relationship
of TAsmOp={$i x8664op.inc} and InsProp : array[tasmop] of TInsProp = {$i
x8664pro.inc} That's what my question is about. - Reply to
Hi, I am looking forward to implement APX instructions set. APX extend general
purpose register count to 32. By reading official documentation about
instructions sets from Intel it come to my attention that APX is in Intel's
road map for upcoming Diamond Rapids cpu. It will be in metal rather so
I have been working on fixing up Textmode IDE and some related packages (Free
Vision, rtl-console) One of the recent large improvement is scrolling by mouse.
I am happy how it turned out. Currently mouse scroll events are going under
evMouseDown. But it does have some unwanted side effects in ex
There is release_3_2_4-branch with fpc version 3.2.4-rc1. As i understand this
is foundation for fpc 3.2.4 release!
Is there possible to add more commits from main branch? I know that fixes is
officially frozen since June 9th.
Those are commits I would like to see in final 3.2.4 release.
Change
> Fixed 2 and 3. Thank you. one more ... {\$ifdef FPU_HAS_PURE}pure;{\$ENDIF}
> FPU_HAS_PURE probably is typo and should be: FPC_HAS_PURE ___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc
1. pure function value to constants function foo(i:longword):longword; pure;
begin foo:=9; end; const bar = foo( 8 ); //-- not allowed.. but i expect
this to work! jar : longword = foo( 7 ); //-- and this as well 2. this
does not end grasefully function foo (i:longword):shortstring;
reepascal.org>
To: <
fpc-devel@lists.freepascal.org>
If you've got the commit(s) to hand, there's still time!
Kit
On 08/06/2024 14:00, Marģers . via fpc-devel wrote:
Is there a reason why missing x86 assembler instructions ha
Is there a reason why missing x86 assembler instructions have not made to fixes (except for avx512, that would be too much)?
To get finally forward with the 3.2.4 release, fixes will be frozen by 9th June, so if there are some last second cherry picks needed, now it’s time
more Textmode ide patches
1) Options->Compiler->Assembler assembler output options has not bees working properly (asm_output_options_ide.patch)
2) make available Assembler reader options for x86_64 (asm_reader_options_x86_64_ide.patch)
3) make asm output options for x8
> 5) make Ctrl+Enter shortcut key possible in unix/linux xterm: ctrl_enter_xterm_unix_keyboard.diff
I found out that this patch also eliminates Ctrl+J shortcut key and turn it into Ctrl+Enter.
But that is what already happening with Ctrl+i, Ctrl+M, Ctrl+[, Ctrl+H...
More inv
Improvements for Textmode ide
1) current ide (of fpc 3.3.1) has problems with second compilations. Resolve issue with this patch tdef_nil_for_ide_fpc331.patch
2) add missing xterm escape string sequences keyboard_add_escape_keys_unix_fpc331.patch
3) fpc 3.2.3 add missing xterm esca
Some compiler x86 assembler improvements
1) patch for fpc 3.3.1 (attachment: mkx86ins_version_bump.patch)
compiler/utils/mkx86ins.pp
Version bumped from 1.6.1 to 1.6.2
There has been changes to code, so version has to represent that.
2) Patch to enable ENTER asm instru
>> Is there a way to download human readable format documenation?
>
>Please explain ?
html, pdf, chm format...
The documentation is available as PDF. That's human readable ?
> Looking documentation of 3.2.2 and it is bad. Errors and errors. Wanted to crosschech, maybe it is all fixed meanwh
On 2024-05-09 09:17, Marģers . via fpc-devel wrote:
Hi,
> Is there a way to download human readable format documenation?
>
> Looking documentation of 3.2.2 and it is bad. Errors and errors.
What do you mean with "errors and errors"?
Wrong word usage, decription of fun
Is there a way to download human readable format documenation?
Looking documentation of 3.2.2 and it is bad. Errors and errors. Wanted to crosschech, maybe it is all fixed meanwhile.
Failing to compilde documentation by myself. Where to download or how to compile?
Simple "make" does not work. It
1) does not work
make clean singlezipinstall OS_TARGET=win32 CPU_TARGET=i386 ALLOW_WARNINGS=1 OPT=" -O2 -vxitl -Cp80486 -Op80486"
hangs on
system.inc(421,2) Start reading includefile C:\Users\Lietotajs\Downloads\fora\a\486\gh\rtl\inc\generic.inc
100 5.174/5.888 Kb Used
900 5.307/6.336 Kb Us
On 2024-02-27 13:08, Marģers . wrote:
>>> Should I be able to compile DOS go32v2 target from DOS itself?
>>>
>>> compiling trunk using "make" fall into infinite loop on this
>> command
>>>
>>> t:\sv\fpc331\compiler\ppc1.exe -Ur -Xs -O2 -n -Fi../inc -Fi../i386
>>> -FE. -FUt:\sv\fpc331\rtl\units\go
Should I be able to compile DOS go32v2 target from DOS itself?
Overcoming some challenges was possible to compile fpc 3.2.2 with starting compiler version 3.2.2. Version 3.2.0 does not work.
compiling trunk using "make" fall into infinite loop on this command
t:\sv\fpc331\compiler\ppc1.exe -Ur -
1. why you leave "time:=..." in benchmark loop? It does add 50% of execution time per call.
2. Pascal version does not match assembler version. Had to fix it.
//Result := X + Counter + $87654321;
Result:=Result + X + $87654321;
Result:=Result xor y;
3. Assembler functions can be u
There is this super new, super fast and super what not image format. I have added support for fcl-images.
attached zip file contains:
1) read and write support in files
qoif/qoicomn.pas
qoif/fpwriteqoi.pas
qoif/fpreadqoi.pas
2) example of read and write QOI file
qoif/wrqoif.pas
qoif/wrpngf.pas
m
Hi,
Thank you for implementation.
Is that true, that you can not detect word and byte size on division by constant? Squeezing in 32 bit register it would make byte-code shorter, not necessarily faster.
- Reply to message -
Subject: Re: [fpc-devel] The "magic div" algorithm
From: J. Gare
I came up with even shorter variant of div
example
function teDWordDivBy7_v4( divided : dword):dword; assembler; nostackframe;
asm
mov ecx,divided
mov rax,2635249153693862181
mul rcx
mov eax,edx
end;
current version for comparison
function teDWordDivBy7_v0( divided : dword):d
function teByteDivBy7( divided : dword):dword; assembler; nostackframe;
asm
mov ecx,divided
mov eax,293
mul ecx
shr eax, 11
end;
- Reply to message -
Subject: Re: [fpc-devel] The "magic div" algorithm
From: Marģers . via fpc-devel
To: FPC developers' list
I have a reputable source rather than just an online one (I know there's one somewhere that isn't behind a paywall).
Gareth aka. Kit
On 20/08/2021 18:46, Marģers . via fpc-devel wrote:
is there a reference to the algorithm that's used to calculate the
reciprocal constants us
is there a reference to the algorithm that's used to calculate the
reciprocal constants used in the integer division optimisations for x86 and AArch64?
Hacker’s Delight
Second Edition
Henry S. Warren, Jr.
___
fpc-devel maillist - fpc-devel@lists
- Reply to message -
Subject: Re: [fpc-devel] duplicate internal error numbers
Date: ceturtd., 8 okt. 2020, 19:39
From: Sven Barth via fpc-devel
To: FPC developers' list
> Marģers . via fpc-devel schrieb am Do., 8.
> Okt. 2020, 12:39:
> > > I would advise against
- Reply to message -
Subject: Re: [fpc-devel] duplicate internal error numbers
Date: trešd., 7 okt. 2020, 16:40
From: J. Gareth Moreton via fpc-devel
To:
> When two different programmers write code on the same day in different
> parts of the compiler, there's bound to be a clash eventu
- Reply to message -
Subject: Re: [fpc-devel] duplicate internal error numbers
Date: trešd., 7 okt. 2020, 14:16
From: Jonas Maebe via fpc-devel
To:
> On 07/10/2020 13:02, Marģers . via fpc-devel wrote:
> > found total 4300+
> > 1001 error number has to be changed to
i did check for duplicate internal error numbers
found total 4300+
1001 error number has to be changed to make all error number unique
as there are so huge number of changes to make i have question
1) would it be desirable to change all (or most) duplicate error numbers in one single big patch?
- Reply to message -
Subject: [fpc-devel] Producing assembly with less branches?
From: Stefan Glienke
To:
> Hi,
> not sure if anything significantly changed in trunk compared to 3.2 wrt
> to optimized code being generated but I am quite disappointed that fpc
> (checked win64 with -O3 a
can someone check if remove of r44737 in r44738 was intended?
https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/compiler/aarch64/aoptcpu.pas?r1=44738&r2=44737&pathrev=44738
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freep
> > From: J. Gareth Moreton
> > To:
> >> Are you able to dump the nodes as well with -an? (You'll need to define
> >> -dEXTDEBUG though) That might give some clues behind the presence of
> >> that movslq instruction.
> >
> You will need to also add ALLOW_WARNINGS=1 to the make call.
Ok, ALLOW_W
From: J. Gareth Moreton
To:
> Are you able to dump the nodes as well with -an? (You'll need to define
> -dEXTDEBUG though) That might give some clues behind the presence of
> that movslq instruction.
building compiler with -dEXTDEBUG does not work for me
make singlezipinstall OS_TARGET=linu
benefit of resolving
this issue - 2 or 1 free registers available for other purposes.
> On 04/02/2020 18:50, Marģers . via fpc-devel wrote:
> > p.s. tested execution speed and there is no measurable difference.
> >
> >
> >> asm code
> >> # [109] bit:=
p.s. tested execution speed and there is no measurable difference.
> asm code
> # [109] bit:= longint(1) shl k;
> movslq %ecx,%rdx
> # Register r8d allocated
> movl $1,%r8d
> # Register edx,edx allocated
> shlx %edx,%r8d,%edx
> # Register r8d released
> # Reg
hi
example code:
function roo(lk:longint):byte;
var k : longint;
bit : longint;
num : byte;
begin
num:=0;
for k:=0 to 25 do
begin
bit:= longint(1) shl k;
if (lk and bit) <> 0 then
begin
lk:=lk xor bit;
inc(num);
> Does that mean in some situations, if you have a small, tight loop, it
> might be better to optimise over speed in some very rare cases? For
> example, turning MOV EAX, $ into OR EAX, $FF to squeeze out a
> few extra bytes, even though the instruction introduces a false dependency.
Laten
> 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 exp
> 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
> By the way, what is your 'particular CPU'? If it's not Intel-based,
amd zen 1. gen - the same x86_64. Not much help for testing on other platforms.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailma
blobing - i meant unnecessarily increase in size, that function loses good
shape. There is no such word "blobing" in English. My bad.
let me periphrases 'just wrong' - 'questionable right'. Currently inlining are
left in hands of programmers. And it is abused as magical performance booster.
Fo
> - Identifying functions that are only used once. This became a slight point
> of contention between Florian and myself, because I inlined a couple of
> functions
Inlining every once used function is just wrong. Gain from eliminating call and
function prologue and epilogue might not be suffic
hi,
Java is going to have multi-line strings https://www.youtube.com/watch?v=J1YKAFtNz70
I'm posting this, because they have different way of indentation as its currently in proposed patch.
Maybe it worth of consideration. If not, it's ok.
__
> make info PP=/home/user/fpc304/lib/fpc/3.0.4/ppcx64
> If the compiler is found, it should be reported
as the first line printed after == Configuration
info ==
== Configuration info ==
FPC.. /home/user/fpc304/lib/fpc/3.0.4/ppcx64
"make info" shows correct location of starting
compil
Hi,
i used simple script for compiling compiler
export PP=/home/user/fpc304/lib/fpc/3.0.4/ppcx64
make singlezipinstall OS_TARGET=linux
CPU_TARGET=x86_64 OPT="
-Fu/home/user/fpc304/lib/fpc/3.0.4/units/x86_64-linux/rtl/"
Reason of "export PP=" is that i don't have
installed fpc, so i have to
- Reply to message -
From:
To:
> On 7/6/19 4:50 PM, wkitt...@windstream.net wrote:
> > writeln("MultiLine1= '",MultiLine1,"'");
> > writeln("MultiLine2= '",MultiLine2,"'");
> (* i forgot to do the line for MultiLine3 *)
> writeln("MultiLine3= '",MultiLine3,"'");
> (* th
- Reply to message -
Subject: Re: [fpc-devel] Some thoughts on
multi-line string support, and a possible syntax
that I think is perfectly clean and Pascal-ish.
Date: trešd., 3 jūl., 23:20
From: Ben Grasset
To: FPC developers' list
> program Example;
> (*
> This is a perfectly
>
- Reply to message -
Subject: Re: [fpc-devel] XML node dump feature
Date: otrd., 25 jūn., 03:16
From: Ben Grasset
To: FPC developers' list
> const
> A: TVec3F = (X: 1.2; Y: 2.4; Z: 3.8);
> B: TVec3F = (X: 2.1; Y: 4.2; Z: 8.3);
> // You can't do the next part currently, obviou
> As mentioned in a previous message, fpc trunk
supports a volatile
> intrinsic:
>
http://wiki.freepascal.org/FPC_New_Features_Trunk#Support_for_.22volatile.22_intrinsic
My bad, I didn't know about volatile intrinsic.
So, does it mean that compiler is allowed to
optimize any variable, even promote
As i understand this idea is another way around key word "volatile" in order to allow compiler perform more optimization.
Then why to go half way introducing "safe", when it's better introduce "volatile". Not too long ago here was discussion about it, but it was strongly rejected by core team.
I d
- Reply to message -
Subject: Re: [fpc-devel] Successful implementation
of inline support for pure assembler routines on x86
Date: 2019. gada 17. marts 19:38:03
From: Florian Klämpfl
To:
> Am 15.03.19 um 11:32 schrieb J. Gareth Moreton:
> * using inline assembler is always the worst
- Reply to message -
Subject: Re: [fpc-devel] Successful implementation
of inline supportforpureassembler routines on x86
Date: 2019. gada 18. marts 00:28:10
From: J. Gareth Moreton
To: FPC developers' list
> To use the integer clamp function as an
example (if x < 0 then x := 0):
> I'm a tad confused in regards to the best course
of action regarding MOVZX. Many of the peephole
optimisations seek to change them to MOV followed
by AND (e.g. "movzbl (mem), %eax" to "mov (mem),
%al; and $0xff, %eax"). Does MOVZX have a
well-documented performance penalty in modern
processors
fillchar is one useful function, but should be
avoided from use in time critical code by any
cost. Only reasonable way to improve fillchar is
to make it internal function, where fpc can
decide, depending on parameters, what will be best
solution for filling mem with specified value. But
it will
- Reply to message -
Subject: Re: [fpc-devel] x86_64 Optimizer Overhaul
Date: 2018. gada 12. decembris 17:02:02
From: J. Gareth Moreton
To: FPC developers' list
> By the way, what generates that set of
> operations? I'm curious because I want to
> see what's going on in the compiler.
> Nice spot with the "incq" command there. It
wasn't intentional for that to be split into 3
commands, but is likely just a side-effect of pass
1 not being run twice now... granted, since one of
my criteria was that the code should not be less
optimal, I'll see if I can watch out for that one.
- Reply to message -
Subject: Re: [fpc-devel] x86_64 Optimizer Overhaul
Date: 2018. gada 6. decembris 18:57:29
From: J. Gareth Moreton
To: FPC developers' list
> I believed I've fixed the bug. Thanks for your
help.
Now it's way better. -O3 and -O4 works fine.
Speed test for my prog
I run it no linux. Problem code part.
type PLongData = ^TLongData;
TLongData = array [0..100] of longint;
function binarySearchLong ( sortedArray:PLongData; nLen, toFind:longint):longint;
var low, high, mid, l, h, m : longint;
begin
{ Returns index of toFind in sortedArray, or -1 if not
> I've had problems testing it under Linux due to configuration difficulties, so if anyone is willing to try out "make all", I'll be most grateful.
"make all" work well on linux.
Compiler options -O3 and -O4 are broken.
It was possible to compile my program, but program at some point went into n
> The support is currently only on the
> https://svn.freepascal.org/FPC/svn/fpc/branches/debug_eh branch.
I got sources from
https://svn.freepascal.org/svn/fpc/branches/debug_eh
> ** Linux: you may also have to specify the library path to libgcc_s.
> E.g. on Ubuntu 16.04:
> make LOCALOPT="-dllvm
60 matches
Mail list logo