vlv@drux3.UUCP (Vaughn Vernon) (08/27/85)
>> If you have come to expect performance >> from a 'C' compiler from a Unix point of view, you will be pleasantly >> accommodated by Microsoft. >> >> The bugs that may exist in the Microsoft compiler will never be confronted >> by the above average programmer and/or software project! Go ahead - >> beat the heck out of it ... if you can! >> Vaughn Vernon >Well, I've had the MSC 3.0 compiler all weekend, and managed to find a few >bugs without trying very hard. I installed it on my XT as per instructions, >and the first compile I tried went to never-never land and died. After a >lot of futzing around, I found I had to remove a "fix" that extended my >type-ahead buffer to 128 bytes, since the MSC compiler uses the (teensy) >environment to point to include, lib and .h files. Apparently there was >a conflict, and the compiler didn't check for one. It is the only program >(including two other C compilers) that has had any trouble like this. I have an extended type ahead. Never had a problem! >I then learned about the fun message "Out of environment space" >and spent time learning to avoid it. I next learned that the compiler is >happy with (modified switchar) pathnames like /bin/include, but the linker >isn't, so you have to set up your environment variable pathnames with >(retch) backslashes or locate things where you don't need pathnames. If >this is a Unix point of view I'll eat it, raw. Don't blame Microsoft 'C' ... blame Microsoft DOS! To say the least it is a hack at best(Unix stuff)! If you want Un*x, buy Xenix! The nice thing about MSC and Xenix is you can run the same programs on MS-DOS and Xenix. MSC supports relocatable objects (.obj) between MS-DOS and Xenix. And about all the environment space lost. I'm sure glad I don't have to give full path names to all of my includes, libs etc. This is a Unix feature. I think you can do without them though and just do all that "grunt work" by hand if you like. I've been putting up with MS-DOS for around 3 years now! >By the way, it is only about 4 to 5 times slower than DeSmet C to compile >and link moderate-sized programs; I guess that's good. CI-C86 is about 7 >times slower. Yep! DeSmet is real fast. I like the DeSmet compiler. Used it for two years. Microsoft doesn't claim to be fast. But then again I doubt that any other compiler comes close to doing all the optimization that MS does. I think the DeSmet compiler says ... take the line of 'C' and make it assembler. MSC says ... take this line of 'C' and make it into our psuedo language; then optimize; then make it assember. This allows Pascal and Fortran and the like the be called and visa-versa from 'C'. And allows fast code too. DeSmet gives you alot of freedom. The thing that gripps me about it though are things like _setmem(). How hard would it have been to write it as memset() with all the variables passed in the right order? I know I know! Write a macro, syyyyyyyyyyyyy! >The object >code is small and runs fast. That's where most of it's time is spent. Well worth the wait. >routines to link with the (modified) calling conventions, that two (2) >register variables are supported. You can also guess that from the >(re-written) version of sieve.c that comes with it -- two register >variables are defined, whereas the original sieve.c didn't use them. >It helps: sieve runs in 6.2 seconds with them defined, 10.6 sec without. Nice feature ... I'm sure not complaining! pushing and poping two more registers is not too bad. You only have to do it if you use them. >Overall, it's better than the other 2 compilers mentioned above, but it >doesn't beat them on all counts, and it still tastes a lot of MS-DOS >mixed in with the Unix. I totally agree! It is a 'C' compiler that allows the most Unix like features on MS-DOS. It does the best that could probably be done with what there is to work with in the first place. >WHY are the environment space and the maximum command-line argument strings >so small? Were they set up for 64K machines and never changed? > > Ed Nather MS-DOS limits ... not MSC! Disclaimmer: These opinions are just that .... opinions. Vaughn Vernon AT&T ISL - Denver, CO ihnp4!drutx!{drux1 | drux3}!vlv
caf@omen.UUCP (Chuck Forsberg WA7KGX) (08/28/85)
A few points to keep in mind: The object file formats are NOT compatible between Xenix and DOS. The .o files used on Xenix cannot be linked by the DOS linker, and DOS style .obj files don't mix with ld. It also appears impossible to take files from the Xenix libraries to fill in for missing routines in the DOS cross libraries. My documentation claims SI and DI are saved by every function call and always returned. But, the optimizer sometimes takes out the saves and resotres. MSC does not include any source code, not even to the startup routine. If your application needs something special in the way of stack setup, etc., you're stuck with Lattice. The MSC code density advantage is strongest with small model programs. A huge model 32 bit int "version" of the siev.c benchmark takes 252 bytes with Lattice C and 271 bytes with MSC. I don't know what the state of the Lattice large model compiler is, but I have yet to see a program longer than a couple of pages compile and execute properly with MSC's huge model on the Xenix system. -- Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf CIS:70715,131 Omen Technology Inc 17505-V NW Sauvie Island Road Portland OR 97231 Voice: 503-621-3406 Modem: 503-621-3746 (Hit CR's for speed detect) omen Any ACU 1200 1-503-621-3746 se:--se: link ord: Giznoid in:--in: uucp Home of Professional-YAM, the most powerful COMM program for the IBM PC
dan@rose3.UUCP (Dan Messinger) (09/06/85)
caf@omen.UUCP (Chuck Forsberg WA7KGX) writes >The object file formats are NOT compatible between Xenix and DOS. The >.o files used on Xenix cannot be linked by the DOS linker, and DOS style >.obj files don't mix with ld. It also appears impossible to take files >from the Xenix libraries to fill in for missing routines in the DOS >cross libraries. Yes and no. My Xenix came with a complete DOS cross-development package. Works real slick. Just add a -dos to the cc command, and the result is a .exe file. A different set of libraries are used in this case. These files ARE compatable with DOS link. I was forced to find out. My MSC distribution floppy had a hard error in the middle of the library. I took the entire cross-development library from Xenix and moved it to a DOS system. And the .o files from cc -dos are link compatible, too. But don't forget to rename them to .obj files after moving them to a DOS system. Dan Messinger ihnp4!umn-cs!rosevax!rose3!dan