toma@tekgvs.UUCP (06/05/87)
I seem to remember someone wondering how to set the stack size. I caught a glimpse when reading the manual then I lost the place. The manual is badly indexed, and I could not find it again. So after perusing the startup code (thoughtfully provided .ASM file), I "rediscovered" that there is a global variable _stklen that when given an initial value will set the stack size when execution begins. Since people are wondering if it works, everything I have tried that has been standard C, no extensions & pass lint & *NIX compatible functions, compiles and executes fine. Those programs that are heavily relying on Microsoft C *usually* compile and *less usually* execute. While their library appears to be modeled on the Microsoft Library, the definitions of some functions differ -- I was caught by FP_OFF and FP_SEG not being usable for assignment in TurboC. Turbo also doesn't declare stdaux and stdprn. Also, a program which extensively used bit fields on a char didn't work (Turbo only allows them on ints). As far as performance. The compiler does a breathtaking 20,000 lpm on my 80386 AT Clone. Programs (all small model) are about 10% smaller than MSC. Execution times vary, are usually slightly faster, but has been as much as 25% slower. In all cases, both compilers were set with maximum "speed" code generation options. The "registers" option for Turbo is not always faster, btw. The Turbo C environment is great for small programs but for large ones suffers -- the built-in make is anemic (is limited to c-language sources, no asm, and a final link step), the editor is limited to one window, and debugging facilities are non-existant (the "Debug" menu selection is a pure joke -- it only pertains to compilation). I have a strong preference for "my" environment of Epsilon, MSC (or Metaware High C when I want more control over compilation), and Don Kneller's NDMAKE. Outside of the Turbo environment, the turbo compiler and linker are not as nice -- the linker does not know about library directories or even default libraries (MSC passes the library names to LINK). Option switches for the compiler (such as where include files are located) must be either on the command line or in a file. Borland must not believe in environment variables. I still feel burned by Turbo Prolog, and even with the delayed introduction there were some flaws. I have found a number of obvious manual typos. And their only sample program, Microcalc (TM), will not compile -- they include "stat.h" rather than "sys/stat.h". The manual is badly organized -- poorly indexed, no cross referencing, and there is "reference" in the "users" manual (memory maps, for one) and "user" instructions for the utility programs in the "reference" manual. The function reference is abbridged -- too many definitions refer you to others; while this is better than the *NIX manual, it is no where near as nice as Microsoft's. My feeling is that this compiler is great for personal use, but only fair for professional use (but the library source availability may change that). The price is sure right, at least during their introductory offer. Tom Almy tektronix!tekgvs!toma Disclaimer: I have no connection with either Microsoft, Borland, Lugaru (Epsilon), or Mr. Kneller other than as a satisfied user.