[EMAIL PROTECTED] wrote:
> Just so everyone is aware of this, we have encountered plenty of compatibility
> problems with apps using A4 to point to their globals.
Then those were broken apps! A correctly written program must manage A4 in a
way that is absolutely transparent to PalmOS and to other program entities. The
PalmOS calling convention ascribes no special meaning to A4 and treats it like
every other address register aside from A0 and A1, i.e., if you call a function
A4 on return will be the same as it was on entry, but on entry to your
externally accessible functions, such as form event handler callbacks and all
that, its value is undefined and you must preserve/restore it on return. This
is explained in great detail in the Programmer's Guide to PalmOS gcc, which
tells programmers who to write correct programs that comply with these external
ABI requirements and do all kinds of cool magic internally.
> (In fact, we put a hack into PalmOS 3.5 so that these apps will continue to
> work... but its not going to stay there forever!!)
Well, it's definitely nice that you are putting workarounds for broken apps in
your ROMs, but please be assured that neither I nor any other developers at our
company are relying on it. I perfectly understand the PalmOS calling convention
and that PalmOS is absolutely under no obligation to maintain A4 in callbacks,
all code that I write makes no such assumptions, and this is what I teach to
the people to whom I promote my development tool suite (other developers at our
company and the PalmOS developer community at large).
> The last time I checked, the developer had to manually add calls to save, set
> up, & restore the a4 register for use of globals in callback routines (like
> form event handlers, etc).
Yes, this is correct, and my version includes macros that make this very easy
and *extensive* documentation on how, and much more importantly why, this must
be done.
> As long as this is still the case [...]
I have no plans to change this because I believe that the current approach is
the right one.
> [...] then some developers will probably continue to forget, and their apps
> will break [...]
Of course, but it's their problem!
> [...] on future versions of PalmOS because the OS does NOT preserve the A4
> register.
Why future? PalmOS never maintained A5 and neither I nor any other responsible
programmer ever expected it to.
> Plus, if you just point to your globals with A5 instead, then its
> easier and more efficient because you don't HAVE to go to any extra work to
> save/set up/restore it.
Are you talking about reverse-engineering SysAppStartup() and doing what it
does, i.e., setting up your own A5 world complete with that magical 4-byte
system pointer at 0(A5)? Well, when I looked at the source I saw that it would
probably be possible, but obviously this is doing what apps are not supposed to
do and can break in any future version, etc. I'm particularly concerned about
that magical system pointer at 0(A5). Apps aren't even supposed to know about
its existence, are they?
OTOH, A4-based data access is absolutely transparent and invisible to PalmOS
(assuming a responsible programmer who has read and understood my full manual,
of course), and it is absolutely impossible for future PalmOS versions to break
it no matter how hard they try.
Besides, what about program entities other than applications? GLib application-
level shared libraries, for example? I would imagine that if a library messed
with A5 on entry things would go up in smoke very quickly, as soon as someone
calls any memory manager or data manager functions that use the magical system
pointer at 0(A5). Again, A4 solves the problem in an ABI-transparent way that
is by definition unbreakable because it's transparent and externally strictly
conforms to the existing ABI.
> Another piece of PalmOS history:
> The reason that every launch code doesn't support globals is because we needed
> to keep these launchcodes FAST. Some are broadcast to every application
> installed on the device... as it is the performace can be "poor", but it would
> be a lot worse if every one of those apps set up and disposed of its globals.
I understand this of course, and my mechanism doesn't *always* manufacture the
data segment on every launch. Instead, I let the user provide a function that
makes the decision whether to do this or not based on the launch code and
flags, so that you have globals when you need them and pay no performance
penalty when you don't.
--
Michael Sokolov 2695 VILLA CREEK DR STE 240
Software Engineer DALLAS TX 75234-7329 USA
JP Systems, Inc. Phone: +1-972-484-5432 x247
or +1-888-665-2460 x247
E-mail: [EMAIL PROTECTED] Fax: +1-972-484-4154
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
