Graeme Geldenhuys wrote:
On 03/09/12 14:05, Mark Morgan Lloyd wrote:
Except that modifying the compiler to generate highly-optimised code for
specific high-level tasks is probably more work than having a fragment
of assembler that needs to be written once per target CPU.
And writing the asse
- Oorspronkelijk e-mail -
> Van: "Graeme Geldenhuys"
> Aan: fpc-devel@lists.freepascal.org
> Verzonden: Maandag 3 september 2012 16:06:14
> Onderwerp: Re: [fpc-devel] Re: Faster Implementation for IntToStr
>
> On 03/09/12 14:05, Mark Morgan Lloyd wrote:
&
- Oorspronkelijk e-mail -
> Van: "Graeme Geldenhuys"
> Aan: fpc-devel@lists.freepascal.org
> Verzonden: Maandag 3 september 2012 12:42:11
> Onderwerp: Re: [fpc-devel] Re: Faster Implementation for IntToStr
>
> On 03/09/12 10:19, Daniël Mantione wrote:
>
On 03/09/12 14:05, Mark Morgan Lloyd wrote:
Except that modifying the compiler to generate highly-optimised code for
specific high-level tasks is probably more work than having a fragment
of assembler that needs to be written once per target CPU.
And writing the assembler for that one task fi
On 03/09/12 13:04, Sven Barth wrote:
and so there is the chance that FPC performs better on ARM than Delphi :)
Always good to hear! :)
Graeme.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo
Am 03.09.2012 15:37, schrieb Nico Erfurth:
On 03.09.12 14:04, Sven Barth wrote:
It will be interesting to benchmark Delphi's ARM compiler once it comes
out as we had quite some work on the ARM optimizer in the last months
and so there is the chance that FPC performs better on ARM than Delphi :)
On 03.09.12 14:04, Sven Barth wrote:
> It will be interesting to benchmark Delphi's ARM compiler once it comes
> out as we had quite some work on the ARM optimizer in the last months
> and so there is the chance that FPC performs better on ARM than Delphi :)
Well, AFAIK the Delphi compiler for AR
Graeme Geldenhuys wrote:
On 03/09/12 08:33, Michael Schnell wrote:
OTOH, for such a low-level stuff ASM _might_ provide a speed advantage.
Or it means the FPC compiler has place for improvement converting Object
Pascal code to ASM - generating more optimised ASM with -O2 or -O3
parameters.
And furthermore, current intrinsic implementation of BSR/BSF also does not
check Z-flag after execution. That is bad, I think.. :(
I have no AMD/etc CPU to stress-test, only Intel. So I can not guarantee
the assumption of "unchanged destination, if source=0".
---
WBR,
Max.
Am 03.09.2012 12:42, schrieb Graeme Geldenhuys:
On 03/09/12 10:19, Daniël Mantione wrote:
Certainly, but the code used in that asm implementation is quite out of
reach for compilers.
Certainly, but there is always scope for improvements right? eg: Delphi
is well know for generating more optim
BTW, I found only one caveat in that asm-implementation: according to Intel docs
target register of BSR is "undefined" if source=0, so Z-flag should always
be checked after BSF/BSR.
In case of "int_str" ECX randomisation after BSR surely will lead to crash,
but in practice I can not reproduce suc
On 03/09/12 10:19, Daniël Mantione wrote:
Certainly, but the code used in that asm implementation is quite out of
reach for compilers.
Certainly, but there is always scope for improvements right? eg: Delphi
is well know for generating more optimised ASM than FPC. I'm by no means
saying that
Daniël Mantione wrote on Mon, 03 Sep 2012:
Certainly, but the code used in that asm implementation is quite out
of reach for compilers.
Given that we now have support for the bsr intrinsic, it should be
possible to more or less literally translate it into Pascal though.
The trick to change th
Op Mon, 3 Sep 2012, schreef Graeme Geldenhuys:
On 03/09/12 08:33, Michael Schnell wrote:
OTOH, for such a low-level stuff ASM _might_ provide a speed advantage.
Or it means the FPC compiler has place for improvement converting Object
Pascal code to ASM - generating more optimised ASM with
On 03/09/12 08:33, Michael Schnell wrote:
OTOH, for such a low-level stuff ASM _might_ provide a speed advantage.
Or it means the FPC compiler has place for improvement converting Object
Pascal code to ASM - generating more optimised ASM with -O2 or -O3
parameters.
G.
__
On 09/02/2012 04:11 PM, Max Nazhalov wrote:
Don't bother with assembler -- it's not portable at all. In general,
just make a clean implementation of what You think, try to adopt this
to "generic.inc", recompile the trunk, run test suite and then create
Mantis entry with source diff. Sure it wil
On 09/02/2012 03:51 PM, Amir wrote:
In general, how can one propose some changes in a library? Should
the suggestion goes through this mailing list?
The most appropriate way seems to be to improve the existing ASM
version. Of course other archs would not take advantage from this but
coul
On Sun Sep 2 15:51:05 CEST 2012 Amir wrote:
> I could not follow what the code does, as it is in assembly, but it
> looks like it has the same idea as mine.
>
>In general, how can one propose some changes in a library? Should the
> suggestion goes through this mailing list?
Don't bother
On 02 Sep 2012, at 15:51, Amir wrote:
> In general, how can one propose some changes in a library? Should the
> suggestion goes through this mailing list?
Create a patch against the FPC sources and post it as a feature to the bug
tracker (http://bugs.freepascal.org ).
Jonas_
I could not follow what the code does, as it is in assembly, but it
looks like it has the same idea as mine.
In general, how can one propose some changes in a library? Should the
suggestion goes through this mailing list?
Amir
On 09/02/2012 05:24 PM, Jonas Maebe wrote:
On 02 Sep 2012,
On 02 Sep 2012, at 14:46, Max Nazhalov wrote:
> And also an i386-speciic assembler variants in "./FPC_SRC/rtl/i386/i386.inc",
> which I suspect use approach similar to yours, but I'm not sure they are
> "enabled"..
>
> {$if defined(disabled) and defined(regcall)}
> procedure int_str(l:longword
On Sun, 02 Sep 2012, Amir wrote:
> Hi,
>In one of my project, I have to call IntToStr more than 10M times.
> I noticed that IntToStr calls Str function. I implemented my own version
> of IntToStr which is almost twice faster than the current implementation
> of IntToStr.
> I wonder if it is p
22 matches
Mail list logo
