gunning@sunybcs.UUCP (04/29/87)
I have been using my MIX compiler for about 6 months and have several
complaints. First, it is SLOW. VERY slow. Second, it only supports the
small memory model but this is not mentioned in either the advertisements
or in the manual. The way I found out was that once my program reached a
certain size it crashed to the operating system, with no message, when I
tried to run it. I called MIX and the person who answered informed me that
my program was too big for the compiler to handle.
Well, I can't say I am upset about this; after all the compiler only costs
39.95. It is, as far as I can tell, a full implementation of the K&R specs
for the language and I have not had any problem compiling (small) programs
which were developed with other compilers. Included with the compiler is a
facility for speeding up the compiled code (at the expense of size) and a
facility for compacting the code (at the expense of speed). Both seem to
work as claimed; when the SPEEDUP program is run on a compiled file, the
program does indeed run faster. I have not benchmarked it to determine just
how much faster it is but it is a noticeable improvement.
The manual has one major problem: each section of the manual has its own
index. This is a nice feature EXCEPT that a complete index is not provided
at the end of the manual. So if you want to find something you have to
search several indices instead of just one. But this is just a minor
inconvenience.
As for how this compiler compares to others: I used the Microsoft C Compiler
(version 3.0) extensively last summer. It was an EXTREMELY frustrating
experience due to the fact that the compiler had NO ability to recover from
syntactical errors. This meant that I had to recompile a program after
fixing EACH syntax error, including missing semicolons. Totally ridiculous.
The MIX compiler performs much better than this. It does a very good
job of recovering from every error I have inadvertently introduced into
my programs. When you consider that the Microsoft compiler lists for about
TEN TIMES the price of the MIX compiler you may be willing to overlook the
limitations of the MIX compiler.
As for the debugger, Ctrace, it is *WONDERFUL* when it works. I have had
problems using it with non-toy programs. The latest frustration is that
it prints the message: "Ctrace error zt" and crashes. No explanation of
error messages is given in the manual and when I called MIX to ask what
"error zt" means, the person I talked to told me that it was an internal
error that should never occur. This problem may have arisen because I
was nearing the 64K barier on file size and Ctrace, like the C compiler,
can only handle programs which are smaller than 64K.
In summation: I can highly recommend both the C compiler and Ctrace for
people who will be writing programs which use the small memory model
and who don't mind waiting a little while for the compiler to do its
work (about 2-3 minutes for a 60K file). For a combined price of $80 you
get a wonderful debugger, an excellent compiler, and a very good manual
which also has a tutorial section for novice C programmers. For those
people who want a blindingly-fast compiler that supports multiple memory
models, I suggest that you look elsewhere.
As for waiting for Turbo-C: I guess it depends upon how patient you are.
I have given up on Borland. I called their order number today to find out
when Turbo-C would be available and now they are saying sometime in mid-May.
I decided to buy the Datalight Optimum-C compiler for $139. It supports
5 memory models, has the ANSI extensions, has ROMable code support/startup,
is compatible with the DOS linker and assembler, comes with a Make utility,
and provides 12! types of optimization. Most importantly, it is available
NOW (I ordered it this morning and it was shipped this afternoon). For a
review of this compiler see _Dr._Dobbs_Journal_, August 1986 and
_Computer_Language_, February 1986. Note that these reviews were conducted
prior to the new "global optimizer" version.
--
CSNET : gunning@buffalo.CSNET
BITNET : gunning@sunybcs.BITNET
UUCP : ...!{allegra,decvax,watmath}!sunybcs!gunningvandys@Lindy.UUCP (04/30/87)
Yah, I bought the package for its price, too. Let me amplify on the
debugger, though: FLAKY. I suffered through corrupted screen I/O,
mysterious crashes, and lost breakpoints. When it worked, it was truly
nice.
The libraries were okay, if a little short on quality. My favorite
was:
if( (fp = fopen(argv[1],"r")) == NULL ){
perror(argv[1]);
exit(1);
}
which would result (for a non-existent file) in:
<file>: No error.
Oh, well. They also didn't seem to take typing too seriously, as
redeclaration of function types and usage of void function's values
elicited no complaint whatsoever.
So, bottom line: a "cheap thrill" C compiler. I think you'd be out
on a limb to try and use it for anything serious. For myself, I still
use Microsoft C version 1, and it's a much better compiler: better
error messages, better code, and faster compiles. Amazingly, symdeb
works on it, too!
Andrew Valencia
vandys@lindy.stanford.edu
br.ajv@rlg.BITNETscott@hpcvck.HP (Scott Linn) (05/02/87)
Just thought I would put my two cents worth into the discussion...
I also bought the MIX compiler for the price, and the fact that it will
run on my HP150 (generic MSDOS). It has been pretty good for the price,
but I've had a few problems, too.
First, the enumerated data types don't assign constants to the
identifiers. Example:
enum day {sun, mon, tue, wed, thu, fri, sat} next_day;
.
.
.
switch (next_day) {
case sun: (whatever)
case mon: (whatever)
etc. The MIX compiler gives an error at each case statement, saying
something to the effect that the compiler was expecting a constant, as
it should. But, it was apparent that the enum statement did not assign
sun, mon, etc. as constants. Anyway, I never got it to work.
Next, I was trying to open PRN: as a binary file, to perform a screen
dump. I used a routine which changed the printer device to raw mode
as well. The program never worked, as the program never printed the
data in raw mode (according to my dos routine, the printer *was* in
raw mode). After transferring the program to Datalight C with the
minor changes necessary for the DOS calls, the program worked just
fine. So, I know that the programming was correct. Anyway, I called
the MIX company, and they weren't helpful at all.
I bought the Datalight Optimum C package, and have been very pleased
with it. Compiles are very easy with the controller program they
give you, and the make utility is nice. I would recommend this
compiler over MIX C any day.
If anyone has any comments as to what I may have been doing wrong (if
anything) in my MIX programs, let me know!
Scott Linn
hplabs!hp-pcd!hpcvck!scottV125KJG8%UBVMS.BITNET@wiscvm.wisc.EDU (05/13/87)
<gunning@sunybcs.uucp> writes: >I have been using my MIX compiler for about 6 months and have several >complaints. First, it is SLOW. VERY slow. This is true even in a CP/M-80 or Z-System environment. Also, the memory requirements that the compiler asserts wreak havoc with the already limited space that Z-System provides for transient programs. Even the C.COM/C.OVY package which is 10k smaller will still cause a stack/heap collision on large files. Nothing I can do about that until I can bank-switch the code in another segment on my HD64180... >Well, I can't say I am upset about this; after all the compiler only costs >39.95. It is, as far as I can tell, a full implementation of the K&R specs >for the language and I have not had any problem compiling (small) programs >which were developed with other compilers. Included with the compiler is a >facility for speeding up the compiled code (at the expense of size) and a >facility for compacting the code (at the expense of speed). Both seem to >work as claimed; when the SPEEDUP program is run on a compiled file, the >program does indeed run faster. I have not benchmarked it to determine just >how much faster it is but it is a noticeable improvement. The manual claims here that speeds of up to three times faster are typical, and as high as 10 times faster if the code places heavy emphasis on integer arithmetic. If I need the compiled program to run rapidly and can put up with a limited C, I'll use Small C... I may have an IEEE-compatible math library written inspired by all the floating point errors discussed on here working in Small C soon... MIX C will compile and link quickly, but runtimes are slow, and a 20k file called RUNTIME.OVY has to be brought in; because of Z-System, I need only one copy of the file in my system. --Curtis R. Anderson a (hacking?) student at State University of New York at Buffalo. If I have opened my big mouth far enough to shoot flames, they are mine, not the university's... BITNET: V125KJG8@UBVMS.BITNET ARPA/INTERNET: V125KJG8%UBVMS.BITNET@WISCVM.WISC.EDU
V125KJG8%UBVMS.BITNET@wiscvm.wisc.EDU (05/14/87)
<gunning@sunybcs.uucp> writes: >I have been using my MIX compiler for about 6 months and have several >complaints. First, it is SLOW. VERY slow. This is true even in a CP/M-80 or Z-System environment. Also, the memory requirements that the compiler asserts wreak havoc with the already limited space that Z-System provides for transient programs. Even the C.COM/C.OVY package which is 10k smaller will still cause a stack/heap collision on large files. Nothing I can do about that until I can bank-switch the code in another segment on my HD64180... >Well, I can't say I am upset about this; after all the compiler only costs >39.95. It is, as far as I can tell, a full implementation of the K&R specs >for the language and I have not had any problem compiling (small) programs >which were developed with other compilers. Included with the compiler is a >facility for speeding up the compiled code (at the expense of size) and a >facility for compacting the code (at the expense of speed). Both seem to >work as claimed; when the SPEEDUP program is run on a compiled file, the >program does indeed run faster. I have not benchmarked it to determine just >how much faster it is but it is a noticeable improvement. The manual claims here that speeds of up to three times faster are typical, and as high as 10 times faster if the code places heavy emphasis on integer arithmetic. If I need the compiled program to run rapidly and can put up with a limited C, I'll use Small C... I may have an IEEE-compatible math library written inspired by all the floating point errors discussed on here working in Small C soon... MIX C will compile and link quickly, but runtimes are slow, and a 20k file called RUNTIME.OVY has to be brought in; because of Z-System, I need only one copy of the file in my system. --Curtis R. Anderson a (hacking?) student at State University of New York at Buffalo. If I have opened my big mouth far enough to shoot flames, they are mine, not the university's... BITNET: V125KJG8@UBVMS.BITNET ARPA/INTERNET: V125KJG8%UBVMS.BITNET@WISCVM.WISC.EDU -------