Xref: utzoo comp.arch:10646 comp.misc:6553
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!sun-barr!ames!purdue!mentor.cc.purdue.edu!pur-ee!pur-phy!sawmill!mdbs!wsmith
From: wsmith@mdbs.UUCP (Bill Smith)
Newsgroups: comp.arch,comp.misc
Subject: Re: TRON (a little long)
Summary: Is VCISC (i.e. TRON) bad during page faults?
Message-ID: <1449@mdbs.UUCP>
Date: 14 Jul 89 14:24:04 GMT
References: <32424@apple.Apple.COM> <226@arnor.UUCP> <33015@apple.Apple.COM> <29418@ism780c.isc.com>
Organization: MDBS Inc., Lafayette, IN
Lines: 22

] >Instructions range from 16-160 bits (this is probably
] >an exaggeration, but I can't find my documentation on it right now, and it is
] >a nice round order of magnitude :-) ) I seem to recall that addressing modes
] >are more like addressing expressions.
] >{decwrl,hplabs}!amdahl!apple!baum
] 
] 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?

Bill Smith
uunet!pur-ee!mdbs!wsmith