home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / fortran / 4415 < prev    next >
Encoding:
Text File  |  1992-11-23  |  1.7 KB  |  39 lines

  1. Newsgroups: comp.lang.fortran
  2. Path: sparky!uunet!pgroup!lfm
  3. From: lfm@pgroup.com (Larry Meadows)
  4. Subject: Re: ENTRY in main (was re: Jumping from nested subroutine)
  5. Message-ID: <By6Ast.BA1@pgroup.com>
  6. Date: Mon, 23 Nov 1992 14:26:53 GMT
  7. References: <By4xpo.FG@iapa.uucp%mailhost.ecn.uoknor.edu> <1992Nov23.114807.4734@monu6.cc.monash.edu.au>
  8. Organization: The Portland Group, Portland, OR
  9. Lines: 28
  10.  
  11. Well, I can't resist...
  12.  
  13. What the original poster wants is called non-local GOTO in pascal, and
  14. setjmp/longjmp in C.  In either case, the return stack is unwound to
  15. the invocation record of the function to which control is being returned.
  16. In pascal this is the function containing the label to which control
  17. is being transferred; in C, it is the function that called setjmp.
  18.  
  19. Ordinarily, unwinding the stack consists of restoring the stack pointer,
  20. possibly the frame pointer; then, control transfer is performed by loading
  21. the program counter (i.e., performing an indirect branch).  Machines
  22. with register windows are more complicated; I'm sure someone can tell us
  23. exactly how it is done on the Sparc.
  24.  
  25. So, anyway, it should be possible to call setjmp and longjmp from fortran,
  26. assuming they exist on the original poster's system.  Problem is, they
  27. would need fortran entry points, since wrapping a C function around
  28. the original setjmp/longjmp won't work (setjmp must be called from the
  29. function to which control is to return, then that function must not return
  30. before longjmp is called).  If fortran entry point's don't exist, I'd
  31. be inclined to hack the object to create them.
  32.  
  33. Of course, the ability to do all this is entirely system dependent.
  34.  
  35. Good luck.
  36. -- 
  37. Larry Meadows        The Portland Group
  38. lfm@pgroup.com
  39.