Operating System - OpenVMS
1748177 Members
4242 Online
108758 Solutions
New Discussion юеВ

Re: problem porting macro-32 code

 
Hein van den Heuvel
Honored Contributor

Re: problem porting macro-32 code



"1. is it now possible to get the initial and current mailbox message quota of a mailbox without going into kernel mode code"

Check out the comp.os.vms newsgroup
Rob Brooks (VMS Engineering) just requested suggestions for new getdvi item codes.

At this time the item is not yet visibile through google groups, but in an hour or so try:

http://www.google.com/groups?as_q=getdvi&as_ugroup=comp.os.vms&as_drrb=q&as_qdr=d&lr


hth,
Hein.
Ian Miller.
Honored Contributor

Re: problem porting macro-32 code

I will move the lock/unlock macros and see. I've emailed Rob Brooks.
____________________
Purely Personal Opinion
Ian Miller.
Honored Contributor

Re: problem porting macro-32 code

after a quick play last night I've found that if I use a stack based argument list to sys$cmkrnl then things behave better - no crash and meaningful data!
So the invalid exception bugcheck was something to do with accessing the statically allocated arglist.

Can somebody explain what homing arguments is about. I get a informational message about
@8(ap)in getbuf_k that this requires homed arguments in the calling routing. It appears to work but I wondered what the informational message is trying to tell me.
____________________
Purely Personal Opinion
John Gillings
Honored Contributor

Re: problem porting macro-32 code

Ian,

On Alpha the emphasis was on speed, so the calling standard defined argument passing to be done in registers, rather than the memory based mechanism used on VAX. So, the first 6 arguments are found in R16 through R21 (or, if floating point by immediate value, F16 through F21). If there are more than 6 arguments, the extras are passed on the stack.

However, there are some things you may want to do with an argument that won't work on registers. Your case "@8(AP)" is one example because you're taking an offset from the argument pointer. Another is passing an entire argument list to another routine:

CALLG (AP),G^AnoterRoutine

To achieve this, you need to "home" your argument list. It's really just copying the arguments to a stack based structure. It's easy to do, just add the clause "HOME_ARGS=TRUE" to your .CALL_ENTRY definition. This isn't done automatically because it's overhead that won't be necessary for the common cases (Alpha philosophy, don't do *anything* unnecessary).

Another option is to replace @8(AP) with (R17), but that will make your code Alpha dependent (it's possible the compiler is already doing what you mean - you're getting the informational to warn you to check the generated machine code to ensure it's really is doing what you want).

John Gillings
A crucible of informative mistakes
Ian Miller.
Honored Contributor

Re: problem porting macro-32 code

John - thanks for the explaination. I am using the home_args=TRUE. getmbx appears to work fine so I've updated for VMS V7.3-1 change (mailbox quota can be in a different longword location) and am now working on setmbx.
____________________
Purely Personal Opinion