          <<< NOTED::DISK$NOTES7:[NOTES$LIBRARY_7OF4]HACKERS.NOTE;1 >>>
                               -< ** Hackers ** >-
================================================================================
Note 1778.0         Relocating code from P0 to S0 Space (NPP)          6 replies
STAR::FENSTER "Yaacov Fenster, Process Improvement, " 6 lines  10-SEP-1995 09:07
--------------------------------------------------------------------------------
    On Vax copying some code from my process space to S0 so that another
    process could call it was easy: Allocate some NP space, copy the code
    there, and that was about it. On AXP it seems to be a "bit" more
    complex. Any good examples (Especially in C) ?
    
    	Yaacov
================================================================================
Note 1778.1         Relocating code from P0 to S0 Space (NPP)             1 of 6
VIVIAN::RANCE "http://vivian.hhl.dec.com/rance/busi" 11 lines  10-SEP-1995 14:17
                                -< One example >-
--------------------------------------------------------------------------------

> Any good examples (Especially in C) ?
  
     This is something that I found incredibly difficult to do.
     I can't offer a good example, but I did post an example of 
     how to copy code from P0 space to P1 space and execute it 
     in 402.59.    I spent a lot of time trying to do this in C 
     before I gave up and wrote the only piece of MACRO64 that 
     I have ever written.

     	Stuart
================================================================================
Note 1778.2         Relocating code from P0 to S0 Space (NPP)             2 of 6
XDELTA::HOFFMAN "Steve; VMS Engineering"             11 lines  11-SEP-1995 10:05
                               -< Use A Driver? >-
--------------------------------------------------------------------------------

   Uh, what are you up to?

   I'd likely first look at loading an execlet, device driver or similar
   construct, and using that as the basis for interprocess operations.

   With the interprocess memory read and write primitives present under
   OpenVMS Alpha, one can sometimes entirely avoid copying code around.

   There are a number of entries under the "Interprocess AST" keyword.
   (Yaacov, I suspect you've already checked most/all of these notes.)
================================================================================
Note 1778.3         Relocating code from P0 to S0 Space (NPP)             3 of 6
STAR::KUEHNEL "Andy Khnel"                           9 lines  12-SEP-1995 11:46
--------------------------------------------------------------------------------
    Much of it depends on how many global data you need to carry along.  
    For the 64-bit project, we wrote code to put procedure descriptors and
    code into P2 space and got it executed as AST routines.
    
    I have to admit that our AST routine is extremely trivial because we
    wanted to avoid run-time fixups.  If you can live with barely any
    global references or RTL routines, you can check the test pack for some
    example code (e.g. x..._vmstst$:[vmstest.sys_64.lis]enqdeq64.lis, and
    address64asts.lis)
================================================================================
Note 1778.4         Relocating code from P0 to S0 Space (NPP)             4 of 6
RDGENG::WOOD_J "..mnoQPRstu.."                       53 lines  16-JUL-1996 02:56
              -< converting VAX Macro to DEC C for OpenVMS Alpha >-
--------------------------------------------------------------------------------
An ISV is trying to convert the following VAX Macro-32 to use DEC C on OpenVMS
Alpha. He has a few questions for which I'd be grateful of any suggestions
which I can pass on to him.

Thanks,
  John Wood
-------------

I wish to relocate a section of data and code to a new memory area (Non paged
pool) ie:

; Start of section to be relocated
base_address::					; Base of common code
queue:		.LONG		0,0		; Queue header for buffered data
server_pcb::	.BLKL		1		; Address of server PCB
abort_flag:	.LONG		0		; Flag to signal abort to server
;
; First routine.
;
first:
	...
	rsb
;
; Second routine
;
second:
	...
	rsb
length == . - base_address
rel_queue = queue - base_address
rel_server_pcb = server_pcb - base_address
rel_abort_flag = abort_flag - base_address
rel_first = first - base_address
rel_second = second - base_address
; End of section to be relocated

; Section which moves to pool
        bsbw    allocate_pool			; Allocate pool
        movw    r1,common_size			; Save size actually allocated
        movl    r2,common_address		; Save common code base address
        movc3   #length,base_address,(r2)	; Move code to non-paged pool
; Example of access
	movl	common_address,r12		; Get address of common code
	clrl	rel_abort_flag(12)		; Clear abort flag
	jsb	w^rel_first(r12)		; Do first function


I can group the code and data together using the linkage_psect and code_psect
pragmas, and the linkage option COLLECT=.  Although this will not give me a
value for length I can at least move the whole of the resultant linkage cluster
containing the code, linkage and data sections.  The problem lies in
identifying offsets to the data and function entry points, and how to implement
a call to them referenced from the common_address.
================================================================================
Note 1778.5*        Relocating code from P0 to S0 Space (NPP)             5 of 6
HNDYMN::MCCARTHY "A Quinn Martin Production"           1 line  16-JUL-1996 06:03
                           -< try DEC C conference >-
--------------------------------------------------------------------------------
I'd suggest trying the turris::decc conference.
================================================================================
Note 1778.6         Relocating code from P0 to S0 Space (NPP)             6 of 6
XDELTA::HOFFMAN "Steve, OpenVMS Engineering"         29 lines  16-JUL-1996 08:16
--------------------------------------------------------------------------------

   Hackers is not the appropriate spot for customer questions. 

   I'll assume the ISV has access to the source listings -- access to
   the listings is a necessity for this level of coding.

   The tough part of this question has very little to do with porting the
   Macro32 code to C (Macro32 is available on Alpha), it has to do with
   getting the code (properly) relocated -- or prying this particular
   requirement out of the application.  (There is no mention of what
   task(s) the application will perform...)

   The relocation of code under OpenVMS Alpha is somewhat more difficult
   than under OpenVMS VAX -- see 1786.*, 1778.* (P2 space), 1753.*, and
   other notes for similar (previous) discussions.  (I'd personnally try
   to avoid this particular approach.)

   Depending on what the actual purpose of the application is, existing
   routines such as EXE$READ_PROCESS, and EXE$WRITE_PROCESS might be of
   interest.  SCH*$QAST is another call used in this area, and OpenVMS
   Alpha P2 space might be of interest.

   For somewhat more "static" applications, I'd *strongly* recommend the
   use of an execlet or a pseudo device driver.  (The pseudo driver has
   the advantages of avoiding all of the relocation headaches, providing
   all manner of code and data storage areas, providing security checking,
   providing a user-mode interface, and being `relatively' portable between
   OpenVMS VAX and Alpha.)

