Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!samsung!think.com!linus!linus!faron!bs From: bs@faron.mitre.org (Robert D. Silverman) Newsgroups: comp.arch Subject: Re: standard extensions Message-ID: <1991Feb25.135057.23667@linus.mitre.org> Date: 25 Feb 91 13:50:57 GMT References: <6049@mentor.cc.purdue.edu> <3381.27c548c3@iccgcc.decnet.ab.com> Sender: news@linus.mitre.org (News Service) Organization: The MITRE Corporation, Bedford, MA 01730 Lines: 27 Nntp-Posting-Host: faron.mitre.org In article ph@ama-1.ama.caltech.edu (Paul Hardy) writes: :In article <3381.27c548c3@iccgcc.decnet.ab.com> herrickd@iccgcc.decnet.ab.com (daniel lance herrick) writes: : :> What has frosted me about the languages is that the arithmetic :> operators are all single valued. I usually want the quotient :> and remainder from a division. I have to tell the compiler to :> give me the quotient and then tell it to give me the remainder. : :This is annoying, but it's one thing an optimizer should look for since it :happens a lot in multi-precision code so that it won't cost much extra time. :Alternatively there's Forth, a stack-based language, which will leave a :quotient and remainder on the stack after a divide. And there's always :assembly language.... Yes. There always is assembler. However, the cost of calling an assembler routine to do a division returning both quotient and remainder is very expensive. In-lining mechanisms for assembler code are woefully inadequate in current languages. One can, of course, look at the intermediate assembler code generated by the compiler of a HLL and then adjust your assembler code so that register usage is correct, but this is very clumsy and must be redone everytime you make a change to the HLL code. -- Bob Silverman #include Mitre Corporation, Bedford, MA 01730 "You can lead a horse's ass to knowledge, but you can't make him think" Brought to you by Super Global Mega Corp .com