home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / vms / 22144 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  6.6 KB
  1. Path: sparky!uunet!ukma!usenet.ins.cwru.edu!agate!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: <9301280442.AA02004@uu3.psi.com>
  6. Date: 28 Jan 93 03:41:13 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Distribution: world
  9. Organization: The Internet
  10. Lines: 126
  11.  
  12.  
  13.      >>Gruesome details are available in the CRTL portion of the VMS
  14.     >>listings.  This ugly violation of the VMS Procedure Calling Standard
  15.  
  16.     > In what way is this a violation of the Procedure Calling Standard?
  17.     > It is perfectly legitimate for a procedure to reserve space on the
  18.     > stack for data of local interest; nothing says that that space has
  19.     > to correspond to variables visible to the user.
  20.  
  21.     That won't wash.  The violation is in VAXC$ESTABLISH, which will
  22.     clobber the top of your stack if you haven't allocated the
  23.     undocumented hidden variable for it.  It mungs its _caller's_ stack;
  24.     that's completely different from extra stack space being used by the
  25.     current procedure.
  26.  
  27.     Alternatively, your own code can clobber the saved handler address,
  28.  
  29. Your own code cannot touch the saved handler address unless it uses and
  30. invalid pointer.  It could just as easily clobber the handler address at
  31. (FP).
  32.  
  33.     which in turn can result in an ACCVIO inside VAXCRTL for non-longjmp
  34.     conditions.  The documentation for VAXC$ESTABLISH states that it is
  35.     only usable from code compiled by VAX C because that particular
  36.     compiler allocates stack space for its use, but it still violates the
  37.     procedure calling standard.
  38.  
  39. It is perfectly legitimate for a procedure in a language support RTL to make
  40. assumptions about the environment compiled code will set up for it.  Try
  41. calling one of the routines that implements formatted I/O in FORTRAN without
  42. setting up the appropriate environment.
  43.  
  44. LIB$ESTABLISH also modifies its caller's stack frame.  In fact, the only
  45. difference between LIB$ESTABLISH and VAXC$ESTABLISH is in the addressing
  46. mode of one instruction.  Do you also claim that LIB$ESTABLISH is in violation
  47. of the Standard?
  48.  
  49. In many languages, you NEVER call language support RTL routines directly;
  50. the compiler generates all the calls.  In C, because of its extreme low level,
  51. just about all calls have to be visible to the user.
  52.  
  53. Calling internal FORTRAN support routines is not supported, except in code
  54. generated by the FORTRAN compiler.  (That's not to say it can't be made to
  55. work.)  Calling VAXC$ESTABLISH is not supported outside of code generated by
  56. the VAX C compiler (although again it can be made to work).  I see no signi-
  57. ficant difference, and I see no violation of the calling standard.  Would it
  58. have made you happier if, instead of a documented VAXC$ESTABLISH routine,
  59. VAX C had defined a new statement, say establish <handler>, which turned into
  60. just such a call?
  61.  
  62.     >                      It is perfectly permissible for a condition
  63.     > handler to make calls to other procedures, basing its choices on
  64.     > locally available data. That's just what this condition handler is
  65.     > doing; it's no different, in principle, from having a local variable
  66.     > that indicates what you were trying to do, and a condition handler
  67.     >  that checks that variable to decide what furtheraction to take.
  68.  
  69.          That would be true if such usage didn't interfere with user code.
  70.     Try calling VAXC$ESTABLISH from code compiled by some other compiler
  71.     sometime (recent releases of GCC excepted), then tell me that it isn't
  72.     violating the procedure calling standard.
  73.  
  74. Try calling the Ada RTL routines that manage tasking from some code written in
  75. some other language.  In fact, I'll bet that if you name any language RTL, I
  76. can find some routine in it that, if called from another language, will cause
  77. quick failure.  So?
  78.  
  79. As for GCC:  It's really too damn bad for GCC that, when it tries to make use
  80. of the VAX C RTL, it has to play by the rules.  The VAX C RTL was written to
  81. support the VAX C compiler.  It owes absolutely nothing to the writers of
  82. GCC.
  83.  
  84.     >>is for setjmp/longjmp handling, and is inherited from the Pascal
  85.     >>compiler of all places! ...
  86.  
  87.     > Actually, I think it's the BASIC compiler (which had to pull the
  88.     > same kind of trick to implement its user error handling).
  89.  
  90.          My post was not based on speculation; check the source listings.
  91.     They took the implementation from Pascal's GOTO handler.  Perhaps the
  92.     Pascal implementation was derived from BASIC's, but if so, the C code
  93.     doesn't mention it.
  94.  
  95. What can I tell you; my understanding was that the technique of using stack
  96. unwinding as it is done in VAX C was first developed for BASIC.  Good
  97. solutions to hard problems get re-used.  BASIC's needs are somewhat different,
  98. so I can't say I'm shocked that the actual code came from Pascal.
  99.  
  100. Look, let's back off and look at the bigger picture for a moment.  The C
  101. language brings with it two features - well, one is just a common abuse of
  102. the language - that are in and of themselves incompatible with the VAX
  103. Procedure Calling standard:
  104.  
  105.     1.  Functions view their arguments as a block of successive values
  106.         which they can step through - and modify.  Without the
  107.         overhead of copying values around, this results in generated
  108.         code that modifies the values pointed to by AP, a practice
  109.         once strictly prohibited by the Calling Standard:  That data
  110.         belongs exclusively to the caller.  A field test version of
  111.         VAX C (I think V3.0) tried to obey the calling standard
  112.         strictly:  When the address of any argument was taken, the
  113.         argument was re-bound to a new stack location, and the value
  114.         passed in the argument block was copied on procedure entry.
  115.         Such an implementation is completely consistent with both
  116.         K&R and ANSI C, as well as with the Standard.  However, so
  117.         many customers objected that it broke their code that the
  118.         change was backed out before the final version of the compiler
  119.         and never tried again.  Instead, VAX C was given a waiver
  120.         from this requirement of the Standard.  It causes grief for
  121.         mixed FORTRAN/C programs to this day.
  122.  
  123.     2.  setjmp/longjmp simply cannot be implemented strictly within the
  124.         Calling Standard.  The old "just pop the stack pointer back
  125.         to where it was" approach is absolutely a violation.
  126.  
  127.         Rather than bitch about the "horrible" way this is done, would
  128.         you like to suggest an implementation that will (a) conform
  129.         to the ANSI definition; (b) conform to the Procedure Calling
  130.         Standard; (c) behave rationally in a mixed language environ-
  131.         ment, where there may be stack frames for code created by
  132.         several different compilers arbitrarily mixed on the stack
  133.         between the frame where the longjmp takes place and the frame
  134.         it will end up in?  If you can, I, for one, would be quite
  135.         interested in seeing it.
  136.                             -- Jerry
  137.  
  138.