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 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 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.
__
Hello,
I searched a bit but there seams to be no documentation showing how to
implement a new dataset, correct? Any idea what is the list of minimum
amount of methods which I need to implement? I really would like to
implement the absolute minimum to get started. I am starting already
based on wha
On Mon, 3 Sep 2012, Felipe Monteiro de Carvalho wrote:
Hello,
I searched a bit but there seams to be no documentation showing how to
implement a new dataset, correct? Any idea what is the list of minimum
amount of methods which I need to implement? I really would like to
implement the absolut
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
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
> > The installer encountered the following error:
> > Access violation
> > make[2]: *** [all] Error 1
> > make[2]: Leaving directory `C:/Dev/FPC/sources/packages'
> > make[1]: *** [packages_all] Error 2
> > make[1]: Leaving directory `C:/Dev/FPC/sources'
> > make: *** [build-stamp.arm-wince] Error
Gennadiy Poryev wrote on Mon, 03 Sep 2012:
> The installer encountered the following error:
> Access violation
> make[2]: *** [all] Error 1
> make[2]: Leaving directory `C:/Dev/FPC/sources/packages'
> make[1]: *** [packages_all] Error 2
> make[1]: Leaving directory `C:/Dev/FPC/sources'
> make:
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
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 Mon, Sep 3, 2012 at 11:18 AM, wrote:
> I think your best bet is to create a descendent of TBufDataset: it is in
> itself a full TDataset.
>
> You'll have to implement the least amount of methods there, and you can see
> in TSQLQuery which ones.
But why would this be a better solution? TBufDat
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
On Mon, 3 Sep 2012, Felipe Monteiro de Carvalho wrote:
On Mon, Sep 3, 2012 at 11:18 AM, wrote:
I think your best bet is to create a descendent of TBufDataset: it is in
itself a full TDataset.
You'll have to implement the least amount of methods there, and you can see
in TSQLQuery which one
> But why would this be a better solution? TBufDataset is huge
> ... it me it looks much harder to understand how it works and
> subclass it then to attempt to start with empty methods and
> see if implementing something on them will work.
>
You can also take a look at rxmemds in the rx compone
On Mon, Sep 3, 2012 at 2:15 PM, wrote:
> And do not forget, you don't need to do TBufDataset, but TSQLQuery.
> That just implements a few simple things. The rest is taken care of by
> TBufDataset.
Now you are confusing me even more. Are you suggesting that I subclass
TSQLQuery?
--
Felipe Monte
On Mon, Sep 3, 2012 at 2:19 PM, Ludo Brands wrote:
> What is it you are trying to accomplish? A dataset that can be accessed from
> java or the other way around, access an android integrated database
> (sqlite?) over jni?
The second one: Access sqlite Java API from native code.
The normal TSQLit
>
> The second one: Access sqlite Java API from native code.
>
> The normal TSQLite3Connection does not work in Android (no idea why).
>
Then you need to make a TSQLConnection descendant which is below
TBufDataset.
Ludo
___
fpc-devel maillist - fp
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.
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.
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
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 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
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 Mon, Sep 3, 2012 at 2:15 PM, wrote:
> Believe me, it is not :-)
Could you make some theorical considerations about this? From what I
see now my 2 choices are either implement a TDBDataset descendent or a
TSQLConnection descendent. For me it doesn't matter either way, but
TSQLConnection looks
> >> > The installer encountered the following error:
> >> > Access violation
> >> > make[2]: *** [all] Error 1
> >> > make[2]: Leaving directory `C:/Dev/FPC/sources/packages'
> >> > make[1]: *** [packages_all] Error 2
> >> > make[1]: Leaving directory `C:/Dev/FPC/sources'
> >> > make: *** [build-s
Gennadiy Poryev wrote on Mon, 03 Sep 2012:
Is there a way to locally prevent this particular package from being
compiled and included in installation? I don't use it anyway.
You can edit packages/fpmake_proc.inc and fpmake_add.inc. I doubt it
will help though. The problem is probably not c
Does this
1) prevent functions declared in this unit from being inlined (in this
or other units)
2) functions from other units, that are called in this unit from being
inlined:
I get 1, but not 2:
program project1; {$mode objfpc}{$H+} {$INLINE OFF}
uses Classes, types;
function MyPoint(X,
Am 03.09.2012 17:13, schrieb Martin:
Does this
1) prevent functions declared in this unit from being inlined (in this
or other units)
2) functions from other units, that are called in this unit from being
inlined:
I get 1, but not 2:
program project1; {$mode objfpc}{$H+} {$INLINE OFF}
uses Cl
- 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:
> >
> > Certainly, but the code used
- 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:
> >
> > Except that modifying the
> > Is there a way to locally prevent this particular package from being
> > compiled and included in installation? I don't use it anyway.
> You can edit packages/fpmake_proc.inc and fpmake_add.inc. I doubt it will
> help though. The problem is probably not caused by that package in
> particular, b
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
33 matches
Mail list logo
