Path: utzoo!attcan!uunet!samsung!sdd.hp.com!ucsd!helios.ee.lbl.gov!pasteur!rigel!melvin
From: melvin@rigel (Steve Melvin)
Newsgroups: comp.arch
Subject: Re: resuming after fault (was GC & limit checking by MMU hardware)
Summary: Yet Another Piece of VAX Trivia
Keywords: GC, stack, heap, MMU
Message-ID: <26846@pasteur.Berkeley.EDU>
Date: 8 Aug 90 14:36:24 GMT
References: <1990Jul19.151524.22544@diku.dk> <11075@alice.UUCP> <3729@auspex.auspex.com> <25899@mimsy.umd.edu>
Sender: news@pasteur.Berkeley.EDU
Reply-To: melvin@rigel (Steve Melvin)
Organization: University of California at Berkeley
Lines: 90
X-Local-Date: 8 Aug 90 07:36:24 PDT

In article <25899@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes:
>...
>Basically, the problem here is that on an exception, the 680[123]0
>simply pushes the entire microengine state; a return from exception
>reloads the microengine state so that the instruction can be continued
>...
>If there is no documented way to verify the state (as there is on the
>VAX), it becomes difficult for an O/S to allow user code to handle an
>exception: if the user code modifies the state, this could crash the
>machine, or allow improper privileges.
>...
>In terms of computer architecture, the lesson here is that there must
>be a documented method to verify any state left behind.

It seems that what you really must be saying is that the hardware should
provide protections, becuase in this particular example, the OS has no way
of verifying the register contents.  If the user mangles the registers and
then returns with FPD set, an access violation may result, but the hardware
guarantees that the machine won't crash and no improper privileges will
result.

The VAX architecture specifies what the lower 2, 4 or 6 registers contain
after a string instruction is finished, but not what they contain in the
middle of a string instruction when an exception is taken with FPD set.
(Officially, an instruction is "unpredictable" if registers are modified
with FPD set or if FPD is set by software.)  Most implementations have done
things in similar ways, but these are not architecturally guaranteed (see
below).

The larger point about allowing user level access to exception handling
is well taken, but that's a separate issue from forcing the exact
specification of all the temporary state which an implementation may want
to keep around.

----
Steve Melvin						  ...!ucbvax!melvin
University of California, Berkeley		melvin@polaris.Berkeley.EDU
----

P.S.  Here's a little program I wrote several years ago which relies on
differences in FPD state packing to prove that user level programs could
discern different implementations.  There is an 8-bit field "delta pc"
packed into R0 which encodes the length of the instruction so that upon
restarting, the instruction doesn't have to be decoded again.
----
/* testimpl.c */

/* Use hardware dependencies in how FPD information is packed away to
 * test the type of VAX implementation being run on.  Depends on whether
 * or not the delta PC value stored in R0 should be added to the PC of
 * the opcode or the incremented PC.  Uses the fact that the REI
 * instruction can be executed from unprivileged code.
 */

main()
{
	if (tstimpl()) {
		printf("implementation is 11/780, microvax\n");
	} else {
		printf("implementation is 8600\n");
	}
}

/* link with the following assembly language file:
	.data
	.comm	_buf1,8
	.comm	_buf2,8

	.text
	.align	1
	.globl	_tstimpl
_tstimpl:
	.word	0xFFC
	movl	$0x010c,r0
	movl	$_buf1+4,r1
	movl	$0,r2
	movl	$_buf2+4,r3
	movl	$0,r4
	movl	$0,r5
	movpsl	r11
	bisl2	$0x08000000, r11
	pushl	r11
	pushl	$_tst1
	rei
_tst1:
	movc3	$2,_buf1,_buf2
	ret
	incl	r0
	ret
*/