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 6 of 22 — ← Prev page 1 … 4 5 [6] 7 8 … 22 Next page →
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2013-09-23 09:23 +0200 |
| Message-ID | <gLydnWM2lq_lcaLPnZ2dnUVZ8nednZ2d@lyse.net> |
| In reply to | #13806 |
On 23/09/13 01:19, Tom Gardner wrote: > 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. > Exactly true. That's why it is useful for a compiler to have flags like "-ffast-math". (I keep using gcc as an example here, as it is commonly used for all sorts of work from small embedded systems to large, fast, accurate HPC systems. Other compilers are presumably similar.) When you need full IEEE, and are willing to pay for it (such as by having an expensive cpu which handles everything quickly in hardware - or by sacrificing the code space and time), then you compile with full IEEE and the compiler will follow the ordering you give it. When you need small and fast calculations, and know that your algorithm is well behaved for the values you need, then you use "-ffast-math" and let the compiler re-arrange things. For those that need more control, there are more detailed compiler flags. It is not really any different from any other tradeoffs in calculations. In embedded systems, it's not uncommon to have to calculate sine waves. But if these are destined for an 8-bit accurate PWM signal, then there is no point in using an IEEE-compatible sinf() function correct to 23 significant bits - you can use a small table and linear interpolation to get all the accuracy you need. > >> 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 > As applications and uses change, so do the techniques you need to apply. And of course there are no clear boundaries - as noted before, all generalisations are false :-) There are plenty of embedded applications that require "HPC-style" calculations, and as microcontrollers get faster at arithmetic, there will be more. The key is to understand your requirements, understand the maths in your algorithms, and understand your compiler. You have to make sure that the code is correct - that it is accurate enough for the job in hand with the values you will use (both now and in the future), and that it is efficient enough for the system in hand. (Correctness trumps speed every time - but for embedded systems it is not uncommon to have a time limit as part of the correctness requirements.) Different techniques are needed to get this right - full IEEE is one way to control ordering and track incorrect calculations, but it is far from the only one.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-09-23 09:00 +0100 |
| Message-ID | <TyS%t.111927$k06.80134@fx32.am4> |
| In reply to | #13816 |
On 23/09/13 08:23, David Brown wrote: I agree with your other points... > The key is to understand your requirements, understand the maths in your > algorithms, and understand your compiler. That's true in an ideal world, but we live on Planet Earth. It is often difficult to find anybody that understands the application domain, is a numerical expert, and is a good engineer. Finding them in one person or several people in the same place at the same time is more than difficult. What normally happens is that you get several different people each of which incorrectly /thinks/ they understand most of the problem and solution. > Correctness trumps speed every time Even considering "the best is the enemy of the good", I wish I was that optimistic! :(
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2013-09-23 11:31 +0200 |
| Message-ID | <UaednaDdnIv8l93PnZ2dnUVZ7tudnZ2d@lyse.net> |
| In reply to | #13818 |
On 23/09/13 10:00, Tom Gardner wrote: > On 23/09/13 08:23, David Brown wrote: > > I agree with your other points... > >> The key is to understand your requirements, understand the maths in your >> algorithms, and understand your compiler. > > That's true in an ideal world, but we live on Planet Earth. > It is often difficult to find anybody that understands > the application domain, is a numerical expert, and is a > good engineer. Finding them in one person or several > people in the same place at the same time is more than > difficult. I have found a person who is pretty good at the numerical stuff (and can understand what he needs to find and read for the bits he doesn't know), and is a pretty good engineer - me. Now all I need to do is find the time to do /everything/ ! Your point is well taken. When this sort of thing gets complicated, there often has to be cooperation between different people here. The key is that there has to be someone who understands the issues with numerical computation, sitting between the mathematician (who knows that "a * b = b * a") and the programmer (who knows that "a * b == b * a") and can get the details right. IEEE ordering rules /may/ help a bit here, but they are only an aid - they certainly don't help for all issues. > > What normally happens is that you get several different > people each of which incorrectly /thinks/ they understand > most of the problem and solution. Haven't you heard that two minuses gives a plus? :-) > > >> Correctness trumps speed every time > > Even considering "the best is the enemy of the good", > I wish I was that optimistic! :( >
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-09-28 13:02 -0700 |
| Message-ID | <7xhad4vhoi.fsf@ruckus.brouhaha.com> |
| In reply to | #13803 |
David Brown <david.brown@removethis.hesbynett.no> writes: > No, "fast-math" is not about "withstanding wrong answers"... 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. You're saying in that application, speed is more important than accuracy, i.e. it can withstand answers that are wrong according to the expectations one would place on general purpose numerics. > Rough floating point - such as "-ffast-math" - is about a different > balance between the accuracy and the cost of the calculations. I like to think we're moving towards a world where floating point hardware is standard even in embedded MCU's used for anything numerical. So no need for anything like -ffast-math. > 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. ... Note that these occur > on a regular basis in HPC, but far less so in embedded systems. Wasn't this thread originally about a Kalman filter? Those involve matrix inverses (or at least pseudo-inverses) and are used all the time in embedded systems such as GPS navigation. >> Verification (in the sense of certifying that the program does the right >> thing for ALL POSSIBLE inputs, not just for your test vectors)... > 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. "Verification" in the fussier parts of the software assurance world means something more specific: it means you produce a machine-checked mathematical theorem that the program does what its specification says for all possible inputs, e.g. using something like Coq, or Spark/Ada, or maybe the DBC stuff in Ada 2012. That's what I was saying was above my pay grade for floating point programs. Obviously tons of real-world software is written without these methods, but they're becoming more accessible, and they're mandatory for some critical systems. > 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. Indeed, I've had (some) formal training in the subject, but yes, at my current level of knowledge I wouldn't want to work on serious numerics code without expert advice. At least I have enough sense to recognize this situation. I have my doubts about certain other people around here. By the way, one of the numerical analysis professors at my school used to say any idiot could write a good matrix inversion routine, but to compute eigenvalues properly you had to know what you were doing. > 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. Not at all. Say you have a navigation system: that's embedded, ok? Say you give it some coordinates you want to go to, with some constraints on the route that turn out to not have a solution. That could perfectly well result in some calculation giving a NaN, at which point the device tells you to try again. All working as intended. Or if you have a machine tool that does motion planning and you tell it a shape you want it to make, the same situation could arise. Embedded is not all about flushing toilets.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-09-28 22:54 +0100 |
| Message-ID | <weI1u.11041$s36.4564@fx06.am4> |
| In reply to | #13947 |
On 28/09/13 21:02, Paul Rubin wrote: > Wasn't this thread originally about a Kalman filter? Those involve > matrix inverses (or at least pseudo-inverses) and are used all the time > in embedded systems such as GPS navigation. snip > Indeed, I've had (some) formal training in the subject, but yes, at my > current level of knowledge I wouldn't want to work on serious numerics > code without expert advice. At least I have enough sense to recognize > this situation. I have my doubts about certain other people around > here. :) Just so. Know the feeling :)
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2013-09-28 22:33 +0000 |
| Message-ID | <l27lg6$gp0$1@speranza.aioe.org> |
| In reply to | #13947 |
In comp.dsp Paul Rubin <no.email@nospam.invalid> wrote: > David Brown <david.brown@removethis.hesbynett.no> writes: >> No, "fast-math" is not about "withstanding wrong answers"... 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. > You're saying in that application, speed is more important than > accuracy, i.e. it can withstand answers that are wrong according to the > expectations one would place on general purpose numerics. There are problems where you need somewhat less precision than those available, and a motor controller might be one. For a larger example, some iterative partial differential equation solvers are fairly insensitive to errors, as long as they can average out. Faster allows for a finer discretization, and so, in the end, more accurate results. Those are the kind of problems that Cray was designing for. >> Rough floating point - such as "-ffast-math" - is about a different >> balance between the accuracy and the cost of the calculations. > I like to think we're moving towards a world where floating point > hardware is standard even in embedded MCU's used for anything > numerical. So no need for anything like -ffast-math. Maybe, but in many cases more speed is still useful. >> 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. ... Note that these occur >> on a regular basis in HPC, but far less so in embedded systems. > Wasn't this thread originally about a Kalman filter? Those involve > matrix inverses (or at least pseudo-inverses) and are used all the > time in embedded systems such as GPS navigation. The important word above is large. Matrix inversion, and problems related to matrix inversion, easily lose as the matrix gets bigger. Available algorithms, such as partial pivoting, allow one to keep more of the precision along the way, and so larger matrices before all precision is gone. (snip) > By the way, one of the numerical analysis professors at my school > used to say any idiot could write a good matrix inversion routine, > but to compute eigenvalues properly you had to know what you > were doing. Probably true. For one, actual matrix inversion tends to be used only for small problems, and hopefully well conditioned problems. Otherwise, LU decomposition is more often used. (snip) -- glen
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-09-28 22:29 -0700 |
| Message-ID | <7x8uygmc0z.fsf@ruckus.brouhaha.com> |
| In reply to | #13955 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: >> that application... can withstand answers that are wrong according to >> the expectations one would place on general purpose numerics. > There are problems where you need somewhat less precision than those > available, and a motor controller might be one. I think we're in agreement. A general purpose solution has to be suitable for a wide range of applications, but a given specific application might be able to get by with something more limited. > For a larger example, some iterative partial differential equation > solvers are fairly insensitive to errors.... Those are the kind of > problems that Cray was designing for. Yeah, I remember Kahan mentioning that, Cray arithmetic was so inaccurate that you had to use very numerically robust algorithms on it. Found it: <http://www.drdobbs.com/architecture-and-design/a-conversation-with-william-kahan/184410314> ...and not ask the guys designing H-bombs or supersonic wings, because these latter don't give much of a damn about floating point. Their algorithms are very robust, they can tolerate all sorts of floating point, after all, they run on Crays! Anything that runs on a Cray doesn't care how you round, because a Cray rounds in a way that beggars description. I wonder whether fancier algorithms with lower computational complexity are equally numerically robust. >> world where floating point hardware is standard ... So no need for >> anything like -ffast-math. > Maybe, but in many cases more speed is still useful. Hardware sounds faster than software no matter what. In another post I mentioned a six dollar TI DSP that does around 0.8 GFlops in IEEE single precision or (IIRC) maybe a third of that in double precision. I wonder if there is any CPU that can simulate floating point with --fast-math at that speed. >> Wasn't this thread originally about a Kalman filter? Those involve >> matrix inverses > The important word above is large. Hmm, ok. I seem to remember hearing the original CAT scanners solved big linear systems (maybe not with actual inversion) so maybe that counts as an embedded application with large matrices. Later they did it more efficiently with the Radon transform. I don't know about now.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-09-29 10:01 +0100 |
| Message-ID | <b0S1u.10441$Ra5.5297@fx16.am4> |
| In reply to | #13967 |
On 29/09/13 06:29, Paul Rubin wrote: > Yeah, I remember Kahan mentioning that, Cray arithmetic was so > inaccurate that you had to use very numerically robust algorithms on it. > > Found it: > <http://www.drdobbs.com/architecture-and-design/a-conversation-with-william-kahan/184410314> Entertaining and useful reference, thanks. A good glimpse of the deficiencies of various languages and hardware. I liked these snippets about the "here there be dragons" issue... DDJ: So for those who are interested in the mathematical accuracy of their praxis, there are tools available for free that allow them to achieve this. WK: It is remarkable how infrequently these tools are used by people who ought to know better. DDJ: Like who? WK: Like Microsoft. But let's get back to John Palmar. ... WK: Most numerical computation doesn't matter. I know that sounds perverse, but in my experience, looking over the shoulders of other people, at least nine-tenths of what they compute gets thrown away, much of it without ever being looked at. They have only to get a glimpse of something to realize they never should have computed it in the first place. Most numerical computation doesn't matter, therefore a great deal of it can be wrong without deflecting the course of history. Some numerical computation matters a lot. We don't usually know what it is until afterwards. We may not know until too late. How do you know the answer is wrong unless you know the right answer? And if you knew the right one, why would you compute the wrong one? ... WK: Error creeps in. You have to learn the techniques of error analysis and decide what degree of error is tolerable. There are three good books... But look at the thickness of these books! Look at the bibliography in this one -- 1134 citations! People generally are not going to read these books. ... WK: So finally, in exasperation, [John Palmar] made them a sort of "put up or shut up" argument. He said, "I'll tell you what. I'll relinquish my salary, provided you'll write down your number of how many you expect to sell, then give me a dollar for every one you sell beyond that." They didn't do it, but if they had, John Palmar would not have to think of working for a living
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@removethis.hesbynett.no> |
|---|---|
| Date | 2013-09-29 23:02 +0200 |
| Message-ID | <yvCdncNwwonoCNXPnZ2dnUVZ8kednZ2d@lyse.net> |
| In reply to | #13947 |
On 28/09/13 22:02, Paul Rubin wrote: > David Brown <david.brown@removethis.hesbynett.no> writes: >> No, "fast-math" is not about "withstanding wrong answers"... 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. > > You're saying in that application, speed is more important than > accuracy, i.e. it can withstand answers that are wrong according to the > expectations one would place on general purpose numerics. I wonder if you are confusing accuracy and resolution. Floating point is /always/ approximate - as are pretty much all measurements and outputs. There is no such thing as "the expectations one would place on general purpose numerics" once you move outside the purely integer domain. Right or wrong is about be accurate /enough/ - once you are accurate enough, everything else is a waste of time and resources. > >> Rough floating point - such as "-ffast-math" - is about a different >> balance between the accuracy and the cost of the calculations. > > I like to think we're moving towards a world where floating point > hardware is standard even in embedded MCU's used for anything numerical. > So no need for anything like -ffast-math. You can like to think whatever you want, but the reality is that that the floating point hardware seen in embedded MCU's generally does not follow IEEE. It follows a "-ffast-math" style world - often with just single precision. At best, you get flags or can enable software exceptions to get the full IEEE (although these are seldom if ever used). In fact, since many software floating point libraries /do/ support IEEE, the move towards hardware floating point is a move /away/ from NaNs and friends. > >> 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. ... Note that these occur >> on a regular basis in HPC, but far less so in embedded systems. > > Wasn't this thread originally about a Kalman filter? Those involve > matrix inverses (or at least pseudo-inverses) and are used all the time > in embedded systems such as GPS navigation. > Yes, matrix inverses are used "all the time" in some embedded applications - although you should remember that these represent a tiny proportion of the world of embedded systems. But why are you worrying about matrix inverses? It is true that if your algorithms are implemented badly, then you can quickly lose precision when inverting large matrices. But if you think that IEEE - rather than -ffast-math - makes any significant difference, you are wrong. At best, it pushes the limit of "large" to very slightly larger. If your algorithms are good, and well-tuned to the data you are working with (you are not making general matrix inversions here - the data is application-specific), then your results will be good. If your algorithms are bad, then your results will be bad - and no amount of IEEE compliance will save you. >>> Verification (in the sense of certifying that the program does the right >>> thing for ALL POSSIBLE inputs, not just for your test vectors)... > >> 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. > > "Verification" in the fussier parts of the software assurance world > means something more specific: it means you produce a machine-checked > mathematical theorem that the program does what its specification says > for all possible inputs, e.g. using something like Coq, or Spark/Ada, or > maybe the DBC stuff in Ada 2012. That's what I was saying was above my > pay grade for floating point programs. Obviously tons of real-world > software is written without these methods, but they're becoming more > accessible, and they're mandatory for some critical systems. Perhaps I misread you - I thought you meant actively running through all possible inputs and checking that the results are as expected. This is sometimes done - I know of processors where the floating point hardware (single-precision only) has been verified in this way. The level of verification required varies enormously according to requirements - sometimes a few test vectors is enough, sometimes a formal mathematical proof is required (with or without the help of computerised theorem checking). Verification at the appropriate level for the job in hand should not be "above your pay grade" - it should be a critical part of all coding you do (in some jobs, most of the verification may be done by a separate person - but you certainly should be capable of doing it yourself). > >> 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. > > Indeed, I've had (some) formal training in the subject, but yes, at my > current level of knowledge I wouldn't want to work on serious numerics > code without expert advice. At least I have enough sense to recognize > this situation. I have my doubts about certain other people around > here. Knowing your limits is, of course, vital knowledge - and something a lot of people have trouble with! > > By the way, one of the numerical analysis professors at my school used > to say any idiot could write a good matrix inversion routine, but to > compute eigenvalues properly you had to know what you were doing. > >> 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. > > Not at all. Say you have a navigation system: that's embedded, ok? Say > you give it some coordinates you want to go to, with some constraints on > the route that turn out to not have a solution. That could perfectly > well result in some calculation giving a NaN, at which point the device > tells you to try again. All working as intended. Or if you have a > machine tool that does motion planning and you tell it a shape you want > it to make, the same situation could arise. Garbage in, garbage out. A NaN cannot turn garbage into something useful. At best, it can tell you you are getting garbage out - but it is much better if your code can figure out that the input data makes no sense, and take appropriate action. Consider "divide by zero" errors. When you rely on IEEE NaNs and infinities, you only get your NaN or inf when you are actually dividing by zero - when you are dividing by something close to zero, you get technically "correct" but equally meaningless values that propagate into more errors and nonsense numbers, causing all sorts of havoc along the way such as ruining your running averages or accumulators. On the other hand, if you simply check that the value makes sense (such as checking for a minimum absolute value), you can quickly and reliably identify the problem before anything goes wrong. > Embedded is not all about flushing toilets. The only concrete thing you can say about embedded systems is that they vary enormously. So I am sure there exist embedded applications where strict IEEE-compliant floating point (single or double) makes sense. But I am confident that it is very rare.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-30 10:36 -0400 |
| Message-ID | <l2c2ag$1o6$1@dont-email.me> |
| In reply to | #13977 |
On 9/29/2013 5:02 PM, David Brown wrote: > On 28/09/13 22:02, Paul Rubin wrote: >> David Brown <david.brown@removethis.hesbynett.no> writes: >>> No, "fast-math" is not about "withstanding wrong answers"... 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. >> >> You're saying in that application, speed is more important than >> accuracy, i.e. it can withstand answers that are wrong according to the >> expectations one would place on general purpose numerics. > > I wonder if you are confusing accuracy and resolution. Floating point is > /always/ approximate - as are pretty much all measurements and outputs. True for measurements, not true for floating point. 2.0 * 2.0 produces *exactly* 4.0 in floating point on every machine I've ever worked with. So it is not *always* approximate. I assume you are stating this in contrast to integers where you should keep the range of data within bounds of the integer yielding exact results. But of course that is the problem, because of the limited range integers become very limited in use. Then there is fixed point which can be calculated with integer operations, but in fixed point it is not uncommon to truncate multiply results making the answers *approximate*. So I fail to see your point really. > There is no such thing as "the expectations one would place on general > purpose numerics" once you move outside the purely integer domain. Right > or wrong is about be accurate /enough/ - once you are accurate enough, > everything else is a waste of time and resources. The only problem with integers is they just won't do for many calculations. <<<snip>>> >>>> Verification (in the sense of certifying that the program does the >>>> right >>>> thing for ALL POSSIBLE inputs, not just for your test vectors)... >> >>> 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. >> >> "Verification" in the fussier parts of the software assurance world >> means something more specific: it means you produce a machine-checked >> mathematical theorem that the program does what its specification says >> for all possible inputs, e.g. using something like Coq, or Spark/Ada, or >> maybe the DBC stuff in Ada 2012. That's what I was saying was above my >> pay grade for floating point programs. Obviously tons of real-world >> software is written without these methods, but they're becoming more >> accessible, and they're mandatory for some critical systems. > > Perhaps I misread you - I thought you meant actively running through all > possible inputs and checking that the results are as expected. This is > sometimes done - I know of processors where the floating point hardware > (single-precision only) has been verified in this way. Really? That would be at a minimum (assuming you check the different fields separately, 2**n where n is the sum of bits in two mantissas. Were these very *small* floating point formats? Even 20 bit mantissas require a trillion tests to verify all possible mantissa combinations. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Randy Yates <yates@digitalsignallabs.com> |
|---|---|
| Date | 2013-09-30 14:09 -0400 |
| Message-ID | <87pprqji4o.fsf@digitalsignallabs.com> |
| In reply to | #13990 |
rickman <gnuarm@gmail.com> writes: > [...] > The only problem with integers is they just won't do for many > calculations. Surprisingly few, in my experience. It is usually just _easier_ to write (double) floating point code. Do not neglect the fact that, with double floating point, you're throwing around 64 bits of data. 64 integer bits is a whole lot - more precision than a double (which I believe has already been stated). -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-10-01 01:27 -0400 |
| Message-ID | <l2dmhb$on2$1@dont-email.me> |
| In reply to | #14004 |
On 9/30/2013 2:09 PM, Randy Yates wrote: > rickman<gnuarm@gmail.com> writes: >> [...] >> The only problem with integers is they just won't do for many >> calculations. > > Surprisingly few, in my experience. It is usually just _easier_ to write > (double) floating point code. > > Do not neglect the fact that, with double floating point, you're > throwing around 64 bits of data. 64 integer bits is a whole lot - more > precision than a double (which I believe has already been stated). Precision and range are two different things. There are times when more range is required than even 64 bits provides. That is actually the *only* reason for using floating point, to get the extended range provided by the exponent, no? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2013-10-01 05:46 +0000 |
| Message-ID | <l2dnjs$1jo$1@speranza.aioe.org> |
| In reply to | #14023 |
In comp.dsp rickman <gnuarm@gmail.com> wrote: > On 9/30/2013 2:09 PM, Randy Yates wrote: >> rickman<gnuarm@gmail.com> writes: >>> The only problem with integers is they just won't do for many >>> calculations. >> Surprisingly few, in my experience. It is usually >> just _easier_ to write (double) floating point code. >> Do not neglect the fact that, with double floating point, you're >> throwing around 64 bits of data. 64 integer bits is a whole lot - more >> precision than a double (which I believe has already been stated). > Precision and range are two different things. There are times when more > range is required than even 64 bits provides. That is actually the > *only* reason for using floating point, to get the extended range > provided by the exponent, no? It should be, but it isn't. Well, for one, sometimes the range isn't so big for a give problem, but you don't know the order of magnitude well enough to use fixed point. If the operands and result have relative error, then floating point is still a good choice. Another reason is that many people don't know how to do scaled fixed point, or are too lazy to do it. The lack of support from many high-level languages doesn't help. But the real distinction should be absolute vs. relative error. When the error (uncertainty) is independent of the magnitude, then fixed point should be used. That is often true for DSP problems. -- glen
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2013-10-01 09:19 +0200 |
| Message-ID | <FoydnQRIpaUV6tfPnZ2dnUVZ8oCdnZ2d@lyse.net> |
| In reply to | #13990 |
On 30/09/13 16:36, rickman wrote: > On 9/29/2013 5:02 PM, David Brown wrote: >> On 28/09/13 22:02, Paul Rubin wrote: >>> David Brown <david.brown@removethis.hesbynett.no> writes: >>>> No, "fast-math" is not about "withstanding wrong answers"... 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. >>> >>> You're saying in that application, speed is more important than >>> accuracy, i.e. it can withstand answers that are wrong according to the >>> expectations one would place on general purpose numerics. >> >> I wonder if you are confusing accuracy and resolution. Floating point is >> /always/ approximate - as are pretty much all measurements and outputs. > > True for measurements, not true for floating point. 2.0 * 2.0 produces > *exactly* 4.0 in floating point on every machine I've ever worked with. > So it is not *always* approximate. I assume you are stating this in > contrast to integers where you should keep the range of data within > bounds of the integer yielding exact results. But of course that is the > problem, because of the limited range integers become very limited in > use. Then there is fixed point which can be calculated with integer > operations, but in fixed point it is not uncommon to truncate multiply > results making the answers *approximate*. > > So I fail to see your point really. On this last point we agree! Yes, there are occasions when the floating point implementation can be exact such as 2.0 * 2.0. But in general, it is /not/ exact. If you write "a = b / 3.0; c = a + a + a;" you cannot expect b and c to be equal. Of course integer and fixed point arithmetic can also be inexact - but they have a clear set of rules for which they /are/ exact. (I know IEEE has plenty of rules for floating - but they are inevitably much more complex, and in real life there is a certain amount of implementation dependent behaviour.) And my point is that floating point is always appropriate - I was not making claims that alternative types of arithmetic are always accurate. > > >> There is no such thing as "the expectations one would place on general >> purpose numerics" once you move outside the purely integer domain. Right >> or wrong is about be accurate /enough/ - once you are accurate enough, >> everything else is a waste of time and resources. > > The only problem with integers is they just won't do for many calculations. Again, I am not making /any/ claims that integers are the best for everything. (Though you might like to think about how floating point calculations are implemented in software - they use integer arithmetic. Apparently integer arithmetic /will/ do for /any/ calculation, if it can be done at all. Floating point just makes some calculations much easier to work with.) My argument is not against using floating point - it is against the mystical belief that IEEE compliance makes floating point somehow into exact mathematics rather than a numerical approximation, or that IEEE somehow makes a real-world difference in real-world embedded calculations. I am trying to point out to those that seem to have trouble understanding (not you, Rick) that all floating point is approximate. IEEE may give you marginally better tolerances in some circumstances than "-ffast-math" type floating point, but it is marginal, and does not affect the principle of picking the correct representation for the job in hand. > > <<<snip>>> > >>>>> Verification (in the sense of certifying that the program does the >>>>> right >>>>> thing for ALL POSSIBLE inputs, not just for your test vectors)... >>> >>>> 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. >>> >>> "Verification" in the fussier parts of the software assurance world >>> means something more specific: it means you produce a machine-checked >>> mathematical theorem that the program does what its specification says >>> for all possible inputs, e.g. using something like Coq, or Spark/Ada, or >>> maybe the DBC stuff in Ada 2012. That's what I was saying was above my >>> pay grade for floating point programs. Obviously tons of real-world >>> software is written without these methods, but they're becoming more >>> accessible, and they're mandatory for some critical systems. >> >> Perhaps I misread you - I thought you meant actively running through all >> possible inputs and checking that the results are as expected. This is >> sometimes done - I know of processors where the floating point hardware >> (single-precision only) has been verified in this way. > > Really? That would be at a minimum (assuming you check the different > fields separately, 2**n where n is the sum of bits in two mantissas. > Were these very *small* floating point formats? Even 20 bit mantissas > require a trillion tests to verify all possible mantissa combinations. > I don't know the details of what was tested. But the test bench involved thousands of the processors running flat out for 6 months, IIRC. The interesting thing is that a research student took the source code for the chip (or the part they were testing) and did a complete formal mathematical verification of the code. He found exactly the same flaws as the brute-force testing found, but he completed the job in 5 months!
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-10-01 03:28 -0400 |
| Message-ID | <l2dtjh$mkj$1@dont-email.me> |
| In reply to | #14035 |
On 10/1/2013 3:19 AM, David Brown wrote: > On 30/09/13 16:36, rickman wrote: >> On 9/29/2013 5:02 PM, David Brown wrote: >>> On 28/09/13 22:02, Paul Rubin wrote: >>>> David Brown<david.brown@removethis.hesbynett.no> writes: >>>>> No, "fast-math" is not about "withstanding wrong answers"... 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. >>>> >>>> You're saying in that application, speed is more important than >>>> accuracy, i.e. it can withstand answers that are wrong according to the >>>> expectations one would place on general purpose numerics. >>> >>> I wonder if you are confusing accuracy and resolution. Floating point is >>> /always/ approximate - as are pretty much all measurements and outputs. >> >> True for measurements, not true for floating point. 2.0 * 2.0 produces >> *exactly* 4.0 in floating point on every machine I've ever worked with. >> So it is not *always* approximate. I assume you are stating this in >> contrast to integers where you should keep the range of data within >> bounds of the integer yielding exact results. But of course that is the >> problem, because of the limited range integers become very limited in >> use. Then there is fixed point which can be calculated with integer >> operations, but in fixed point it is not uncommon to truncate multiply >> results making the answers *approximate*. >> >> So I fail to see your point really. > > On this last point we agree! > > Yes, there are occasions when the floating point implementation can be > exact such as 2.0 * 2.0. But in general, it is /not/ exact. If you > write "a = b / 3.0; c = a + a + a;" you cannot expect b and c to be > equal. Of course integer and fixed point arithmetic can also be inexact > - but they have a clear set of rules for which they /are/ exact. (I > know IEEE has plenty of rules for floating - but they are inevitably > much more complex, and in real life there is a certain amount of > implementation dependent behaviour.) And my point is that floating > point is always appropriate - I was not making claims that alternative > types of arithmetic are always accurate. Maybe I don't understand. I thought you were comparing fixed point and floating point. How would integer handle "a = b / 3; c = a + a + a;"? In the general case, not so well I expect. Your point about floating point being *always* approximate is no more right than to say fixed point is *always* approximate (in other words, wrong). I really don't get what your point is at all. >>> There is no such thing as "the expectations one would place on general >>> purpose numerics" once you move outside the purely integer domain. Right >>> or wrong is about be accurate /enough/ - once you are accurate enough, >>> everything else is a waste of time and resources. >> >> The only problem with integers is they just won't do for many calculations. > > Again, I am not making /any/ claims that integers are the best for > everything. (Though you might like to think about how floating point > calculations are implemented in software - they use integer arithmetic. > Apparently integer arithmetic /will/ do for /any/ calculation, if it > can be done at all. Floating point just makes some calculations much > easier to work with.) > > My argument is not against using floating point - it is against the > mystical belief that IEEE compliance makes floating point somehow into > exact mathematics rather than a numerical approximation, or that IEEE > somehow makes a real-world difference in real-world embedded > calculations. I am trying to point out to those that seem to have > trouble understanding (not you, Rick) that all floating point is > approximate. IEEE may give you marginally better tolerances in some > circumstances than "-ffast-math" type floating point, but it is > marginal, and does not affect the principle of picking the correct > representation for the job in hand. I don't think anyone has said "IEEE compliance makes floating point somehow into exact mathematics rather than a numerical approximation". Where did you get this? > I don't know the details of what was tested. But the test bench > involved thousands of the processors running flat out for 6 months, > IIRC. The interesting thing is that a research student took the source > code for the chip (or the part they were testing) and did a complete > formal mathematical verification of the code. He found exactly the same > flaws as the brute-force testing found, but he completed the job in 5 > months! Wow, hardware running flat out for 6 months or a grad student running flat out for 5 months. I'm not sure which is more impressive. Maybe a post-doc could have done it in three months? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2013-10-01 10:13 +0200 |
| Message-ID | <nI6dnQ4fr5ayGdfPnZ2dnUVZ8iadnZ2d@lyse.net> |
| In reply to | #14038 |
On 01/10/13 09:28, rickman wrote: > On 10/1/2013 3:19 AM, David Brown wrote: >> On 30/09/13 16:36, rickman wrote: >>> On 9/29/2013 5:02 PM, David Brown wrote: >>>> On 28/09/13 22:02, Paul Rubin wrote: >>>>> David Brown<david.brown@removethis.hesbynett.no> writes: >>>>>> No, "fast-math" is not about "withstanding wrong answers"... 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. >>>>> >>>>> You're saying in that application, speed is more important than >>>>> accuracy, i.e. it can withstand answers that are wrong according to >>>>> the >>>>> expectations one would place on general purpose numerics. >>>> >>>> I wonder if you are confusing accuracy and resolution. Floating >>>> point is >>>> /always/ approximate - as are pretty much all measurements and outputs. >>> >>> True for measurements, not true for floating point. 2.0 * 2.0 produces >>> *exactly* 4.0 in floating point on every machine I've ever worked with. >>> So it is not *always* approximate. I assume you are stating this in >>> contrast to integers where you should keep the range of data within >>> bounds of the integer yielding exact results. But of course that is the >>> problem, because of the limited range integers become very limited in >>> use. Then there is fixed point which can be calculated with integer >>> operations, but in fixed point it is not uncommon to truncate multiply >>> results making the answers *approximate*. >>> >>> So I fail to see your point really. >> >> On this last point we agree! >> >> Yes, there are occasions when the floating point implementation can be >> exact such as 2.0 * 2.0. But in general, it is /not/ exact. If you >> write "a = b / 3.0; c = a + a + a;" you cannot expect b and c to be >> equal. Of course integer and fixed point arithmetic can also be inexact >> - but they have a clear set of rules for which they /are/ exact. (I >> know IEEE has plenty of rules for floating - but they are inevitably >> much more complex, and in real life there is a certain amount of >> implementation dependent behaviour.) And my point is that floating >> point is always appropriate - I was not making claims that alternative >> types of arithmetic are always accurate. > > Maybe I don't understand. I thought you were comparing fixed point and > floating point. How would integer handle "a = b / 3; c = a + a + a;"? > In the general case, not so well I expect. > > Your point about floating point being *always* approximate is no more > right than to say fixed point is *always* approximate (in other words, > wrong). > > I really don't get what your point is at all. You are jumping in to a discussion (or argument) between other people here. This has become a huge thread with many branches - I think this branch has got crossed somehow. Someone has been saying that IEEE compliance is important because it gives stricter control of rounding, operation ordering, etc., along with features like NaNs and infs. I have been saying that it is not important in most uses - especially in the embedded world - because you can't rely on NaNs and infs for anything other than "something has gone wrong", and avoiding mistakes early is usually a better strategy, and because floating point is inherently inaccurate so your code must already tolerate rounding issues and the like. Integers or fixed point did not enter the discussion (in this argument, anyway) until you brought them up. So I am not arguing with /you/ here - I suspect you agree with me (when you do floating point in your FPGA, do you implement full IEEE ?). > > >>>> There is no such thing as "the expectations one would place on general >>>> purpose numerics" once you move outside the purely integer domain. >>>> Right >>>> or wrong is about be accurate /enough/ - once you are accurate enough, >>>> everything else is a waste of time and resources. >>> >>> The only problem with integers is they just won't do for many >>> calculations. >> >> Again, I am not making /any/ claims that integers are the best for >> everything. (Though you might like to think about how floating point >> calculations are implemented in software - they use integer arithmetic. >> Apparently integer arithmetic /will/ do for /any/ calculation, if it >> can be done at all. Floating point just makes some calculations much >> easier to work with.) >> >> My argument is not against using floating point - it is against the >> mystical belief that IEEE compliance makes floating point somehow into >> exact mathematics rather than a numerical approximation, or that IEEE >> somehow makes a real-world difference in real-world embedded >> calculations. I am trying to point out to those that seem to have >> trouble understanding (not you, Rick) that all floating point is >> approximate. IEEE may give you marginally better tolerances in some >> circumstances than "-ffast-math" type floating point, but it is >> marginal, and does not affect the principle of picking the correct >> representation for the job in hand. > > I don't think anyone has said "IEEE compliance makes floating point > somehow into exact mathematics rather than a numerical approximation". > Where did you get this? > > >> I don't know the details of what was tested. But the test bench >> involved thousands of the processors running flat out for 6 months, >> IIRC. The interesting thing is that a research student took the source >> code for the chip (or the part they were testing) and did a complete >> formal mathematical verification of the code. He found exactly the same >> flaws as the brute-force testing found, but he completed the job in 5 >> months! > > Wow, hardware running flat out for 6 months or a grad student running > flat out for 5 months. I'm not sure which is more impressive. Maybe a > post-doc could have done it in three months? > This was a /long/ time ago - 25 years or so. Back in the days when students had to work hard, and when chips and computers were expected to have a long market time, so you could do real long-term testing.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-10-01 12:39 -0400 |
| Message-ID | <l2ett1$csd$1@dont-email.me> |
| In reply to | #14041 |
On 10/1/2013 4:13 AM, David Brown wrote: > On 01/10/13 09:28, rickman wrote: >> On 10/1/2013 3:19 AM, David Brown wrote: >>> On 30/09/13 16:36, rickman wrote: >>>> On 9/29/2013 5:02 PM, David Brown wrote: >>>>> On 28/09/13 22:02, Paul Rubin wrote: >>>>>> You're saying in that application, speed is more important than >>>>>> accuracy, i.e. it can withstand answers that are wrong according to >>>>>> the >>>>>> expectations one would place on general purpose numerics. >>>>> >>>>> I wonder if you are confusing accuracy and resolution. Floating >>>>> point is >>>>> /always/ approximate - as are pretty much all measurements and outputs. >>>> >>>> True for measurements, not true for floating point. 2.0 * 2.0 produces >>>> *exactly* 4.0 in floating point on every machine I've ever worked with. >>>> So it is not *always* approximate. I assume you are stating this in >>>> contrast to integers where you should keep the range of data within >>>> bounds of the integer yielding exact results. But of course that is the >>>> problem, because of the limited range integers become very limited in >>>> use. Then there is fixed point which can be calculated with integer >>>> operations, but in fixed point it is not uncommon to truncate multiply >>>> results making the answers *approximate*. >>>> >>>> So I fail to see your point really. >>> >>> On this last point we agree! >>> >>> Yes, there are occasions when the floating point implementation can be >>> exact such as 2.0 * 2.0. But in general, it is /not/ exact. If you >>> write "a = b / 3.0; c = a + a + a;" you cannot expect b and c to be >>> equal. Of course integer and fixed point arithmetic can also be inexact >>> - but they have a clear set of rules for which they /are/ exact. (I >>> know IEEE has plenty of rules for floating - but they are inevitably >>> much more complex, and in real life there is a certain amount of >>> implementation dependent behaviour.) And my point is that floating >>> point is always appropriate - I was not making claims that alternative >>> types of arithmetic are always accurate. >> >> Maybe I don't understand. I thought you were comparing fixed point and >> floating point. How would integer handle "a = b / 3; c = a + a + a;"? >> In the general case, not so well I expect. >> >> Your point about floating point being *always* approximate is no more >> right than to say fixed point is *always* approximate (in other words, >> wrong). >> >> I really don't get what your point is at all. > > You are jumping in to a discussion (or argument) between other people > here. This has become a huge thread with many branches - I think this > branch has got crossed somehow. > > Someone has been saying that IEEE compliance is important because it > gives stricter control of rounding, operation ordering, etc., along with > features like NaNs and infs. I have been saying that it is not > important in most uses - especially in the embedded world - because you > can't rely on NaNs and infs for anything other than "something has gone > wrong", and avoiding mistakes early is usually a better strategy, and > because floating point is inherently inaccurate so your code must > already tolerate rounding issues and the like. > > Integers or fixed point did not enter the discussion (in this argument, > anyway) until you brought them up. > > So I am not arguing with /you/ here - I suspect you agree with me (when > you do floating point in your FPGA, do you implement full IEEE ?). I was simply responding to the statement about FP *always* being approximate. Unless it is qualified somehow it is an absurd statement. It is a given that FP will round if you do any number of non-simplistic calculations, but these same calcs would likely not fit a fixed point calculation either. So I don't follow the point. I don't see where anyone here is assuming FP is *always* exact either. >>> My argument is not against using floating point - it is against the >>> mystical belief that IEEE compliance makes floating point somehow into >>> exact mathematics rather than a numerical approximation, or that IEEE >>> somehow makes a real-world difference in real-world embedded >>> calculations. I am trying to point out to those that seem to have >>> trouble understanding (not you, Rick) that all floating point is >>> approximate. IEEE may give you marginally better tolerances in some >>> circumstances than "-ffast-math" type floating point, but it is >>> marginal, and does not affect the principle of picking the correct >>> representation for the job in hand. >> >> I don't think anyone has said "IEEE compliance makes floating point >> somehow into exact mathematics rather than a numerical approximation". >> Where did you get this? I didn't see a response to this. >>> I don't know the details of what was tested. But the test bench >>> involved thousands of the processors running flat out for 6 months, >>> IIRC. The interesting thing is that a research student took the source >>> code for the chip (or the part they were testing) and did a complete >>> formal mathematical verification of the code. He found exactly the same >>> flaws as the brute-force testing found, but he completed the job in 5 >>> months! >> >> Wow, hardware running flat out for 6 months or a grad student running >> flat out for 5 months. I'm not sure which is more impressive. Maybe a >> post-doc could have done it in three months? >> > > This was a /long/ time ago - 25 years or so. Back in the days when > students had to work hard, and when chips and computers were expected to > have a long market time, so you could do real long-term testing. I should have added a smilely at the end of that suggestion. In my day grad students were the final form of indentured servitude. I don't know about now. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> |
|---|---|
| Date | 2013-10-01 16:56 +0000 |
| Message-ID | <l2eusq$g3u$1@dont-email.me> |
| In reply to | #14047 |
On 2013-10-01, rickman <gnuarm@gmail.com> wrote: > > I should have added a smilely at the end of that suggestion. In my day > grad students were the final form of indentured servitude. I don't know > about now. > A long term review of phdcomics.com would seem to suggest it's _still_ the current practice. :-) Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2013-10-01 18:59 +0000 |
| Message-ID | <l2f62g$nb3$1@speranza.aioe.org> |
| In reply to | #14047 |
In comp.dsp rickman <gnuarm@gmail.com> wrote: (snip, someone wrote) >> Someone has been saying that IEEE compliance is important because it >> gives stricter control of rounding, operation ordering, etc., along with >> features like NaNs and infs. I have been saying that it is not >> important in most uses - especially in the embedded world - because you >> can't rely on NaNs and infs for anything other than "something has gone >> wrong", and avoiding mistakes early is usually a better strategy, and >> because floating point is inherently inaccurate so your code must >> already tolerate rounding issues and the like. >> Integers or fixed point did not enter the discussion (in this argument, >> anyway) until you brought them up. >> So I am not arguing with /you/ here - I suspect you agree with me (when >> you do floating point in your FPGA, do you implement full IEEE ?). > I was simply responding to the statement about FP *always* being > approximate. Unless it is qualified somehow it is an absurd > statement. Maybe better is that floating point should always be assumed to be approximate. Yes it often gives the exact result, but it is better not to assume that it does. In the days before the IEEE, there were many different forms that rounded and such different ways. Cray built machines with no divide, but instead allowed one to multiply by the reciprocal, either to full precision, or less than full precision (but faster). There was a Cray machine where mutliply wasn't commutative. That is, where X*Y-Y*X might not give zero. And there are a lot of scientific problems where such arithmetic is perfectly fine. The IBM Stretch allowed one to select between shifting in zeros and shifting in ones during post-normalization. That is, more or less, round up or round down. With IEEE, if you don't know the rounding mode in effect, then it is best to treat the result as approximate. > It is a given that FP will round if you do any number of > non-simplistic calculations, but these same calcs would > likely not fit a fixed point calculation either. So I don't > follow the point. I don't see where anyone here is > assuming FP is *always* exact either. Pretty much all machines allow one to do multiple word fixed point addition and subtraction. That was more important on the eight-bit processors, as that was needed to do larger operations. It isn't all that hard to do multiple word multiply. Divide is a little harder. It is, one most machines, somewhat harder to do higher precision floating point using the available operations. It can be done, is done, and is usually slow enough to discourage its use. (snip) -- glen
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-10-01 17:25 -0400 |
| Message-ID | <l2felv$ngh$1@dont-email.me> |
| In reply to | #14051 |
On 10/1/2013 2:59 PM, glen herrmannsfeldt wrote: > In comp.dsp rickman<gnuarm@gmail.com> wrote: > > (snip, someone wrote) >>> Someone has been saying that IEEE compliance is important because it >>> gives stricter control of rounding, operation ordering, etc., along with >>> features like NaNs and infs. I have been saying that it is not >>> important in most uses - especially in the embedded world - because you >>> can't rely on NaNs and infs for anything other than "something has gone >>> wrong", and avoiding mistakes early is usually a better strategy, and >>> because floating point is inherently inaccurate so your code must >>> already tolerate rounding issues and the like. > >>> Integers or fixed point did not enter the discussion (in this argument, >>> anyway) until you brought them up. > >>> So I am not arguing with /you/ here - I suspect you agree with me (when >>> you do floating point in your FPGA, do you implement full IEEE ?). > >> I was simply responding to the statement about FP *always* being >> approximate. Unless it is qualified somehow it is an absurd >> statement. > > Maybe better is that floating point should always be assumed to > be approximate. Yes it often gives the exact result, but it is > better not to assume that it does. > > In the days before the IEEE, there were many different forms that > rounded and such different ways. Cray built machines with no > divide, but instead allowed one to multiply by the reciprocal, > either to full precision, or less than full precision (but faster). > > There was a Cray machine where mutliply wasn't commutative. > That is, where X*Y-Y*X might not give zero. > > And there are a lot of scientific problems where such arithmetic > is perfectly fine. > > The IBM Stretch allowed one to select between shifting in zeros > and shifting in ones during post-normalization. That is, more or > less, round up or round down. > > With IEEE, if you don't know the rounding mode in effect, then > it is best to treat the result as approximate. > >> It is a given that FP will round if you do any number of >> non-simplistic calculations, but these same calcs would >> likely not fit a fixed point calculation either. So I don't >> follow the point. I don't see where anyone here is >> assuming FP is *always* exact either. > > Pretty much all machines allow one to do multiple word fixed > point addition and subtraction. That was more important on the > eight-bit processors, as that was needed to do larger operations. > It isn't all that hard to do multiple word multiply. Divide > is a little harder. It is, one most machines, somewhat harder to > do higher precision floating point using the available operations. > It can be done, is done, and is usually slow enough to discourage > its use. I'm just going to make one more point and then I'm done with this topic. Floating point is just fixed point with a range extending multiplier added. Anything you can do with fixed point you can do with floating point. The opposite is *not* true. -- Rick
[toc] | [prev] | [next] | [standalone]
Page 6 of 22 — ← Prev page 1 … 4 5 [6] 7 8 … 22 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web