Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #25896 > unrolled thread
| Started by | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| First post | 2017-03-05 16:03 -0700 |
| Last post | 2017-03-11 14:21 -0700 |
| Articles | 20 on this page of 202 — 22 participants |
Back to article view | Back to comp.arch.embedded
Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-05 16:03 -0700
Re: Language feature selection Wouter van Ooijen <wouter@voti.nl> - 2017-03-06 08:04 +0100
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-07 10:31 -0700
Re: Language feature selection Wouter van Ooijen <wouter@voti.nl> - 2017-03-07 23:29 +0100
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-08 02:49 -0700
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-08 13:18 +0100
Re: Language feature selection Wouter van Ooijen <wouter@voti.nl> - 2017-03-08 16:58 +0100
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-08 10:35 -0700
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-08 22:07 +0100
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-06 08:40 +0100
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-06 10:31 +0100
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-06 08:47 -0700
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-06 21:33 +0100
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-06 13:44 -0700
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-07 12:24 +0100
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-07 09:34 -0700
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-08 10:14 +0100
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-08 10:37 -0700
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-08 22:09 +0100
Re: Language feature selection Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2017-03-06 22:50 +0200
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-07 12:31 +0100
Re: Language feature selection rickman <gnuarm@gmail.com> - 2017-03-07 14:45 -0500
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-06 08:39 +0000
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-06 08:39 -0700
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-06 17:27 +0000
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-06 13:30 -0700
Re: Language feature selection Dimiter_Popoff <dp@tgi-sci.com> - 2017-03-06 11:11 +0200
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-06 13:38 -0700
Re: Language feature selection Dimiter_Popoff <dp@tgi-sci.com> - 2017-03-07 12:18 +0200
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-07 10:28 -0700
Re: Language feature selection George Neuner <gneuner2@comcast.net> - 2017-03-06 13:33 -0500
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-06 13:36 -0700
Re: Language feature selection George Neuner <gneuner2@comcast.net> - 2017-03-06 22:15 -0500
Re: Language feature selection George Neuner <gneuner2@comcast.net> - 2017-03-06 22:22 -0500
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-07 00:27 -0700
Re: Language feature selection George Neuner <gneuner2@comcast.net> - 2017-03-08 12:20 -0500
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-08 11:23 -0700
Re: Language feature selection George Neuner <gneuner2@comcast.net> - 2017-03-10 13:43 -0500
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-10 16:49 -0700
Re: Language feature selection George Neuner <gneuner2@comcast.net> - 2017-03-11 04:17 -0500
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-11 12:33 -0700
Re: Language feature selection George Neuner <gneuner2@comcast.net> - 2017-03-12 18:08 -0400
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-12 17:25 -0700
Re: Language feature selection George Neuner <gneuner2@comcast.net> - 2017-03-15 21:05 -0400
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-16 17:23 -0700
Re: Language feature selection George Neuner <gneuner2@comcast.net> - 2017-03-17 23:59 -0400
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-17 23:25 -0700
Re: Language feature selection Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2017-03-18 12:05 +0200
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-18 04:04 -0700
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-18 04:39 -0700
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-18 03:55 -0700
Re: Language feature selection upsidedown@downunder.com - 2017-03-18 16:00 +0200
Re: Language feature selection Les Cargill <lcargill99@comcast.com> - 2017-03-11 16:35 -0600
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-11 15:39 -0700
Re: Language feature selection Grant Edwards <invalid@invalid.invalid> - 2017-03-06 18:59 +0000
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-06 12:36 -0700
Re: Language feature selection Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2017-03-07 19:02 +0000
Re: Language feature selection Grant Edwards <invalid@invalid.invalid> - 2017-03-07 19:18 +0000
Re: Language feature selection Grant Edwards <invalid@invalid.invalid> - 2017-03-07 19:19 +0000
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-07 12:38 -0700
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-07 22:10 -0600
Re: Language feature selection Paul Rubin <no.email@nospam.invalid> - 2017-03-07 20:35 -0800
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-08 20:43 -0600
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-07 23:48 -0700
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-08 20:48 -0600
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-08 21:15 -0700
Re: Language feature selection Paul Rubin <no.email@nospam.invalid> - 2017-03-09 01:33 -0800
Re: Language feature selection Grant Edwards <invalid@invalid.invalid> - 2017-03-09 14:47 +0000
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-09 16:40 +0100
Re: Language feature selection Grant Edwards <invalid@invalid.invalid> - 2017-03-09 16:15 +0000
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-09 22:04 +0100
Re: Language feature selection John Devereux <john@devereux.me.uk> - 2017-03-10 07:46 +0000
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-10 13:21 +0100
Re: Language feature selection Les Cargill <lcargill99@comcast.com> - 2017-03-09 17:57 -0600
Re: Language feature selection Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2017-03-10 11:16 +0200
Re: Language feature selection Jacob Sparre Andersen <jacob@jacob-sparre.dk> - 2017-03-10 20:39 +0100
Re: Language feature selection Paul Rubin <no.email@nospam.invalid> - 2017-03-10 13:32 -0800
Re: Language feature selection Niklas Holsti <niklas.holsti@tidorum.invalid> - 2017-03-11 14:58 +0200
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-13 13:02 +0100
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-08 10:46 +0100
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-08 20:33 -0600
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-09 11:08 +0100
Re: Language feature selection Britt <britt.snodgrass@gmail.com> - 2017-03-09 07:04 -0800
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-09 16:36 +0100
Re: Language feature selection Grant Edwards <invalid@invalid.invalid> - 2017-03-09 16:11 +0000
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-09 12:06 -0600
Re: Language feature selection Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2017-03-09 19:26 +0100
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-09 22:08 +0100
Re: Language feature selection Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2017-03-09 19:04 +0000
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-09 15:34 -0700
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-09 15:40 -0700
Re: Language feature selection Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2017-03-10 14:19 +0000
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-10 11:10 -0700
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-10 11:49 -0700
Re: Language feature selection Les Cargill <lcargill99@comcast.com> - 2017-03-09 18:00 -0600
Re: Language feature selection Les Cargill <lcargill99@comcast.com> - 2017-03-09 17:54 -0600
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-09 18:54 -0600
Re: Language feature selection Grant Edwards <invalid@invalid.invalid> - 2017-03-10 04:07 +0000
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-10 08:07 -0600
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-10 13:59 +0100
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-10 08:17 +0000
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-10 11:24 -0700
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-10 19:09 +0000
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-10 12:33 -0700
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-10 23:25 +0000
Re: Language feature selection George Neuner <gneuner2@comcast.net> - 2017-03-10 20:22 -0500
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-11 01:32 +0000
Re: Language feature selection Paul Rubin <no.email@nospam.invalid> - 2017-03-10 18:16 -0800
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-11 09:59 +0000
Re: Language feature selection Paul Rubin <no.email@nospam.invalid> - 2017-03-11 02:23 -0800
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-11 11:13 +0000
Re: Language feature selection George Neuner <gneuner2@comcast.net> - 2017-03-11 14:28 -0500
Re: Language feature selection George Neuner <gneuner2@comcast.net> - 2017-03-11 17:20 -0500
Re: Language feature selection George Neuner <gneuner2@comcast.net> - 2017-03-12 16:26 -0400
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-12 21:46 +0100
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-12 23:15 +0000
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-13 14:14 -0400
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-13 18:48 +0000
Re: Language feature selection "Brian G. Lucas" <bagel99@gmail.com> - 2017-03-13 15:17 -0500
Re: Language feature selection Niklas Holsti <niklas.holsti@tidorum.invalid> - 2017-03-13 23:17 +0200
Re: Language feature selection "Brian G. Lucas" <bagel99@gmail.com> - 2017-03-13 17:27 -0500
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-13 17:10 -0700
Re: Language feature selection Niklas Holsti <niklas.holsti@tidorum.invalid> - 2017-03-14 10:11 +0200
Re: Language feature selection "Brian G. Lucas" <bagel99@gmail.com> - 2017-03-14 12:23 -0500
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-14 13:27 +0100
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-14 13:30 -0400
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-14 22:03 +0100
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-14 17:24 -0400
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-11 07:19 -0600
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-11 19:43 +0000
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-12 09:28 -0600
Re: Language feature selection George Neuner <gneuner2@comcast.net> - 2017-03-12 15:15 -0400
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-12 19:38 +0000
Re: Language feature selection Paul Rubin <no.email@nospam.invalid> - 2017-03-10 18:08 -0800
Re: Language feature selection George Neuner <gneuner2@comcast.net> - 2017-03-11 04:22 -0500
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-11 10:02 +0000
Re: Language feature selection Paul Rubin <no.email@nospam.invalid> - 2017-03-11 02:22 -0800
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-11 11:07 +0000
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-10 14:30 -0600
Re: Language feature selection Paul Rubin <no.email@nospam.invalid> - 2017-03-10 13:37 -0800
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-10 16:30 -0600
Re: Language feature selection Paul Rubin <no.email@nospam.invalid> - 2017-03-10 18:14 -0800
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-11 07:46 -0600
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-11 12:53 -0700
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-12 09:45 -0600
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-12 11:56 -0700
Re: Language feature selection Dimiter_Popoff <dp@tgi-sci.com> - 2017-03-12 21:05 +0200
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-12 14:40 -0700
Re: Language feature selection Dimiter_Popoff <dp@tgi-sci.com> - 2017-03-13 00:36 +0200
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-12 17:00 -0700
Re: Language feature selection Robert Wessel <robertwessel2@yahoo.com> - 2017-03-13 16:50 -0500
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-13 17:08 -0700
Re: Language feature selection Robert Wessel <robertwessel2@yahoo.com> - 2017-03-13 20:51 -0500
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-13 20:31 -0700
Re: Language feature selection Robert Wessel <robertwessel2@yahoo.com> - 2017-03-14 21:45 -0500
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-14 21:16 -0700
Re: Language feature selection Les Cargill <lcargill99@comcast.com> - 2017-03-11 16:40 -0600
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-10 15:10 -0700
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-10 16:42 -0600
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-10 17:02 -0700
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-11 00:46 +0000
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-11 13:05 -0700
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-11 21:58 +0000
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-11 15:19 -0700
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-11 23:27 +0000
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-10 20:14 -0600
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-11 12:16 -0700
Re: Language feature selection Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2017-03-10 20:40 +0100
Re: Language feature selection Wouter van Ooijen <wouter@voti.nl> - 2017-03-10 22:28 +0100
Re: Language feature selection Jacob Sparre Andersen <jacob@jacob-sparre.dk> - 2017-03-10 20:03 +0100
Re: Language feature selection Grant Edwards <invalid@invalid.invalid> - 2017-03-10 19:48 +0000
Re: Language feature selection Jacob Sparre Andersen <jacob@jacob-sparre.dk> - 2017-03-13 21:25 +0100
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-10 13:03 -0700
Re: Language feature selection Jacob Sparre Andersen <jacob@jacob-sparre.dk> - 2017-03-13 21:40 +0100
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-13 14:35 -0700
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-14 01:06 +0000
Re: Language feature selection Paul Rubin <no.email@nospam.invalid> - 2017-03-13 19:23 -0700
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-14 08:48 +0000
Re: Language feature selection Paul Rubin <no.email@nospam.invalid> - 2017-03-14 02:14 -0700
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-14 09:33 +0000
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-14 09:21 -0700
Re: Language feature selection Les Cargill <lcargill99@comcast.com> - 2017-03-17 06:01 -0500
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-17 11:39 +0000
Re: Language feature selection Les Cargill <lcargill99@comcast.com> - 2017-03-17 07:16 -0500
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-17 13:49 +0000
Re: Language feature selection Paul Rubin <no.email@nospam.invalid> - 2017-03-17 11:03 -0700
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-17 19:21 +0100
Re: Language feature selection Paul Rubin <no.email@nospam.invalid> - 2017-03-17 11:34 -0700
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-17 20:26 +0100
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-17 20:07 +0000
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-17 20:29 +0000
Re: Language feature selection Les Cargill <lcargill99@comcast.com> - 2017-03-17 19:19 -0500
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-18 08:18 +0000
Re: Language feature selection Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2017-03-14 21:20 +0100
Re: Language feature selection jim.brakefield@ieee.org - 2017-03-10 18:46 -0800
Re: Language feature selection Niklas Holsti <niklas.holsti@tidorum.invalid> - 2017-03-11 15:41 +0200
Re: Language feature selection jim.brakefield@ieee.org - 2017-03-11 14:20 -0800
Re: Language feature selection upsidedown@downunder.com - 2017-03-12 00:54 +0200
Re: Language feature selection jim.brakefield@ieee.org - 2017-03-12 18:08 -0700
Re: Language feature selection upsidedown@downunder.com - 2017-03-13 23:36 +0200
Re: Language feature selection Robert Wessel <robertwessel2@yahoo.com> - 2017-03-13 17:03 -0500
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-11 14:21 -0700
Page 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2017-03-10 16:30 -0600 |
| Message-ID | <o9v9e1$1trv$1@gioia.aioe.org> |
| In reply to | #25988 |
On 2017-03-10 3:37 PM, Paul Rubin wrote: > Walter Banks <walter@bytecraft.com> writes: >> The brouhaha about "@" and C is really more about having >> supporting syntax to be able to explain what is desired without >> needing an indirect definition. That is my real argument not that >> it can't be done. > > It's probably clearest to just call functions to bang on those > registers. The compiler can inline them so there shouldn't be > overhead. > >> It is a real eyeopener to spend some time with some of the current >> crop of programmers who are using what many of us would consider a >> toy language to actually achieve some pretty remarkable results. It >> took me a long time to respect what they are doing. > > Do you mean C? > More like the whole crop of interpreted languages now being used. I tend to think of C as something of our generation. A high percentage (but not all) of the compiler projects I have done has been C compilers. w..
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-03-10 18:14 -0800 |
| Message-ID | <87d1dor24v.fsf@nightsong.com> |
| In reply to | #25990 |
Walter Banks <walter@bytecraft.com> writes:
>> Do you mean C?
> More like the whole crop of interpreted languages now being used.
Oh ok, but those languages are generally sugared-up re-inventions of
Lisp, which is even older than C, and which the cogniscenti have been
using all along ;-). E. W. Dijkstra in his Turing Award lecture back in
1972 had already observed:
With a few very basic principles at its foundation, it [LISP] has
shown a remarkable stability. Besides that, LISP has been the
carrier for a considerable number of in a sense our most
sophisticated computer applications. LISP has jokingly been
described as "the most intelligent way to misuse a computer". I
think that description a great compliment because it transmits the
full flavour of liberation: it has assisted a number of our most
gifted fellow humans in thinking previously impossible thoughts.
By all means give the interpreters a try if you haven't. They make
programming more productive along several axes, at the cost of some
hardware resources (cpu and memory) that are generally plentiful with
today's computers.
> I tend to think of C as something of our generation.
Yes, I was less surprised that good stuff was being done in interpreted
languages, as that it's now relatively rare for even their expert users
to have ever used C for anything.
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2017-03-11 07:46 -0600 |
| Message-ID | <oa0v3v$cl0$1@gioia.aioe.org> |
| In reply to | #26000 |
On 2017-03-10 8:14 PM, Paul Rubin wrote: > Walter Banks <walter@bytecraft.com> writes: >>> Do you mean C? >> More like the whole crop of interpreted languages now being used. > > Oh ok, but those languages are generally sugared-up re-inventions of > Lisp, which is even older than C, and which the cogniscenti have > been using all along ;-). E. W. Dijkstra in his Turing Award lecture > back in 1972 had already observed: > > With a few very basic principles at its foundation, it [LISP] has > shown a remarkable stability. Besides that, LISP has been the carrier > for a considerable number of in a sense our most sophisticated > computer applications. LISP has jokingly been described as "the most > intelligent way to misuse a computer". I think that description a > great compliment because it transmits the full flavour of liberation: > it has assisted a number of our most gifted fellow humans in thinking > previously impossible thoughts. > > By all means give the interpreters a try if you haven't. They make > programming more productive along several axes, at the cost of some > hardware resources (cpu and memory) that are generally plentiful > with today's computers. > >> I tend to think of C as something of our generation. > > Yes, I was less surprised that good stuff was being done in > interpreted languages, as that it's now relatively rare for even > their expert users to have ever used C for anything. > It is our generation that is obsessed with optimization execution and data space. Some of the programs I have seen be developed in by these people tend to be using algorithms that are exchanging our sense of optimization for application performance. (VR applications for example) Related to that we have almost always treated processor resources as a rare resource and when I changed that mind set on some of the massively parallel systems I have been working on to processors are just a resource that needs to be managed like memory in applications I was suddenly seeing huge leaps in application performance. w..
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2017-03-11 12:53 -0700 |
| Message-ID | <oa1kes$9lm$1@dont-email.me> |
| In reply to | #26014 |
On 3/11/2017 6:46 AM, Walter Banks wrote: > On 2017-03-10 8:14 PM, Paul Rubin wrote: >> Walter Banks <walter@bytecraft.com> writes: >>>> Do you mean C? >>> More like the whole crop of interpreted languages now being used. >> >> Oh ok, but those languages are generally sugared-up re-inventions of >> Lisp, which is even older than C, and which the cogniscenti have >> been using all along ;-). E. W. Dijkstra in his Turing Award lecture >> back in 1972 had already observed: >> >> With a few very basic principles at its foundation, it [LISP] has >> shown a remarkable stability. Besides that, LISP has been the carrier >> for a considerable number of in a sense our most sophisticated >> computer applications. LISP has jokingly been described as "the most >> intelligent way to misuse a computer". I think that description a >> great compliment because it transmits the full flavour of liberation: >> it has assisted a number of our most gifted fellow humans in thinking >> previously impossible thoughts. >> >> By all means give the interpreters a try if you haven't. They make >> programming more productive along several axes, at the cost of some >> hardware resources (cpu and memory) that are generally plentiful >> with today's computers. >> >>> I tend to think of C as something of our generation. >> >> Yes, I was less surprised that good stuff was being done in >> interpreted languages, as that it's now relatively rare for even >> their expert users to have ever used C for anything. > > It is our generation that is obsessed with optimization execution and > data space. Agreed (as I stated elsewhere). But this is only natural given our "upbringing" -- in much the same way that folks who lived through The Great Depression are far less likely to discard items than those who grew up in "times of plenty". And, while hardware has grown cheaper and more capable over the years, you still don't see 32b CPU's in *mice* or debouncing keys in keyboards! Even "fancy" products often leverage external resources to control costs (is there any reason why a TV *can't* do its own speech recognition without farming that task out to some remote server? really??) > Some of the programs I have seen be developed in by these > people tend to be using algorithms that are exchanging our sense of > optimization for application performance. (VR applications for example) > > Related to that we have almost always treated processor resources as a > rare resource and when I changed that mind set on some of the massively > parallel systems I have been working on to processors are just a > resource that needs to be managed like memory in applications I was > suddenly seeing huge leaps in application performance. Agreed. But, that only makes sense in certain contexts. E.g., when I started the design of my current system, I approached it as "dumb motes" connected to a relatively high performance "server". The motes were essentially "I/O extenders" (cuz you can't run thousands of sensor and actuator cables to a single central server). But, I quickly concluded that battery power was unrealistic (do you want to change a hundred batteries in your maintenance cycle??) and "wall warts" too much of an eyesore (a hundred wall warts) as well as impractical from a wiring standpoint (what do you do if you don't have an electric outlet nearby?). And, wireless comms opens up a bundle of security/privacy/reliability issues (at the very least, DoS attacks). A *wired* system avoids all of these issues (power and comms in the same cable). And, once you have the cost (labor) of wiring such a system, saving a few dollars in each node becomes silly -- especially if adding "smarts" means you can REMOVE smarts from that "central server". Distributing the computational tasks requires different notions of "efficiency"; particularly when it comes to managing the developer! The idea of saving a few bytes by packing fields into a word is just nonsense! Or, inlining a function to save a few microseconds at runtime. Add to that the growing trend of opening systems to third-party (or user-based) extension while maintaining a modicum of reliability/security and the old notions of where to spend resources are out the window!
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2017-03-12 09:45 -0600 |
| Message-ID | <oa3qfe$16oc$1@gioia.aioe.org> |
| In reply to | #26019 |
On 2017-03-11 1:53 PM, Don Y wrote: >> It is our generation that is obsessed with optimization execution and >> data space. > > Agreed (as I stated elsewhere). But this is only natural given our > "upbringing" -- in much the same way that folks who lived through > The Great Depression are far less likely to discard items than those > who grew up in "times of plenty". > > And, while hardware has grown cheaper and more capable over the years, > you still don't see 32b CPU's in *mice* or debouncing keys in keyboards! Developers have discovered that updating old 8 bit applications to run on modern 32 bit general purpose processors have had a hidden cost. Some applications are better suited to small processors for code size and a variety of things emi from chips due to increased width of the data buses and board layout issues. w..
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2017-03-12 11:56 -0700 |
| Message-ID | <oa45fl$om5$1@dont-email.me> |
| In reply to | #26032 |
On 3/12/2017 8:45 AM, Walter Banks wrote: > On 2017-03-11 1:53 PM, Don Y wrote: >>> It is our generation that is obsessed with optimization execution and >>> data space. >> >> Agreed (as I stated elsewhere). But this is only natural given our >> "upbringing" -- in much the same way that folks who lived through >> The Great Depression are far less likely to discard items than those >> who grew up in "times of plenty". >> >> And, while hardware has grown cheaper and more capable over the years, >> you still don't see 32b CPU's in *mice* or debouncing keys in keyboards! > > Developers have discovered that updating old 8 bit applications to run on > modern 32 bit general purpose processors have had a hidden cost. > Some applications are better suited to small processors for code size and a > variety of things emi from chips due to increased width of the data buses and > board layout issues. Of course! Small processors also tend to offer more predictable performance, lower power consumption, etc. But, beyond it all, cost is still a huge factor in many applications. When your end-user price is $20, there's not much room for "unnecessary" silicon, regardless of how much development time you *might* trim off your schedule, "ease of maintenance", etc.
[toc] | [prev] | [next] | [standalone]
| From | Dimiter_Popoff <dp@tgi-sci.com> |
|---|---|
| Date | 2017-03-12 21:05 +0200 |
| Message-ID | <oa4609$qm4$1@dont-email.me> |
| In reply to | #26032 |
On 12.3.2017 г. 17:45, Walter Banks wrote: > On 2017-03-11 1:53 PM, Don Y wrote: >>> It is our generation that is obsessed with optimization execution and >>> data space. >> >> Agreed (as I stated elsewhere). But this is only natural given our >> "upbringing" -- in much the same way that folks who lived through >> The Great Depression are far less likely to discard items than those >> who grew up in "times of plenty". >> >> And, while hardware has grown cheaper and more capable over the years, >> you still don't see 32b CPU's in *mice* or debouncing keys in keyboards! > > Developers have discovered that updating old 8 bit applications to run > on modern 32 bit general purpose processors have had a hidden cost. > Some applications are better suited to small processors for code size > and a variety of things emi from chips due to increased width of the > data buses and board layout issues. > > w.. Hi Walter, I had - still have - some work done in the 80-s I don't have to part with. It was done on a 6809 (under MDOS, the OS which used to run on Motorola's Exorsiser systems, back then I ran it on hardware I had built with ROM (BIOS as they now have it) I had written). So what did it cost me? A few weeks of work to emulate the 6809 system I had on a Power architecture processor running under DPS. 46 kilobytes of code; this includes a terminal emulation (my graphics terminal I had designed back then), can be run in multiple instances in multiple windows - and runs about 50 times faster than the original 2MHz 09 ran (in fact than two of them, one was in the graphics terminal, interfaced via a parallel FIFO-ed cable to the system board; the terminal board was not emulated as if running on a 6809, just its functionality (was easier using the dps graphics services)). The silicon all this can run on is certainly cheaper than it could have been back in the 80-s with the 6809... I am not contradicting your point of course, I am sure the hidden costs you refer to do exist. But this is probably when people try to replicate a device programmed 30 years ago cleanly with some new high level language stuff put together by todays popular methods (which are very messy in my book by this is another matter). Dimiter ------------------------------------------------------ Dimiter Popoff, TGI http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2017-03-12 14:40 -0700 |
| Message-ID | <oa4f2p$r0k$1@dont-email.me> |
| In reply to | #26034 |
Hi Dimiter,
On 3/12/2017 12:05 PM, Dimiter_Popoff wrote:
> On 12.3.2017 г. 17:45, Walter Banks wrote:
>> On 2017-03-11 1:53 PM, Don Y wrote:
>>>> It is our generation that is obsessed with optimization execution and
>>>> data space.
>>>
>>> Agreed (as I stated elsewhere). But this is only natural given our
>>> "upbringing" -- in much the same way that folks who lived through
>>> The Great Depression are far less likely to discard items than those
>>> who grew up in "times of plenty".
>>>
>>> And, while hardware has grown cheaper and more capable over the years,
>>> you still don't see 32b CPU's in *mice* or debouncing keys in keyboards!
>>
>> Developers have discovered that updating old 8 bit applications to run
>> on modern 32 bit general purpose processors have had a hidden cost.
>> Some applications are better suited to small processors for code size
>> and a variety of things emi from chips due to increased width of the
>> data buses and board layout issues.
> I had - still have - some work done in the 80-s I don't have to part
> with. It was done on a 6809 (under MDOS, the OS which used to run
> on Motorola's Exorsiser systems, back then I ran it on hardware I had
> built with ROM (BIOS as they now have it) I had written).
> So what did it cost me? A few weeks of work to emulate the 6809
> system I had on a Power architecture processor running under DPS.
> 46 kilobytes of code; this includes a terminal emulation (my graphics
> terminal I had designed back then), can be run in multiple instances
> in multiple windows - and runs about 50 times faster than the original
> 2MHz 09 ran (in fact than two of them, one was in the graphics
> terminal, interfaced via a parallel FIFO-ed cable to the system board;
> the terminal board was not emulated as if running on a 6809, just
> its functionality (was easier using the dps graphics services)).
>
> The silicon all this can run on is certainly cheaper than it
> could have been back in the 80-s with the 6809...
>
> I am not contradicting your point of course, I am sure the hidden
> costs you refer to do exist. But this is probably when people
> try to replicate a device programmed 30 years ago cleanly with
> some new high level language stuff put together by todays
> popular methods (which are very messy in my book by this is
> another matter).
I think the point is the assumptions that are inherent in the
original ("crippled", by today's standards) implementations.
Non-standard data types, hand-optimization that doesn't lend
itself to a newer processor or language, etc.
I always cringed when I had to maintain a "small system" that
someone else had designed/implemented... no way to know what hacks
he relied on in his design (that aren't documented, of course!)
As a result, I would strongly resist the temptation to "fix"
outrageously bad implementations unless the effort was required
for me to implement the changes contracted. I'd never know if
some change would break something of which I was unaware!
[I've seen some REALLY BAD implementations of small systems -- I
suspect because the folks hired for the original effort weren't
chosen for their abilities to develop BIG/well-defined systems
and were more "hackers" than anything else]
[[I knew of one (very large!) company that assigned responsibility
for the software on a multi-million dollar development project to
a *technician* -- because he tinkered with software AS A HOBBY!]]
Note the problems the MAME folks have had getting (pseudo-)*true*
emulation of the systems that ran on 8b CPU's that were 1000 times
slower than modern machines despite all the resources they can throw
at the problem!
[And, I suspect that these systems only *appear* to emulate
their ancestors but don't really when examined in fine detail
(e.g., under conditions of overload)]
[toc] | [prev] | [next] | [standalone]
| From | Dimiter_Popoff <dp@tgi-sci.com> |
|---|---|
| Date | 2017-03-13 00:36 +0200 |
| Message-ID | <oa4iaj$6db$1@dont-email.me> |
| In reply to | #26039 |
On 12.3.2017 г. 23:40, Don Y wrote:
> Hi Dimiter,
>
> On 3/12/2017 12:05 PM, Dimiter_Popoff wrote:
>> On 12.3.2017 г. 17:45, Walter Banks wrote:
>>> On 2017-03-11 1:53 PM, Don Y wrote:
>>>>> It is our generation that is obsessed with optimization execution and
>>>>> data space.
>>>>
>>>> Agreed (as I stated elsewhere). But this is only natural given our
>>>> "upbringing" -- in much the same way that folks who lived through
>>>> The Great Depression are far less likely to discard items than those
>>>> who grew up in "times of plenty".
>>>>
>>>> And, while hardware has grown cheaper and more capable over the years,
>>>> you still don't see 32b CPU's in *mice* or debouncing keys in
>>>> keyboards!
>>>
>>> Developers have discovered that updating old 8 bit applications to run
>>> on modern 32 bit general purpose processors have had a hidden cost.
>>> Some applications are better suited to small processors for code size
>>> and a variety of things emi from chips due to increased width of the
>>> data buses and board layout issues.
>
>> I had - still have - some work done in the 80-s I don't have to part
>> with. It was done on a 6809 (under MDOS, the OS which used to run
>> on Motorola's Exorsiser systems, back then I ran it on hardware I had
>> built with ROM (BIOS as they now have it) I had written).
>> So what did it cost me? A few weeks of work to emulate the 6809
>> system I had on a Power architecture processor running under DPS.
>> 46 kilobytes of code; this includes a terminal emulation (my graphics
>> terminal I had designed back then), can be run in multiple instances
>> in multiple windows - and runs about 50 times faster than the original
>> 2MHz 09 ran (in fact than two of them, one was in the graphics
>> terminal, interfaced via a parallel FIFO-ed cable to the system board;
>> the terminal board was not emulated as if running on a 6809, just
>> its functionality (was easier using the dps graphics services)).
>>
>> The silicon all this can run on is certainly cheaper than it
>> could have been back in the 80-s with the 6809...
>>
>> I am not contradicting your point of course, I am sure the hidden
>> costs you refer to do exist. But this is probably when people
>> try to replicate a device programmed 30 years ago cleanly with
>> some new high level language stuff put together by todays
>> popular methods (which are very messy in my book by this is
>> another matter).
>
> I think the point is the assumptions that are inherent in the
> original ("crippled", by today's standards) implementations.
> Non-standard data types, hand-optimization that doesn't lend
> itself to a newer processor or language, etc.
>
> I always cringed when I had to maintain a "small system" that
> someone else had designed/implemented... no way to know what hacks
> he relied on in his design (that aren't documented, of course!)
> As a result, I would strongly resist the temptation to "fix"
> outrageously bad implementations unless the effort was required
> for me to implement the changes contracted. I'd never know if
> some change would break something of which I was unaware!
Hi Don,
my point is that instead of trying to "port" the old code it is
much easier to simply emulate the old processor instruction set
_completely_, like I did with the 6809. People just overlook
it. And, like I said, the entire thing was 45 kilobytes (and the
actual processor emulation is a fraction of that) of PPC code....
Even the 6809 - a fairly complex 8 bit CPU - was quite easy
to emulate on a Power architecture processor with its huge
register set, all registers being larger than those to emulate etc.
And processors of that era tend to be well documented, at least
those I know (Motorolas) used to be.
As long as the original code does not do timing loops
everything runs just fine. If there are timing loops well,
they have to be taken care of. Not hard to locate.
Then emulating on a much faster CPU makes life easier;
you can just include some virtual machinery in the emulation,
e.g. trap read/writes to old peripheral addresses and handle
them on the new CPU using its peripherals - and its power
(I did not do that IIRC, I just modified a little the ROM
entry points - did have the sources as I had written it - so
that say for disk accesses via the old floppy disk controller
the thing traps and uses a memory image for a floppy disk
(the largest one was 512 kilobytes....).
A 400 MHz Power core (603e derivative) runs about 50 times
faster than two 2 MHz 6809 CPU-s could run in parallel,
without the emulation being particularly tricky or pushed,
just the old processor took a lot of cycles to do things.
They all did.
Mind you, I have done the "porting" as well - when performance
mattered. This is how I started vpa - it assembled CPU32 sources
into PPC object code. The effort did not take me a few weeks
as it did with the 6809 emulation, it took me about _a year_,
the vpa sources are 880 kilobytes - I have been progressing at
half my average programming rate which is about 150k/month...
Much much harder than the emulation (well, this was the tool
creation of course, not really comparable the two things).
Dimiter
------------------------------------------------------
Dimiter Popoff, TGI http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2017-03-12 17:00 -0700 |
| Message-ID | <oa4na1$oem$1@dont-email.me> |
| In reply to | #26041 |
On 3/12/2017 3:36 PM, Dimiter_Popoff wrote:
> my point is that instead of trying to "port" the old code it is
> much easier to simply emulate the old processor instruction set
> _completely_, like I did with the 6809. People just overlook
> it. And, like I said, the entire thing was 45 kilobytes (and the
> actual processor emulation is a fraction of that) of PPC code....
> Even the 6809 - a fairly complex 8 bit CPU - was quite easy
> to emulate on a Power architecture processor with its huge
> register set, all registers being larger than those to emulate etc.
> And processors of that era tend to be well documented, at least
> those I know (Motorolas) used to be.
But Exorcisers/Exormacs are essentially "desktop" machines -- they
run text processing applications, for the most part. Even the debuggers
are reasonably "rich" applications -- they've got a healthy budget and
sell price that they could command.
> As long as the original code does not do timing loops
> everything runs just fine. If there are timing loops well,
> they have to be taken care of. Not hard to locate.
The problem comes when the timing is *implicit*. E.g., you
can't just emulate the functionality of the code being
emulated but, also, must emulate the *timing* of that code.
[If you could do this, then timing loops wouldn't be an issue]
E.g., there were arcade pieces (video/pinball) that would
sit in very tight loops effectively shifting *bits* out
as fast as the processor could manage (because the hardware
was designed by someone ignorant of the *software* issues!).
loop
sample bit
if bit HI
output HI
else
output LO
repeat
Not only do you have to emulate the "time around the loop"
(i.e., each repetition) AND match that of the original
execution time (otherwise, you're altering the frequency
component of the generated "bit stream"), *but*, you also have
to ensure the time between one "output HI" and the next "output HI"
*or* "output LO" remains constant -- otherwise you're introducing
clock jitter.
Then, wrap this in a bigger loop to enumerate all of the bits in
a particular byte:
bigloop:
fetch byte
bitcount = 8
loop:
sample bit
if bit HI
output HI
else
output LO
bitcount--
repeat if not zero
advance pointer
bytecount--
repeat bigloop if not done
And the time from output of the last bit of one byte to
the output of the first bit of the next byte must now satisfy
the same inter-bit time as between any two bits within a
single byte.
[If using this to generate audio, clock jitter can beat
through the signal annoyingly]
If you look through some of my old (ancient) code, you'll
often see numbers in parens adjacent to each instruction
(ASM) indicating the number of clock cycles. This code stanza
will be bracketed with comments like:
// set output to desired state
...
// (5)
// (10/12)
// (4)
...
// at least (19) clock cycles have elapsed -- sufficient
// delay for Fosc <= 12.3MHz
I.e., instead of spinning in a loop, I was "doing work" that needed
to be done and using the side effect (elapsed time) of that work
to provide my delay.
If you just look at the object/ROM image, you'd not know that this
was happening for a deliberate reason.
For really short delays, there isn't often a practical alternative.
OTOH, old processors had far more predictable "best case" timings
(if they happened to "run long", no problem -- you're looking for
AT LEAST some minimum delay)
> Then emulating on a much faster CPU makes life easier;
> you can just include some virtual machinery in the emulation,
> e.g. trap read/writes to old peripheral addresses and handle
> them on the new CPU using its peripherals - and its power
> (I did not do that IIRC, I just modified a little the ROM
> entry points - did have the sources as I had written it - so
> that say for disk accesses via the old floppy disk controller
> the thing traps and uses a memory image for a floppy disk
> (the largest one was 512 kilobytes....).
>
> A 400 MHz Power core (603e derivative) runs about 50 times
> faster than two 2 MHz 6809 CPU-s could run in parallel,
> without the emulation being particularly tricky or pushed,
> just the old processor took a lot of cycles to do things.
> They all did.
>
> Mind you, I have done the "porting" as well - when performance
> mattered. This is how I started vpa - it assembled CPU32 sources
> into PPC object code. The effort did not take me a few weeks
> as it did with the 6809 emulation, it took me about _a year_,
> the vpa sources are 880 kilobytes - I have been progressing at
> half my average programming rate which is about 150k/month...
> Much much harder than the emulation (well, this was the tool
> creation of course, not really comparable the two things).
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-03-13 16:50 -0500 |
| Message-ID | <7m4eccdaioel5srh2og36dmks46ddhc5bd@4ax.com> |
| In reply to | #26019 |
On Sat, 11 Mar 2017 12:53:46 -0700, Don Y <blockedofcourse@foo.invalid> wrote: >(is there any reason why a TV *can't* do its own speech recognition without >farming that task out to some remote server? really??) Well, yes. The fairly high* quality speech recognition we see today depends on access to a large and evolving** database of things people have actually said and written. The modern speech recognition systems are yet another example that brute force is a much more viable approach to many problems than people used to think. *FSVO "high" **IOW, "Watch Game of Thrones" would be well understood now simply because that would be, in whole or in part, a common query. A few years ago, before the series hit, it would have been much shakier.
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2017-03-13 17:08 -0700 |
| Message-ID | <oa7c4m$37f$1@dont-email.me> |
| In reply to | #26060 |
On 3/13/2017 2:50 PM, Robert Wessel wrote: > On Sat, 11 Mar 2017 12:53:46 -0700, Don Y > <blockedofcourse@foo.invalid> wrote: > >> (is there any reason why a TV *can't* do its own speech recognition without >> farming that task out to some remote server? really??) > > Well, yes. The fairly high* quality speech recognition we see today > depends on access to a large and evolving** database of things people > have actually said and written. The modern speech recognition systems > are yet another example that brute force is a much more viable > approach to many problems than people used to think. > > *FSVO "high" > > **IOW, "Watch Game of Thrones" would be well understood now simply > because that would be, in whole or in part, a common query. A few > years ago, before the series hit, it would have been much shakier. It's a limited domain recognizer. Even if next season adds a show called "Fraggle Frooppy Figglesnorts", the service that provides the "TV guide" can provide enough information for the local recognizer to handle the recognition locally. [I don't expect even a remote server connected recognizer to correctly handle "Watch Alfred Hitchcock" if he's no longer on-the-air. Does your TV stop working when the server goes offline? Your network connection dies? Provider goes out of business? etc.]
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-03-13 20:51 -0500 |
| Message-ID | <snieccd05ssv0cmbmruo8tpr0u8isdjgkc@4ax.com> |
| In reply to | #26064 |
On Mon, 13 Mar 2017 17:08:41 -0700, Don Y <blockedofcourse@foo.invalid> wrote: >On 3/13/2017 2:50 PM, Robert Wessel wrote: >> On Sat, 11 Mar 2017 12:53:46 -0700, Don Y >> <blockedofcourse@foo.invalid> wrote: >> >>> (is there any reason why a TV *can't* do its own speech recognition without >>> farming that task out to some remote server? really??) >> >> Well, yes. The fairly high* quality speech recognition we see today >> depends on access to a large and evolving** database of things people >> have actually said and written. The modern speech recognition systems >> are yet another example that brute force is a much more viable >> approach to many problems than people used to think. >> >> *FSVO "high" >> >> **IOW, "Watch Game of Thrones" would be well understood now simply >> because that would be, in whole or in part, a common query. A few >> years ago, before the series hit, it would have been much shakier. > >It's a limited domain recognizer. Even if next season adds a show >called "Fraggle Frooppy Figglesnorts", the service that provides the >"TV guide" can provide enough information for the local recognizer to >handle the recognition locally. It's really not. Consider "the news show with John Smith" or "a movie with Hepburn and...", or "a children's show with animated unicorns". >[I don't expect even a remote server connected recognizer to >correctly handle "Watch Alfred Hitchcock" if he's no longer >on-the-air. Does your TV stop working when the server goes >offline? Your network connection dies? Provider goes out >of business? etc.] I dunno. "OK Google" on my phone immediately popped up a list of Hitchcock videos and shows for that query. And yes, a large chunk of my TV service dies if my network connection goes out.
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2017-03-13 20:31 -0700 |
| Message-ID | <oa7o13$pp6$1@dont-email.me> |
| In reply to | #26067 |
On 3/13/2017 6:51 PM, Robert Wessel wrote: > On Mon, 13 Mar 2017 17:08:41 -0700, Don Y > <blockedofcourse@foo.invalid> wrote: > >> On 3/13/2017 2:50 PM, Robert Wessel wrote: >>> On Sat, 11 Mar 2017 12:53:46 -0700, Don Y >>> <blockedofcourse@foo.invalid> wrote: >>> >>>> (is there any reason why a TV *can't* do its own speech recognition without >>>> farming that task out to some remote server? really??) >>> >>> Well, yes. The fairly high* quality speech recognition we see today >>> depends on access to a large and evolving** database of things people >>> have actually said and written. The modern speech recognition systems >>> are yet another example that brute force is a much more viable >>> approach to many problems than people used to think. >>> >>> *FSVO "high" >>> >>> **IOW, "Watch Game of Thrones" would be well understood now simply >>> because that would be, in whole or in part, a common query. A few >>> years ago, before the series hit, it would have been much shakier. >> >> It's a limited domain recognizer. Even if next season adds a show >> called "Fraggle Frooppy Figglesnorts", the service that provides the >> "TV guide" can provide enough information for the local recognizer to >> handle the recognition locally. > > > It's really not. Consider "the news show with John Smith" or "a movie > with Hepburn and...", or "a children's show with animated unicorns". That's a different feature. If the guide contained an entry that had the words "news" "john" and "smith" in it, I would expect it to be able to find that entry with just local processing. "a children's show with animated unicorns" might not be discernible from an examination of the guide entries. Nor would "old geezer escorting a midget through a magical land". >> [I don't expect even a remote server connected recognizer to >> correctly handle "Watch Alfred Hitchcock" if he's no longer >> on-the-air. Does your TV stop working when the server goes >> offline? Your network connection dies? Provider goes out >> of business? etc.] > > I dunno. "OK Google" on my phone immediately popped up a list of > Hitchcock videos and shows for that query. > > And yes, a large chunk of my TV service dies if my network connection > goes out. Without your internet connection, can you turn the TV on? off? change volume? command it to "watch CSI Miami"? The music we've loaded (from CD) into SWMBO's vehicle contains song titles, etc. I can say "Play Little Green Bag" and it will realize that there is a song having the title "Little Green Bag" on the internal disk drive and immediately start playing it. It might have a problem if I asked it to "play fish" and fish was spelled "ghoti" on the song title... If the (TV) guide listed "CSI Miami", I'd expect it to be accessible without requiring a server's assistance. If _The Day the Earth Stood Still_ was listed in the guide's *description* of the "Late Night Movie" (a regularly scheduled time slot that presents a "movie du jour"), I'd expect to be able to access it by saying "watch Day Earth Still". The computationally intensive part of the problem is converting sound to glyphs. The "search" algorithm beyond that is relatively trivial. Being able to say "watch old movie with big robot from outer space" would require completely different processing requirements and more general knowledge. [*Think* about it. With speech recognition local, could *you* search through a guide and come up with a likely match in these cases? Would that be a HARDER challenge than recognizing the speech itself?]
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-03-14 21:45 -0500 |
| Message-ID | <97ahccl27fve5gq1d8vnh3ae7f2vftn174@4ax.com> |
| In reply to | #26069 |
On Mon, 13 Mar 2017 20:31:34 -0700, Don Y <blockedofcourse@foo.invalid> wrote: >On 3/13/2017 6:51 PM, Robert Wessel wrote: >> On Mon, 13 Mar 2017 17:08:41 -0700, Don Y >> <blockedofcourse@foo.invalid> wrote: >> >>> On 3/13/2017 2:50 PM, Robert Wessel wrote: >>>> On Sat, 11 Mar 2017 12:53:46 -0700, Don Y >>>> <blockedofcourse@foo.invalid> wrote: >>>> >>>>> (is there any reason why a TV *can't* do its own speech recognition without >>>>> farming that task out to some remote server? really??) >>>> >>>> Well, yes. The fairly high* quality speech recognition we see today >>>> depends on access to a large and evolving** database of things people >>>> have actually said and written. The modern speech recognition systems >>>> are yet another example that brute force is a much more viable >>>> approach to many problems than people used to think. >>>> >>>> *FSVO "high" >>>> >>>> **IOW, "Watch Game of Thrones" would be well understood now simply >>>> because that would be, in whole or in part, a common query. A few >>>> years ago, before the series hit, it would have been much shakier. >>> >>> It's a limited domain recognizer. Even if next season adds a show >>> called "Fraggle Frooppy Figglesnorts", the service that provides the >>> "TV guide" can provide enough information for the local recognizer to >>> handle the recognition locally. >> >> >> It's really not. Consider "the news show with John Smith" or "a movie >> with Hepburn and...", or "a children's show with animated unicorns". > >That's a different feature. If the guide contained an entry >that had the words "news" "john" and "smith" in it, I would >expect it to be able to find that entry with just local >processing. > >"a children's show with animated unicorns" might not be discernible >from an examination of the guide entries. Nor would "old geezer >escorting a midget through a magical land". > >>> [I don't expect even a remote server connected recognizer to >>> correctly handle "Watch Alfred Hitchcock" if he's no longer >>> on-the-air. Does your TV stop working when the server goes >>> offline? Your network connection dies? Provider goes out >>> of business? etc.] >> >> I dunno. "OK Google" on my phone immediately popped up a list of >> Hitchcock videos and shows for that query. >> >> And yes, a large chunk of my TV service dies if my network connection >> goes out. > >Without your internet connection, can you turn the TV on? off? change >volume? command it to "watch CSI Miami"? Sure I can turn it on and off without an internet connection, but unless CSI Miami happens to be on a Comcast channel at the moment (or recorded from one earlier), I can't watch it. And very little (some live events excepted) of our TV watching follows that pattern. On-demand, Netflix, Hulu, etc. So TV is mostly dead for us without an internet connection. >The music we've loaded (from CD) into SWMBO's vehicle contains song >titles, etc. I can say "Play Little Green Bag" and it will realize that >there is a song having the title "Little Green Bag" on the internal disk >drive and immediately start playing it. It might have a problem if I >asked it to "play fish" and fish was spelled "ghoti" on the song title... > >If the (TV) guide listed "CSI Miami", I'd expect it to be accessible without >requiring a server's assistance. If _The Day the Earth Stood Still_ was >listed in the guide's *description* of the "Late Night Movie" (a regularly >scheduled time slot that presents a "movie du jour"), I'd expect to be >able to access it by saying "watch Day Earth Still". > >The computationally intensive part of the problem is converting sound >to glyphs. The "search" algorithm beyond that is relatively trivial. No it's not - the sound-to-text part is solidly integrated with the database of things that are actually said. The Google voice assistant is particularly adept at letting you watch it change what it's "heard" as you get further into you sentence. >Being able to say "watch old movie with big robot from outer space" would >require completely different processing requirements and more general >knowledge. > >[*Think* about it. With speech recognition local, could *you* >search through a guide and come up with a likely match in these cases? >Would that be a HARDER challenge than recognizing the speech itself?] No I couldn't, but that's why we have computers and databases and whatnot - so we have *better* reference works than a TV Guide.
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2017-03-14 21:16 -0700 |
| Message-ID | <oaaf1d$126$1@dont-email.me> |
| In reply to | #26089 |
On 3/14/2017 7:45 PM, Robert Wessel wrote: >>>> [I don't expect even a remote server connected recognizer to >>>> correctly handle "Watch Alfred Hitchcock" if he's no longer >>>> on-the-air. Does your TV stop working when the server goes >>>> offline? Your network connection dies? Provider goes out >>>> of business? etc.] >>> >>> I dunno. "OK Google" on my phone immediately popped up a list of >>> Hitchcock videos and shows for that query. >>> >>> And yes, a large chunk of my TV service dies if my network connection >>> goes out. >> >> Without your internet connection, can you turn the TV on? off? change >> volume? command it to "watch CSI Miami"? > > Sure I can turn it on and off without an internet connection, but So, the TV can recognize your speech WITHOUT the need for an external server/service. > unless CSI Miami happens to be on a Comcast channel at the moment (or > recorded from one earlier), I can't watch it. And very little (some > live events excepted) of our TV watching follows that pattern. > On-demand, Netflix, Hulu, etc. So TV is mostly dead for us without an > internet connection. Different issue, entirely -- having an internet connection to *source* material (vs. having it to provide a speech recognition *service*). TV could fetch the "catalogs" of each of those services "on demand" *or* ahead of time and present them to you or use them to resolve your unprompted requests. If you don't have a Hulu account, no need for it to examine Hulu's offerings, etc. >> The music we've loaded (from CD) into SWMBO's vehicle contains song >> titles, etc. I can say "Play Little Green Bag" and it will realize that >> there is a song having the title "Little Green Bag" on the internal disk >> drive and immediately start playing it. It might have a problem if I >> asked it to "play fish" and fish was spelled "ghoti" on the song title... >> >> If the (TV) guide listed "CSI Miami", I'd expect it to be accessible without >> requiring a server's assistance. If _The Day the Earth Stood Still_ was >> listed in the guide's *description* of the "Late Night Movie" (a regularly >> scheduled time slot that presents a "movie du jour"), I'd expect to be >> able to access it by saying "watch Day Earth Still". >> >> The computationally intensive part of the problem is converting sound >> to glyphs. The "search" algorithm beyond that is relatively trivial. > > No it's not - the sound-to-text part is solidly integrated with the > database of things that are actually said. The Google voice assistant > is particularly adept at letting you watch it change what it's "heard" > as you get further into you sentence. Implementation detail. >> Being able to say "watch old movie with big robot from outer space" would >> require completely different processing requirements and more general >> knowledge. >> >> [*Think* about it. With speech recognition local, could *you* >> search through a guide and come up with a likely match in these cases? >> Would that be a HARDER challenge than recognizing the speech itself?] > > No I couldn't, *Really*?? If a local service spit out a set of words that it recognized (with likelihoods) from an utterance, you couldn't examine a set of databases that you held, locally, to determine what the likely selection might be? It really *isn't* difficult. The problem lies in the actual recognition, not in the "mapping to meaning" aspect. > but that's why we have computers and databases and > whatnot - so we have *better* reference works than a TV Guide.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2017-03-11 16:40 -0600 |
| Message-ID | <oa1tvl$2o8$2@dont-email.me> |
| In reply to | #26014 |
Walter Banks wrote: > On 2017-03-10 8:14 PM, Paul Rubin wrote: >> Walter Banks <walter@bytecraft.com> writes: >>>> Do you mean C? >>> More like the whole crop of interpreted languages now being used. >> >> Oh ok, but those languages are generally sugared-up re-inventions of >> Lisp, which is even older than C, and which the cogniscenti have >> been using all along ;-). E. W. Dijkstra in his Turing Award lecture >> back in 1972 had already observed: >> >> With a few very basic principles at its foundation, it [LISP] has >> shown a remarkable stability. Besides that, LISP has been the carrier >> for a considerable number of in a sense our most sophisticated >> computer applications. LISP has jokingly been described as "the most >> intelligent way to misuse a computer". I think that description a >> great compliment because it transmits the full flavour of liberation: >> it has assisted a number of our most gifted fellow humans in thinking >> previously impossible thoughts. >> >> By all means give the interpreters a try if you haven't. They make >> programming more productive along several axes, at the cost of some >> hardware resources (cpu and memory) that are generally plentiful >> with today's computers. >> >>> I tend to think of C as something of our generation. >> >> Yes, I was less surprised that good stuff was being done in >> interpreted languages, as that it's now relatively rare for even >> their expert users to have ever used C for anything. >> > It is our generation that is obsessed with optimization execution and > data space. Some of the programs I have seen be developed in by these > people tend to be using algorithms that are exchanging our sense of > optimization for application performance. (VR applications for example) > > Related to that we have almost always treated processor resources as a > rare resource and when I changed that mind set on some of the massively > parallel systems I have been working on to processors are just a > resource that needs to be managed like memory in applications I was > suddenly seeing huge leaps in application performance. > > w.. > > We've been at the von Neumann bottleneck for close to 20 years now for most architectures. I haven't seen anything CPU bound in a very long time, but I'm not in that market space. With CUDA, anything is increasingly possible. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2017-03-10 15:10 -0700 |
| Message-ID | <o9v83u$c54$1@dont-email.me> |
| In reply to | #25985 |
On 3/10/2017 1:30 PM, Walter Banks wrote:
> On 2017-03-10 12:24 PM, Don Y wrote:
>>>
>>> If something is important to the correct operation of the program,
>>> then I like it to be visible in the source code. A useful benefit
>>> is that the information is easily found and analysed by the IDEs
>>> and/or other source code manipulation tools around.
>>
>> I guess it depends on what you consider "source code". How do you
>> treat makefiles, linker scripts, etc.? Clearly they are all
>> important to the *intended* operation of the program -- as are the
>> actual tools, themselves.
>>
>> How much of this cruft do you clutter the "sources" with in the
>> attempt to ensure they accompany the sources? What about applications
>> wherein multiple languages are combined; how do you nail down the
>> "implementation defined" behavior of their interfaces? What order
>> will your Java/C/Python/foo function build its stack frame? How will
>> your FORTRAN/Pascal/ASM/bar module interface to it??
>
> There are lots of tools issues that should be re-examined. There is many
> cases where the tool execution is backwards to what generates the best
Yes, but you also have to figure the "developer" in that calculus.
People need to be able to wrap their brains around their solutions
(esp if those solutions import "components" from other crania!)
A machine can have (near) infinite storage; humans tend to need to
reduce things to simpler mental models, eliding many of the details
(that a machine *could* examine and exploit).
Additionally, there is value in "hiding detail" when dealing with
human agents; you can (undoubtedly) "trust" a machine with those
details -- cuz, you'd know the constraints placed on what it could
*do* with them! (something that you wouldn't trust to a human!)
> code. The compile link sequence where some key information about the
> target ISA or processor architecture is not known until link time
> sometimes forces the compiler to use a subset of the actual processors
> ISA rather than take advantage of a specific member feature. The recent
> discussion of the mill belt length is a good example of how important
> this is. This type of compiler approach can encapsulate the specific
> processor variations and make application wide optimizations with
> relative ease.
>
> Switching this around so the compiler is focused on creation code for a
> well defined target rarely is anything more than including a device
> specific header file in the application. (as a side effect eliminating
> the link step)
>
> What's wrong with a single set of sources that defines an application,
> no command line options or linker scripts just an application including
> the definition of the target, files and libraries it needs. Compilation
> is both faster by many factors and there is a simple self contained
> project that can be easily re-created after a decade or more.
That would depend on the size and complexity of the project, right?
I have 192 processors (each with multiple cores) in my current design.
It would be *delightful* if <something> could sort out how best to
allocate resources at run-time instead of my crude metrics.
But, those tools don't exist and aren't likely to any time soon.
As a result, I have to develop solutions that meatware can manage...
and, with existing tools as I don't relish becoming a tool-designer
any more than absolutely necessary for *my* needs -- with little or
no interest in "yours" (out of no malice to "you")
> (The oldest project we have helped customers re-create in the last year
> was archived by the customer in 1988, we have copies of every released
> tool set. Start to recreating an identical HEX file < 2 hours from
> receiving the customer support request email)
I can build any project almost instantly -- as long as I don't
ALSO need to bring up target hardware and/or hardware debugging tools.
(I've been diligent about preserving tools AND development environments)
> The brouhaha about "@" and C is really more about having supporting
> syntax to be able to explain what is desired without needing an
> indirect definition. That is my real argument not that it can't be done.
> Most languages have some way to access the underlying machine, fewer of
> these languages do so in a simple clean way.
Agreed. Software (language designers) seem to think in terms of some
EXISTING environment, not in the CREATION of that environment. This
may be a necessary practical concession: how much effort should go
into supporting bare metal when that metal changes at a rate that
approaches a typical development cycle length?
> Don I am not arguing to create a more complex world but in the area of
> language design why are many tool sets burdened with solutions to the
> computer limitations of 1980?
Walter, you're preaching to the choir! But, in my case, I am
interested in the *applications* and suffer the inadequacies of the
tools. Why are telephones (to this day!) so "uncomfortable" to
hold? Hasn't anyone ever looked at the characteristics of a
human hand and how it might wrap around a "handset"? How much
time should folks ("users") spend thinking about this vs. just
making their phone calls and tolerating the klunky physical
implementation?
My current project involves 4 or 5 different languages. And, concepts
that don't inherently map to traditional language primitives. How much
time do I spend trying to bend my implementation to the languages? Or,
the languages to the implementation?
Do I add keywords to the language to cause the automatic generation
of client- and server-side stubs for procedures and functions that
are intended to be RPC's? Or, do I invent an IDL to use alongside
the targeted languages? And, "manually" create the necessary stubs?
> It is a real eyeopener to spend some time with some of the current crop
> of programmers who are using what many of us would consider a toy
> language to actually achieve some pretty remarkable results. It took me
> a long time to respect what they are doing.
I think there are a few different issues, involved (ignoring egos, NIH, etc.).
First, it seems difficult for those of us with "long histories" to
wrap our heads around how much technology has changed over the course
of our *individual* careers. Recall, for many of us, "software" didn't
exist before we were born -- so, it's not like trying to understand the
advances in PLUMBING since the Roman Era! :>
I have to make a very *conscious* effort not to pack 8 "flags" into a byte.
Or, "reuse" a byte for different purposes by exploiting knowledge of
which parts of the application are running at any given time. I can recall
counting subroutine invocations in an early 8085 project so that I could
map the 7 most common invocations to 7 of the "restart" vectors (thus
allowing a 3 byte "CALL" to be replaced by a one byte "RST" -- just to
save TWO BYTES several times) in order to shrink the size of the binary to
avoid adding another $50 EPROM to the product's cost!
Or, carefully selecting the condition code for a JUMP/CALL (and the
surrounding code's structure) to leverage my knowledge of how often
that condition will be met -- to trim a few clock cycles off that
execution path through the code.
Its also hard to comprehend how much *faster* (and cheaper) the hardware
has become. When I started my current project, I was unduly biased by
my past conceptions of costs and spent a fair bit of effort "skimping"
on the system architecture to save a few dollars here and there. And,
rely on COTS hardware (e.g., PC's) for the "heavy lifting". This has
a profound influence over what you can do and where you can "do" it!
Over time, it became !painfully! obvious that this was me clinging
to an obsolete idea of hardware costs. Why not "PC's (figuratively)
everywhere"? Sure, no need for all those displays, keyboards, UI's, etc.
But, the compute power is cheap enough (if you stay way back from
the state of the art) that its silly to cripple the implementation
by "prematurely optimizing (hardware) cost"!
Likewise, why burden an "average user" with having to understand the
issues involved in "programming"? Why should they have to care about
data types, overflow, roundoff error, etc.? With all that horsepower
available, why not do some of the heavy lifting FOR the user?
length = 12 feet 8.5 inches
width = 8 feet 6 inches
height = 4/3 meters
volume = length * width * height
print "Volume is " (cubic yards) volume " cubic yards."
[I cringe each time I see something done in a runtime that "shouldn't
have to be done", in some other approach to the problem -- e.g., GC]
These same issues have analogs on the development side. Build cycles for
the aforementioned 8085 project took 4 hours (edit, compile, link, burn
EPROMs). I'd get *two* passes at the code -- using a 'scope probe as my
debugger -- in a normal work day. And, had to share THE development system
with 2 other folks who were operating under similar constraints (with scarce
target prototypes!).
Now, its almost easier to "make world" than it is to ensure you've got
ALL the dependencies properly defined in a set of makefiles. And why worry
about incremental backups when its far more convenient to just image the
entire system, daily?
Yet, each of these were skills that were very important when building products
that had to outperform their implementation hardware and development budgets.
How do you rearrange your meatware to address the new "realities"?
Second, how do you square your KNOWLEDGE, gained from years of experience,
of the sorts of errors that are encountered in developing code (regardless
as to how well you've honed your skillset to avoid these) and the LIKELIHOOD
of those errors (in folks with "less capable" skillsets?) with mechanisms
in languages/tools that purport to minimize those? It's like complaining
that you're being FORCED to wear a seatbelt while driving! (is there some
reason you WANT to be injured in a crash?)
Third, how can you ignore the inevitable FUTURE evolution of the product,
tools, *CODEBASE*, etc. given historical evidence? How many products
are flash-in-the-pans and exist as little historical islands without
contributing to their successors and peers?
In my current project, I have to balance many competing design criteria
at different levels in the design. E.g., I wouldn't want to code the OS
in the same sort of language that "users" use for scripting. Nor would
I want future subsystem developers to have to deal with the intricacies
of the OS at anything beyond a certain level of abstraction.
So, I trade-off complexity, capability, "safety", reliability, etc.
as best fitting the capabilities of the (types of) folks who will
*probably* be involved at the different levels in the project's
implementation (a "crack coder" would grimace at the constraints
placed on him by the scripting language; and an "average user"
would be glossy-eyed trying to understand how the OS works!)
I think the same sort of calculus is involved when developing or embracing
any toolset (isn't a product just a different type of tool?).
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2017-03-10 16:42 -0600 |
| Message-ID | <o9va4t$1v2e$1@gioia.aioe.org> |
| In reply to | #25989 |
On 2017-03-10 4:10 PM, Don Y wrote: >> What's wrong with a single set of sources that defines an >> application, no command line options or linker scripts just an >> application including the definition of the target, files and >> libraries it needs. Compilation is both faster by many factors and >> there is a simple self contained project that can be easily >> re-created after a decade or more. > > That would depend on the size and complexity of the project, right? I > have 192 processors (each with multiple cores) in my current design. > It would be *delightful* if <something> could sort out how best to > allocate resources at run-time instead of my crude metrics. > > But, those tools don't exist and aren't likely to any time soon. Most of my time now is working on both tools and ISA's. There has been some really significant changes in both approaches to compiling for heterogeneous parallel environments and execution environments that have hundreds to thousands of processors in them. We are likely sooner than later to see some major shifts in tool sets. I am currently working on a reference design for one of these that has several hundred execution units. w..
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2017-03-10 17:02 -0700 |
| Message-ID | <o9velo$4dc$1@dont-email.me> |
| In reply to | #25991 |
On 3/10/2017 3:42 PM, Walter Banks wrote: > On 2017-03-10 4:10 PM, Don Y wrote: >>> What's wrong with a single set of sources that defines an >>> application, no command line options or linker scripts just an >>> application including the definition of the target, files and >>> libraries it needs. Compilation is both faster by many factors and >>> there is a simple self contained project that can be easily >>> re-created after a decade or more. >> >> That would depend on the size and complexity of the project, right? I >> have 192 processors (each with multiple cores) in my current design. >> It would be *delightful* if <something> could sort out how best to >> allocate resources at run-time instead of my crude metrics. >> >> But, those tools don't exist and aren't likely to any time soon. > > Most of my time now is working on both tools and ISA's. There has been > some really significant changes in both approaches to compiling for > heterogeneous parallel environments and execution environments that have > hundreds to thousands of processors in them. But they are (largely) *static* environments (?). The toolchain doesn't have to decide when to bring another processor on-line... or, when it can retire a running processor and migrate its workload to some OTHER processor, etc. Or, which aspects of an application should be bound to specific processors (nearness of related I/Os) and which aspects should AVOID particular processors (as they were in insecure locations). [Simulations of my first workload scheduler immediately brought every processor online and kept them there! D'uh!] I've found it "trying" to come up with even a suitable set of criteria by which to constrain these choices. E.g., "performance" can be evaluated in a variety of ways: throughput, response time, power consumption, redundancy, etc. Just coming up with *a* set of criteria is a challenge. And, if the user can bias this at run-time, it becomes even more challenging! (perhaps userX might be willing to suffer slower response times for reduced power consumption?) [As I get older, I am encountering more applications where The Right Answer is really elusive and often not available "at compile time". *Or*, even DESIGN TIME! (I'm still at a loss to forumulate a test suite to score the performance of the different speech synthesizer implelmentations I've created -- let alone their "costs"! sqrt(3) = 1.732 is a "better" answer than sqrt(3) = 1.7; but, how do you decide which pronunciation of which utterance is "better" -- and, how to weight the performances of the limitless number of POSSIBLE uterances to come up with a composite score??)] > We are likely sooner than later to see some major shifts in tool sets. > I am currently working on a reference design for one of these that has > several hundred execution units. I'd be interested in seeing what directions you took when you have something to share! And, the assumptions you made along the way. Time for my evening jaunt... cripes, still 90 degrees -- this won't be fun. :<
[toc] | [prev] | [next] | [standalone]
Page 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web