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 4 of 22 — ← Prev page 1 2 3 [4] 5 6 … 22 Next page →
| From | dp <dp@tgi-sci.com> |
|---|---|
| Date | 2013-09-24 02:15 -0700 |
| Message-ID | <9c0f41cf-3c0a-42e2-b458-47ca9e8690e7@googlegroups.com> |
| In reply to | #13845 |
On Tuesday, September 24, 2013 11:13:48 AM UTC+3, Don Y wrote: > ... > > I would have thought you had finished that and were working on the > Model 4 by now!! ;-) Uhm, so would have I but I am not short of distractions so it took longer. It has been stable for quite a while now but I am not quite done with all the commands which use the longnamed directories. Many of them just work but there are surprises and I have to dig. E.g. now I am fixing the "md" command, its buffer for the text to go into the . and .. files is too short. > (Have you thought about this "portability" issue regarding your > naming implementation?) I think I got it right (though only time will tell). I made the names stored upper case only, with the case info (bit per byte) separately after that. Then since the names can be up to 254 bytes long but can also be just 1 byte, I made the entry length variable. If a call searches for a file it will compare 32-bit wise only upper case text (so the search is case independent); if I want to implement case dependent search all I have to do is let the compare go on for another subsequent longwords (which contain the case data). Now I have that "default" file name to pass to the highest level "open" call (called fetch$, now I have a newer one fetchx$). If the name (passed as text) is null, the default name is taken; if the name has no suffix, the suffix from the default name is taken; and if the name text carries only a suffix (suffix being what is past the last "." character in the name) the default name but not suffix is taken. I made a call which now will insert any part of a name - text AND case info - into any other name, opening space for both the text and the case info... This took me a while (with all the distractions, normally it would have been much much faster). But hey, I have it working and usable... well, almost usable. I mean I can copy, delete etc. files but by no means all applications are happy with the longnamed thing yet... Uh, how come the moaning paragraph got by far the longest :-) Dimiter
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-09-24 15:56 -0700 |
| Message-ID | <l1t5b0$3l4$1@speranza.aioe.org> |
| In reply to | #13850 |
Hi Dimiter, On 9/24/2013 2:15 AM, dp wrote: > On Tuesday, September 24, 2013 11:13:48 AM UTC+3, Don Y wrote: >> ... >> >> I would have thought you had finished that and were working on the >> Model 4 by now!! ;-) > > Uhm, so would have I but I am not short of distractions so it took > longer. It has been stable for quite a while now but I am not quite done > with all the commands which use the longnamed directories. Many > of them just work but there are surprises and I have to dig. E.g. > now I am fixing the "md" command, its buffer for the text to go > into the . and .. files is too short. Stop goofing off and get back to work! I know you're enjoying the few remaining days above FREEZING, but... :> [Check your mail -- "didi" -- I took this offlist] --don
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2013-09-23 00:46 -0500 |
| Message-ID | <8alv391u9gqree3ul4sh02hu4dm5o0c52m@4ax.com> |
| In reply to | #13802 |
On Sun, 22 Sep 2013 12:21:47 -0700, Don Y <this@isnotme.com> wrote: >Hi Tom, > >On 9/22/2013 12:08 PM, Tom Gardner wrote: >> On 22/09/13 18:56, Don Y wrote: > >>> I wouldn't describe it as "lightly and amusingly written" by a >>> long shot! But, if you've ever written a floating point library >>> and.or floating point algorithms that had to work in ALL cases, >>> it is an excellent discussion of many of the "why's" and the >>> "issues to be wary of". >>> >>> Well worth the time to read, IMnsHO. And, *reread* if you >>> actually need to *understand* these issues! >> >> Yes, that is useful. I'm sure I came across the first half >> many years ago, but it might be buried in my paper library. > >I've scanned most of my paper documents out of necessity. >Just take up too damned much *space*! Unfortunately, they >aren't searchable in that state -- but, they weren't searchable >as paper, either! :> While not perfect, you should be able to OCR the scanned documents, and convert them to PDFs. These days many scanners will do that by default.
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-09-22 23:18 -0700 |
| Message-ID | <l1omgi$muu$1@speranza.aioe.org> |
| In reply to | #13810 |
Hi Robert, On 9/22/2013 10:46 PM, Robert Wessel wrote: > On Sun, 22 Sep 2013 12:21:47 -0700, Don Y <this@isnotme.com> wrote: >> I've scanned most of my paper documents out of necessity. >> Just take up too damned much *space*! Unfortunately, they >> aren't searchable in that state -- but, they weren't searchable >> as paper, either! :> > > While not perfect, you should be able to OCR the scanned documents, > and convert them to PDFs. These days many scanners will do that by > default. I've been *really* disappointed with the results! You have to double-check everything to ensure nothing has been "dropped". I've seen programs that would *skip* large blocks of text. Or, get confused over images with callouts, complex formats, etc. So, I've opted to just preserve an *image* of the page in the hope that, someday, tools get smarter (or, I find myself with gobs and gobs of time to proofread tens of thousands of scanned pages :-/ ) Disk space is cheap -- $0.10/GB? It's not worth the downside risk.
[toc] | [prev] | [next] | [standalone]
| From | Arlet Ottens <usenet+5@c-scape.nl> |
|---|---|
| Date | 2013-09-23 09:00 +0200 |
| Message-ID | <523fe6fb$0$15943$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #13811 |
On 09/23/2013 08:18 AM, Don Y wrote: > Hi Robert, > > On 9/22/2013 10:46 PM, Robert Wessel wrote: >> On Sun, 22 Sep 2013 12:21:47 -0700, Don Y <this@isnotme.com> wrote: > >>> I've scanned most of my paper documents out of necessity. >>> Just take up too damned much *space*! Unfortunately, they >>> aren't searchable in that state -- but, they weren't searchable >>> as paper, either! :> >> >> While not perfect, you should be able to OCR the scanned documents, >> and convert them to PDFs. These days many scanners will do that by >> default. > > I've been *really* disappointed with the results! You have to > double-check everything to ensure nothing has been "dropped". > > I've seen programs that would *skip* large blocks of text. Or, > get confused over images with callouts, complex formats, etc. > > So, I've opted to just preserve an *image* of the page in the > hope that, someday, tools get smarter (or, I find myself with > gobs and gobs of time to proofread tens of thousands of scanned > pages :-/ ) You could keep the original, but also make an OCR version that you could search.
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-09-23 00:18 -0700 |
| Message-ID | <l1oq0b$vrf$1@speranza.aioe.org> |
| In reply to | #13813 |
Hi Arlet, On 9/23/2013 12:00 AM, Arlet Ottens wrote: > On 09/23/2013 08:18 AM, Don Y wrote: >> I've been *really* disappointed with the results! You have to >> double-check everything to ensure nothing has been "dropped". >> >> I've seen programs that would *skip* large blocks of text. Or, >> get confused over images with callouts, complex formats, etc. >> >> So, I've opted to just preserve an *image* of the page in the >> hope that, someday, tools get smarter (or, I find myself with >> gobs and gobs of time to proofread tens of thousands of scanned >> pages :-/ ) > > You could keep the original, but also make an OCR version that you could > search. Keeping the original *paper* copy is out of the question. I had just *way* too much paper! I could keep *images* of each page and, separately, OCR'd versions. But, I'm still forced to "proof" all those OCR'd pages -- otherwise, what's the advantage of having them (if you have no idea how good the versions are). Easier to hold onto the scanned images (which only require the scanner software to know how to detect black/white/grey/color/etc.) and, later, run those through a piece of software that lets you view raw image and OCR'd image side by side). [Some scanners preserve the TIFF *and* "text" in the same file but it doesn't eliminate the need to proof it all] Moral of story: get electronic versions of as many documents as possible!
[toc] | [prev] | [next] | [standalone]
| From | Arlet Ottens <usenet+5@c-scape.nl> |
|---|---|
| Date | 2013-09-23 09:27 +0200 |
| Message-ID | <523fed7b$0$15978$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #13815 |
On 09/23/2013 09:18 AM, Don Y wrote: > Hi Arlet, > > On 9/23/2013 12:00 AM, Arlet Ottens wrote: >> On 09/23/2013 08:18 AM, Don Y wrote: > >>> I've been *really* disappointed with the results! You have to >>> double-check everything to ensure nothing has been "dropped". >>> >>> I've seen programs that would *skip* large blocks of text. Or, >>> get confused over images with callouts, complex formats, etc. >>> >>> So, I've opted to just preserve an *image* of the page in the >>> hope that, someday, tools get smarter (or, I find myself with >>> gobs and gobs of time to proofread tens of thousands of scanned >>> pages :-/ ) >> >> You could keep the original, but also make an OCR version that you could >> search. > > Keeping the original *paper* copy is out of the question. > I had just *way* too much paper! > > I could keep *images* of each page and, separately, OCR'd versions. > But, I'm still forced to "proof" all those OCR'd pages -- otherwise, > what's the advantage of having them (if you have no idea how > good the versions are). That's what I meant. Keep the original scanned images, and a separate OCR version. You don't have to proofread the OCR. 9 out of 10 hits with a search is better than nothing at all.
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-09-23 06:56 -0700 |
| Message-ID | <l1ph9l$39f$1@speranza.aioe.org> |
| In reply to | #13817 |
Hi Arlet, On 9/23/2013 12:27 AM, Arlet Ottens wrote: > On 09/23/2013 09:18 AM, Don Y wrote: >>> You could keep the original, but also make an OCR version that you could >>> search. >> >> Keeping the original *paper* copy is out of the question. >> I had just *way* too much paper! >> >> I could keep *images* of each page and, separately, OCR'd versions. >> But, I'm still forced to "proof" all those OCR'd pages -- otherwise, >> what's the advantage of having them (if you have no idea how >> good the versions are). > > That's what I meant. Keep the original scanned images, and a separate > OCR version. At least one of the tools here gives me that capability (I can't recall which -- "searchable TIFF's") > You don't have to proofread the OCR. 9 out of 10 hits with a search is > better than nothing at all. It gives you a false sense of security. Ages ago, I "scanned" all my bank statements, credit card statements, etc. -- excellent way to get rid of "useless" paper! :> Come tax time, I figured I could "cheat" and just pull the "data" from those scanned copies (instead of transcribing detail records by hand). That was my first "disappointment" with COTS OCR. "Why can't I find a record of this check being deposited?" The "save the image, only" strategy grew out of that experience. It satisfies my primary goal: getting rid of paper. It just doesn't give me much *more* than that!
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2013-09-23 10:50 -0500 |
| Message-ID | <mtn049t1q52360send0a529ggr17df17lm@4ax.com> |
| In reply to | #13811 |
On Sun, 22 Sep 2013 23:18:53 -0700, Don Y <this@isnotme.com> wrote: >Hi Robert, > >On 9/22/2013 10:46 PM, Robert Wessel wrote: >> On Sun, 22 Sep 2013 12:21:47 -0700, Don Y <this@isnotme.com> wrote: > >>> I've scanned most of my paper documents out of necessity. >>> Just take up too damned much *space*! Unfortunately, they >>> aren't searchable in that state -- but, they weren't searchable >>> as paper, either! :> >> >> While not perfect, you should be able to OCR the scanned documents, >> and convert them to PDFs. These days many scanners will do that by >> default. > >I've been *really* disappointed with the results! You have to >double-check everything to ensure nothing has been "dropped". > >I've seen programs that would *skip* large blocks of text. Or, >get confused over images with callouts, complex formats, etc. > >So, I've opted to just preserve an *image* of the page in the >hope that, someday, tools get smarter (or, I find myself with >gobs and gobs of time to proofread tens of thousands of scanned >pages :-/ ) > >Disk space is cheap -- $0.10/GB? It's not worth the downside >risk. If you do it right, the OCR'd text is just stored as a transparent layer over the image layer in the PDF, so you have both in the same file. And you can always touch up the OCR layer with your favorite PDF tools (and still leave the image layer alone). While not perfect, you can search much of the document - which is better than none at all. FWIW, many of the manuals on bitsavers are stored that way.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-09-28 13:04 -0700 |
| Message-ID | <7xd2nsvhl3.fsf@ruckus.brouhaha.com> |
| In reply to | #13774 |
Tom Gardner <spamjunk@blueyonder.co.uk> writes: > http://people.ds.cam.ac.uk/nmm1/Arithmetic/Notes/notes.pdf > http://people.ds.cam.ac.uk/nmm1/Arithmetic/index.html I hadn't seen those before. They are nice, thanks.
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2013-09-20 15:41 +0300 |
| Message-ID | <e8go39hj1ac6is5115qecc8n7jq1fcppq8@4ax.com> |
| In reply to | #13768 |
On Thu, 19 Sep 2013 22:22:47 -0700, Paul Rubin <no.email@nospam.invalid> 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. The denormal question only exists due to using hidden bit normalization in a Radix-2 system. Since a Radix-8 or Radix-16 floating representation does not have that hidden bit issue, were denormals ever a problem with these machines ?
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2013-09-20 14:33 +0000 |
| Message-ID | <l1hmbq$9vh$1@speranza.aioe.org> |
| In reply to | #13777 |
In comp.dsp upsidedown@downunder.com wrote: (snip, previously I wrote) >>> I suppose, but I still think that denormals were a bad idea. (snip) > The denormal question only exists due to using hidden bit > normalization in a Radix-2 system. Since a Radix-8 or Radix-16 > floating representation does not have that hidden bit issue, were > denormals ever a problem with these machines ? For S/360 style (still available with z/Architecture) radix 16, they would only come from add unnormalized, and subtract unnormalized. For other instructions, on post normalization underflow they either generate zero or wrap the exponent and interrupt, depending on a mask bit. For S/360 style prenormalization for add/subtract, it is done based on the exponent value and not the bits. The Fortran AINT function (truncate to integer, but keep in floating point form) you just add X'47000000' that is, 0*16**7. During prenormalization, the appropriate bits will be shifted out, zero added, and then post normalized. Note also how easy it is to read S/360 style floating point values in a hex dump. The first (leftmost) two digits are sign and seven bit biased exponent, then six or 14 hex digits of fraction in base 16. So, yes, if you stored a denormal it would work right in add/subtract. I am not sure what multiply and divide would do with one. -- glen
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2013-09-20 15:55 +0300 |
| Message-ID | <dtgo39dhjrcjvgjpi5sse6b1kosip98f65@4ax.com> |
| In reply to | #13768 |
On Thu, 19 Sep 2013 22:22:47 -0700, Paul Rubin <no.email@nospam.invalid> wrote: >> 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. Sounds like sweeping the problem under the carpet :-). If you really get infinity at some intermediate stage, this really looks that the algorithm was faulty from the beginning or not valid for the range of arguments. Relying on 1/Inf=0 may hide much more fundamental problems.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-09-20 08:42 -0700 |
| Message-ID | <7xd2o3biu0.fsf@ruckus.brouhaha.com> |
| In reply to | #13778 |
upsidedown@downunder.com writes: > If you really get infinity at some intermediate stage, this really > looks that the algorithm was faulty from the beginning or not valid > for the range of arguments. Relying on 1/Inf=0 may hide much more > fundamental problems. The function may have had a pole at some point where you ran it. In this case the algorithm is faulty if the floating point architecture doesn't handle infinity properly. IEEE-754 was designed to make the algorithm non-faulty. That said, there are a lot of sharp corners to the behavior so you're going to write a non-buggy algorithm that makes use of it, it helps to really know what you're doing with the intricacies of the standard.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2013-09-23 09:06 +0200 |
| Message-ID | <pNGdnbA-G_vjdaLPnZ2dnUVZ7t2dnZ2d@lyse.net> |
| In reply to | #13782 |
On 20/09/13 17:42, Paul Rubin wrote:
> upsidedown@downunder.com writes:
>> If you really get infinity at some intermediate stage, this really
>> looks that the algorithm was faulty from the beginning or not valid
>> for the range of arguments. Relying on 1/Inf=0 may hide much more
>> fundamental problems.
>
> The function may have had a pole at some point where you ran it. In
> this case the algorithm is faulty if the floating point architecture
> doesn't handle infinity properly. IEEE-754 was designed to make the
> algorithm non-faulty. That said, there are a lot of sharp corners to
> the behavior so you're going to write a non-buggy algorithm that makes
> use of it, it helps to really know what you're doing with the
> intricacies of the standard.
>
IEEE-754 infinities and NaNs were /not/ designed to make such an
algorithm "non-faulty". They just allow the code to continue without a
halt or a trap, and see later that the function was called with an
invalid input. (It is likely to be the calling code that is wrong here,
rather than the called algorithm - except if the called function is
badly specified.)
If you have a function f() with a pole at X, and you write "y = f(X)",
then the answer is /always wrong/. It doesn't matter if the function
returns 0, 27, +inf, or formats your hard drive - it is still wrong.
All an "inf" or "NaN" can tell you is that you have done something wrong.
Of course, this can be useful in some circumstances - but it is not
really different than setting errno, or returning a struct { bool valid;
double result; }, or returning some other kind of signal value.
There are times when you can do mathematical reasoning with functions
even at its poles (such as looking at limits close to the poles). But
IEEE-754 "inf" does not let you do that - you don't have nearly enough
information to do anything sensible except see that you have had an error.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-09-28 12:07 -0700 |
| Message-ID | <7xhad4rci8.fsf@ruckus.brouhaha.com> |
| In reply to | #13814 |
David Brown <david@westcontrol.removethisbit.com> writes: > If you have a function f() with a pole at X, and you write "y = f(X)", > then the answer is /always wrong/. It doesn't matter if the function > returns 0, 27, +inf, or formats your hard drive - it is still wrong. If the final answer is Inf then it's invalid, but you might have an intermediate result be Inf, and IEEE arithmetic says what's supposed to happen then (e.g. 1/Inf = 0). Kahan has given some examples of calculations designed to make use of this property. I remember a trick question from math class: where are the singularities of the cotangent function? Obvious answer: cot x = cos x / sin x, so it has poles at the roots of sin x: 0, 180 degrees, etc. Trick answer: cot x is actually defined as 1/tan x, so it also has removable singularities at the places where cos x = 0. Inf in IEEE arithmetic can let you treat the function as continuous at points like that, which you might want to do. > All an "inf" or "NaN" can tell you is that you have done something wrong. Not at all, Inf is valid in IEEE arithmetic as described above, and NaN just means you did an invalid calculation, maybe on purpose, in which case it's not "wrong". For example, think of a general purpose numerical root-finding algorithm which you give an arbitrary function f and an initial guess x. It starts making other guesses near x, and if it gets a NaN, it says "ok that guess was outside the function domain, I'll make the next guess somewhere else". HP calculators of the 1990's had a rootfinder that did that, using IEEE 854 arithmetic.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@removethis.hesbynett.no> |
|---|---|
| Date | 2013-09-29 22:15 +0200 |
| Message-ID | <7sSdnXfnStnMF9XPnZ2dnUVZ8iadnZ2d@lyse.net> |
| In reply to | #13946 |
On 28/09/13 21:07, Paul Rubin wrote: > David Brown <david@westcontrol.removethisbit.com> writes: >> If you have a function f() with a pole at X, and you write "y = f(X)", >> then the answer is /always wrong/. It doesn't matter if the function >> returns 0, 27, +inf, or formats your hard drive - it is still wrong. > > If the final answer is Inf then it's invalid, but you might have an > intermediate result be Inf, and IEEE arithmetic says what's supposed to > happen then (e.g. 1/Inf = 0). Kahan has given some examples of > calculations designed to make use of this property. > > I remember a trick question from math class: where are the singularities > of the cotangent function? Obvious answer: cot x = cos x / sin x, so it > has poles at the roots of sin x: 0, 180 degrees, etc. Trick answer: cot x > is actually defined as 1/tan x, so it also has removable singularities > at the places where cos x = 0. Inf in IEEE arithmetic can let you > treat the function as continuous at points like that, which you might > want to do. You do not get /workable/ removable singularities in calculations using simple floating point numerical approximations, such as IEEE describes. It may be possible to find particular examples when things happen to work out correctly, but that's just luck. Write your code /correctly/ within the limits of the numerical model you are using, or use a different model that provides enough detail and flexibility to be able to correctly model the types of numbers or sequences you want. As for cot, you can define it as cos/sin and there are no singularities of any sort at cos x = 0. Your maths teacher just defined it as 1/tan in order to illustrate that some functions need more careful definitions in order to work as you first think. And how it is defined bears no relationship to how it is calculated in a numerical approximation - and it is the approximation algorithm that is key when you want to get useful results. If you think you can just write "1/tan(x)" and rely on the "magic" of IEEE's infinities to make things work at cos x = 0, you are kidding yourself. > >> All an "inf" or "NaN" can tell you is that you have done something wrong. > > Not at all, Inf is valid in IEEE arithmetic as described above, and NaN > just means you did an invalid calculation, maybe on purpose, in which > case it's not "wrong". For example, think of a general purpose > numerical root-finding algorithm which you give an arbitrary function f > and an initial guess x. It starts making other guesses near x, and if > it gets a NaN, it says "ok that guess was outside the function domain, > I'll make the next guess somewhere else". HP calculators of the 1990's > had a rootfinder that did that, using IEEE 854 arithmetic. > Such "rootfinder" algorithms are the only reasonable justification I have seen for NaN's. And yes, all they tell you is precisely "you've done something wrong". For rootfinders, such information can be useful - since you have (presumably) already tested the correctness of the test function when you are within the valid input domain, they then tell you you are outside that domain.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-10-01 00:33 -0700 |
| Message-ID | <7xy56de985.fsf@ruckus.brouhaha.com> |
| In reply to | #13976 |
David Brown <david.brown@removethis.hesbynett.no> writes: > If you think you can just write "1/tan(x)" and rely on the "magic" of > IEEE's infinities to make things work at cos x = 0, you are kidding > yourself. It's not magic, it's just the properties of the arithmetic. It's just like if the specification of some CPU architecture says a certain combination of instructions will give result X, it's perfectly ok to use that combination if X is what you want. This is especially true if the architects have come out and said they designed the instruction set with that particular effect in mind, i.e. it's not a quirk or anomaly. Obviously if you want something different from X, you should not use that combination of instructions. And whether you want X depends on the very low level details of your application. Obviously you can't just close your eyes and ignore singularities because you think the machine arithmetic will take care of them. It is, however, ok to plan around them and arrange your code for the specific function domain, so that the right thing happens if you hit upon one. If you are saying X (in this case the behavior of IEEE Infinity) is never a reasonable thing to want to rely on in the first place, you're going to have to take that up with the designers rather than with me. Since they were world-renowned numerical analysts with tons of experience implementing numerical algorithms that dealt with these issues, I am most comfortable assuming that they knew what they were doing when they designed the standard the way they did.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2013-10-01 10:25 +0200 |
| Message-ID | <EL2dnW65XtGeGtfPnZ2dnUVZ7t-dnZ2d@lyse.net> |
| In reply to | #14033 |
On 01/10/13 09:33, Paul Rubin wrote: > David Brown <david.brown@removethis.hesbynett.no> writes: >> If you think you can just write "1/tan(x)" and rely on the "magic" of >> IEEE's infinities to make things work at cos x = 0, you are kidding >> yourself. > > It's not magic, it's just the properties of the arithmetic. It's just > like if the specification of some CPU architecture says a certain > combination of instructions will give result X, it's perfectly ok to use > that combination if X is what you want. This is especially true if the > architects have come out and said they designed the instruction set with > that particular effect in mind, i.e. it's not a quirk or anomaly. > Obviously if you want something different from X, you should not use > that combination of instructions. And whether you want X depends on the > very low level details of your application. Obviously you can't just > close your eyes and ignore singularities because you think the machine > arithmetic will take care of them. It is, however, ok to plan around > them and arrange your code for the specific function domain, so that the > right thing happens if you hit upon one. > > If you are saying X (in this case the behavior of IEEE Infinity) is > never a reasonable thing to want to rely on in the first place, you're > going to have to take that up with the designers rather than with me. > Since they were world-renowned numerical analysts with tons of > experience implementing numerical algorithms that dealt with these > issues, I am most comfortable assuming that they knew what they were > doing when they designed the standard the way they did. > I'm sure the guys at IEEE were very smart. But it was in a different time, for different hardware, different software and different types of applications. They could have done the best possible job at the time - but still it is absurd to suggest that the choices made then are the ideal choices for the type of hardware, software and applications we have now - especially in the embedded world. While the mathematics hasn't changed, other things have. There will be HPC folk that feel 64-bit IEEE is far too limited in range and resolution. Microcontroller producers feel full IEEE hardware implementations are too big, complex and power-hungry. Toolchain vendors feel software library implementations of full IEEE are too slow and bulky, and they restrict the optimiser too much. Embedded developers feel they don't care about irrelevant details of features they will never use, but they do care about code speed and size. All I am saying is pick the right tool for the job. When you want simple floating point, the basic IEEE formats are quite a reasonable balance of range and precision - but most of the details beyond that are unnecessary costs with very little real-life benefits.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-10-03 10:26 -0700 |
| Message-ID | <7xpprmp8oc.fsf@ruckus.brouhaha.com> |
| In reply to | #14044 |
David Brown <david@westcontrol.removethisbit.com> writes: > I'm sure the guys at IEEE were very smart. But it was in a different > time, for different hardware, different software and different types of > applications. The driving implementation at the time was the Intel 8087. Not too much different from embedded processors of today. The supercomputer guys mostly just looked on with amusement. > There will be HPC folk that feel 64-bit IEEE is far too limited in range > and resolution. That's why 80 and 128 bit were invented. > Microcontroller producers feel full IEEE hardware > implementations are too big, complex and power-hungry. I'd like to see actual numbers about that. What I seem to be hearing is that the world's top numerics experts spend years agreeing that the right way to solve this problem is to do X, Y, and Z; and then some hardware guy or PHB at a microprocessor vendor says "well I'm smarter than all those experts, so I think X and Y sound fine but I'm going to leave out Z and save 5 cents on transistors". If that's what's going on, it's not impressive. > Toolchain vendors feel software library implementations of full IEEE > are too slow and bulky, and they restrict the optimiser too much. This is fine, they can have an option like --fast-math for users who want it, though they should also have --ieee-math, preferably as the default. It's less of a problem than the hardware vendor who removes following the standard as even as a possibility for the user. > Embedded developers feel they don't care about irrelevant details of > features they will never use, but they do care about code speed and > size. I wonder how often they're actually qualified to make such decisions. One thing about standards is they're codifications of best practices. If someone builds a critical application and something goes wrong because they decided to ignore a standard, they're potentially in a world of hurt.
[toc] | [prev] | [next] | [standalone]
Page 4 of 22 — ← Prev page 1 2 3 [4] 5 6 … 22 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web