Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!tut.cis.ohio-state.edu!abvax!iccgcc!herrickd From: herrickd@iccgcc.decnet.ab.com (daniel lance herrick) Newsgroups: comp.arch Subject: Re: bizarre instructionsexi Message-ID: <3440.27ca5635@iccgcc.decnet.ab.com> Date: 26 Feb 91 17:36:04 GMT References: <9102220245.AA14853@ucbvax.Berkeley.EDU> <1991Feb25.134714.23523@linus.mitre.org> <10244@dog.ee.lbl.gov> <1991Feb25.203629.5059@linus.mitre.org> Lines: 21 In article <1991Feb25.203629.5059@linus.mitre.org>, bs@faron.mitre.org (Robert D. Silverman) writes: > In article <10244@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes: Chris provides [gcc implementation of (q,r)=(a*b+c)/d] > > Ah yes. A universal solution. Machine dependent. Ugly syntax. Only > works with one compiler. > > Furthermore, it does nothing to contradict the assertions I made above > that the arithmetic could not be done in the HLL and that assembler > routines had to be called. It does inline the subroutine, however. I still havn't been object oriented, so I may be completely misunderstanding things. However, couldn't one design an object for g++ that performs the correct calculation, no matter how ugly its internals, and then persuade the people familiar with the internals of g++ to make this object a little closer to builtin? Would this bring us closer to having a language that does the right*thing? Wouldn't operator overloading let us use sensible expressions for the operations? dan herrick herrickd@iccgcc.decnet.ab.com Brought to you by Super Global Mega Corp .com