heath@ncrcae.Columbia.NCR.COM (Robert Heath) (11/22/89)
In the last year or so the 88100 CPU has gone through a number of versions (e.g. D.0, D.5, E.0, E.1, E.2, etc.). To compensate for known chip problems, one of the steps in the compilation process has been a "silicon filter" which inserts instructions into the compiler's output before going to the assembler. These instructions are essentially software workarounds. The silicon filter provides reliability at some cost to performance. As later versions of the chip emerge, bugs are corrected, and the need for silicon filtering diminishes. Eventually no silicon filtering will be required as long as one runs with the "bug free" chip. This suggests that software generated for a later mask will not reliably run on an earlier mask. From a shrink-wrapped software developer's point of view, one wants minimal filtering at maximum reliability. To third party developers, that means targeting their 88K binaries to some baseline version of the mask. My question is: what version of the 88100 silicon do software vendors consider the baseline ? (e.g. D.5, E.2, etc.) Since this is more of a business decision, you won't find the answer in your 88open BCS and OCS standards. Robert Heath NCR Corp. W.Columbia, SC 803-791-6315
tom@ssd.harris.com (Tom Horsley) (11/25/89)
>Since this is more of a business decision, you won't find the answer in >your 88open BCS and OCS standards. Not true. The BCS standard includes a description of the architecture. It says that this 32 bit instruction fed to the CPU will do these things. Any cpu that does not do those things cannot be BCS compliant. This is also sort of a moot point. We have been running without a silicon filter for quite some time and have found no problems. The chips Motorola is turning out these days are pretty good. -- ===================================================================== domain: tahorsley@ssd.csd.harris.com USMail: Tom Horsley uucp: ...!novavax!hcx1!tahorsley 511 Kingbird Circle or ...!uunet!hcx1!tahorsley Delray Beach, FL 33444 ======================== Aging: Just say no! ========================
meissner@dg-rtp.dg.com (Michael Meissner) (11/29/89)
In article <5395@ncrcae.Columbia.NCR.COM> heath@ncrcae.Columbia.NCR.COM (Robert Heath) writes: | In the last year or so the 88100 CPU has gone through a number of versions | (e.g. D.0, D.5, E.0, E.1, E.2, etc.). To compensate for known chip problems, | one of the steps in the compilation process has been a "silicon filter" | which inserts instructions into the compiler's output before going | to the assembler. These instructions are essentially software workarounds. | The silicon filter provides reliability at some cost to performance. GNU C on the 88k as provided by Data General, no longer uses the silicon filter, and assumes at least E1 level of the chips. We did retain the ability of running the silicon filter, but don't do it by default when /bin/gcc is invoked. | As later versions of the chip emerge, bugs are corrected, and the need | for silicon filtering diminishes. | Eventually no silicon filtering will be required as long as one runs with | the "bug free" chip. This suggests that software generated for a later | mask will not reliably run on an earlier mask. | | From a shrink-wrapped software developer's point of view, one wants minimal | filtering at maximum reliability. To third party developers, that means | targeting their 88K binaries to some baseline version of the mask. | My question is: what version of the 88100 silicon do software vendors | consider the baseline ? (e.g. D.5, E.2, etc.) D level silicon is NOT acceptable unless you never use double precision floating point. Data General uses E.1 as the baseline for DG/UX 4.10, and will use E.2 as the baseline for DG/UX 4.20. I would expect E.2 to be the baseline for quite some time due to the cost of rev'ing up the chips, but I don't speak for DG. | Since this is more of a business decision, you won't find the answer in | your 88open BCS and OCS standards. | | Robert Heath | NCR Corp. | W.Columbia, SC | 803-791-6315 -- Michael Meissner, Data General. Until 12/15: meissner@dg-rtp.DG.COM After 12/15: meissner@osf.org