Re: Palm OS 5.0 codegen
Brought to you by:
jmarshall
From: John M. <jo...@fa...> - 2002-03-19 16:50:52
|
On Tue, Mar 19, 2002 at 11:02:42AM -0500, Robert Baruch wrote: > Pet...@ot... wrote: >> From what I understand, the ARM base 68k emulator has very different >> performance characteristics than a real 68000 chip. Has there been any >> thought to generating code specifically targeted at the OS5 emulator? Not by me. :-) >> Specifically, I'm thinking that the emulator probably has a fairly large >> instruction dispatch penalty. Where the 68000 chip often rewards a >> compiler for using two small instructions (e.g. addq) I suspect that the >> emulator will penalize this. Interesting. Another problem is that operating on 16 bit data is probably going to be *slower* than operating on 32 bit data. I think that one could probably be handled well enough with current GCC m68k tuning options and careful coding, but your one might be harder. > That's true, but it would be moot if 5.0 can run ARM natively. In that case > you'd use an ARM compiler rather than a 68k compiler. OS 5.0 will run on ARM hardware, and (most of) the OS will be native ARM code. But pretty much *no* applications will be completely written with ARM compilers. Subroutines with tight loops certainly, but system API calls from ARM code on OS 5.0 are painful enough that noone will want to spend much time doing them. Except Aaron, of course ;-). Some details at http://falch.net/Articles/?art=311 and palm-dev-forum etc. We'll start seeing native ARM applications on Palm OS 6 or whatever they call it, whenever that might be. > I suppose if you really wanted to, you could add another 68k mode and > fix up the 68k files for that mode. It's an interesting question. I can't really think how to test it at the moment. :-) But I'm hopeful that with native ARM subroutines available for compute-bound subroutines and general application processing probably dominated by OS UI routines (which will also be native ARM) and sleeping, this sort of tuning will only give small improvements. At least, that's my excuse off the top of my head for acting as if I'm not interested myself and making you look into it, Peter. :-) > I'm not really sure, since I'm > just starting out with hacking gcc. BTW in my experience the way to get to grips with m68k.md is to read the Machine Descriptions chapter of the GCC manual several times while playing with adding something to m68k.md. And think of the time spent as an investment :-). John |