Xref: utzoo comp.arch:10649 comp.misc:6559
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!iuvax!uxc.cso.uiuc.edu!dino!atanasoff!hascall
From: hascall@atanasoff.cs.iastate.edu (John Hascall)
Newsgroups: comp.arch,comp.misc
Subject: Re: TRON (a little long)
Message-ID: <1216@atanasoff.cs.iastate.edu>
Date: 15 Jul 89 15:41:04 GMT
References: <32424@apple.Apple.COM> <226@arnor.UUCP> <33015@apple.Apple.COM> <29418@ism780c.isc.com> <1449@mdbs.UUCP>
Reply-To: hascall@atanasoff.cs.iastate.edu.UUCP (John Hascall)
Organization: Iowa State Univ. Computation Center
Lines: 40

In article <1449@mdbs.UUCP> wsmith@mdbs.UUCP (Bill Smith) writes:
>] >Instructions range from 16-160 bits (this is probably
>] But his 160 bit estimate was conservative.  Here is an example
>] of a single instruction.  The number of bits in the instruction is 416.  And
>] there are instructions that are even longer than this one.
 
>]      mov @(@(@(@(a,r1),b,r2),c,r3),d,r4), @(@(@(@(a,r1),b,r2),c,r3),d,r4)
 
>What will happen when such an instructions crosses a page boundary and
>a page fault occurs?   Is there some trickery that must be written into
>the operating system to avoid thrashing when the instruction is restarted.

>I've heard that the VAX can have instructions that can be very long.  Do
>VAXEN need to be careful in this situation as well?


     The longest instruction on a VAX is 37 bytes (296 bits).  VAX instructions
     are 1 byte of opcode (there are a few 2 byte opcodes--mostly quadruple
     precision) followed by the operand specifier(s).  No instruction has
     more than 6 operands and the longest operand specifier is 6 bytes:


	       @789ABCDE(Rn)[Ri]    or   789ABCDE(Rn)[Ri]


     It seems to me that the instruction (including operand specifiers) can
     be in at most 2 pages, and a "@displacement(Rn)[Rindex]" operand can
     reference 4 pages (2 references [address of operand & operand] * 2 pages
     [both happen to straddle a page boundary]) giving 2 + (6 * 4) = 26 pages
     which must be able to be in memory.

     I don't know of an special mechanism that would prevent one of the
     required pages from being selected as the victim to page-in one of
     the other required pages.  I suspect they rely on this being a low
     probability event (in the worst case an extra page-in [or so]).
     I also seem to recall some minimum number of in-memory pages for a
     process which I suspect must be somewhat above 26.


     John Hascall