home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / vms / 22247 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  2.8 KB
  1. Path: sparky!uunet!crdgw1!rpi!uwm.edu!linac!att!ucbvax!lrw.com!leichter
  2. From: leichter@lrw.com (Jerry Leichter)
  3. Newsgroups: comp.os.vms
  4. Subject: Re: VAXC divide problems (V3.2)
  5. Message-ID: <9301271830.AA15422@uu3.psi.com>
  6. Date: 27 Jan 93 17:12:27 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Organization: The Internet
  9. Lines: 46
  10.  
  11.  
  12.     ...As I explained in an earlier reply, the subtraction of 4 from the
  13.     stack pointer is for allocation of a local variable for use by the
  14.     VAXC$ESTABLISH condition-handler setup routine.  That's not a
  15.     condition handler itself, but the address of any handler you pass it
  16.     is stored on the stack in the top four bytes, so they actually are
  17.     space for a [pointer to a] condition handler.  The value pointed to by
  18.     the frame pointer is set to a handler inside the C run-time library.
  19.  
  20. All fine so far.
  21.  
  22.     Gruesome details are available in the CRTL portion of the VMS
  23.     listings.  This ugly violation of the VMS Procedure Calling Standard
  24.  
  25. In what way is this a violation of the Procedure Calling Standard?  It is
  26. perfectly legitimate for a procedure to reserve space on the stack for data of
  27. local interest; nothing says that that space has to correspond to variables
  28. visible to the user.  It is perfectly permissible for a condition handler to
  29. make calls to other procedures, basing its choices on locally available data.
  30. That's just what this condition handler is doing; it's no different, in
  31. principle, from having a local variable that indicates what you were trying
  32. to do, and a condition handler that checks that variable to decide what
  33. further action to take.
  34.  
  35.     is for setjmp/longjmp handling, and is inherited from the Pascal
  36.     compiler of all places! ...
  37.  
  38. Actually, I think it's the BASIC compiler (which had to pull the same kind
  39. of trick to implement its user error handling).  Any run-time system that
  40. needs to gain control when frames are unwound off the stack, for any of a
  41. wide variety of reasons, will have to do something of this sort.
  42.  
  43. LIB$ESTABLISH is a low-level tool that provides access to an important
  44. facility that many HLL's don't independently provide.  It has always been
  45. made clear in the standards and the documentation that, if an HLL provides
  46. equivalent facilities, you should use them - and you may HAVE to use them.
  47. Some HLL's (I think BASIC is one, but I'd have to check the documentation;
  48. Ada is almost certainly another) neither allow you to call LIB$ESTABLISH, nor
  49. provide a directly equivalent routine (though the provide other ways to do
  50. the same kind of thing).  VAX C provides VAXC$ESTABLISH, which is a direct,
  51. "plug-compatible" replacement for LIB$ESTABLISH.  What do you find so "ugly"
  52. about it?  (The REAL ugliness is setjmp/longjmp, whose design and interface
  53. were inspired by a particular run-time implementation, and which are just
  54. plain uncomfortable in many otherwise quite reasonable systems.)
  55.  
  56.                             -- Jerry
  57.