Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Patches
  • Category Infrastructure → Build environment
  • Assigned To No-one
  • Operating System Generic RaaA
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by thomasjfox - 2011-12-01
Last edited by kugel. - 2012-02-03

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

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

   pcm-mixer-enable-asm-optimiza... (1.7 KiB)
Closed by  kugel.
2012-02-03 20:59
Reason for closing:  Out of Date
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

firmware has now the asm folder which selects optimized asm regardless of native/hosted.

MikeS commented on 2011-12-01 21:36

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.

kugel. commented on 2011-12-02 06:49

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).

thomasjfox commented on 2011-12-03 09:55
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?

MikeS commented on 2011-12-03 16:53

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.

MikeS commented on 2011-12-03 16:57

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.

kugel. commented on 2011-12-06 11:44

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.

thomasjfox commented on 2011-12-09 19:51

Hmm, "firmware/target/asm" is easy to confuse with "firmware/target/arm".

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

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing