learning the system.
Yours faithfully,
J. Gareth Moreton aka. Curious Kit
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Hi everyone,
Following on from an enhancement report I posted a few months ago, I decided to
take a shot at learning the
nuances of the compiler's source code and programming in the improvements
myself. These don't fix any bugs per
se, but aim to reduce the code size of compiled x86-64 binari
Thank you Anthony,
Admittedly I was a little nervous, wondering if you guys might think "what's
this squirt doing submitting
something that isn't even a bug?!"
Good to know that it looks reasonable. I did do a full build of FPC and
Lazarus with it to ensure it
actually compiled and ran (Laza
ämpfl flor...@freepascal.org sent:
> Am 24.09.2017 um 14:20 schrieb J. Gareth Moreton:
>
> > Hi everyone,
>
> >
>
> > Following on from an enhancement report I posted
> a few months ago, I decided to take a shot at learning the
> > nuances of the compiler's so
Hi Markus,
Nice to see there's more than one person working to improve compiled code on
x86-64!
I can answer one question... the byte sequence 0F B6 01 is the direct machine
code representation of movzbl
(%rcx),%eax - this might be due to a bug with the assembler or movzbl not being
recognise
then it might be a necessity -
otherwise is it possible to
flag it up to get it fixed in GAS rather than having to do the dangerous task
of encoding direct machine
code to get around it?
Gareth
On Sun 01/10/17 00:00 , "J. Gareth Moreton" gar...@moreton-family.com sent:
> Hi Marku
So I've been doing some playing around recently, and noticed that while
FillChar has some very fast internal
code for initialising a block of memory, making use of non-temporal hints and
memory fences, the versions
for the larger types fall back to slow Pascal code. To showcase this, I ran a
E.
J. Gareth "Kit" Moreton
On Wed 01/11/17 11:03 , Sergei Gorelkin via fpc-devel
fpc-devel@lists.freepascal.org sent:
>
>
>
>
> 01.11.2017 10:46, Sven Barth via fpc-devel wrote:
>
> > Am 01.11.2017 05:58 schrieb "J. Gareth
> Moreton" e...@moret
Okay, I'm about to start attempting to implement my versions of FillWord,
FillDWord and FillQWord (along with
some fixes to bugs that I noticed in my code in the interim)... given that I
have to push and pop RDI to use
REP STOSQ etc, what do I need to do in order to ensure SEH handles the stack
ome SEH code to account for "push %rdi" (Linux
doesn't have this problem), I'd be
most grateful. I hope it's at least a good start.
Yours faithfully,
J. Gareth Moreton
___
fpc-devel maillist - fpc-devel@lists.freepascal
tium III era. Is it worth updating the longer byte sequences to use the
5-to-9-byte sequences for a
very minor performance boost and reduction in file entropy (the 00s will be
easier to compress since they
generally appear more frequently in the entirety of the binary)?
Yours faithfully
I'm guessing my code is not correct or causes problems. I haven't had much
luck in finding a straight answer
regarding proper exception handling with assembler code (where correcting
non-volatile registers and stack
space are concerned), although I'll keep trying. I tried asking on the forum,
Hi everyone,
Re: https://bugs.freepascal.org/view.php?id=32637
I apologise for my slight outburst. I didn't quite appreciate Thaddy's response
when I asked how to get SEH to
keep track of pushed registers (
http://forum.lazarus.freepascal.org/index.php/topic,39071.msg266937 ), but
Marcov gave
Hi everyone,
Re: https://bugs.freepascal.org/view.php?id=32637
I apologise for my slight outburst. I didn't quite appreciate Thaddy's response
when I asked how to get SEH to
keep track of pushed registers (
http://forum.lazarus.freepascal.org/index.php/topic,39071.msg266937 ), but
Marcov gave
Hi everyone,
Re: https://bugs.freepascal.org/view.php?
id=32637
I have now modified my assembler code that
contains ".seh_pushreg %rdi" after each
"push %rdi" instruction (the Linux
versions don't actually push any registers
because the required %rdi register is
volatile on that platform). I
sent:
> On Sun, 2017-11-26 at 09:29 +0000, J. Gareth Moreton wrote:
>
> > I'm guessing my code is not correct or causes
> problems. I haven't
> > had much luck in finding a straight answer
>
> > regarding proper exception handling with
> assembler code (wh
vel"
fpc-devel@lists.freepascal.org sent:
>
>
>
>
> 29.11.2017 15:12, J. Gareth Moreton wrote:
>
> > Thanks Christo.
>
> >
>
> > Apologies for 4 messages coming in at once. I
> think there were a few technical glitches with the mailing
> > list
Thu 30/11/17 04:26 , "J. Gareth Moreton" gar...@moreton-family.com sent:
> Ooh right, okay. Thanks for that Sergei. I just put it in somewhat
> blindly because the compiler inserts it
> for Pascal code after the normal prologue after creating a stack frame, but
> complained
With no further objections, I've uploaded the patch to
https://bugs.freepascal.org/view.php?id=32637 - it is
prefixed with "STACK_FRAME_" - ignore the other 3 patches, as they're incorrect.
Gareth aka. Kit
On Thu 30/11/17 04:47 , "J. Gareth Moreton" gar...@mo
Hi everyone,
This is not something I'm able to check myself because I don't have Linux or a
suitable virtual machine
installed, but according to another assembler programmer, Linux is possibly
doing something weird if the
return type is an array of 4 Singles (stored as a record type):
Conside
r 2 Singles put into another, instead of into an XMM register each, say.
Kit
On Sun 03/12/17 14:18 , Jonas Maebe jo...@freepascal.org sent:
> On 03/12/17 01:01, J. Gareth Moreton wrote:
>
>
>
> > The rules of the
>
> > x86_64 ABI - http://refspecs.linuxbase.org
Hi everyone,
I have a little question to ask. If one wishes to request new features for a
future version of Free Pascal,
how does one go about it and what is the process of determining if it is a good
idea or should be dropped, as
well as any cross-platform and language nuances that need sort
Thanks for the answers everyone. I've
added my suggestion near the bottom of the
page. I wasn't sure because what I propose
is a language feature, namely per-type
byte alignment.
Kit
On Tue 05/12/17 13:05 , Bart
bartjun...@gmail.com sent:
> On Tue, Dec 5, 2017 at 10:07 AM, Mark
Morgan Lloyd
Should I still open a bug/feature request though? When it comes to
high-performance applications such as
games and scientific/mathematical programs, I feel this is quite important.
Kit
On Tue 05/12/17 17:34 , "J. Gareth Moreton" gar...@moreton-family.com sent:
> Thanks fo
Ah, thank you for clearing that up. Time for a different approach then -
feature request!
Kit
On Tue 05/12/17 21:08 , Jonas Maebe jo...@freepascal.org sent:
> On 04/12/17 13:01, J. Gareth Moreton wrote:
>
> > Fair enough. I would have thought that
> "array[0..3] of
uage features rather than
components or anything to do with
the IDE). One is the aforementioned byte alignment feature, and the other is
Microsoft's "vectorcall"
calling convention for Win32 and Win64.
I hope the ideas are not fundamentally flawed.
Kit
On Tue 05/12/17 20
s Hajny wrote:
>
> > On Tue, December 5, 2017 21:50, J.
Gareth
> Moreton wrote:> Should I still open a
bug/feature request though? When
> it comes to> high-performance
applications such as> games and
> scientific/mathematical programs, I feel
this is quite> important.
&g
Hi everyone,
Since I'm masochistic in my desire to understand and improve the Free Pascal
Compiler, I would like to add
some vectorisation support in its optimisation cycle, since that is one thing
that many other compilers
attempt to do these days. But before I begin, does FPC support any ki
30, since
almost all modern Intel and AMD processors
have 56+ elements in their queues.
On Sun 10/12/17 13:50 , "Florian Klämpfl"
flor...@freepascal.org sent:
> Am 10.12.2017 um 02:29 schrieb J. Gareth
Moreton:
>
> > Hi everyone,
>
> >
>
> > Since
I guess fixing that might be a good
starting point. There's also the issue of
memory alignment causing crashes.
Kit
On Mon 11/12/17 12:19 , mar...@stack.nl
(Marco van de Voort) sent:
> In our previous episode, Adriaan van Os
said:
>
> > > Since I'm masochistic in my desire
to
> understand a
ife's calling!!
Kit
On Mon 11/12/17 13:44 , "Adriaan van Os" f...@microbizz.nl sent:
> J. Gareth Moreton wrote:
>
> > I guess fixing that might be a good
>
> > starting point. There's also the issue of
>
> > memory alignment causing crashes.
>
P.S. For design ideas and patches that need collaboration, is the Wiki usually
the way of going about it?
Kit
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
I created a Wiki page to plan things out:
http://wiki.lazarus.freepascal.org/Vectorization
It's a stub currently.
Kit
On Mon 11/12/17 20:34 , "J. Gareth Moreton" gar...@moreton-family.com sent:
> P.S. For design ideas and patches that need collaboration, is the Wiki
> usu
Okay, sit back everyone - this is a long read!
I'm starting with the problem as listed in
https://bugs.freepascal.org/view.php?id=27870 with the source
code provided, although with {$codealign varmin=16} and {$codealign
localmin=16} at the top.
I'm running the latest version of the compi
approved yet.
With things like loop unrolling and optimisation as well, this will likely be a
long-term area of research
on my part.
Kit
On Tue 12/12/17 10:21 , "Adriaan van Os" adri...@microbizz.nl sent:
> J. Gareth Moreton wrote:
>
> > I created a Wiki page to plan things
https://bugs.freepascal.org/view.php?id=27870
I've made a patch that hopefully fixes this bug, as well as provide some future
expansion for vectorization.
There are a few new internal sizes such as "OS_MF128" that serve to ensure the
most optimal move command is
used (out of MOVAPS, MOVAPD and
Hey Adriaan,
I dare ask - did the patch help out your issue at all? I did supply it to
Florian as well, although he has
his own work in progress for vectorization, so whether my code is compatible or
not waits to be seen.
Gareth aka. Kit
On Thu 14/12/17 20:29 , "J. Gareth Moreton
Hi everyone,
I can't remember if this has been brought up in the fpc-devel mailing list yet,
but as discussed under
Feature Ideas (
http://wiki.lazarus.freepascal.org/Feature_Ideas#Per-type_Byte_Alignment ) and
in bug number
32780 ( https://bugs.freepascal.org/view.php?id=32780 ), I would lik
Hi everyone,
During my exploration of FPC, I noticed that the 'mod' operator is not
optimized in the same way 'div' is.
Though not deeply tested on other platforms yet, I have developed a patch for
3.1.1 that implements the
algorithm that calculates a reciprocal constant for unsigned 'mod' op
I've used DivMod myself before, akin to something like this under Windows:
{$ASMMODE Intel}
function DivMod(N, D: QWord; var R: QWord): QWord; assembler; nostackframe;
asm
MOV R9, RDX
MOV RAX, RCX
XOR RDX, RDX { Zero RDX because the DIV operation uses RDX:RAX as the
numerator }
DIV R9
power of
> two, then
> a mod t
>
> can be translated at compile time to
>
> a and (t-1)
>
>
>
> Cheers, Ched'
>
>
>
>
>
>
>
>
>
> Le 05.01.2018 à 04:32, J. Gareth Moreton
a écrit :
>
> > Hi everyone,
>
So while testing some proposed optimisations for how div and mod operations are
compiled, I came across an
internal error in the compiler.
https://bugs.freepascal.org/view.php?id=33004
I haven't yet delved into the location of Internal error 200706094, but
something worth bringing up because i
On Thu 11/01/18 21:03 , Florian Klämpfl
flor...@freepascal.org sent:
> Am 11.01.2018 um 21:46 schrieb J. Gareth
Moreton:
>
> > So while testing some proposed
optimisations for
> how div and mod operations are compiled,
I came across an
> > internal
Hi everyone,
So unless anyone has any objections, I would like to start experimenting to
implement a feature that allows
for per-type data alignment. The main purpose for this is to better support
x86-64 SIMD extensions, where
aligned data is far faster to process. While there is a compiler
One minor thing... the square brackets are meant to denote an optional element,
not part of the actual syntax.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
pascal.org/view.php?
id=32780 - unless you want the 'align' suffix.
Gareth aka. Kit.
On Mon 22/01/18 21:07 , Florian Klämpfl flor...@freepascal.org sent:
> Am 19.01.2018 um 21:08 schrieb J. Gareth Moreton:
>
> > Hi everyone,
>
> >
>
> > So unless
any local variables are given the correct alignment
on the stack, even if the
stack is unaligned beforehand.
Gareth aka. Kit
On Fri 26/01/18 15:41 , "Adriaan van Os" f...@microbizz.nl sent:
> J. Gareth Moreton wrote:
>
> > Oh right. I see that you've opted to
Sorry, something badly worded there. However, normally the stack is then
aligned to a 16-byte boundary,
BEFORE any variables are put on the stack, because a stack frame is set up
which includes pushing RBP to the
stack, hence aligning it.
On Fri 26/01/18 20:57 , "J. Gareth Moreton
On Sat 27/01/18 16:33 , Jonas Maebe jo...@freepascal.org sent:
>
>
> Adriaan van Os wrote:
>
> > J. Gareth Moreton wrote:
>
> >
>
> >> For Florian's fix though, any local
> variables are given the correct
> >> alignment o
Hi everyone,
So I've almost finished implementing Microsoft's 'vectorcall' calling
convention into Free Pascal - the final
sticking point are Homogeneous Float Aggregates (HFA's), since the
documentation isn't tremendously clear on
their internal alignment - vectorcall allows the passing and r
Hi everyone,
After a lot of work, I have implemented 'vectorcall' into Win64, and made a
patch for Lazarus to recognise
the keyword in the IDE and highlight it accordingly.
FPC vectorcall patch:
https://bugs.freepascal.org/view.php?id=32781
Lazarus vectorcall support patch:
https://bugs.free
PS assume you are on devel list tho' doing a reply to this email in gmail
copies you and devel? Doh.
On 7 February 2018 at 08:23, J. Gareth Moreton wrote:
Hi everyone,
After a lot of work, I have implemented 'vectorcall' into Win64, and made
a patch for Lazarus to recogni
Hi everyone,
Sorry this took so long. There was a bug in my "vectorcall" submission
in that if you specified "vectorcall" on a method under Linux (it might
have been specifically a virtual method), it stored Self in RCX instead of
RDI, rather than silently ignoring the Windows-only calling conv
the bug tracker.
Gareth aka. Kit
On Sun 01/04/18 02:07 , "J. Gareth Moreton" gar...@moreton-family.com
sent:
Hi everyone,
Sorry this took so long. There was a bug in my "vectorcall" submission
in that if you specified "vectorcall" on a method under Linux (it
If I may add a possible solution, would code akin to the following fix the
problems? (Pray that the mail list formatting doesn't mess it all up!)
{$WARN 7121 off : Check size of memory operand "$1: memory-operand-size is
$2 bits, but expected [$3 bits]"}
{$ASMMODE Intel}
const
MAX_D
I've done some speed and accuracy comparisons between our respective Frac
functions. Initially, my "SafeFrac" was marginally faster than
"FracDoSkip", but I managed to optimise Thorsten's routine a little bit
into the following:
function FracSkip2(const X: ValReal): ValReal; assembler; nostackf
As an extra point, removing the 'skip' check (i.e. cmp ax, $3FE0, jbe
@@skip) removes 6 bytes from the code size and shaves about 2 to 3
nanoseconds off the execution time in most cases, and it could be argued
that it's worth going for the 'no skip' version because using Frac on a
value of x where
That's great to hear! Glad to help.
For functions with no stack frame, the
compiler simply puts RET at the very end
of the routine and is all that's needed.
For functions with a stack frame, either
LEAVE or MOV RSP, RBP; POP RBP must
precede it. The optional parameter after
RET is the number
...@gmx.net sent:
> From: fpc-devel On Behalf
> Of J. Gareth Moreton
> For functions with a stack frame, either LEAVE or MOV RSP, RBP; POP
> RBP must precede it.
It's not quite that simple, at least under windows:
https://docs.microsoft.com/en-us/cpp/build/prolog-and-epilo
Hi Florian. Thorsten and I got down to a fairly optimised version of
Frac, in both speed and size:
function Frac(const X: ValReal): ValReal; assembler; nostackframe;
asm
movq rax, xmm0
shr rax, 48
and ax, $7FF0
cmp ax, $4330
jge @@zero
I reopened the bug ticket to attach a patch with the new function. It also
contains some code for "Int" that passes through the input unchanged if its
magnitude is greater than 2^52 (at this point, the precision means it can't
have a fractional component). I've set it to "feedback" currently so S
As Sven pointed out, there are still
faults in our functions in that they don't
honour NaNs. It's an easy enough fix, but
will just need an extra bit of code.
I asked about the rules regarding
infinities, but going by what happens with
the old floating-point stack, an exception
is raised, so
On Tue 01/05/18 20:11 , Jonas Maebe
jo...@freepascal.org sent:
> On 01/05/18 21:06, J. Gareth Moreton
wrote:
>
> > I asked about the rules regarding
>
> > infinities, but going by what happens
with
>
> > the old floating-point stack, an
exception
>
> &
It turns out I did over-engineer the solution somewhat - this version is
far more efficient, honours NaNs and triggers SIGFPE if infinity is passed
in (subsd triggers it), hence there are no regressions.
function fpc_frac_real(d: ValReal): ValReal; compilerproc; assembler;
nostackframe;
On Wed 02/05/18 06:55 , Sven Barth pascaldra...@googlemail.com sent:
...
Thank you for the work so far. Does it also work correctly when
exceptions are disabled?
Regards, Sven
I confess I haven't tested that - I know it involves setting the FPU
control word, but what should I expect?
Gar
dering infinity is an abnormal value to pass, this is
sort of permissible, I think.
Gareth
On Wed 02/05/18 10:16 , "J. Gareth Moreton" gar...@moreton-family.com
sent:
On Wed 02/05/18 06:55 , Sven Barth pascaldra...@googlemail.com sent:
...
Thank you for the work so far. Does it also
I'll keep working on it though, because it seems that some routines may
return placeholder values if exceptions are masked.
Gareth aka. Kit
On Thu 03/05/18 02:35 , "J. Gareth Moreton" gar...@moreton-family.com
sent:
Hi guys,
I've been having difficulties disabling fl
Tests complete! It turns out that I was using SetExceptionMask wrong and
subtracting rather than adding exInvalidOp.
When exceptions are disabled, this new Frac function returns NaN when you
pass in plus or minus infinity. This is consistent with the specification
as listed in Chapter 11, Secti
It's already there. I deleted the faulty one and included a new copy with
the fix. It's probably not the best approach, but I didn't want a long
list of patches like I've ended up with before.
Gareth aka. Kit
On Thu 03/05/18 06:56 , "Sven Barth" pascaldra...@g
As touched upon in the bug report for the broken Frac function, I have
submitted my improved Int function as a separate bug report (
https://bugs.freepascal.org/view.php?id=33693 ). I have supplied a test
program and a sample log to demonstrate correct behaviour.
Gareth aka. Kit
__
Hi everyone,
So for those who have observed me, I can be a little... excitable and
optimistic sometimes with developing for Free Pascal. Sometimes it might
not be for the best, but I'd like to think that what I propose and create
can me implemented relatively seamlessly. To explain, my main sp
egards, Christo
On 13 May 2018 10:31 pm, "J. Gareth Moreton" wrote:
Thanks for your kind words, Christo. A lot of this is personal research,
but I would like to make some elements work. For inline support on
assembler routines, I'm going to be rather conservative about what w
Sorry for this apparent spam. I was talking with Christo about my
current research into a Deep Optimizer and limited inline support for
assembler routines, but unless I'm missing something, my replies aren't
appearing on the mailing list. I'm not sure if there's something in my
messages that's b
Thanks for your kind words, Christo. A lot of this is personal research,
but I would like to make some elements work. For inline support on
assembler routines, I'm going to be rather conservative about what will be
successful - for example, if there exists a CALL operation inside the
routine, I w
iling list that my 1st reply was received by the list.
Regards,Christo
On Tue, May 15, 2018 at 3:10 AM, J. Gareth Moreton wrote:
Sorry for this apparent spam. I was talking with Christo about my
current research into a Deep Optimizer and limited inline support for
assembler routines, but unless I
Unless I'm mistaken, Wolf, you cannot inline procedures that have asm
blocks appearing anywhere (this includes the entire procedure).
Nevertheless, does the disassembly of your program show it to be inlined?
Gareth aka. Kit
___
fpc-devel maillist -
What I've gathered is that with the following routine:
function DoSomething: Integer;
begin
for Result:=alow to ahigh do
if Something(Result) then exit;
end;
The issue occurs if "Something(Result)" always returns False and the
for-loop exits normally. While some languages and compi
Hi everyone,
I've just recently submitted a patch with some code that makes one of the
compiler errors clearer for the user, and minimises a 'cascade' where more
errors appear due to the presence of the first one. Translations aside,
what's the general policy with these "ease of use" patches th
What you've shown suggests that the
routine is NOT inlined, as it's building a
stack frame and the 'add' operations at
the very top looks like padding (they're
all zeroes in machine code) to align the
procedure to a 16 byte boundary, and would
crash the program if directly executed.
Look at
Lawyers or not, well-defined behaviour can only be a good thing for a
language. As for those code snippets in the VCL and the like, unless we
want to change the rule so that the for-loop counter has a distinct value
afterwards, Result should be explicitly set after the for loop (presumably
peop
That looks sensible. Sorry to waste your time on this. I'm glad it states
the for-loop variable will be left undefined - that's good enough
documentation for me.
I wouldn't call it a quick fix... more of fixing an oversight, since I can
see the trick of using Result as the for-counter being ve
Apologies, I meant it was undefined if the loop exits normally,
but retains its current value if terminated prematurely. Ah well!
Admittedly I do like concrete rules, and any situations where something
is undefined is explicitly stated. Hopefully we can put this one to bed
now! Back to more
"
I think based on both documented and observed behaviour, the following
definition would be appropriate:
The for-loop variable is undefined after the loop if the loop ran to
completion. It retains its last value if the loop exited in a controlled
way (goto, break, exit, ?) before running to
Hi everyone,
So I've been taking a look at the issue listed in bug ticket #32913, where
a try...finally block inside the except part of a try...except block either
produces bad assembly language or raises Internal Error 200309201. So
far, I'm still trying to understand the control flow of the co
One could possibly refactor elements of the compiler, and the improvements
to the optimizer might also help in places. I wouldn't call it a major
priority though, although I will make suggestions if I spot anything.
Granted, the niche that I've crafted for myself is assembly language
optimisation
Unless I'm missing something, that could be unrolled without any
problems. The only problem that could occur is if Test2 raises an
exception (which, as the name implies, is an exceptional situation) or it
jumps outside of the procedure, which can only realistically occur in some
compiler optimisa
In that example, I would logically expect an infinite loop.
Realistically, I'm not sure, because you're literally trying to trick the
compiler with a construct like that (which all testers should do!) - that
one could be fun to test!
Gareth aka. Kit
On Mon 21/05/18 19:43 , Florian Klämpfl flo
but if it
doesn't, well, at least I know more about assembly language and have gained
experience to improve the peephole optimiser and other elements of FPC.
Gareth aka. Kit
On Mon 21/05/18 20:44 , Florian Klämpfl flor...@freepascal.org sent:
Am 13.05.2018 um 21:02 schrieb Christo:
> On S
Hi guys,
So I'm still experimenting and researching with the deep optimiser, and
I'm starting to have some successes... until I found a compiler bug!
https://bugs.freepascal.org/view.php?id=33794
What I'm trying to do, and something which I'd like to try out with the
regular peephole optimis
I stand corrected. Sorry to waste your time on that.
Gareth aka. Kit
On Sun 27/05/18 08:31 , Sven Barth via fpc-devel
fpc-devel@lists.freepascal.org sent:
Am 27.05.2018 um 02:48 schrieb J. Gareth Moreton:
Hi guys,
So I'm still experimenting and researching with the deep opti
und a couple of peephole optimisations that don't rely on tricky code
like that in the bug report! I'll submit a patch later, just in case I find
a few more.
Gareth aka Kit.
On Sun 27/05/18 13:00 , Florian Klämpfl flor...@freepascal.org sent:
Am 27.05.2018 um 02:48 schrieb J. Gareth Moret
I've come across an interesting situation with the compiler when it comes
to while loops. It's not necessary erroneous, but I wonder if it incurs a
speed penalty.
Using my code sample to demonstrate:
type
TBinList = record
Key: Integer;
Data: CodePointer;
end;
PBinLi
Good call on using "repeat...until" in my own code, thanks!
I wasn't clear, but my intention was also keeping the conditional check at
the end of the loop, but duplicating it at the start with the condition
inverted. In other words, having both these example code segments:
xorl %
(Apologies if anyone has received multiple copies of this reply - I was
having trouble with the e-mail client and the message formatting)
Good call on using "repeat...until" in my own code, thanks!
I wasn't clear, but my intention was also keeping the conditional check at
the end of the
That seems fair. Thank you for your
answer. I'm still learning about the
nuances of branch prediction and the like.
On Tue 29/05/18 21:27 , Florian Klämpfl
flor...@freepascal.org sent:
> Am 28.05.2018 um 01:55 schrieb J. Gareth
Moreton:
>
> >
>
> > In this case, t
Hi everyone,
I'm starting to make some modifications to the optimizer so it optimises
div and mod operations on signed integers (I've done unsigned integers
already). One question that I've stumbled across... what are the rules
regarding the sign of the result? Experimenting with IDIV suggests
sto Crause"
christo.cra...@gmail.com sent:
> On Fri, Jun 1, 2018 at 11:13 AM, J.
Gareth Moreton wrote:
> Hi everyone,
>
> I'm starting to make some modifications
to the optimizer so it optimises
> div and mod operations on signed
integers (I've done unsigned integers
>
Hi everyone,
I think the latest version of the compiler on SVN is broken. I tried
getting a clean copy from the repository, but running the script fails with
the following on x86_64-win64:
system.pp(123,5) Error: Asm: [sub reg64,imm8s] invalid combination of
opcode and operands
system.pp(126
6/18 18:24 , "J. Gareth Moreton" gar...@moreton-family.com
sent:
Hi everyone,
I think the latest version of the compiler on SVN is broken. I tried
getting a clean copy from the repository, but running the script fails with
the following on x86_64-win64:
system.pp(123,5) Error: A
It seems to have been fixed now after I did a manual deletion of all .o
and .ppu files. Not sure what that was all about. Sorry to waste
anyone's time - emergency over.
Gareth aka. Kit
On Fri 01/06/18 18:35 , "J. Gareth Moreton" gar...@moreton-family.com
sent:
Okay, it prob
1 - 100 of 1212 matches
Mail list logo
