[comp.lang.c] Borland's new C compiler

wvpj@vax1.ccs.cornell.edu (Marc Parmet) (06/04/87)

Anyone out there have reviews of Borland's new C compiler?  Does it truly
generate tighter and faster code than MSC 4.0 in one pass?  Anyone run
independant benchmarks?  
 
Any comments would be appreciated.
  
Marc Parmet
Cornell Math Dept.

iverson@cory.Berkeley.EDU (Tim Iverson) (06/05/87)

In article <381@vax1.ccs.cornell.edu> wvpj@vax1.UUCP (Marc Parmet) writes:
>Anyone out there have reviews of Borland's new C compiler?  [...]

Does anyone know if CodeView will work with the .exe files produced
by this compiler?

- Tim Iverson
  iverson@cory.Berkeley.EDU
  ucbvax!cory!iverson

ephram@violet.berkeley.edu.UUCP (06/08/87)

In article <2835@zen.berkeley.edu> iverson@cory.Berkeley.EDU.UUCP (Tim Iverson) writes:
>Does anyone know if CodeView will work with the .exe files produced
>by this compiler?
>
>- Tim Iverson
>  iverson@cory.Berkeley.EDU
>  ucbvax!cory!iverson

The answer is a qualified yes.  CodeView will work with an Assembly language
program also.  The catch is that there is no info about source code and no
variable names included in the .exe file.  That means that what you will have
is the Assembly view of the codeview screen without symbols (memory ref's
only).  Still a viable tool though.

Ephram Cohen
ephram@violet.berkeley.edu

ephram@violet.berkeley.edu

darrylo@hpsrlc.HP.COM (Darryl Okahata) (06/08/87)

In comp.lang.c, iverson@cory.Berkeley.EDU (Tim Iverson) writes:

>In article <381@vax1.ccs.cornell.edu> wvpj@vax1.UUCP (Marc Parmet) writes:
>>Anyone out there have reviews of Borland's new C compiler?  [...]
>
>Does anyone know if CodeView will work with the .exe files produced
>by this compiler?

Codeview will not work with Turbo C.  If it did, Microsoft could probably
sell quite a few copies of CV (assuming they did sell CV as a standalone
product).

>
>- Tim Iverson
>  iverson@cory.Berkeley.EDU
>  ucbvax!cory!iverson
>----------

     -- Darryl Okahata
        ucbvax!ucbcad!ames!hplabs!hpcea!hpsrla!darrylo		<== best path
	hplabs!hpcea!hpsrla!darrylo				<== alternative
	CompuServe: 75206,3074

Disclaimer: the above is the author's personal opinion and is not the
opinion or policy of his employer or of the little green men that
have been following him all day.

jpn@teddy.UUCP (06/08/87)

>>Anyone out there have reviews of Borland's new C compiler?  [...]
>
>Does anyone know if CodeView will work with the .exe files produced
>by this compiler?

Well, it will WORK, but Turbo C does not put in the symbolic information
that Codeview needs to work in symbolic mode (which is probably what you
were really asking).  Turbo C appears to be able to put line number
information into the .obj file, so it will probably work with SYMDEB
(untried).

ssnyder@tybalt.caltech.edu (Scott S. Snyder) (06/09/87)

In article <4074@teddy.UUCP> jpn@teddy.UUCP (John P. Nelson) writes:
>>>Anyone out there have reviews of Borland's new C compiler?  [...]
>>
>>Does anyone know if CodeView will work with the .exe files produced
>>by this compiler?
>
>Well, it will WORK, but Turbo C does not put in the symbolic information
>that Codeview needs to work in symbolic mode (which is probably what you
>were really asking).  Turbo C appears to be able to put line number
>information into the .obj file, so it will probably work with SYMDEB
>(untried).

  Yes, SYMDEB will work. However, you CAN get CodeView to use line numbers
and global symbols from Turbo-C programs. You just have to use Microsoft's
linker. Since Turbo doesn't put default library names into the .obj file,
you'll also have to tell LINK about all the Turbo libraries and the startup
object file (c0), i.e., something like this:

    link/co \tc\lib\c0s pgm, pgm,,\tc\lib\emu \tc\lib\maths \tc\lib\cs

(handy tip: put emu (or fp87) BEFORE cs in the link command; otherwise floating
 point doesn't work. Also, c0 should be before your program name; otherwise
 spurious "Null pointer assignment" errors are generated)

Of course, CodeView won't know about anything about types or
automatic variables.

And now a question: TC doesn't seem to support modifying static data with near,
far, and huge like MSC does (TC seems only to allow them for pointers and
functions). Is this correct? Are there other ways to achieve the same thing?
(specifically, what I want to do is to have an array bigger than 64k without
having to use the huge model).


sss

turnera@hubcap.UUCP (Allen Turner) (06/10/87)

I encountered two problems during the process of converting a program 
from MSC 3.0 to Turbo_C and I don't know if they are bugs or features.

The first problem (please don't flame me for this one, I inherited this
code) occurred because Turbo_C, unlike MSC 3.0, requires the argument types
of functions to be declared.  MSC requires a function declaration
if the function returns something other than an int while Turbo_C requires this
and  the declaration for all arguments.  For example in MSC 

char *strswap();       /* in calling routine */



char *strswap(a,b,count);     /* start of subroutine strswap */
char *a,*b;
int count;
{
...
}


would be required while in Turbo_C

char *strswap(char *a,char *b,int count); /* in calling routine */


char *strswap(char *a, char *b,int count); /* start of subroutine strswap */
{
....
}

would be required.


I haven't decided if this requirement is an indication of a smart compiler or
a dumb one but the explicit declarations did allow Turbo_C to turn up some
errors that MSC missed.



The second problem I encountered involved the way MSC and Turbo_C deal with
command lines. If the following command were given at the DOS prompt:

C>test b="this is a test"

MSC considers argv[1]='b="this is a test"' and argv[2]='' while Turbo_C 
considers argv[1]='b=' and argv[2]='this is a test' (Note: Turbo_C did 
eliminate the quotation marks as I have indicated).  Which, if either 
of these, is correct?


Are these bugs or features?  I looked in K&R but I couldn't find a thorough
explanation of either of these points.


Allen Turner