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
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.
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
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
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.
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 :
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
For unsigned
utable 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 used in the integer division opt
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 -
- 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 an a
- 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
- 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
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=44737=44738
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
> > 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,
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
f 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:= longint(1
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
> #
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.
> 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
> 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 boun
> 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
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.
> - 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
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
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,"'");
> (*
- 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,
> 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
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
- 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
- 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
> 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
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
> 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
> 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
45 matches
Mail list logo
