How long before we see some decent native ARM software.

[RedSlug]

Coming from a Zaurus where there was a thriving community producing a good choice of software (if not always 100% polished), I'm quite disapointed in the choice of software for my Clie. A lot of it is M68K and has not been updated since forever.

I'd love to see more emulators ( Bochs, Mame, UAE etc ). I'd Really like to see Opera (already working on ARM on the Zaurus). A nice fast VNC would be great.

Views?

[aaronchow]

You can't. Palm won't let you to have a 100% ARM native program yet, but they're providing ARM-let as a stepping stone right now.

[RedSlug]

Thats so very short-sighted. If Palm is not careful, then PalmOS if going to die, due to lack of any power-apps which are available on the PPC. PalmOS needs ports of solid software to appear to be a viable alternative. "KISS" no longer applies now that PDAs are more than just diary & telephone book.

[aaronchow]

No, Palm is doing the right thing. Remember, there will be no backward-compatible mode once the program is written completely native for ARM core. And this will be a good news if and only if everyone upgrades their Palm unit into the newest one and every developers completely re-written their software to take advantage of it.

But, as always, you don't expect everyone to do jump into the PalmOS 5 ship right away, so it is safer for Palm to have a stepping stone so that we (as a user) will continue to have varieties of program with some functionalities from the help of ARM-lets.

PS ~ This is exactly what Microsoft did. They released Windows95 as a stepping stone of WindowsNT, so 16-bit programs can still be run under Windows95 compatability mode.

[aaronchow]

Originally posted by RedSlug
Thats so very short-sighted. If Palm is not careful, then PalmOS if going to die, due to lack of any power-apps which are available on the PPC. PalmOS needs ports of solid software to appear to be a viable alternative. "KISS" no longer applies now that PDAs are more than just diary & telephone book.

Also, if you really understands what PalmOS is, you will notice that PalmOS will never try to replace a desktop PC. PalmOS's role is to act like your PC's companion.

More over, PalmOS is only an operating system, and it's not them that are responsible to develop powerful software. Their primary job is to help developers develop apps for PalmOS, and I have to say that they are doing an excellent job out of it.

Also, I'm also a Zaurus owner, and the beauty of the Zaurus people is to share their own programs for others to use and modify instead of asking other people to do it for you. Although I'm pretty much still a learner in programming, I'm ashame to know such Zaurus user exsists.

[TechnoCat]

Originally posted by RedSlug
Thats so very short-sighted. If Palm is not careful, then PalmOS if going to die, due to lack of any power-apps which are available on the PPC. PalmOS needs ports of solid software to appear to be a viable alternative. "KISS" no longer applies now that PDAs are more than just diary & telephone book. I don't see that. Palm software is compatible across all Palms. WinCE (PPC) software isn't; you need it for your particular processor, but also previous versions (called H/PC for "handheld PC") won't run on a PPC and vice-versa.

Palm isn't making those mistakes. Your typical well-writtenPalm program calls MemCopy() instead of memcpy(), for example; the former is a Palm API, the latter is a standard C function, but the former is processor-optimized on whatever platform it's running on.

So the bottom line is this: the vast majority of well-written Palm programs are already ARM optimized, simply by running them on the newer platform.

[RedSlug]

aaronchow, I disagree with you. Microsoft did not stop people from writing 32Bit programs.

Having a stepping stone is dual edged sword. It's great that all your old applications still run. But it's bad that developers will develop for the "Lowest common denominator". There is little enough reason to create ARM only programs, without the added (unneccesary) complication that ARM only programs are forbidden by Palm. ARM native applications are neccesary to compete. Even if it's just for the games!! :-)

[RedSlug]

Ohterwise, why bother having an ARM CPU at all. Why not just use the latest and greatest Dragonball...

[jaydisc]

Native ARM will be available in OS 6, which I believe is within a year. Should palm have just dumped their entire software library and jumped right into that? You wanna hear people complain about short-sightedness....

[TechnoCat]

Originally posted by RedSlug
Ohterwise, why bother having an ARM CPU at all. Why not just use the latest and greatest Dragonball...
Because the ARM runs previous Palm programs much faster.

I already answered your question in my post above, which explains to you the technical reason why "native" is meaningless in this context and Palm programs will simply speed up on OS5/ARM... but I guess it was a bit too technical for you. So here's some data...

http://www.kittycentral.net/palms.html

These are benchmarks I personally did across a variety of Palm systems. Of them, Speedy is a normal (i.e. well-written) app, Benchmark is written in Quartus Forth and therefore probably ignores all the normal Palm API rules (because it wasn't written in C, the Palm API language), and the yCPUBench ones come in 68K and ARM forms specifically to take the API out of it.

So the only benchmark relevant to your question of how well normal apps run on OS5/ARM is Speedy, which is why it's listed first on my site. (I didn't do that for you; it was just the rigorous thing to do when I built that page a while ago.)

Note that the Zire 71 is more than six times faster than the SJ33 according to Speedy, even though (1) It's only 2.2 times faster by clock and (2) it's not OS5/ARM optimized?

In general, that's what you'll see. Most programs will simply be much faster, as long as the developers read the Palm API documentation and used Palm API calls rather than C library calls, simply because the OS provides a glue layer.

[TechnoCat]

Originally posted by jaydisc
Native ARM will be available in OS 6, which I believe is within a year.Native ARM is already available. Just wrap the ARM code in a "subroutine" that you call with [b]PceNativeCall[b].

The downside to using PceNativeCall (or ARM native code in general) is that ARM systems are a very small fraction of the Palm installed base and you can't run that code on previous processors/OS versions. So you would either need to forgo the larger market or write the same functionality twice, conditionally branching. (Unlike WinCE/PPC though, it can be in the same executable.) And remember it won't buy you much if the program originally used the Palm APIs whenever possible anyhow.

This is decently documented on page 1239 (of 2416 pages, I kid you not; you really don't want to print this document out!) of the Palm OS Programmer's API Reference .

[RedSlug]

Originally posted by TechnoCat

Because the ARM runs previous Palm programs much faster.

I already answered your question in my post above, which explains to you the technical reason why "native" is meaningless in this context and Palm programs will simply speed up on OS5/ARM... but I guess it was a bit too technical for you. So here's some data...

http://www.kittycentral.net/palms.html

Believe me I understood perfectly your post. I've been coding for about 15 years. (But not for handhelds)

What you were saying is that if you call PalmOS's libraries (I can only assume written in ARM code) you would be getting the full benefit.

There are problems with this. It assumes that..

1.. The PalmOS libraries are written in the most optimised manner possible.
2.. There is a PalmOS library call available for everything you could possibly hope to optimise.

Yes I can see that calling the correct Memory Copy routine would run the ARM optimised version and give you better performance than a DragonBall equivilant. That goes without saying.
But what if I want to write my own Memory Copy routine that does something slightly different, or better. What if I want to write an ARM optimised Mandelbrot program?

It's important to understand I do not disagree with having an emulator to cope with the back catalogue!! But I would also like to see some real ARM versions of software which are sluggish on my Clie.

e.g. Netfront - I have a mobile device with a 75mhz ARM CPU with a browser wchich seems to run about 5 times as fast as Netfront. Possibly this is to do with bad programming, but I cannot belive that an ARM native version would not be any quicker.

It's great that calls like PceNativeCall exist and applications like XCade are starting to appear. I'd like to see more.

An emulator to cope with the back catalogue is great.
An emulator that uses ARM optimised libraries to speed up programs is even better.

I would argue that, for those with ARM CPU Palms, some ARM native applications can run substantially faster. And that these applications should be encouraged as not to hold back progress.

[TechnoCat]

Originally posted by RedSlug
What you were saying is that if you call PalmOS's libraries (I can only assume written in ARM code) you would be getting the full benefit.

There are problems with this. It assumes that..

1.. The PalmOS libraries are written in the most optimised manner possible.Generally I would expect this to be the case. MemCopy, for example, would probably drop-down to a processor-specific version of memcpy() inside the OS/processor. The term for the call is "Glue Layer", and it does indeed ensure that that call is optimized.
2.. There is a PalmOS library call available for everything you could possibly hope to optimise.No, that's why PceNativeCall exists. Certainly tight processor loops, some esoteric DSP functions, or heavy math will be better off optimized for each processor... if for no other reason than to avoid function call overhead. But such optimizations are quite rare.

Yes I can see that calling the correct Memory Copy routine would run the ARM optimised version and give you better performance than a DragonBall equivilant. That goes without saying.
But what if I want to write my own Memory Copy routine that does something slightly different, or better. What if I want to write an ARM optimised Mandelbrot program?That is why you get PceNativeCall. It's important to understand I do not disagree with having an emulator to cope with the back catalogue!! But I would also like to see some real ARM versions of software which are sluggish on my Clie.

e.g. Netfront - I have a mobile device with a 75mhz ARM CPU with a browser wchich seems to run about 5 times as fast as Netfront. Even if they do it, how will you know? The web ran incredibly slowly on my 90MHz Pentium years back. (I still have the pup too!)
An emulator that uses ARM optimised libraries to speed up programs is even better. and that's what Palm gave you.

I would argue that, for those with ARM CPU Palms, some ARM native applications can run substantially faster. And that these applications should be encouraged as not to hold back progress.I agree that some programs would run faster with significant portions tossed into PceNativeCall blocks, but you weren't encouraging them, you were bashing Palm for allegedly not supporting native ARM running, when in fact Palm covered vast amounts of functionality with a transparent glue layer solving the vast quantity of potential performance problem areas. In general, the problems you see are likely due to the programmers using standard C libraries rather than the Palm API, rather than due to any deficiencies in Palm's ARM support. The only way Palm could have better dealt with it would have been to actually provide a proper development environment that did the compiling of memcpy() to MemCopy() (for example) themselves. But then we'd be moaning about how lousy a dev environment they built and how they should simply have supported other ones, which is what they did.

[RedSlug]

No, not bashing Palm, It was originally a call for proper ARM applications. Someone ellse suggested this was not possible, which I said was short sighted. Luckily this proved to be false - thanks for clearing that up.

And as we both agree that some application would benefit from more ARMlets its good to see we are all talking the same language - :)

Looking forward to Quake.......