home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!ukma!usenet.ins.cwru.edu!agate!ucbvax!EQL.Caltech.Edu!rankin
- From: rankin@EQL.Caltech.Edu (Pat Rankin)
- Newsgroups: comp.os.vms
- Subject: Re: VAXC divide problems (V3.2)
- Message-ID: <930126214249.21c07f31@EQL.Caltech.Edu>
- Date: 27 Jan 93 05:47:20 GMT
- Sender: usenet@ucbvax.BERKELEY.EDU
- Organization: The Internet
- Lines: 32
-
- >>> subl2 #4,sp
- >>>Don't ask me why it allocated space on the stack without using it,
-
- >>I think the stack space is for the condition handler.
-
- > Think again. The subl2 is obviously for the variable i which is
- > allocated on the stack. [...]
- >
- > It seems that the compiler didn't "notice" that it didn't use the
- > space it put asside on the stack for i. This has obviously nothing
- > to do with a condition handler.
-
- Nope. As I explained in an earlier reply, the subtraction of 4
- from the stack pointer is for allocation of a local variable for use
- by the VAXC$ESTABLISH condition-handler setup routine. That's not a
- condition handler itself, but the address of any handler you pass it
- is stored on the stack in the top four bytes, so they actually are
- space for a [pointer to a] condition handler. The value pointed to by
- the frame pointer is set to a handler inside the C run-time library.
- Gruesome details are available in the CRTL portion of the VMS listings.
- This ugly violation of the VMS Procedure Calling Standard is for
- setjmp/longjmp handling, and is inherited from the Pascal compiler
- of all places!
-
- You can easily verify this by exploring with the debugger. Or even
- simpler for the case in question, either compile with /nooptimize or
- declare `i' to be volatile and you'll discover that 8 bytes are allocated
- on the stack instead of 4, and `i' uses the 2nd longword. The compiler
- didn't forget that it had moved `i' into a register.
-
- Pat Rankin, rankin@eql.caltech.edu
-
-