Queries regarding calls to divmod assembly functions

[Daniel Towner <daniel dot towner at picochip dot com>]

Hi all,

I am currently working on the implementation of division/modulus 
assembly libraries for incorporation into my port of gcc (which is 
currently a private port, but will be submitted back at some point). I 
have run into a few problems that I would appreciate some help with.

My port is for a very small embedded processor. Code size is very 
important (the various flavours of processor have 0.5, 8 or 48KB 
instruction memory). Speed is not that important, provided we don't 
waste too many cycles.

I have two assembly functions providing unsigned HI and SI mode 
computation, with two more simple functions which allow the unsigned 
functions to be used in signed mode. Each assembly function generates 
the quotient and the remainder. There is no point in having individual 
division/modulus functions, since the algorithm I use in the assembly 
function produces both these results.

Initially, I tried to do as the manual suggested, and omit any patterns 
for div/mod, to force gcc to use divmod instead, and setup the divmod 
optab to call a named assembly function. However, div would still call a 
div library, instead of the divmod library. So I set the div optab 
library function to null. Unfortunately this didn't appear to work; 
while the absence of any instruction pattern or library function works 
for mod (it generates a call to the appropriate library), the div 
expansion (in expand_divmod) seems to fail if no library or no 
instruction pattern is available, and leaves the function without trying 
a divmod library call. This results in the last part of expand_divmod 
trying to call gen_lowpart on a NULL_RTX. Is that correct? It seems easy 
to add a call to a divmod library as a last resort, but will that 
adversely affect other ports?

Next I tried to make the divmodM4 patterns generate a call directly to 
my divmod function by having a define_expand which invokes 
expand_twoval_binop_libfunc. This means that when the expand_divmod 
function is run, it finds the divmod instruction, which it then 
indirectly uses to generate the divmod library call. This appears to 
work as I expect. Are there any gotchas I should be aware of in doing this?

Now I have two final queries with this scheme. Firstly, if the source 
code contains a div and a mod in quick succession, then I end up with 
two calls to my divmod routine, although the instruction sequences to 
set up the two calls are identical. Are there any tweaks I can apply to 
allow the result of the first call to be reused, ratehr than calling the 
function again? Secondly, the SI mode version of the function returns 
the two data values by passing in an address to which to write the 
values. I can make the functions smaller and faster by changing the 
calling convention for just that function (i.e., return in registers 
instead), but how should I go about fixing the gcc end to call the 
functions differently? Should I explicitly emit the instructions to set 
up the call in the divmodsi4 define_expand, or should I change the ABI 
to be different for that one function, if possible?

thanks,

dan.

--
============================================================================
Daniel Towner
picoChip Designs Ltd, Riverside Buildings, 108, Walcot Street, BATH, BA1 5BG
daniel.towner@picochip.com
+44 (0) 7786 702589

This email and any files transmitted with it are confidential and intended solely for the use of the individuals to whom they are addressed. If you have received this email in error please notify the sender and delete the message from your system immediately.