Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!edcastle!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.arch Subject: Re: F.P. vs. arbitrary-precision (was: Killer Micro II) Message-ID: Date: 14 Sep 90 13:52:07 GMT References: <3755@osc.COM> <4513@taux01.nsc.com> <119244@linus.mitre.org> <1990Sep10.215549.26260@uncecs.edu> <119879@linus.mitre.org> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 61 Nntp-Posting-Host: odin In-reply-to: bs@linus.mitre.org's message of 12 Sep 90 15:15:46 GMT On 12 Sep 90 15:15:46 GMT, bs@linus.mitre.org (Robert D. Silverman) said: bs> In any event, your response adresses LANGUAGE issues, not hardware. bs> I'm quite happy to work in assembler to handle double length bs> registers as long as the HARDWARE provides the capability. Agreed - on the other hand you should provide both single * single => double double / single => single and single * single => single single / single => single for compiler writers, because handling register pairs in code generators is notoriously a pain, and many languages only need (more or less regrettably) the all single length version (with or without an overlow indication). bs> What is needed is simply a single, temporary double word. Typically bs> after forming a double word product it is then reduced to a single bs> word. e.g. compute AB/C, AB mod C, etc. bs> Note that for language purposes one could provide an in-line routine bs> to multiply two words and return the upper/lower halves. Similarly bs> a division routine could take the two halves and divide by a third bs> number. You may find agreement in an old and very nice paper (Software Practice and Experience, early seventies) by Martin Richards (he of BCPL and tripos fame) about having just a *single* procedure call he calls muldiv, that returns the result of doing _both_ things, i.e. (single * single => double) / single => single He claims that in *many* case this is all that is needed to obviate the lack of double length integers, or even floating point, as it is the crucial thing for efficient fixed point arithmetic, and it also need never expose double length integers to the language. Such a procedure is easily codable as an inline in GNU C/Objective-C/C++, or with SUN's .il files, and can solve an awful lot of problems. As you say above, one could also have mulrem, as in (single * single => double) % single => single I may be dreaming, but I think that both actually already exist in Forth, and for the same reason as in BCPL: because they are word oriented languages, they only have a single length of integer, and thus the issue of double length (especially if the basic word is 16 bits) is pressing. It may also help to have double shifts, but I am not so sure. -- Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk