Path: utzoo!attcan!uunet!cs.utexas.edu!usc!snorkelwacker!bloom-beacon!primerd!peterson
From: peterson@primerd.prime.com
Newsgroups: comp.arch
Subject: Re: Is handling off-alignment impor
Message-ID: <57300003@primerd>
Date: 15 Aug 90 11:37:00 GMT
References: <12459@encore.Encore.COM>
Lines: 50
Nf-ID: #R:encore.Encore.COM:-1245900:primerd:57300003:000:1491
Nf-From: primerd.prime.com!peterson    Aug 15 07:37:00 1990


/* Written 10:45 am  Aug 12, 1990 by pinocchio.encore@encore.UUCP in primerd:comp.arch */
/* ---------- "Re: Is handling off-alignment impor" ---------- */
From article <488@array.UUCP>, by colin@array.UUCP (Colin Plumb):
>>>mash@mips.COM (John Mashey) writes:
>>>> Can anyone give some live examples where software takes advantage of the
>>>> mode where the CPU just zeroes the low-order bits and conitnues...
> 
>>jkenton@pinocchio.encore.com (Jeff Kenton) writes:
>>> The only case I've seen is a low level, PROM based, debugger on the 88k
>>> which runs in this mode.
> 
> In article <467@hitachi.uucp> jon@hitachi.UUCP (Jon Ryshpan) writes:
>> I can't imagine a *worse* place to turn off a trap detecting possible
>> errors than in a debugger.
> 
> I think we can assume that it restores the state while running the debugged
> code; it just turns off the trap for internal use.  I don't think detecting
> errors in the PROM monitor does you much good, anyway, so why worry? :-}

Unfortunately, it doesn't.  As I said in my (partially quoted) posting, I'm
not convinced that the small saving in debugger code is worth the loss of
general error checking it costs you.






















- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      jeff kenton  ---	temporarily at jkenton@pinocchio.encore.com	 
		   ---  always at (617) 894-4508  ---
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
/* End of text from primerd:comp.arch */