Hi !

Dimanche 25 F�vrier 2001 04:24, Aaron Ardiri a �crit:

>   i am on vacation.. but.. what the hell :)

Thanks for taking time to answer while on vacation !

> > 1) I would like to know which registers are assumed to be modified
> > between function calls and which in fact did not need to be saved.
> > By looking at the generated code, it seems than D0, D1 and D2 does not
> > need to be saved if we use them in some inline ASM code.
>
>   dont make any assumptions :) it probably doesn't hurt to push em
>   all, and pop em all when you are done.. :) the optimizer may do some
>   fancy stuff :)

I agree with you, pushing 3 more registers on stack doesnt hurt.
But it's just for my "information", I would like to know what are the rules 
and if they are specific to each version of m68k tools.

> > 2) Is there any way to ask the compiler to use registers for passing
> > arguments instead of using the stack ?
>
>   sure.. write the call yourself, put in some inline assembler,
>   pass pointers into registers, and do a jsr :) chances are tho,
>   your routine that you will call will probably need to be written in
>   ASM too - so your assumptions are set.

In fact, what I want the compiler to do, is to use registers for passing 
arguments on ALL the functions called, not only the ASM ones.
This makes code smaller and faster.

> > 3) How may I force GCC to generate a mulu instruction, instead of muls ?
>
>   dunno.. either do it inline, or accept it :)

I think it is an important issue : if you have two unsigned 16 bits values to 
multiply, I don't understand why the compiler generate a muls, as the result 
could be different when one of the values is > 32767.
I know the compiler may generate a call to a function handling multiplication 
with big numbers, but if you explain it ( by casting, or using right type of 
data ) that the two values to multiplicate are unsigned 16 bits ones and that 
you want the result in an unsigned 32 bits integers, it should generate a 
mulu, not a muls...

>   general gcc assembler info - heaps of it available, see Cube3D/Burning
>   for samples of inline assembly using gcc.. where possible, and i see
>   benefits.. i use it all the time

Yes I know, good samples to look at ! :-)
But what I'm looking for is a documentation of how the m68k tools work : 
which general registers are assumed to be destroyed between functions calls, 
what kind of optimization could be made by "explaining" it to the compiler 
etc...
These topics are not covered in the online doc of prc-tools.

-- 
Daniel Morais

-- 
For information on using the Palm Developer Forums, or to unsubscribe, please see 
http://www.palmos.com/dev/tech/support/forums/

Reply via email to