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 2 of 22 — ← Prev page 1 [2] 3 4 … 22 Next page →
| From | David Brown <david.brown@removethis.hesbynett.no> |
|---|---|
| Date | 2013-09-15 22:12 +0200 |
| Message-ID | <1uWdneh9na0oiavPnZ2dnUVZ8judnZ2d@lyse.net> |
| In reply to | #13603 |
On 15/09/13 21:09, robert bristow-johnson wrote: > On 9/15/13 11:33 AM, rickman wrote: >> On 9/15/2013 2:02 PM, Tim Wescott wrote: >>> On Sun, 15 Sep 2013 12:33:10 -0400, rickman wrote: >>> >>>> On 9/15/2013 4:52 AM, Paul Rubin wrote: >>>>> rickman<gnuarm@gmail.com> writes: >>>>>>> Kalman filter >>>>>> Why is this algorithm so easy on a PC but so hard in an FPGA? >>>>> >>>>> The requirement of double precision floating point, one presumes. What >>>>> would the FPGA approach to that be? The DSP blocks in FPGA's are >>>>> usually fixed point and narrow. >>>> >>>> Do you know how floating point is calculated? The question says you >>>> don't. I assume you have only worked with floating point from the >>>> software perspective where the computation "just happens". >>> >>> Gosh, Rick. It must be nice to be smarter than everyone else on the >>> entire planet. >>> >>> Has it ever occurred to you that folks on comp.dsp are, by and large, >>> people who _do_ know things like that, and may have even implemented >>> floating point algorithms, possibly even in hardware? >> >> You did not add anything to the conversation. I asked the question >> because, as I stated, his question implies that he doesn't. If he did >> know how floating point was implemented in hardware he would know that >> the same multipliers used for fixed point are used for floating point. >> Someone knowledgeable might also know that floating point addition is >> pretty much the same complexity as multiplication and requires the use >> of multiplier blocks for optimal implementation in an FPGA. > > you use multiplier blocks for optimal implementation of barrel shifting > in an FPGA? i didn't know that. (and i don't know diddley about FPGA > programming, or about hooking them up. so there's a lot i don't know.) > >> >> If Paul does understand how floating point is implemented then I would >> next be asking him why he asked the question he did. >> >> Meanwhile you have added nothing to the conversation. If you want to >> discuss the issue I suggest that you not be so snarky about it. > > boy, glad i don't have dog in this tiff. > > i too, from what little i know regarding FPGAs, was a little dubious of > any inference that doing floating point in an FPGA is a paradigm shift. > but it's gotta be a little messier. i wouldn't think that doing it in > double is additionally messier, but it's gotta be *more*, of course. > > about the statement: "The DSP blocks in FPGA's are usually fixed point > and narrow." are you disputing that? are DSP blocks in FPGA's usually > floating point and phat and pheature-rich? like more FPGA designs are > being done which way? > > i dunno, honestly, you tell me. > He is simply disputing the idea that anything could be implemented in software more easily than in an FPGA. I know FPGA's can be useful devices, and I know that experts can write code for them faster and more efficiently than many non-experts would imagine, but I for one am getting fed up with this "FPGA are the best at everything - the fastest, cheapest, quickest development, lowest power, most efficient, longest living, best development tools, etc., etc." nonsense. Please, Rick, we /know/ FPGAs are useful devices. But give it a rest? No sane person - not even a Xilinx or Altera salesman - would claim that implementing a Kalman filter is not orders of magnitude harder in an FPGA than in software on a processor with good double precision floating point support. The X and A salesmen will tell you that this is why they put hard ARM cores in their chips - so you can do the PWM, encoders, etc., in FPGA, and the complex maths in the cpu.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-15 16:32 -0400 |
| Message-ID | <l155i2$42m$1@dont-email.me> |
| In reply to | #13608 |
On 9/15/2013 4:12 PM, David Brown wrote: > On 15/09/13 21:09, robert bristow-johnson wrote: >> On 9/15/13 11:33 AM, rickman wrote: >>> On 9/15/2013 2:02 PM, Tim Wescott wrote: >>>> On Sun, 15 Sep 2013 12:33:10 -0400, rickman wrote: >>>> >>>>> On 9/15/2013 4:52 AM, Paul Rubin wrote: >>>>>> rickman<gnuarm@gmail.com> writes: >>>>>>>> Kalman filter >>>>>>> Why is this algorithm so easy on a PC but so hard in an FPGA? >>>>>> >>>>>> The requirement of double precision floating point, one presumes. >>>>>> What >>>>>> would the FPGA approach to that be? The DSP blocks in FPGA's are >>>>>> usually fixed point and narrow. >>>>> >>>>> Do you know how floating point is calculated? The question says you >>>>> don't. I assume you have only worked with floating point from the >>>>> software perspective where the computation "just happens". >>>> >>>> Gosh, Rick. It must be nice to be smarter than everyone else on the >>>> entire planet. >>>> >>>> Has it ever occurred to you that folks on comp.dsp are, by and large, >>>> people who _do_ know things like that, and may have even implemented >>>> floating point algorithms, possibly even in hardware? >>> >>> You did not add anything to the conversation. I asked the question >>> because, as I stated, his question implies that he doesn't. If he did >>> know how floating point was implemented in hardware he would know that >>> the same multipliers used for fixed point are used for floating point. >>> Someone knowledgeable might also know that floating point addition is >>> pretty much the same complexity as multiplication and requires the use >>> of multiplier blocks for optimal implementation in an FPGA. >> >> you use multiplier blocks for optimal implementation of barrel shifting >> in an FPGA? i didn't know that. (and i don't know diddley about FPGA >> programming, or about hooking them up. so there's a lot i don't know.) >> >>> >>> If Paul does understand how floating point is implemented then I would >>> next be asking him why he asked the question he did. >>> >>> Meanwhile you have added nothing to the conversation. If you want to >>> discuss the issue I suggest that you not be so snarky about it. >> >> boy, glad i don't have dog in this tiff. >> >> i too, from what little i know regarding FPGAs, was a little dubious of >> any inference that doing floating point in an FPGA is a paradigm shift. >> but it's gotta be a little messier. i wouldn't think that doing it in >> double is additionally messier, but it's gotta be *more*, of course. >> >> about the statement: "The DSP blocks in FPGA's are usually fixed point >> and narrow." are you disputing that? are DSP blocks in FPGA's usually >> floating point and phat and pheature-rich? like more FPGA designs are >> being done which way? >> >> i dunno, honestly, you tell me. >> > > He is simply disputing the idea that anything could be implemented in > software more easily than in an FPGA. I know FPGA's can be useful > devices, and I know that experts can write code for them faster and more > efficiently than many non-experts would imagine, but I for one am > getting fed up with this "FPGA are the best at everything - the fastest, > cheapest, quickest development, lowest power, most efficient, longest > living, best development tools, etc., etc." nonsense. I never said anything of the sort. Please stop with the nonsense yourself. > Please, Rick, we /know/ FPGAs are useful devices. But give it a rest? No > sane person - not even a Xilinx or Altera salesman - would claim that > implementing a Kalman filter is not orders of magnitude harder in an > FPGA than in software on a processor with good double precision floating > point support. The X and A salesmen will tell you that this is why they > put hard ARM cores in their chips - so you can do the PWM, encoders, > etc., in FPGA, and the complex maths in the cpu. If you don't want to have a rational conversation, please don't reply. If you want to explain why a Kalman filter is so hard in an FPGA, please do. I'm sure it is not hard to show what part of the algorithm is FPGA unfriendly. As to the ARM cores, they are very recent if you look around. So it was never done until the ARM cores came out? As to the complex maths statement, I wish Ray Andraka were here. Of course he never bothered with such silly conversations, but as to the math, well, he is pretty much the expert. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2013-09-16 09:17 +0200 |
| Message-ID | <p66dnfsn0fo9LavPnZ2dnUVZ8lmdnZ2d@lyse.net> |
| In reply to | #13611 |
On 15/09/13 22:32, rickman wrote: > On 9/15/2013 4:12 PM, David Brown wrote: >> On 15/09/13 21:09, robert bristow-johnson wrote: >>> On 9/15/13 11:33 AM, rickman wrote: >>>> On 9/15/2013 2:02 PM, Tim Wescott wrote: >>>>> On Sun, 15 Sep 2013 12:33:10 -0400, rickman wrote: >>>>> >>>>>> On 9/15/2013 4:52 AM, Paul Rubin wrote: >>>>>>> rickman<gnuarm@gmail.com> writes: >>>>>>>>> Kalman filter >>>>>>>> Why is this algorithm so easy on a PC but so hard in an FPGA? >>>>>>> >>>>>>> The requirement of double precision floating point, one presumes. >>>>>>> What >>>>>>> would the FPGA approach to that be? The DSP blocks in FPGA's are >>>>>>> usually fixed point and narrow. >>>>>> >>>>>> Do you know how floating point is calculated? The question says you >>>>>> don't. I assume you have only worked with floating point from the >>>>>> software perspective where the computation "just happens". >>>>> >>>>> Gosh, Rick. It must be nice to be smarter than everyone else on the >>>>> entire planet. >>>>> >>>>> Has it ever occurred to you that folks on comp.dsp are, by and large, >>>>> people who _do_ know things like that, and may have even implemented >>>>> floating point algorithms, possibly even in hardware? >>>> >>>> You did not add anything to the conversation. I asked the question >>>> because, as I stated, his question implies that he doesn't. If he did >>>> know how floating point was implemented in hardware he would know that >>>> the same multipliers used for fixed point are used for floating point. >>>> Someone knowledgeable might also know that floating point addition is >>>> pretty much the same complexity as multiplication and requires the use >>>> of multiplier blocks for optimal implementation in an FPGA. >>> >>> you use multiplier blocks for optimal implementation of barrel shifting >>> in an FPGA? i didn't know that. (and i don't know diddley about FPGA >>> programming, or about hooking them up. so there's a lot i don't know.) >>> >>>> >>>> If Paul does understand how floating point is implemented then I would >>>> next be asking him why he asked the question he did. >>>> >>>> Meanwhile you have added nothing to the conversation. If you want to >>>> discuss the issue I suggest that you not be so snarky about it. >>> >>> boy, glad i don't have dog in this tiff. >>> >>> i too, from what little i know regarding FPGAs, was a little dubious of >>> any inference that doing floating point in an FPGA is a paradigm shift. >>> but it's gotta be a little messier. i wouldn't think that doing it in >>> double is additionally messier, but it's gotta be *more*, of course. >>> >>> about the statement: "The DSP blocks in FPGA's are usually fixed point >>> and narrow." are you disputing that? are DSP blocks in FPGA's usually >>> floating point and phat and pheature-rich? like more FPGA designs are >>> being done which way? >>> >>> i dunno, honestly, you tell me. >>> >> >> He is simply disputing the idea that anything could be implemented in >> software more easily than in an FPGA. I know FPGA's can be useful >> devices, and I know that experts can write code for them faster and more >> efficiently than many non-experts would imagine, but I for one am >> getting fed up with this "FPGA are the best at everything - the fastest, >> cheapest, quickest development, lowest power, most efficient, longest >> living, best development tools, etc., etc." nonsense. > > I never said anything of the sort. Please stop with the nonsense yourself. Re-read your posts of the past few days, in this thread and the "AREF bypass capacitance" thread. Fair enough, you haven't explicitly claimed that FPGA's are the best solution in all ways for all problems - I exaggerated. But you have made still a range of absurd claims about how good they are in many circumstances, despite evidence to the contrary. FPGAs have their uses - there are things you can do with them that would be near-impossible, and very expensive, to do in any other way. And there is an overlap of problems that can be solved by either processors/microcontrollers or FPGAs. But face facts - there are lots of problems that are more efficiently done in software, and that means a microcontroller or processor (or soft processor /if/ you already need an FPGA for other things). You will be a better advocate of FPGAs if you are realistic about them - at the moment, you are scaring off the fence-sitters. > > >> Please, Rick, we /know/ FPGAs are useful devices. But give it a rest? No >> sane person - not even a Xilinx or Altera salesman - would claim that >> implementing a Kalman filter is not orders of magnitude harder in an >> FPGA than in software on a processor with good double precision floating >> point support. The X and A salesmen will tell you that this is why they >> put hard ARM cores in their chips - so you can do the PWM, encoders, >> etc., in FPGA, and the complex maths in the cpu. > > If you don't want to have a rational conversation, please don't reply. > > If you want to explain why a Kalman filter is so hard in an FPGA, please > do. I'm sure it is not hard to show what part of the algorithm is FPGA > unfriendly. > I haven't implemented a Kalman filter myself, though I trust Tim's judgement here. But you don't need any experience to look at the Wikipedia page (or any other webpage or book) and see that this is a complex algorithm, and is best done step by step. What you seem to be missing entirely here is that no one is saying Kalman filters cannot be implemented on FPGAs - we are saying it is vastly more difficult to do so. It takes a lot of work to learn to understand these things, and to test and debug the code step by step. It is orders of magnitude easier with software that is easy to start and stop, debug, view data, print out logs of data, feed with test data, run on a PC rather than the target, etc. (And if you think to mention FPGA "simulation" - or even "co-simulation" - don't bother, for reasons that are obvious to everyone else. If you want to talk about MyHDL or Lava, I'll be happy to hear your new ideas.) When you have a good, working Kalman implementation in software, and you need to run it 100 times faster with little regard for hardware costs - /then/ it is time to break out the FPGA and transfer it over. > As to the ARM cores, they are very recent if you look around. So it was > never done until the ARM cores came out? Yes, people implemented Kalman filters in FPGAs before there were hard ARM cores - there were other hard cpu cores before that (PowerPC, and older weaker ARMs) as well as a multitude of soft cpu cores. And as I say, it /is/ possible to implement Kalman in "pure" fpga. People implement these things for a doctoral thesis - while in the pure software world, people knock them up in a couple of days using software downloaded from the net. /That/ is the difference. > > As to the complex maths statement, I wish Ray Andraka were here. Of > course he never bothered with such silly conversations, but as to the > math, well, he is pretty much the expert. >
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-09-16 10:21 +0100 |
| Message-ID | <o4AZt.92976$on4.18677@fx11.am4> |
| In reply to | #13623 |
On 16/09/13 08:17, David Brown wrote: > On 15/09/13 22:32, rickman wrote: >> I never said anything of the sort. Please stop with the nonsense yourself. > > Re-read your posts of the past few days, in this thread and the "AREF > bypass capacitance" thread. Fair enough, you haven't explicitly claimed > that FPGA's are the best solution in all ways for all problems - I > exaggerated. But you have made still a range of absurd claims about how > good they are in many circumstances, despite evidence to the contrary. > > FPGAs have their uses - there are things you can do with them that would > be near-impossible, and very expensive, to do in any other way. And > there is an overlap of problems that can be solved by either > processors/microcontrollers or FPGAs. But face facts - there are lots > of problems that are more efficiently done in software, and that means a > microcontroller or processor (or soft processor /if/ you already need an > FPGA for other things). > > You will be a better advocate of FPGAs if you are realistic about them - > at the moment, you are scaring off the fence-sitters. That just about sums up my perception as well. As I noted in a prelude to a note on the AREF thread 'My starting point is to be amused by anybody that implicitly extrapolates from "my previous constraints and requirements" to "everybody's constraints and requirements". Having got that out of the way...'
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-16 13:53 -0400 |
| Message-ID | <l17gj3$139$1@dont-email.me> |
| In reply to | #13623 |
On 9/16/2013 3:17 AM, David Brown wrote: > On 15/09/13 22:32, rickman wrote: >> On 9/15/2013 4:12 PM, David Brown wrote: >>> >>> He is simply disputing the idea that anything could be implemented in >>> software more easily than in an FPGA. I know FPGA's can be useful >>> devices, and I know that experts can write code for them faster and more >>> efficiently than many non-experts would imagine, but I for one am >>> getting fed up with this "FPGA are the best at everything - the fastest, >>> cheapest, quickest development, lowest power, most efficient, longest >>> living, best development tools, etc., etc." nonsense. >> >> I never said anything of the sort. Please stop with the nonsense yourself. > > Re-read your posts of the past few days, in this thread and the "AREF > bypass capacitance" thread. Fair enough, you haven't explicitly claimed > that FPGA's are the best solution in all ways for all problems - I > exaggerated. But you have made still a range of absurd claims about how > good they are in many circumstances, despite evidence to the contrary. This is a more reasonable conversation, but you still make unsupported claims. What did I say that was "absurd"? > FPGAs have their uses - there are things you can do with them that would > be near-impossible, and very expensive, to do in any other way. And > there is an overlap of problems that can be solved by either > processors/microcontrollers or FPGAs. But face facts - there are lots > of problems that are more efficiently done in software, and that means a > microcontroller or processor (or soft processor /if/ you already need an > FPGA for other things). Again, I have never said anything to the contrary. My point is that the line between the taks more usefully done on an FPGA and tasks done more usefully on an MCU is not where most people (at least in this thread) think it is. There is a *lot* of prejudice and bias about FPGAs and the effort required to use them. This mess started when I questioned the use of the word "nightmare" used to describe the FPGA development process. I don't think you are trying to support that claim are you? No, you are trying to make the point that it's not the opposite because you seem to feel I am saying FPGAs make everything easy. I'm not saying that and that is obvious if you read what I actually write. > You will be a better advocate of FPGAs if you are realistic about them - > at the moment, you are scaring off the fence-sitters. Again, you are making a claim about my position without any support. What did I say that was unrealistic? >>> Please, Rick, we /know/ FPGAs are useful devices. But give it a rest? No >>> sane person - not even a Xilinx or Altera salesman - would claim that >>> implementing a Kalman filter is not orders of magnitude harder in an >>> FPGA than in software on a processor with good double precision floating >>> point support. The X and A salesmen will tell you that this is why they >>> put hard ARM cores in their chips - so you can do the PWM, encoders, >>> etc., in FPGA, and the complex maths in the cpu. >> >> If you don't want to have a rational conversation, please don't reply. >> >> If you want to explain why a Kalman filter is so hard in an FPGA, please >> do. I'm sure it is not hard to show what part of the algorithm is FPGA >> unfriendly. >> > > I haven't implemented a Kalman filter myself, though I trust Tim's > judgement here. But you don't need any experience to look at the > Wikipedia page (or any other webpage or book) and see that this is a > complex algorithm, and is best done step by step. Why does that make it hard in an FPGA? > What you seem to be missing entirely here is that no one is saying > Kalman filters cannot be implemented on FPGAs - we are saying it is > vastly more difficult to do so. It takes a lot of work to learn to > understand these things, and to test and debug the code step by step. > It is orders of magnitude easier with software that is easy to start and > stop, debug, view data, print out logs of data, feed with test data, run > on a PC rather than the target, etc. (And if you think to mention FPGA > "simulation" - or even "co-simulation" - don't bother, for reasons that > are obvious to everyone else. If you want to talk about MyHDL or Lava, > I'll be happy to hear your new ideas.) Yes, they say it is *MUCH* harder to do in an FPGA... without *any* supporting evidence. Your bias is pretty clear from this paragraph alone. You list in detail the software process and then negate without ***any*** evidence the utility of HDL simulation. In fact, you decry it specifically stating that you don't need to provide any evidence because it is "obvious"!!! That is *exactly* the sort of bias I am addressing. Have you done FPGA work? > When you have a good, working Kalman implementation in software, and you > need to run it 100 times faster with little regard for hardware costs - /then/ it is time to break out the FPGA and transfer it over. More bias... this assumes that the *only* utility of an FPGA is to make things run very fast and that FPGA hardware costs are much higher than CPU hardware costs. Really? I have FPGA boards that sell for under $50. I believe the hardware cost the OP talked about was a SBC of some sort which is not likely to be under $50. >> As to the ARM cores, they are very recent if you look around. So it was >> never done until the ARM cores came out? > > Yes, people implemented Kalman filters in FPGAs before there were hard > ARM cores - there were other hard cpu cores before that (PowerPC, and > older weaker ARMs) as well as a multitude of soft cpu cores. And as I > say, it /is/ possible to implement Kalman in "pure" fpga. People > implement these things for a doctoral thesis - while in the pure > software world, people knock them up in a couple of days using software > downloaded from the net. /That/ is the difference. And yet, no one can tell me what aspect of a Kalman filter makes it so hard to implement in an FPGA... -- Rick
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2013-09-17 07:31 +0000 |
| Message-ID | <l190h8$4vl$1@speranza.aioe.org> |
| In reply to | #13639 |
In comp.dsp rickman <gnuarm@gmail.com> wrote: (snip, someone wrote) >> FPGAs have their uses - there are things you can do with them that would >> be near-impossible, and very expensive, to do in any other way. And >> there is an overlap of problems that can be solved by either >> processors/microcontrollers or FPGAs. But face facts - there are lots >> of problems that are more efficiently done in software, and that means a >> microcontroller or processor (or soft processor /if/ you already need an >> FPGA for other things). > Again, I have never said anything to the contrary. My point is that the > line between the taks more usefully done on an FPGA and tasks done more > usefully on an MCU is not where most people (at least in this thread) > think it is. There is a *lot* of prejudice and bias about FPGAs and the > effort required to use them. This mess started when I questioned the > use of the word "nightmare" used to describe the FPGA development > process. I don't think you are trying to support that claim are you? > No, you are trying to make the point that it's not the opposite because > you seem to feel I am saying FPGAs make everything easy. I'm not saying > that and that is obvious if you read what I actually write. When an existing processor is fast enough, that is probably the best choice. When a small number (cluster) is fast enough, that might also be the best choice. When you need to be 1000's of times faster, and the algorithm does a lot of fixed point addition, maybe some multiplication, you can do much better in a medium sized FPGA. For floating point algorithms, you might be able to use fixed point a little wider instead. A systolic array can be a very efficient way to process a large amount of data if the dependency is right. >> You will be a better advocate of FPGAs if you are realistic about them - >> at the moment, you are scaring off the fence-sitters. (snip) >> I haven't implemented a Kalman filter myself, though I trust Tim's >> judgement here. But you don't need any experience to look at the >> Wikipedia page (or any other webpage or book) and see that this is a >> complex algorithm, and is best done step by step. > Why does that make it hard in an FPGA? (snip) >> When you have a good, working Kalman implementation in software, and you >> need to run it 100 times faster with little regard for hardware costs - > /then/ it is time to break out the FPGA and transfer it over. Well, hardware costs usually do come in, but often enough the FPGA is cheaper than 100 or 1000 of the currently popular microprocessor. > More bias... this assumes that the *only* utility of an FPGA is to make > things run very fast and that FPGA hardware costs are much higher than > CPU hardware costs. Really? I have FPGA boards that sell for under > $50. I believe the hardware cost the OP talked about was a SBC of some > sort which is not likely to be under $50. Over the years, there have been many tries at boards for general purpose hardware acceleration that interface to another system. Most have not been very successful commercially. As well as I know it, mostly it is the problem of getting data into and out of the FPGA that makes it hard, and reduces the usefulness of the solution. -- glen
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-17 04:46 -0400 |
| Message-ID | <l194u1$1pi$1@dont-email.me> |
| In reply to | #13654 |
On 9/17/2013 3:31 AM, glen herrmannsfeldt wrote: > In comp.dsp rickman<gnuarm@gmail.com> wrote: > > (snip, someone wrote) > >>> FPGAs have their uses - there are things you can do with them that would >>> be near-impossible, and very expensive, to do in any other way. And >>> there is an overlap of problems that can be solved by either >>> processors/microcontrollers or FPGAs. But face facts - there are lots >>> of problems that are more efficiently done in software, and that means a >>> microcontroller or processor (or soft processor /if/ you already need an >>> FPGA for other things). > >> Again, I have never said anything to the contrary. My point is that the >> line between the taks more usefully done on an FPGA and tasks done more >> usefully on an MCU is not where most people (at least in this thread) >> think it is. There is a *lot* of prejudice and bias about FPGAs and the >> effort required to use them. This mess started when I questioned the >> use of the word "nightmare" used to describe the FPGA development >> process. I don't think you are trying to support that claim are you? >> No, you are trying to make the point that it's not the opposite because >> you seem to feel I am saying FPGAs make everything easy. I'm not saying >> that and that is obvious if you read what I actually write. > > When an existing processor is fast enough, that is probably the > best choice. When a small number (cluster) is fast enough, that might > also be the best choice. > > When you need to be 1000's of times faster, and the algorithm does > a lot of fixed point addition, maybe some multiplication, you can do > much better in a medium sized FPGA. > > For floating point algorithms, you might be able to use fixed point > a little wider instead. > > A systolic array can be a very efficient way to process a large > amount of data if the dependency is right. These are all your opinions. I find it interesting that you use a multiplier of 1000 for your cut over point. So at 100 you would use 100 CPUs rather than an FPGA? That is a rhetorical question... >>> You will be a better advocate of FPGAs if you are realistic about them - >>> at the moment, you are scaring off the fence-sitters. > > (snip) >>> I haven't implemented a Kalman filter myself, though I trust Tim's >>> judgement here. But you don't need any experience to look at the >>> Wikipedia page (or any other webpage or book) and see that this is a >>> complex algorithm, and is best done step by step. > >> Why does that make it hard in an FPGA? You didn't respond to this question. Would you care to comment? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | robert bristow-johnson <rbj@audioimagination.com> |
|---|---|
| Date | 2013-09-17 10:46 -0700 |
| Message-ID | <l1a4gv$pje$1@dont-email.me> |
| In reply to | #13659 |
On 9/17/13 1:46 AM, rickman wrote: > On 9/17/2013 3:31 AM, glen herrmannsfeldt wrote: ... >> >> When an existing processor is fast enough, that is probably the >> best choice. When a small number (cluster) is fast enough, that might >> also be the best choice. >> >> When you need to be 1000's of times faster, and the algorithm does >> a lot of fixed point addition, maybe some multiplication, you can do >> much better in a medium sized FPGA. >> >> For floating point algorithms, you might be able to use fixed point >> a little wider instead. >> in fact, sometimes with an apples-to-apples comparison (same word width), sometimes you get less mean square error with fixed. i have shown (at the 2008 AES) that comparing 32-bit IEEE float to 32-bit fixed, that if your required headroom is less than about 40 dB (and 40 dB headroom is an awful lotta headroom for audio, far more than necessary) that 32-bit fixed beats 32-bit float. since dB SNR + dB headroom add to a constant, it's even more pronounced if, say, only 12 dB headroom is needed (32-bit fixed point will have 28 dB better SNR than 32-bit float). so sometimes it doesn't even have to be "wider". >> A systolic array can be a very efficient way to process a large >> amount of data if the dependency is right. > > These are all your opinions. I find it interesting that you use a > multiplier of 1000 for your cut over point. So at 100 you would use 100 > CPUs rather than an FPGA? That is a rhetorical question... > i think that Glen was just covering his butt. certainly if your CPU "solution" is 1000 times shy of the computational bandwidth needed, making the "ware" a bit harder might be indicated. i dunno if you could even get a 1000 times improvement in speed, but maybe hope to. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."
[toc] | [prev] | [next] | [standalone]
| From | Randy Yates <yates@digitalsignallabs.com> |
|---|---|
| Date | 2013-09-17 22:30 -0400 |
| Message-ID | <87mwnauaij.fsf@digitalsignallabs.com> |
| In reply to | #13675 |
robert bristow-johnson <rbj@audioimagination.com> writes: > ... > in fact, sometimes with an apples-to-apples comparison (same word > width), sometimes you get less mean square error with fixed. i have > shown (at the 2008 AES) that comparing 32-bit IEEE float to 32-bit > fixed, that if your required headroom is less than about 40 dB (and 40 > dB headroom is an awful lotta headroom for audio, far more than > necessary) that 32-bit fixed beats 32-bit float. Robert, What do you mean by "headroom?" Do you mean the extra dynamic range required in the intermediate computations, such as is typically provided on fixed-point processors by the "guard" bits? Also, could I please get a copy of your preprint? -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-09-17 22:43 -0700 |
| Message-ID | <7xbo3qptw6.fsf@ruckus.brouhaha.com> |
| In reply to | #13675 |
robert bristow-johnson <rbj@audioimagination.com> writes: > shown (at the 2008 AES) that comparing 32-bit IEEE float to 32-bit > fixed,... 32-bit fixed beats 32-bit float. That's why 64-bit float was invented ;-). Seriously, the idea of double precision isn't that you need an ultra-precise final result, but rather, that if you're doing a numerical algorithm with a lot of steps that's accumulating a small amount of roundoff error in each step, the accumulated errors won't reach physical significance unless the calculation is unusually long or the algorithm is especially unstable at the input data. For that reason all these suggestions of using non-IEEE floating point formats sound hacky unless they're coming from numerics experts. The era of ad hoc floating point formats was the 1970's and earlier. The world has moved on since then.
[toc] | [prev] | [next] | [standalone]
| From | gtwrek@sonic.net (Mark Curry) |
|---|---|
| Date | 2013-09-18 14:35 +0000 |
| Message-ID | <l1cdn2$jf5$1@dont-email.me> |
| In reply to | #13687 |
In article <7xbo3qptw6.fsf@ruckus.brouhaha.com>, Paul Rubin <no.email@nospam.invalid> wrote: >robert bristow-johnson <rbj@audioimagination.com> writes: >> shown (at the 2008 AES) that comparing 32-bit IEEE float to 32-bit >> fixed,... 32-bit fixed beats 32-bit float. <snip> >For that reason all these suggestions of using non-IEEE >floating point formats sound hacky unless they're coming from numerics >experts. The era of ad hoc floating point formats was the 1970's and >earlier. The world has moved on since then. That's not the case at all for FPGAs and probably ASICs too. In fact, there's new support in VHDL for the IEEE "variable precision" floating point. Where the number of bits in the mantissa, and exponent are explictly set. It's a very good idea for HW design. And you don't need to be a "numerics" expert. It's not difficult at all. I point FPGA folks to Randy's fixed point tutorial all the time. Regards, Mark
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2013-09-18 18:41 +0300 |
| Message-ID | <6qgj39l04vfuc6ssdfb2le5h23gat6fg01@4ax.com> |
| In reply to | #13687 |
On Tue, 17 Sep 2013 22:43:05 -0700, Paul Rubin <no.email@nospam.invalid> wrote: >robert bristow-johnson <rbj@audioimagination.com> writes: >> shown (at the 2008 AES) that comparing 32-bit IEEE float to 32-bit >> fixed,... 32-bit fixed beats 32-bit float. > >That's why 64-bit float was invented ;-). Seriously, the idea of double >precision isn't that you need an ultra-precise final result, but rather, >that if you're doing a numerical algorithm with a lot of steps that's >accumulating a small amount of roundoff error in each step, the >accumulated errors won't reach physical significance unless the >calculation is unusually long or the algorithm is especially unstable at >the input data. For that reason all these suggestions of using non-IEEE >floating point formats sound hacky unless they're coming from numerics >experts. The era of ad hoc floating point formats was the 1970's and >earlier. The world has moved on since then. What so special about IEEE float/doubles ? The only, but _significant_, advantage was that finally you could easily transfer floating point data from one computer system (from different vendors) to an other in binary format using magnetic tapes and later TCP/IP. Before this, at least for ad hoc transfers, it was common practice to print out float values as decimal digits in ASCII/EBCDIC onto the magnetic tape and then read those decimal strings such as "+1.23456789E+05" into the other system and convert it to the local floating point representation. This of course caused all kinds of rounding/truncation errors. Fortunately with IEEE floats, this is no longer required, but only a few years ago, I had to write conversion routines for some old Siemens PLC floating point format with special location of the exponent field, the exponent bias/offset and hidden bit conventions to get the most of the accuracy needed.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-09-18 09:12 -0700 |
| Message-ID | <7x38p2p0qc.fsf@ruckus.brouhaha.com> |
| In reply to | #13692 |
upsidedown@downunder.com writes: > What so special about IEEE float/doubles ? The only, but > _significant_, advantage was that finally you could easily transfer > floating point data from one computer system ... to an other The much more significant difference is that numerical calculations work correctly in IEEE that were broken in earlier formats. That is why Prof. Kahan (the designer) got the Turing award. It wasn't for data interchangeability, it was for finally getting the math right. As he put it, he designed IEEE 754 to make the world safe for floating point hardware. http://www.cs.berkeley.edu/~wkahan/ieee754status/why-ieee.pdf gives some of the rationale for the standard. Other pages on his site are also interesting if you care about numerics.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2013-09-19 07:57 +0000 |
| Message-ID | <l1eaq3$7q8$1@speranza.aioe.org> |
| In reply to | #13695 |
In comp.dsp Paul Rubin <no.email@nospam.invalid> wrote: > upsidedown@downunder.com writes: >> What so special about IEEE float/doubles ? The only, but >> _significant_, advantage was that finally you could easily transfer >> floating point data from one computer system ... to an other > The much more significant difference is that numerical calculations > work correctly in IEEE that were broken in earlier formats. > That is why Prof. Kahan (the designer) got the Turing award. > It wasn't for data interchangeability, it was for finally > getting the math right. As he put it, he designed IEEE 754 > to make the world safe for floating point hardware. I suppose, but I still think that denormals were a bad idea. Each exponent bit double the range of representable values. Denormals increase the range slightly, by much less than one bith worth, with a large extra cost in logic. Inf and NaN are nice, but not needed for a hardware array implementation. You can easily supply extra data lines to pass the needed information along with the numeric value. That takes much less logic than generating and decoding the Inf/NaN bit patterns. > http://www.cs.berkeley.edu/~wkahan/ieee754status/why-ieee.pdf gives some > of the rationale for the standard. Other pages on his site are also > interesting if you care about numerics. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-09-19 22:22 -0700 |
| Message-ID | <7xhadg2hjs.fsf@ruckus.brouhaha.com> |
| In reply to | #13729 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > I suppose, but I still think that denormals were a bad idea. That was the subject of a very long debate mentioned in the interview I linked in another post, but consensus finally emerged at the time, and appears to have held up in retrospect, that the denormals (I think this is what they mean by gradual underflow) was the right thing. > Inf and NaN are nice, but not needed for a hardware array > implementation. Really, they are used in calculations. You can run a calculation without a lot of intermediate tests because you can check at the end if a NaN came out. Similarly in cases where you can get real answers despite the appearance of Inf in some intermediate result (e.g. since 1/Inf=0), you can rely on it working. That isn't someone abusing the standard in some way that's too smart for their own good. The standard was designed in order to make that type of calculation work in the determinate cases and give NaN in the indeterminate cases.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2013-09-20 05:44 +0000 |
| Message-ID | <l1gnc1$j0o$1@speranza.aioe.org> |
| In reply to | #13768 |
In comp.dsp Paul Rubin <no.email@nospam.invalid> wrote: (snip) >> Inf and NaN are nice, but not needed for a hardware array >> implementation. > Really, they are used in calculations. You can run a calculation > without a lot of intermediate tests because you can check at the end if > a NaN came out. Similarly in cases where you can get real answers > despite the appearance of Inf in some intermediate result (e.g. since > 1/Inf=0), you can rely on it working. That isn't someone abusing the > standard in some way that's too smart for their own good. The standard > was designed in order to make that type of calculation work in the > determinate cases and give NaN in the indeterminate cases. I think you snipped out too much. In an FPGA implementation, it is easier to just run a separate line saying that the value is Inf or NaN. That is faster and easier than coding it into 64 bits, and then decoding it again just a little later. It is the bit representation that isn't needed, not the concept. (I suppose that was confusing, since I was also suggesting that the concept of denormals wasn't needed.) -- glen
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-09-20 00:05 -0700 |
| Message-ID | <7x8uysas7b.fsf@ruckus.brouhaha.com> |
| In reply to | #13771 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > In an FPGA implementation, it is easier to just run a separate line > saying that the value is Inf or NaN. That is faster and easier than > coding it into 64 bits, and then decoding it again just a little later. > It is the bit representation that isn't needed, not the concept. I see, yeah, that makes some sense, as long as the algorithm can make use of the features. I'm still pretty unclear about how a conventionally presented algorithm is supposed to be translated into FPGA form.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2013-09-20 14:18 +0000 |
| Message-ID | <l1hlf7$7c3$1@speranza.aioe.org> |
| In reply to | #13773 |
In comp.dsp Paul Rubin <no.email@nospam.invalid> wrote: (snip, I wrote) >> In an FPGA implementation, it is easier to just run a separate line >> saying that the value is Inf or NaN. That is faster and easier than >> coding it into 64 bits, and then decoding it again just a little later. >> It is the bit representation that isn't needed, not the concept. > I see, yeah, that makes some sense, as long as the algorithm > can make use of the features. If not, then no need to wire it up. Seems to me that some would do best with saturating arithmetic, where overflow generates the largest value and underflow zero. That is probably better than wrapping. > I'm still pretty unclear about how a conventionally presented > algorithm is supposed to be translated into FPGA form. My favorite for FPGA is the systolic array. Some algorithms are easy to convert to systolic array form, others not so easy. -- glen
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2013-09-20 16:24 +0300 |
| Message-ID | <3vho391ov5dfhhf0cff9ahar36pi5l2ra6@4ax.com> |
| In reply to | #13771 |
On Fri, 20 Sep 2013 05:44:33 +0000 (UTC), glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >In comp.dsp Paul Rubin <no.email@nospam.invalid> wrote: > >(snip) > >>> Inf and NaN are nice, but not needed for a hardware array >>> implementation. > >> Really, they are used in calculations. You can run a calculation >> without a lot of intermediate tests because you can check at the end if >> a NaN came out. Similarly in cases where you can get real answers >> despite the appearance of Inf in some intermediate result (e.g. since >> 1/Inf=0), you can rely on it working. That isn't someone abusing the >> standard in some way that's too smart for their own good. The standard >> was designed in order to make that type of calculation work in the >> determinate cases and give NaN in the indeterminate cases. > >I think you snipped out too much. > >In an FPGA implementation, it is easier to just run a separate line >saying that the value is Inf or NaN. That is faster and easier than >coding it into 64 bits, and then decoding it again just a little later. > >It is the bit representation that isn't needed, not the concept. In industrial control systems, often 8-16 additional bits are transferred with the actual measurement all the way from the sensor through out the system to an operator display or controller. These extra bits are often called data quality or fault bits. Such bits could include sensor cable open/shorted, out of range etc. but an overflowing intermediate calculation could add an overflow bit to this bit mask. The final data user then has to determine how to react to this data. On the operator's display, questionable data could be displayed in a different colour or discard questionable data from a control loop. In the Harrisburg case, there was a lot of confusion, which sensors produced reliable values and which didn't. In some situations, the quality of data may be even more important as the actual value. Now the question is, is it sufficient to code some special values into the FP representation or add one or two lines in a FPGA implementation.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-09-20 08:31 +0100 |
| Message-ID | <NRS_t.133985$AH1.15468@fx19.am4> |
| In reply to | #13768 |
On 20/09/13 06:22, Paul Rubin wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>> I suppose, but I still think that denormals were a bad idea.
>
> That was the subject of a very long debate mentioned in the interview I
> linked in another post, but consensus finally emerged at the time, and
> appears to have held up in retrospect, that the denormals (I think this
> is what they mean by gradual underflow) was the right thing.
>
>> Inf and NaN are nice, but not needed for a hardware array
>> implementation.
>
> Really, they are used in calculations. You can run a calculation
> without a lot of intermediate tests because you can check at the end if
> a NaN came out. Similarly in cases where you can get real answers
> despite the appearance of Inf in some intermediate result (e.g. since
> 1/Inf=0), you can rely on it working. That isn't someone abusing the
> standard in some way that's too smart for their own good. The standard
> was designed in order to make that type of calculation work in the
> determinate cases and give NaN in the indeterminate cases.
I highly recommend reading this set of notes:
- lightly and amusingly written
- information dense
- university course in "how to avoid being bitten by
computer arithmetic"
- theoretical, why features are there and how features interact
- practical, how various languages get it right/wrong
- written by somebody that has been on the sharp end
of diagnosing corner-case HPC "issues" over the last 40 years
Even a cursory inspection will cut through some of
the arrogant guff that has appeared in this thread
http://people.ds.cam.ac.uk/nmm1/Arithmetic/Notes/notes.pdf
http://people.ds.cam.ac.uk/nmm1/Arithmetic/index.html
[toc] | [prev] | [next] | [standalone]
Page 2 of 22 — ← Prev page 1 [2] 3 4 … 22 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web