Sorry, I just realised that was unfairly impatient of me. I've still got
little things I can work on, but I'm worried about creating a large
backlog.
Gareth
On Fri 15/06/18 21:11 , "J. Gareth Moreton" gar...@moreton-family.com
sent:
Something tells me that we should write our own patch.exe
Something tells me that we should write our own patch.exe at some point to
alleviate these shortcomings! Thanks for the patch again.
Any word on what I've submitted so far? I ask because I found some new
peephole optimisations that can make some good speed and size savings, but
one of them requ
Am 15.06.2018 um 18:17 schrieb J. Gareth Moreton:
Not much luck for me - the file won't patch without options or modifications, and using -p 1 to remove the "a/" and "b/"
from the starts of the files causes an assertion in patch.exe.
Sorry, my bad. The patch has unix line feeds, this crashes p
Not much luck for me - the file won't patch without options or
modifications, and using -p 1 to remove the "a/" and "b/" from the starts
of the files causes an assertion in patch.exe. Back to doing it manually
for now!
Gareth
On Fri 15/06/18 16:23 , Florian Klämpfl flor...@freepascal.org sent
Oh! I'm still a beginner with version
control, it seems!
On Fri 15/06/18 16:23 , Florian Klämpfl
flor...@freepascal.org sent:
> Am 14.06.2018 um 23:49 schrieb J. Gareth
Moreton:
>
> > Hi Florian,
>
> >
>
> > I don't know if you have any answers,
but I'm
> unable to apply any patches I rece
Am 14.06.2018 um 23:49 schrieb J. Gareth Moreton:
Hi Florian,
I don't know if you have any answers, but I'm unable to apply any patches I receive. I can view them and see the
changes, and manually apply them via copy+paste if I have to, but using the "Apply Patch" option ends up not doing
anyt
Hi Florian,
I don't know if you have any answers, but I'm unable to apply any patches
I receive. I can view them and see the changes, and manually apply them via
copy+paste if I have to, but using the "Apply Patch" option ends up not
doing anything. Is there a fix to this, or does it error out b
Thanks. I'll have a study of this and potentially move my initial deep
optimisation component to this stage.
I've made some more peephole optimisations in the meantime, but I'm going
to hold off on posting them because they're starting to conflict with my
other submissions. Besides, I've given
Am 13.06.2018 um 20:50 schrieb J. Gareth Moreton:
I haven't fully uncovered the secrets of
the compiler yet, but I did notice "pre-
peephole pass" under x86, but I think the
only functions it touched was one of the
bit shifts. Does this occur before
register allocation or was it just
something th
I haven't fully uncovered the secrets of
the compiler yet, but I did notice "pre-
peephole pass" under x86, but I think the
only functions it touched was one of the
bit shifts. Does this occur before
register allocation or was it just
something that had to be done before Pass
1?
Gareth
On W
Am 12.06.2018 um 23:27 schrieb J. Gareth Moreton:
Ideally yes, but this occurs after peephole optimisations where all of the register allocations have already been made.
Doing the peephole and deep optimisations while the registers are still in a virtual state would be better overall, but
may r
Am 12.06.2018 um 23:45 schrieb nick...@gmail.com:
On Mon, 2018-06-11 at 21:07 +0100, J. Gareth Moreton wrote:
Thanks David,
I'm still learning some of the nuances of the Intel and AMD
processors, but most of it is just logical analysis. Admittedly my
main drive has been to shrink down the size
Ideally yes, but this occurs after peephole optimisations where all of the
register allocations have already been made. Doing the peephole and deep
optimisations while the registers are still in a virtual state would be
better overall, but may require a huge overhaul of the compiler that might
be
On Mon, 2018-06-11 at 21:07 +0100, J. Gareth Moreton wrote:
> Thanks David,
>
> I'm still learning some of the nuances of the Intel and AMD
> processors, but most of it is just logical analysis. Admittedly my
> main drive has been to shrink down the size of the binary, since
> Delphi and Free Pas
Thanks David,
I'm still learning some of the nuances of the Intel and AMD processors,
but most of it is just logical analysis. Admittedly my main drive has
been to shrink down the size of the binary, since Delphi and Free Pascal
have always been a little bit bloated in comparison. Not that it
Hi,
nice work.
On 8. 6. 2018 0:46, J. Gareth Moreton wrote:
> The deep optimiser changes this to:
>
> movq %rcx,%rax
> movq %rdx,%rsi
> movq %rcx,%rbx
>
> It determines, for the third MOV, it can
> change %rax for %rcx to minimise a
> pipeline stall, and then knows that %rbx
> and %rcx conta
So a progress update.
I've tied in part of my deep optimiser
into the peephole optimiser, specifically
PostPeepholeOptMov, and it's had some
unexpected benefits. One of the things it
does is start with a MOV command that
copies a register's contents into another,
then looks at subsequent ref
So far, I'm researching the optimisation as listed below... tracking
registers with identical values and changing them to minimise pipeline
stalls. Because I don't need to keep track of their actual values, just
whether they've changed since a particular MOV instruction, I've managed to
move this
Am 21.05.2018 um 21:05 schrieb J. Gareth Moreton:
Would you object to me trying anyway, Florian?
No, feel free to go ahead, but it needs to be done step by step.
It might be that I run into the same problems you had and it's too
unsafe, but I'm going by a conservative philosophy in that if it
Would you object to me trying anyway, Florian? It might be that I run into
the same problems you had and it's too unsafe, but I'm going by a
conservative philosophy in that if it spots something that it can't work
out (e.g. an instruction that it's not programmed to handle) or is
potentially unsaf
Am 13.05.2018 um 21:02 schrieb Christo:
> On Sun, 2018-05-13 at 03:28 +0100, J. Gareth Moreton wrote:
>> Expand on Data Flow Analysis in the compiler.
>>
>> What I personally call the "Deep Optimizer", I'm proposing an
>> assembler-level optimisation
>> system (although it won't touch pure assemb
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
From: fpc-devel On Behalf Of Wolf
Sent: Friday, 18 May 2018 07:27
This is the disassembly of function GetProcessorUsed: longint;inline;
Unless you advise me otherwise, I take the absence of function
GetProcessorUsed: longint;inline; mentioned anywhere in this screen print
that GetProc
Hi Gareth,
This is the disassembly of /function GetProcessorUsed: longint;
inline; /Unless you advise me otherwise, I take the absence of /function
GetProcessorUsed: longint; inline; /mentioned anywhere in this screen
print that /GetProcessorUsed/ is indeed inlined. And in the face of
Hi,
On 17. 5. 2018 0:56, Wolf wrote:
>
>
> On 14/05/2018 04:30, David Pethes wrote:
>> Hi,
>> I would welcome inlining of (simple) asm routines.
>>
> I do not know what you consider to be the existing obstacles to inlining
> assembler routines.
That this doesn't get inlined :) (FPC trunk, few wee
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 -
On 14/05/2018 04:30, David Pethes wrote:
Hi,
I would welcome inlining of (simple) asm routines.
I do not know what you consider to be the existing obstacles to inlining
assembler routines. What I do know is that in the attached program,
inlining does work. It summarises my (current) understa
Hi,
I would welcome inlining of (simple) asm routines. Lately I wanted to
use the BEXTR instruction to speed up some inlined bit reading
functions. As there's no intrinsic for it and including even a simple
assembly method disables inlining, it didn't go well.
As for using a BEXTR intrinsic instea
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
On Sun, 2018-05-13 at 03:28 +0100, J. Gareth Moreton wrote:
> Expand on Data Flow Analysis in the compiler.
>
> What I personally call the "Deep Optimizer", I'm proposing an assembler-level
> optimisation
> system (although it won't touch pure assembler routines) that rearranges
> commands and
I don't know much about AVR yet, but who knows. At the moment I'm
researching how inline Pascal procedures are compiled and seeing how it can
be translated into assembler routines. It might end up that I end up
writing a kind of mid-level assembler within the Pascal compiler that
allows the regis
31 matches
Mail list logo
