1748044 Members
5003 Online
108757 Solutions
New Discussion юеВ

LINK issue?

 
SOLVED
Go to solution
Willem Grooters
Honored Contributor

LINK issue?

A program has been developed (modules compiled) and linked on a AlphaServer 2000, VMS 6.2, DEC V5.0-003 and LINK version A11-35, using 1 commandprocedure to do it all.
There ar a runnable image, and a sharable one, to include the functionality within other appliactions (callable routines). Size of both the images is 367 blocks.

All files have been copied to a DS20 running VMS 7.3-1, and all has been recompiled (Compaq C 6.5-001) and linked (version A12-03). This rebuild used the very same commandprocedure as on the old machine. The only change was addition of /NOWARNING (due to usage of CRTL), and removal of one file that was needed on the old machine.
Size of the objects is somewhat inceased (in the order of tens of bytes), but the size of the images is over 1750 blocks - about 5 times the image on VMS 6.2!

ANA/IMA shows quite a number of differences in the image header and in the section attributes.
I added a ZIP (because of the size) of the ANA/IMA output, output of ANA/OBJ of one of the compiled modules and the build-procedures. one directory the old, the other the new situation.

Please an explanation (and , if possible, what should be changed) to get the things right.
Willem Grooters
OpenVMS Developer & System Manager
11 REPLIES 11
Uwe Zessin
Honored Contributor

Re: LINK issue?

I have a dim memory about the handling of demand zero compression when going from V6 to V7 on VAX (or migration to Alpha) - sorry it's about 8 years ago. I would try and put the following line into the LINKer's options file:
UNSUPPORTED=1
.
John Gillings
Honored Contributor
Solution

Re: LINK issue?

Willem,

"get the things right" is subjective. Times change and priorities change. The relative cost of different resources has changed drammatically in the time from V6.2 to V7.3-1. Whereas before the cost of disk space may have made it important to preserve disk space, most likely at the cost of performance. Now the cost of an extra 1300 blocks of disk space is so miniscule that it makes more sense to recover the performance. So what was "right" then, may be different from what is "right" now.

If you really want to track this down, I suggest you generate link maps with /MAP/FULL/CROSS (indeed, digression, general comment in compiling and linking - disk space is cheap! So, please consider generating full compiler listings and link maps every time you compile and link. It will pay off in debugging code, especially when problems are found in production). Examine the PSECT contributions and their attributes. I agree with Uwe that the most likely explanation is changes in DZRO processing, BUT it's also possible that a change in data alignment has blown out a data structure.

However, I recommend you seriously consider what you're trying to "fix" here. The time you spend finding and (if possible) changing the resulting size of this image will be orders of magnitude more than the cost of the disk space you recover (at the current cost of disk space, your 0.5MB of disk is worth only a small fraction of a second of your time!) Weigh that against the potential for faster image activation, because there's less work to do "unpacking" the image.
A crucible of informative mistakes
Willem Grooters
Honored Contributor

Re: LINK issue?

John,

Explanation accepted, this can be communicated if questions arise. One point though, that should be taken into account.

The whole application consists of about 260 executables, all single, runnable images, bisedes one or two sharebles. On the new machine, this covers 190K blocks. In the old days, a complete build would occupy 170K blocks.
Most is programmed in Dibol (Synergy), version 5.6 (quite old).
The application is distributed to our customers to be stored on their own VMS clusters. Most of them have not too much diskspace, and due to government investment plans, none will be able to add much more hardware.

Well, 20K block added is allowable, but I would have a hard time explaning (and most likely, lose the battle) if the application would expand in the proportions I saw on this image. I think we're lucky that the issue occurs in the non-Dibol programs only, that did not require a Digital/Compaq/HP (VMS-native) compiler...

(How we get into this 'trouble'): This was not a migration path over new versions of VMS and C, but a new machine where VMS 7.3-1 and latest C version were installed. This issue may have been mentioned in the release notes of VMS 7.0 or C, what would have been read if we were upgrading. Now, this was simply overlooked).

Willem
Willem Grooters
OpenVMS Developer & System Manager
Jan van den Ende
Honored Contributor

Re: LINK issue?

Wim,

I guess I recognise the environment :-), but for many years now WE are runnung DBL 5.7.6.



but a new machine where VMS 7.3-1 and the latest version ... were installed.


How's that, "latest version"?
Wouldn't that be 7.3-2 ??

John,

I immediately agree on the arguments, but, using your same wish for performance improvement:
Do you really think that the extra time required for your extra processor activity is more then the extra time for transferring more data from disk to memory?
And especially take into consideration the inevitable cases where the extra amount of data-to-be-transfered just makes the requirement for an EXTRA IO! (Maybe because of transfer size, maybe because the extra size caused an extra file segment).

And, in the case of DZRO, do you think that mapping in pages from the free list plus transfering the data pages (happening to be all zero) to them is faster than mapping in pre-zeroised pages from the DZRO list?

Of course I don't have pertinent data on it, but my gut feeling says.... I guess that were I presented specific quantitative info that would go against my feelings on this, I would probably spend quite some time in trying to find some fault in them, and only after very convincingly being shown that every detail is correct, that this is one of those rare cases where gut feeling can be deceptive....

Jan
Don't rust yours pelled jacker to fine doll missed aches.
Craig A Berry
Honored Contributor

Re: LINK issue?

Willem,

There are various different things that could be at issue, here, but this is what came to mind:

Type

$ HELP CC/OPTIMIZE

Pay particular attention to the INLINE and TUNE keywords, and study what options are used in your build procedure. For example, if you have /TUNE=HOST, you have switched from optimizing for an EV4 to optimizing for an EV6. More likely, though, is that the default inlining is much more aggressive in C 6.5 than in C 5.0. You should also look at /OPTIMIZE=INTRINSICS. There are probably a lot more functions now that are available as intrinsics and will not be implemented as library calls. You can of course turn off any optimizations you wish.

Since the greatest size increase happens at link time rather than compile time, I would also want to analyze your link process. If you want to make sure you are linking against the CRTL's shareable image and not the object libraries, do the following:

1.) Compile your code with /PREFIX=ALL
2.) Get rid of any LNK$LIBRARY logical name definitions in your build procedures or the environment (or at least any such definitions that point to CRTL libraries).
3.) Remove any explicit references to CRTL object libraries in any linker options files you may have.

If you do these things, the linker should look in IMAGELIB.OLB to figure out where to get things, and by default it will link against the shareable images, thus not including that code in your image (which may or may not be what's happening, but worth a look).

I don't know for sure whether any of these suggestions will help, but until you check out and eliminate them you won't know either.
Craig A Berry
Honored Contributor

Re: LINK issue?

I belatedly noticed that you supplied the build procedure with your original post. The procedure that creates the shareable image has the following line just before the link:

$ define/user decc$shr [-.com]empty.exe

This would almost certainly cause the linker to pull in the object code for all the CRTL routines into your image. Why that wouldn't also happen on VMS 6.2 I don't know, or perhaps it did happen but the size of those routines is much bigger now. If you have an ongoing need to distribute C applications to people on pre-7.x systems, I'd recommend hunting through the natural language search assistant for 'BACKPORT'.

On an unrelated note, I would also recommend migrating away from the /STANDARD=VAXC in your compiler switches as soon as possible.
Willem Grooters
Honored Contributor

Re: LINK issue?

Jan,
"latest": C version (this code is in C), not VMS ;-).
"Performance": on VAX, it matters. I have measured a program on these parameters, but it depends on how the image is built up. The one I observerd, was bad - in this respect.
On Alpha, I don't think it matters that much. At least, I should have to monitor the loading and mapping of the program - and (as John correctly states) the human cost outweighs the gain in performance.

Craig:
What I've seen is that empty.exe is what is says: EMPTY. just 5 blocks (I added ANA/IMA output), so I don't think this to be the case.
Getting rid of /STANDARD=VAXC - see comment on performence: just a matter of cost. The VERY SAME code should be runnable as shareable image, called by (old Dibol) code, and so it might well be a requirement. It simply doesn't hurt either... (If I had time on my own, I could check it out. But (as usual) this is scarce....)
Willem Grooters
OpenVMS Developer & System Manager
Jan van den Ende
Honored Contributor

Re: LINK issue?

Willem,

I never mentioned C version.
I referred to your "...new machine where VMS 7.3-1 and latest ...", wondering why that was NOT 7.3-2?

And I was wondering about your DIBOL (aka DBL) version. IIRC, we got the upgrade because of the memory barrier issue that became relevant at (I think) EV67. The release notes of VMS 7.1-2 made quite a fuss about it, but essentially, if you still have code compiled by early compiler versions, you should recompile.


AND that includes any routines from software suppliers !!!


Basically, _ONLY HAVE_ a "newly" compiled version of any software. For DBL, that would be V5.7.6. And that also applies to the runtime environment!!.

Should you not be able to acquire it regularly, contact me you-know-where. I'm sure we can work something out.


jpe


Don't rust yours pelled jacker to fine doll missed aches.
Craig A Berry
Honored Contributor

Re: LINK issue?

Willem,

I didn't quite explain enough about the empty executable. I believe what's happening is that linking against an empty image pointed to by DECC$SHR is intended to do the same as LINK/NOSYSSHR except only for the CRTL. If the linker doesn't resolve the CRTL symbols in DECC$SHR (which it won't if that points to an empty file), it will go on down the list defined by IMAGELIB.OLB and end up pulling in the object code from STARLET.OLB. There are any number of reasons this code would be much larger on modern versions of VMS than on 6.2.

You can prove this by doing an experiment. Create a one-line C program with a single printf (or any other CRTL routine). Just compile and link normally (all default qualifiers) and make note of the resulting image size. Then redefine DECC$SHR to your empty shareable image and relink. Notice the increase in your image size. When I do this, I see an increase of 1771 blocks.

I can't remember when exactly the CRTL came to be a standard part of the VMS distribution, so the trick to pull in everything as object code may have been done to avoid having to distribute the CRTL with the product.