mslater@cup.portal.com (Michael Z Slater) (01/31/91)
I'm trying to find out the real status of the 68040, and would appreciate any comments users can supply. The official line from Motorola is that the part is doing great and that more than 10,000 were shipped in December. Moto admits that there are some bugs, but says that all have simple workarounds. NeXT has shipped some machines, and at least some users seem satisfied. Floating-point performance is lousy for 030 binaries, but is good if the programs are recompiled for the 040. However, several sources have told me that the bug list is still lengthy and they have yet to see any parts they consider production quality. I've heard rumors that HP hasn't been able to get their systems running reliably, and that performance is disappointing. Motorola has yet to release any benchmark data to back up its performance claims. The most extreme of the rumors that have been circulating is that Moto is cancelling the 040. This seems extremely unlikely, to say the least, and I'd bet this rumor originated from one of Moto's competitors (take your pick). But the fact that some people believe it indicates how much uncertainty there still is about the 040, a year after its announcement. Is Moto keeping quiet on benchmarks because they don't like the results? Are the bugs really minor? Is the chip really in volume production? I'd appreciate any information users of the chip can supply. I'd be really delighted if someone sent me a copy of the current errata list. Michael Slater, Editor and Publisher, Microprocessor Report mslater@cup.portal.com 707/823-4004 fax: 707/823-0504 874 Gravenstein Hwy. So., Suite 14, Sebastopol, CA 95472
heiby@mcdchg.chg.mcd.mot.com (Ron Heiby) (02/08/91)
Note that I am not part of Motorola's Semiconductor Sector. I'm basically a customer, just like everybody else. I have a copy of the errata sheet for the 18D34B. If you can get a part, you can get the sheet (I believe). (Perhaps members of the press could contact the appropriate office at Semiconductor to get one?) Almost all of the items seemed to me to be related to the FPU or the MMU. Most seem to have workarounds. Many are marked as being fixed in the next mask. I have a customer who has ported a real-time kernel to our first 68040 based board. He reports that running his software compiled with a 68020 compiler, taking *NO* advantage of optimizations in the newer processor and *NOT* taking into consideration alignment issues for performance optimization, with Icache on and Dcache in copy-back mode, he is seeing 3 to 3.5 times the performance of the 68020 board running at the same clock speed, same quantity of (on-board and total) DRAM in some of his benchmark tests. That brings us to what I believe are the reasons we've seen very little in the way of benchmarks. The compiler vendors have not yet produced compilers that understand and take advantage of the optimizations that are possible with the 68040. The 3 to 3.5 X figures can be taken as *minimums*, with much better performance expected when the compilers are there. (I've heard that a major C compiler vendor is in Beta with its compiler right now.) The problem is that once "official" numbers are published, people tend to forget all of the caveats about how they came from an ancient compiler that had never heard of MOVE16 instructions (for example). As always, to find out what kind of performance boost your application will see, the best thing to do is to try it. Second best is to *deeply* understand exactly how your benchmarks have been constructed, compiled, loaded, and executed. Beyond that, all you've got (as my figures above) are general ballpark figures with mucho caveats. I have heard no rumor about cancelling the 040. It sounds completely ridiculous to me. I *have* seen detailed plans for our second 68040 board offering. I am *VERY* impressed. -- Ron Heiby, heiby@chg.mcd.mot.com Moderator: comp.newprod "Wrong is wrong, even when it helps you." Popeye
joeo@sharp..westford.ccur.com (Joe Orost) (02/13/91)
In article <55919@mcdchg.chg.mcd.mot.com> heiby@mcdchg.chg.mcd.mot.com (Ron Heiby) writes: > The problem >is that once "official" numbers are published, people tend to forget >all of the caveats about how they came from an ancient compiler that >had never heard of MOVE16 instructions (for example). Other than aligning the stack on a 16-byte boundary, and aligning all external data modules on a similar boundary, how does a compiler take advantage of the MOVE16 instruction? regards, joe -- Full-Name: Joseph M. Orost Email: joeo@tinton.ccur.com Phone: (201) 758-7284 Fax: (201) 758-7113 US Mail: MS 322; Concurrent Computer Corporation; 106 Apple St Tinton Falls, NJ 07724
mjs@hpfcso.FC.HP.COM (Marc Sabatella) (02/14/91)
> Other than aligning the stack on a 16-byte boundary, and aligning all > external data modules on a similar boundary, how does a compiler take > advantage of the MOVE16 instruction? Not very useful in ordinary code generation. Structure assignment comes to mind. A compiler that has never heard of it is probably not severely hampered. In implementation of library functions, it has obvious uses for memcpy, et al, but those are hand coded assembly if you care about speed anyhow, so again, the compiler need not generate it. The kinds of things a compiler could do to take advantage of the '040 are aligning things on 8 byte (half cache line) boundaries, avoiding addressing modes that tie up the integer unit, and instruction scheduling to keep the pipeline flowing. -------------- Marc Sabatella (marc@hpmonk.fc.hp.com) Disclaimers: 2 + 2 = 3, for suitably small values of 2 Bill and Dave may not always agree with me
heiby@mcdchg.chg.mcd.mot.com (Ron Heiby) (02/15/91)
joeo@sharp..westford.ccur.com (Joe Orost) writes: > Other than aligning the stack on a 16-byte boundary, and aligning all > external data modules on a similar boundary, how does a compiler take > advantage of the MOVE16 instruction? Er, um, by generating object code for it? Remember that the MOVE16 instruction did not exist before the MC68040. So, compilers that generate code for 68020 and 68030 processors will not be generating MOVE16 instructions. If they did, the executing code would be trapping on an illegal instruction. Now that the MC68040 exists, it implements the MOVE16 instruction, so compilers can "take advantage of the" new "MOVE16 instruction" by generating object code that uses it to move blocks of memory around. -- Ron Heiby, heiby@chg.mcd.mot.com Moderator: comp.newprod "Wrong is wrong, even when it helps you." Popeye
halkoD@batman.moravian.EDU (David Halko) (02/19/91)
does someone have a quick set of Specs for the 68040, so the general consencous can get an idea of what this CPU can do? what does the 68040 chip set go for now a days? How easy is it for one to get ones hands on it? David J. Halko