aharon@WISDOM.BITNET (Aharon Shtull-Trauring) (02/22/88)
We are in the process of porting a very large system from Vax pascal to C,
with the express purpose of being able to run on Apollos and Suns also.
We used a semi-automatic translator and then cleaned up the code to make it
real C. Nonehteless there is a close correlation between the C and Pascal.
Low and behold we noticed that the C objects are between 5 and 10 times larger
than the Pascal objects. Worse yet, what was a 5000 block image (compiled
and linked with debug) under pascal, is now 40000 blocks. After talking
to the Dec support people here in Israel, who turned to the European
support center, we were told that 'C under VMS is not a devlopment language'
(this is a direct, uncensored quote)!!!!!!!!!!!! We are in fact starting
to do all our debugging on our Suns and Apollos. Nonetheless, I do forsee
having to debug on the Vaxes to find all the wierd bugs VAXC no doubt will
cause. I should mention, that most of the 40000 blocks were debug records
(according to the map). Digital Europe claimed (again this is a direct quote)
that all the extra stuff is things the compiler added so that C can
emulate unix!!!!!!!!!!!!!!! By the way our development machine is a Vaxstation
on a cluster (which unfortunatley shares an ethernet with Suns and APollos)
so a link can take well over an hour if doesn't die because of page file
hitting 0!
My question:
(1) Has anyone else encountered a similar problem and how did they get around
it (if they did)?
(2) Are there any good third party C compilers with good debuggers
available out there that run under VMS, that won't cause the same problems?
Help!!!!!!!!!!!!!!!!!!!
aharon shtull-trauring
aharon@wisdom.bitnettsf@arizona.edu (Ted Frohling) (02/22/88)
You are linking with the use of an options file with at least the line sys$share:vaxcrtl/share in it aren't you? If not the image will become very large. It sounds like the European support people didn't really know what they were talking about or didn't understand your problem and were blowing wind. Images don't get large because of all that Unix compatiblity stuff unless you have references for every C function. You aren't externing every C function are you? Good luck.
garry@batcomputer.tn.cornell.edu (Garry Wiegand) (02/23/88)
The /DEBUG executable can indeed be huge on a big program. The common cause is lots of little files each including some big .H files - the debugging symbol information ends up being replicated a bunch of times, and the effective number of lines of code is in the zillions. For example, for about 400 small modules, each of which includes about 1500 lines of .H stuff, I get a fully-debuggable .EXE of about 11,000 blocks. The same thing with no debugging at all is about 600 blocks. What I do is to compile most of the files /NODEBUG and then just a few in the current work vicinity with /DEBUG. (Then you link the whole thing /DEBUG, of course.) If the "work vicinity" is logically distinct from the rest of the system, I also sometimes build fully-debuggable shareable library images that hold the non-changing part of the system, and then just link to them repeatedly. See the SET IMAGE command in the debugger. (Um, we ARE talking about /DEBUG images, aren't we? I got that implication from the end, where you ask about "other debuggers". And the original Pascal wasn't built /DEBUG, or was all in one file, am I right?) Dunno about your problems with DEC/Europe. Sounds like they're not used to talking about C yet. (Odd, though - the VMS C compiler and support library are six or eight years old now! DEC/Europe really should know their stuff better.) garry wiegand (garry@oak.cadif.cornell.edu - ARPA) (garry@crnlthry - BITNET) PS - The VMS debugger is the best I've ever encountered - my experience with Unix dbx and sdb, for example, is that they roll over and croak with anything remotely large. Bugs up the wazoo! The VMS debugger, on the other hand, has saved man-years of work here, and it's probably the last, best, reason we're still a VMS shop!
kaiser@hillst.dec.com (Systems Consultant; DTN 297-4445) (02/24/88)
decwrl!decvax!ucbvax!WISDOM.BITNET!aharon writes, in part: We are in the process of porting a very large system from Vax pascal to C... the C objects are between 5 and 10 times larger than the Pascal objects ... what was a 5000 block image (compiled and linked with debug) under pascal, is now 40000 blocks. What you need to know, at a guess, is how to link with the sharable runtime library. Just as a hint, one of the sentences on page 15-3 of my copy of the manual "Programming in VAX C", in a section headed "Using the VAX C RTL as a Shareable Image", says in part: You drastically reduce the size of a program's executable image... When all else fails, read the documentation. [Acerbic comment on reading skills omitted here.] ---Pete Kaiser%hillst.dec@decwrl.dec.com decwrl!hillst.dec.com!kaiser DEC, 3 Results Way (MRO3-3/G20), Marlboro MA 01752 617-467-4445
jdp@adiron.UUCP (Powell) (02/25/88)
In article <8802220606.AA16924@ucbvax.Berkeley.EDU>, aharon@WISDOM.BITNET (Aharon Shtull-Trauring) writes: > > We are in the process of porting a very large system from Vax pascal to C, > with the express purpose of being able to run on Apollos and Suns also. > We used a semi-automatic translator and then cleaned up the code to make it > real C. Nonehteless there is a close correlation between the C and Pascal. > Low and behold we noticed that the C objects are between 5 and 10 times larger > than the Pascal objects. Worse yet, what was a 5000 block image (compiled > and linked with debug) under pascal, is now 40000 blocks. After talking > to the Dec support people here in Israel, who turned to the European > support center, we were told that 'C under VMS is not a devlopment language' > (this is a direct, uncensored quote)!!!!!!!!!!!! > ... > Digital Europe claimed (again this is a direct quote) > that all the extra stuff is things the compiler added so that C can > emulate unix!!!!!!!!!!!!!!! Several years ago, I converted approximately 6000 lines of code from PASCAL to C under UNIX (after first getting the PASCAL code to compile and execute properly on UNIX after it was developed on VMS). This experience showed me that relative sizes on one machine do not carry over to other machines (or replace "machine" with operating system). The actual lines of C code in direct translation was greater than the number of lines of PASCAL code on UNIX but the optimized C executable was about 1/2 as large as the optimized PASCAL executable (plus the C code was put into separate files so a one-line change to a function required only a few seconds to recompile and test. The PASCAL was all in one file so a one-line change to that required several minutes to recompile and test. Also under UNIX, the C version (with a few enhancements that should have slowed it down) ran probably about 20% faster than the PASCAL version. I am not trying to start a C vs. PASCAL discussion here, I am just saying that DEC's claim is valid. DEC says that C is not a development language under VMS, I say that PASCAL is not a development language under UNIX. Under UNIX, PASCAL (and FORTRAN) have intermediate libraries that let the language environment be simulated by equivalent UNIX system calls or subroutines so that PASCAL's writeln('Hello world'); is probably ultimately translated into C's fprintf(stdout,"Hello world\n"); by the language's library. If you want to flame DEC, do it for the reason that they don't seem to want to make C a "development language", not because they told you that it's not a development language. At least they were honest. BTW, I do not and never have worked for DEC. I just live in an environment where 4.3BSD, ULTRIX 2.0, SUN's 3.2, and VMS with DCL and DEC-shell are a part of everyday life. Good luck. John D. Powell PAR Technology
kaiser@hillst.dec.com (Systems Consultant; DTN 297-4445) (02/26/88)
I'm sorry for the acerbic non-comment on WISDOM.BITNET!aharon's original note; I regretted it perhaps .03 milliseconds after it was committed to mail. I read "image" as *.EXE. Is there any way to patch an image to get rid of unnecessary debug records? There is. But why build it with debugging information in the first place? Do you want some, but not all, debugging information? Different problem. The nature of the debug information records is documented in the VAX/VMS micro- fiche for VMS V4.n, so you should be able to figure out how to rewrite an image with only selected kinds of records. If you want to get rid of all debug and trace information, that's also well documented, and is even made visible with ANALYZE/IMAGE, e.g., $ ANALYZE /IMAGE Analyze Image 25-FEB-1988 09:56:20.05 Page 1 DISK$USER:[KAISER.EXE]SAMPLE-IMAGE.EXE;1 [...] Global Symbol Table & Debug Symbol Table Information debug symbol table VBN: 64, block count: 6 global symbol table VBN: 0, record count: 0 [...] Just truncate at the proper place (or rewrite, omitting the debug symbol table). Judging by the responses to the original message, it was ambiguous, and I wasn't alone in not perceiving that all their "own kernel stuff is built as shareable libraries." ---Pete Kaiser%hillst.dec@decwrl.dec.com decwrl!hillst.dec.com!kaiser DEC, 3 Results Way (MRO3-3/G20), Marlboro MA 01752 617-467-4445
terry@wsccs.UUCP (terry) (03/02/88)
In article <8802220606.AA16924@ucbvax.Berkeley.EDU>, aharon@WISDOM.BITNET (Aharon Shtull-Trauring) writes: > > Low and behold we noticed that the C objects are between 5 and 10 times larger > than the Pascal objects. Worse yet, what was a 5000 block image (compiled > and linked with debug) under pascal, is now 40000 blocks. As far as the object size is concerned, *STOP* compiling with the /DEBUG and /NOOPTIMIZE qualifiers! > After talking > to the Dec support people here in Israel, who turned to the European > support center, we were told that 'C under VMS is not a devlopment language' > (this is a direct, uncensored quote)!!!!!!!!!!!! This is typical. We have been selling our VMS terminal emulator/ file transfer program into Europe, and I was told basically the same thing by an Digital engineer from Germany. After several far-from-cheap calls and faxes, it was determined that the reason the were having problems with the code file, despite Digital/Europe's claims that it was a 'bug' in our code, was the fact that most European sites aren't even running VMS 4.4 yet. According to one source, support is attrocious. For all you net-landers, we have 4.7. Call your service rep. He's holding out. > We are in fact starting > to do all our debugging on our Suns and Apollos. Nonetheless, I do forsee > having to debug on the Vaxes to find all the wierd bugs VAXC no doubt will > cause. I should mention, that most of the 40000 blocks were debug records > (according to the map). Again, *STOP* compiling with the /DEBUG and /NOOPTIMIZE qualifiers! > Digital Europe claimed (again this is a direct quote) > that all the extra stuff is things the compiler added so that C can > emulate unix!!!!!!!!!!!!!!! Digital's C does not emulate UNIX. If it does, it is pronounced 'Eunochs', as in casterated. The only place I found even an attempt at compatability was in resoloutin of filenames, and then only if you bought DEC/Shell (an optional product). I have a good 300,000 lines of C code which doesn't run, even in the DEC/Shell environment, to prove this. On the other hand, our primary product does run very well, so it can be done, at the price of a lot of time. > My question: > (1) Has anyone else encountered a similar problem and how did they get around > it (if they did)? YES, and nearly 8 months of re-coding. What version of VMS are you running? I suspect you are running an older version where the libraries for C are not linked shared. Linking shared will substantially reduced your executable size, but on sites prior to 4.6, you are likely to get an error regarding and inability to run ...[sys0.]crtl.exe, as they have to be installed shared to be run correctly. > (2) Are there any good third party C compilers with good debuggers > available out there that run under VMS, that won't cause the same problems? Whitesmiths is bad. It is not UNIX or VMS compatable. Your mileage may vary, of course. I have found the Whitesmiths C for the Charles-Rivers Data Systems box to be more than adequate in a UNIX environment. | Terry Lambert UUCP: ...!decvax!utah-cs!century!terry | | @ Century Software or : ...utah-cs!uplherc!sp7040!obie!wsccs!terry | | SLC, Utah | | These opinions are not my companies, but if you find them | | useful, send a $20.00 donation to Brisbane Australia... | | 'There are monkey boys in the facility. Do not be alarmed; you are secure' |
val@wsccs.UUCP (Val Kartchner) (03/03/88)
In article <244@wsccs.UUCP>, terry@wsccs.UUCP (terry) writes: > Digital's C does not emulate UNIX. If it does, it is pronounced > 'Eunochs', as in casterated. The only place I found even an attempt at > compatability was in resoloutin of filenames, and then only if you bought > DEC/Shell (an optional product). On the contrary, VAX C does parse Unix (Pronounced eunuch and meaning it too) filenames. This requires no optional products, and no special parameters to fopen(). Repeat: VMS parses Unix filenames without anything special. -- --- /\ ------------ Val Kartchner {UT@WSC} ---- #include <flamesuit.h> ----- /\/\ . /\ | "Those who don't understand VMS are condemmed to reinvent / \/ \/\/ \ | Unix; those who understand VMS and Unix use VMS." ==/ U i n T e c h \====!ihnp4!utah-cs!utah-gr!uplherc!sp7040!obie!wsccs!val====
terry@wsccs.UUCP (terry) (03/03/88)
In article <248@wsccs.UUCP>, val@wsccs.UUCP (Val Kartchner) writes: > In article <244@wsccs.UUCP>, terry@wsccs.UUCP (terry) writes: > > Digital's C does not emulate UNIX. If it does, it is pronounced > > 'Eunuchs', as in casterated. The only place I found even an attempt at > > compatability was in resoloutin of filenames, and then only if you bought > > DEC/Shell (an optional product). > > On the contrary, VAX C does parse Unix (Pronounced eunuch and meaning > it too) filenames. This requires no optional products, and no special > parameters to fopen(). Repeat: VMS parses Unix filenames without > anything special. Execept documentation, which only comes with DEC/Shell, still an optional product. Do you read docs, or simply ask Dave? Also, the parsing is ala' Ultrix, and I still maintain that Ultrix is not real UNIX (my code files from real Berkely UNIX don't run EXACTLY the same). | Terry Lambert UUCP: ...!decvax!utah-cs!century!terry | | @ Century Software or : ...utah-cs!uplherc!sp7040!obie!wsccs!terry | | SLC, Utah | | These opinions are not my companies, but if you find them | | useful, send a $20.00 donation to Brisbane Australia... | | 'There are monkey boys in the facility. Do not be alarmed; you are secure' |
cole@sas.UUCP (Tom Cole) (03/03/88)
in reference to the "unix compatibility takes up space", there is a tiny kernel of truth to it. If your main entry point is named "main" then you get some extra stuff for supporting DECShell linked into your image. However, it's not all that much. But to completely avoid the wasted space, just name your main entry point something else and make sure it is the first object module in your link. You can save a few blocks in your image this way.
terry@wsccs.UUCP (terry) (03/04/88)
In article <8802251456.AA15795@decwrl.dec.com>, kaiser@hillst.dec.com (Systems Consultant; DTN 297-4445) writes: > I'm sorry for the acerbic non-comment on WISDOM.BITNET!aharon's original note; > I regretted it perhaps .03 milliseconds after it was committed to mail. > > I read "image" as *.EXE. Is there any way to patch an image to get rid of > unnecessary debug records? There is. But why build it with debugging > information in the first place? Do you want some, but not all, debugging > information? Different problem. You want all debugging info EXCEPT a specific entry, which you want to be invisible to users of your program/product. > The nature of the debug information records is documented in the VAX/VMS > microfiche for VMS V4.n, so you should be able to figure out how to rewrite > an image with only selected kinds of records. The entire point of the VMS help facility seems to be providing Digital engineers with an excuse for poor/non-understandable/inaccurate documentation (see my previous posting on the QIO$ parameters to the parity call, as documentaion goes). The point is to get _rid_ of _specific_ records. > If you want to get rid of all > debug and > trace information, that's also well documented, and is even made > visible with [example of an ANAL/IMAGE extracted] > Just truncate at the proper place (or rewrite, omitting the debug symbol > table). Either of which tend to remove the wrong records. The entire purpose of "doing it without debug" is to _NOT_ alter previous info while avoiding the creation of more info. Uses? How about serialization of distribution media? Patching library module ID numbers when you aren't calling 4.3 incompatable stuff, so that you don't have to have several versions for several versions of VMS? The possibilities are endless... BTW: The was a neat futility to do just that for all sorts of files that i just glommed off the net: zap, posted by John Vromans... coming to a archive near you! | Terry Lambert UUCP: ...!decvax!utah-cs!century!terry | | @ Century Software or : ...utah-cs!uplherc!sp7040!obie!wsccs!terry | | SLC, Utah | | These opinions are not my companies, but if you find them | | useful, send a $20.00 donation to Brisbane Australia... | | 'There are monkey boys in the facility. Do not be alarmed; you are secure' |