> Short (16-bit) math won't generate calls to these functions; it'll
generate
> 68000 instructions that do the math directly. The compiler generates
calls
> to a long math function when it needs (or thinks it needs) long math
to do
> index calculations. For example, code like this will produce a call to
> __lmul__:
>
> typedef struct {Char first[5]; Char last[5];} NameType;
> NameType name, *nameP;
> UInt16 index;
> name = nameP[index];
>
> If you declared nameP as:
>
> NameType nameP[10];
>
> the compiler would know that short math was adequate. Or you could do
the
> indexing manually, ensuring that the appropriate types are being used
at all
> stages of the calculation. With some understanding of how the compiler
> works, you can prevent the compiler from generating calls to the long
math
> functions, making your code run faster, and eliminating the
constraints on
> how the code is organized that result from such calls.
Interesting -- I'd not realized the compiler would generate a long math
call for indexing operations. I'll check with our compiler engineer
this weekend; given that no data objects on Palm OS will be larger than
64K, it may be possible to avoid that overhead. You actually can have
>64K objects, but only using FtrPtrNew, so it would need to be a
"switchable" option.
> Another function that's in the startup library is __wswtch__. The
compiler
> generates calls to this function when you use a switch statement with
a 16
> bit argument, at least under some circumstances. I don't know the
details.
> You can avoid such calls by using if statements rather than switch
> statements - not pretty, but it works.
__wswtch__ is used when we generate a switch that uses a lookup table.
The compiler has different metrics for this, depending on the "generate
code for speed/size" option. This call is used in deference to putting
the lookup code inline to reduce code size.
> You can call functions in the startup library from other segments. I'm
not
> sure how this works, but I know I've done it successfully. It probably
uses
> a jump table at the beginning of each segment.
Actually, the jump table is in the data segment. But, you couldn't
reach the other segments if you didn't go through the jump table to
start, so this shouldn't be an issue.
> If you're using the Small
> code model, which I recommend, all calls in the first segment must be
within
> 32K of the function being called. Since these functions are at the
beginning
> of the startup library, which is at the beginning of the segment, and
these
> functions are tiny, you have about 32K of space in which to put such
code.
> If my theory about how intersegment calls to startup functions is
correct,
> the same 32K limit applies to other segments as well.
The library will actually be placed whereever you specify it in the
segment list. It is important to make sure it is in segment 1.
However, you could move it to be in the middle of the segment if it
helped.
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
