From:	AITGW::"MACRO32@WKUVX1.BITNET" 23-MAR-1992 12:49:28.74
To:	MACRO32@WKUVX1.BITNET
CC:	
Subj:	Re: Interesting trick with AST routines.

Received: by AITGW.DECnet (utk-mail11 v1.5) ; Mon, 23 Mar 92 12:48:25 EST
Received: from ukcc.uky.edu by aitgw.ge.com (5.65/GE Gateway 1.5)
	id AA22034; Mon, 23 Mar 92 12:48:20 -0500
Received: from ukcc.uky.edu by UKCC.uky.edu (IBM VM SMTP V2R2)
   with BSMTP id 7619; Mon, 23 Mar 92 12:42:27 EST
Received: from UKCC by ukcc.uky.edu (Mailer R2.08) with BSMTP id 0382; Mon, 23
 Mar 92 12:42:25 EST
Received: from WKUVX1.BITNET by ukcc.uky.edu (Mailer R2.08) with BSMTP id 0282;
 Mon, 23 Mar 92 12:39:26 EST
Errors-To: MacroMan@WKUVX1.BITNET
X-Listname: "VMS Internals, MACRO, and BLISS Discussions"
    <MACRO32@WKUVX1.BITNET>
Received: from CUNYVM.BITNET (MAILER) by WKUVX1 (MX V3.1) with BSMTP; Mon, 23
          Mar 1992 11:20:27 CST
Received: from CUNYVM by CUNYVM.BITNET (Mailer R2.08) with BSMTP id 6322; Mon,
          23 Mar 92 11:35:06 EST
Received: from gateway.novell.com by CUNYVM.CUNY.EDU (IBM VM SMTP V2R2) with
          TCP; Mon, 23 Mar 92 11:35:02 EST
Received: from ithaca.Eng.Sandy.Novell.COM by gateway.novell.com (4.1/SMI-4.1)
          id AA02004; Mon, 23 Mar 92 08:56:29 MST
Received: by ithaca.Eng.Sandy.Novell.COM (4.1/SMI-4.1) id AA03058; Mon, 23 Mar
          92 08:56:29 MST
From: <ed_heinrich@npd.novell.com>
Reply-To: MACRO32@WKUVX1.BITNET
Message-Id: <9203231556.AA03058@ithaca.Eng.Sandy.Novell.COM>
Subject: Re: Interesting trick with AST routines.
To: MACRO32@WKUVX1.BITNET
Date: Mon, 23 Mar 92 8:56:28 MST
In-Reply-To: <01GHVKHUY1DC000T9X@NAUVAX.UCC.NAU.EDU>; from "Anthony C.
    McCracken" at Mar 20, 92 6:11 pm
X-Mailer: ELM [version 2.3 PL11]
 
>
>    After studying the VAX/VMS Internals manual in detail and combining that
> with knowledge gleaned by poking around via the debugger in the system
> executive I've discovered the following, totally unsupported, "feature" of
> ASTs and AST routines.
>    It is possible to code an AST routine that can be interupted by another AST
> at the same access mode.  I've helped many a student programmer discover why
> their programs hang by locating such bad practices as calling $HIBER from
> within an AST or waiting for an event flag that gets set by another AST
 routine.
>    The problem is that generally an AST can only be interupted by another AST
> from a higher access mode.  It's possible to dismiss the AST from inside the
> AST thus allowing interuptions by other ASTs in such a way that the final RET
> instruction can properly clean up the stack.  A sample code segment follows.
>
>         .TITLE  AST TEST
>         .PSECT  DATA,RD,WRT,NOEXE
>
> DELAY:  .LONG   -10*1000*1000*2 ; 2 second delay for $SETIMR
>         .LONG   -1
> MD:     .ASCID  /SYS$OUTPUT/    ; Should be your terminal
> MCH:    .BLKW   1               ; I/O channel
> MYBUFF: .BLKB   20              ; Buffer for I/O
> MYSIZ = .-MYBUFF                ; Buffer size
>
>         .PSECT  CODE,RD,NOWRT,EXE
>         .ENTRY  MAIN,^M<>
>         $ASSIGN_S       CHAN=MCH,DEVNAM=MD              ; Get the keyboard
>         $SETIMR_S       DAYTIM=DELAY,ASTADR=AST1        ; Set a timer and
>         $HIBER_S                                        ; Go to sleep
>         $EXIT_S                                         ; That's all folks
>
> ;+
> ;  AST1 gets executed when the timer goes off.  It will make itself AST
> ;  interuptable in it's first two instructions.  Then it will queue a READ
> ;  to the terminal and then wait for an event flag to be set.  The event flag
> ;  gets set in the AST for the terminal read.  Finally $WAKE is called and
> ;  then AST1 returns.  The main thread gets control and exits.
> ;-
>         .ENTRY  AST1,^M<R2,R3,R4,R5>
>         MOVAB   MYASTRET,16(FP) ; Replace EXE$ASTRET with MYASTRET in the call
>         CHMK    #0              ; frame and dismiss the AST now.
>         $CLREF_S        #5
>         $QIO_S  CHAN=MCH,FUNC=#IO$_READVBLK,ASTADR=AST2,P1=MYBUFF,P2=#MYSIZ
>         $WAITFR_S       EFN=#5  ; AST2 will set event flag 5
>         $WAKE_S
>         RET             ; Not to EXE$ASTRET but to MYASTRET
>
> ;+
> ;  AST2 is called when the I/O request from AST1 completes.  It just sets an
> ;  event flag and returns to AST1 who is waiting on the flag.
> ;-
>         .ENTRY  AST2,^M<>
>         $SETEF_S        EFN=#5
>         RET
>
> ;+
> ;  MYASTRET is a munged version of EXE$ASTRET.  The only difference is that a
> ;  call to EXE$ASTEXIT (via CHMK #0) isn't performed.  It's already been done
> ;  in the AST.  The stack cleanup instructions are duplicated exactly.
> ;-
> MYASTRET:
>         ADDL2   #8,SP           ; Remove number of args and the AST parameter
>         MOVQ    (SP)+,R0        ; Restore R0 and R1
>         REI                     ; Return to the main process thread (or AST)
>
>         .END    MAIN
>
>
> Tony McCracken
>
>
> +----------------------------------------+-----------------------------------+
> | Anthony C. McCracken                   |                                   |
> | Northern Arizona University            | Boom boom boom,,, Still going !   |
> | Flagstaff, Arizona                     |                                   |
> |                                        | VMS just keeps going and going and|
> | acm@nauvax                   BitNet    | going.  Nothing outlasts VAX/VMS. |
> | acm@nauvax.ucc.nau.edu       Internet  |                                   |
> | 602.523.9422.us.west         Noise net |                                   |
> +----------------------------------------+-----------------------------------+
>
 
Tony has discovered a very powerful mechanism that is mentioned as being
reserved to Digital but has worked for as long as I know unchanged.  A more
subtle use is to allow a routine to be called as either an AST or non-AST
routine and, if an AST, dismiss the AST once the "critical" code path has
executed.
 
In addition, for languages other than Macro-32, it is possible to access
this "undocumented" system service via a call to SYS$CLRAST, which takes
no parameters, instead of the CHMK #0 instruction.
 
 
--
-------------------------------------------------------------------------------
Ed Heinrich, Novell, Inc.       Sandy, Utah
ed_heinrich@npd.Novell.COM
-------------------------------------------------------------------------------
 
