jdt@bucsb.bu.edu.UUCP (Dave Tenny) (05/22/86)
Here is a followup on the article I submitted as
AZTEC, good, bad, HELP.
The news is mostly good.
If you are porting large amounts of code from Lattice to Aztec,
you might find the following useful:
1.) ALWAYS use the +L (32bit int) option of the compiler,
and link with the 32 bit libraries. This is what
was causing most of the problems for me.
If you are not explicitly calling Intuition/AmigaDOS routines
you can probably get away without the +L option.
2.) Beware playing around with BOOL objects. I never proved to
my satisfaction that this was causing problems, but the following
suspicious situation exists:
in exec/types.h:
typedef short BOOL ;
#define TRUE 1L
#define FALSE 0L
3.) I still believe the librarian is not trustworthy.
I have examples where a linked module works with loose
object code, but fails when the object code was placed in a
library with the REPLACE option and subsequently re-linked.
4.) I believe that the librarian -T option fails for RAM: libraries
because of an intuition/AmigaDOS bug, and not a LB bug.
Hopefully fixed in next intuition release.
I finally got my favorite TERMINAL program working, as well as 3 or 4
other tools I can't live without using the above guidelines.
I had to keep the source loose, and repeat LN's until I had a
control file for the '-f' option of LN which had no unresolved externs.
I still believe that, provided the librarian utility is made worthwhile,
that Aztec should distribute the ORD utility with the developers
package. Only when both these things are done will I find the
librarian usable.
Having linked some tools successfully now, a typical (I'm happy to report)
code comparison is:
my terminal program: Lattice -> 39420 bytes, Manx -> 18480 bytes.
Many other tools were reduced in size by 50-70 percent!
There are still some port problems I haven't traced,
but I now feel good enough about the Aztec development package
to recommend it.
Good job Aztec!
Jeffrey D. Tennyhiggin@cbmvax.cbm.UUCP (Paul Higginbottom) (06/01/86)
In article <296@bucsb.bu.edu.UUCP> jdt@bucsb.bu.edu.UUCP (Dave Tenny) writes: > 2.) Beware playing around with BOOL objects. I never proved to > my satisfaction that this was causing problems, but the following > suspicious situation exists: > > in exec/types.h: > typedef short BOOL ; > #define TRUE 1L > #define FALSE 0L >... > >Good job Aztec! > > Jeffrey D. Tenny <chomp...> Yes, Jeffrey, your suspicion was warranted. The following will cause a problem: doit(5, TRUE); . . } doit(count, flag) int count; BOOL flag; { ... } Since BOOL is a short (i.e., 16 bits unless +l is specified under the compiler) but the constant TRUE or FALSE is long (32 bits), 'flag' will ALWAYS be zero in doit(). Aztec, arguably should have seen this and made BOOL typedef'ed to long, but Amiga is partially at fault, because they've been trying to make SHORT's go away and replace them with WORD to make life easier, and if this had been done, this problem would not have arisen. Hope this helps. Regards, Paul Higginbottom Disclaimer: I do not work for Commodore, and my opinions are at least my own. FLAME Also, I won't be on here for much longer (sniff), because Commodore views "outsiders" using their vax to post to read news as a security threat! I guess they don't need help on here either.
daveh@cbmvax.cbm.UUCP (Dave Haynie) (06/02/86)
> Regards, Paul Higginbottom > > FLAME > Also, I won't be on here for much longer (sniff), because Commodore views > "outsiders" using their vax to post to read news as a security threat! > I guess they don't need help on here either. Last I heard, it also had something to do with wasting tons of CPU time playing "trek" and "rogue" -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Dave Haynie {caip,inhp4,allegra,seismo}!cbmvax!daveh "I read dozens of books, 'bout heros and crooks, and I learned much, of both of their style.." -Jimmy Buffet These opinions are my own, though for a small fee they be yours too. \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
hardie@sask.UUCP (Peter Hardie ) (06/03/86)
Has anyone tried out the trig functions and floating point in the Aztec
compiler? A friend of mine has had a lot of trouble with them. For example,
#define PI 3.1415926525987654321 /* don't worry about the exact value */
main()
{
printf("%f\n",PI);
}
will print some outrageous value like 0.0922 etc.
but changing only the defined value to 3.14159 will make it print out a
more or less reasonable value.
He also tried out a program I have that generates data for a 'spider' which
is used in satellite tracking. If we use the lattice compiler then it outputs
exactly what my Vax 4.2bsd version prints out. But the Manx version only gets
about half the numbers right, even after we have corrected problems such as the
PI value above.
It appears to me that the sin and cos functions don't work too well near
PI/2 but I haven't looked into it real hard.
Any ideas?
Tnx
Pete
ihnp4!sask!hardieaburto@marlin.UUCP (06/05/86)
In article <379@sask.UUCP> hardie@sask.UUCP writes: >Has anyone tried out the trig functions and floating point in the Aztec >compiler? A friend of mine has had a lot of trouble with them. For example, >#define PI 3.1415926525987654321 /* don't worry about the exact value */ >main() >{ > printf("%f\n",PI); >} > >will print some outrageous value like 0.0922 etc. >but changing only the defined value to 3.14159 will make it print out a >more or less reasonable value. >He also tried out a program I have that generates data for a 'spider' which >is used in satellite tracking. If we use the lattice compiler then it outputs >exactly what my Vax 4.2bsd version prints out. But the Manx version only gets >about half the numbers right, even after we have corrected problems such as the >PI value above. >It appears to me that the sin and cos functions don't work too well near >PI/2 but I haven't looked into it real hard. >Any ideas? >Tnx >Pete >ihnp4!sask!hardie Newsgroups: net.micro.amiga Subject: Re: Followup: Aztec - good, bad, help. Summary: Expires: References: <296@bucsb.bu.edu.UUCP> <379@sask.UUCP> Sender: Reply-To: aburto@marlin.UUCP (Alfred A. aburto) Followup-To: Distribution: Organization: Naval Ocean Systems Center, San Diego Keywords: In article <379@sask.UUCP> hardie@sask.UUCP writes: >Has anyone tried out the trig functions and floating point in the Aztec >compiler? A friend of mine has had a lot of trouble with them. For example, >#define PI 3.1415926525987654321 /* don't worry about the exact value */ >main() >{ > printf("%f\n",PI); >} > >will print some outrageous value like 0.0922 etc. >but changing only the defined value to 3.14159 will make it print out a >more or less reasonable value. >He also tried out a program I have that generates data for a 'spider' which >is used in satellite tracking. If we use the lattice compiler then it outputs >exactly what my Vax 4.2bsd version prints out. But the Manx version only gets >about half the numbers right, even after we have corrected problems such as the >PI value above. >It appears to me that the sin and cos functions don't work too well near >PI/2 but I haven't looked into it real hard. >Any ideas? I don't have any ideas about Aztec C but I know that LATTICE V3.02 does not compute COS(PI/4) correctly. AAA