Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ihnp4!ptsfa!lll-lcc!seismo!rochester!cornell!batcomputer!braner
From: braner@batcomputer.UUCP
Newsgroups: comp.sys.atari.st
Subject: Re: Compiler Question
Message-ID: <281@batcomputer.tn.cornell.edu>
Date: Wed, 25-Feb-87 23:50:10 EST
Article-I.D.: batcompu.281
Posted: Wed Feb 25 23:50:10 1987
Date-Received: Sun, 1-Mar-87 13:01:33 EST
References: <1264@husc6.UUCP> <788@bath63.ux63.bath.ac.uk>
Reply-To: braner@batcomputer.UUCP (braner)
Organization: Theory Center, Cornell University, Ithaca NY
Lines: 24
Summary: short and long ints, floating point

[]

If you want your programs to be portable, DON'T use 'short' directly.
Your Lattice 'short' is 16 bits, while, for example, Megamax 'short' is 8!
One solution is to use 'WORD' and "#define WORD short /* 16 bits */" at the
top of your program (or in a standard include file).

About floating point performance of the C compilers: most of them are
TERRIBLE.  Slow and buggy.  This is my main problem in using the ST for
scientific programming.  The IEEE format is partly to blame (very badly
suited for the 68000 architecture), but that's not the only problem.
Inefficient code is the real culprit.  (Trig functions written in C (!).
Calls to a dispatcher, passing an op code, rather than directly to
the appropriate routine.  Unnecessary extra copying of data...)
Absoft FORTRAN, for example, does FP an order of magnitude faster than
Megamax C.  Not to mention that Megamax log(x) yields garbage for
negative x (instead of an error message) and HANGS upon log(0)...  Alas,
I HATE FORTRAN (for no rational reason :-).  When will the C compiler
vendors realize that some people are serious about using FP?

I love C, but it is not for everything.  THE COMPLETE FP PACKAGE _MUST_
BE WRITTEN IN HAND-OPTIMIZED ASSEMBLER LANGUAGE!!!

- Moshe Braner