Vax macro to Alpha macro

[selahattin okur]

Hello,
We are trying to create .obj of a macro, which is now running on vax/vms V5.5-2H4(vax v4200) , on an alpha vms 7.3(DS20-e).

When I compile the macro on VMS 7.3 I get this :
L2S::RASIT.OKUR>macro /migrat/diagn=a.a/lis pcount

$sfdef
^
%AMAC-E, unrecognized statement
at line number 88 in file DSA0:[ERDEMIR.RASIT.OKUR]PCOUNT.MAR;5

movzbl @sf$l_save_ap(fp),r0
^
%AMAC-E, undefined symbol SF$L_SAVE_AP
at line number 97 in file DSA0:[ERDEMIR.RASIT.OKUR]PCOUNT.MAR;5

.end
^
%AMAC-E, previous errors prevent further analysis
at line number 99 in file DSA0:[ERDEMIR.RASIT.OKUR]PCOUNT.MAR;5
----------------
On vax system in starlet.mlb I can see the the $sfdef with lib/lis command but on VMS 7.3 I couldnt find these entries in mlb.

I am attaching the source of macro and the mlb files.

Thanks in advance.

[Hoff]

This code uses VAX architecture features. Specifically, this code is rummaging around in the VAX call frames, looking at the arguments.

The call frames and the calling standard are among the areas that have seen some of the most significant implementation changes among the architectures.

Start by reading the application porting manuals, if you've not already done so.

Some of the interesting stuff is here:
http://h71000.www7.hp.com/doc/archived.html

Some is here:
http://www.hp.com/go/openvms/doc/

And start with these two documents:
http://h71000.www7.hp.com/doc/82final/5601/aa-pv64e-te.pdf
http://h71000.www7.hp.com/doc/73final/documentation/pdf/ovms_migr_appl.pdf

This code pokes around in the VAX stack frames, which means you'll need to figure out exactly what the code is really doing with the saved argument pointer in the stack frame, and migrate it. There are some LIB$ calls that might be of use here, that allow you to more easily navigate the call frames. But whether you can use those depends on what the code is doing.

PCOUNT.MAR implies you're looking at the program counter (PC), and that sort of thing is specific to the platform. On recent OpenVMS Alpha and OpenVMS I64 versions, there are SDA extensions that can be used to track the PC addresses, as well as traceback and other routines. Put another way, there may well be replacement code available in OpenVMS itself; you may need to rework the existing code to use these routines, rather than the more direct work to re-implement what the code was doing.

[selahattin okur]

Pcount.mar has been used for the parameter count of the subroutine, where pcount itsel has been called.

[Robert Gezelter]

selahattin,

Most likely, MACRO-32 code that dates to VAX/VMS 5.5-2 will require other changes in the declaritives.

The AMACRO compiler is rather strict about what it will allow.

My recommendation is to read the manual on porting VERY carefully, and work through all of the code making the required changes. It is far more frustrating to work one diagnostic at a time.

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

[Jess Goodman · Accepted solution]

You can't call routine B from routine A to get the number of arguments passed to routine A on an Alpha, like you could on a VAX.

Instead you have to use a language extension to get the number of arguments to a routine in that routine itself.

In the routine is in Fortran just use the IARGCOUNT intrinsic. It's return value is the number of arguments of the calling routine:
NARGS = IARGCOUNT()

In C/C++ use:
#include
va_count(nargs);

[Hoff]

Ok. I've unrar'd that archive and had a look at the code. (First time I've seen a rar archive in this corner of the programming universe, too.)

Here's what matters from within the rar...

.entry pcount,^m<>
movzbl @sf$l_save_ap(fp),r0
ret

Here's some related reading...

http://h71000.www7.hp.com/wizard/wiz_6246.html

And here's the detailed and serious reading around the code here...

http://h71000.www7.hp.com/doc/82final/5973/5973pro_004.html#bottom_004

Here's some very serious example source code...

http://www.myths.com/~dpm/vms/her/her.c

Or yes, do use the language-specific constructs for whatever language is in use here. And if you're using a language that has this argument count extension, this approach will be the easiest way.

[John Gillings]

selahattin,

Your pcount routine is the least of your problems! What do you do with the information once you've got it?

Roll-your-own variable argument list processing was fairly simple and reliable on VAX, but it's completely different on Alpha and different again on Itanium. There are lots of things that are likely to break.

You don't say what language you're calling from. Chances are you're going to need to do some rewrites. As others have mentioned, several languages now have native support for variable argument lists. Another option is to declare a fixed argument list, which contains a self describing, variable structure.

(it's a pity that very few language architects seem to have realised that an argument list is really just another data structure)

[Hoff]

>(it's a pity that very few language architects seem to have realised that an argument list is really just another data structure)

In various of the older languages and environments, that's quite true. In the language software I'm working with now, what you can do in this area is, well, staggering. Far past passing argument list data structures around, and far more flexible.

[selahattin okur]

Thanks for all the replies.
I've also found the fortran intrinsic function IARGCOUNT, but we are trying to migrate all the system from vax to alpha with minimum modification.There are so many subroutines and they are really old.
The caller routine is fortran like most of the others.
Thanks again, I will read the documents and give it a try, if I cant succeed, I will use the workarounds.

[Hoff]

When you're porting from VAX to Alpha, always look to get rid of these Macro32 subroutines.

While Macro32 itself is largely portable to OpenVMS Alpha and OpenVMS I64, most folks that wrote Macro32 routines for use with Fortran or similar languages did so for what are usually non-portable reasons. And there are almost always solutions for these reasons that don't involve Macro32.

The other common Macro32 module that folks need to deal with when porting are the transfer vectors for a shareable image, and that too requires conversion out of Macro32.