Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-lcc!pyramid!voder!kontron!brad From: brad@kontron.UUCP (Brad Yearwood) Newsgroups: comp.sys.atari.st Subject: More on Alcyon double float array problem Message-ID: <1295@kontron.UUCP> Date: Thu, 15-Jan-87 05:35:07 EST Article-I.D.: kontron.1295 Posted: Thu Jan 15 05:35:07 1987 Date-Received: Fri, 16-Jan-87 00:38:05 EST References: <1294@kontron.UUCP> Organization: Kontron Electronics, Mt. View, CA Lines: 54 I was waiting for somebody else to more-or-less confirm my finding before posting this particular note. Another posting received this evening seems to confirm things sufficiently. Try the following program: double a[16]; main() { int i; double p, q; i = 10; p = 2.0; q = 3.0; a[i] = p * q; } Examine the generated code. Unless the late hour was impairing my judgment, the double multiply library routine returns its result in D0 and D1 (R0 and R1 - whatever you want to call them). The effective address calculation for a[i] promptly clobbers one or the other of these registers before doing the stores of each half of the result. No wonder my Fast Fourier Transforms and digital filters gave so many zero results that could be cured by breaking the computation down into tiny bite sized pieces, carefully avoiding any array element assignment more complex than: a[i] =I also observed printf hangups in debugging - possibly the partially corrupted stores create non-numbers which wedge the conversion routine. When reduced to tiny bite-sized pieces, however, Alcyon lets the inverse FFT of the FFT of 200 real data points zero-padded to 256, return very much the original real data, with only 0.0 and -0.0 imaginary components, and 0.0 or -0.0 in the real components of the 56 original zero-fill points. This is all using the IEEE package - not the fast package. My numerical luck with Mark Williams C hasn't been quite so good yet, with substantial fuzz remaining in both the imaginary components and zero-fill. They _do_ generate correct code, however. Win a few and lose a few. Maybe us seriously masochistic types who like the idea of slow floating point image processing on a budget, really just need a diversified portfolio of compilers to spread our risks. Disclaimer: This reflects work of strictly personal interest. Though we are commercially involved in image processing, my work at Kontron lies elsewhere. Brad Yearwood Kontron Electronics {voder, pyramid}!kontron!brad Mountain View, California (415) 965-7020