Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!wuarchive!usc!apple!oliveb!tymix!cirrusl!sunkist!grenley
From: grenley@sunkist.UUCP (George Grenley)
Newsgroups: comp.sys.nsc.32k
Subject: Re: NSC Grumblings by George Grenley
Message-ID: <1201@cirrusl.UUCP>
Date: 2 Jan 90 22:15:27 GMT
References: <371@illian.UUCP>
Sender: news@cirrusl.UUCP
Reply-To: grenley@sunkist (George Grenley)
Organization: CIRRUS LOGIC Inc.
Lines: 50

In article <371@illian.UUCP> darylm@illian.UUCP (Daryl V. McDaniel) writes:

>George,

>> did you work around the problem where the '532 hangs if you write a
>> floating point number across a page boundary, and you fault on the
>> second page?  The '532 hangs on this condition, I believe - but I 
>> may be incorrect on this.

>As far as the '532 hanging on floating point operands that span a page
>boundary into a non-resident page, I've never seen it.

>If data is properly aligned it will never span a page boundary.  I forced
>both 32-bit and 64-bit floating point values to span a page boundary,
>ensured that the second page would cause a fault, and tried floating point
>operations with that data.  Not a problem.

>Daryl V. McDaniel				.........sun!nosun!illian!darylm
>Micronetics, Aloha, Oregon, USA		USENET:	...tektronix!nosun!illian!darylm

Perhaps I mis-remember the problem slightly.  AS of Jan'89, all steppings of the
'532 (A1,A2,B0,B2)  would lock up under the following conditions.

1. A write was occurring of a floating point (8 byte) number
2. The address was such that the operand spanned two MMU pages, i.e., 4K boundary
3. An MMU fault occurred on the second page - specifically page-not-present.

I don't know if it happens every time or just sometimes, bu a couple of
customers found it.  Even if an operand is long-word aligned, it can cross
a page boundary - rarely do the s/w types bother to avoid this.  As a 
result, a fair amount of existing code would break.  New code, or re-comp-
iling old code, could work around it easily, but binary compatibility
didn't exist.  I believe both Opus and Encore were _upset_, to say the
leasy, because they had large amounts of installed binary code....

A hardware fix - rather a clever one, too - was developed by Jonathan Levy,
a sometime contributor to this group, which required only a PAL or two
externally, and triggered an interrupt when it saw this condition.  Thus,
the OS could deal with it.

I don't know whether any later stepping of the '532 fixed this on
chip or not - NSC fired me in January, and I haven't kept up.

Daryl, you might want to dig into this a little further.  I may have the
details wrong, but the problem is real, albeit obscure.

Hope this helps any potential '532 developers out there...

Regards,
George Grenley