Re: COMPLEX: Summary and language extension

[Mike Griebling <grieblm@trt.allied.com>]

> >  Date: Mon, 12 Feb 96 08:59:40 EST
> >  From: Mike Griebling <grieblm@trt.allied.com>
> >  
> >  As an addition, the ABS() function could also be applied to both
> >  COMPLEX and LONGCOMPLEX types to return the magnitude of the 
> >  complex number.  Since ABS() is in the language anyway, it would
> >  be a free function and make cartesian to polar conversions a bit
> >  simpler and more efficient. BTW, ABS(z)=Sqrt(z.r*z.r+z.i*z.i).
> 
> This would mean to introduce either two opcodes abs_cmplx and
> abs_longcmplx into GSA (if translating ABS into a single GSA
> instruction), or to add opcodes for the sqrt function (if the
> front-end turns the complex ABS into elementary real operations).  The
> first option has the disadvantage of introducing opcodes dealing with
> complex math.
> 
> I'd prefer to include complex ABS, just to have a general ABS function
> that extends naturally to complex types.  But it's up to the back-end
> people if (yes or no), and how (abs or sqrt opcodes), they want to
> include the necessary math opcodes.

I wouldn't mind if the front-end did the translation for me and just
introduced an op-code for the sqrt function.  Most RISC processors 
seem to have a sqrt instruction built-in anyway.  By exposing the
instructions to the optimizer, there may be some optimizations that
can be done.
 
> -- Michael

Michael G.