darylm@illian.UUCP (Daryl V. McDaniel) (12/31/89)
George, I am surprised at your bitterness. I will agree that NSC has had quite a few problems with the 32K family and has provided uneven marketing support for it. But, I disagree with several specific points you bring up. I will respond to issues mentioned in your reply to John Theus since I ignored your previous postings. >>National's commitment to the 32k has been uneven and ragged. Ask the >>customers - Sequent, for instance, which switched to the '386 for their >>new model, after getting a 32032 out the door. Tektronix, which basically >>never could get them to work right. The Siemens (Sequent) '532 machines are doing quite well, in Europe, and I understand that they are taking sales away from other Sequent machines. Tektronix shipped two product familys, with two generations of one family, which were based on the 32k. If you were to check the UUCP maps, you would see that there are many of those machines in use, particularly in the Portland area. There are hundreds of the machines in one Federal agency alone. The machines were built, shipped, and many are still in use so I guess that they figured out how to "get them to work right". We have been providing consulting and design services for the 32K family since early 1981. We were quite dubious at first because of National's history with the PACE ("The world's first 16-bit microprocessor"). As time progressed, it became obvious that NSC engineers had some great ideas in the 32k. There were some problems, especially with MMU misoperation, but after some hard work by National, Sequent, Tektronix, and other engineers the problems were identified and fixed. The 32332/32382 came up a lot faster than the '032 and '016. There were still a few gotchas and a major conceptual problem (for us anyway -- the MMU didn't handle dynamic bus sizing so all page tables, etc, had to be in 32-bit memory). The 32532 addressed the majority of CUSTOMER complaints about the 32k family by making a chip that is easy to design with, adds direct interrupt mode for faster interrupt response, improved slave protocol, cleaner burst mode, multiprocessor support, and homogeneous memory access. These features were a result of CUSTOMER input. Yes, the first couple steps of the '532 did have some problems but no more than reasonable with a part of this complexity. At all times, technical support from NSC has been excellent. We have had direct access to the chip designers for all technical problems. The local and regional NSC sales force and AEs have been truly helpful and worked to expedite resolution of all problems. National's national marketing efforts were pretty poor, though. > ... are you planning a "732" > (or whatever NSC calls the follow-on to the '532) board? Three, how > 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. Due to our commitment to the 32k family, we will support future members of the family. With NSC's concentration on the embedded controller market, there is some question on how long parts with MMUs will be available. There is quite a lot of pressure being put on NSC to continue with GP 32k processors, with MMUs, for the UNIX and workstation market. This is pretty clear indication that there are companies shipping 32k based products that are happy with the family. 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. There may have been a problem in early 32381 FPUs where they wouldn't properly restart operations. We have been experimenting with custom slave processors and have found that the CPU will hang if the slave doesn't properly restart the operation when the CPU encounters an exception on an operand fetch or transfer. The reason the CPU hangs, is that the slave never signals completion of the operation and the '532 is DESIGNED to wait for the slave to complete. Please, we don't need any NSC bashing in this group. Any one that has produced products based on the 32k family is quite aware of how National really is. Some people feel that they were burnt by NSC but many others have stuck it out and feel that they have a darn good product now. How about some ideas on how we can help the 32k family. I am sure that constructive comments to National would be welcomed. ------------ -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Daryl V. McDaniel .........sun!nosun!illian!darylm Micronetics, Aloha, Oregon, USA USENET: ...tektronix!nosun!illian!darylm
grenley@sunkist.UUCP (George Grenley) (01/03/90)
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