🚀 go-pugleaf

In article <Bvo7FC.M01@ithaca.com>, garry@ithaca.com (Garry Wiegand) writes:
>In a recent article I wrote:
>>> DEC ought to redo their shareable-image technology. The current method
>>> was invented almost 15 years ago and has a variety of problems.
>
>And Nigel Arnot responded:
>>        I'm curious. I know that making a shareable image can be tedious,
>>but once put together they seem to work rather well. What improvements
>>do you have in mind, and has anyone done something like them already?
>
>The Big 3 that come to mind:
>
>1. Writeable psects should default to "no-share" in all the higher languages.
>2. Transfer tables should go away.
>3. Shareable image version numbers should go away.
>
>#1 is an artifact of the way someone at DEC was thinking about
>virtual memory in the early days. The rule became "if you're shared,
>and you have a Fortran common block, say, you MUST be trying to
>communicate through writeable shared memory - why would any user
>program want to be shared otherwise??"   Only later did code
>modularity, and library shareable images, become interesting
>concepts, and by then it was too late to change the defaults.
>Everyone with portable code nowadays has to has to use a linker
>options file to override all the compiled psect declarations. 
>

	If you are porting, you expect to have to make some changes.  However
if you are just recompiling and link your program you *DO NOT* expect to have
to make changes.  So as not to break what is out their right now, I'd be very
much against this.  However, a quailifier on the compile commands that makes
no-share the default would be OK.


>The way to achieve #2, the departure of the transfer table, is by
>"lazy binding" of symbols - the linker just checks that the symbols
>needed are there in the current version of a referenced shareable
>image; the image activator does the work at run-time of making the
>final symbol-to-address binding. The first time I saw this, years
>ago, I said "naah, that can't possibly be fast enough - image
>activation will be slowed down bigtime." Being scientific, I
>immediately set out to prove my foregone conclusion. Un-for-tunate-ly,
>in all the torture tests I could dream up the slowdown due to the
>dynamic binding was either trivial or completely undetectable. And
>since then CPU's have gotten a lot faster. (The activator code I was
>testing was probably a BSD4.3 Unix derivation on a Sun. They did a
>good job of that code.)

	Take a look on how things work on Alpha VMS.  (Its done)

>The primary purpose in life of #3, the shareable image version
>numbers, is to guard to the transfer table against "accidents". Once
>the transfer table is gone (#2) one can immediately do away with the
>version numbers (or change the default setting to "match any".)
>You'll recall that version-number unpleasantness on Vaxcrtl.exe is
>what got us started on this thread originally.

	I disagree, I like being able to make sure that I'm not going to
experience version skew between the pieces of my program.  The reason for the
version change could be changed sematics of some of the entry points, not just
new entry points. Anyway, as you noted, you have control when you build the
sharable on how excat the match has to be.

>
>Wouldn't it be nice to build a shareable with a simple /SHARE,
>no options file and no assembler code?
>

	This is the way it operates on some Unix systems.  I find that our
stuff still has option files.  This is due to the fact that, in general, we do
not want to export *all* of our global symbols.  Unix, by default,
exports all global symbols vs VMS which exports none.  Either way, if you only
want some exported, you have to do some work.