I'd be interested to know what the cpu benefit on android is when
optimisations are enabled.. :)
On 13.10.2010 13:14, Dave Hooper wrote:
I'd be interested to know what the cpu benefit on android is when
optimisations are enabled.. :)
I just did some tests:
http://www.alice-dsl.net/simonemartitz/rockbox/test_codec_stats.pdf
(armv5 build even though my phone is armv6).
Best
2010/10/12 Dave Hooper d...@beermex.com:
Would anybody be so kind as to test this patch please:
FS#11666
http://www.rockbox.org/tracker/task/11666
Confirmed continued working on ipod video target build. Not confirmed sim
build (yet, doing that now). Not confirmed that it fixes the PIC
What happened to add %[z_ptr] line?
Oh, I see it. It was changed in rockbox/trunk in r25993 but not in the
patch I use.
regards,
Slawomir Testowy
2010/10/12 Dave Hooper d...@beermex.com:
Yep. Assuming it works would you be able to recreate that patch for mainline
trunk to include the changes in Rockbox svn? :)
I confirm the patch works :)
I can create quite easily the patch for mailine based on
Am Mo, 11.10.2010, 14:37 schrieb Dave Hooper:
I didn't get much chance to investigate (I believe I
have some working changes to remove the macro-hell which gcc should now
have
more luck with, but my arm-elf-objdump seems incompatible with eabi so
unable to easily check the disassembly)
Sigh, right. Can't believe I didn't spot that! Should be fixing tonight all
being well..
Would anybody be so kind as to test this patch please:
FS#11666
http://www.rockbox.org/tracker/task/11666
Confirmed continued working on ipod video target build. Not confirmed sim
build (yet, doing that now). Not confirmed that it fixes the PIC problems, as
don't currently have a way of
I hope to take a look today
On 17.09.2010 09:32, Slawomir Testowy wrote:
Hi all!
For some time I have been using tremor with fastermdct patch found on
http://www.rockbox.org/wiki/FasterMDCT. This patch gives huge speedup on
i686/x86_64 machines and smaller, but still significant, speedup on
On 17.09.2010 09:32, Slawomir Testowy wrote:
Hi all!
For some time I have been using tremor with fastermdct patch found on
http://www.rockbox.org/wiki/FasterMDCT. This patch gives huge speedup on
i686/x86_64 machines and smaller, but still significant, speedup on ARM.
Everything works great
2010/9/17 Rafaël Carré rafael.ca...@gmail.com:
On Fri, 17 Sep 2010 16:26:31 +0200
Slawomir Testowy slawomir.test...@gmail.com wrote:
2010/9/17 Rafaël Carré rafael.ca...@gmail.com:
On Fri, 17 Sep 2010 14:01:48 +0200
Slawomir Testowy slawomir.test...@gmail.com wrote:
Hi,
thanks for
2010/9/18 Nils Wallménius nils.wallmen...@gmail.com:
gcc lets you specify the pic register with -mpic-register= so it would
be a qucick test to try with r11 or something.
Nils
Unfortunately, this doesn't work:
configure:3276: checking whether the C compiler works
configure:3298:
On Mon, 20 Sep 2010 11:00:01 +0200
Slawomir Testowy slawomir.test...@gmail.com wrote:
(gdb) bt
#0 0x0003b3a0 in pass (z_arg=value optimized out,
STEP_arg=value optimized out, n_arg=value optimized out)
at fft-ffmpeg.c:243
0x3b3a0 ...
(gdb) disass $pc-32 $pc+32
A syntax error
2010/9/20 Rafaël Carré rafael.ca...@gmail.com:
Try disass $pc-32,$pc+32
Thanks!
... is not shown here, can you run the commands on the same crash?
--
Rafaël Carré
I'm sorry. My fault.
Program received signal SIGSEGV, Segmentation fault.
0x0003b3a0 in pass (z_arg=value optimized out,
That looks weird to me! R10 still holds one side of the previous butterfly
calculation but looks like gcc is assuming it still holds some address (I
don't know how pic is supposed to work however). So it's either a gcc bug,
or we need to explicitly put t10 in clobbers in asm (even though gcc
Meant to type r10 not t10
That looks weird to me! R10 still holds one side of the previous butterfly
calculation but looks like gcc is assuming it still holds some address (I
don't know how pic is supposed to work however). So it's either a gcc bug,
or we need to explicitly put t10 in clobbers
I suppose gcc doesn't actually know whether I want to use the value of pic
or not, when I explicitly say register(r10). So I think it's assuming I do
want the value of pic and that 'i know what I'm doing'. If I unrolled those
macros somewhat so that I don't need to keep registers live across
2010/9/20 Rafaël Carré rafael.ca...@gmail.com:
On Mon, 20 Sep 2010 11:29:59 +0100
Dave Hooper d...@beermex.com wrote:
I suppose gcc doesn't actually know whether I want to use the value
of pic or not, when I explicitly say register(r10). So I think it's
assuming I do want the value of pic
Yep, same problem as far as I can tell. We've just moved the problem from
uses-of-r10 to uses-of-r11. The asm code doesn't detect or avoid using the
pic register, so if you change the pic register something else will happen.
The fix requires telling gcc I want to use r10 here, so if you are using
(You can see from this 'new' segfault that gcc clearly hasn't realised we've
trashed r11 during the immediately-preceding calculations - the add/sub/stm
stuff)
Yep, same problem as far as I can tell. We've just moved the problem from
uses-of-r10 to uses-of-r11. The asm code doesn't detect or
On 20.09.2010 11:02, Slawomir Testowy wrote:
2010/9/18 Nils Wallméniusnils.wallmen...@gmail.com:
gcc lets you specify the pic register with -mpic-register= so it would
be a qucick test to try with r11 or something.
Nils
Unfortunately, this doesn't work:
configure:3276: checking whether
More like bad (or at least) ambiguous code that I'm not surprised gcc
treated differently to how the author expected/intended (see all the
subsequent replies on the thread)
On 20.09.2010 11:02, Slawomir Testowy wrote:
2010/9/18 Nils Wallméniusnils.wallmen...@gmail.com:
gcc lets you specify the
On 20.09.2010 19:27, Dave Hooper wrote:
Oh sorry, you mean changing the register used for pic. I got mixed up.
I personally don't know if that's expected to work for r11 or not,
although that's not really the actual problem (or solution) here
Isn't it the only way to determine the pic
gcc lets you specify the pic register with -mpic-register= so it would
be a qucick test to try with r11 or something.
Nils
Hi all!
For some time I have been using tremor with fastermdct patch found on
http://www.rockbox.org/wiki/FasterMDCT. This patch gives huge speedup on
i686/x86_64 machines and smaller, but still significant, speedup on ARM.
Everything works great until I compile tremor on ARM with -fPIC flag (I
That's very interesting indeed. I too observed a segfault when trying to use
the fastermdct patch on top of a libtremor used by an MPD server but
couldn't pinpoint the reason. That's one of the reasons this patch hasn't
hit upstream Tremor.
I know the code well but that line seems very mysterious
If I remember correctly, gcc was not clever enough to maintain the ordering
constraints needed by the ldmia/stmia calls, so I needed to assign the
registers manually to prevent generating bad code (by the way x86 shouldn't
use this file at all so compilation issues wouldn't show up on your build).
On Fri, 17 Sep 2010 12:08:38 +0100
Dave Hooper d...@beermex.com wrote:
If I remember correctly, gcc was not clever enough to maintain the
ordering constraints needed by the ldmia/stmia calls, so I needed to
assign the registers manually to prevent generating bad code
Ah right, GCC can not be
On Fri, 17 Sep 2010 14:01:48 +0200
Slawomir Testowy slawomir.test...@gmail.com wrote:
Hi,
thanks for quick response.
2010/9/17 Rafaël Carré rafael.ca...@gmail.com:
I think the OP should post .S output of gcc and also give
us compiler version and options being used
--
Rafaël Carré
On Fri, 17 Sep 2010 16:26:31 +0200
Slawomir Testowy slawomir.test...@gmail.com wrote:
2010/9/17 Rafaël Carré rafael.ca...@gmail.com:
On Fri, 17 Sep 2010 14:01:48 +0200
Slawomir Testowy slawomir.test...@gmail.com wrote:
Hi,
thanks for quick response.
2010/9/17 Rafaël Carré
I think it's hard to tell - let's see what happens without optimisations
(-O0) since the code won't always align easily to the source otherwise.
On Fri, 17 Sep 2010 16:26:31 +0200
Slawomir Testowy slawomir.test...@gmail.com wrote:
2010/9/17 Rafaël Carré rafael.ca...@gmail.com:
On Fri, 17 Sep
31 matches
Mail list logo
