Rockbox

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.

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

> 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?

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.

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.

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.

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

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