Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!think.com!linus!linus!linus!bs From: bs@linus.mitre.org (Robert D. Silverman) Newsgroups: comp.arch Subject: Re: bizarre instructions Message-ID: <1991Feb26.174559.9417@linus.mitre.org> Date: 26 Feb 91 17:45:59 GMT References: <9102220245.AA14853@ucbvax.Berkeley.EDU> <10278@dog.ee.lbl.gov> <6870@mentor.cc.purdue.edu> Sender: news@linus.mitre.org (News Service) Organization: The MITRE Corporation, Bedford, MA 01730 Lines: 93 Nntp-Posting-Host: linus.mitre.org In article <6870@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes: :In article <10278@dog.ee.lbl.gov>, torek@elf.ee.lbl.gov (Chris Torek) writes: :> [Bob Silverman asks for a way to compute (A * B + C) divrem D and :> claims that `Even on machines that support double length integer :> multiplies, one cannot put the above operations into HLL' (because :> the compiler cannot use 32x32=>64 bit operations) and that `one is :> FORCED to call assembler routines to do this'.] :> :> In article <10244@dog.ee.lbl.gov> I demonstrate that the last claim :> is false. :> :> >>This has its drawbacks: the syntax is distinctly un-pretty, and it :> >>requires gcc, and it is machine-dependent. It does, however, work. :> :> In article <1991Feb25.203629.5059@linus.mitre.org> bs@faron.mitre.org :> (Robert D. Silverman) writes: :> >Ah yes. A universal solution. Machine dependent. Ugly syntax. Only :> >works with one compiler. :> :> Do you want a machine-independent solution for using the machine :> instruction(s) that compute(s) (A * B + C) divrem D? :> :> This is clearly impossible, since some machines have no such instructions. : :I agree partly with both. The LANGUAGE should probably contain some such :instruction, and it certainly should allow the writing : : E,F = (A * B + C) divrem D : :or even : : E,F = (A * B + C) / D : Actually I would settle for the following::: I am more than willing to write the assembler code for an operation ---- we will call FOO. FOO takes 3 arguments and returns 2 more. I would then like to see the following in a HLL: asm_routine(FOO(a,b,c,d,e)) The compiler will then fetch my assembler routine, and RESOLVE any register/stack/addressing conflicts that might arise because the assembler routine uses the same registers/addresses etc. that are produced by the calling routine. The compiler will straighten out any conflicts [renaming registers within the assembler routine as needed etc.] and then in-line the assembler routine. It is true that I must rewrite FOO for every new machine, but because FOO is time critical it is worth my trouble to do just that. FOO would be written as an ordinary subroutine; it would assume that the arguments to it had been placed on the stack the same as any other subroutine call. There are currently machines which have no multiply or divide instruction at all, e.g. SPARC. When the compiler sees an operation a*b it generates a subroutine call. Building in a 'divrem' operator into a language could be done the same way. For machines that have the instruction there is no problem. For those that don't, a subroutine call is generated. The only difficulty in the above paragraph would be in deciding that a 'divrem' operator was worth adding to the language. If enough people can agree that it IS worthwhile, then actually doing it is a non-problem. As for all of you who claim that 'divrem' (or 'foo' or any other special operation) is not needed let me remind you of one thing: The current SPARC does not have integer multiply or divide in hardware. The next release (Version 8) will have it. If, as all of you have been claiming that multiplication & division are so infrequent as to not be needed, then why did SUN add it in? Now I can't say of my own personal knowledge, of course, but ask yourself what user or set of users would have enough clout [i.e. a big enough market] to convince SUN to add such a thing. Hint: think 'cryptography' Many of the instructions under discussion are essential for good performance in cryptographic applications. As more and more PC users hook into networks, computer security applications will become more important. As will the necessary instructions to support those applications. -- 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