🚀 go-pugleaf

In article <85553@sun.uucp> khb@sun.UUCP (Keith Bierman - Sun Tactical Engineering) writes:
|In article <1798@ardent.UUCP> mac@mrk.ardent.com (Mike McNamara) writes:
|>	Ardent Titans and MIPSCO boxes and SGIs will *not* run each
|>others a.outs, although things like /bin/file will recognize foriegn
|>objects as native sons...
|>
|>	And it makes sense, The Ardent Titan is up to four Mips R2000
|>each tightly intergrated with a custom vector processing unit. What do
|>you expect an M120 to do when given an Ardent `dvma' instruction?
|>(double precision A = B*C+D). (Probably bus error...).
|>
|
|C'mon old buddy, isn't there a way to generate scalar only code ?
|Shouldn't one expect scalar only code to be portable ? A vector
|version of gnu-emacs, for example,  might be nice...but being able to
|"plug and play" can be handy.
|
	NASTRAN, GATEWAY, FIDAP, et. al. are interested in Floating
Point performance.  They sell binaries for big bucks. Hence the desire
for an ABI, but the price of loss of performance (from ignoring vendor
specific fp (and vendor specific multiple processor synchronization)
hardware is too high.)  As long as the chip vendors do not supply MP
synch.  instructions, system vendors will have to roll their own,
leading to incompatibility.  While MIPSco does provide a FP Coprocessor,
we rolled our own Vector FP unit, to get the 64 MFLOPs peak.

	Gnu-emacs needs a fast integer box with good VM.  They
distribute source for free. Hence no need for ABI for Gnu-emacs.
(Although compatible networking code helps a lot!!)

|
|Keith H. Bierman


mac @ ardent.com