earleh@eleazar.dartmouth.edu (Earle R. Horton) (09/23/88)
In article <1995@iscuva.ISCS.COM> jimc@iscuva.ISCS.COM (Jim Cathey) writes: >In article <10134@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: >>I just acquired Aztec C 3.6c from MacWareHouse for $65.00. Seems like >>... >>The advertised MPW source-level support is pretty close, too, although >>they do use icky 16-bit ints, and the compiler barfs on MPW C style >>pascal function prototypes. > >16-bit ints are not 'icky', and I for one have never had any problem sticking >a (long) in an expression to force it into the 32-bit realm. I much prefer >the efficiency of the shorter integers, especially since the system will >usually fully support long arithmetic easily. > 16 bit ints are icky, Icky, ICKY, I-C-K-Y, because all the standard C library functions assume ints for parameters, and you cannot malloc() a large array or do any of a number of other basic operations using a compiler which uses 16 bit ints, without using low-level system-specific calls. Luckily, I see that Aztec does support a switch to change sizeof(int). These are my opinions solely, and reflect my programming style. I am fully justified in calling 16 bits "icky" in much the same manner as my children are justified in calling broiled mackerel "icky." I am also willing to allow that 32 bit ints are "icky" to you, but this is only because of your unenlightened state, which you may grow out of some day. Let us agree to disagree, OK? >The same cannot be said for going the other way (short arithmetic on >long-integer systems). > I don't follow the reasoning here. On architectures where short integer arithmetic is more efficient, you can simply declare variables as "short" and do arithmetic on them all day long. Be aware, however, that systems exist where short integer arithmetic buys you nothing. >Why oh why didn't Apple beat GreenHills profusely about the head and shoulders >to break their Vax mindset???? Now we're forever stuck with "Do you mean >Pascal integers or C integers?" (Some compilers even have a switch to change >the integer size. I would accept this solution.) See above, Aztec does this, although I haven't tried the long int option yet. Contrary to popular belief, an "int" is not, has never been, and never will be the same thing as a Pascal "INTEGER," not even on systems where the two happen to be the same size. The problem is not that MPW, or LSC, or Aztec use long or short ints, but that they use ints or shorts at all when talking to the ToolBox. The proper thing to do would have been have been to make a typedef for "INTEGER" and use it consistently throughout the #include files for the ToolBox. It is unfortunate that no one who wrote a C compiler for the Macintosh ever thought to do this, to my knowledge. It appears to be too late now, and pity the poor programmer who has to port between C systems on the Macintosh, or who has to maintain a program which can be compiled on more than one of them. Aztec update: It appears that I bought the entry level Aztec system, and don't get "make" with it. Big deal, I'll use MPW make. I have managed to get a fairly large program to compile and run successfully under both MPW and Aztec Cs, and with a minimum of "#ifdefs" for compiler model. My program is a three dimensional color animation, which uses hardware floating point arithmetic on the Mac II, rather than "icky" fixed point math as does the Apple-supplied Graf3D. The Aztec and MPW versions of the program run at about the same speed, but the real surprise is in the size. The MPW-compiled and linked program is 50k in size, while the Aztec-produced program is 40k! Either the Green Hills compiler is inefficient (I doubt this), or the MPW linker is incredibly stupid, or the MPW run time libraries are bloated, and contain lots of icky stuff that I don't need. I have a pretty good idea which compiler I will be using from now on, since it's faster, too. Earle R. Horton. 23 Fletcher Circle, Hanover, NH 03755 (603) 643-4109 Sorry, no fancy stuff, since this program limits my .signature to three