Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!snorkelwacker!think!husc6!encore!pinocchio.encore.com
From: jkenton@pinocchio.encore.com (Jeff Kenton)
Newsgroups: comp.arch
Subject: Re: GC triggering and stack limit checking by MMU hardware
Message-ID: <12283@encore.Encore.COM>
Date: 23 Jul 90 18:34:52 GMT
References: <3729@auspex.auspex.com>
Sender: news@Encore.COM
Lines: 36

From article <3729@auspex.auspex.com>, by guy@auspex.auspex.com (Guy Harris):
>>The problem is that certain machine architectures (eg. Motorola 68K) and OS
>>implementations (eg. SunOS at least in some versions) do not provide
>>a continuable address violation signal (SIGSEGV), even though at the kernel
>>level, address translation faults (page faults) are continuable. Not having
> 
>>Newer machines/architectures might handle this better,
> 
> I think most RISC machines (not entirely surprisingly) have less or no
> context of that sort; I'd expect things to work OK on a SPARC-based Sun,
> for example, as well as a MIPS-based machine. 
> 
> In fact, what architectures other than the 68K architectures have lots
> of context for that?  I don't think the 386 or the WE32K, for example,
> have that problem.


The 88000 provides enough information to know what memory access failed,
but not where the instruction was that triggered the failure (the access
enters the memory pipeline while the instruction stream continues).  The
typical kernel faults in a missing page (if possible) and completes the
memory access from within the kernel.  It then returns to the user code
stream at the place where the exception took, which is usually not the
instruction which caused the fault.








- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      jeff kenton  ---	temporarily at jkenton@pinocchio.encore.com	 
		   ---  always at (617) 894-4508  ---
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -