gary@apex.UUCP (Gary Wisniewski) (11/21/87)
I converted our product from MSC 4.0 to MSC 5.0 this evening and
thought I'd make a quantitative report of my findings. I'd be
curious to hear what everyone else's experiences turn out to be.
The program converted:
FrontRunner. A TSR database product compatible with dBASE III+.
There are about 50000 lines of code, written in C and assembler.
Assembler accounts for about 6000 of those lines. FrontRunner
is an interpreter, but creates pseudo-compiled code internally.
Pseudo-code is reverse-polish stack-oriented. Functions vary
widely in size, but an average is 75 lines. Code is well
written with register declarations and function prototypes.
Most functions use pascal calling sequence with near call
optimizations when possible. Memory model is `medium'. I wrote
my own memory allocator which is slightly slower than MSC
but less than half the size. The code works well and there
are very few loose ends (the product is currently on the market).
The process of conversion:
I had to make some (very minor) command line adjustments. I also
had to change about 20 references to memcpy() to the equivalent
memmove(). memcpy() now works differently. We have our own
startup code which is substantially the same as MSC ... no conversion
was required there.
All in all ... conversion was straightforward and the product
appears to work identically under both compiler versions. Total
elapsed time for conversion (including compiler installation): 5.5 hrs.
Strange happenings:
I got an internal compiler from "emit.c" when it hit the line:
qtraverse[qmac[qx]++];
Changing it to the following fixed it:
qtraverse[qmac[qx]];
qmac[qx]++;
Compilation details:
Memory model: medium
Command options: /Osal /Gs /Zd /AM /Zp /FPa /DLINT_ARGS
Link options: /map/noi/li/noe
Results; execution speed:
Execution speed appears to have increased. A very quick benchmark
test yielded about an 8% increase. The following dBASE program was
executed under both versions:
i = 0
? time()
do while i < 10000
i = i + 1
enddo
? time()
MSC 4.0 running time: 41 seconds
MSC 5.0 running time: 38 seconds (8% improvement)
The program is converted to byte-codes and executed by a byte-code
interpreter. All values are floating point.
Results; space:
I was a bit disappointed, since we were hoping for a space improvement
more than anything else:
MSC 4.0 image size after loading: 166064 bytes
MSC 5.0 image size after loading: 167712 bytes (1% loss)
All code was identical, except for memmove substitution and the qmac++
change necessary to avoid the code generation bug.
Here is a detailed summary of how the code and data segment sizes stack up.
Most entries represent individual modules. Those marked with an asterisk
are libraries which contain multiple modules.
Object Size Segment Class 5.0 vs. 4.0
MSC4.0 MSC5.0
00696H 006D4H FRONT_TEXT CODE LARGER
002FFH 002EEH INTER_TEXT CODE SMALLER
00214H 00210H CMDEVAL_TEXT CODE SMALLER
006B5H 006EAH CMDPARSE_TEXT CODE LARGER
00019H 0001AH CTERROR_TEXT CODE LARGER
00037H 00032H DBGLOBAL_TEXT CODE SMALLER
0017FH 00192H DBREC_TEXT CODE LARGER
000C7H 000B6H ENVMGR_TEXT CODE SMALLER
009B8H 009B8H PRGEXEC_TEXT CODE SAME
0056BH 0055EH DOFILE_TEXT CODE SMALLER
0003EH 00042H ERRMSG_TEXT CODE LARGER
*0733CH 078FCH _TEXT CODE LARGER (MSC runtime library)
0008EH 00088H SHOWTERM_TEXT CODE SMALLER
0001AH 00014H SETERR_TEXT CODE SMALLER
01031H 00FE6H CMD_A_TEXT CODE SMALLER
001DAH 001E0H CMD_ACPT_TEXT CODE LARGER
000EAH 000E2H CMD_CLOS_TEXT CODE SMALLER
001E0H 001D8H CMD_CMD_TEXT CODE SMALLER
00257H 00244H CMD_INDX_TEXT CODE SMALLER
002CAH 002B8H CMD_DIR_TEXT CODE SMALLER
0046FH 004E0H CMD_DISP_TEXT CODE LARGER
00146H 00148H CMD_FIND_TEXT CODE LARGER
000C2H 000C6H CMD_GOTO_TEXT CODE LARGER
0013AH 00136H CMD_LOCA_TEXT CODE SMALLER
0008EH 0008EH CMD_Q_TEXT CODE SAME
00B1BH 00B4CH CMD_SET_TEXT CODE LARGER
00094H 00096H CMD_SHOW_TEXT CODE LARGER
00084H 00082H CMD_SKIP_TEXT CODE SMALLER
00188H 0019EH CMD_STOR_TEXT CODE LARGER
001F8H 001F6H CMD_USE_TEXT CODE SMALLER
00299H 00280H CMD_DO_TEXT CODE SMALLER
001E0H 001D6H CMD_PAST_TEXT CODE SMALLER
0003DH 0003EH CMD_SELE_TEXT CODE LARGER
00104H 00108H CMD_REPL_TEXT CODE LARGER
004A5H 00490H CMD_FILE_TEXT CODE SMALLER
00059H 00058H CMD_APND_TEXT CODE SMALLER
00078H 00076H CMD_COMP_TEXT CODE SMALLER
000B3H 000B4H FRBI_TEXT CODE LARGER
000C8H 000C8H FRBO_TEXT CODE SAME
002AEH 002A4H CMD_AVER_TEXT CODE SMALLER
0020BH 0024EH CMDUTIL_TEXT CODE LARGER
000A2H 000A2H CMD_COUN_TEXT CODE SAME
00435H 0043AH SYNONYM_TEXT CODE LARGER
0006CH 00078H CMD_PUB_TEXT CODE LARGER
00049H 0004AH CMD_RLSE_TEXT CODE LARGER
000B0H 000BAH STATES_TEXT CODE LARGER
000F8H 000F8H CMD_DELE_TEXT CODE SAME
0002EH 0002EH CMD_ZERO_TEXT CODE SAME
0016BH 00184H DBGETKEY_TEXT CODE LARGER
0011EH 0011CH SERIAL_TEXT CODE SMALLER
0007AH 0007CH CMD_SOUN_TEXT CODE LARGER
00091H 00094H DISPSTAT_TEXT CODE LARGER
*00F99H 00F7AH UTILS_TEXT CODE SMALLER
*007B6H 007B0H SCOPE_TEXT CODE SMALLER
*0191FH 01924H DBHLI_TEXT CODE LARGER
001B4H 001AAH EFILES_TEXT CODE SMALLER
0011AH 00118H EALIAS_TEXT CODE SMALLER
00026H 00024H AUXFILE_TEXT CODE SMALLER
00082H 00082H EPATHS_TEXT CODE SAME
0002CH 0002CH DBKEYS_TEXT CODE SAME
0002EH 0002EH DBTODBK_TEXT CODE SAME
*0528BH 051F2H PARSER_TEXT CODE SMALLER
*01CDEH 01C58H WINDOW_TEXT CODE SMALLER
00083H 00096H MPOOLI_TEXT CODE LARGER
0005EH 0005EH REALLOC_TEXT CODE SAME
00021H 00022H MEMAVL_TEXT CODE LARGER
00030H 00036H FREECT_TEXT CODE LARGER
00000H 00000H C_ETEXT ENDCODE
00036H 00042H NULL BEGDATA
03884H 02198H _DATA DATA
0000EH 0000EH CDATA DATA
00070H 017ACH CONST CONST
00008H 00008H HDR MSG
000D1H 00176H MSG MSG
00002H 00027H PAD MSG
00001H 00001H EPAD MSG
006E2H 006E2H _BSS BSS
00BACH 00BACH c_common BSS
02000H 02000H STACK STACK
Compared to Turbo C (warning: subjective material follows)
About 2 months ago we went through the same exercize with
Turbo C. Again, we were hoping for space reduction. Here is
my recollection of the results:
Conversion time: 10 hours
Speed: Improved by about 5%
Space: Reduced by about 8%
Problems: Many bugs
We scrapped the Turbo conversion, mostly because the product
was not yet reliable. MSC is much more solid as it comes out of
the box. Turbo seemed to achieve greater space reduction. There
were more changes to make, of course, but both conversions were
relatively easy. Turbo ASM conversions weren't bad either.
Gary J Wisniewski
Apex Software Corporation
uucp: {allegra,bellcore,cadre}!pitt!darth!apex!gary
phone: (412) 681-4343cmaag@csd4.milw.wisc.edu (Christopher N Maag) (11/23/87)
In article <312@apex.UUCP> gary@apex.UUCP (Gary Wisniewski) writes: >[...] >Strange happenings: > > I got an internal compiler [error] from "emit.c" when it hit the line: > > qtraverse[qmac[qx]++]; > I've also gotten an "internal compiler error" with a similar (although a little more complicated) expression: /* add the new packet to the input queue */ imp_list[i].in_queue[imp_list[i].in_q_ptr++]=wrk_packet; I was running QuickC at the time. Needless to say, this runs fine under MSC v. 4.0, Mark William's C, and Berkeley UNIX C. When I was trying to isolate the problem so I could submit it to Microsoft I cut the program from about 500 lines down to 50, and, you guessed it, the problem went away. Has anyone brought this problem to Microsoft's attention yet? I would have, but I'm a little short on time right now. Chris. ======================================================================= Path: uwmcsd1!csd4.milw.wisc.edu!cmaag From: cmaag@csd4.milw.wisc.edu bitnet: cmaag%csd4.milw.wisc.edu@wiscvm.bitnet {seismo|nike|ucbvax|harvard|rutgers!ihnp4}!uwvax!uwmcsd1!uwmcsd4!cmaag =======================================================================
wtm@neoucom.UUCP (11/30/87)
<<stuff about compiler errors, etc>> In the Nov. 30th Cringeley column, he really lets MSC 5.0 / QuickC really have it with both barrels. Surprisingly, he claims that MSC5.0 gets indigestion when used with Western Digital HD controller cards being the root of mysterious errors. I find it a little hard to believe that one of the PeeCees out in Redmond or else on of the Beta people didn't have a WD controller. I guess we're still in the stage where MSC5.0 is coalescing from vapor ware. Condensation ware, perhaps? This whole vapor ware situation (not just Microsoft is guilty) is starting to get out of hand. It seems like one's company just isn't in vogue unless it names the next version any more than 15 minutes after the current version hits the streets. Never mind that coding hasn't even begun on the upgrade. Some companies are verging on vacuum ware-- absolutely no substance to announcements. --Bill
bobr@zeus.TEK.COM (Robert Reed) (12/02/87)
Well, I've used my new copy of MSC 5.0 to recompile my hacked up version of microEmacs, (along with several other utilities) and the only trouble I got was some warning that I had conditionals nested too deeply for the debug version. I was quite relieved after reading some of the stories posted here. -- Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK
farren@gethen.UUCP (Michael J. Farren) (12/03/87)
In article <794@neoucom.UUCP> wtm@neoucom.UUCP (Bill Mayhew) writes: >In the Nov. 30th Cringeley column, he really lets MSC 5.0 / QuickC >really have it with both barrels. Do you really believe anything this alleged man says without other proof? His record is abysmal. -- ---------------- Michael J. Farren "... if the church put in half the time on covetousness unisoft!gethen!farren that it does on lust, this would be a better world ..." gethen!farren@lll-winken.arpa Garrison Keillor, "Lake Wobegon Days"
mac@idacrd.UUCP (Bob McGwier) (12/07/87)
in article <2779@zeus.TEK.COM>, bobr@zeus.TEK.COM (Robert Reed) says: > Xref: idacrd comp.sys.ibm.pc:10459 comp.lang.c:5528 > > Well, I've used my new copy of MSC 5.0 to recompile my hacked up version of > microEmacs, (along with several other utilities) and the only trouble I got > was some warning that I had conditionals nested too deeply for the debug > version. I was quite relieved after reading some of the stories posted here. > -- > Robert Reed I also have been able to compile u-Emacs 3.9 with no pain after I had expunged some of the garbage in the version before I put it through 4.0. I also have written and maintain a very large satellite tracking package with graphics, data base manipulation, much floating point, etc. That all compiled after changing a few memcpy's to memmove's and the graphics routines supplied do a better job, faster than those I had cobbled together. The code is about 10-15% faster (much faster in math but I am giving you the average) so I should be MUCH happier, right???? Wrong. I have a friend, Phil Karn. He has written quite a few routines that make much use of the many of the things that "C" should be good at. DES, networking code, etc. First compiled with MSC 5.0 with every option in the book turned on, and then compiled with Aztec 4.10a with NO options turned, he and then I compared run times and sizes. We found the Aztec code to be consistently 20%-30% faster and smaller (here variance was larger but nevertheless always smaller). No one every likes to admit "their" compiler is not the greatest and best. But . . . . Bob