ndle.
Gareth aka. Kit
On 29/04/2024 21:31, Sven Barth via fpc-devel wrote:
Am 29.04.2024 um 08:42 schrieb J. Gareth Moreton via fpc-devel:
Aah, partially answered. It's not supported in 3.2.2, but there is
better support for it in the trunk.
You had me worried there for a mome
e!
Kit
On 25/05/2024 16:42, Sven Barth via fpc-devel wrote:
J. Gareth Moreton via fpc-devel
schrieb am Sa., 25. Mai 2024, 10:49:
Thought I'd give a small update.
I was distracted over the past month with work, the arm-linux
blocking
bug and a couple of merge requests whi
g the jump table in the same section as the
actual code) unfortunately didn't work, so it's something more subtle.
Kit
On 26/05/2024 11:55, Sven Barth via fpc-devel wrote:
J. Gareth Moreton via fpc-devel
schrieb am Sa., 25. Mai 2024, 22:18:
Indeed - I'm not giving up! I
,
although I'm not sure if it's a permissions issue or a subtle fault with
the pointers. This may require refactoring later on or if bugs manifest
in larger projects.
Kit
On 26/05/2024 21:33, J. Gareth Moreton via fpc-devel wrote:
Thank you for all your assistance with this Sven.
Shouldn't this be made as a merge request?
On 28/05/2024 07:12, Marģers . via fpc-devel wrote:
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,
Heh, that's fair. It was essentially how we did it in the past anyway!
Kit
On 29/05/2024 22:08, Florian Klämpfl via fpc-devel wrote:
On 29.05.24 13:09, J. Gareth Moreton via fpc-devel wrote:
Shouldn't this be made as a merge request?
I am sure we can handle also such patc
I made a post on that topic, as I remember that bug. It was a peephole
optimisation that I introduced, but before anyone tries to lynch me for
breaking the compiler, the reason why things broke is because it makes
the optimisation on the assumption that the FLAGS register was not in
use. Howe
referring to exactly. Hopefully not my
aforementioned commit, because I think making sure the flag register is
properly allocated so the peephole optimizer can make the correct
informed choices is pretty important!
Kit
On 02/06/2024 11:51, J. Gareth Moreton via fpc-devel wrote:
I made a post on that
evel wrote:
On 02/06/2024 21:06, J. Gareth Moreton via fpc-devel wrote:
I admit I'm not overly sure how to handle Thaddy sometimes:
"They fixed it in the wrong way. It is fixed in a way to solve a
single - rare - problem by an OP that seems to have more infuence
than me and the fixer
P.S. That's commit abf89eea0d6a36add99bfbcb6a0cedcec18cca59
On 03/06/2024 22:33, Adriaan van Os via fpc-devel wrote:
Florian Klämpfl via fpc-devel wrote:
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 i
Uncertain if this one has been added or not:
https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/218 - this
one fixes a bug with division nodes
Commits are:
54aae023ea2f4ee864c4ef3ce98ad387c166cb52 - bug fix
fb14bc845943073730f66be5c0450fe08afca276 - tests
Kit
On 02/06/2024 21:28,
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 have not made
to fixes (except for avx512, that would be too much)?
To get finally forward with the 3.2.4 release, fixe
*From:* J. Gareth Moreton via fpc-devel < fpc-devel@lists.freepascal.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
extra test case.
Kit
On 10/06/2024 21:54, Florian Klämpfl via fpc-devel wrote:
On 05.06.24 13:16, J. Gareth Moreton via fpc-devel wrote:
Uncertain if this one has been added or not:
https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/218 -
this one fixes a bug with division node
Hi everyone,
This might be the silliest question, but where are functions like
fpc_sin_real defined and implemented in the compiler, specifically for
x86_64? I'm playing around with a faster algorithm but can't seem to
find the actual files where the code is implemented. Functions like
fpc_f
On 25/06/2024 18:24, J. Gareth Moreton via fpc-devel wrote:
Hi everyone,
This might be the silliest question, but where are functions like
fpc_sin_real defined and implemented in the compiler, specifically for
x86_64? I'm playing around with a faster algorithm but can't seem to
Hi Marģers,
Thanks for the feedback!
Assigning the results of pure functions to constants has not yet been
developed. I had planned to add it once the bulk of pure functions
(i.e. the current merge request) had been approved since it requires
some additional work (specifically what happens i
Hi everyone,
So for a few weeks now, I've been playing with the idea of speeding up
the trig functions in Free Pascal, or at least the trig functions for
Single-precision which find uses in graphical applications where deep
precision is not absolutely necessary, but speed is paramount.
Never
in the code.
Merge request has been updated - I have also added two new tests based
on your examples. Thanks again Marģers.
Kit
On 28/06/2024 13:24, J. Gareth Moreton via fpc-devel wrote:
Hi Marģers,
Thanks for the feedback!
Assigning the results of pure functions to constants has not yet bee
re functions? It seems like the JIT is actually
easier to implement than all this complicated node analysis, but probably
slower to run I may guess. I think the LLVM backend could do this but the main
code generator I'm not sure.
On Jun 30, 2024, at 9:17 AM, J. Gareth Moreton via fpc-de
Aah, thanks Marco. I still have some things to learn about FPC!
Kit
On 01/07/2024 08:05, Marco van de Voort via fpc-devel wrote:
Op 1-7-2024 om 02:34 schreef Hairy Pixels via fpc-devel:
I had a question about pure functions. I'm seeing some newer
languages have a JIT built-in so they can run
In the case of JVM, the JIT compiler is specific to Java, I think.
Normally JIT requires the source code to be compiled into an
intermediate bytecode first (e.g. Java bytecode or the Common
Intermediate Language (.NET)).
Kit
On 01/07/2024 09:33, Mattias Gaertner via fpc-devel wrote:
On 7/
On a related note, I do wonder where pure functions might help with
JIT. It depends on what Florian and the other administrators and
developers seek, but currently I aim for my pure function implementation
to fulfil both standard properties (1. same output for the same
input(s), and 2. no side
Oh yes, that's a silly mistake! Easy enough to fix hopefully.
Kit
On 01/07/2024 18:09, Marģers . wrote:
> 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
--
This email has been checked for viruses by A
Fixed! Thanks again Marģers.
Kit
On 01/07/2024 18:09, Marģers . wrote:
> 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
--
This email has been checked for viruses by Avast antivirus software.
www.avas
Hi everyone,
Just thought I'd give a heads-up on what's happening with me and the
compiler improvements. Also, I've been busy with contract work and have
just had some minor surgery, so I'm not running on all cylinders currently.
* Still waiting on administrator comments and feedback on my
Should I use a compiler definition instead like "-dX86_VECTORS"? That
way, the feature can easily be turned off.
Kit
On 21/08/2024 15:59, J. Gareth Moreton via fpc-devel wrote:
Hi everyone,
Just thought I'd give a heads-up on what's happening with me and the
compiler imp
s, and there may
be some unnecessary reads and writes between the stack and XMM
registers, but I'm working on it, bit by it.
My current branch can be found here:
https://gitlab.com/CuriousKit/optimisations/-/commits/ucomplex-x86-vector
Kit
On 23/08/2024 17:56, J. Gareth Moreton via fpc-devel
Thanks Denis,
I have to be slightly careful though because the example I gave with
"addps" is not actually correct, because (%r8) could be unaligned (it
works fine with "vaddps" though due to a paradigm change in the design
of AVX compared to SSE). In this situation a more correct example wou
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 1
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
fpc-develfp
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 supp
urce code. Dmitriy
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
> alr
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 tho
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
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
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.
>
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
> be
ous failure 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
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 he
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 versi
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 wit
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 i
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 it
ising currently!
Gareth 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
0 03:59, Ryan Joseph via fpc-devel 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
nter
type (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 arra
fining 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 fp
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 pro
t;compiler/x86/aasmcpu.pas".
Torsten
-----Original-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 h
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 circumstances
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?
#x27; and
'cmp' on %rax directly)
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
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
ot
correct. I check 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, a
ka. Kit
On 01/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.
it looks 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. An
07:59, 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'
size,
does it pay off.
So it looks 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
ide 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
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
03/10/2020 14:18, Jonas Maebe via fpc-devel 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
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
don't
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 ak
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 r
ng up.
Let me know 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
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
onally, 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
uotient will
always be 0 or 1 in these instances.
Gareth aka. 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 d
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
fl
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
e LDR).
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 w
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 optimisati
ly awkward 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
0 14:10, Jonas Maebe 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
, although 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 awkwa
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.
https://ww
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
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
e
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
.
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 part
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
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 to
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 for
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, it'
yan Joseph via fpc-devel 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
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 eve
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,
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 fpc-d
ackgrounds, 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-d
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. K
en 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): ansistri
Arch64, and on the
same platform, I'm almost finshed implementing 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-de
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 AM
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 defined".
Yes, and the
On 24/11/2020 01:13, 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
1 - 100 of 493 matches
Mail list logo
