Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!ucsd!usc!srhqla!demott!kdq From: kdq@demott.COM (Kevin D. Quitt) Newsgroups: comp.sys.ibm.pc.programmer Subject: Re: Looking for experience with big project upgrades from MSC 5.1 to 6.0 Message-ID: <297@demott.COM> Date: 13 Jun 90 19:22:49 GMT References: <1990Jun13.132843.13966@Octopus.COM> Reply-To: kdq@demott.COM (Kevin D. Quitt) Organization: DeMott Electronics Co., Van Nuys CA Lines: 82 In article <1990Jun13.132843.13966@Octopus.COM> pete@Octopus.COM (Pete Holzmann) writes: >I'm working on a very large commercial software project using MSC 5.1 and >some assembler. It is complex, huge, hairy, etc. Doesn't use Windows, >but does use graphics, interrupts, EMS, lots and lots of overlays, etc. > ... > 1. In general, did it go very smoothly? (i.e. no gotcha's vs. so many > gotcha's we cried for a month... :-)) It went smoother for us than expected. We kept both compilers around, but within a week we discarded 5.1. > 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?) Generally speaking, we use /Ox /Gs, and where speed is a requirement we use /Gsr - there are major gains to be had here, and only minor annoyances to get them. The r indicates to the compiler to use a much faster (albeit non-standard) calling convention, except for functions explicity declared as cdecl. In heavy subroutine oriented code, we get a gain of 10 to 40% in speed. For those (unfortunately fairly common) functions that are broken by loop optimiation, we were alreasy using #pragmas in the file, so have not been affected. We do seem to require fewer of them, though. Another nice feature is that 6.0 will put debugging info into a file compiled with optimization. > 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...) Maybe we're just lucky, but we haven't observed any new ones. > > 4. What kind of hassles have you had with auxilliary tools (linkers, > debuggers, etc.)? Does everything still work ok? Codeview's a lot nicer, it automatically remembers most of your context from the previous session. I'm using it without a mouse, so it's not quite so convenient as it might be. One problem we did have was the failure of a breakpoint to happen when a line was executed. That was finally traced down to a compiler problem - the NOP used to even a RET was flagged as the first byte of the next line, so that CV made the NOP the breakpoint. Of course, all the linked code jumped to the next instruction. We don't use the PWB though. We use Epsilon - it's a better editor, and does a better job of make. When we have time to decode the help files, we'll add the context sensitive help the PWB has. > 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?) We don't compile for size, since we spawn and exec all over the place, but we do get 10-40% better speed. > 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 :-))? We were having problems meeting real-time requirements until we switched to 6.0. -- _ Kevin D. Quitt Manager, Software Development 34 12 N 118 27 W DeMott Electronics Co. 14707 Keswick St. Van Nuys, CA 91405-1266 VOICE (818) 988-4975 FAX (818) 997-1190 MODEM (818) 997-4496 Telebit PEP last demott!kdq kdq@demott.com 96.37% of the statistics used in arguments are made up.