Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch > #3118 > unrolled thread
| Started by | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| First post | 2011-08-23 10:48 -0700 |
| Last post | 2011-08-29 09:18 -0700 |
| Articles | 20 on this page of 246 — 39 participants |
Back to article view | Back to comp.arch
Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-08-23 10:48 -0700
Re: Solving the Floating-Point Goldilocks Problem! BGB <cr88192@hotmail.com> - 2011-08-23 16:24 -0700
Re: Solving the Floating-Point Goldilocks Problem! Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-08-24 07:20 +0200
Re: Solving the Floating-Point Goldilocks Problem! BGB <cr88192@hotmail.com> - 2011-08-23 23:22 -0700
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-08-24 14:38 -0700
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-08-25 17:42 -0700
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-08-27 09:45 -0700
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-08-27 18:03 -0700
Re: Solving the Floating-Point Goldilocks Problem! Brett Davis <ggtgp@yahoo.com> - 2011-08-26 20:31 -0500
Re: Solving the Floating-Point Goldilocks Problem! BGB <cr88192@hotmail.com> - 2011-08-26 20:08 -0700
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-08-27 02:35 -0700
Re: Solving the Floating-Point Goldilocks Problem! Brett Davis <ggtgp@yahoo.com> - 2011-08-27 15:27 -0500
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-08-27 13:41 -0700
Re: Solving the Floating-Point Goldilocks Problem! Brett Davis <ggtgp@yahoo.com> - 2011-08-27 17:34 -0500
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-08-27 17:40 -0700
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-08-27 17:50 -0700
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-08-28 23:49 -0700
Re: Solving the Floating-Point Goldilocks Problem! BGB <cr88192@hotmail.com> - 2011-08-27 22:40 -0700
Re: Solving the Floating-Point Goldilocks Problem! "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-28 19:33 -0700
Re: Solving the Floating-Point Goldilocks Problem! Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-08-29 13:56 +0200
Re: Solving the Floating-Point Goldilocks Problem! "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-29 09:07 -0700
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-08-29 17:56 +0100
Re: Solving the Floating-Point Goldilocks Problem! "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-29 11:56 -0700
Re: Solving the Floating-Point Goldilocks Problem! Peter Flass <Peter_Flass@Yahoo.com> - 2011-08-29 16:12 -0400
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-08-29 20:46 +0100
Re: Solving the Floating-Point Goldilocks Problem! Kalle Olavi Niemitalo <kon@iki.fi> - 2011-08-30 07:48 +0300
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-08-30 08:22 +0100
Re: Solving the Floating-Point Goldilocks Problem! BGB <cr88192@hotmail.com> - 2011-08-31 11:34 -0700
Re: Solving the Floating-Point Goldilocks Problem! "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-29 22:22 -0700
Re: Solving the Floating-Point Goldilocks Problem! Andrew Reilly <areilly---@bigpond.net.au> - 2011-08-30 11:17 +0000
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-08-30 12:35 +0100
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-08-30 07:02 -0700
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-08-30 15:18 +0100
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-08-30 15:12 -0700
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-08-31 08:30 +0100
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-01 09:54 -0700
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-01 10:09 -0700
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-01 18:01 +0100
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-01 12:25 -0700
Re: Solving the Floating-Point Goldilocks Problem! sidd <sidd@situ.com> - 2011-09-01 20:02 -0400
Re: Solving the Floating-Point Goldilocks Problem! Elliott Roper <nospam@yrl.co.uk> - 2011-09-02 10:27 +0100
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-02 11:33 +0100
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-02 08:09 -0700
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-02 08:12 -0700
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-02 15:50 +0100
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-02 08:49 -0700
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-02 17:00 +0100
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-02 15:55 -0700
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-03 18:06 -0700
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-02 07:58 -0700
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-02 15:56 +0100
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-02 07:42 -0700
Re: Solving the Floating-Point Goldilocks Problem! Andreas Eder <andreas_eder@gmx.net> - 2011-09-02 17:51 +0200
Re: Solving the Floating-Point Goldilocks Problem! sidd <sidd@situ.com> - 2011-08-31 12:11 -0400
Complex Number Representation nmm1@cam.ac.uk - 2011-09-02 21:22 +0100
Re: Solving the Floating-Point Goldilocks Problem! "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-30 07:08 -0700
Re: Solving the Floating-Point Goldilocks Problem! Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-08-31 10:39 +0200
Re: Solving the Floating-Point Goldilocks Problem! "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-31 08:00 -0700
Re: Solving the Floating-Point Goldilocks Problem! Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-08-31 18:38 +0200
Re: Solving the Floating-Point Goldilocks Problem! Peter Flass <Peter_Flass@Yahoo.com> - 2011-08-31 13:18 -0400
Re: Solving the Floating-Point Goldilocks Problem! "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-31 19:09 -0700
Re: Solving the Floating-Point Goldilocks Problem! Brett Davis <ggtgp@yahoo.com> - 2011-08-30 00:19 -0500
Re: Solving the Floating-Point Goldilocks Problem! Brett Davis <ggtgp@yahoo.com> - 2011-08-31 23:46 -0500
Re: Solving the Floating-Point Goldilocks Problem! BGB <cr88192@hotmail.com> - 2011-08-31 09:56 -0700
Re: Solving the Floating-Point Goldilocks Problem! Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-09-01 08:23 +0200
Re: Solving the Floating-Point Goldilocks Problem! BGB <cr88192@hotmail.com> - 2011-08-31 14:02 -0700
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-01 04:02 -0700
Re: Solving the Floating-Point Goldilocks Problem! Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-09-01 19:42 +0200
Re: Solving the Floating-Point Goldilocks Problem! BGB <cr88192@hotmail.com> - 2011-08-31 23:20 -0700
Re: Solving the Floating-Point Goldilocks Problem! "James Van Buskirk" <not_valid@comcast.net> - 2011-09-12 15:53 -0600
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-12 22:31 +0100
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-12 22:56 +0100
Re: Solving the Floating-Point Goldilocks Problem! Walter Bushell <proto@panix.com> - 2011-09-12 21:00 -0400
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-13 10:10 +0100
Re: Solving the Floating-Point Goldilocks Problem! Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-09-13 04:58 +0200
Re: Solving the Floating-Point Goldilocks Problem! Peter Flass <Peter_Flass@Yahoo.com> - 2011-09-01 07:25 -0400
Re: Solving the Floating-Point Goldilocks Problem! Tim Shoppa <shoppa@trailing-edge.com> - 2011-09-01 10:37 -0700
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-01 18:25 +0100
Re: Solving the Floating-Point Goldilocks Problem! Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2011-09-01 19:56 +0100
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-01 12:30 -0700
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-01 12:38 -0700
Re: Solving the Floating-Point Goldilocks Problem! Peter Flass <Peter_Flass@Yahoo.com> - 2011-09-01 17:13 -0400
Re: Solving the Floating-Point Goldilocks Problem! Patrick Scheible <kkt@zipcon.net> - 2011-09-01 14:48 -0700
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-01 22:49 +0100
Re: Solving the Floating-Point Goldilocks Problem! Robert Wessel <robertwessel2@yahoo.com> - 2011-09-01 18:08 -0500
Re: Solving the Floating-Point Goldilocks Problem! "Charlie Gibbs" <cgibbs@kltpzyxm.invalid> - 2011-09-02 00:26 -0800
Re: Solving the Floating-Point Goldilocks Problem! "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-09-02 05:06 -0700
Re: Solving the Floating-Point Goldilocks Problem! Robert Wessel <robertwessel2@yahoo.com> - 2011-09-02 10:46 -0500
Re: Solving the Floating-Point Goldilocks Problem! Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-09-02 12:08 -0700
Re: Solving the Floating-Point Goldilocks Problem! Patrick Scheible <kkt@zipcon.net> - 2011-09-02 13:54 -0700
Re: Solving the Floating-Point Goldilocks Problem! jmfbahciv <See.above@aol.com> - 2011-09-03 14:57 +0000
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-03 15:33 +0100
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-03 13:42 -0700
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-04 08:46 +1000
Re: Solving the Floating-Point Goldilocks Problem! Ahem A Rivet's Shot <steveo@eircom.net> - 2011-09-04 08:05 +0100
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-04 17:44 +1000
Re: Solving the Floating-Point Goldilocks Problem! Ahem A Rivet's Shot <steveo@eircom.net> - 2011-09-04 08:56 +0100
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-04 18:52 +1000
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-04 08:55 -0700
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-04 16:46 +0100
Re: Solving the Floating-Point Goldilocks Problem! jmfbahciv <See.above@aol.com> - 2011-09-04 13:21 +0000
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-04 14:03 +0100
Re: Solving the Floating-Point Goldilocks Problem! Peter Flass <Peter_Flass@Yahoo.com> - 2011-09-04 14:15 -0400
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-04 18:52 +0100
Re: Solving the Floating-Point Goldilocks Problem! Peter Flass <Peter_Flass@Yahoo.com> - 2011-09-04 15:00 -0400
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-04 21:02 +0100
Re: Solving the Floating-Point Goldilocks Problem! Peter Flass <Peter_Flass@Yahoo.com> - 2011-09-04 19:22 -0400
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-05 07:09 +0100
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-05 04:48 +1000
Re: Solving the Floating-Point Goldilocks Problem! Walter Bushell <proto@panix.com> - 2011-09-04 20:18 -0400
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-04 03:53 +1000
Re: Solving the Floating-Point Goldilocks Problem! jmfbahciv <See.above@aol.com> - 2011-09-04 13:21 +0000
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-05 03:57 +1000
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-04 08:47 -0700
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-05 04:03 +1000
Re: Solving the Floating-Point Goldilocks Problem! Peter Flass <Peter_Flass@Yahoo.com> - 2011-09-04 14:30 -0400
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-05 04:49 +1000
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-04 15:53 -0700
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-05 09:55 +1000
Re: Solving the Floating-Point Goldilocks Problem! Piotr Wyderski <peter.pan@neverland.mil> - 2011-10-19 19:17 +0200
Re: Solving the Floating-Point Goldilocks Problem! Ahem A Rivet's Shot <steveo@eircom.net> - 2011-09-04 19:54 +0100
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-04 20:56 +0100
Re: Solving the Floating-Point Goldilocks Problem! Peter Flass <Peter_Flass@Yahoo.com> - 2011-09-04 19:16 -0400
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-04 16:26 -0700
Re: Solving the Floating-Point Goldilocks Problem! Morten Reistad <first@last.name> - 2011-09-05 13:45 +0200
Re: Solving the Floating-Point Goldilocks Problem! Bakul Shah <usenet@bitblocks.com> - 2011-09-05 12:09 -0700
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-05 20:51 +0100
Re: Solving the Floating-Point Goldilocks Problem! Morten Reistad <first@last.name> - 2011-09-06 10:57 +0200
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-06 19:43 +1000
Re: Solving the Floating-Point Goldilocks Problem! Morten Reistad <first@last.name> - 2011-09-06 10:55 +0200
Re: Solving the Floating-Point Goldilocks Problem! Tom Gardner <spamjunk@blueyonder.co.uk> - 2011-09-06 11:36 +0100
OT English Re: Solving the Floating-Point Goldilocks Problem! wclodius@lost-alamos.pet (William Clodius) - 2011-09-05 13:33 -0600
Re: Solving the Floating-Point Goldilocks Problem! Patrick Scheible <kkt@zipcon.net> - 2011-09-05 23:12 -0700
Re: Solving the Floating-Point Goldilocks Problem! "Charlie Gibbs" <cgibbs@kltpzyxm.invalid> - 2011-09-07 09:44 -0800
Re: Solving the Floating-Point Goldilocks Problem! Robert Wessel <robertwessel2@yahoo.com> - 2011-09-03 13:41 -0500
Re: Solving the Floating-Point Goldilocks Problem! scott@slp53.sl.home (Scott Lurndal) - 2011-09-03 21:36 +0000
Re: Solving the Floating-Point Goldilocks Problem! Robert Wessel <robertwessel2@yahoo.com> - 2011-09-03 20:18 -0500
Re: Solving the Floating-Point Goldilocks Problem! Peter Flass <Peter_Flass@Yahoo.com> - 2011-09-04 08:31 -0400
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-04 13:11 +0100
Re: Solving the Floating-Point Goldilocks Problem! scott@slp53.sl.home (Scott Lurndal) - 2011-09-05 17:14 +0000
Re: Solving the Floating-Point Goldilocks Problem! blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-09-07 09:07 +0000
Re: Solving the Floating-Point Goldilocks Problem! Ahem A Rivet's Shot <steveo@eircom.net> - 2011-09-07 12:15 +0100
Re: Solving the Floating-Point Goldilocks Problem! Walter Bushell <proto@panix.com> - 2011-09-07 08:37 -0400
Re: Solving the Floating-Point Goldilocks Problem! Ahem A Rivet's Shot <steveo@eircom.net> - 2011-09-07 13:50 +0100
Re: Solving the Floating-Point Goldilocks Problem! Walter Bushell <proto@panix.com> - 2011-09-07 09:21 -0400
Re: Solving the Floating-Point Goldilocks Problem! Bernd Felsche <berfel@innovative.iinet.net.au> - 2011-09-08 08:42 +0800
Re: Solving the Floating-Point Goldilocks Problem! jmfbahciv <See.above@aol.com> - 2011-09-08 14:10 +0000
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-08 19:09 -0700
Re: Solving the Floating-Point Goldilocks Problem! Patrick Scheible <kkt@zipcon.net> - 2011-09-05 22:50 -0700
Re: Solving the Floating-Point Goldilocks Problem! jmfbahciv <See.above@aol.com> - 2011-09-06 13:45 +0000
Re: Solving the Floating-Point Goldilocks Problem! Patrick Scheible <kkt@zipcon.net> - 2011-09-06 09:08 -0700
Re: Solving the Floating-Point Goldilocks Problem! jmfbahciv <See.above@aol.com> - 2011-09-07 14:13 +0000
Re: Solving the Floating-Point Goldilocks Problem! Patrick Scheible <kkt@zipcon.net> - 2011-09-07 09:42 -0700
Re: Solving the Floating-Point Goldilocks Problem! Bernd Felsche <berfel@innovative.iinet.net.au> - 2011-09-08 09:05 +0800
Re: Solving the Floating-Point Goldilocks Problem! jmfbahciv <See.above@aol.com> - 2011-09-08 14:10 +0000
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-08 04:49 +1000
Re: Solving the Floating-Point Goldilocks Problem! jmfbahciv <See.above@aol.com> - 2011-09-08 14:09 +0000
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-09 03:17 +1000
Re: Solving the Floating-Point Goldilocks Problem! Gene Wirchenko <genew@ocis.net> - 2011-09-10 23:07 -0700
Re: Solving the Floating-Point Goldilocks Problem! Ahem A Rivet's Shot <steveo@eircom.net> - 2011-09-11 09:06 +0100
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-11 10:07 +0100
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-11 06:48 -0700
Re: Solving the Floating-Point Goldilocks Problem! Peter Flass <Peter_Flass@Yahoo.com> - 2011-09-11 08:26 -0400
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-11 13:00 +0100
Re: Solving the Floating-Point Goldilocks Problem! Patrick Scheible <kkt@zipcon.net> - 2011-09-11 07:36 -0700
Re: Solving the Floating-Point Goldilocks Problem! Piotr Wyderski <peter.pan@neverland.mil> - 2011-10-19 19:15 +0200
Re: Solving the Floating-Point Goldilocks Problem! Patrick Scheible <kkt@zipcon.net> - 2011-10-19 14:45 -0700
Re: Solving the Floating-Point Goldilocks Problem! "Charlie Gibbs" <cgibbs@kltpzyxm.invalid> - 2011-10-19 17:13 -0800
Re: Solving the Floating-Point Goldilocks Problem! jmfbahciv <See.above@aol.com> - 2011-10-20 13:38 +0000
Re: Solving the Floating-Point Goldilocks Problem! blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-27 09:01 +0000
Re: Solving the Floating-Point Goldilocks Problem! Peter Flass <Peter_Flass@Yahoo.com> - 2011-09-02 20:41 -0400
Re: Solving the Floating-Point Goldilocks Problem! Ahem A Rivet's Shot <steveo@eircom.net> - 2011-09-03 06:58 +0100
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-03 07:19 +0100
Re: Solving the Floating-Point Goldilocks Problem! Bakul Shah <usenet@bitblocks.com> - 2011-09-02 21:54 -0700
Re: Solving the Floating-Point Goldilocks Problem! Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-09-03 09:05 -0700
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-03 16:42 +0100
Re: Solving the Floating-Point Goldilocks Problem! scott@slp53.sl.home (Scott Lurndal) - 2011-09-03 21:00 +0000
Re: Solving the Floating-Point Goldilocks Problem! Bakul Shah <usenet@bitblocks.com> - 2011-09-03 11:01 -0700
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-03 19:18 +0100
Re: Solving the Floating-Point Goldilocks Problem! Bakul Shah <usenet@bitblocks.com> - 2011-09-03 13:05 -0700
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-04 08:09 +0100
Re: Solving the Floating-Point Goldilocks Problem! scott@slp53.sl.home (Scott Lurndal) - 2011-09-03 21:34 +0000
Re: Solving the Floating-Point Goldilocks Problem! Jean-Marc Bourguet <jm@bourguet.org> - 2011-09-04 22:15 +0200
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-04 21:07 +0100
Re: Solving the Floating-Point Goldilocks Problem! Peter Flass <Peter_Flass@Yahoo.com> - 2011-09-02 20:21 -0400
Re: Solving the Floating-Point Goldilocks Problem! Tim Shoppa <shoppa@trailing-edge.com> - 2011-09-06 09:32 -0700
Re: Solving the Floating-Point Goldilocks Problem! blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-09-07 09:09 +0000
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-07 07:17 -0700
Re: Solving the Floating-Point Goldilocks Problem! Ahem A Rivet's Shot <steveo@eircom.net> - 2011-09-07 16:00 +0100
Re: Solving the Floating-Point Goldilocks Problem! Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2011-09-07 16:40 +0100
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-07 09:57 -0700
Re: Solving the Floating-Point Goldilocks Problem! Patrick Scheible <kkt@zipcon.net> - 2011-09-07 09:39 -0700
Re: Solving the Floating-Point Goldilocks Problem! Morten Reistad <first@last.name> - 2011-09-07 20:47 +0200
Re: Solving the Floating-Point Goldilocks Problem! jmfbahciv <See.above@aol.com> - 2011-09-08 14:09 +0000
Re: Solving the Floating-Point Goldilocks Problem! Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-09-08 09:13 -0700
Re: Solving the Floating-Point Goldilocks Problem! Morten Reistad <first@last.name> - 2011-09-08 18:59 +0200
Re: Solving the Floating-Point Goldilocks Problem! jmfbahciv <See.above@aol.com> - 2011-09-09 15:21 +0000
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-09 12:48 -0700
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-10 06:27 +1000
Re: Solving the Floating-Point Goldilocks Problem! Morten Reistad <first@last.name> - 2011-09-09 23:04 +0200
Re: Solving the Floating-Point Goldilocks Problem! Bernd Felsche <berfel@innovative.iinet.net.au> - 2011-09-08 08:57 +0800
Re: Solving the Floating-Point Goldilocks Problem! jmfbahciv <See.above@aol.com> - 2011-09-08 14:10 +0000
Re: Solving the Floating-Point Goldilocks Problem! "Charlie Gibbs" <cgibbs@kltpzyxm.invalid> - 2011-09-08 07:50 -0800
Re: Solving the Floating-Point Goldilocks Problem! Walter Bushell <proto@panix.com> - 2011-09-08 12:07 -0400
Re: Solving the Floating-Point Goldilocks Problem! Walter Bushell <proto@panix.com> - 2011-09-08 12:10 -0400
Re: Solving the Floating-Point Goldilocks Problem! Ahem A Rivet's Shot <steveo@eircom.net> - 2011-09-08 17:38 +0100
Re: Solving the Floating-Point Goldilocks Problem! Seebs <usenet-nospam@seebs.net> - 2011-09-09 03:43 +0000
Re: Solving the Floating-Point Goldilocks Problem! Robert Wessel <robertwessel2@yahoo.com> - 2011-09-08 12:21 -0500
Re: Solving the Floating-Point Goldilocks Problem! Peter Flass <Peter_Flass@Yahoo.com> - 2011-09-01 17:09 -0400
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-02 08:59 +1000
Re: Solving the Floating-Point Goldilocks Problem! blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-09-07 09:07 +0000
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-07 20:03 +1000
Re: Solving the Floating-Point Goldilocks Problem! blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-09-08 16:55 +0000
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-09 03:52 +1000
Re: Solving the Floating-Point Goldilocks Problem! blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-01 15:57 +0000
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-10-02 05:51 +1100
Re: Solving the Floating-Point Goldilocks Problem! blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-07 11:31 +0000
Re: Solving the Floating-Point Goldilocks Problem! Morten Reistad <first@last.name> - 2011-09-07 14:08 +0200
Re: Solving the Floating-Point Goldilocks Problem! Ahem A Rivet's Shot <steveo@eircom.net> - 2011-09-07 14:18 +0100
Re: Solving the Floating-Point Goldilocks Problem! Huge <Huge@nowhere.much.invalid> - 2011-09-07 14:05 +0000
Re: Solving the Floating-Point Goldilocks Problem! Morten Reistad <first@last.name> - 2011-09-07 20:54 +0200
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-08 05:27 +1000
Re: Solving the Floating-Point Goldilocks Problem! timcaffrey@aol.com (Tim McCaffrey) - 2011-09-16 18:48 +0000
Re: Solving the Floating-Point Goldilocks Problem! sidd <sidd@situ.com> - 2011-09-07 18:53 -0400
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-08 04:37 +1000
Re: Solving the Floating-Point Goldilocks Problem! Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-09-08 10:19 +0200
Re: Solving the Floating-Point Goldilocks Problem! kenney@cix.compulink.co.uk - 2011-09-08 05:14 -0500
Re: Solving the Floating-Point Goldilocks Problem! Gene Wirchenko <genew@ocis.net> - 2011-09-11 12:58 -0700
Re: Solving the Floating-Point Goldilocks Problem! Ahem A Rivet's Shot <steveo@eircom.net> - 2011-09-12 10:01 +0100
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-12 19:35 +1000
Re: Solving the Floating-Point Goldilocks Problem! Patrick Scheible <kkt@zipcon.net> - 2011-09-12 09:25 -0700
Re: Solving the Floating-Point Goldilocks Problem! Michael Black <et472@ncf.ca> - 2011-09-12 13:27 -0400
Re: Solving the Floating-Point Goldilocks Problem! Ben Pfaff <blp@cs.stanford.edu> - 2011-09-12 10:41 -0700
Re: Solving the Floating-Point Goldilocks Problem! Patrick Scheible <kkt@zipcon.net> - 2011-09-12 11:34 -0700
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-13 05:40 +1000
Re: Solving the Floating-Point Goldilocks Problem! Michael Black <et472@ncf.ca> - 2011-09-12 15:53 -0400
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-12 13:08 -0700
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-08 04:14 +1000
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-07 11:31 -0700
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-08 05:35 +1000
Re: Solving the Floating-Point Goldilocks Problem! Bernd Felsche <berfel@innovative.iinet.net.au> - 2011-09-08 08:40 +0800
Re: Solving the Floating-Point Goldilocks Problem! Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-09-07 20:25 +0200
Re: Solving the Floating-Point Goldilocks Problem! blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-09-08 16:58 +0000
Re: Solving the Floating-Point Goldilocks Problem! Robert Wessel <robertwessel2@yahoo.com> - 2011-09-08 12:31 -0500
Re: Solving the Floating-Point Goldilocks Problem! Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-08-30 13:46 +0200
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-08-29 09:18 -0700
Page 1 of 13 [1] 2 3 … 13 Next page →
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2011-08-23 10:48 -0700 |
| Subject | Solving the Floating-Point Goldilocks Problem! |
| Message-ID | <94ca7874-13a5-43eb-b482-0abbdcf4fdd4@df3g2000vbb.googlegroups.com> |
On my web site, on the page http://www.quadibloc.com/arch/perint.htm I note that there are rationales, however shaky, that suggest that other sizes for floating-point numbers instead of 32 bits and 64 bits may be useful. 36 bits gives just a little extra precision, which was sorely missed when the 360 replaced the 7094. 48 bits can give the same precision and exponent range as is customarily provided on pocket calculators, and thus one would at least suspect it's closer to the "sweet spot" for many scientific calculations than either conventional 32 bit single precision or conventional 64 bit double precision. Well, on the series of pages that begins with the page noted above, I considered a number of possible ways of dealing with the issue. But these various ways were quite elaborate and complicated, tending to require perhaps a 48-bit wide memory bus or a 120-bit wide memory bus, circuits to divide the contents of an index register by three or fifteen, and other potentially impractical things. Well, now, on the page http://www.quadibloc.com/arch/per05.htm I've outlined a scheme which uses a 256-bit wide memory bus and which requires only the most trivial transformations to be applied to index register contents to address arrays packed according to that scheme. John Savard
[toc] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2011-08-23 16:24 -0700 |
| Message-ID | <j31d42$n9k$1@news.albasani.net> |
| In reply to | #3118 |
On 8/23/2011 10:48 AM, Quadibloc wrote: > On my web site, on the page > > http://www.quadibloc.com/arch/perint.htm > > I note that there are rationales, however shaky, that suggest that > other sizes for floating-point numbers instead of 32 bits and 64 bits > may be useful. > > 36 bits gives just a little extra precision, which was sorely missed > when the 360 replaced the 7094. > > 48 bits can give the same precision and exponent range as is > customarily provided on pocket calculators, and thus one would at > least suspect it's closer to the "sweet spot" for many scientific > calculations than either conventional 32 bit single precision or > conventional 64 bit double precision. > I use a variant of 48-bit floats already for in-pointer floating-point values on 64-bit systems. the main reason is mostly for fitting the value directly into a pointer and still allowing the pointer to point to other things (although it is technically possible to do the reverse and shove a 64-bit pointer into a +NaN for a double, relying on the fact that +NaN has more bits free to use than the current OS/HW-imposed address-space sizes...). currently, a 28-bit float scheme is used on 32-bit systems, again because it has "nearly as much" accuracy as a 32-bit float. at present, for both simplicity and performance, the 48 and 28 bit values are shaved doubles and floats. previously I had used a custom float28, but then noted some bugs with the encoding/decoding with some values (probably due to an arithmetic issue or similar), and switching to just a 32-bit float with 4 bits shaved off was faster and simpler (even if potentially slightly less accurate). in the past I had also used a custom 24-bit scheme (prior to the present 28-bit one). for arithmetic, one pulls the values out of the pointers, does arithmetic on them, and puts the result back into a pointer. note: this is mostly for sake of a dynamically-typed VM. also, although some people can use the "double for everything with pointers and integers shoved into NaNs" strategy, this will take up 2x the memory space on 32-bit systems, and offer relatively little gain on 64-bit systems (slightly more accurate floating-point values, for the need to now "extract" pointers from references, rather than just being able to cast them). > Well, on the series of pages that begins with the page noted above, I > considered a number of possible ways of dealing with the issue. But > these various ways were quite elaborate and complicated, tending to > require perhaps a 48-bit wide memory bus or a 120-bit wide memory bus, > circuits to divide the contents of an index register by three or > fifteen, and other potentially impractical things. > > Well, now, on the page > > http://www.quadibloc.com/arch/per05.htm > > I've outlined a scheme which uses a 256-bit wide memory bus and which > requires only the most trivial transformations to be applied to index > register contents to address arrays packed according to that scheme. > > John Savard
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <"terje.mathisen at tmsw.no"> |
|---|---|
| Date | 2011-08-24 07:20 +0200 |
| Message-ID | <l9eei8-li72.ln1@ntp6.tmsw.no> |
| In reply to | #3120 |
BGB wrote: > I use a variant of 48-bit floats already for in-pointer floating-point > values on 64-bit systems. Top bits/bottom bits? I.e. where is the pointer (just 16 bits?)and where is the float? > > the main reason is mostly for fitting the value directly into a pointer > and still allowing the pointer to point to other things (although it is > technically possible to do the reverse and shove a 64-bit pointer into a > +NaN for a double, relying on the fact that +NaN has more bits free to > use than the current OS/HW-imposed address-space sizes...). > > currently, a 28-bit float scheme is used on 32-bit systems, again > because it has "nearly as much" accuracy as a 32-bit float. That sounds like reserving the bottom 4 bits for up to 16 different type tags? > > at present, for both simplicity and performance, the 48 and 28 bit > values are shaved doubles and floats. previously I had used a custom > float28, but then noted some bugs with the encoding/decoding with some > values (probably due to an arithmetic issue or similar), and switching > to just a 32-bit float with 4 bits shaved off was faster and simpler > (even if potentially slightly less accurate). OK, that does sound like reserving the bottom 4 bits, which of course makes coding/decoding significantly slower than the actual fp operations, but otoh I guess you only do the encoding when you store the final value? > > > in the past I had also used a custom 24-bit scheme (prior to the present > 28-bit one). > > for arithmetic, one pulls the values out of the pointers, does > arithmetic on them, and puts the result back into a pointer. > > > note: this is mostly for sake of a dynamically-typed VM. > also, although some people can use the "double for everything with > pointers and integers shoved into NaNs" strategy, this will take up 2x > the memory space on 32-bit systems, and offer relatively little gain on > 64-bit systems (slightly more accurate floating-point values, for the > need to now "extract" pointers from references, rather than just being > able to cast them). Ouch! Using NaNs can cause partial ieee implementations to slow down by several orders of magnitude, since they will trap to a sw handler. I assume your target platform(s) don't have this particular problem? Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2011-08-23 23:22 -0700 |
| Message-ID | <j325kf$1si$1@news.albasani.net> |
| In reply to | #3121 |
On 8/23/2011 10:20 PM, Terje Mathisen wrote: > BGB wrote: >> I use a variant of 48-bit floats already for in-pointer floating-point >> values on 64-bit systems. > > Top bits/bottom bits? > > I.e. where is the pointer (just 16 bits?)and where is the float? the float goes in the low 48 bits. the high bits are currently just a magic value outside the normal address range. say, if we are dealing with a 64-bit system such as x86-64, and have a 48 bit address space, then only: 0x00000000_00000000 - 0x0000FFFF_FFFFFFFF and: 0xFFFF0000_00000000 - 0xFFFFFFFF_FFFFFFFF are valid address ranges. values like: 0x7F000000_00000000 - 0x7FFFFFFF_FFFFFFFF are essentially free, allowing using the high 16-bits to encode the range type, and the low 48 to encode the value. 32-bit x86 is similar, except that using this scheme leaves far less space: current Windows and Linux only have 0xC0000000 - 0xFFFFFFFF usable as a free range (and only because the OS uses them for itself), and apparently some Linux builds will not reserve this address range, leaving the client process to detect this and potentially resort to mmap to give an address range to divide up. however, with only a 30 bit space, and one needs 2 bits for the type, this only leaves 28 for a large value. one can get 2 more usable bits by tagging the low 2 bits, but the drawback here is that one is then limited to aligned pointers (say, one can't point into a string or array). using the high-bits just means the ability to reserve sufficiently large chunks of address space, but does not impact pointers elsewhere. this also means potentially the ability to type-tag things outside the GC/VM/... proper, say one can type-tag function pointers and similar. >> >> the main reason is mostly for fitting the value directly into a pointer >> and still allowing the pointer to point to other things (although it is >> technically possible to do the reverse and shove a 64-bit pointer into a >> +NaN for a double, relying on the fact that +NaN has more bits free to >> use than the current OS/HW-imposed address-space sizes...). >> >> currently, a 28-bit float scheme is used on 32-bit systems, again >> because it has "nearly as much" accuracy as a 32-bit float. > > That sounds like reserving the bottom 4 bits for up to 16 different type > tags? except it is the high 4 bits. technically, the float is shoved into an integer and shifted right 4 bits, and then added to the base for the flonum range. >> >> at present, for both simplicity and performance, the 48 and 28 bit >> values are shaved doubles and floats. previously I had used a custom >> float28, but then noted some bugs with the encoding/decoding with some >> values (probably due to an arithmetic issue or similar), and switching >> to just a 32-bit float with 4 bits shaved off was faster and simpler >> (even if potentially slightly less accurate). > > OK, that does sound like reserving the bottom 4 bits, which of course > makes coding/decoding significantly slower than the actual fp > operations, but otoh I guess you only do the encoding when you store the > final value? actually, decoding: take value, shift-left 4 bits, return as float. encoding: shift right 4 bits, add base address, return as pointer. it is a little costly, but things could always be far worse. >> >> >> in the past I had also used a custom 24-bit scheme (prior to the present >> 28-bit one). >> >> for arithmetic, one pulls the values out of the pointers, does >> arithmetic on them, and puts the result back into a pointer. >> >> >> note: this is mostly for sake of a dynamically-typed VM. >> also, although some people can use the "double for everything with >> pointers and integers shoved into NaNs" strategy, this will take up 2x >> the memory space on 32-bit systems, and offer relatively little gain on >> 64-bit systems (slightly more accurate floating-point values, for the >> need to now "extract" pointers from references, rather than just being >> able to cast them). > > Ouch! > > Using NaNs can cause partial ieee implementations to slow down by > several orders of magnitude, since they will trap to a sw handler. > > I assume your target platform(s) don't have this particular problem? > I haven't tested for this personally, but it seems to work fine AFAICT on x86 and x86-64, although granted if one is trying to use a pointer/... in a real-valued calculation, they are probably doing something wrong. at least in my implementation of the concept (not as often used, but it is available), I treated the reference as a 64-bit integer value except when treating it as a double. in C, the conversions can be done using pointers and casting. say: double f; uint64_t i; i=*(uint64_t *)(&f); and: f=*(double *)(&i); if using SSE and ASM, then it is mostly movd/movq between the SSE registers and GPRs: movq rax, xmm3 which theoretically has a slowdown (say, if xmm3 previously held a double), but I haven't really noticed it (I suspect it is fairly small). or such...
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2011-08-24 14:38 -0700 |
| Message-ID | <9545b042-5df6-49d4-9062-dcdafd38e18e@h6g2000yqe.googlegroups.com> |
| In reply to | #3118 |
I have now added, on the page http://www.quadibloc.com/arch/ar0502.htm a description of a feature for my imaginary computer architecture which makes use of this technique to allow efficient processing of large arrays of 36-bit or 48-bit numbers that are accessed randomly and won't fit in cache... thus complementing the data memory width control feature, which provides a more convenient and comprehensive way of handling data of unusual lengths under more ordinary conditions. This also allowed me to correct some mistakes that had crept into the arrangement of the Program Status Block the last time I had modified it. John Savard
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2011-08-25 17:42 -0700 |
| Message-ID | <8ce5cd46-542e-4a7d-9bda-38b64f617409@z7g2000vbp.googlegroups.com> |
| In reply to | #3128 |
On Aug 24, 3:38 pm, Quadibloc <jsav...@ecn.ab.ca> wrote: > I have now added, on the page > > http://www.quadibloc.com/arch/ar0502.htm > > a description of a feature for my imaginary computer architecture > which makes use of this technique to allow efficient processing of > large arrays of 36-bit or 48-bit numbers that are accessed randomly > and won't fit in cache... thus complementing the data memory width > control feature, which provides a more convenient and comprehensive > way of handling data of unusual lengths under more ordinary > conditions. > > This also allowed me to correct some mistakes that had crept into the > arrangement of the Program Status Block the last time I had modified > it. Further mistakes have been corrected; the diagram of the Program Status Block has finally been split into four pieces, and the description has been reordered to reflect changes in the organization of the PSB. As well, another missing feature has been added to the architecture. Instead of merely choosing between 32-bit and 64-bit addressing, there are now intermediate options where the base registers are still 32 bits long, but their contents are shifted left by 4, 8, or 12 bits before being used in address calculation. Thus, one can choose to operate with 32 bit, 36 bit, 40 bit, 44 bit, or 64 bit virtual addresses, with respective maximum memory sizes of 4 gigabytes, 64 gigabytes, 1 terabyte, 16 terabytes, or 64 exabytes. John Savard
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2011-08-27 09:45 -0700 |
| Message-ID | <408cf942-b9ce-48ee-8a47-32bc8a0aa307@z15g2000yqk.googlegroups.com> |
| In reply to | #3140 |
On Aug 25, 6:42 pm, Quadibloc <jsav...@ecn.ab.ca> wrote: > As well, another missing feature has been added to the architecture. > Instead of merely choosing between 32-bit and 64-bit addressing, there > are now intermediate options where the base registers are still 32 > bits long, but their contents are shifted left by 4, 8, or 12 bits > before being used in address calculation. On this page, http://www.quadibloc.com/arch/ar0703.htm I have finally added - not yet completely - one feature the architecture sorely needed. Due to the large amount of flexibility I had provided it with, aside from register contents (which are rather large, given that the machine has sets of vector registers like the Cray-1 and its later successors) context switching in the case of interrupts has a large amount of overhead, since it has two program counters (for Honeywell-800 like bisequential operation) and a 512-bit Program Status Block. Since most of that Program Status Block deals with optional features that do not need to be used in order to perform useful computations, an option has now been provided where a 64-bit Program Status Word includes a four-bit index field to select from one of sixteen possible values for the rest of the Program Status Block. Bisequential operation may also be globally disabled. This lets the processor operate with interrupt overhead comparable to a conventional architecture - except when switching between different tasks that both use the vector registers. (When they're not used by a process, features already exist to lock out access to them. As well, register remapping is expected to be provided on larger implementations.) John Savard
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2011-08-27 18:03 -0700 |
| Message-ID | <4f81efc4-ecb3-4de1-9c5a-1292f50dbe9a@33g2000yqu.googlegroups.com> |
| In reply to | #3177 |
On Aug 27, 10:45 am, Quadibloc <jsav...@ecn.ab.ca> wrote: > Since most of that Program Status Block deals with optional features > that do not need to be used in order to perform useful computations, > an option has now been provided where a 64-bit Program Status Word > includes a four-bit index field to select from one of sixteen possible > values for the rest of the Program Status Block. Bisequential > operation may also be globally disabled. This feature has been removed, as some re-thinking is required. The first 96 bits of the Program Status Block also need to be able to assume any value, as they are used to keep track of individual processes. This means that getting rid of the various operating modes would not reduce the size of the program status information by a useful amount. John Savard
[toc] | [prev] | [next] | [standalone]
| From | Brett Davis <ggtgp@yahoo.com> |
|---|---|
| Date | 2011-08-26 20:31 -0500 |
| Message-ID | <ggtgp-D45E45.20310626082011@netnews.mchsi.com> |
| In reply to | #3118 |
In article <94ca7874-13a5-43eb-b482-0abbdcf4fdd4@df3g2000vbb.googlegroups.com>, Quadibloc <jsavard@ecn.ab.ca> wrote: > Well, now, on the page > > http://www.quadibloc.com/arch/per05.htm > > I've outlined a scheme which uses a 256-bit wide memory bus and which > requires only the most trivial transformations to be applied to index > register contents to address arrays packed according to that scheme. It is perhaps more useful to look at the other end of the spectrum, ATI supports 16 bit floats, and 24 bit, also have heard of packing 3 floats in 32 bits. Survey of Floating-Point Formats http://mrob.com/pub/math/floatformats.html
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2011-08-26 20:08 -0700 |
| Message-ID | <j39nc8$lsf$1@news.albasani.net> |
| In reply to | #3164 |
On 8/26/2011 6:31 PM, Brett Davis wrote: > In article > <94ca7874-13a5-43eb-b482-0abbdcf4fdd4@df3g2000vbb.googlegroups.com>, > Quadibloc<jsavard@ecn.ab.ca> wrote: >> Well, now, on the page >> >> http://www.quadibloc.com/arch/per05.htm >> >> I've outlined a scheme which uses a 256-bit wide memory bus and which >> requires only the most trivial transformations to be applied to index >> register contents to address arrays packed according to that scheme. > > It is perhaps more useful to look at the other end of the spectrum, > ATI supports 16 bit floats, and 24 bit, also have heard of packing > 3 floats in 32 bits. > > Survey of Floating-Point Formats > http://mrob.com/pub/math/floatformats.html yep, 16 and 24 bit floats are nifty. 16 is good at memory saving. 24 is good for shoving a float into 3 bytes, or if one can't reasonably reserve a 28 bit glob of address space to shove a float into a 32-bit pointer. 1.7.16 actually sounds about like the format I used. 1.4.3 is also good for lossy compression of 16-bit data. I before also developed a scheme for packing a unit quaternion into 3 bytes, mostly intended for animation purposes: a 3x3 or 4x4 transformation matrix is costly to send, say, over the network; a 3x3 rotation matrix (subset of a 4x4 translation matrix) can be encoded as a unit quaternion (which requires 4 normalized floating-point values); a unit quaternion can be encoded as 3 numbers: 2 to encode an axis (as 2 angles), and 1 to encode an angle; these 3 numbers can be shoved into 24 bits. also, shoving 3 floats into say, 24 or 32 bits, allows also expressing an origin. then, one can cram an entire transformation matrix in 6 bytes (48 bits). if one gives a few more bits, an 8 byte (64-bit) format is also possible. these matrices are not necessarily all that good for expressing the position of an object in a scene (we generally need at least a 12 or 16 bit integer for something like this), this does generally work fairly well for things like encoding the rotations for the all of the joints in a skeletal model or rag-doll. an example of a 64 bit translation matrix: 9 bits: phi (0 - 2pi) 9 bits: theta (0 - pi) 10 bits: rho (0 - 2 pi) 1.5.6 float: x-offset 1.5.6 float: y-offset 1.5.6 float: z-offset so: 28 bits rotation, 36 bits origin. a trivial 128-bit variant (sufficient for scene object placement): an example of a 64 bit translation matrix: 19 bits: phi (0 - 2pi) 18 bits: theta (0 - pi) 19 bits: rho (0 - 2pi) 1.7.16 float: x-offset 1.7.16 float: y-offset 1.7.16 float: z-offset so: 56 bits rotation, 72 bits origin. accurate to one unit for a scene of +-65536 units, with a fairly large max size. where: phi and theta would encode the axis (phi is the angle around the zenith, and theta the distance from the zenith, with rho giving the rotation along the indicated axis). or such...
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2011-08-27 02:35 -0700 |
| Message-ID | <4bc3716a-f2d9-48cd-a675-61475db88f6c@en1g2000vbb.googlegroups.com> |
| In reply to | #3164 |
On Aug 26, 7:31 pm, Brett Davis <gg...@yahoo.com> wrote: > It is perhaps more useful to look at the other end of the spectrum, Short floating-point numbers indeed have their applications, such as in graphics. The architecture in question _does_ support a 16-bit floating-point type, but not for normal floating-point instructions. Instead, as is the case for other conventional microprocessor architectures, it supports them only in what are referred to as "short vector instructions": http://www.quadibloc.com/arch/ar0103.htm analogous to MMX and AltiVec. John Savard
[toc] | [prev] | [next] | [standalone]
| From | Brett Davis <ggtgp@yahoo.com> |
|---|---|
| Date | 2011-08-27 15:27 -0500 |
| Message-ID | <ggtgp-9EA2C0.15274527082011@netnews.mchsi.com> |
| In reply to | #3172 |
In article <4bc3716a-f2d9-48cd-a675-61475db88f6c@en1g2000vbb.googlegroups.com>, Quadibloc <jsavard@ecn.ab.ca> wrote: > On Aug 26, 7:31 pm, Brett Davis <gg...@yahoo.com> wrote: > > > It is perhaps more useful to look at the other end of the spectrum, > > Short floating-point numbers indeed have their applications, such as > in graphics. > > The architecture in question _does_ support a 16-bit floating-point > type, but not for normal floating-point instructions. Instead, as is > the case for other conventional microprocessor architectures, it > supports them only in what are referred to as "short vector > instructions": > > http://www.quadibloc.com/arch/ar0103.htm Short floats are for storage and transport, I don't think you should try and do math with short floats. Convert on load and store. The graphics chips convert to 32 bit float, otherwise the math quickly breaks down. BGB made an excellent post, there is great use/need for compressed floats.
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2011-08-27 13:41 -0700 |
| Message-ID | <decaa5c2-121c-4b4e-a61a-781d390b372a@o10g2000vby.googlegroups.com> |
| In reply to | #3187 |
On Aug 27, 2:27 pm, Brett Davis <gg...@yahoo.com> wrote: > Short floats are for storage and transport, I don't think you should > try and do math with short floats. Convert on load and store. > > The graphics chips convert to 32 bit float, otherwise the math quickly > breaks down. It certainly is true that having extra precision helps avoid problems in a long series of calculations. I don't know what the graphics chips usually do. > BGB made an excellent post, there is great use/need for compressed floats. Well, yes - for specialized graphics programs. I don't recall a REAL*2 type offered in FORTRAN compilers. That's why the feature is where it belongs - in the specialized instructions that will be used for graphics. John Savard
[toc] | [prev] | [next] | [standalone]
| From | Brett Davis <ggtgp@yahoo.com> |
|---|---|
| Date | 2011-08-27 17:34 -0500 |
| Message-ID | <ggtgp-7DBD35.17343827082011@netnews.mchsi.com> |
| In reply to | #3191 |
In article <decaa5c2-121c-4b4e-a61a-781d390b372a@o10g2000vby.googlegroups.com>, Quadibloc <jsavard@ecn.ab.ca> wrote: > On Aug 27, 2:27 pm, Brett Davis <gg...@yahoo.com> wrote: > > > Short floats are for storage and transport, I don't think you should > > try and do math with short floats. Convert on load and store. > > > > The graphics chips convert to 32 bit float, otherwise the math quickly > > breaks down. > > It certainly is true that having extra precision helps avoid problems > in a long series of calculations. I don't know what the graphics chips > usually do. > > > BGB made an excellent post, there is great use/need for compressed floats. > > Well, yes - for specialized graphics programs. I don't recall a REAL*2 > type offered in FORTRAN compilers. That's why the feature is where it > belongs - in the specialized instructions that will be used for > graphics. If you followed the Larrabee threads or GPU compute threads then you know that GPUs are getting close to being general purpose CPUs today. x86 does not support short floats, but people are using them anyway. The real bottle neck is bandwidth to/from memory and to/from the graphics chip. These days of infinite ALU compute, but limited bandwidth will stay with us as everything goes embedded due to heat cost. I look at my PC and my iPad and my iPhone and all of them need good graphics, all could benefit from adding native short float support. Engineers that allocate a gigabyte array of doubles to hold 12 bit analog to digital samples are just not being smart. Everything that matters gets compressed today, or will be compressed. Speaking of which i hope you not making the classic RISC mistake of requiring data alignment to natural data sizes. Compressed data does not respect alignment, and all data is compressed. If you really want your CPU design to be novel and stand out and be noticed then add a programmable data structure decoder/encoder block to the load store pipeline. This would be more efficient than calling an external macro block and DMAing the data back and forth to the CPU, as is common today in the embedded world. This will make your vector processor simpler/smaller as you only need to support about four data data types: Double, float, int, char. Altivec is for software encode/decode in the registers, a mistake.
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2011-08-27 17:40 -0700 |
| Message-ID | <6d1c9b0f-b866-456a-9f3a-2f2d48c30093@d25g2000yqh.googlegroups.com> |
| In reply to | #3193 |
On Aug 27, 4:34 pm, Brett Davis <gg...@yahoo.com> wrote: > If you really want your CPU design to be novel and stand out and be > noticed then add a programmable data structure decoder/encoder block > to the load store pipeline. There is something like that in the architecture: http://www.quadibloc.com/arch/ar020502.htm describes Code 12 microprograms - these programs read programs on the fly and reformat them; code as well as, optionally, data; and the part which reformats floating-point data can also be invoked separately for use with normal programs, as described in a section of this page http://www.quadibloc.com/arch/ar0502.htm under the heading "Operand Filtering". However, this is mostly intended for compatibility use with legacy programs, as its implementation is not envisaged to be particularly efficient. John Savard
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2011-08-27 17:50 -0700 |
| Message-ID | <dca26f5a-53d3-4114-9956-e62f9317ed7f@h9g2000vbr.googlegroups.com> |
| In reply to | #3193 |
On Aug 27, 4:34 pm, Brett Davis <gg...@yahoo.com> wrote: > Speaking of which i hope you not making the classic RISC mistake of > requiring data alignment to natural data sizes. Compressed data does > not respect alignment, and all data is compressed. Depends what you mean by "requiring". Like the IBM 370, yes, this architecture will handle unaligned operands. In most operating modes, however, they will only be *addressable* without indexing or a bad base register value if you use longer format more general instructions instead of the most ordinary memory-reference instructions. To save opcode space, it usually makes use of a technique most notably used by the SEL 32 computer - the last few bits of the displacement field are used to distinguish between operand types. John Savard
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2011-08-28 23:49 -0700 |
| Message-ID | <b51f0fb4-7936-457c-8ab8-129c2de423a7@t7g2000vbv.googlegroups.com> |
| In reply to | #3193 |
On Aug 27, 4:34 pm, Brett Davis <gg...@yahoo.com> wrote: > If you really want your CPU design to be novel and stand out and be > noticed It should also be noted that its main purpose is to be an illustrative design explaining "how computers work", and so it's actually as "ordinary" and pedestrian as possible... _except_ for including just about every feature from every other computer architecture, so that they're all present to explain. The idea also is that if only one computer architecture must dominate, the way the x86 does, then it's necessary to ensure we don't "lose anything" as a result. But that means individual cores are bulkier - of course, if the specialized instructions are needed, then they would perform better. John Savard
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2011-08-27 22:40 -0700 |
| Message-ID | <j3ckmc$qsp$1@news.albasani.net> |
| In reply to | #3191 |
On 8/27/2011 1:41 PM, Quadibloc wrote: > On Aug 27, 2:27 pm, Brett Davis<gg...@yahoo.com> wrote: > >> Short floats are for storage and transport, I don't think you should >> try and do math with short floats. Convert on load and store. >> >> The graphics chips convert to 32 bit float, otherwise the math quickly >> breaks down. > > It certainly is true that having extra precision helps avoid problems > in a long series of calculations. I don't know what the graphics chips > usually do. > AFAICT, typically they load values from bytes or float16 values, perform calculations in float32, and then store the results back into bytes or float16 when done. for example, the textures are often bytes (or sometimes texture compression is used, in which case often one is really only looking at a few bits per component, but this allows getting more graphics into video memory). http://en.wikipedia.org/wiki/S3_Texture_Compression a partial reason being that if one actually does much math directly with byte or float16 values, then accuracy will degrade rapidly. however, using 32-bit floats for calculations tends to be notably more stable (despite the limited precision of both the input and output data). >> BGB made an excellent post, there is great use/need for compressed floats. > > Well, yes - for specialized graphics programs. I don't recall a REAL*2 > type offered in FORTRAN compilers. That's why the feature is where it > belongs - in the specialized instructions that will be used for > graphics. > actually, I also use stuff like this sometimes in things like audio signal processing as well. another notable use-case is, interestingly, trying to shove a lot of update data over a network connection for things like multiplayer gaming, where a lot may be happening in the scene, keeping latency low is a high priority, and where the amount of data one can reliably get over the internet in a timely manner is often surprisingly limited, ... many protocols then make use of compression schemes to try to keep messages small. (nevermind the issue of TCP vs UDP for the moment...). for example, consider a user has a 1.5 Mbps internet connection (say, home ADSL), but one can only reliably get around a 48 kbps stream to go through without instability or interruptions (much like how a 96 or 128kbps internet-radio stream will often stall and need to rebuffer, but a 48 kbps stream rarely stalls). effectively, this means there is around 6kB/s which can be used for the game updates. at 10Hz (generally needed so that things still feel reasonably responsive), this means each frame update needs to be under around 614 bytes or so for optimal player experience. if then one then considers that there might be enemies and projectiles flying all over the place (or the player is death-matching against 10-20 or so other people), and a raw transformation matrix would require 64 bytes (10% of the total reasonable per-frame message size), then compression seems to make a bit more sense. hence, why it makes some sense to try to shave bits where possible. even within a single computer, using compact representations often makes some sense for things like saving memory (memory saved in one place is more memory that can be used for something else, and again, with 3D stuff, ones' memory doesn't necessarily go all that far sometimes). or such...
[toc] | [prev] | [next] | [standalone]
| From | "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> |
|---|---|
| Date | 2011-08-28 19:33 -0700 |
| Message-ID | <4E5AFA77.70008@SPAM.comp-arch.net> |
| In reply to | #3164 |
On 8/26/2011 6:31 PM, Brett Davis wrote: > In article > <94ca7874-13a5-43eb-b482-0abbdcf4fdd4@df3g2000vbb.googlegroups.com>, > Quadibloc<jsavard@ecn.ab.ca> wrote: >> Well, now, on the page >> >> http://www.quadibloc.com/arch/per05.htm >> >> I've outlined a scheme which uses a 256-bit wide memory bus and which >> requires only the most trivial transformations to be applied to index >> register contents to address arrays packed according to that scheme. > > It is perhaps more useful to look at the other end of the spectrum, > ATI supports 16 bit floats, and 24 bit, also have heard of packing > 3 floats in 32 bits. > > Survey of Floating-Point Formats > http://mrob.com/pub/math/floatformats.html In case you are interested, I have run into FP7 and FP8, 7 and 8 bit formats, in Intel and ATI GPUs. http://semipublic.comp-arch.net/wiki/Collection_of_Unusual_Datatypes_and_Formats
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <"terje.mathisen at tmsw.no"> |
|---|---|
| Date | 2011-08-29 13:56 +0200 |
| Message-ID | <obbsi8-67p2.ln1@ntp6.tmsw.no> |
| In reply to | #3219 |
Andy "Krazy" Glew wrote: > On 8/26/2011 6:31 PM, Brett Davis wrote: >> Survey of Floating-Point Formats >> http://mrob.com/pub/math/floatformats.html > > In case you are interested, I have run into FP7 and FP8, 7 and 8 bit > formats, in Intel and ATI GPUs. > > http://semipublic.comp-arch.net/wiki/Collection_of_Unusual_Datatypes_and_Formats > Nice article, thanks! Block fp formats have been quite common afaik in the embedded world, where you would store an array of (integer) mantissas, all sharing a common exponent. With a few guard bits to reduce the need for block renormalization this seems like an efficient layout. Re the various packed pixel formats, and how BMM can extract what you need, even from the wrong byte order: It seems vastly more power efficient to have a plain byte swapper in front of the usual shift & mask bitfield extractor? Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
Page 1 of 13 [1] 2 3 … 13 Next page →
Back to top | Article view | comp.arch
csiph-web