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