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 7 of 22 — ← Prev page 1 … 5 6 [7] 8 9 … 22 Next page →
| From | Randy Yates <yates@digitalsignallabs.com> |
|---|---|
| Date | 2013-10-01 18:37 -0400 |
| Message-ID | <87k3hw39ec.fsf@digitalsignallabs.com> |
| In reply to | #14054 |
rickman <gnuarm@gmail.com> writes: > [...] > I'm just going to make one more point and then I'm done with this > topic. Floating point is just fixed point with a range extending > multiplier added. Anything you can do with fixed point you can do > with floating point. The opposite is *not* true. Here is something you can do with fixed-point that you can't do with floating point: perform a multiply-accumulate with 64 bits of precision. -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
[toc] | [prev] | [next] | [standalone]
| From | Randy Yates <yates@digitalsignallabs.com> |
|---|---|
| Date | 2013-10-01 19:29 -0400 |
| Message-ID | <871u4436z9.fsf@digitalsignallabs.com> |
| In reply to | #14056 |
Randy Yates <yates@digitalsignallabs.com> writes: > rickman <gnuarm@gmail.com> writes: >> [...] >> I'm just going to make one more point and then I'm done with this >> topic. Floating point is just fixed point with a range extending >> multiplier added. Anything you can do with fixed point you can do >> with floating point. The opposite is *not* true. > > Here is something you can do with fixed-point that you can't do > with floating point: perform a multiply-accumulate with 64 bits > of precision. That is presuming a few things, for one, that the intermediate accumulator done with at least > 64 bits. My point is that, for certain operations (i.e., MACs), if you want the best possible precision, use 64-bit fixed-point, not floating-point, presuming the range of a 64-bit integer suffices. -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
[toc] | [prev] | [next] | [standalone]
| From | Randy Yates <yates@digitalsignallabs.com> |
|---|---|
| Date | 2013-10-01 19:31 -0400 |
| Message-ID | <87txh01sce.fsf@digitalsignallabs.com> |
| In reply to | #14058 |
Randy Yates <yates@digitalsignallabs.com> writes: > (i.e., MACs) Correction: "e.g., MACs". -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
[toc] | [prev] | [next] | [standalone]
| From | robert bristow-johnson <rbj@audioimagination.com> |
|---|---|
| Date | 2013-10-01 16:36 -0700 |
| Subject | Re: Small, fast, resource-rich processor (die evil thread, die!!!) |
| Message-ID | <l2fm9b$20a$1@dont-email.me> |
| In reply to | #14056 |
with apologies to Tim, who started a nice thread. but it's time, i think, to euthanize it. maybe not. some threads go on forever. On 10/1/13 3:37 PM, Randy Yates wrote: > rickman<gnuarm@gmail.com> writes: >> [...] >> I'm just going to make one more point and then I'm done with this >> topic. promise? >> Floating point is just fixed point with a range extending >> multiplier added. Anything you can do with fixed point you can do >> with floating point. The opposite is *not* true. and neither is the non-opposite true. if i were Vlad, i might point out in some undiplomatic language that this is a naive belief. > Here is something you can do with fixed-point that you can't do > with floating point: perform a multiply-accumulate with 64 bits > of precision. that's processor specific, i think, ain't it, Randy? i mean, a SHArC can do 32x32 to 64 bits. does that count? here's something that's not processor specific: moving sum or moving average filter implemented as the simplest non-trivial TIIR (Truncated IIR filter, which is theoretically an FIR). do it in float and you'll get little turds stuck this critically-stable feedback loop. those turds accumulate, given enough time. do it in fixed and you *know* that you are subtracting exactly what you added N samples prior to that. and you know what you are adding now will eventually be perfectly subtracted later. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."
[toc] | [prev] | [next] | [standalone]
| From | Randy Yates <yates@digitalsignallabs.com> |
|---|---|
| Date | 2013-10-01 20:51 -0400 |
| Subject | Re: Small, fast, resource-rich processor (die evil thread, die!!!) |
| Message-ID | <87eh841om6.fsf@digitalsignallabs.com> |
| In reply to | #14060 |
robert bristow-johnson <rbj@audioimagination.com> writes: > with apologies to Tim, who started a nice thread. but it's time, i > think, to euthanize it. > > maybe not. some threads go on forever. > > On 10/1/13 3:37 PM, Randy Yates wrote: >> rickman<gnuarm@gmail.com> writes: >>> [...] >>> I'm just going to make one more point and then I'm done with this >>> topic. > > promise? > >>> Floating point is just fixed point with a range extending >>> multiplier added. Anything you can do with fixed point you can do >>> with floating point. The opposite is *not* true. > > and neither is the non-opposite true. if i were Vlad, i might point > out in some undiplomatic language that this is a naive belief. > >> Here is something you can do with fixed-point that you can't do >> with floating point: perform a multiply-accumulate with 64 bits >> of precision. > > that's processor specific, i think, ain't it, Randy? i mean, a SHArC > can do 32x32 to 64 bits. does that count? well, if you are saying "in one cycle," then yes, it's processor specific. I just meant generally, using standard C data types (especially the stdint.h stuff like int16_t, int32_t, int64_t, etc.) that should extend on whatever processor. > here's something that's not processor specific: > > moving sum or moving average filter implemented as the simplest > non-trivial TIIR (Truncated IIR filter, which is theoretically an > FIR). > > do it in float and you'll get little turds stuck this > critically-stable feedback loop. those turds accumulate, given enough > time. do it in fixed and you *know* that you are subtracting exactly > what you added N samples prior to that. and you know what you are > adding now will eventually be perfectly subtracted later. another good example. -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
[toc] | [prev] | [next] | [standalone]
| From | Randy Yates <yates@digitalsignallabs.com> |
|---|---|
| Date | 2013-10-01 21:08 -0400 |
| Subject | Re: Small, fast, resource-rich processor (die evil thread, die!!!) |
| Message-ID | <87vc1gcwda.fsf@digitalsignallabs.com> |
| In reply to | #14062 |
Randy Yates <yates@digitalsignallabs.com> writes: > well, if you are saying "in one cycle," then yes, it's processor > specific. I just meant generally, using standard C data types > (especially the stdint.h stuff like int16_t, int32_t, int64_t, etc.) > that should extend on whatever processor. Hmm, well I just learned something I didn't know. According to the C99 spec, the integer types I mentioned above are not required. However, int_least8_t int_least16_t int_least32_t int_least64_t are. But to do a 64-bit MAC with reasonable precision you would need an int_least128_t, which is not required. So I guess this is processor specific. -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2013-10-02 09:08 +0200 |
| Subject | Re: Small, fast, resource-rich processor (die evil thread, die!!!) |
| Message-ID | <5uOdnYwT3-kUW9bPnZ2dnUVZ8oednZ2d@lyse.net> |
| In reply to | #14064 |
On 02/10/13 03:08, Randy Yates wrote: > Randy Yates <yates@digitalsignallabs.com> writes: > >> well, if you are saying "in one cycle," then yes, it's processor >> specific. I just meant generally, using standard C data types >> (especially the stdint.h stuff like int16_t, int32_t, int64_t, etc.) >> that should extend on whatever processor. > > Hmm, well I just learned something I didn't know. According to the C99 > spec, the integer types I mentioned above are not required. The size-specific types /are/ required if the target supports them - which means almost every system other than some DSP's with minimum data sizes greater than 8 bits. > > However, > > int_least8_t > int_least16_t > int_least32_t > int_least64_t > > are. int_least64_t is not required unless the compiler supports a suitable type. The "int_fast8_t" and family are also required in the same way as the "int_least8_t" family. > > But to do a 64-bit MAC with reasonable precision you would need an > int_least128_t, which is not required. So I guess this is processor > specific. > Compilers don't seem to support 128-bit types very well, unless the target is at least 64-bit in the first place. There is no fundamental reason for this - having a 32-bit target support 128-bit "long long long ints" is no different from having an 8-bit target support 32-bit "long int". gcc for the 8-bit avr even supports 64-bit ints. I suppose there is not much demand for 128-bit integers.
[toc] | [prev] | [next] | [standalone]
| From | Mel Wilson <mwilson@the-wire.com> |
|---|---|
| Date | 2013-10-02 09:36 -0400 |
| Subject | Re: Small, fast, resource-rich processor (die evil thread, die!!!) |
| Message-ID | <l2h7ha$j90$1@dont-email.me> |
| In reply to | #14070 |
David Brown > Compilers don't seem to support 128-bit types very well, unless the > target is at least 64-bit in the first place. There is no fundamental > reason for this - having a 32-bit target support 128-bit "long long long > ints" is no different from having an 8-bit target support 32-bit "long > int". gcc for the 8-bit avr even supports 64-bit ints. I suppose there > is not much demand for 128-bit integers. The number of atoms in the universe is estimated to be 1e80 within a couple of orders of magnitude. The square root of that would be about a 120-bit number. You'd think there would be a need. Mel.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2013-10-02 17:16 -0500 |
| Subject | Re: Small, fast, resource-rich processor (die evil thread, die!!!) |
| Message-ID | <mb6p495msh2b2hj40f88hn28mf23463656@4ax.com> |
| In reply to | #14084 |
On Wed, 02 Oct 2013 09:36:37 -0400, Mel Wilson <mwilson@the-wire.com> wrote: >David Brown >> Compilers don't seem to support 128-bit types very well, unless the >> target is at least 64-bit in the first place. There is no fundamental >> reason for this - having a 32-bit target support 128-bit "long long long >> ints" is no different from having an 8-bit target support 32-bit "long >> int". gcc for the 8-bit avr even supports 64-bit ints. I suppose there >> is not much demand for 128-bit integers. > >The number of atoms in the universe is estimated to be 1e80 within a couple >of orders of magnitude. The square root of that would be about a 120-bit >number. You'd think there would be a need. Folks doing monetary stuff commonly use ~128 bit integers under the hood. Even when scaled 64 bit numbers are sufficient for all stored values, intermediate results are often bigger. The Cobol folks, who, if nothing else, care about handling currency, have specified ~64 bit integers (actually the requirement is that the user can define types with 18 decimal digits and a sign), and intermediates of twice that size since the sixties, and more recent standards have doubled those requirements.
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2013-10-03 10:15 +0300 |
| Subject | Re: Small, fast, resource-rich processor (die evil thread, die!!!) |
| Message-ID | <nu5q49l07mmh7opa3c4t6nl8dc1qj2vp7o@4ax.com> |
| In reply to | #14096 |
On Wed, 02 Oct 2013 17:16:04 -0500, Robert Wessel <robertwessel2@yahoo.com> wrote: >>The number of atoms in the universe is estimated to be 1e80 within a couple >>of orders of magnitude. The square root of that would be about a 120-bit >>number. You'd think there would be a need. > > >Folks doing monetary stuff commonly use ~128 bit integers under the >hood. Even when scaled 64 bit numbers are sufficient for all stored >values, intermediate results are often bigger. > >The Cobol folks, who, if nothing else, care about handling currency, >have specified ~64 bit integers (actually the requirement is that the >user can define types with 18 decimal digits and a sign), and >intermediates of twice that size since the sixties, and more recent >standards have doubled those requirements. COBOL people often store numeric data as one ASCII/EBCDIC numeric character in a byte or as two BCD digits in a byte. Thus, there is quite a flexibility in allocating storage for permanent storage as well as intermediate results.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2013-10-03 02:32 -0500 |
| Subject | Re: Small, fast, resource-rich processor (die evil thread, die!!!) |
| Message-ID | <gm6q49ppei28p4ebvuttmm2utklvf2cp5m@4ax.com> |
| In reply to | #14102 |
On Thu, 03 Oct 2013 10:15:09 +0300, upsidedown@downunder.com wrote: >On Wed, 02 Oct 2013 17:16:04 -0500, Robert Wessel ><robertwessel2@yahoo.com> wrote: > >>>The number of atoms in the universe is estimated to be 1e80 within a couple >>>of orders of magnitude. The square root of that would be about a 120-bit >>>number. You'd think there would be a need. >> >> >>Folks doing monetary stuff commonly use ~128 bit integers under the >>hood. Even when scaled 64 bit numbers are sufficient for all stored >>values, intermediate results are often bigger. >> >>The Cobol folks, who, if nothing else, care about handling currency, >>have specified ~64 bit integers (actually the requirement is that the >>user can define types with 18 decimal digits and a sign), and >>intermediates of twice that size since the sixties, and more recent >>standards have doubled those requirements. > >COBOL people often store numeric data as one ASCII/EBCDIC numeric >character in a byte or as two BCD digits in a byte. Thus, there is >quite a flexibility in allocating storage for permanent storage as >well as intermediate results. Which are also integers, although clearly not the binary variety. But almost all Cobol implementations do support binary forms, and will pick 1/2/4/8/16 byte binary fields as needed to store the requested data (IOW, if you define a field as "PIC 9(7) BINARY", you'd usually get a four byte binary, "PIC 9(10) BINARY" would get you an eight byte field*). In any event the size requirements for intermediates are spelled out as part of the arithmetic performance requirements, and are not usually directly visible to the programmer. *And those would get four and six byte "PACKED" and seven and ten byte "DISPLAY" format fields.
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2013-10-03 15:45 +0000 |
| Subject | Re: Small, fast, resource-rich processor (die evil thread, die!!!) |
| Message-ID | <524d8ff2.886360661@news.demon.co.uk> |
| In reply to | #14096 |
On Wed, 02 Oct 2013 17:16:04 -0500, Robert Wessel <robertwessel2@yahoo.com> wrote: >Folks doing monetary stuff commonly use ~128 bit integers under the >hood. Even when scaled 64 bit numbers are sufficient for all stored >values, intermediate results are often bigger. Just to emphasise the point, one of our clients uses 128 bit scaled integers. The application is estimation of construction projects. The difference between the scaled integer solution and the FP solution just for the cost of concrete to cap the piles of the Hong Kong airport was US$ 10,000,000. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-10-03 09:06 -0700 |
| Subject | Re: Small, fast, resource-rich processor (die evil thread, die!!!) |
| Message-ID | <7xmwmqmj9a.fsf@ruckus.brouhaha.com> |
| In reply to | #14120 |
stephenXXX@mpeforth.com (Stephen Pelc) writes: > Just to emphasise the point, one of our clients uses 128 bit scaled > integers. The application is estimation of construction projects. > The difference between the scaled integer solution and the FP > solution just for the cost of concrete to cap the piles of the > Hong Kong airport was US$ 10,000,000. Whaaaa? How are they doing that calculation? Obviously at least one of the two answers is wrong--but which? Have they tried it with something like MPRS and 1000 digit precision?
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-10-03 17:18 +0100 |
| Subject | Re: Small, fast, resource-rich processor (die evil thread, die!!!) |
| Message-ID | <iNg3u.29154$Ra5.8665@fx16.am4> |
| In reply to | #14120 |
On 03/10/13 16:45, Stephen Pelc wrote: > On Wed, 02 Oct 2013 17:16:04 -0500, Robert Wessel > <robertwessel2@yahoo.com> wrote: > >> Folks doing monetary stuff commonly use ~128 bit integers under the >> hood. Even when scaled 64 bit numbers are sufficient for all stored >> values, intermediate results are often bigger. > > Just to emphasise the point, one of our clients uses 128 bit scaled > integers. The application is estimation of construction projects. > The difference between the scaled integer solution and the FP > solution just for the cost of concrete to cap the piles of the > Hong Kong airport was US$ 10,000,000. Did they also do a sensitivity analysis on the assumptions/presumptions on which the estimate was based? Maybe that $10m is lost in the noise!
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2013-10-03 16:51 +0000 |
| Subject | Re: Small, fast, resource-rich processor (die evil thread, die!!!) |
| Message-ID | <524d9f84.890347142@news.demon.co.uk> |
| In reply to | #14120 |
On Thu, 03 Oct 2013 15:45:46 GMT, stephenXXX@mpeforth.com (Stephen Pelc) wrote: >Just to emphasise the point, one of our clients uses 128 bit scaled >integers. The application is estimation of construction projects. >The difference between the scaled integer solution and the FP >solution just for the cost of concrete to cap the piles of the >Hong Kong airport was US$ 10,000,000. Naturally the integer estimate was closer to reality. Do you really think that that my client's competitors are going to explain why/how they got it wrong? This is one of those areas where you should assume the presence of non-disclosure agreements. We just supply tools and consultancy. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-10-03 10:11 -0700 |
| Subject | Re: Small, fast, resource-rich processor (die evil thread, die!!!) |
| Message-ID | <7xtxgyp9cy.fsf@ruckus.brouhaha.com> |
| In reply to | #14123 |
stephenXXX@mpeforth.com (Stephen Pelc) writes: > Naturally the integer estimate was closer to reality. How do you know that? I'd expect it to depend on the numbers and calculations involved. Did you try it with 80 or 128 bit floats?
[toc] | [prev] | [next] | [standalone]
| From | Randy Yates <yates@digitalsignallabs.com> |
|---|---|
| Date | 2013-10-02 09:52 -0400 |
| Subject | Re: Small, fast, resource-rich processor (die evil thread, die!!!) |
| Message-ID | <87a9irdblg.fsf@digitalsignallabs.com> |
| In reply to | #14070 |
David Brown <david@westcontrol.removethisbit.com> writes: > [...] > int_least64_t is not required unless the compiler supports a suitable > type. David, That's not what my copy of the C99 spec states (re: section 7.18.1.2): The following types are required: int_least8_t int_least16_t int_least32_t int_least64_t uint_least8_t uint_least16_t uint_least32_t uint_least64_t All other types of this form are optional. -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2013-10-03 09:35 +0200 |
| Subject | Re: Small, fast, resource-rich processor (die evil thread, die!!!) |
| Message-ID | <guqdnbTQjfqzg9DPnZ2dnUVZ8kGdnZ2d@lyse.net> |
| In reply to | #14086 |
On 02/10/13 15:52, Randy Yates wrote: > David Brown <david@westcontrol.removethisbit.com> writes: >> [...] >> int_least64_t is not required unless the compiler supports a suitable >> type. > > David, > > That's not what my copy of the C99 spec states (re: section 7.18.1.2): > > The following types are required: > int_least8_t > int_least16_t > int_least32_t > int_least64_t > uint_least8_t > uint_least16_t > uint_least32_t > uint_least64_t > All other types of this form are optional. > I thought int_least64_t was only required if the compiler has a "long long" of at least 64 bit, and that you could be C99 compliant without supporting anything bigger than 32-bit. But I'm not going to argue here (that's what comp.lang.c is for!), because I don't think it makes any practical difference.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2013-10-03 03:26 -0500 |
| Subject | Re: Small, fast, resource-rich processor (die evil thread, die!!!) |
| Message-ID | <hgaq491h0btfjgtm0r5sruch2s7vnq98mg@4ax.com> |
| In reply to | #14105 |
On Thu, 03 Oct 2013 09:35:09 +0200, David Brown <david@westcontrol.removethisbit.com> wrote: >On 02/10/13 15:52, Randy Yates wrote: >> David Brown <david@westcontrol.removethisbit.com> writes: >>> [...] >>> int_least64_t is not required unless the compiler supports a suitable >>> type. >> >> David, >> >> That's not what my copy of the C99 spec states (re: section 7.18.1.2): >> >> The following types are required: >> int_least8_t >> int_least16_t >> int_least32_t >> int_least64_t >> uint_least8_t >> uint_least16_t >> uint_least32_t >> uint_least64_t >> All other types of this form are optional. >> > >I thought int_least64_t was only required if the compiler has a "long >long" of at least 64 bit, and that you could be C99 compliant without >supporting anything bigger than 32-bit. But I'm not going to argue here >(that's what comp.lang.c is for!), because I don't think it makes any >practical difference. No, C99 requires a long long of at least 64 bits.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2013-10-03 13:27 +0200 |
| Subject | Re: Small, fast, resource-rich processor (die evil thread, die!!!) |
| Message-ID | <ubednf4lab8hydDPnZ2dnUVZ8uCdnZ2d@lyse.net> |
| In reply to | #14107 |
On 03/10/13 10:26, Robert Wessel wrote: > On Thu, 03 Oct 2013 09:35:09 +0200, David Brown > <david@westcontrol.removethisbit.com> wrote: > >> On 02/10/13 15:52, Randy Yates wrote: >>> David Brown <david@westcontrol.removethisbit.com> writes: >>>> [...] >>>> int_least64_t is not required unless the compiler supports a suitable >>>> type. >>> >>> David, >>> >>> That's not what my copy of the C99 spec states (re: section 7.18.1.2): >>> >>> The following types are required: >>> int_least8_t >>> int_least16_t >>> int_least32_t >>> int_least64_t >>> uint_least8_t >>> uint_least16_t >>> uint_least32_t >>> uint_least64_t >>> All other types of this form are optional. >>> >> >> I thought int_least64_t was only required if the compiler has a "long >> long" of at least 64 bit, and that you could be C99 compliant without >> supporting anything bigger than 32-bit. But I'm not going to argue here >> (that's what comp.lang.c is for!), because I don't think it makes any >> practical difference. > > > No, C99 requires a long long of at least 64 bits. > Fair enough. Thanks for the correction.
[toc] | [prev] | [next] | [standalone]
Page 7 of 22 — ← Prev page 1 … 5 6 [7] 8 9 … 22 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web