eugene@pioneer.arpa (Eugene Miya N.) (06/09/87)
In article <3810039@nucsrl.UUCP> ram@nucsrl.UUCP (Renu Raman) writes: > Martin hit it on the nail here about designing with compatibility in > mind. Take the case of the IBM 360s/VAXens/Intel. The 360 > was definitely a workhorse of the 60-70s (with an excellent architecture > for its time) but got plagued by compatability features. No, in some ways, the 360/370 were regarded as rather mediocre in their time. The curse of compatibility has largely been the fault of software people writing in assembly language (for performance reasons in only a few cases [although this is a frequent excuse]), not writing portable code with small tight kernels of dependency info, writing code to make use of special software or hardware features [after all why else would you buy a machine for it bells and whistles?] which were not portable, and the "nobody every got fired for buying Big Blue" philosophy. > The other end of the spectrum like AMD, MIPS (certainly not small) > where compatibility is not the issue, the designs have been bold and > innovative. Would they also degenerate into mediocrity with market > build-up? What do you want to do make innovative architectures or make money? ;-) > The problem becomes more severe to-day with RISCy processors, > [as design issues/RISC ideas are notoriously different from > group to group (group = individual/corp/univ/research ctr)] > where maintaining compatibility over a generation of processors > will certainly be difficult. At the same time one needs > compatibilty to stay in business. What do you optimize here? You have a good data point to start with: Unix. Try your hand moving your favorite code (not a Unix utility) to every conceivable machine possible. Especially try your hand in getting away from: VAXen and SUNs and other 32-bit machines. Consider, if you are post SIII or 4.1BSD: 1) a PDP-11, the smaller the better, 2) a 36-bit Univac/Unisys machine, 3) all the new mini-supers: Convexes, Alliants, and the real supers: the Crays and the ETA when it gets up, 4) and stranger newer architectures like the Multiflow which also runs Unix [forget the Hypercubes (Note new article about them in current IEEE Spectrum), these are local memory machines which require special consideration]. You will probably find your code is less portable than you thought unless it is a very simple code. From the Rock of Ages Home for Retired Hackers: --eugene miya NASA Ames Research Center eugene@ames-aurora.ARPA "You trust the `reply' command with all those different mailers out there?" "Send mail, avoid follow-ups. If enough, I'll summarize." {hplabs,hao,ihnp4,decwrl,allegra,tektronix,menlo70}!ames!aurora!eugene