Brad,
I think there were macros relying on the copiler to handle 64-bit math
and, as I remember, it was 2 times slower than arm specific code. But
I'll check anyway. Altough 32-bit math should be enough, but it probably
needs some good thinking and smart tricks (or may be not).
Regards,
Victor.
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Brad
Midgley
Sent: Tuesday, January 17, 2006 23:01 PM
To: [email protected]
Subject: [Bluez-devel] libsbc refactoring
Victor,
I've been meaning to try to simplify the 64-bit fixed point by
eliminating the struct that combines two 32-bit values. So now we depend
on the compiler to do all 64-bit math. The arm assembly goes out.
Can you try this and make sure it's still performing well on arm?
This makes all the different flavors of math look the same in the basic
ops:
#define SBC_FIXED_0(val) {val =3D 0;}
#define ADD(dst, src) {dst +=3D src;}
#define SUB(dst, src) {dst -=3D src;}
#define MUL(dst, a, b) {dst =3D (sbc_fixed_t)a * b;} #define MULA(dst, a,
b) {dst +=3D (sbc_fixed_t)a * b;}
so we could even eliminate these macros. I know Marcel would be happy to
see them go ;)
Brad
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files for problems? Stop! Download the new AJAX search engine that
makes searching your log files as easy as surfing the web. DOWNLOAD
SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=3D=
121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
This e-mail message contains information which is confidential and may be=
privileged. It is intended for use by the addressee only. If you are not=
the intended addressee, we request that you notify the sender immediatel=
y and delete or destroy this e-mail message and any attachment(s), withou=
t copying, saving, forwarding, disclosing or using its contents in any ot=
her way. TomTom N.V., TomTom International BV or any other company belong=
ing to the TomTom group of companies will not be liable for damage relati=
ng to the communication by e-mail of data, documents or any other informa=
tion.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Victor
I will roll it back if we know that is happening with gcc.
If it isn't too hard to modify the arm assembly for doing the basic ops
using an int64_t instead of the int32_t/uint32_t I'd like to see that.
Where should I pick up with the 32-bit code? I think I saw this in a header
#define SP4(val) (val >> SCALE_PROTO4_TBL)
and I was thinking it should look more like
#define SP4(val) (((int32_t)val)/(1<<SCALE_PROTO4_TBL))
To preserve negative values. Does that seem reasonable? I didn't do
anything with this idea yet.
I think the (int32_t) cast was necessary because the tables use a
positive-looking hex constant for negative values.
Brad
> I think (may be mistakenly) gcc does not use all the optimizations, only
> generic ones and, probably, the 32x32 -> 64 register multiplication is
> not among them. It might be that the arm compiler does this kind of
> optimizations, but it needs licensing I guess.
>
> Regards,
> Victor.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Brad
I think (may be mistakenly) gcc does not use all the optimizations, only
generic ones and, probably, the 32x32 -> 64 register multiplication is
not among them. It might be that the arm compiler does this kind of
optimizations, but it needs licensing I guess.
Regards,
Victor.
On Thu, 2006-01-19 at 09:36 -0700, Brad Midgley wrote:
> Victor
>
> > I think there were macros relying on the copiler to handle 64-bit math
> > and, as I remember, it was 2 times slower than arm specific code. But
> > I'll check anyway. Altough 32-bit math should be enough, but it probably
> > needs some good thinking and smart tricks (or may be not).
>
> I want to have a look at unifying on 32-bit but I was hoping this would
> be ok to clean things up a bit.
>
> I can see why assembly would be better than working with two 32-bit
> values. You don't have a way to get at the add-with-carry assembly
> instruction for example. But the compiler has got to be doing something
> wrong if basic math ops on a native c type (int64_t) are only half as
> fast as hand-coded assembly. :(
>
> Brad
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Victor
> I think there were macros relying on the copiler to handle 64-bit math
> and, as I remember, it was 2 times slower than arm specific code. But
> I'll check anyway. Altough 32-bit math should be enough, but it probably
> needs some good thinking and smart tricks (or may be not).
I want to have a look at unifying on 32-bit but I was hoping this would
be ok to clean things up a bit.
I can see why assembly would be better than working with two 32-bit
values. You don't have a way to get at the add-with-carry assembly
instruction for example. But the compiler has got to be doing something
wrong if basic math ops on a native c type (int64_t) are only half as
fast as hand-coded assembly. :(
Brad
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel