Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #13464 > unrolled thread
| Started by | Tim Wescott <tim@seemywebsite.really> |
|---|---|
| First post | 2013-09-11 11:11 -0500 |
| Last post | 2013-09-11 22:19 -0400 |
| Articles | 20 on this page of 428 — 35 participants |
Back to article view | Back to comp.arch.embedded
Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-11 11:11 -0500
Re: Small, fast, resource-rich processor Rich Webb <webb.ra@example.net> - 2013-09-11 12:45 -0400
Re: Small, fast, resource-rich processor Frank Miles <fpm@u.washington.edu> - 2013-09-11 16:59 +0000
Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-11 10:08 -0700
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-11 12:27 -0500
Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-11 11:23 -0700
Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-11 11:32 -0700
Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-11 11:30 -0700
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-11 18:26 +0000
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-11 13:37 -0500
Re: Small, fast, resource-rich processor David Brown <david.brown@removethis.hesbynett.no> - 2013-09-11 21:51 +0200
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-09-11 16:46 -0400
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-12 14:00 +0200
Re: Small, fast, resource-rich processor Anders.Montonen@kapsi.spam.stop.fi.invalid - 2013-09-14 10:24 +0000
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-15 02:38 -0400
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-15 01:52 -0700
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-15 12:33 -0400
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-15 13:02 -0500
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-15 14:33 -0400
Re: Small, fast, resource-rich processor robert bristow-johnson <rbj@audioimagination.com> - 2013-09-15 12:09 -0700
Re: Small, fast, resource-rich processor David Brown <david.brown@removethis.hesbynett.no> - 2013-09-15 22:12 +0200
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-15 16:32 -0400
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-16 09:17 +0200
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-16 10:21 +0100
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-16 13:53 -0400
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-17 07:31 +0000
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-17 04:46 -0400
Re: Small, fast, resource-rich processor robert bristow-johnson <rbj@audioimagination.com> - 2013-09-17 10:46 -0700
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-09-17 22:30 -0400
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-17 22:43 -0700
Re: Small, fast, resource-rich processor gtwrek@sonic.net (Mark Curry) - 2013-09-18 14:35 +0000
Re: Small, fast, resource-rich processor upsidedown@downunder.com - 2013-09-18 18:41 +0300
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-18 09:12 -0700
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-19 07:57 +0000
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-19 22:22 -0700
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-20 05:44 +0000
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-20 00:05 -0700
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-20 14:18 +0000
Re: Small, fast, resource-rich processor upsidedown@downunder.com - 2013-09-20 16:24 +0300
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-20 08:31 +0100
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-20 12:43 -0500
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-20 20:29 +0100
Re: Small, fast, resource-rich processor gtwrek@sonic.net (Mark Curry) - 2013-09-20 21:39 +0000
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-20 15:27 -0700
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-20 23:52 +0100
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-20 18:52 -0700
Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-20 19:38 -0700
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-24 01:20 -0700
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-24 01:22 -0700
Re: Small, fast, resource-rich processor Robert Wessel <robertwessel2@yahoo.com> - 2013-09-24 03:33 -0500
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-24 21:17 -0400
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-22 10:56 -0700
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-22 20:08 +0100
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-22 12:21 -0700
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-23 00:12 +0100
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-22 16:50 -0700
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-23 09:12 +0100
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-23 06:49 -0700
Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-23 16:31 -0700
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-24 01:13 -0700
Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-24 02:15 -0700
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-24 15:56 -0700
Re: Small, fast, resource-rich processor Robert Wessel <robertwessel2@yahoo.com> - 2013-09-23 00:46 -0500
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-22 23:18 -0700
Re: Small, fast, resource-rich processor Arlet Ottens <usenet+5@c-scape.nl> - 2013-09-23 09:00 +0200
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-23 00:18 -0700
Re: Small, fast, resource-rich processor Arlet Ottens <usenet+5@c-scape.nl> - 2013-09-23 09:27 +0200
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-23 06:56 -0700
Re: Small, fast, resource-rich processor Robert Wessel <robertwessel2@yahoo.com> - 2013-09-23 10:50 -0500
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-28 13:04 -0700
Re: Small, fast, resource-rich processor upsidedown@downunder.com - 2013-09-20 15:41 +0300
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-20 14:33 +0000
Re: Small, fast, resource-rich processor upsidedown@downunder.com - 2013-09-20 15:55 +0300
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-20 08:42 -0700
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-23 09:06 +0200
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-28 12:07 -0700
Re: Small, fast, resource-rich processor David Brown <david.brown@removethis.hesbynett.no> - 2013-09-29 22:15 +0200
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-10-01 00:33 -0700
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-10-01 10:25 +0200
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-10-03 10:26 -0700
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-10-03 19:07 +0000
Re: Small, fast, resource-rich processor Scott Hemphill <hemphill@hemphills.net> - 2013-10-03 19:17 -0400
Re: Small, fast, resource-rich processor Scott Hemphill <hemphill@hemphills.net> - 2013-10-03 21:00 -0400
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-18 11:29 -0500
Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-18 10:20 -0700
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-18 21:53 -0700
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-19 09:48 +0200
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-19 09:38 +0100
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-19 11:24 +0200
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-19 10:53 +0100
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-19 13:12 +0200
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-19 15:31 +0100
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-19 15:44 +0100
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-19 22:53 -0700
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-20 08:37 +0100
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-30 17:48 +0100
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-10-01 00:37 -0700
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-10-01 09:14 +0100
Re: Small, fast, resource-rich processor David Brown <david.brown@removethis.hesbynett.no> - 2013-09-22 21:31 +0200
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-23 00:19 +0100
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-23 09:23 +0200
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-23 09:00 +0100
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-23 11:31 +0200
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-28 13:02 -0700
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-28 22:54 +0100
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-28 22:33 +0000
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-28 22:29 -0700
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-29 10:01 +0100
Re: Small, fast, resource-rich processor David Brown <david.brown@removethis.hesbynett.no> - 2013-09-29 23:02 +0200
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-30 10:36 -0400
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-09-30 14:09 -0400
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-01 01:27 -0400
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-10-01 05:46 +0000
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-10-01 09:19 +0200
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-01 03:28 -0400
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-10-01 10:13 +0200
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-01 12:39 -0400
Re: Small, fast, resource-rich processor Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2013-10-01 16:56 +0000
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-10-01 18:59 +0000
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-01 17:25 -0400
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-10-01 18:37 -0400
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-10-01 19:29 -0400
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-10-01 19:31 -0400
Re: Small, fast, resource-rich processor (die evil thread, die!!!) robert bristow-johnson <rbj@audioimagination.com> - 2013-10-01 16:36 -0700
Re: Small, fast, resource-rich processor (die evil thread, die!!!) Randy Yates <yates@digitalsignallabs.com> - 2013-10-01 20:51 -0400
Re: Small, fast, resource-rich processor (die evil thread, die!!!) Randy Yates <yates@digitalsignallabs.com> - 2013-10-01 21:08 -0400
Re: Small, fast, resource-rich processor (die evil thread, die!!!) David Brown <david@westcontrol.removethisbit.com> - 2013-10-02 09:08 +0200
Re: Small, fast, resource-rich processor (die evil thread, die!!!) Mel Wilson <mwilson@the-wire.com> - 2013-10-02 09:36 -0400
Re: Small, fast, resource-rich processor (die evil thread, die!!!) Robert Wessel <robertwessel2@yahoo.com> - 2013-10-02 17:16 -0500
Re: Small, fast, resource-rich processor (die evil thread, die!!!) upsidedown@downunder.com - 2013-10-03 10:15 +0300
Re: Small, fast, resource-rich processor (die evil thread, die!!!) Robert Wessel <robertwessel2@yahoo.com> - 2013-10-03 02:32 -0500
Re: Small, fast, resource-rich processor (die evil thread, die!!!) stephenXXX@mpeforth.com (Stephen Pelc) - 2013-10-03 15:45 +0000
Re: Small, fast, resource-rich processor (die evil thread, die!!!) Paul Rubin <no.email@nospam.invalid> - 2013-10-03 09:06 -0700
Re: Small, fast, resource-rich processor (die evil thread, die!!!) Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-10-03 17:18 +0100
Re: Small, fast, resource-rich processor (die evil thread, die!!!) stephenXXX@mpeforth.com (Stephen Pelc) - 2013-10-03 16:51 +0000
Re: Small, fast, resource-rich processor (die evil thread, die!!!) Paul Rubin <no.email@nospam.invalid> - 2013-10-03 10:11 -0700
Re: Small, fast, resource-rich processor (die evil thread, die!!!) Randy Yates <yates@digitalsignallabs.com> - 2013-10-02 09:52 -0400
Re: Small, fast, resource-rich processor (die evil thread, die!!!) David Brown <david@westcontrol.removethisbit.com> - 2013-10-03 09:35 +0200
Re: Small, fast, resource-rich processor (die evil thread, die!!!) Robert Wessel <robertwessel2@yahoo.com> - 2013-10-03 03:26 -0500
Re: Small, fast, resource-rich processor (die evil thread, die!!!) David Brown <david@westcontrol.removethisbit.com> - 2013-10-03 13:27 +0200
Re: Small, fast, resource-rich processor (die evil thread, die!!!) Randy Yates <yates@digitalsignallabs.com> - 2013-10-03 12:55 -0400
Re: Small, fast, resource-rich processor (die evil thread, die!!!) David Brown <david@westcontrol.removethisbit.com> - 2013-10-04 16:59 +0200
Re: Small, fast, resource-rich processor (die evil thread, die!!!) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-10-02 01:02 +0000
Re: Small, fast, resource-rich processor (die evil thread, die!!!) "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2013-10-03 16:28 +0200
Re: Small, fast, resource-rich processor (die evil thread, die!!!) dp <dp@tgi-sci.com> - 2013-10-03 08:03 -0700
Re: Small, fast, resource-rich processor (die evil thread, die!!!) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-10-03 19:15 +0000
Re: Small, fast, resource-rich processor (die evil thread, die!!!) Randy Yates <yates@digitalsignallabs.com> - 2013-10-03 15:50 -0400
Re: Small, fast, resource-rich processor (die evil thread, die!!!) Tim Wescott <tim@seemywebsite.really> - 2013-10-03 15:27 -0500
Re: Small, fast, resource-rich processor (die evil thread, die!!!) Randy Yates <yates@digitalsignallabs.com> - 2013-10-03 16:37 -0400
Re: Small, fast, resource-rich processor (die evil thread, die!!!) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-10-03 21:51 +0000
Re: Small, fast, resource-rich processor (die evil thread, die!!!) Robert Wessel <robertwessel2@yahoo.com> - 2013-10-04 00:02 -0500
Re: Small, fast, resource-rich processor (die evil thread, die!!!) Tim Wescott <tim@seemywebsite.really> - 2013-10-02 00:12 -0500
Re: Small, fast, resource-rich processor (die evil thread, die!!!) robert bristow-johnson <rbj@audioimagination.com> - 2013-10-03 10:24 -0700
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-10-02 00:13 -0500
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-10-02 06:51 +0000
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-10-02 09:55 -0400
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-10-02 09:58 -0400
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-02 03:12 -0400
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-10-02 09:49 -0400
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-02 12:04 -0400
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-10-02 12:51 -0400
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-10-02 15:18 -0400
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-02 19:46 -0400
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-10-01 23:09 +0000
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-19 03:53 -0400
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-19 01:45 -0700
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-19 04:34 -0400
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-19 02:17 -0700
Re: Small, fast, resource-rich processor gtwrek@sonic.net (Mark Curry) - 2013-09-19 16:49 +0000
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-19 17:05 +0000
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-19 13:08 -0700
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-19 20:22 +0000
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-19 14:42 -0700
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-20 00:34 -0400
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-19 22:15 -0700
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-20 08:43 +0100
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-19 22:16 -0700
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-19 12:28 -0500
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-09-19 15:08 -0400
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-18 12:52 -0400
Re: Small, fast, resource-rich processor robert bristow-johnson <rbj@audioimagination.com> - 2013-09-18 10:23 -0700
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-19 08:03 +0000
Re: Small, fast, resource-rich processor robert bristow-johnson <rbj@audioimagination.com> - 2013-09-19 12:53 -0700
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-18 21:31 -0700
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-19 04:18 -0400
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-19 02:02 -0700
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-19 16:47 +0000
Re: Small, fast, resource-rich processor j.m.granville@gmail.com - 2013-09-24 19:54 -0700
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-25 19:12 +0100
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-25 11:50 -0700
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-26 01:26 -0400
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-26 09:11 +0100
Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-26 02:12 -0700
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-26 13:46 +0100
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-26 09:55 -0700
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-26 18:44 +0100
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-26 12:31 -0700
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-26 23:09 +0100
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-26 08:45 -0400
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-19 07:44 +0000
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-19 03:58 -0400
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-19 09:45 +0100
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-19 16:50 +0000
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-19 07:31 +0000
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-17 11:30 -0500
Re: Small, fast, resource-rich processor gtwrek@sonic.net (Mark Curry) - 2013-09-17 21:11 +0000
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-18 13:11 -0400
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-17 11:42 +0200
Re: Small, fast, resource-rich processor Al Clark <aclark@danvillesignal.com> - 2013-09-17 14:06 +0000
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-17 16:44 +0200
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-17 11:43 -0500
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-17 13:22 -0400
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-18 17:17 +0200
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-18 16:46 +0100
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-18 09:16 -0700
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-18 14:13 -0400
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-18 20:00 +0100
Re: Small, fast, resource-rich processor Les Cargill <lcargill99@comcast.com> - 2013-09-18 19:56 -0500
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-19 09:56 +0100
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-18 14:01 -0400
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-18 12:35 -0700
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-18 23:28 +0200
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-18 16:39 -0500
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-18 17:26 -0700
Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-18 17:56 -0700
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-22 17:53 -0700
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-23 01:00 -0400
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-23 00:15 -0700
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-23 11:31 -0500
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-23 21:15 -0400
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-09-23 22:41 -0400
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-24 02:57 -0400
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-23 18:42 -0700
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-23 21:16 -0500
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-23 20:31 -0700
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-24 12:01 -0500
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-19 03:14 -0400
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-19 00:53 -0700
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-19 09:58 +0200
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-18 16:43 -0500
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-19 03:21 -0400
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-19 00:54 -0700
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-19 08:25 +0000
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-26 09:03 -0400
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-26 06:47 -0700
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-26 09:46 -0400
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-26 10:06 -0700
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-26 13:45 -0400
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-26 23:54 -0700
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-29 08:31 -0400
Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2013-09-29 23:37 +0000
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-30 01:16 +0100
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-29 22:31 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-30 10:06 +0100
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-30 11:12 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-30 09:24 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-01 01:33 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-30 22:48 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-01 03:04 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-10-01 00:27 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-01 03:32 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2013-09-30 11:37 +0000
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-30 13:40 +0100
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-30 11:43 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-30 17:07 +0100
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-30 11:38 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2013-09-30 18:57 +0000
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-30 12:36 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor jhallen@TheWorld.com (Joseph H Allen) - 2013-09-30 20:15 +0000
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2013-09-30 20:38 +0000
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-01 02:55 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2013-10-01 11:50 +0000
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-01 12:53 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2013-10-01 17:34 +0000
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-01 17:31 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2013-10-02 12:15 +0000
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-02 12:19 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2013-10-03 11:55 +0000
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-10-03 01:04 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-04 00:19 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-10-03 23:07 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-10-01 20:06 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-10-01 22:38 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-02 03:09 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-10-02 00:51 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-02 03:58 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-10-02 01:27 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-02 04:24 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-10-02 01:54 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-02 19:51 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-10-03 00:17 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-04 00:27 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-10-03 23:09 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-04 09:30 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-10-06 10:53 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-09 05:12 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-10-09 02:24 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2013-10-09 12:05 +0000
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-10-09 08:06 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-10-04 10:01 +0100
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-04 09:38 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-10-04 15:25 +0100
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-04 10:35 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-10-03 09:43 +0100
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-04 00:29 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-10-04 01:04 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-04 09:40 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-10-02 10:21 +0100
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-02 19:54 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-10-03 09:48 +0100
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-10-03 00:21 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-10-03 09:55 +0100
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-10-03 04:45 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-10-03 13:02 +0100
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-10-03 07:19 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-04 00:02 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-10-04 00:55 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-04 09:45 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-10-02 10:06 +0100
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-10-02 02:24 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-10-02 10:57 +0100
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-10-02 04:31 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-10-02 15:45 +0100
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-10-02 08:29 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-10-03 00:47 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-10-03 09:59 +0100
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-10-03 10:09 +0100
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-01 01:51 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-30 10:44 -0400
Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-27 01:10 -0700
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-29 08:36 -0400
Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-29 22:06 -0700
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-30 11:47 -0400
Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-30 09:14 -0700
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-19 01:27 +0200
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-19 03:49 -0400
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-15 16:40 -0400
Re: Small, fast, resource-rich processor robert bristow-johnson <rbj@audioimagination.com> - 2013-09-15 14:53 -0700
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-16 14:22 -0400
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-15 15:12 -0700
Re: Small, fast, resource-rich processor robert bristow-johnson <rbj@audioimagination.com> - 2013-09-15 14:58 -0700
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-15 18:19 -0500
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-16 14:48 -0400
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-16 17:17 -0500
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-16 18:41 -0400
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-17 11:22 -0500
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-17 15:40 -0400
Re: Small, fast, resource-rich processor Torfinn Ingolfsen <tingo@home.no> - 2013-09-17 18:44 +0200
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-16 14:31 -0400
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-17 07:44 +0000
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-17 11:46 -0500
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-19 09:21 +0000
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-19 12:26 -0500
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-19 20:17 +0000
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-18 08:25 -0700
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-18 14:16 -0400
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-18 12:39 -0700
Re: Small, fast, resource-rich processor langwadt@fonz.dk - 2013-09-18 15:18 -0700
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-19 09:49 +0000
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-17 07:35 +0000
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-15 13:11 -0700
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-15 16:26 -0400
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-15 16:36 -0400
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-17 07:49 +0000
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-17 05:30 -0400
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-19 10:00 +0000
Re: Small, fast, resource-rich processor gtwrek@sonic.net (Mark Curry) - 2013-09-16 16:51 +0000
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-16 14:54 -0400
Re: Small, fast, resource-rich processor gtwrek@sonic.net (Mark Curry) - 2013-09-16 19:06 +0000
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-16 15:22 -0400
Re: Small, fast, resource-rich processor Rob Gaddi <rgaddi@technologyhighland.invalid> - 2013-09-17 09:40 -0700
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-17 11:48 -0500
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-17 15:50 -0400
Re: Small, fast, resource-rich processor gtwrek@sonic.net (Mark Curry) - 2013-09-17 21:03 +0000
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-09-17 17:05 -0400
Re: Small, fast, resource-rich processor gtwrek@sonic.net (Mark Curry) - 2013-09-17 21:16 +0000
Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-17 16:38 -0700
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-09-17 21:33 -0400
Re: Small, fast, resource-rich processor Anssi Saari <as@sci.fi> - 2013-09-18 10:48 +0300
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.please> - 2013-09-15 10:39 -0500
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-15 12:39 -0400
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-15 12:58 -0500
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-15 11:33 -0700
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-15 14:40 -0400
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.please> - 2013-09-15 14:25 -0500
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-15 13:35 -0700
Re: Small, fast, resource-rich processor robert bristow-johnson <rbj@audioimagination.com> - 2013-09-15 12:40 -0700
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.please> - 2013-09-15 14:57 -0500
Re: Small, fast, resource-rich processor robert bristow-johnson <rbj@audioimagination.com> - 2013-09-15 13:44 -0700
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-16 01:46 -0700
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-16 10:26 +0100
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-16 02:44 -0700
Re: Small, fast, resource-rich processor Mel Wilson <mwilson@the-wire.com> - 2013-09-16 09:01 -0400
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-16 12:18 -0700
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.please> - 2013-09-16 10:06 -0500
Re: Small, fast, resource-rich processor robert bristow-johnson <rbj@audioimagination.com> - 2013-09-16 10:34 -0700
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-16 12:09 -0700
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-16 17:31 -0500
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-16 12:00 -0700
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-17 07:59 +0000
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-17 10:13 +0100
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-17 05:56 -0400
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-17 11:37 +0100
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-17 16:00 -0400
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-17 21:30 +0100
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-18 12:46 -0400
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-18 18:00 +0100
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-11 12:10 -0700
Re: Small, fast, resource-rich processor Vladimir Vassilevsky <nospam@nowhere.com> - 2013-09-11 14:30 -0500
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-09-11 15:39 -0400
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-09-11 15:46 -0400
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-09-11 20:39 -0400
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.please> - 2013-09-11 20:03 -0500
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-12 14:09 +0200
Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-12 07:11 -0700
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-12 16:34 +0200
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-09-12 10:42 -0400
Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-12 12:48 -0700
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-12 16:14 -0500
Re: Small, fast, resource-rich processor Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2013-09-12 21:39 +0200
Re: Small, fast, resource-rich processor David Brown <david.brown@removethis.hesbynett.no> - 2013-09-12 23:41 +0200
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-12 16:08 -0500
Re: Small, fast, resource-rich processor David Brown <david.brown@removethis.hesbynett.no> - 2013-09-13 01:00 +0200
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-12 23:03 -0500
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-13 08:47 +0200
Re: Small, fast, resource-rich processor Dave Nadler <drn@nadler.com> - 2013-09-11 15:40 -0700
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.please> - 2013-09-11 20:05 -0500
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-09-11 22:19 -0400
Page 5 of 22 — ← Prev page 1 … 3 4 [5] 6 7 … 22 Next page →
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2013-10-03 19:07 +0000 |
| Message-ID | <l2kf8v$hr5$1@speranza.aioe.org> |
| In reply to | #14126 |
In comp.dsp Paul Rubin <no.email@nospam.invalid> wrote: > David Brown <david@westcontrol.removethisbit.com> writes: >> I'm sure the guys at IEEE were very smart. But it was in a different >> time, for different hardware, different software and different types of >> applications. > The driving implementation at the time was the Intel 8087. Not too much > different from embedded processors of today. The supercomputer guys > mostly just looked on with amusement. >> There will be HPC folk that feel 64-bit IEEE is far too limited in range >> and resolution. > That's why 80 and 128 bit were invented. I suppose, but there is very little support for 128 outside IBM. IBM has supported it since the 360/85 around 1968. >> Microcontroller producers feel full IEEE hardware >> implementations are too big, complex and power-hungry. > I'd like to see actual numbers about that. What I seem to be hearing is > that the world's top numerics experts spend years agreeing that the > right way to solve this problem is to do X, Y, and Z; and then some > hardware guy or PHB at a microprocessor vendor says "well I'm smarter > than all those experts, so I think X and Y sound fine but I'm going to > leave out Z and save 5 cents on transistors". If that's what's going > on, it's not impressive. Well, one thing in IEEE-754 that I don't think is worthwhile is denormals. The 64 bit format has an 11 bit exponent for a range of about -1023 to +1023. Denormals allow, approximately, the range to go down to -1040, and log2(1040) is about 10.02. So it allows for an additional 0.02 bits of exponent. How much additional logic does it take to do that? As I understand it, many implementations interrupt and fix it up in software. That still takes a fair amount of hardware, but in a deep pipeline system is pretty much impossible. If you really need more range, us an additional whole exponent bit. But with a fixed number of bits, there is always a tradeoff between significand and exponent bits. Even so, 0.02 bits is pretty small. >> Toolchain vendors feel software library implementations of full IEEE >> are too slow and bulky, and they restrict the optimiser too much. > This is fine, they can have an option like --fast-math for users who > want it, though they should also have --ieee-math, preferably as the > default. It's less of a problem than the hardware vendor who removes > following the standard as even as a possibility for the user. >> Embedded developers feel they don't care about irrelevant details of >> features they will never use, but they do care about code speed and >> size. Well, first of all, too much embedded work uses floating point when fixed point would be a better choice. > I wonder how often they're actually qualified to make such decisions. > One thing about standards is they're codifications of best practices. > If someone builds a critical application and something goes wrong > because they decided to ignore a standard, they're potentially in a > world of hurt. OK, say someone is building a heart rate monitor. First, a heart rate will never be NaN, and shouldn't be Inf. It could be zero, though. (But not within the range of floating point.) For hospital use, it will have to have various certifications, such as the FDA, but, as far as I know, not the IEEE. (And it should be done in fixed point!) -- glen
[toc] | [prev] | [next] | [standalone]
| From | Scott Hemphill <hemphill@hemphills.net> |
|---|---|
| Date | 2013-10-03 19:17 -0400 |
| Message-ID | <m3li2alzax.fsf@hemphills.net> |
| In reply to | #14128 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: [snip] > Well, one thing in IEEE-754 that I don't think is worthwhile > is denormals. The 64 bit format has an 11 bit exponent for a > range of about -1023 to +1023. Denormals allow, approximately, > the range to go down to -1040, and log2(1040) is about 10.02. > So it allows for an additional 0.02 bits of exponent. > How much additional logic does it take to do that? > > As I understand it, many implementations interrupt and fix it > up in software. That still takes a fair amount of hardware, but > in a deep pipeline system is pretty much impossible. > > If you really need more range, us an additional whole exponent bit. > > But with a fixed number of bits, there is always a tradeoff between > significand and exponent bits. Even so, 0.02 bits is pretty small. [snip] I don't think it adds a lot of additional logic. (I have just recently implemented IEEE floating point using integer arithmetic with the idea of porting to the 6502.) One thing in its favor is that zero is just another denormal. If you don't have logic for denormals, then you have to have special logic to recognize and handle zero. Scott -- Scott Hemphill hemphill@alumni.caltech.edu "This isn't flying. This is falling, with style." -- Buzz Lightyear
[toc] | [prev] | [next] | [standalone]
| From | Scott Hemphill <hemphill@hemphills.net> |
|---|---|
| Date | 2013-10-03 21:00 -0400 |
| Message-ID | <m3hacxn938.fsf@hemphills.net> |
| In reply to | #14134 |
Scott Hemphill <hemphill@hemphills.net> writes: > glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > > [snip] > >> Well, one thing in IEEE-754 that I don't think is worthwhile >> is denormals. The 64 bit format has an 11 bit exponent for a >> range of about -1023 to +1023. Denormals allow, approximately, >> the range to go down to -1040, and log2(1040) is about 10.02. >> So it allows for an additional 0.02 bits of exponent. >> How much additional logic does it take to do that? >> >> As I understand it, many implementations interrupt and fix it >> up in software. That still takes a fair amount of hardware, but >> in a deep pipeline system is pretty much impossible. >> >> If you really need more range, us an additional whole exponent bit. >> >> But with a fixed number of bits, there is always a tradeoff between >> significand and exponent bits. Even so, 0.02 bits is pretty small. > > [snip] > > I don't think it adds a lot of additional logic. (I have just recently > implemented IEEE floating point using integer arithmetic with the idea > of porting to the 6502.) One thing in its favor is that zero is just > another denormal. If you don't have logic for denormals, then you have > to have special logic to recognize and handle zero. OK, this wasn't very accurate. There are still places you have to "recognize and handle zero". There are other places where zero is just another denormal. Scott -- Scott Hemphill hemphill@alumni.caltech.edu "This isn't flying. This is falling, with style." -- Buzz Lightyear
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <tim@seemywebsite.really> |
|---|---|
| Date | 2013-09-18 11:29 -0500 |
| Message-ID | <PM2dnZYEB6h1SaTPnZ2dnUVZ5vSdnZ2d@giganews.com> |
| In reply to | #13687 |
On Tue, 17 Sep 2013 22:43:05 -0700, Paul Rubin wrote: > robert bristow-johnson <rbj@audioimagination.com> writes: >> shown (at the 2008 AES) that comparing 32-bit IEEE float to 32-bit >> fixed,... 32-bit fixed beats 32-bit float. > > That's why 64-bit float was invented ;-). Seriously, the idea of double > precision isn't that you need an ultra-precise final result, but rather, > that if you're doing a numerical algorithm with a lot of steps that's > accumulating a small amount of roundoff error in each step, the > accumulated errors won't reach physical significance unless the > calculation is unusually long or the algorithm is especially unstable at > the input data. For that reason all these suggestions of using non-IEEE > floating point formats sound hacky unless they're coming from numerics > experts. The era of ad hoc floating point formats was the 1970's and > earlier. The world has moved on since then. I'm going from hearsay here, but: The biggest argument for using non IEEE-compliant floating point is that by and large the largest expenditure of logic (or code and clock ticks in emulation) to implementing 100% compliant floating point code is properly dealing with all possible exceptions and combinations thereof. If your algorithm is debugged and verified to the point where you can be sure of never, ever hitting an exception, then your floating point processing costs go down. The second-biggest argument is a strong advantage of FPGAs: you can tailor your data path to your data. And yes, you'd really want a numerics expert on board, or to do your design conservatively, if you were going to proceed. Which is just yet another tax on your project if you're going to use FPGAs instead of standard processors. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
[toc] | [prev] | [next] | [standalone]
| From | dp <dp@tgi-sci.com> |
|---|---|
| Date | 2013-09-18 10:20 -0700 |
| Message-ID | <29634de6-f1e5-4e79-a254-29de1e392556@googlegroups.com> |
| In reply to | #13697 |
On Wednesday, September 18, 2013 7:29:28 PM UTC+3, Tim Wescott wrote: > On Tue, 17 Sep 2013 22:43:05 -0700, Paul Rubin wrote: > ... > > And yes, you'd really want a numerics expert on board, or to do your > design conservatively, if you were going to proceed. Hmmm, doing the calculations to see how many bits you need, how you begin to accumulate error in FP if the mantissa is too short etc. hardly takes more than high-school grade maths... Dimiter
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-09-18 21:53 -0700 |
| Message-ID | <7x7gedqun7.fsf@ruckus.brouhaha.com> |
| In reply to | #13697 |
Tim Wescott <tim@seemywebsite.really> writes: > The biggest argument for using non IEEE-compliant floating point is that > by and large the largest expenditure of logic (or code and clock ticks in > emulation) to implementing 100% compliant floating point code is properly > dealing with all possible exceptions and combinations thereof. This makes sense for software emulations and maybe for FPGA's, but I think with hardware implementations, handling all those flags and traps can be done concurrently with the main calculation, with a handful of extra gates. > If your algorithm is debugged and verified to the point where you can be > sure of never, ever hitting an exception, then your floating point > processing costs go down. I wonder what kinds of verification techniques exist for this. It's above my pay grade, I guess. > And yes, you'd really want a numerics expert on board, or to do your > design conservatively, if you were going to proceed. Which is just yet > another tax on your project if you're going to use FPGAs instead of > standard processors. Well put. By the way here's an interview about IEEE 754 that I saw some years ago but just came across again: http://www.cs.berkeley.edu/~wkahan/ieee754status/754story.html This stuff is not trivial. It's not just a "format".
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2013-09-19 09:48 +0200 |
| Message-ID | <nJidnWKYksHCMafPnZ2dnUVZ8t6dnZ2d@lyse.net> |
| In reply to | #13719 |
On 19/09/13 06:53, Paul Rubin wrote: > Tim Wescott <tim@seemywebsite.really> writes: >> The biggest argument for using non IEEE-compliant floating point is that >> by and large the largest expenditure of logic (or code and clock ticks in >> emulation) to implementing 100% compliant floating point code is properly >> dealing with all possible exceptions and combinations thereof. That is /one/ of the arguments for avoiding IEEE. It is certainly an argument for using "loose" IEEE in software (such as with gcc's "-ffast-math" switch). There are other requirements for IEEE beyond the logic to handle the assorted NaNs, denormals, etc. For example, IEEE imposes quite strict requirements for rounding, ordering and error margins, to make the results as repeatable as possible across different systems. This puts severe limits on the compiler's optimiser - it cannot change "a * b" into "b * a", or "(a / b) / c" into "a / (b * c)" or "a * (1 / (b * c))", even if the results are faster. Have a look at the gcc manual for the various "-ffast-math" flag details: <http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-ffast_002dmath-924> (Other compilers will normally have similar flags of some sort, though perhaps not in the same detail, if they allow users the choice of strict IEEE or faster floating point.) > > This makes sense for software emulations and maybe for FPGA's, but I > think with hardware implementations, handling all those flags and traps > can be done concurrently with the main calculation, with a handful of > extra gates. Actually, this is not true - especially of smaller FPU with single-precision only, and just the main arithmetic functions (no transcendentals, but perhaps a square root function) . Many hardware floating point units require significant software help to be fully IEE compliant. You can set control flags for how it should handle things like NaNs - such as to ignore them (i.e., do the calculations as though it were a normal floating point - garbage in, garbage out), or to trap to a software exception for full handling. > >> If your algorithm is debugged and verified to the point where you can be >> sure of never, ever hitting an exception, then your floating point >> processing costs go down. > > I wonder what kinds of verification techniques exist for this. It's > above my pay grade, I guess. It should not be "above your pay grade" - even if you are an amateur. It's called "make sure your program works with the correct data". How do you know your function won't generate NaNs and other nonsense? Write the code correctly, and give it valid data (or check the data if it might be invalid). For most work - and certainly anything embedded - you will only ever hit exceptional floating point values if you've got bugs in your code or algorithms. So you treat these issues just like any other potential bugs. > >> And yes, you'd really want a numerics expert on board, or to do your >> design conservatively, if you were going to proceed. Which is just yet >> another tax on your project if you're going to use FPGAs instead of >> standard processors. > > Well put. > > By the way here's an interview about IEEE 754 that I saw some years ago > but just came across again: > http://www.cs.berkeley.edu/~wkahan/ieee754status/754story.html > > This stuff is not trivial. It's not just a "format". >
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-09-19 09:38 +0100 |
| Message-ID | <nKy_t.83027$G02.82194@fx13.am4> |
| In reply to | #13726 |
On 19/09/13 08:48, David Brown wrote: > On 19/09/13 06:53, Paul Rubin wrote: >> Tim Wescott <tim@seemywebsite.really> writes: >>> If your algorithm is debugged and verified to the point where you can be >>> sure of never, ever hitting an exception, then your floating point >>> processing costs go down. >> >> I wonder what kinds of verification techniques exist for this. It's >> above my pay grade, I guess. > > It should not be "above your pay grade" - even if you are an amateur. > It's called "make sure your program works with the correct data". How > do you know your function won't generate NaNs and other nonsense? Write > the code correctly, and give it valid data (or check the data if it > might be invalid). The experience of the professional high performance computing (HPC) community indicates that is /not/ the case. Googling for HPC on comp.arch (especially anything by Nick MacLaren who's been at the sharp end of that since the 60s) will give you indications as to why. In particular you will get a feeling for why IEEE754 still has inherent problems, even though it is significantly better than the alternatives. > For most work - and certainly anything embedded - you will only ever hit > exceptional floating point values if you've got bugs in your code or > algorithms. So you treat these issues just like any other potential bugs. Analysing the algorithm is non-trivial, whether or not IEEE754 is used. The one ray of light for embedded/dsp work is that the range of inputs is likely to be more constrained. A ray of darkness for embedded/dsp work is that shortcuts will probably be taken to fit the algorithm into the available resources. >> By the way here's an interview about IEEE 754 that I saw some years ago >> but just came across again: >> http://www.cs.berkeley.edu/~wkahan/ieee754status/754story.html >> >> This stuff is not trivial. It's not just a "format". Yes indeed!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2013-09-19 11:24 +0200 |
| Message-ID | <Gs2dnQX9WoEiX6fPnZ2dnUVZ8nydnZ2d@lyse.net> |
| In reply to | #13737 |
On 19/09/13 10:38, Tom Gardner wrote: > On 19/09/13 08:48, David Brown wrote: >> On 19/09/13 06:53, Paul Rubin wrote: >>> Tim Wescott <tim@seemywebsite.really> writes: >>>> If your algorithm is debugged and verified to the point where you >>>> can be >>>> sure of never, ever hitting an exception, then your floating point >>>> processing costs go down. >>> >>> I wonder what kinds of verification techniques exist for this. It's >>> above my pay grade, I guess. >> >> It should not be "above your pay grade" - even if you are an amateur. >> It's called "make sure your program works with the correct data". How >> do you know your function won't generate NaNs and other nonsense? Write >> the code correctly, and give it valid data (or check the data if it >> might be invalid). > > The experience of the professional high performance computing > (HPC) community indicates that is /not/ the case. The HPC community have different requirements - they are basically the main users of IEEE functionality beyond the basic maths. They /do/ care about the treatment of NaNs, the consistency between different implementations, etc. But this is c.a.e. - here it is seldom worth the cost or effort to support these features. And here we don't accept that the result of a calculation could be wrong or NaN - and you guarantee that in the same way as you do the rest of the verification, bug checking, testing and qualification of your software. (That is to say, the details and the effort vary enormously - the methods used for designing a singing birthday card and a pacemaker are rather different.) > > Googling for HPC on comp.arch (especially anything by > Nick MacLaren who's been at the sharp end of that since > the 60s) will give you indications as to why. > > In particular you will get a feeling for why IEEE754 > still has inherent problems, even though it is > significantly better than the alternatives. > > >> For most work - and certainly anything embedded - you will only ever hit >> exceptional floating point values if you've got bugs in your code or >> algorithms. So you treat these issues just like any other potential >> bugs. > > Analysing the algorithm is non-trivial, whether or > not IEEE754 is used. > Are we talking about one particular algorithm here (such as Kalman)? > The one ray of light for embedded/dsp work is that the > range of inputs is likely to be more constrained. It is not a "ray of light" - it is a powerful spotlight. And if your algorithm is so convoluted that you fear values might go to infinity, or lead to divide by zeros, or lose too much precision, then you are screwed anyway. No amount of IEEE "magic" will help you. > > A ray of darkness for embedded/dsp work is that shortcuts > will probably be taken to fit the algorithm into the > available resources. > > >>> By the way here's an interview about IEEE 754 that I saw some years ago >>> but just came across again: >>> http://www.cs.berkeley.edu/~wkahan/ieee754status/754story.html >>> >>> This stuff is not trivial. It's not just a "format". > > Yes indeed! >
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-09-19 10:53 +0100 |
| Message-ID | <xQz_t.99269$NO1.903@fx14.am4> |
| In reply to | #13743 |
On 19/09/13 10:24, David Brown wrote: > On 19/09/13 10:38, Tom Gardner wrote: >> On 19/09/13 08:48, David Brown wrote: >>> On 19/09/13 06:53, Paul Rubin wrote: >>>> Tim Wescott <tim@seemywebsite.really> writes: >>>>> If your algorithm is debugged and verified to the point where you >>>>> can be >>>>> sure of never, ever hitting an exception, then your floating point >>>>> processing costs go down. >>>> >>>> I wonder what kinds of verification techniques exist for this. It's >>>> above my pay grade, I guess. >>> >>> It should not be "above your pay grade" - even if you are an amateur. >>> It's called "make sure your program works with the correct data". How >>> do you know your function won't generate NaNs and other nonsense? Write >>> the code correctly, and give it valid data (or check the data if it >>> might be invalid). >> >> The experience of the professional high performance computing >> (HPC) community indicates that is /not/ the case. > > The HPC community have different requirements - they are basically the > main users of IEEE functionality beyond the basic maths. They /do/ care > about the treatment of NaNs, the consistency between different > implementations, etc. I should have been clearer; my comment was mainly a response to the "...should not be above your pay grade..." statement. > But this is c.a.e. - here it is seldom worth the cost or effort to > support these features. That may be your experience. It was definitely *not* the case for one of my embedded projects. > And here we don't accept that the result of a > calculation could be wrong or NaN - and you guarantee that in the same > way as you do the rest of the verification, bug checking, testing and > qualification of your software. (That is to say, the details and the > effort vary enormously - the methods used for designing a singing > birthday card and a pacemaker are rather different.) You're overstating your case to make a point - but I agree with the point in *most* cases. >> Googling for HPC on comp.arch (especially anything by >> Nick MacLaren who's been at the sharp end of that since >> the 60s) will give you indications as to why. >> >> In particular you will get a feeling for why IEEE754 >> still has inherent problems, even though it is >> significantly better than the alternatives. >> >> >>> For most work - and certainly anything embedded - you will only ever hit >>> exceptional floating point values if you've got bugs in your code or >>> algorithms. So you treat these issues just like any other potential >>> bugs. >> >> Analysing the algorithm is non-trivial, whether or >> not IEEE754 is used. >> > > Are we talking about one particular algorithm here (such as Kalman)? Yes. :) In my experience many software weenies take a deep breath when you ask them "if you have two numbers known to 1% and you do an arithmetic operation on them, what do you know about the result" Most will eventually stumble towards the divide-by-zero case. Most will also say "1%", incorrectly. Many have to have it explained in detail, with examples, that you don't know *anything* about the result - if you are subtracting two nearly equal numbers. And they are often the ones writing financial software algorithms. Sad. Very sad. >> The one ray of light for embedded/dsp work is that the >> range of inputs is likely to be more constrained. > > It is not a "ray of light" - it is a powerful spotlight. > > And if your algorithm is so convoluted that you fear values might go to > infinity, or lead to divide by zeros, or lose too much precision, then > you are screwed anyway. No amount of IEEE "magic" will help you. Agreed, but the algorithm doesn't need to be convoluted for problems to arise. I've seen it when calculating the cost of a phone call! And the "solution" used to get the code to pass a unit test (and therefore by definition correct) left my lower jaw flapping on my chest.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2013-09-19 13:12 +0200 |
| Message-ID | <Z9adnbf_9aicQafPnZ2dnUVZ8nOdnZ2d@lyse.net> |
| In reply to | #13745 |
On 19/09/13 11:53, Tom Gardner wrote: > On 19/09/13 10:24, David Brown wrote: >> On 19/09/13 10:38, Tom Gardner wrote: >>> On 19/09/13 08:48, David Brown wrote: >>>> On 19/09/13 06:53, Paul Rubin wrote: >>>>> Tim Wescott <tim@seemywebsite.really> writes: >>>>>> If your algorithm is debugged and verified to the point where you >>>>>> can be >>>>>> sure of never, ever hitting an exception, then your floating point >>>>>> processing costs go down. >>>>> >>>>> I wonder what kinds of verification techniques exist for this. It's >>>>> above my pay grade, I guess. >>>> >>>> It should not be "above your pay grade" - even if you are an amateur. >>>> It's called "make sure your program works with the correct data". How >>>> do you know your function won't generate NaNs and other nonsense? >>>> Write >>>> the code correctly, and give it valid data (or check the data if it >>>> might be invalid). >>> >>> The experience of the professional high performance computing >>> (HPC) community indicates that is /not/ the case. >> >> The HPC community have different requirements - they are basically the >> main users of IEEE functionality beyond the basic maths. They /do/ care >> about the treatment of NaNs, the consistency between different >> implementations, etc. > > I should have been clearer; my comment was mainly a > response to the "...should not be above your pay grade..." > statement. > > >> But this is c.a.e. - here it is seldom worth the cost or effort to >> support these features. > > That may be your experience. It was definitely *not* > the case for one of my embedded projects. In embedded design, all generalisations are false... > > >> And here we don't accept that the result of a >> calculation could be wrong or NaN - and you guarantee that in the same >> way as you do the rest of the verification, bug checking, testing and >> qualification of your software. (That is to say, the details and the >> effort vary enormously - the methods used for designing a singing >> birthday card and a pacemaker are rather different.) > > You're overstating your case to make a point - but I > agree with the point in *most* cases. > > >>> Googling for HPC on comp.arch (especially anything by >>> Nick MacLaren who's been at the sharp end of that since >>> the 60s) will give you indications as to why. >>> >>> In particular you will get a feeling for why IEEE754 >>> still has inherent problems, even though it is >>> significantly better than the alternatives. >>> >>> >>>> For most work - and certainly anything embedded - you will only ever >>>> hit >>>> exceptional floating point values if you've got bugs in your code or >>>> algorithms. So you treat these issues just like any other potential >>>> bugs. >>> >>> Analysing the algorithm is non-trivial, whether or >>> not IEEE754 is used. >>> >> >> Are we talking about one particular algorithm here (such as Kalman)? > > Yes. :) > > In my experience many software weenies take a deep > breath when you ask them "if you have two numbers > known to 1% and you do an arithmetic operation on > them, what do you know about the result" > > Most will eventually stumble towards the divide-by-zero > case. > > Most will also say "1%", incorrectly. > > Many have to have it explained in detail, with examples, > that you don't know *anything* about the result - if > you are subtracting two nearly equal numbers. Yes - it all depends on what these arithmetic operations are, and how your 1% is defined (1% of full scale? 1% away from the true value - and if so, what if the true value is 0?). Are you interested in error distributions or just margins? (I am a maths "weenie" as well as a software weenie, so I hope I'd do better than "most" here.) > > And they are often the ones writing financial > software algorithms. > Well, the economists that make the financial models in the first place have little basis in reality, so bad implementations are not going to make things worse! > Sad. Very sad. > > >>> The one ray of light for embedded/dsp work is that the >>> range of inputs is likely to be more constrained. >> >> It is not a "ray of light" - it is a powerful spotlight. >> >> And if your algorithm is so convoluted that you fear values might go to >> infinity, or lead to divide by zeros, or lose too much precision, then >> you are screwed anyway. No amount of IEEE "magic" will help you. > > Agreed, but the algorithm doesn't need to be > convoluted for problems to arise. I've seen it > when calculating the cost of a phone call! > Maybe the algorithm wasn't convoluted enough here. > And the "solution" used to get the code to pass a > unit test (and therefore by definition correct) > left my lower jaw flapping on my chest. Was it one of these great "solutions" that involves spotting that you are running as a test, and doing special-case code to pass the test? I've seen that done on occasion.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-09-19 15:31 +0100 |
| Message-ID | <0VD_t.86373$rR5.80544@fx27.am4> |
| In reply to | #13747 |
On 19/09/13 12:12, David Brown wrote:
> On 19/09/13 11:53, Tom Gardner wrote:
>> On 19/09/13 10:24, David Brown wrote:
> In embedded design, all generalisations are false...
Including that one :)
>> In my experience many software weenies take a deep
>> breath when you ask them "if you have two numbers
>> known to 1% and you do an arithmetic operation on
>> them, what do you know about the result"
>>
>> Most will eventually stumble towards the divide-by-zero
>> case.
>>
>> Most will also say "1%", incorrectly.
>>
>> Many have to have it explained in detail, with examples,
>> that you don't know *anything* about the result - if
>> you are subtracting two nearly equal numbers.
>
> Yes - it all depends on what these arithmetic operations are, and how
> your 1% is defined (1% of full scale? 1% away from the true value - and
> if so, what if the true value is 0?). Are you interested in error
> distributions or just margins? (I am a maths "weenie" as well as a
> software weenie, so I hope I'd do better than "most" here.)
Your questions indicate that you are already streets
ahead of most software weenies :(
Keep it simple: 1% of the value. That avoids considering
what the full scale of a natural number might be!
>> And they are often the ones writing financial
>> software algorithms.
>
> Well, the economists that make the financial models in the first place
> have little basis in reality, so bad implementations are not going to
> make things worse!
In this case the customers shouted if the cost was off
by a penny per call! Justifiably, IMHO.
But apart from that we are in violent agreement.
>> Sad. Very sad.
>>
>>
>>>> The one ray of light for embedded/dsp work is that the
>>>> range of inputs is likely to be more constrained.
>>>
>>> It is not a "ray of light" - it is a powerful spotlight.
>>>
>>> And if your algorithm is so convoluted that you fear values might go to
>>> infinity, or lead to divide by zeros, or lose too much precision, then
>>> you are screwed anyway. No amount of IEEE "magic" will help you.
>>
>> Agreed, but the algorithm doesn't need to be
>> convoluted for problems to arise. I've seen it
>> when calculating the cost of a phone call!
>>
>
> Maybe the algorithm wasn't convoluted enough here.
It really wasn't that complex: more or less fixed
cost per call plus cost per minute. The complexity
was in high availability, "low" latency, and deciding
what the call's coefficients were in the first place.
>> And the "solution" used to get the code to pass a
>> unit test (and therefore by definition correct)
>> left my lower jaw flapping on my chest.
>
> Was it one of these great "solutions" that involves spotting that you
> are running as a test, and doing special-case code to pass the test?
> I've seen that done on occasion.
No. Worse.
Start by using floating point for monetary values.
Find you've got the wrong answer.
Invent a numerically invalid mechanism for
getting the right value for the test cases.
Don't worry about other cases ("it passed the unit
tests, so it is right", by definition).
Don't worry that it is computationally expensive
(reasonable since that didn't affect performance).
And no, I'm not going to say what the invalid
mechanism was, and if somebody guessed the answer
I couldn't possibly comment.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-09-19 15:44 +0100 |
| Message-ID | <F5E_t.75462$WW4.46137@fx34.am4> |
| In reply to | #13749 |
Sorry, that escaped by mistake.
> No. Worse.
>
> Start by using floating point for monetary values.
> Find you've got the wrong answer.
>
> Invent a numerically invalid mechanism for
> getting the right value for the test cases.
and use it for all arithmetic for calculating
the cost.
Don't even think that the "solution" might cause
as many problems as it "cures".
Don't even think of considering that the
algorithms might now be faulty by design, since...
> Don't worry about other cases ("it passed the unit
> tests, so it is right", by definition).
>
> Don't worry that it is computationally expensive
> (reasonable since that didn't affect performance).
>
> And no, I'm not going to say what the invalid
> mechanism was, and if somebody guessed the answer
> I couldn't possibly comment.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-09-19 22:53 -0700 |
| Message-ID | <7xa9j82g4a.fsf@ruckus.brouhaha.com> |
| In reply to | #13726 |
David Brown <david@westcontrol.removethisbit.com> writes: > For example, IEEE imposes quite strict requirements for rounding, > ordering and error margins, to make the results as repeatable as > possible across different systems. I'd have to say that is a misconception. It's not for repeatbility: IEEE imposes those requirements in order to help numerical algorithms give the right answers. I.e., bypassing the requirements leads to wrong answers. Mathematics is not modern art or literary criticism where everything is subjective and there's no right or wrong answer. Numerical problems actually do have wrong answers and IEEE-754 was designed because the mathematicians who designed it had a huge amount of experience with previous systems and they were tired of getting wrong answers and they decided to (somewhat) fix the situation. > Have a look at the gcc manual for the various "-ffast-math" flag details: > (Other compilers will normally have similar flags of some sort, If your application can withstand wrong answers, then sure. It's something you have to be judicious about rather than generalizing. >> I wonder what kinds of verification techniques exist for this. It's >> above my pay grade, I guess. > It should not be "above your pay grade" - even if you are an amateur. Verification (in the sense of certifying that the program does the right thing for ALL POSSIBLE inputs, not just for your test vectors) is a very complicated subject. I know a little about how it's done for integer math, but floating point adds another level of complexity and I just mean I don't have any clue how the high-assurance community deals with it. It goes way beyond the topic at hand though. > It's called "make sure your program works with the correct data". How > do you know your function won't generate NaNs and other nonsense? There is nothing nonsensical about NaN's. They are part of the standard and algorithms intended to run on standard-conformant hardware can and do use NaN and Inf on purpose, expecting them to propagate through calculations the way the standard says they should. If your floating point implementation requires avoiding them, then you're imposing restrictions on the user's algorithm choices.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-09-20 08:37 +0100 |
| Message-ID | <NWS_t.133986$AH1.58728@fx19.am4> |
| In reply to | #13770 |
Everybody on this thread should, at the very least, speed read http://people.ds.cam.ac.uk/nmm1/Arithmetic/Notes/notes.pdf http://people.ds.cam.ac.uk/nmm1/Arithmetic/index.html It is amusingly written by someone that's been on the sharp end of diagnosing numerical problems with HPC since the 60s. Even a cursory inspection will cut through some of the ignorant guff that has appeared in this thread On 20/09/13 06:53, Paul Rubin wrote: > David Brown <david@westcontrol.removethisbit.com> writes: >> For example, IEEE imposes quite strict requirements for rounding, >> ordering and error margins, to make the results as repeatable as >> possible across different systems. > > I'd have to say that is a misconception. It's not for repeatbility: > IEEE imposes those requirements in order to help numerical algorithms > give the right answers. I.e., bypassing the requirements leads to wrong > answers. Mathematics is not modern art or literary criticism where > everything is subjective and there's no right or wrong answer. > Numerical problems actually do have wrong answers and IEEE-754 was > designed because the mathematicians who designed it had a huge amount of > experience with previous systems and they were tired of getting wrong > answers and they decided to (somewhat) fix the situation. > >> Have a look at the gcc manual for the various "-ffast-math" flag details: >> (Other compilers will normally have similar flags of some sort, > > If your application can withstand wrong answers, then sure. It's > something you have to be judicious about rather than generalizing. > >>> I wonder what kinds of verification techniques exist for this. It's >>> above my pay grade, I guess. >> It should not be "above your pay grade" - even if you are an amateur. > > Verification (in the sense of certifying that the program does the right > thing for ALL POSSIBLE inputs, not just for your test vectors) is a very > complicated subject. I know a little about how it's done for integer > math, but floating point adds another level of complexity and I just > mean I don't have any clue how the high-assurance community deals with > it. It goes way beyond the topic at hand though. > >> It's called "make sure your program works with the correct data". How >> do you know your function won't generate NaNs and other nonsense? > > There is nothing nonsensical about NaN's. They are part of the standard > and algorithms intended to run on standard-conformant hardware can and > do use NaN and Inf on purpose, expecting them to propagate through > calculations the way the standard says they should. If your floating > point implementation requires avoiding them, then you're imposing > restrictions on the user's algorithm choices. >
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-09-30 17:48 +0100 |
| Message-ID | <nXh2u.16243$MA5.5466@fx20.am4> |
| In reply to | #13775 |
This is also amusing (and frightening). http://www.eecs.berkeley.edu/%7Ewkahan/Mindless.pdf Those that claim something along the lines of "it is OK as long as you make sure you have a good algorithm" should read all of that before making such pronouncements. On 20/09/13 08:37, Tom Gardner wrote: > Everybody on this thread should, at the very least, speed read > http://people.ds.cam.ac.uk/nmm1/Arithmetic/Notes/notes.pdf > http://people.ds.cam.ac.uk/nmm1/Arithmetic/index.html > > It is amusingly written by someone that's been on the > sharp end of diagnosing numerical problems with HPC > since the 60s.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-10-01 00:37 -0700 |
| Message-ID | <7xpprpe91f.fsf@ruckus.brouhaha.com> |
| In reply to | #13999 |
Tom Gardner <spamjunk@blueyonder.co.uk> writes: > This is also amusing (and frightening). > http://www.eecs.berkeley.edu/%7Ewkahan/Mindless.pdf Oh cool, I'm glad you found that. There is lots of other good stuff on his site too.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-10-01 09:14 +0100 |
| Message-ID | <Bvv2u.13694$QZ.12927@fx11.am4> |
| In reply to | #14036 |
On 01/10/13 08:37, Paul Rubin wrote: > Tom Gardner <spamjunk@blueyonder.co.uk> writes: >> This is also amusing (and frightening). >> http://www.eecs.berkeley.edu/%7Ewkahan/Mindless.pdf > > Oh cool, I'm glad you found that. There is lots of other good stuff on > his site too. I haven't looked at the rest, yet. There's only so many minutes left in my remaining life :( Not all numerical practitioners agree completely with everything Kahan says (surprise!), but they do listen and think about what he says.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@removethis.hesbynett.no> |
|---|---|
| Date | 2013-09-22 21:31 +0200 |
| Message-ID | <XIydndCNPpDg2KLPnZ2dnUVZ8iqdnZ2d@lyse.net> |
| In reply to | #13770 |
On 20/09/13 07:53, Paul Rubin wrote: > David Brown <david@westcontrol.removethisbit.com> writes: >> For example, IEEE imposes quite strict requirements for rounding, >> ordering and error margins, to make the results as repeatable as >> possible across different systems. > > I'd have to say that is a misconception. It's not for repeatbility: > IEEE imposes those requirements in order to help numerical algorithms > give the right answers. I.e., bypassing the requirements leads to wrong > answers. Mathematics is not modern art or literary criticism where > everything is subjective and there's no right or wrong answer. > Numerical problems actually do have wrong answers and IEEE-754 was > designed because the mathematicians who designed it had a huge amount of > experience with previous systems and they were tired of getting wrong > answers and they decided to (somewhat) fix the situation. > >> Have a look at the gcc manual for the various "-ffast-math" flag details: >> (Other compilers will normally have similar flags of some sort, > > If your application can withstand wrong answers, then sure. It's > something you have to be judicious about rather than generalizing. No, "fast-math" is not about "withstanding wrong answers" any more than "numerical maths on computers is about withstanding wrong answers". It is about being less fussy about details that are irrelevant to your application. If you are writing software on a microcontroller for positioning a motor, then insisting on strict IEEE might give you a few molecule width's worth of accuracy, at the cost of not getting the calculations done in time. Rough floating point - such as "-ffast-math" - is about a different balance between the accuracy and the cost of the calculations. I think I have said in several places that this is about /embedded/ applications - /obviously/ you have to pick your implementation details according to your needs. The kind of applications where IEEE really gets useful is when you need accurate control of the order of calculations - such as summing power series or inverting large matrices. These sorts of calculations can quickly result in rubbish even with DP floating point, if you are not precise about calculation ordering. Note that these occur on a regular basis in HPC, but far less so in embedded systems. Different types of problem, different solutions. > >>> I wonder what kinds of verification techniques exist for this. It's >>> above my pay grade, I guess. >> It should not be "above your pay grade" - even if you are an amateur. > > Verification (in the sense of certifying that the program does the right > thing for ALL POSSIBLE inputs, not just for your test vectors) is a very > complicated subject. I know a little about how it's done for integer > math, but floating point adds another level of complexity and I just > mean I don't have any clue how the high-assurance community deals with > it. It goes way beyond the topic at hand though. > If you don't know your program works, it is a useless program. That does not mean you "verify all possible inputs" - it means you write correct code, think about different possible cases, consider corner cases and extreme cases, and write test code to confirm your theories. If you don't know how to do that for the program in hand, you are not qualified to write the code. That means if you are writing code that does floating point calculations including things like matrix inversions, and you don't know how to be sure your values remain accurate (to within your requirements) and avoid nasty things like dividing by zero, subtracting nearly-equal numbers, etc., then get someone else to write the code. >> It's called "make sure your program works with the correct data". How >> do you know your function won't generate NaNs and other nonsense? > > There is nothing nonsensical about NaN's. They are part of the standard > and algorithms intended to run on standard-conformant hardware can and > do use NaN and Inf on purpose, expecting them to propagate through > calculations the way the standard says they should. If your floating > point implementation requires avoiding them, then you're imposing > restrictions on the user's algorithm choices. > In the real world, NaN's are nonsense. At best, they represent mistakes. Embedded systems are about the real world. Hence, NaN's are nonsense in c.a.e. and c.dsp. (Infinities might turn up in the mathematical theory behind the code - that's find, because they can be useful mathematical concepts. But in floating point code, they tell you that your algorithm or your implementation is either misused or broken.)
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-09-23 00:19 +0100 |
| Message-ID | <4WK%t.93316$iy6.63830@fx12.am4> |
| In reply to | #13803 |
On 22/09/13 20:31, David Brown wrote: > The kind of applications where IEEE really gets useful is when you need accurate control of the order of calculations - such as summing power series or inverting large matrices. These sorts of > calculations can quickly result in rubbish even with DP floating point, if you are not precise about calculation ordering. Provided, of course, that your compiler or combination of compiler flags doesn't decide to "optimise" the computation. > Note that these occur on a regular basis in HPC, but far less so in embedded systems. Different types of problem, different solutions. True in the past, but now embedded systems are sufficiently powerful to contain complex numerical algorithms that previously were the domain of HPC experts. There are, I am told by people that I respect, very good reasons why FORTRAN still rules in numerical computing. See some of the references in other postings for reasons, e.g. http://people.ds.cam.ac.uk/nmm1/Arithmetic/Notes/notes.pdf http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
[toc] | [prev] | [next] | [standalone]
Page 5 of 22 — ← Prev page 1 … 3 4 [5] 6 7 … 22 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web