Conference noted::hackers_v1

Its illegal, and its execution is unpredictable, because an REI is not
executed between modifying and executing the instruction stream.

RTFM.

/Bevin

Ok.  How about for a PDP: MOV -(PC), -(PC)

Or is that considered self duplicating?

Here's another example of why you shouldn't do self-modifying code:

error::
	.word 0
	clrb	10$
	nop
	nop
	nop
	nop
	nop
10$:	movl	#1,r0
	ret

	.end error

If you run this on a 730,750,or MicroVAX I, you will get a reserved operand
fault. If you run it on any other VAX (including Scorpio & Nautilus), it
will return "correctly." If there were only 2 nops there, it would work on
a 750.

	Jon

	RE:.3 - Is that something to do with the instruction pre-fetch (he
guessed, wildly) ?


Trev

Precisely.

	Jon

BTW, every once in a while, this will produce a reserved instruction trap
on ANY VAX.  (All you need is for an interrupt to occur between the modifi-
cation and the execution of the instruction.)

It's actually possible to use this to count the number of interrupts in a
given time interval in user-mode code.
							-- Jerry

RE: 203.1

What manual and page are you referring to?

	Mike

    Re: .7:   DEC STD 032, the VAX Architecture Standard.

    DEC STD 032, Vax Architecture Std, section 8.3
    
    
    The VAX arch. encourages ... separation of ... procedure (instructions) and
    writeable data.
    
    Native mode procedures may not write data which is to be subsequently
    executed as an instruction without an intervening REI instruction
    being executed... If no REI...the instructions are executed are
    UNPREDICTABLE.
    
    
    Actually I was feeling hacked off the day I put response .1 in,
    and the RTFM was uncalled for.  It is a rather obscure reference.
    
    
    /Bevin

The REI reference was the one that I couldn't understand.  Doing an REI
without an exception or interrupt having occurred seemed suspicious.
Since the PC and PSL are popped from the stack when they were never
pushed, it seems to me that the stack will be corrupted.  How is this
avoided?

I ran the program from the debugger in single-step mode and it did what it
was "supposed" to do.   However, running it normally produced the
once-only loop.  It looked to me like the problem was associated with the
instruction look-ahead in the processor.  Isn't this really what is being
exercised here?

	Mike

    	Running the debugger in single step mode you get an REI for
    every instruction in the programme under test (at least one, that
    is).
    
    	The philosophy, I think, is that the architecture should allow
    a particular implementation to do an indefinate amount of instruction
    stream prefetch or caching, but should still allow things like image
    activation or swapping to work. These always do an REI to get to
    the code that is new in memory, so the REI is guaranteed to flush
    any such buffers, but it is the *only* guaranteed way.
    
    	Dave

    
    You just write code to push a valid PSL/PC on the stack before you
    do the REI...
    
    /Bevin

That's what VAX Sort/Merge V4 does.

It builds a few little routines that are executed via JSB linkages.
To ensure that the instructions get there, it does an REI.

There was an interesting bug on the 11/750s (?) that this code turned
up.  If the byte following a one-byte instruction wasn't readable (that
is, the the one-byte instruction was the last byte on a page, and the
next page was protected), it produced an ACCVIO.  So Sort/Merge pads
the generated routines will an extra byte.

BTW - does anyone know whether BASIC (which does 'dynamic linking')
executes an REI before executing the generated code?

    Yep, sure does.  Here is the code:
    
    	MOVPSL	-(SP)		;MEET ARCHITECTURAL SPEC FOR CALLING CODE
	PUSHAB	B^30$		;CONTINUE IN LINE
	REI			;CONTINUE AT NEXT INSTRUCTION
30$:	CALLS	#0,(R3)		;CALL THE USER PROGRAM IN MEMORY