Rockbox

Tasklist

FS#12421 - RaaA: Enable assembler optimized PCM mixer routines

Attached to Project: Rockbox
Opened by Thomas Jarosch (thomasjfox) - Thursday, 01 December 2011, 21:06 GMT
Last edited by Thomas Martitz (kugel.) - Friday, 03 February 2012, 20:59 GMT
Task Type Patches
Category Build environment
Status Closed
Assigned To No-one
Operating System Generic RaaA
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Hi,

attached patch enables assembler optimized PCM mixer routines for RaaA.

This fixes r30099.

@kugel: Is it ok to add "target/arm" to the include path on android?

Cheers,
Thomas
This task depends upon

Closed by  Thomas Martitz (kugel.)
Friday, 03 February 2012, 20:59 GMT
Reason for closing:  Out of Date
Additional comments about closing:  firmware has now the asm folder which selects optimized asm regardless of native/hosted.
Comment by Michael Sevakis (MikeS) - Thursday, 01 December 2011, 21:36 GMT
I think kugel had another idea but I don't remember what it was., possibly a modification to the directory heirarchy for this sort of thing where optimized code is built for both native and app.
Comment by Thomas Martitz (kugel.) - Friday, 02 December 2011, 06:49 GMT
Yea, I think a directory outside the target tree for CPU but not dap/board specifics would be better (or even hard-including like #include "../arm/foo"). Adding arm to the include path perhas unnecessarily pulls in native stuff (or stuff for which you need to be in system/svc mode).
Comment by Thomas Jarosch (thomasjfox) - Saturday, 03 December 2011, 09:55 GMT
> Adding arm to the include path perhas unnecessarily pulls in native stuff

That was my feeling, too.

We could either move the files directly next to "firmware/pcm_mixer.c" or
stuff them into a "firmware/target/pcm_mixer/" directory.

I'd rather avoid to hardcode the path like "../arm/foo".

Any preference?
Comment by Michael Sevakis (MikeS) - Saturday, 03 December 2011, 16:53 GMT
I think I did have them right in the firmware directory at first and that had objections raised so in /target/foo they went.

How about firmware/target/(one of:arm,coldfire,sh,mips)/common? Or firmware/arch/(one of:arm,coldfire,sh,mips)/<filename>?

There is DSP code that could also benefit from an app-level tree.
Comment by Michael Sevakis (MikeS) - Saturday, 03 December 2011, 16:57 GMT
I'm thinking "arch" could be "arch/<particular SoC>" while target could deal with particular makes and models. "arch" could exist in apps as well for architecture app code.

ETA: how to make a subdir for PortalPlayer would sort of resolve itself.
Comment by Thomas Martitz (kugel.) - Tuesday, 06 December 2011, 11:44 GMT
Perhaps not an "arch" dir, but isa (instruction set architecture) or asm for stuff that really only depends on the asm language, not native or hosted or what actual target we build for. I would like such a solution for the thread support files (android uses a copy of the ARM thread support execpt it doesnt do the wfi instruction) as well.

Also require a C equivalent for each asm implementation in that directory.
Comment by Thomas Jarosch (thomasjfox) - Friday, 09 December 2011, 19:51 GMT
Hmm, "firmware/target/asm" is easy to confuse with "firmware/target/arm".

How about "firmware/target/generic_asm" or "firmware/target/optimized"?

Loading...