The gist of it is that you're specifying the earliest CPU that your
program will run on (if it runs on an older CPU, it might crash with
SIGILL). -Cp dictates the instruction set version used overall, while
-Cf specifies the family of floating-point instructions that will be
used. Later
On 14/09/2020 19:41, Michael Van Canneyt via fpc-devel wrote:
Better add an additional (optional) parameter SkipInit : Boolean =
False;
Michael.
I was probably a bit too critical in my last e-mail. I'm sure it's
possible given SetLength is an intrinsic rather than a real subroutine.
Is
aka. Kit
On 15/09/2020 10:11, Sven Barth wrote:
J. Gareth Moreton via fpc-devel <mailto:fpc-devel@lists.freepascal.org>> schrieb am Mo., 14. Sep.
2020, 19:00:
With all this in mind, would there be support for an intrinsic
such as
"SetLengthNoInit" or "SetLength
Hi everyone,
This is something that came up in a discussion with a client. One thing
he noticed when using SetLength with dynamic arrays is that it can cause
a CPU bottleneck because it initialises the entire block to zero, which
is often undesirable if the array is going to be overwritten
On 14/09/2020 19:41, Michael Van Canneyt via fpc-devel wrote:
Better add an additional (optional) parameter SkipInit : Boolean = False;
Michael.
That won't work because constructs such as "var Data: array of array of
Byte; SetLength(Data, 25, 25);" are allowed. Eevn if it's technically
an
oks like a partial read of the lower bits is absolutely fine,
since you're not changing anything.
Gareth aka. Kit
On 02/10/2020 01:40, Nikolay Nikolov via fpc-devel wrote:
On 10/1/20 11:36 PM, J. Gareth Moreton via fpc-devel wrote:
I thought that might be the case - thanks Nikolay. And I me
, J. Gareth Moreton via fpc-devel wrote:
Hi Torsten,
The reason why it's not compiling correctly with -a is because the
operand size is being set to S_XMM, not S_YMM (because it's going by
the size of the source operand), so when writing the .s files, it adds
an 'x' suffix to the end
ead of the lower bits is absolutely fine,
since you're not changing anything.
Gareth aka. Kit
On 02/10/2020 01:40, Nikolay Nikolov via fpc-devel wrote:
On 10/1/20 11:36 PM, J. Gareth Moreton via fpc-devel wrote:
I thought that might be the case - thanks Nikolay. And I meant to
say lower b
s
outside of the subset are not zero, even though the register isn't being
modified.
Gareth aka. Kit
On 02/10/2020 11:57, J. Gareth Moreton via fpc-devel wrote:
So... I've done some tests, replacing TEST RCX, $4 with TEST CL, $4
and the like in a number-crunching function, and it seems to cause
/10/2020 23:10, Martin Frb via fpc-devel wrote:
On 01/10/2020 23:22, J. Gareth Moreton via fpc-devel wrote:
In a way, yes, but not quite the same, since multiple calls to the
nested function would still redirect to the same block of code rather
than being inlined at each call. I suppose more
this.
Torsten
-Original-Nachricht-
Betreff: Re: [fpc-devel] SSE/AVX instruction encodings
Datum: 2020-10-01T18:04:26+0200
Von: "J. Gareth Moreton via fpc-devel"
An: "fpc-devel@lists.freepascal.org"
Hi Torsten,
I've done that already actually, although only to grab the value
Normally internal error numbers need to be unique so it's easier to
identify where the compiler's internal state went bad. I have submitted
a few patches of my own to rectify number clashes, but these are only in
cases where they clash on the same platform (e.g. between two
platform-specific
proposal, completely forgetting about the return
address), but I hope I find the occasional useful gem that can be used
and polished by others!
Gareth aka. Kit
On 02/10/2020 14:13, Nikolay Nikolov via fpc-devel wrote:
On 10/2/20 2:13 PM, J. Gareth Moreton via fpc-devel wrote:
Confirmed my
want to send you functions that use the wrong calling convention!
Gareth aka. Kit
On 02/10/2020 14:13, Nikolay Nikolov via fpc-devel wrote:
On 10/2/20 2:13 PM, J. Gareth Moreton via fpc-devel wrote:
Confirmed my suspicions. if I zero the upper bits of the register (I
used something akin
Hi everyone,
Before I go optimising the wrong thing, I have a question to ask.
What's the policy on platform-specific assembly language in the
compiler, or any code designed to run on a specific (source) platform
(and using a more generic implementation otherwise via $ifdef)? I ask
because
On 16/10/2020 10:47, Jonas Maebe via fpc-devel wrote:
On 16/10/2020 10:14, J. Gareth Moreton via fpc-devel wrote:
Before I go optimising the wrong thing, I have a question to ask.
What's the policy on platform-specific assembly language in the
compiler, or any code designed to run
Kit
On 18/10/2020 01:13, J. Gareth Moreton via fpc-devel wrote:
Well, I think you might be right on this one, Jonas!
I've tested my algorithm against the one used in the compiler. It's 5
times faster when used with small divisors (so loop iterations are
minimal)... but that amounts to about 15 n
Hi everyone,
I've started to look at developing FPC on the Raspberry Pi again, but
I've run into a snag.
The unmodified trunk does not build - it fails when building system.pp
at the ppc1 stage:
math.inc(57,7) Error: Assembler syntax error
math.inc(58,11) Error: Unrecognized opcode round
I can't remember for sure - it might have been 3.0.4, so I'm probably
asking for trouble now. When I get back later I'll check for sure and
try a few things and get back to you. At least it's confirmed that it
actually did not compile!
For the curious, I'm looking to implement the
design.
Gareth aka. Kit
On 18/10/2020 09:53, Sven Barth wrote:
Am 18.10.2020 um 08:56 schrieb J. Gareth Moreton via fpc-devel:
Hi everyone,
I've started to look at developing FPC on the Raspberry Pi again, but
I've run into a snag.
The unmodified trunk does not build - it fails when building
how it goes.
Gareth aka. Kit
On 05/10/2020 14:39, Nikolay Nikolov via fpc-devel wrote:
On 10/4/20 2:01 PM, J. Gareth Moreton via fpc-devel wrote:
Hi Nikolay,
I've got some good code to test, but I need to double-check with
someone to see if the licensing agreements allow (the code is rather
, it treats the "magic add" differently (the
reason why it randomly failed).
Gareth aka. Kit
On 16/10/2020 23:14, J. Gareth Moreton via fpc-devel wrote:
On 16/10/2020 10:47, Jonas Maebe via fpc-devel wrote:
On 16/10/2020 10:14, J. Gareth Moreton via fpc-devel wrote:
Before I go optimising
Ah, thanks Florian.
Gareth aka. Kit
On 18/10/2020 10:01, Florian Klämpfl via fpc-devel wrote:
Am 18.10.20 um 08:56 schrieb J. Gareth Moreton via fpc-devel:
(On another note, a number of AArch64 opcodes are missing, notably
ADDS (add and set flags) and similar instructions -
This is done
. Kit
On 18/10/2020 09:53, Sven Barth wrote:
Am 18.10.2020 um 08:56 schrieb J. Gareth Moreton via fpc-devel:
Hi everyone,
I've started to look at developing FPC on the Raspberry Pi again, but
I've run into a snag.
The unmodified trunk does not build - it fails when building
system.pp
Hi everyone,
Being on a working Intel laptop full-time again, I've gone back to
looking at the Peephole Optimizer like I always used to do. One thing
I've been focusing on is an attempt to reduce the number of passes of
the Peephole Optimizer, since a single pass amounts to stepping through
Well, it looks like it got deleted completely! (It was a weird
advertisement for a security architect or something... someone needs to
tell their advertiser that bug trackers aren't the place to get your
name out!)
Gareth aka. Kit
On 19/10/2020 10:17, J. Gareth Moreton via fpc-devel wrote
Hi everyone,
I just closed a bug report with a comment that it was 'spam'. Would you
agree? https://bugs.freepascal.org/view.php?id=37957
Is there a specific way such 'bugs' should be handled?
Gareth aka. Kit
--
This email has been checked for viruses by Avast antivirus software.
Hi everyone,
So I've been studying the disassembler dumps of the RTL for some new
possible optimisations, and I've found a potential one that's a little
trickier than normal:
...
# Peephole Optimization: MovxMov2Movx
movslq %eax,%rbx
jmp .Lj83
.p2align 4,,10
.p2align 3
via fpc-devel wrote:
On 18/10/2020 13:34, J. Gareth Moreton via fpc-devel wrote:
I've just seen the change you've made Sven (just looking it via diff,
not actually testing the code)... do the standard Pascal comments
seriously cause a problem in AArch64 assembly blocks? Do the braces
have
that's another story, and I'm not sure what the
policy is on platform-specific syntax highlighting.
Gareth aka. Kit
On 18/10/2020 14:41, Sven Barth wrote:
Am 18.10.2020 um 15:15 schrieb J. Gareth Moreton via fpc-devel:
Aah, I see - thanks Jonas. That's a little awkward - presumably we
can't
ailure elsewhere.
Gareth aka. Kit
On Sun 23/08/20 12:09 , "J. Gareth Moreton via fpc-devel"
fpc-devel@lists.freepascal.org sent:
> Thanks Jonas - I'll see if I can pinpoint it now.
>
>
>
> Gareth aka. Kit
>
>
>
> On Sun 23/08/20 13:09 , Jonas Maebe via
Hi everyone,
So my new x86_64 laptop has finally arrived, although it will take a few
days to get everything reconfigured, as well as find the e-mail server
details so I don't have to keep using an antiquated webmail system to
communicate on this account!
Thank you so much to Chris Rorden for
Hi everyone,
I've found a pretty big optimisation that benefits most ARM platforms,
including AArch64, but I'm getting a few random test failures. My
investigations suggest that functions like "fpc_chararray_to_unicodestr" and
other string conversion routines are not being optimised properly
Thanks Jonas - I'll see if I can pinpoint it now.
Gareth aka. Kit
On Sun 23/08/20 13:09 , Jonas Maebe via fpc-devel
fpc-devel@lists.freepascal.org sent:
> On 23/08/2020 12:48, J. Gareth Moreton via fpc-devel wrote:
>
> > I've found a pretty big optimisation that
> benefits mos
Hi everyone,
So some news about my broken laptop. The motherboard needs replacing due to
the processor being
integrated into the board and there being damage caused by overheating to the
point that the CPU
can't regulate itself without going into emergency shutdown.
The only third-party
Writing compilers is a pretty specialised undertaking, so general guides are
rather hard to come by.
For FPC, your best bet is to study the source code of something that already
exists, make notes and
build from there.
Gareth aka. Kit
On Tue 18/08/20 14:39 , Florian Klämpfl via
riy
Pomerantsev. 18.08.2020, 17:47,
> "J. Gareth Moreton via fpc-devel" :
>
> Writing compilers is a pretty specialised
undertaking, so general guides
> are rather hard to come by.
> For FPC, your best bet is to study the
source code of something that
> already exists, ma
Hi everyone.
During my evaluation of the assembly language produced by the AArch64
implementation of the Free Pascal Compiler, I've noticed that it uses the stack
an awful lot and, generally, not many of the 28 or so general-
purpose registers available for it.
The main problem is that even
forgot to add... that was under -O3.
Gareth aka. Kit
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Oh dear, that's a shame. Havoc sounds fun though! Part of me wants to try
anyway because I'm masochistic like that, but I'll do that privately.
As an example, here's something from the classes unit - see how many references
there are to [sp, #16]. It might not be exactly the same as what you
On Thu 20/08/20 15:36 , Florian Klämpfl via
fpc-develfpc-de...@lists.freepascal.org sent:
> Am 20.08.20 um 15:09 schrieb J. Gareth Moreton:
>
> > Oh dear, that's a shame. Havoc sounds fun
> though! Part of me wants to try anyway because I'm masochistic like that,
> but I'll do that privately.
the language itself. I can't say I
speak on behalf of Florian or Jonas, but I sense they want to avoid
feature bloat that became a bit of an issue with Delphi.
Gareth aka. Kit
On 17/09/2020 04:03, Ryan Joseph via fpc-devel wrote:
On Sep 17, 2020, at 9:59 AM, J. Gareth Moreton via fpc-devel
wrote
Hi everyone,
I've decided to take on https://bugs.freepascal.org/view.php?id=37785 -
I've noticed that the compiler isn't too good at working out the sizes
of SSE and AVX instructions. If you look at
Tx86Instruction.SetInstructionOpsize in compiler/x86/rax86.pas, it
checks for individual
Hi everyone,
I have a small question with assembler size optimisation that maybe one
of you guys can give me a second opinion on:
If you are using the "test" instruction to test some of the lower bits
of an instruction, e.g. TEST RCX, $2, is there a penalty with calling
TEST CL, $2 instead?
-Nachricht-
Betreff: [fpc-devel] SSE/AVX instruction encodings
Datum: 2020-10-01T13:57:05+0200
Von: "J. Gareth Moreton via fpc-devel"
An: "FPC developers' list"
Hi everyone,
I've decided to take on https://bugs.freepascal.org/view.php?id=37785 -
I've noticed that th
Hi everyone,
This is an idea that sprung to mind while looking at fixing an unrelated
bug, and that's to do with nested functions.
In situations where a nested function has no parameters, is it feasible
and beneficial to programmatically merge it into the main procedure in
some
:
On Oct 1, 2020, at 10:37 AM, J. Gareth Moreton via fpc-devel
wrote:
In situations where a nested function has no parameters, is it feasible and
beneficial to programmatically merge it into the main procedure
What do you mean by "merge"? Like inlining?
Regards,
R
I think you always get a read penalty when using the high-byte registers
because the processor has to do an implicit shift operation.
Thanks again for the answer.
Gareth aka. Kit
On 01/10/2020 19:43, Nikolay Nikolov via fpc-devel wrote:
On 10/1/20 8:17 PM, J. Gareth Moreton via fpc-devel wro
wrote:
On 01/10/2020 18:37, J. Gareth Moreton via fpc-devel wrote:
On a similar topic, one person mentioned that GCC and other compilers
sometimes 'outline' conditional branches by effectively moving the
branch into a nested procedure in order to help with caching.by giving
the main proced
Useful theory. I'll take a read. Thank you again.
Gareth aka. Kit
On 03/10/2020 19:14, Jonas Maebe via fpc-devel wrote:
On 03/10/2020 18:43, J. Gareth Moreton via fpc-devel wrote:
Sounds like a fun thing to research, that's for sure. Thanks Jonas.
I'm under the impression that exception
evel wrote:
On Sep 15, 2020, at 10:34 PM, J. Gareth Moreton via fpc-devel
wrote:
I'm willing to settle with SetLength(array, len, ... len, NoInit: Boolean =
False), but of course it depends on the overall support for it, which isn't
looking too promising currently!
I'd rather put the time i
(which would be a little unfriendly for third-party users), there
isn't really a way around this.
Gareth aka. Kit
On 17/09/2020 03:08, Ryan Joseph via fpc-devel wrote:
On Sep 16, 2020, at 9:10 PM, J. Gareth Moreton via fpc-devel
wrote:
I figure I could design a dynamic array class
Sorry for it being down to one of my optimisations again! Nobody's perfect, I
guess. Thanks Jonas
for fixing it.
Gareth aka. Kit
On Sun 16/08/20 10:27 , C Western via fpc-devel fpc-devel@lists.freepascal.org
sent:
> On 15/08/2020 17:07, Jonas Maebe via fpc-devel wrote:
>
> > On 14/08/2020
I do agree that populating the carry bit is not that straightforward,
especially on processors that don't have an explicit carry.
An alternative approach is to go for something similar to the SHRD
instruction, that pulls in bits from another register rather than the
carry bit -
Do you have an assembly dump of that file, or at least a snippet of the
culprit subroutine?
Gareth aka. Kit
On 29/12/2020 07:17, Pascal Riekenberg via fpc-devel wrote:
cpu.pp(77,15) Error: Unrecognized opcode xbegin
cpu.pp(77,22) Error: Assembler syntax error
cpu.pp(83,15) Error: Unrecognized
Crumbs, this minor aside has blown up more than the original problem!
To get back on topic, it seems there's a bug with one of the node code
generators under -O2 and above. It's not something I've researched that
deeply, but I would like to see it fixed. First though we need to find
which
)
Gareth aka. Kit
On 25/11/2020 10:08, Sven Barth via fpc-devel wrote:
J. Gareth Moreton via fpc-devel <mailto:fpc-devel@lists.freepascal.org>> schrieb am Mi., 25. Nov.
2020, 09:51:
Aah, typical! C:\Windows\System32 is supposed to be for 32-bit DLLs,
while C:\Windows\System
Sure thing - I'll give that a try.
Looks like this is my first true experience with DLL Hell!
Gareth aka. Kit
On 25/11/2020 17:13, Marco van de Voort via fpc-devel wrote:
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
Well, I found a temporary solution. installing 32-bit Oracle libraries
didn't fix the problem, so I simply commented out the $linklib entry in
the culprit file. I didn't have any of the other files it listed anyway!
Gareth aka. Kit
On 25/11/2020 17:51, J. Gareth Moreton via fpc-devel wrote
:25, Bart via fpc-devel wrote:
On Thu, Nov 26, 2020 at 5:00 PM J. Gareth Moreton via fpc-devel
wrote:
program break;
{$apptype console}
begin
writeln('I am Break');
end.
Compiles with fpc 3.2.0 and Delphi 7.
Outputs nothing at all with both compilers
If I run it inside GDB
Delphi 7
, Tomas Hajny via fpc-devel wrote:
On 2020-11-24 01:14, J. Gareth Moreton via fpc-devel wrote:
I'd say thie first port of call is "compiler/comphook.pas", line 258:
procedure WriteColoredOutput(var t: Text;color: TOutputColor;const s :
AnsiString);
It looks like a simple "$if
Hi everyone,
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
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 in
I'd say thie first port of call is "compiler/comphook.pas", line 258:
procedure WriteColoredOutput(var t: Text;color: TOutputColor;const s :
AnsiString);
It looks like a simple "$if defined".
Gareth aka. Kit
On 24/11/2020 00:08, Ryan Joseph via fpc-devel wrote:
On Nov 23, 2020, at 1:33
The fact that it doesn't seem to throw a warning if the library is
missing is a bit weird. Or if it does, I haven't noticed the message.
Gareth aka. Kit
On 26/11/2020 21:02, Sven Barth via fpc-devel wrote:
Am 26.11.2020 um 21:48 schrieb J. Gareth Moreton via fpc-devel:
I figured
Hi everyone,
So a couple of people have reported that -O2 sometimes produces bad code
under x86_64. So far it seems isolated to that CPU.
https://bugs.freepascal.org/view.php?id=38129
After my own investigations with the attached code, the problem still
occurs even if the peephole
Technically it isn't a reserved word, or at least not a keyword. Either
way the compiler allows it, but the result is peculiar. It probably
shouldn't be allowed in that case.
Gareth aka. Kit
On 26/11/2020 15:58, Bart via fpc-devel wrote:
On Thu, Nov 26, 2020 at 4:34 PM J. Gareth Moreton via
related.
Gareth aka. Kit
On Fri 27/11/20 19:47 , "J. Gareth Moreton via fpc-devel"
fpc-devel@lists.freepascal.org sent:
> Crumbs, this minor aside has blown up more than the original problem!
>
> To get back on topic, it seems there's a bug with one of the node code
> generato
ogram.
Gareth aka. Kit
On 26/11/2020 19:04, Yuriy Sydorov via fpc-devel wrote:
Hi,
On 26.11.2020 17:34, J. Gareth Moreton via fpc-devel wrote:
Hi everyone,
So a couple of people have reported that -O2 sometimes produces bad
code under x86_64. So far it seems isolated to that CPU.
https://bu
DLL or should it remain
an error?
Gareth aka. Kit
On 26/11/2020 20:33, Sven Barth via fpc-devel wrote:
Am 25.11.2020 um 00:37 schrieb J. Gareth Moreton via fpc-devel:
Hi everyone,
This might be my own configuration, but can people check that
i386-win32 works properly? I tried to build
:
On 2020-11-24 01:14, J. Gareth Moreton via fpc-devel wrote:
I'd say thie first port of call is "compiler/comphook.pas", line 258:
procedure WriteColoredOutput(var t: Text;color: TOutputColor;const s :
AnsiString);
It looks like a simple "$if defined".
Yes, and the more platforms
Hah, that's the reason! Thanks Jonas. Crisis averted.
Now for the original problem...
Gareth aka. Kit
On 26/11/2020 17:52, Jonas Maebe via fpc-devel wrote:
On 26/11/2020 16:34, J. Gareth Moreton via fpc-devel wrote:
P.S. Also, there seems to be a strange, unrelated glitch. If I rename
. I'm not yet sure if it fixes the -O2 bugs
reported on aarch64 specifically - those will have to be tested when
this fix (or another one) goes live.
Gareth aka. Kit
On 27/11/2020 19:47, J. Gareth Moreton via fpc-devel wrote:
Crumbs, this minor aside has blown up more than the original
server uses 3.2.0 as starting compiler
Greetings,
Marcus
Am 21.12.20 um 20:32 schrieb J. Gareth Moreton via fpc-devel:
So far under Windows, it compiled successfully:
make crossinstall CPU_TARGET=m68k OS_TARGET=amiga CROSSOPT="-Avasm
-XV"
CROSSBINDIR=C:\Users\garet\Documents\progr
21.12.20 um 20:54 schrieb J. Gareth Moreton via fpc-devel:
No, I'm using 3.2.0 as well. It might be that it only shows up if
you cross-build from Linux. I'll keep investigating.
Gareth aka. Kit
On 21/12/2020 19:50, Marcus Sackrow via fpc-devel wrote:
Hi,
no, nothing special the server just
/2020 23:18, Karoly Balogh (Charlie/SGR) wrote:
Hi,
On Mon, 21 Dec 2020, J. Gareth Moreton via fpc-devel wrote:
That should be fine - thanks Marcus. I need to reproduce the internal
error that's being reported, and so I can compare the disassembly of
ppcross68k to see where my optimisation
Hi everyone,
I need to fix a bug with one of my optimisations that causes ppcross68k
to raise an internal error. What target platform should I specify
(cross-building from x86_64-win64)?
Gareth aka. Kit
--
This email has been checked for viruses by Avast antivirus software.
um 19:01 schrieb J. Gareth Moreton via fpc-devel:
I need to fix a bug with one of my optimisations that causes
ppcross68k to raise an internal error. What target platform should I
specify (cross-building from x86_64-win64)?
for example your could compile for m68k-amiga with
make crossall
same error message
Good luck.
Am 21.12.20 um 19:40 schrieb J. Gareth Moreton via fpc-devel:
That should be fine - thanks Marcus. I need to reproduce the internal
error that's being reported, and so I can compare the disassembly of
ppcross68k to see where my optimisation is going wrong.
Gareth aka. Kit
Hi everyone,
I need a little bit of assistance so I can stamp out these bugs for you.
As silly as this sounds, I've mislaid my Arm-32 SD card so I have to develop on
AArch64 exclusively on the Raspberry Pi. As a result I only have the AArch64
implementation of FPC installed. Is there a way
Thanks Sven, that worked a treat. Now I need
to try to reproduce these crashes that are
plaguing Arm.
Gareth aka. Kit
On Sat 14/11/20 16:07 , Sven Barth via fpc-
devel fpc-devel@lists.freepascal.org sent:
> Am 14.11.2020 um 15:12 schrieb J. Gareth
Moreton via fpc-devel:
>
> >
Thanks Sven, that worked a treat. Now I need
to try to reproduce these crashes that are
plaguing Arm.
Gareth aka. Kit
On Sat 14/11/20 16:07 , Sven Barth via fpc-
devel fpc-devel@lists.freepascal.org sent:
> Am 14.11.2020 um 15:12 schrieb J. Gareth
Moreton via fpc-devel:
>
> >
Well, some good news. I got a new MicroSD card for Arm-32 Raspbian OS,
although I still need to flash it. I think my old one got lost in my
move a couple of months ago. Long story short, I can get back on track
with isolating these bugs.
Gareth aka. Kit
--
This email has been checked
Fair enough then! I always thought yellow was for warnings, red was for
errors and white was for notes, but if GCC says otherwise, I can't argue!
Gareth aka. Kit
On 22/11/2020 16:08, Sven Barth via fpc-devel wrote:
Am 22.11.2020 um 15:59 schrieb J. Gareth Moreton via fpc-devel:
Hi everyone
Hi everyone,
This might be me being a little bit picky, but I noticed the new
colouring scheme for words like "Warning" and "Error" in the output
logs. Is there any particular reason why "Warning" is in magenta?
Normally the convention is that it's yellow (and "Error" in red).
Granted,
evel wrote:
On Nov 22, 2020, at 7:59 AM, J. Gareth Moreton via fpc-devel
wrote:
Hi everyone,
This might be me being a little bit picky, but I noticed the new colouring scheme for words like "Warning"
and "Error" in the output logs. Is there any particular reason why "
I believe that to enable colour on a Windows console, you need to use an
API function, which can get a bit clumsy because there isn't an
equivalent to \e[0m to reset to default, so you have to retrieve the
current console colour beforehand. Windows 10 /might/ accept the ANSI
escape sequences,
plementing the optimisation that
turns division by a constant into a multiplication and shift.
Gareth aka. Kit
On 22/11/2020 21:37, Ryan Joseph via fpc-devel wrote:
On Nov 22, 2020, at 10:09 AM, J. Gareth Moreton via fpc-devel
wrote:
Personally I'd write the function as something like
Personally I'd write the function as something like "function
GenerateColorCode(codes: array of Byte): ansistring;", mostly in
anticipation of pure functions, because then the compiler can just
replace the call with the relevant string at compile time, but that's a
long way off!
Gareth aka.
on most backgrounds. Plus GCC uses the same colours for warnings.
So, my complaint is dropped!
Gareth aka. Kit
On 22/11/2020 17:09, J. Gareth Moreton via fpc-devel wrote:
Personally I'd write the function as something like "function
GenerateColorCode(codes: array of Byte): ansistring;&quo
Most modern Macs are Unix-based, so the escape sequences should work,
right? Granted, I think we need someone with a Mac or a Mac virtual
machine to test it for sure.
Gareth aka. Kit
On 22/11/2020 16:29, Florian Klämpfl via fpc-devel wrote:
Am 22.11.2020 um 17:23 schrieb Ryan Joseph via
, yellow text would be
hard to see, while green, red, and magenta appear quite well against
both a black and a white background.
I hope a new FPC release happens sooner rather than later; colored
output is really nice to have.
~Kirinn
On 11/22/20 2:59 PM, J. Gareth Moreton via fpc-devel wrote
This is just my personal opinion, but I do think that using
"initialization" is risky if it uses anything outside of the unit, and
hence you should minimise any inter-dependencies. If I had to suggest a
concrete workaround, it would be a initialisation routine that you call
manually or as
Hi everyone,
So I've been investigating a new optimisation, using Florian's
GetNextInstructionUsingRegTrackingUse method, that improves upon
removing MOV instructions and the like that write to registers whose
values are never used (usually because the subroutine exits soon after),
and a few
Sorry, it was! I got a clean copy of the RTL and it compiled
successfully. Sorry about that. Glad I checked here first before
reporting a bug!
Gareth aka. Kit
On 03/01/2021 17:51, Florian Klämpfl via fpc-devel wrote:
Am 02.01.2021 um 18:47 schrieb J. Gareth Moreton via fpc-devel
Oh boy, if it's an accidental modification, I'll be kicking myself! Thanks.
Gareth aka. Kit
On 03/01/2021 17:51, Florian Klämpfl via fpc-devel wrote:
Am 02.01.2021 um 18:47 schrieb J. Gareth Moreton via fpc-devel:
There still seems to be a problem with i386-win32 - this is from
using FPC
I hope this isn't too much to ask, but if this IS intended for this
mailing list, would someone be willing to translate for me? I'm still
learning German (I assume it's German) and am not good enough yet to
make much sense of this.
Gareth aka. Kit
On 22/01/2021 22:37, Michael Ring via
Hi everyone,
I've finally fixed one of the two major bugs on AArch64:
https://bugs.freepascal.org/view.php?id=38055
The other one is still in progress but the problem seems to occur either
in the node second pass stage (converting nodes into assembly language)
or the register allocator.
Ah, thank you Florian.
Gareth aka. Kit
On 04/01/2021 11:49, Florian Klämpfl via fpc-devel wrote:
Am 04.01.2021 um 11:34 schrieb J. Gareth Moreton via fpc-devel
:
Hi everyone,
I'm having a bit of difficulty building i386-win32 from my win64 workstation
(building under -CriotR -O4 because
Hi everyone,
I'm having a bit of difficulty building i386-win32 from my win64
workstation (building under -CriotR -O4 because of my work on optimisation):
[ 43%] Compiled package fv
Start compiling package gdbint for target i386-win32.
File libgdb.a not found
Warning: Unable to determine the
1 - 100 of 438 matches
Mail list logo
