topic Re: IA64 in Operating System - OpenVMS

IA64

MJ26 — Mon, 15 Nov 2010 12:57:50 GMT

Does anyone know of any good .pdf's or websites that explain Vector Tables and how to program with them? I have a macro that was written on Alpha, and will not port over to IA64 successfully. I am looking around the web, and cannot find too many helpful readings. We can rewrite the MACRO if necessary in FORTRAN or in C (if thats possible). Thanks!

Re: IA64

Hoff — Mon, 15 Nov 2010 14:59:32 GMT

I'm going to make assumptions and guesses around your intended question, and around just what you mean by "vector table" here, and presume that this is a question on porting a Macro32 shareable image transfer vector module from OpenVMS VAX over to the mechanisms used on OpenVMS Alpha and OpenVMS I64. If so, then start reading here:

http://labs.hoffmanlabs.com/node/163

If that's not the particular "vector table" you're referring to, then please post a hunk of the Macro32 code involved; some additional background, context, and a reproducer.

Re: IA64

abrsvc — Mon, 15 Nov 2010 15:46:55 GMT

You indicate that this macro code was written on the Alpha. If the code is Macro64, tehn it will need to be re-written. Post a snippet here and we shouldbe able to guide you.

Dan

Re: IA64

MJ26 — Mon, 15 Nov 2010 17:36:39 GMT

$TY PAALGI_VECTOR.MAR
.title lgi$loginout_callouts - data transfer vector holder definition
.ident /v1.4/

lgi$loginout_callouts::

.long 9
.address paalgi_init
.long 0
.address paalgi_decwinit
.address paalgi_identify
.address paalgi_authenticate
.long 0
.long 0
.address paalgi_logout
.long 0

.end

Re: IA64

Hoff — Mon, 15 Nov 2010 18:13:11 GMT

Ah, OK.

So you need help declaring a VMS data structure.

For this case, I'd probably use the declarations that are present in LGIDEF, but that's your call.

Here's the data structure definition you're working with:

http://h71000.www7.hp.com/doc/731final/4493/4493pro_038.html

The necessary declarations are present in Macro32 library, in the Bliss library, and in the C library. Probably in various other language definition libraries, too.

Here's how to get a look at the C struct declaration:

$ lib sys$share:sys$lib_c.tlb/extr=LGIDEF/out=lgidef.h

Here's an introduction to C programming on VMS, and which includes a discussion of SYS$LIB_C.TLB:

http://labs.hoffmanlabs.com/node/273

Whomever coded that Macro32 module didn't do it using the system declarations (no big deal); that'd normally be a block buffer declaration (.blkb, probably) and then the Macro32 symbolic offsets from LGIDEF module. (There's no macro declaration, so what was done with that Macro32 code is functional.)

To that end, there are examples of referring to the *DEF modules in various Macro32 examples, including here:

SYS$EXAMPLES:LAT$RATING_DPT.MAR
SYS$EXAMPLES:PREFER.MAR

Those show DEF declarations, and the rest of the stuff.

.blkb LGI$S_LGIARG_VECTOR

I'd guess that the Macro32 compiler error you're hitting is related to a (missing) PSECT declaration, but I'd need to run a build on an Itanium to confirm that. Probably something like:

.PSECT $RWDATA,RD,WRT,NOEXE,NOSHR

needs to be added ahead of the declarations. But without an Itanium box and without the diagnostics, the specific error isn't clear. (That code should still build, so there's probably something pretty simple wrong with it.)

Here's an introduction to Macro32 programming on VMS:

http://labs.hoffmanlabs.com/node/1435

Re: IA64

Jess Goodman — Mon, 15 Nov 2010 18:24:48 GMT

Offhand, I can not see why that macro code would not work on IA64. But it is possible to use C for LOGINOUT callouts, at least on VAX and Alpha, and I would hope that there is not a general problem with LGI callouts on IA64.

See the C code example attached to my response in this thread:

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1182554

Re: IA64

abrsvc — Mon, 15 Nov 2010 20:48:50 GMT

My first suspicion is that the addresses are unaligned. Using the library offsets rather than specific ".long" directives etc. should resolve the problem. The offsets will create an exceptable structure and should work on both Alpha and I64 without change.

Dan

Re: IA64

Robert Gezelter — Mon, 15 Nov 2010 22:19:37 GMT

MJ26,

First, welcome to the HP ITRC OpenVMS Forum.

So that we can understand precisely what is happening, it would be extremely helpful if you could post the precise error message that you are encountering.

An alignment problem can be addressed directly by properly aligning the PSECT or by using the .ALIGN macro directive.

More information would be extremely useful.

- Bob Gezelter, http://www.rlgsc.com

Re: IA64

Hein van den Heuvel — Tue, 16 Nov 2010 00:57:57 GMT

>> I have a macro that was written on Alpha, and will not port over to IA64 successfully.

Please show use how you come to that conclusion.

The macro you present compiles to the exact same definitions/psects/references/aligment on Alpha as on Itanium. For yucks I tried using "AMAC V5.0-120" and "IMAC V5.0-120-4". They both generate a Psect: . BLANK . 00000028 (00040.) 01 (001.) NOPIC CON REL LCL NOSHR EXE RD WRT
Now as Hoff says, those Psect attribute may no longer be appropriate.

Have you read Jess's reply carefully? You only awared it 5-points suggesting it did not help, yet he points to a rather complete and working example.

Good luck!
Hein

Re: IA64

abrsvc — Tue, 16 Nov 2010 11:51:37 GMT

For clarity in regards to my alignment statement. I wonder if the structure has changed in appearance slightly with the upgrade to I64 such that the "spacing" between elements is no longer as described in the macro definition presented. Using the symbolic offsets ususally prevents this type of problem.

The C solution is perhaps the best though.

Dan

Re: IA64

MJ26 — Tue, 16 Nov 2010 12:10:43 GMT

First, I want to say to Jess, sorry I gave you 5 pts. Please post a blank message and I will assign you more as you have provided a great example. Somehow, I missed it. I did not see the attachment.

Second.....here is what I have coded so far using C based on Jess's example. My next question is if I have all of the paa routines defined in seperate .mar files, is it possible to point to those from this file?

I'm still trying to grasp the concept of vectors, so please be kind :) I assumed that my first .mar file (that I posted first) was pointing to a specific .address in memory to where the associated paa procedures were located. In the "C" code, I do not see where this is happening.

Any thoughts would be great. Thanks!

Re: IA64

MJ26 — Tue, 16 Nov 2010 12:11:08 GMT

/*
** INCLUDE FILES
*/
#include
#include
#include
#include
#include
#include
#include

/* System service calls */
int SYS$ASSIGN();
int SYS$QIOW();
int SYS$DASSGN();

/* Define structure for the callout routines vector */
struct LGI$CALLOUT_VECTOR {
long int LGI$L_ICR_ENTRY_COUNT;
int (*LGI$ICR_INIT) ();
int (*LGI$ICR_IACT_START) ();
int (*LGI$ICR_DECWINIT) ();
int (*LGI$ICR_IDENTIFY) ();
int (*LGI$ICR_AUTHENTICATE) ();
int (*LGI$ICR_CHKRESTRICT) ();
int (*LGI$ICR_FINISH) ();
int (*LGI$ICR_LOGOUT) ();
int (*LGI$ICR_JOBSTEP) ();
};

/* Declare the callout routines that we define below. */
static int paalgi_init();
static int paalgi_decwinit();
static int paalgi_identify();
static int paalgi_authenticate();
static int paalgi_logout();

#pragma nostandard
globaldef struct LGI$CALLOUT_VECTOR LGI$LOGINOUT_CALLOUTS =
{
9, /* argument count */
paalgi_init, /* general login init */
NULL, /* interactive start - initialized */
paalgi_decwinit, /* decwindows init */
paalgi_identify, /* identify - filled in if interactive */
paalgi_authenticate, /* authenticate - filled in if dialup */
NULL, /* check restrictions */
NULL, /* login finish */
paalgi_logout, /* logout */
NULL, /* each batch jobstep */
};

static int paalgi_init()
{
}
static int paalgi_decwinit()
{
}
static int paalgi_identify()
{
}
static int paalgi_authenticate()
{
}
static int paalgi_logout()
{
}

Re: IA64

MJ26 — Tue, 16 Nov 2010 12:19:30 GMT

The other files:

paalig_init.for
paalig_decwinit.for
paalig_identify.for
paalig_authenticate.for
paalig_logout.for

are already compiled and added into the shared images.

Thought that might help.

Re: IA64

Hein van den Heuvel — Tue, 16 Nov 2010 13:23:15 GMT

>> In the "C" code, I do not see where this is happening.

It is not happening. In that C example the LGI vector is filled in with pointers to local routines.

But we now learned that you have the service routines in independent fortra mondule.
The Macro module was, and is, just fine for that.
The .address instructs the LINKER to fill in a reference to routine which eventually the Image Activator will make real.

Isn't it about time you start to describe what went wrong, instead of what it right?
An error message perhaps?
There is a second vector in play, the transfer vector used to build the shareable.

My WAG is the problem is in the linking of the shareable or the logical name defined.

>> Jess, sorry I gave you 5 pts.
And I am sorry for reading too much into that.

Regards,
Hein.

Re: IA64

Robert Gezelter — Tue, 16 Nov 2010 13:41:36 GMT

MJ26,

Concerning your post at 12:10:43 GMT today:

A vector is simply a list of addresses. What the MACRO code does is define a set of longword (32-bit) locations that will contain pointers to the actual locations of the identified routines.

The MACRO assember/compiler (MACRO in the case of VAX; AMACRO compiler for Alpha; IMACRO in the case of IA64) will produce two outputs: the actual storage locations and a list (for the linker) of the external names that are to go into those locations).

When LINK is used to combine the object modules, the address locations will, in concept, be resolved. Actually, they will produce another list, to be used by the image activator when the image is actually loaded into memory (this is one of the foundation concepts behind shareable libraries; the actual locations of external addresses can vary from activation to activation).

While the actual addresses of entry points can change, the vectors (the address of the address) remains unchanged.

The details of this can be found in the internals and data structures manual. A simplified version can be found in the LINKER reference manual. The IDSM is available as a book; the LINKER manual is available from the documentation section of the OpenVMS www site as a PDF.

- Bob Gezelter, http://www.rlgsc.com

Re: IA64

Jess Goodman — Tue, 16 Nov 2010 19:26:49 GMT

I believe the attached C code may serve your needs, although I have not tested it on either Alpha or I64. Build it into the shared image along with your macro routines that it references.

Jess

Re: IA64

H.Becker — Tue, 16 Nov 2010 19:27:20 GMT

While the real probelm is still unknown, we can waste some space and time to get some background information right.

>>> The .address instructs the LINKER to fill in a reference to routine which eventually the Image Activator will make real.

The linker does not see the .address: (the) MACRO (-compiler) turns that into an undefined symbol and an object relocation, because the actual address in or the offset within the image is unknown to (the) MACRO (compiler). In case the symbol is defined in another object module, which is linked into the image, the linker knows where the procedure is and resolves the undefined symbol and applies the object relocation. In terms of the source code, the linker writes the actual address of the prodecure in the data structure. In case the symbol is defined by a universal symbol from a shareable image, the linker doesn't know the procedures's address but resolves the undefined symbol and creates a fixup. The latter may be seen as a "reference". However, the fixup itself has no information whether it is for a routine or data. When the address is known, at image activation time, when for all the involved images their address space is known, the Image Activator applies the fixup, In terms of source code, the Image Activator writes the actual address of the procedure in the data structure.

>>> Actually, they will produce another list, to be used by the image activator when the image is actually loaded into memory.

The Image Activator does not load anything. I'm sure it would have been named loader instead. The Image Activator sets up the virtual address space of all the involved images: one main image and zero to many shareable images. This is usually named as mapping the images, although there is not much actual mapping done. The Image Activator assigns VAs to all the program segments (I64 term) or image sections (Alpha term). These things can be file based, global, demand zero, or pagefile VMS sections. These VMS sections are mapped, when there is real memory associated with the section. Only those sections which are touched at activation time are mapped. The section in which the source code data structure ends up is mapped, when the fixup has to be made. (Obviously it is a pagefile section.) Anything else is NOT in memory especially code and readonly data are not "loaded" into memory. That happens at run-time, that is AFTER activation.

Re: IA64

Jess Goodman — Tue, 16 Nov 2010 19:33:29 GMT

Sorry, cut and paste error - last attachment won't compile. Use this one.

Jess

Re: IA64

Robert Gezelter — Tue, 16 Nov 2010 20:31:38 GMT

Herr Becker,

I well know that the Image Activator sets up the address space and that it does not do the actual loading.

My goal was to explain as simply as possible what is going on. Obviously, the OP is not familiar with the mechanics of resolving external symbols. In all honesty, I have often found the descriptions of external symbol resolution accurate, yet not within the easy grasp of those encountering it for the first time.

- Bob Gezelter, http://www.rlgsc.com

Re: IA64

MJ26 — Wed, 17 Nov 2010 15:48:16 GMT

Thanks EVERYONE for who has taken the time to assist. I will try the various methods to see if I can get something to work successfully. I won't close the discussion until its resolved, and when that happens, I will also put the resolution on here as well. Granted, its possibly a 1 off question, but still, might be handy for someone else.

Again, thanks everyone for the help. This board is very helpful because of the level of expertise here.