[haiku-development] Re: FatELF on Haiku?

  • From: Konstantinos Margaritis <markos@xxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sat, 7 Nov 2009 13:16:22 +0200

On Nov 7, 2009, at 12:58 PM, PulkoMandy wrote:
I don't want apps be 5x bigger for code i'll never use. Particularly
on a small target like ARM or 68k where disk space is usually small.

You seem to miss the point, allow me to explain my argument. Since you referred to ARM (I can't speak for 68k), ARM cpus suffer much more fragmentation than all other cpu lines (like x86 or even PowerPC). As it is, ARM has Thumb, Thumb2, NEON, VFP, iwMMXt, ARM5, ARM7, ARM9, ARM11, ARM9+media array (in the case of zms-05 by Zii Labs), etc. What might provide top performance on one CPU model might be totally unsupported by others, or if supported it might make the cpu totally sluggish. For one thing, ARMv5 code underperforms on later cpu models like ARM9 or ARM11 -the exact technical details evade me- and it would be nice to have well-performing versions for all chips. If not, we'd be a) need several haiku versions/distros for each ARM family, b) support just the base ARM code, but missing all the features like NEON eg. or c) provide an ultra optimised version for one family -eg. Cortex-A8- but all other ARM users would be complaining and missing out all the fun.

A FatELF-based solution sure it has its problems, but esp. in ARM's case it just makes sense. As for disk space, well that's easily solved. A simple tool could be run to "strip" useless/unneeded versions from the binaries. The problem is distribution/maintainance of the whole set of binaries, not the disk space in the end device. In the one case you have multiple versions of the file shipped -btw, how do you expect the user will know the right version for his netbook? In the second case, you have one binary, one "distro" and a tool to strip the binaries. I don't know about you, but I know which option I would choose.

Compilation might need a few extra steps -compiling for all/most possible options and then linking these into one FatELF binary, but I'm positive it's worth it.

Regards

Konstantinos

Other related posts: