RE: Compile and gone! (Was: Re: VMS>7.3 Linker Manual - I64 Short Data restriction)



Hi John,

Quick update: -

I take back a good half of the SHORT DATA whinge! Tried to build the system
again on 8.3 with the latest BASIC compiler and the short data stuff came in
at 2.7MB and plenty of head-room to grow. (Image size still 0.5GB, but what
can you do :-)

Don't know what happened between 8.1 and 8.3 with the Linker or whether
BASIC got less agressive in it's short data annexing but who cares?

Cheers Richard Maher

PS. If the thing actually runs (and the regression testing works out) I
might even take back some of the other 1/2 :-)

Date: Tues, Aug 8 2006 8:33 pm

Hi John,

Thanks for the very detailed response. Doesn't look good does it.

Is your application in COBOL?


No, it's BASIC. The plans were put in place at this site over a year ago to
break the uber-image up into "n" shareable images but I was hoping that if
there was any justice in the world then something would've changed between
8.1 and 8.3 to make bypassing the Short_Data segment possible :-(

I find it difficult in these circumstances to argue against the shameless
Charon-Alpha reseller! Why don't HP just keep smacking VMS users over the
head until they finally wake up and smell the coffee? If you have to
completely re-engineer your application to upgrade to an unproven,
longevity-suspect boat-anchor then why don't you put that migration money
into something with a future?


I personally dislike JF banging-on about that "IA64 Thing", but I tell ya
it's starting to grow on me.


Dear God in heaven please let John have a refreshing holiday and bring him
back safe to start porting MACRO to 8086,I32,Pentium7 whatever it is!


Cheers Richard Maher



"John Reagan" <john.rea...@xxxxxx> wrote in message


news:DBIBg.1639$sx1.741@xxxxxxxxxxxxxxxxxxx


- Hide quoted text -
- Show quoted text -

Richard Maher wrote:
Hi,

When could one expect to see a new version of the Linker Utility
Reference
Manual available with VMS. The one on the Web and Doc CDs appears to be
VMS
7.3 April 2001. All the I64 stuff I've seen is in one of the 8.2 New
Features Manual (Which would make sense if 8.2 was the first supported
itanium version :-) but are we gonna get a new set with 8.3?


Yes, an updated linker manual comes with 8.3.


Also, Can anyone shed any light of possible solutions/work-arounds to
the
4MB limit on this Short Data segment thing? (Something other than "Your
app's crap - re-engineer it!" would be nice :-)


In general, filling up the 4MB short section results from compilers
asking for too many address constants. Although the short section also
contains linker-created function descriptors and static user data 8
bytes or smaller.


As background, on Alpha, each routine is passed a routine-unique pointer
to the "linkage" section which contains its procedure descriptor and all
the compiler requested address constants. While there isn't a hard
limit, the downside is that if multiple compilations need the same
address, there are many copies in the final image. On I64, the
compilers don't allocate space for address constants, but request that
the linker materialize the address for them. It makes the linker more
complicated, but it also allows the linker to remove duplicates.


By convention (we didn't 'invent' the convention, it comes from the
Intel Run-Time Conventions), this linker-created section of address
constants (and function descriptors, etc.) is shared by the whole image.
Each routine has the address of this "short" section passed in R1.
The short section is accessed with the following instructions:


; Add offset from R1 to the location where the linker
; allocated the address. This form of the 'add' instruction
; is defined to be:
; add Ra = imm22, Rb
; where Rb must be either R0, R1, R2, or R3.
;
; When the compiler generates the instruction, it usually
; puts a 0 in the 22-bit literal and issues a relocation.
; The relocation tells the linker to create an address to
; SYM, allocate it in the short section, and modify the
; immediate operand of the instruction to have the offset
; from R1 to the allocated address.
;
add Rn = @ltoff(SYM), R1


; Now that we have the address of the address, fetch it
;
ld8 Rn = [Rn]


; We can now fetch the static data. It might be something
; readonly like a linker-materialized address or it might
; be some user variable (8 bytes or smaller).
;
ld8 Rn = [Rn] ; fetch an 8-byte 'thing'


Specifically what, if anything, does the Option File command
"SHORT_DATA=NO"
do for us? (Latent support only?)


Doesn't do anything for you.


I have seen the /SEGMENT=(Short_data=WRITE) but another 65K is not gonna
help us and it would be could to avoid any behavioural changes where
possible.


You can also try /SEGMENT=SYMBOL_VECTOR=NOSHORT (if you creating a
shareable image), avoid /NONATIVE_ONLY (it makes function descriptors
larger), and avoid pulling code sections from the default cluster.
However, I wouldn't expect much help from any of these.


There seems to be a fair sprinkling of discussions on the web (Some with
Linux and Windows) but it seems to come down to the compiler having to
do it
or you're stuffed?


Will PSECT_ATTR=data,NOSHORT never be allowed?


Can we not CLUSTER/COLLECT out of the SHORT segment hand have the Linker
fix
up the "little" address references to real 32-bit ones?


As you can see from my description above, the compiler generated code
with explicit knowledge that the data in question (user static data or
linker-created addresses/FDs) can be found from an offset from R1. If
you tell the linker not to put that PSECT "near" R1, the code cannot
possibly reach it.


Given the model used, on I64 you can compile all your modules without
any guarantee that you can combine them into one applications.


Right now, I'm working on a COBOL issue where it generates address
constants for code labels to use with the PERFORM statement. I have two
customers who cannot link due to this. I have prototype COBOL compiler
read for testing by one of the customers now. I'm off for a 3 week
absense [2-wks vacation, 1-wk business trip]. I'll finish it when I'm
return.


Now, for those of you who have read the Itanium ELF ABI to see the
complete list of relocations defined, you might notice a handful of
relocations that would let the linker fill in the 64-bit literal of a
'movl' (move with long literal) instruction. Such a relocation would
eliminate the 22-bit (4MB) short section by just not having a short
section. However, the compilers would have to generate different code
and the linker would have to implement them. I don't believe that any
Itanium linker (Windows, Linux, HP-UX, OpenVMS) implement the larger
relocations or do any compilers produce them. It makes the code quite
position dependent and would require a $h!t load of image activation
time relocations especially for shareable images built that way!


Is your application in COBOL? Other than COBOL, I've yet to see an
application that won't link on OpenVMS I64. Of course, knowing the
above information, it would be trivial to hand-construct (well,
machine-construct) an application that wouldn't link.


--
John Reagan
HP Pascal/{A|I}MACRO/COBOL for OpenVMS Project Leader
Hewlett-Packard Company






.