davet@oakhill.UUCP (Dave Trissel) (08/16/85)
[] In article 190@sri-unix.ARPA (Victor R. Frank) said: > In article (338@oakhill.UUCP) Dave Trissel gave the current (Feb 12, 1985) > bug list for the MC68020, one trivial error concerning the LINK instruction. > > I read in the August-September 1985 issue of Micro Cornucopia >on page 50, in an article entitled "The 32-Bit Super Chaps" by 5 >authors from Definicon Systems, allegations that in the 68020: > > 1. The barrel shifter does not work, > 2. The co-processor interface does not work, > 3. The data sheet AC characteristics cannot be met. > > ... but I would be interested in seeing on the net >(net.micro.68k) a rebuttal from Motorola, and any current >information of bugs/availability of the 68881 floating point unit. I guess Definicon Systems gets asked quite frequently why they aren't using the faster MC68020 so they came up with some lame excuses :-). (I'll give you one guess as to where they got this info from.) The allegations are quite absurd. Here is the latest bug list for the '020 1A45J mask which has been out for some time. This is as of August 12, 1985. 1) the CAS2.x instruction will not operate correctly if either of the operand effective addresses is data register indirect (Dn). 2) The TAS instruction will not operate properly if either the read or write portion of the RMC cycle is bus-errored. (We have a ten line fix for this in the exception handler.) 3) The BTST (bit test) instruction when used as follows will not do the bit test: BTST Dn,#< > The first two pertain mostly to OS type semaphore handling and are easily circumvented. The third is just discovered a few days ago and is quite interesting. A few years ago another guy in my group asked me why you would ever want to dynamically test a bit in a constant field so I thought up an example. While investigating this just reported bug we discovered that our assemblers do not and evidently have never supported this as a valid instruction. So it's just possible that it never was even tried by a programmer. So much for the '020. The MC68881 FPU has been heavily sampled and is close to being put into standard production. There is only one serious bug on that chip that I am aware of. One of the log functions has errors (I think logn.) But the fix is quite trivial since we have a logn(x-1) which works. So by including an extra subtract the correct result can be obtained. -- Dave Trissel Motorola Semiconductor Austin, Texas {ihnp4,seismo}!ut-sally!oakhill!davet
henry@utzoo.UUCP (Henry Spencer) (08/20/85)
> ... The MC68881 FPU has been heavily sampled and is close > to being put into standard production. There is only one serious bug on > that chip that I am aware of... There is another that friends of mine are quite disgruntled about: the chip has a vast amount of internal state, hundreds of bytes, and might perhaps do context-switching acceptably fast if it had DMA (!), which it naturally doesn't. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
frankr@enmasse.UUCP (Franklin Reynolds) (08/21/85)
In article <483@oakhill.UUCP> davet@oakhill.UUCP (Dave Trissel) writes: >The allegations are quite absurd. Here is the latest bug list for the '020 >1A45J mask which has been out for some time. This is as of August 12, 1985. > > 1) the CAS2.x instruction will not operate correctly if either of the > operand effective addresses is data register indirect (Dn). > > 2) The TAS instruction will not operate properly if either the read or write > portion of the RMC cycle is bus-errored. (We have a ten line fix for > this in the exception handler.) > > 3) The BTST (bit test) instruction when used as follows will not do the bit > test: > BTST Dn,#< > I just checked the letter I received from Motorola describing bugs in their A45J mask. Please note that my letter is dated july, not august, 1985. Anyway, the first two errors are listed but the third is nowhere to be found. In addition, six other bugs are listed. 1. LINK A7,Disp will load A7 with an undetermined value. 2. During power on RESET the RMC pin may be driven high. If bus error occurs during an arbitrated bus cycle, RMC may driven high for several clocks before being tri-stated. 3. Coprocessor primitive to evaluate EA and transfer data where the EA is immediat addressing and the size is byte passes the operand to the co- processor as a word. As such, the byte operand is passed in bit position [23 -16] rather that bit [31-24]. 4. CMP.x (A7)+,(Ax)+ may not work correctly in a virtual environment. 5. There is a problem with the RTE instruction when returning from a bus access error (bus error or address error) that may cause the porcessor to hang up. The letter goes on to describe how to write a bus exception handler that can deal with problem mentioned above. Franklin Reynolds EnMasse Computer Corp. {genrad,panda,harvard}!enmasse!frankr
cruess@oakhill.UUCP (Michael Cruess) (08/22/85)
More of the story: The MC68881 can save 180 bytes of internal data on a context switch. This only occurs on remainder, trancendental function, and BCD conversion instructions if the save operation occurs during their middle phase of operation. At all other times the idle save format is used, which contains 24 bytes of internal state. In other words, unless your floating point mix is heavily weighed to doing remainders or trancendentals, you get the short format much more frequently. Even so, consider that the execution time of some of these instructions is data dependent, and that the floating point instruction can continue to run (and may complete) while other work pertaining to the context switch is done by the CPU. Yes, you have to reserve the 180 bytes per task just in case. Michael Cruess oakhill!cruess Motorola, Inc. Microprocessor Products Group
davet@oakhill.UUCP (Dave Trissel) (08/23/85)
In article <5883@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: [speaking about 881 bugs...] >There is another that friends of mine are quite disgruntled about: the >chip has a vast amount of internal state, hundreds of bytes, and might >perhaps do context-switching acceptably fast if it had DMA (!), which it >naturally doesn't. Yes, ideally onboard DMA could double the speed of the context save and restore operations. Early on we had to make an estimate of the many tradeoffs involved in having a '881 with DMA. It was then determined that for the basic instruction set (everything but FMOVEM and FSAVE/RESTORE) the DMA would not have improved execution time. One reason being that to verify memory protection would require talking between the '881 and '020 which would have nullified most DMA gains. There were other more subtle issues as well, but the most important was the added complexity it would have added to the '881. Picture the people involved with the project - their task was to design a floating-point chip far more comprehensive than any other and be the first to utilize the new co-processor interface definitions on the MC68020 project which was "growing up" and evolving on its own at the same time. The extra burden of bus master would only have been considered if there was a noticible gain in overall performance. We also considered the down-the-road aspect of merging the '881 in a future chip with the '020 chassis in which case the DMA would have to be re-designed back out of the machine. Once we did decide against the bus master scenario we did include some minor architectural items to try to lessen the pain of context save/restore. First the '881 indicates whether it has been used so that the OS dispatcher can skip the saving of control and FP registers at times. Second, we put a lot of work into the '020 coprocessor interface such that external interrupts could be taken even mid-instruction at certain points of '881 execution. -- Dave Trissel {ihnp4,seismo}!ut-sally!oakhill!davet Motorola Semiconductor Inc. Austin, Texas
davet@oakhill.UUCP (Dave Trissel) (08/23/85)
In article <454@enmasse.UUCP> frankr@enmasse.UUCP (Franklin Reynolds) writes: > >I just checked the letter I received from Motorola describing bugs in their >A45J mask. Please note that my letter is dated july, not august, 1985. >Anyway, the first two errors are listed but the third is nowhere to be found. >In addition, six other bugs are listed. > >1. LINK A7,Disp will load A7 with an undetermined value. > > [etc.] I don't know how but you have a weird document. We have no record of an errata sheet for the month of July and what you have combines the (then) two known bugs of the A45J mask set with the list of bugs for an earlier mask. I can only surmize that someone was trying to list the bugs for both parts but failed to title the second section. If your document was not a composite generated by someone after it left Motorola let us know and our coordinator will investigate. -- Dave Trissel {ihnp4,seismo}!ut-sally!oakhill!davet Motorola Semiconductor Inc. Austin, Texas