Path: utzoo!attcan!uunet!snorkelwacker!usc!cs.utexas.edu!news-server.csri.toronto.edu!turing.toronto.edu!west
From: west@turing.toronto.edu (Tom West)
Newsgroups: comp.sys.ibm.pc.programmer
Subject: Re: Looking for experience with big project upgrades from MSC 5.1 to 6.0
Message-ID: <1990Jun13.170756.11973@jarvis.csri.toronto.edu>
Date: 13 Jun 90 21:07:56 GMT
References: <1990Jun13.132843.13966@Octopus.COM>
Organization: CSRI, University of Toronto
Lines: 100

Pete Holzmann writes:
>Has anybody out there been through (or most of the way through) an upgrade
>of a big pile of code from 5.1 to 6.0?

  I have been involved in porting a 300k program from MSC 5.1 to MSC 6.0  My
experience has been middling (it took longer than I expected).  Unfortunately,
I have had a major problem that has put my upgrade project on hold.  
Specifically, MSC 6.0 generates bad code under certain circumstances under
what are considered "safe" optimizations.  This means that one can never be
certain that one's program is reliable unless you have an exhaustive test
suite.
 
>    1. In general, did it go very smoothly? (i.e. no gotcha's vs. so many
>	gotcha's we cried for a month... :-))

  In my case, I had a bit of assembler.  I was required to either rewrite
the assembler or revise the declarations of the assembler routine to be
_cdecl.  (The -Gr fastcall convention requires this.)  Also, if you have 
routines that redeclare built in routines, this too must be changed.  The
redeclaration of the built-in routines (strcpy, etc.) are almost
certainly different from the ones included in string.h and so on.  This
is again, because all built-in routines are declared _cdecl.  For me,
this was all a bit of a problem, because I was working with C that had
benn generated by another program.  Thus fiddling with the C code was not
very pleasant.  Eventually, I solved this by writing a sed script to delete
all built-in routine declarations in the C code, and include my own .h
file at the beginning of the program that included all the regular .h files
I might need.

>    2. What compiler switches did you end up using in order to have code
>	that always runs ok without tweaking things everywhere? (Or did
>	you end up tweaking everywhere?)

  I am optimizing for size and use /Osleazr /Gsr normally.  However, I had
a number of fatal compiler errors that caused me to use slightly tweaked
options.  Most annoyingly of all, I have a large library that must be compiled
-Alfu.  Unfortunately, if you have a double routine call a double routine with
that memory option, the compiler crashes.  This is annoying because there is
no option I can turn off to correct this.  I have temporarily solved the 
problem by declaring the routines in questions -AL.  This means that my
library routines may not work under certain circumstances, but I know about
this.
  Unfortunately, I have come across a case where MSC 6.0 generates bad code.
(See my previous post)  This means that I don't really dare use it!  I have
no way of knowing if the code produced is suitable to be shipped to our sites!
The MS Product Support people has been sympathetic and they are sending my
bug reports to the dev team, but there is not a lot they can do (especially 
in Canada).

>    3. What kind of global tweaks were required? (i.e. under MSC 5.1, you
>	must make sure that any function definitions in an include file do
>	not span more than one line, or you'll break CV...)

In order to do the optimizations correctly or at all well, you must give
MSC as much space as possible.  Prefereably around the 600k mark.  This means
that we had to abandon our regular development system of having all the source
on a SUN, with PC-NFS on the PC.  Instead, we had to move everything down to
the PC and eliminate all TSRs.  Note that if you don't do this, you won't 
get much in the way of warnings, but your program may be up to 10% bigger!
(When I first compiled some sections of code, I was disappointed to find no
difference in code size between 5.1 and 6.0.  Then I read on the net that
it needs space!  Glad I read the net carefully.  You will still get messages
about routines too large to optimize regardless, but this should only occur
in the larger routines.

>    4. What kind of hassles have you had with auxilliary tools (linkers,
>	debuggers, etc.)? Does everything still work ok?

Everything seemed to work well, I have only played with CV, but it seems
acceptable.  We don't play with PWB, so I haven't tested it.

>    5. Do you have a general idea of code space saved, data space saved,
>	speed improvements? (Probably also in this category: rumor has it
>	that constants can be/are now compiled into the local code segment,
>	which would be a big win in an overlaid architecture; is this true?)

  Our compiled program went from 327k to 296k.  We have not redesigned our
code to take advantage of new features in MSC 6.0.  There is the _based
keyword that might be very useful to others.

>    6. Ignoring the fact that in general you've got to upgrade your tools
>	eventually, was the benefit from upgrading more valuable than the
>	hassle, or was it more trouble than it was worth? (i.e., if you had
>	it to do over, would you wait if you could, maybe for 6.1, or even
>       switch to a different compiler :-))?

  In light of the bad code generation, I have no choice but to suggest you wait
for a bug fix.  From talking with the Tech Support people, I think they are 
having a fair number of problems with this release (they sound a bit frazzled).
I have encountered two fatal compiler errors and one example
of bad code generation using "safe" optimizations.  I made the mistake of
incorporating a few features of MSC 6.0 into my code that I really like. 
(_heapmin may be a solution to heap fragmentation!!), to go any further in
product development, I will have to go back to 5.1, or more likely put 
everything on hold until 6.1 or 6.01 or something.

  The tech support guy claimed they had massively beta tested this thing.  I
wonder what happened?  (He wondered too...)

					Tom West