rwh@me.utoronto.ca (Russell Herman) (05/27/90)
Diomidis Spinelli's MSDOS port of Larry Wall's PERL is a marvelous tortur test for C Compilers. As I promised a couple months ago, I pushed it through MSC6 with interesting results. Testing was done on a 20MHz 386, no caching, DOS 3.3, no TSRs to maximize RAM availability. The source was pre-yacc'ed under SUNOS3.5. Generating PERL.EXE I started with a set of sources that I had slightly tweaked to compile under MSC5.1. As I had experienced some failures amongst the test suite, I discovered that these were diminished, but not eliminated, by disabling register declarations, and by using no optimization toggles. The compiler toggles for MSC5.1 were -AL -J plus -DCRIPPLED_CC. Reassured by the recent postings of markro@microsoft, I decided to start off adding the -Ox and -DINTRINSICS to see their effects. It was nice to be able to type NMAKE and go. The makefile had been previously set up to run from OPUS MAKE, which still out-features Microsoft's. But NMAKE is the first make version from Microsoft that rates an 'acceptable' in my book. The first event that happened was that define.h acquired some compile errors. One thing was thing was made painfully obvious by this. You can no longer guess how something is declared in header files. Remember the good old days when, since you couldn't be sure whether you compiler's errno.h contained a definition for errno, to insure portability you wrote extern int errno; somewhere in your own headers? Well, for MSC6 it has to read #ifdef _MT extern int _far * _cdecl _far volatile _errno(void); #define errno (*_errno()) #else extern int _near _cdecl volatile errno; #endif O ANSI, O INTEL! After eliminating this redeclaration and another flagged for formerly being having a char *, but now replaced by a void *, the compiler went to work. I didn't do any compiler timing tests, because MSC5.1 was used with default optimizations, whereas MSC6 was used with maximun safe optimizations. One thing I noticed about MSC6 is that it's going to encourage us to write more modularized. Lots of subroutines picked up the "function too large for global optimization" warning. By way of example, in the regcomp.c and regex.c (derived from Henry Spencer's version), regcomp, regatom, regclass, regexec, and regmatch all got this. One module blew the compiler out of the water. In array.c, the last line of if ((ar->ary_flags & ARF_REAL) && ar->ary_fill < key) { while (++ar->ary_fill < key) { if (ar->ary_array[ar->ary_fill] != Nullstr) { str_free(ar->ary_array[ar->ary_fill]); ar->ary_array[ar->ary_fill] = Nullstr; was too much for a compiler routine called (I think) regMD.c. Turning off the -Ox toggle for array.c allowed it to compile. On arriving at the link step, there were a couple of newly-created syntax errors. We foolish people who wrote response files specifying all 4 fields, therefore not bothering to place a semicolon after the library names: now there are *5* possible fields for the link utility - oops. And users of /PAC will have to change this toggle to /PACKC, because now there is a /PACKD as well (the purpose of which escapes me, since I couldn't find anything which explains how /PACKD improves runtime efficiency). Comparing MSC5.1 and MSC6 versions of PERL.EXE My DOSified test suite was run, using the "time" function of MKS Tools v3.1. MSC5 MSC6 Elapsed 3:38 3:47 ROM 3:02 3:15 DOS 10.5 8.7 User 25.5 22.5 As for executable size, the two versions weighed in within 1K of each other. I'd call it pretty equal. The User time is somewhat lower under MSC6, but I don't offhand know precisely what these times mean and how they are collected, or why the ROM time should change (unless it includes idle time). But now for the good news. Some of you expressed interest in my making available this version, only to be met with my refusal. I based it on my dissatisfaction with the test suite results, particularly with op.regexp which had 3 failures. I am pleased to report that these tests now give correct results. Some failures in s.op also now work properly, and one case in time.op that should've failed but didn't now does. Looks like 6.0 is a winner! Other comments In case anyone is wondering about how PERL behaves under TC2, forget it. You can't compile it. TC2 has a terrible time with the humungous switch statements produced by yacc-ers, usually running out of memory during compilation. If anyone else has results from other industrial-strength compilers, please post. Russ Herman INTERNET: rwh@me.utoronto.ca UUCP: ..uunet!utai!me!rwh