- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: problem porting macro-32 code
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-05-2004 03:11 AM
тАО05-05-2004 03:11 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-05-2004 11:03 PM
тАО05-05-2004 11:03 PM
Re: problem porting macro-32 code
Purely Personal Opinion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-06-2004 08:17 PM
тАО05-06-2004 08:17 PM
Re: problem porting macro-32 code
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-09-2004 04:03 PM
тАО05-09-2004 04:03 PM
Re: problem porting macro-32 code
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-09-2004 08:50 PM
тАО05-09-2004 08:50 PM
Re: problem porting macro-32 code
Purely Personal Opinion
- « Previous
-
- 1
- 2
- Next »