Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!tank!uwvax!umn-d-ub!umn-cs!mike From: mike@umn-cs.CS.UMN.EDU (Mike Haertel) Newsgroups: comp.arch Subject: Re: Integer Multiply/Divide on Sparc Message-ID: <18132@umn-cs.CS.UMN.EDU> Date: 11 Jan 90 03:21:14 GMT References: <8840005@hpfcso.HP.COM> <1249@otc.otca.oz> Reply-To: mike@umn-cs.cs.umn.edu (Mike Haertel) Organization: Free Software Foundation Lines: 28 In article <1249@otc.otca.oz> gregw@otc.otca.oz (Greg Wilkins) writes: >Even if it is not a new instruction but an integer co-processor, it >still needs to be included in the ABI. > >Without an official yeh or nay on this one, nobody can have confidence in >Suns commitment to open systems and the ABI. I don't see how ABI is related to "open systems." Source level compatibility ought to be enough for anyone. With the emergence of, e.g., ANSI C, POSIX.1, and (less desirably) the X window system, it will be substantially easier to write portable programs, and these standards are likely to have a far longer viable life than any ABI. I see source level standards as being far less likely than ABIs to kill future innovation. RISC architectures, and surely the SPARC, are far from the last word in computer architecture! How will your ABI relate to the massively parallel machines that are likely to become increasinbly prevalent? And yet the source level standards will still be useful, particularly as even some of today's programs might conceivably benefit from parallelizing compilers. -- Mike Haertel "Everything there is to know about playing the piano can be taught in half an hour, I'm convinced of it." -- Glenn Gould