pdaXrom RC5 kernel on Cacko?

[nyar]

Hi,

Played with pdaXrom RC5 again; it is a nice rom, but I'm still finding myself liking Cacko much, much more; far more suited for PDA use, and it has a much more polished, complete feel to it, making the overall user experience is much nicer.  pdaXrom is rather promising, though!

One thing that I'd love to do on Cacko that I can't, is play Quake (and at the same speed that it does on pdaXrom RC5 - it's fast!).

From my understanding, what makes RC5 much faster is the new kernel (?) with vector floating support.

Is this the main thing that makes Quake run so fast on RC5?  If so, is it possible to compile a kernel with this support for Cacko, and will applications which utilise such calculations magically then run faster or do they need to be compiled in special ways to take advantage of this?

(Where can one get the kernel source for RC5, anyway?)

Sorry; I'm still a complete Z newbie, trying to get my head around things.  Plan to get into some dev soon when I finish a couple of larger business projects.

[nyar]

Any clues, anybody?

If this is stupid for some various reason, please let me know.

[Kaze]

i suppose it would require recompilation of almost each & every avalaible .IPKG

[nyar]

Why, though?  It's not like a different linux kernel changes binary or library compatibility.

I'd like to try this anyway - where the heck does one get kernel sources (for pdaXrom), anyway?

[kopsis]

The fast floating point in both OZ and pdaXrom comes not from the kernel, but from gcc 3.4 and its associated run time libraries. To get what you want on Cacko, you'd have to replace the C RTL with a version built with gcc 3.4 with the right settings. But doing that breaks binary compatibility with all other libraries and applications so they would all have to be rebuilt with the newer compiler as well. All in all, a pretty steep price just to play Quake.

[tg]

The fast floating point in both OZ and pdaXrom comes not from the kernel, but from gcc 3.4 and its associated run time libraries. To get what you want on Cacko, you'd have to replace the C RTL with a version built with gcc 3.4 with the right settings. But doing that breaks binary compatibility with all other libraries and applications so they would all have to be rebuilt with the newer compiler as well. All in all, a pretty steep price just to play Quake.

I totally agree with kopsis that it does not make sense to recompile everything for Cacko. If you want speed you are better off joining the OZ effort and porting the apps you like to run there. OZ is the most promising project anyway - even if Z is discontinued (God forbid) that work will not be wasted as OZ can run on other platform as well (as opposed to pdaXRom which seems to only target Zaurus as platform where it will run - someone please correct me if I'm wrong here but that is my current impression).

[nyar]

Thanks for clearing it up; certainly makes a lot more sense now.

I'd join the OZ effort if I had time; not a whole heap at the moment.

[iamasmith]

Just tagging this on my 'todo whenever' list but I've got the source for 2.95.3 and 3.4.2 versions of GCC and the architecture dependent stuff actually looks relatively similiar between the source trees.

I'm thinking it might actually be possible to backport armv5 VFP into gcc 2.95.3 and retain compatibility with the Sharp versions of the C runtime. All existing apps should still run with softfloat (as far as I know at the moment).

If anyone knows for definite that this is going to be a dead end then let me know... it may be an interesting diversion but I have tons of other stuff that I could do.

- Andy