Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #46399
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: The problem with implementation defined behaviour. |
| Date | 2016-04-01 21:53 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <ndmqlj$ek8$3@dont-email.me> (permalink) |
| References | (6 earlier) <2016Mar31.125525@mips.complang.tuwien.ac.at> <ea6d7906-5957-4311-a265-02c3038153ce@googlegroups.com> <h4idndgL64APGWDLnZ2dnUU7-NnNnZ2d@supernews.com> <fbf6d82f-953c-45f1-a918-4da4a9df45b7@googlegroups.com> <2016Apr1.134404@mips.complang.tuwien.ac.at> |
Am Fri, 01 Apr 2016 11:44:04 +0000 schrieb Anton Ertl: > Correct. The specification of M*/ starts with > > |Multiply d1 by n1 producing the triple-cell intermediate result t. > |Divide t by +n2 giving the double-cell quotient d2. For benchmarking, and for code that expects to run on a 32 bit system, but actually runs on a 64 bit system, it's wise to tune M*/ by checking first if the double number actually needs the precision, and if not, using the ordinary */ code instead. That's for sure much faster. Given the timing results of div on Core i7, that approach is even done by Intel: use a fast path for divisions where the top half of the number is just sign extended. On the 4stack processor, I decided against implementing a divider unit, and for Goldschmidt division: first find-first-one in the divider, then shift it so that it is between 0.5 and 0.9999 (decimal point left of the actual number), compute the inverse (which is now between 1 and 1.9999, top bit actually not represented), multiply, and then shift right. For 32 bits, that's 3 multiplications, for 64 bits would be 4 multiplications (just one more); supposed there's an 8 bit index table for the starting value. Computing the remainder requires another multiplication. Multiplications are way faster than division, so that's going to pay off, especially in the 64 bit case, and even more with the M*/ case... because here, the inverse computed once is good enough for both divisions. If you don't have find-first-one as instruction, forget it, but ff1 is far easier to implement than SRT division. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
The problem with implementation defined behaviour. Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-29 14:39 +0000
Re: The problem with implementation defined behaviour. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-29 16:20 +0000
Re: The problem with implementation defined behaviour. "Elizabeth D. Rather" <erather@forth.com> - 2016-03-29 09:16 -1000
Re: The problem with implementation defined behaviour. Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-30 00:06 +0000
Re: The problem with implementation defined behaviour. mhx@iae.nl - 2016-03-29 22:09 -0700
Re: The problem with implementation defined behaviour. "Elizabeth D. Rather" <erather@forth.com> - 2016-03-29 21:37 -1000
Re: The problem with implementation defined behaviour. Paul Rubin <no.email@nospam.invalid> - 2016-03-30 00:48 -0700
Re: The problem with implementation defined behaviour. Paul Rubin <no.email@nospam.invalid> - 2016-03-30 00:48 -0700
Re: The problem with implementation defined behaviour. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-30 07:59 +0000
Re: The problem with implementation defined behaviour. mhx@iae.nl - 2016-03-30 10:16 -0700
Re: The problem with implementation defined behaviour. Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-30 23:43 +0000
Re: The problem with implementation defined behaviour. mhx@iae.nl - 2016-03-31 06:01 -0700
Re: The problem with implementation defined behaviour. Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-01 21:36 +0000
Re: The problem with implementation defined behaviour. mhx@iae.nl - 2016-04-01 14:57 -0700
Re: The problem with implementation defined behaviour. Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-01 21:59 +0000
Re: The problem with implementation defined behaviour. mhx@iae.nl - 2016-04-02 00:51 -0700
Re: The problem with implementation defined behaviour. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-01 08:25 +0000
Re: The problem with implementation defined behaviour. Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-01 21:32 +0000
division performance (was: The problem with implementation defined ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-05 11:12 +0000
Re: division performance (was: The problem with implementation defined ...) Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-05 20:45 +0000
Re: division performance (was: The problem with implementation defined ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-06 10:03 +0000
Re: division performance (was: The problem with implementation defined ...) Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-08 22:53 +0000
Re: division performance (was: The problem with implementation defined ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-09 10:14 +0000
Re: division performance (was: The problem with implementation defined ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-09 13:43 +0000
Re: The problem with implementation defined behaviour. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-31 10:55 +0000
Re: The problem with implementation defined behaviour. mhx@iae.nl - 2016-03-31 06:38 -0700
Re: The problem with implementation defined behaviour. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-31 16:21 +0000
Re: The problem with implementation defined behaviour. Paul Rubin <no.email@nospam.invalid> - 2016-03-31 11:49 -0700
Re: The problem with implementation defined behaviour. "Elizabeth D. Rather" <erather@forth.com> - 2016-03-31 10:11 -1000
Re: The problem with implementation defined behaviour. mhx@iae.nl - 2016-04-01 03:53 -0700
Re: The problem with implementation defined behaviour. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-01 11:44 +0000
Re: The problem with implementation defined behaviour. Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-01 21:53 +0000
Re: The problem with implementation defined behaviour. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-04-02 11:46 -0500
Re: The problem with implementation defined behaviour. Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-02 21:43 +0000
Re: The problem with implementation defined behaviour. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-04-03 03:17 -0500
Re: The problem with implementation defined behaviour. hughaguilar96@gmail.com - 2016-04-01 23:54 -0700
Re: The problem with implementation defined behaviour. Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-30 12:58 +0000
Re: The problem with implementation defined behaviour. Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-30 22:22 +0000
Re: The problem with implementation defined behaviour. Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-30 12:55 +0000
Re: The problem with implementation defined behaviour. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-30 07:44 +0000
Re: The problem with implementation defined behaviour. Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-30 13:08 +0000
Re: The problem with implementation defined behaviour. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-30 13:43 +0000
Re: The problem with implementation defined behaviour. Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-30 22:06 +0000
Re: The problem with implementation defined behaviour. trevor <tgritchie@blueyonder.co.uk> - 2016-03-30 13:13 +0100
Re: The problem with implementation defined behaviour. Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-30 13:56 +0000
Re: The problem with implementation defined behaviour. Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-30 12:49 +0000
csiph-web