peterd@opus.cs.mcgill.ca (Peter Deutsch) (07/13/90)
** Opinions wanted, raging debated expected. Join now! Avoid the rush! ** In article <40088@mips.mips.COM>, mark@mips.COM (Mark G. Johnson) writes: > The June 1990 issue of _IEEE_Micro_ contains an article about the > Morotola 68040, written by some of its designers. The article agrees > with some of the advertising copy, saying "The sustained > performance level is 20 VAX-equivalent MIPS and 3 Mflops at a clock > speed of 25 MHz." (1st paragraph, 4th sentence). . . . > So, the data and the claim that 68040==20VAXmips implies that the earlier > 68020 has a "sustained performance level of 4.9 VAX-equivalent MIPS" > (4.9 = 20/4.1). Does anybody seriously believe this? ... > MIPS. This makes the 68040 a 16 VAXmips machine (at most), not 20 VAXmips > as advertised. > Of course the best method would be to lay hands on an actual computer > system that uses the 68040 and benchmark it; presumably Motorola > and/or NeXT and/or HP will do this someday. Prediction: the SPECmark > will be significantly below 20.0. Background: This gives me an opportunity to raise a question that I would like addressed. I am systems manager for a reasonably sized comp.sci. department (about 60 machines, with a new lab or two under construction that will take this to about 120 by the start of term).We have a couple of Sun 3/280s, a couple of Sun 4/280s, the usual passle of Sun 3/50s, our first SPARCs in place with more on the way, about 1/2 dozen NeXT with more on the way, plus the usual ragtag collection of widows and orphens (a MIPS, a few HPs, a uVax II, etc). My home machine used to be a Sun 3/280 (now I have a NeXT, yes there's a few out there!) Most of our students are on the Sun 4/280 pair, along with the usual collection of grad student projects, imported freeware, professors' code, etc, etc. I myself have done fair sized programming projects on our earlier (now departed) Vax 11/780s and the Sun 3's (plus GASP! PCs) but my exposure to programming on the SPARC architecture has been mostly through word of mouth from my staff and the user community (Sigh, I must be a _REAL_ manager now :-( Preamble: From my own exposure to user complaints about unportable software, etc I would allege that that the SPARC architecture appears to be inherently less forgiving of the programmer than the 68k architecture. I keep receiving reports of software that ran fine on machine 'x' (often 68k machines, Vaxen etc) but that either wont compile or wont run on the Sun 4's. I have had this explained to me (by a defender of the SPARC architecture) as being due to the fact that the SPARC architecture is less forgiving of poor programming (eg byte alignment problem in structures, ignoring warning messages, etc). It was stated to me that "well-wrtten programs work, if not it's the programmer's fault." Now to the question: First, is it true that SPARC is inherently less forgiving? If so, is it due to "limitations" of the architecture (eg. byte-alignment restrictions) or is this a "feature" through which sloppy programmers are now being taught the error of their ways? More specifically, If I accepted the rumours that porting to the SPARC was harder as an axiom could I argue that this was a "bug" of the architecture, not a feature, in the same way that difficulty addressing a 65k array on an 8088 machine is a residual bug due to limited segment size of that chip? Now, a few caveats, disclaimers, etc. Almost all the programming problems I have heard about were in C, which is an inherently low level language (although at least one very large Pascal program, a compiler project, never was ported successfully) and perhaps this should have been sent to comp.lang.c. I _would_ like answers to be centred around the problems of C programmers if this is a reasonable thing to do. The original motivation for this posting was as a followup to a discussion I had that originated from my observation that I seem to hear of more porting problems with the Sun 4's than the Sun 3's. One of my staff disputed my claim, claiming that the problem was with poor C programmers, not the SPARC (or RISC in general). As I have not attempted a serious program on the machine, nor am I all that familiar with its internals, I do _NOT_ claim to be capable to make the comparison, but have trouble swallowing the claim the bugs due to byte-alignment restrictions showing through (if in fact, that is what is happening) is the programmer's fault. I think the "near/far" abomination I used to have to use in the 8088 C compilers showed a fault of the 8088 architecture, raising up through the language to bit the programmer (and I understand that smarter compilers now can hid this from me, well so my poor friends still programming DOS machines claim). Given the (admittedly second-hand) reports of problems, is this not a similar hardware problem raising up through the language? Or am I really out to lunch here? If so, I apologize in advance, so don't flame. Note, I am _NOT_ disputing the worth of RISC architectures, which have given us dramatic performance gains. I'm just asking if we've paid a price in "servicability"? So, here's the clincher. My collegue claims there are NO C programs that will: a) Pass lint on the Sun 3 b) Pass lint on the Sun 4 c) Run, giving a "correct" answer on the Sun3, without crashing. d) Either crash or give the "wrong" answer on the Sun 4. In effect, any crash would be due to faulty programmer, not a faulty architecture. Is this true? Is the reverse true (ie crash on a Sun 3, but not on the Sun 4)? Can we draw valid conclusions about the frequency of either? Both? Enquiring minds want to know. If the appropriate programs exist, I would especially like to see them (email please). Otherwise, I'll follow comments in the groups. I now await the verdict of others more knowledgeble than myself... - peterd