Path: utzoo!yunexus!ists!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!usc!apple!snorkelwacker!spdcc!merk!xylogics!cloud9!jjmhome!m2c!wpi!jhallen
From: jhallen@wpi.wpi.edu (Joseph H Allen)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: C compilers - why not TURBO C?
Message-ID: <5620@wpi.wpi.edu>
Date: 15 Nov 89 15:56:48 GMT
Article-I.D.: wpi.5620
References: <0010@starsend.UUCP> <1199@utkcs2.cs.utk.edu> <2764@levels.sait.edu.au>
Reply-To: jhallen@wpi.wpi.edu (Joseph H Allen)
Organization: Worcester Polytechnic Institute, Worcester, MA. USA
Lines: 87

In article <2764@levels.sait.edu.au> MARWK@levels.sait.edu.au writes:
>In article <1199@utkcs2.cs.utk.edu>, wozniak@utkux1.utk.edu (Bryon Lape) writes:
>> 	Yes, but I cannot remember the names of the companies.  C
>> compilers that create 386 code are aroung $400+.
>> 
>> 	Turbo C is a joke and Quick C 2.00 is slow.
>> 
>> 
>> -bryon-

>Why is TURBO C a joke?

I might agree about QUICK C.  The last time I used it, the editor was
incredibly slow, it required a mouse and I got "INTERNAL ERROR 0001 PLEASE
CALL MICROSOFT SUPPORT" when I tried to compile somthing. (that was a long
time ago though)

But, why is TC it a joke?  The code TC makes isn't terribly great, but I use
it anyway because: 

- It's fast

- It supports tiny model (.COM files)

- Its non-ANSI extensions ease IBM PC/MS-DOS programming:

	/* far memory read for small & tiny models */

	int farread(int fd,char far *buffer,unsigned size)
	{
	unsigned oldds=_DS;
	_BX=fd;
	_CX=size;
	_DX=FP_OFF(buffer);
	_DS=FP_SEG(buffer);
	_AH=0x3f;
	geninterrupt(0x21);		/* This actually makes an 'int 021h'
					   I.E., it's not a function. */
	_DS=oldds;
	__emit__(0x73,0x02,0x19,0xc0);	/* AX=-1 if carry set */
	return _AX;
	}

  Because of these extensions, it's the only compiler I know of that can make
  TSRs without resorting to assembly language.  Device drivers can be made
  by making a simple replacement for the startup code.

- Although its editor is a bit primitive, I generally like its environment.
  In particular, the project file feature is quite handy.  Makefiles are a big
  pain compared to:

	it.c (it.h)
	this.c
	foo.lib
	asmpart.obj

- CS.LIB has only about 3k of helper code (for structures, longs and huge
  pointers).  This is nice since you can make 200 byte C programs if you
  use your own startup code.  (Borland should document this better though)

- It has a nice debugger

- The next error/previous error support is better than that of any stand alone
  editor

TC isn't perfect though.  In particular I'd like it a lot better if:
	- its generated code was better
	- it had a _FLAGS pseudo-variable (even if accessing it overwrites
	  another register)
	- its editor had multiple windows
	- its editor let you use left and right arrow to cross lines
	- its project file would call an assembler (of my choice)

I've also used these compilers:

Zortech:  Makes nice code, but I wish it had an assembly output option.  It
          has a real make utility compared to microsoft and borland.  I use it
	  with tcc when I need to use make.  It would probably be faster than
	  tc if it was memory resident and not in two parts.

Mircosoft's Big compiler:  The code it makes is nice (I like that it uses
			   8088s loop statements).  But it compiles very slow.

Quick C: Maybe you can correct me on this, but I think this compiler is a
         joke.  It only uses medium model in the integrated environment?  Its
	 libraries are different from the Big compilers?  All this may have
         changed since version 1.1