John Marshall <[EMAIL PROTECTED]> wrote:
> This isn't an oversight.
No, I really think whoever wrote that (I guess Kresten Krab Thorup or Ian
Goldberg) simply forgot about sysAppLaunchFlagSubCall, given how easy it is to
handle it correctly.
> You wouldn't want the startup code to reinitialise
> your globals for you, would you?
Of course not.
> To be sure, there should be separate tests
> for loading A4 and calling GccRelocateData().
Obviously.
> I presume you've done this.
Of course I have.
> Actually, this problem wouldn't arise with this new version of prc-tools
> at all!
Which is exactly what I mean by dodging the issue.
> To suggest that
> using the register the OS gives us is an "obtuse dodge" is disingenuous.
It is obtuse. Following Palm's party line blindly without realizing that you
can do much better is what I mean by obtuse. To me following Palm's party line
that globals are to be accessed via A5 isn't much different from following
Hitler's party line that Jews are to be killed. Neither has any reason behind
it other than the leader saying so. Count how many times people on this forum
have complained about not having globals on a find or a beam receive. About
PalmOS deciding for you when you should have globals and when you shouldn't,
without giving them a choice. A4-based data access, on the other hand, allows
you to create your own globals whenever you want to, without being at PalmOS's
mercy. prc-tools-0.5.0, which first introduced A4-based data, used it for
GLibs, for which it is crucial. My prc-tools-0.6.0 evolved enormously in this
direction. You can use the manufactured data facility, which is the name I
invented for these not-from-PalmOS globals, anywhere you want. In particular,
there is a ready-to-use facility for applications to decide for themselves for
which launch codes and flags to have globals. All the work is done for you, you
just provide a function that is called before PilotMain(), takes the same
arguments as PilotMain(), and returns to 1 make globals or 0 to run without
them. Advanced users can do much more, for example, SysLibs with data segments
and multiple code segments.
> Rather, the obtuseness is in having apps access their globals via A4,
> and *requiring* the developer to manage access explicitly.
It is an option, not a requirement, although given how many exciting gcc-only
features (like GLibs) work well or at all only with A4-based data access, it is
indeed the default. If you want to revert to A5-based data access, forego all
gcc-only features, and go back to obtuse CodeWarrior-like programming, just
give gcc the right option on the command line. -mvolatile-gp for gcc-2.7.2.2
and -mno-own-gp for gcc-2.95.2.
> The prc-tools developers invented this use of A4 as a hack to get around
> the fact that the GNU linker couldn't handle the way Palm OS arranges
> globals and A5.
Wrong! prc-tools-0.4.x accessed globals via A5 and only via A5. A4-based data
access was invented in prc-tools-0.5.0 for GLibs. (It is true, though, that
with gcc-2.7.2.2 A5-based data access is less efficient than A4-based, which is
one of the reasons why in prc-tools-0.5.0 they used A4 for everything, not just
GLibs. This is why I recommend Mike to use the callback macros instead of
-mvolatile-gp. gcc-2.95.2 with -mno-own-gp is absolutely equivalent to CW,
however.)
--
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
