fortran calling macro

[JDuck]

I am moving code from a VAX to Itanium. When the fortran code calls a subroutine written in macro it crashes giving an access violation. This appears to be associated with the AP or writting to R0. I have attached a test program that demonstrates the problem

Thanks

[John Reagan]

Didn't you get an -I- message from the Macro compiler for your modification of the AP register?

I received:

%IMAC-I-APTEMPUSE, AP used as a temporary register is converted to R12 in routine DOIT

There is no AP register on Itanium. Your code's use of the auto-increment addressing mode forced us to reassign AP from its semantic meaning of the "arglist" to some scratch register.

Change the:

movl (ap)+,r0

into

movb (ap), r0

John

[JDuck]

Thanks
I got the -i- message but since it was info I didnt think it would be a problem. I read that AP was reassigned to r12. the code you sent did work. how do i increment to get to the next passed argument.

incl r12?
incl ap?

John

[Ian Miller.]

the next argument will be 4(AP).
Best not increment AP

[Ian Miller.]

To quote from the MACRO32 porting manual
[http://h71000.www7.hp.com/doc/82final/5601/aa-pv64e-te.pdf]
"If a VAX MACRO source is
referencing AP as a scratch register, the compiler converts this reference to a
reference to R12. If this is not desirable, you should change the code to use a
different scratch register."

[Ian Miller.]

I think if you do change the code to copy AP to another register then the MACRO compiler will home the argument list. See section
2.4.1 Homed Argument Lists

http://h71000.www7.hp.com/doc/82final/5601/aa-pv64e-te.pdf

[John Reagan]

If you do something like

movab (ap),r6

we'll notice you take the address of the argument list. You can also put the HOME_ARGS=TRUE on the .CALL_ENTRY directive (you should read the Macro Compiler user manual from the docset).

Once the compiler sees the MOVAB or HOME_ARGS, we'll home the argument list to memory to make it look like a VAX. On Itanium, the first 8 arguments are inside of 64-bit wide registers and the remainder of the arguments are in 64-bit wide argument slots. The compiler will copy them all into a 32-bit array to make the arguments look like they do on the VAX. That is the address you'll get with the MOVAB instruction above.

[John Reagan · Accepted solution]

Just for completeness...

I was sent a larger example via email.

MOVL (AP)+,R0 ; POP THE ARGUMENT COUNT INTO R0
MOVL (AP)+,R0 ;ADDRESS OF THE INPUT BUFFER
ADDL2 #24,R0 ;POINT DIRECTLY TO THE DATA BUFFER
MOVL (AP)+,A ;LOAD UNIT NUMBER ADDRESS
MOVL (AP)+,C ;LOAD PAYROLL NUMBER ADDRESS
MOVL (AP)+,D ;LOAD PERSONNAL PASSWORD ADDRESS
MOVL (AP)+,E ;LOAD SYSTEM PASSWORD ADDRESS
MOVL (AP)+,F ;LOAD SHOP NUMBER ADDRESS

The code is reading arguments by incrementing the AP register and walking down the list.

While the AP is a real register on VAX, it is an abstract concept created by the compiler on Alpha and Itanium. Section 2.4.3 in the HP MACRO Compiler Porting and User's Guide talks about this non-portable practice.

A revised sequence would be something like:

MOVL 4(AP),R0 ;ADDRESS OF THE INPUT BUFFER
ADDL2 #24,R0 ;POINT DIRECTLY TO THE DATA BUFFER
MOVL 8(AP),A ;LOAD UNIT NUMBER ADDRESS
MOVL 12(AP),C ;LOAD PAYROLL NUMBER ADDRESS
MOVL 16(AP),D ;LOAD PERSONNAL PASSWORD ADDRESS
MOVL 20(AP),E ;LOAD SYSTEM PASSWORD ADDRESS
MOVL 24(AP),F ;LOAD SHOP NUMBER ADDRESS

There is no actual need to increment/modify the AP register just to fetch the fixed number of arguments. The compiler will do the right thing and location each argument regardless of whether is came in via a register or on the memory stack. No argument homing is needed.

[JDuck]

thanks to all
the ap has been changed to not inc
.call_entry used

found that one routine was using rsb
instead of ret

code is working now

thanks

John