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 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-03-10 08:17 +0000 |
| Message-ID | <iitwA.85025$ft5.80368@fx16.am4> |
| In reply to | #25962 |
On 09/03/17 23:54, Les Cargill wrote: > Walter Banks wrote: >> On 2017-03-05 5:03 PM, Don Y wrote: >>> A quick/informal/UNSCIENTIFIC poll: >>> >>> What *single* (non-traditional) language feature do you find most >>> valuable in developing code? (and, applicable language if unique to >>> *a* language or class of languages) >> >> The @ in various forms to tie a physical address to a symbolic variable. >> This construct more that any other single thing allows many high level >> languages have the ability broaden the range of potential applications >> from high level to close to the machine. >> > > Hi Walter! No offense, but... > > This is utterly 1) inappropriate and 2) unnecessary. It's a *terrible* extension > to ( I presume C, where I have seen it ). > > Even back on Borland, Microsoft, Tektronix and ... another VAX C compiler 30ish > years ago, you'd use a linker/locater to put specific structures at specific > locations. > > The source code itself doesn't need to know about where variables go[1]. > > Its part of the responsibility of tools that are invoked later > in the build cycle. This is a philosophical difference. 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. In the same vein, in C I dislike having correct code operation being dependent on combinations of command line compiler arguments. >> It is language independent and very easy to add to compilers without >> changing the basic form of the language. >> > > it very nearly destroys the portability of code that uses it... That seems unimportant to me. I cannot think of a reason why you would need to nail down addresses in portable code. Of course "portable" is not a black and white concept! Any examples?
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2017-03-10 11:24 -0700 |
| Message-ID | <o9uqr5$qmh$1@dont-email.me> |
| In reply to | #25968 |
On 3/10/2017 1:17 AM, Tom Gardner wrote: > On 09/03/17 23:54, Les Cargill wrote: >> Walter Banks wrote: >>> On 2017-03-05 5:03 PM, Don Y wrote: >>>> A quick/informal/UNSCIENTIFIC poll: >>>> >>>> What *single* (non-traditional) language feature do you find most >>>> valuable in developing code? (and, applicable language if unique to >>>> *a* language or class of languages) >>> >>> The @ in various forms to tie a physical address to a symbolic variable. >>> This construct more that any other single thing allows many high level >>> languages have the ability broaden the range of potential applications >>> from high level to close to the machine. >>> >> >> Hi Walter! No offense, but... >> >> This is utterly 1) inappropriate and 2) unnecessary. It's a *terrible* extension >> to ( I presume C, where I have seen it ). >> >> Even back on Borland, Microsoft, Tektronix and ... another VAX C compiler 30ish >> years ago, you'd use a linker/locater to put specific structures at specific >> locations. >> >> The source code itself doesn't need to know about where variables go[1]. >> >> Its part of the responsibility of tools that are invoked later >> in the build cycle. > > This is a philosophical difference. > > 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?? > In the same vein, in C I dislike having correct code > operation being dependent on combinations of command > line compiler arguments. There's usually a difference between "correct" and "desired". It's unfortunate when "correct" relies on command line arguments to resolve some "implementation defined behavior" with which the compiler could, otherwise, take liberties. Likewise, if the order and locations at which objects can be bound can arbitrarily be altered and affect operation [These should be eschewed, IMO] (This is an issue on many processors, without concern for the actual I/O's) Of course, there's no way for the tool to know/enforce these constraints other than a suitable note to the future developer! >>> It is language independent and very easy to add to compilers without >>> changing the basic form of the language. >> >> it very nearly destroys the portability of code that uses it... > > That seems unimportant to me. I cannot think of a > reason why you would need to nail down addresses > in portable code. Of course "portable" is not a > black and white concept! Therein lies the rub. Code can be "portable" yet still tied to a particular processor (but a different implementation). E.g., reset_processor()... > Any examples?
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-03-10 19:09 +0000 |
| Message-ID | <aSCwA.83766$8b6.51029@fx19.am4> |
| In reply to | #25975 |
On 10/03/17 18:24, Don Y wrote: > On 3/10/2017 1:17 AM, Tom Gardner wrote: >> On 09/03/17 23:54, Les Cargill wrote: >>> Walter Banks wrote: >>>> On 2017-03-05 5:03 PM, Don Y wrote: >>>>> A quick/informal/UNSCIENTIFIC poll: >>>>> >>>>> What *single* (non-traditional) language feature do you find most >>>>> valuable in developing code? (and, applicable language if unique to >>>>> *a* language or class of languages) >>>> >>>> The @ in various forms to tie a physical address to a symbolic variable. >>>> This construct more that any other single thing allows many high level >>>> languages have the ability broaden the range of potential applications >>>> from high level to close to the machine. >>>> >>> >>> Hi Walter! No offense, but... >>> >>> This is utterly 1) inappropriate and 2) unnecessary. It's a *terrible* extension >>> to ( I presume C, where I have seen it ). >>> >>> Even back on Borland, Microsoft, Tektronix and ... another VAX C compiler 30ish >>> years ago, you'd use a linker/locater to put specific structures at specific >>> locations. >>> >>> The source code itself doesn't need to know about where variables go[1]. >>> >>> Its part of the responsibility of tools that are invoked later >>> in the build cycle. >> >> This is a philosophical difference. >> >> 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. Keep it simple... Source code => as defined in the language standard. If something is tool-specific, then it is not part of the source code. Hence compiler arguments are not part of the source code. Code inspection tools such as browsers, analysers, and compliance checkers work on the source code. That's important. > 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?? > >> In the same vein, in C I dislike having correct code >> operation being dependent on combinations of command >> line compiler arguments. > > There's usually a difference between "correct" and "desired". Not really. If there is a distinction between "desired" and "correct" then I can instantly rewrite the program to be much faster and much smaller. > It's unfortunate when "correct" relies on command line > arguments to resolve some "implementation defined behavior" > with which the compiler could, otherwise, take liberties. That is always the case with C/C++, unless the program uses no separately compiled libraries and turns off all optimisations. Other languages are much better in that regard. > Likewise, if the order and locations at which objects > can be bound can arbitrarily be altered and affect operation That is just one small consideration in this context. > [These should be eschewed, IMO] > > (This is an issue on many processors, without concern for the > actual I/O's) > > Of course, there's no way for the tool to know/enforce these constraints > other than a suitable note to the future developer! And that's undesirable. >>>> It is language independent and very easy to add to compilers without >>>> changing the basic form of the language. >>> >>> it very nearly destroys the portability of code that uses it... >> >> That seems unimportant to me. I cannot think of a >> reason why you would need to nail down addresses >> in portable code. Of course "portable" is not a >> black and white concept! > > Therein lies the rub. Code can be "portable" yet still tied to > a particular processor (but a different implementation). E.g., > reset_processor()... More than just a processor, consider different boards with the same processor. > >> Any examples?
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2017-03-10 12:33 -0700 |
| Message-ID | <o9uuti$a2o$1@dont-email.me> |
| In reply to | #25979 |
On 3/10/2017 12:09 PM, Tom Gardner wrote:
>>>> The source code itself doesn't need to know about where variables go[1].
>>>>
>>>> Its part of the responsibility of tools that are invoked later
>>>> in the build cycle.
>>>
>>> This is a philosophical difference.
>>>
>>> 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.
>
> Keep it simple...
>
> Source code => as defined in the language standard.
So, you're requiring everything "that is important to the correct
operation of the program" to reside *in* that "source code", NOT
handled by the linkage editor (?)
[The linkage editor is outside the scope of the "language standard"]
> If something is tool-specific, then it is not part
> of the source code. Hence compiler arguments are
> not part of the source code.
>
> Code inspection tools such as browsers, analysers,
> and compliance checkers work on the source code.
> That's important.
>
>> 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??
>>
>>> In the same vein, in C I dislike having correct code
>>> operation being dependent on combinations of command
>>> line compiler arguments.
>>
>> There's usually a difference between "correct" and "desired".
>
> Not really.
>
> If there is a distinction between "desired" and
> "correct" then I can instantly rewrite the program
> to be much faster and much smaller.
"Desired" implies some acknowledgement of the application and tools
involved.
Ages ago, it wasn't uncommon to have applications that did
bank switching, overlays, etc. WHERE things resided was
a crucial part of how they would work IN THAT ENVIRONMENT.
E.g., if the trampoline code could ever be mapped *out* of
the address space, then the bank-switching feature came to an
unceremonious halt.
Move the exact same application to a machine with a larger
physical address space, tweek the linker script accordingly
and the code is still "correct".
In the first case, where things are located can also have a marked
impact on size and space ("desired" behavior); by avoiding the
overhead of "distant" references for those things that can (or must)
benefit from the "near" efficiencies.
>> It's unfortunate when "correct" relies on command line
>> arguments to resolve some "implementation defined behavior"
>> with which the compiler could, otherwise, take liberties.
>
> That is always the case with C/C++, unless the program
> uses no separately compiled libraries and turns off
> all optimisations.
No. You can discipline yourself to avoid relying on undocumented
behaviors or "letting the compiler choose" (among possible
interpretations). Of course, writing PORTABLE code under those
constraints is considerably harder (how many folks actually
worry about exceeding the implementation-specific limits for
particular data types? Or, verify that their code will continue
to function properly *if* those limits are considerably higher
than "nominal" from the Standard?)
> Other languages are much better in that regard.
Sure. But that comes at the expense of either requiring more
work of the processor (given that the language isn't tailored
to a particular processor) *or* rendering extra processor
capabilities moot.
[E.g., imagine all ints were 16b and you developed an application
on a 128b processor in <whatever> language. Or, that all ints were
128b and you wanted to run the application on a 16b processor. etc.]
>> Likewise, if the order and locations at which objects
>> can be bound can arbitrarily be altered and affect operation
>
> That is just one small consideration in this context.
Of course! I was merely drawing attention to the fact (which could
easily have been overlooked) that *order* can affect the DESIRED
operation (e.g., performance).
>> [These should be eschewed, IMO]
>>
>> (This is an issue on many processors, without concern for the
>> actual I/O's)
>>
>> Of course, there's no way for the tool to know/enforce these constraints
>> other than a suitable note to the future developer!
>
> And that's undesirable.
But largely unavoidable. Its also undesireable for developers to
write crappy code, fail to document their algorithms/implementations,
fail to include comprehensive test suites, etc. But, there is a
point at which you have to assume "professional" means more than
"paid to do a job".
>>>>> It is language independent and very easy to add to compilers without
>>>>> changing the basic form of the language.
>>>>
>>>> it very nearly destroys the portability of code that uses it...
>>>
>>> That seems unimportant to me. I cannot think of a
>>> reason why you would need to nail down addresses
>>> in portable code. Of course "portable" is not a
>>> black and white concept!
>>
>> Therein lies the rub. Code can be "portable" yet still tied to
>> a particular processor (but a different implementation). E.g.,
>> reset_processor()...
>
> More than just a processor, consider different
> boards with the same processor.
I addressed "different boards" with my "different implementation"
reference. E.g., relocating a UART to a different location in
(memory/IO) space, altering the "sense" of the address lines to
that device (i.e., so consecutive registers are NOT in consecutive
locations *or* are presented in an entirely different order),
scrambling the data lines (e.g., so 0x53 is returned when the character
'5' is received), etc.
The "reset_processor()" reference intending to suggest the fact that
most processors "come out of reset" at a particular (fixed!) point in
their address space, regardless of the rest of the board around them.
[This sort of thing is increasingly common with SoC targets where
many of the design choices (e.g., address map) have been taken away
from the *hardware* designer]
>>> Any examples?
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-03-10 23:25 +0000 |
| Message-ID | <zBGwA.237681$qK5.83287@fx45.am4> |
| In reply to | #25980 |
On 10/03/17 19:33, Don Y wrote:
> On 3/10/2017 12:09 PM, Tom Gardner wrote:
>
>>>>> The source code itself doesn't need to know about where variables go[1].
>>>>>
>>>>> Its part of the responsibility of tools that are invoked later
>>>>> in the build cycle.
>>>>
>>>> This is a philosophical difference.
>>>>
>>>> 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.
>>
>> Keep it simple...
>>
>> Source code => as defined in the language standard.
>
> So, you're requiring everything "that is important to the correct
> operation of the program" to reside *in* that "source code", NOT
> handled by the linkage editor (?)
I'm not requiring anything.
I'm stating what I believe to be desirable, and why.
> [The linkage editor is outside the scope of the "language standard"]
>
>> If something is tool-specific, then it is not part
>> of the source code. Hence compiler arguments are
>> not part of the source code.
>>
>> Code inspection tools such as browsers, analysers,
>> and compliance checkers work on the source code.
>> That's important.
>>
>>> 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??
>>>
>>>> In the same vein, in C I dislike having correct code
>>>> operation being dependent on combinations of command
>>>> line compiler arguments.
>>>
>>> There's usually a difference between "correct" and "desired".
>>
>> Not really.
>>
>> If there is a distinction between "desired" and
>> "correct" then I can instantly rewrite the program
>> to be much faster and much smaller.
>
> "Desired" implies some acknowledgement of the application and tools
> involved.
Que?
> Ages ago, it wasn't uncommon to have applications that did
> bank switching, overlays, etc. WHERE things resided was
> a crucial part of how they would work IN THAT ENVIRONMENT.
> E.g., if the trampoline code could ever be mapped *out* of
> the address space, then the bank-switching feature came to an
> unceremonious halt.
>
> Move the exact same application to a machine with a larger
> physical address space, tweek the linker script accordingly
> and the code is still "correct".
>
> In the first case, where things are located can also have a marked
> impact on size and space ("desired" behavior); by avoiding the
> overhead of "distant" references for those things that can (or must)
> benefit from the "near" efficiencies.
What's your point about future language features?
>>> It's unfortunate when "correct" relies on command line
>>> arguments to resolve some "implementation defined behavior"
>>> with which the compiler could, otherwise, take liberties.
>>
>> That is always the case with C/C++, unless the program
>> uses no separately compiled libraries and turns off
>> all optimisations.
>
> No. You can discipline yourself to avoid relying on undocumented
> behaviors or "letting the compiler choose" (among possible
> interpretations). Of course, writing PORTABLE code under those
> constraints is considerably harder (how many folks actually
> worry about exceeding the implementation-specific limits for
> particular data types? Or, verify that their code will continue
> to function properly *if* those limits are considerably higher
> than "nominal" from the Standard?)
Not in C/C++. The languages remove the ability of any
compiler to determine what is and is not aliased. That
precludes many optimisations unless you assert there
won't be aliasing.
>> Other languages are much better in that regard.
>
> Sure. But that comes at the expense of either requiring more
> work of the processor (given that the language isn't tailored
> to a particular processor) *or* rendering extra processor
> capabilities moot.
>
> [E.g., imagine all ints were 16b and you developed an application
> on a 128b processor in <whatever> language. Or, that all ints were
> 128b and you wanted to run the application on a 16b processor. etc.]
Shrug.
>>> Likewise, if the order and locations at which objects
>>> can be bound can arbitrarily be altered and affect operation
>>
>> That is just one small consideration in this context.
>
> Of course! I was merely drawing attention to the fact (which could
> easily have been overlooked) that *order* can affect the DESIRED
> operation (e.g., performance).
>
>>> [These should be eschewed, IMO]
>>>
>>> (This is an issue on many processors, without concern for the
>>> actual I/O's)
>>>
>>> Of course, there's no way for the tool to know/enforce these constraints
>>> other than a suitable note to the future developer!
>>
>> And that's undesirable.
>
> But largely unavoidable. Its also undesireable for developers to
> write crappy code, fail to document their algorithms/implementations,
> fail to include comprehensive test suites, etc. But, there is a
> point at which you have to assume "professional" means more than
> "paid to do a job".
Nice idea. Meanwhile, back on planet earth...
>>>>>> It is language independent and very easy to add to compilers without
>>>>>> changing the basic form of the language.
>>>>>
>>>>> it very nearly destroys the portability of code that uses it...
>>>>
>>>> That seems unimportant to me. I cannot think of a
>>>> reason why you would need to nail down addresses
>>>> in portable code. Of course "portable" is not a
>>>> black and white concept!
>>>
>>> Therein lies the rub. Code can be "portable" yet still tied to
>>> a particular processor (but a different implementation). E.g.,
>>> reset_processor()...
>>
>> More than just a processor, consider different
>> boards with the same processor.
>
> I addressed "different boards" with my "different implementation"
> reference.
You wrote "... yet still tied to a particular
processor (but a different implementation)..."
i.e a different implementation of a processor.
> E.g., relocating a UART to a different location in
> (memory/IO) space, altering the "sense" of the address lines to
> that device (i.e., so consecutive registers are NOT in consecutive
> locations *or* are presented in an entirely different order),
> scrambling the data lines (e.g., so 0x53 is returned when the character
> '5' is received), etc.
>
> The "reset_processor()" reference intending to suggest the fact that
> most processors "come out of reset" at a particular (fixed!) point in
> their address space, regardless of the rest of the board around them.
>
> [This sort of thing is increasingly common with SoC targets where
> many of the design choices (e.g., address map) have been taken away
> from the *hardware* designer]
Ah. You are choosing a definition of "portable" to coincide
with your contentions. Difficult to argue against that.
>
>>>> Any examples?
>
>
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2017-03-10 20:22 -0500 |
| Message-ID | <4gj6cc5c94jm8ikg4ntkprj8pugasrbqvf@4ax.com> |
| In reply to | #25992 |
On Fri, 10 Mar 2017 23:25:20 +0000, Tom Gardner <spamjunk@blueyonder.co.uk> wrote: >On 10/03/17 19:33, Don Y wrote: >> >> ... You can discipline yourself to avoid relying on undocumented >> behaviors or "letting the compiler choose" (among possible >> interpretations). Of course, writing PORTABLE code under those >> constraints is considerably harder (how many folks actually >> worry about exceeding the implementation-specific limits for >> particular data types? Or, verify that their code will continue >> to function properly *if* those limits are considerably higher >> than "nominal" from the Standard?) > >Not in C/C++. The languages remove the ability of any >compiler to determine what is and is not aliased. That >precludes many optimisations unless you assert there >won't be aliasing. Now that is an overstatement. It is merely excruciatingly difficult for a C/C++ compiler to determine aliasing ... it is _not_ impossible. There are at least 2 compilers which do whole program alias analysis. George
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-03-11 01:32 +0000 |
| Message-ID | <nsIwA.247947$vF2.81484@fx46.am4> |
| In reply to | #25996 |
On 11/03/17 01:22, George Neuner wrote: > On Fri, 10 Mar 2017 23:25:20 +0000, Tom Gardner > <spamjunk@blueyonder.co.uk> wrote: > >> On 10/03/17 19:33, Don Y wrote: >>> >>> ... You can discipline yourself to avoid relying on undocumented >>> behaviors or "letting the compiler choose" (among possible >>> interpretations). Of course, writing PORTABLE code under those >>> constraints is considerably harder (how many folks actually >>> worry about exceeding the implementation-specific limits for >>> particular data types? Or, verify that their code will continue >>> to function properly *if* those limits are considerably higher >>> than "nominal" from the Standard?) >> >> Not in C/C++. The languages remove the ability of any >> compiler to determine what is and is not aliased. That >> precludes many optimisations unless you assert there >> won't be aliasing. > > Now that is an overstatement. It is merely excruciatingly difficult > for a C/C++ compiler to determine aliasing ... it is _not_ impossible. > There are at least 2 compilers which do whole program alias analysis. How do they do that if the program includes a library for which the source is not available, and for which the compiler flags are not known?
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-03-10 18:16 -0800 |
| Message-ID | <878tocr20w.fsf@nightsong.com> |
| In reply to | #25997 |
Tom Gardner <spamjunk@blueyonder.co.uk> writes: >> There are at least 2 compilers which do whole program alias analysis. > > How do they do that if the program includes a library for which the > source is not available, and for which the compiler flags are not > known? "Whole program" means the compiler has all of the source code and can munch it all as a single piece. All kinds of added optimizations are then possible.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-03-11 09:59 +0000 |
| Message-ID | <mUPwA.64577$PU6.12232@fx13.am4> |
| In reply to | #26001 |
On 11/03/17 02:16, Paul Rubin wrote: > Tom Gardner <spamjunk@blueyonder.co.uk> writes: >>> There are at least 2 compilers which do whole program alias analysis. >> >> How do they do that if the program includes a library for which the >> source is not available, and for which the compiler flags are not >> known? > > "Whole program" means the compiler has all of the source code and can > munch it all as a single piece. All kinds of added optimizations are > then possible. I thought you would say that. It means such alias analysis is impossible in many (most?) applications.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-03-11 02:23 -0800 |
| Message-ID | <87wpbwp0x8.fsf@nightsong.com> |
| In reply to | #26005 |
Tom Gardner <spamjunk@blueyonder.co.uk> writes: > It means such alias analysis is impossible in many (most?) > applications. Global alias analysis, yes, but some local analysis is possible.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-03-11 11:13 +0000 |
| Message-ID | <RZQwA.66244$o87.47982@fx21.am4> |
| In reply to | #26008 |
On 11/03/17 10:23, Paul Rubin wrote: > Tom Gardner <spamjunk@blueyonder.co.uk> writes: >> It means such alias analysis is impossible in many (most?) >> applications. > > Global alias analysis, yes, but some local analysis is possible. With the emphasis on "some". Significant difficulties arise with non-primitive data that is shared rather than copied. In the C/C++ /language/, aliasing is a pig resulting in pessimised code. Typically, unlike other languages, you have to resort giving extra assertions to the /tools/; those assertions are the source of quite a few subtle problems.
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2017-03-11 14:28 -0500 |
| Message-ID | <ttj8cc9ta66bo2tbkp02tdefme4rhajvno@4ax.com> |
| In reply to | #26010 |
On Sat, 11 Mar 2017 11:13:53 +0000, Tom Gardner <spamjunk@blueyonder.co.uk> wrote: >On 11/03/17 10:23, Paul Rubin wrote: >> Tom Gardner <spamjunk@blueyonder.co.uk> writes: >>> It means such alias analysis is impossible in many (most?) >>> applications. >> >> Global alias analysis, yes, but some local analysis is possible. > >With the emphasis on "some". Significant difficulties >arise with non-primitive data that is shared rather >than copied. > >In the C/C++ /language/, aliasing is a pig resulting in >pessimised code. Typically, unlike other languages, you >have to resort giving extra assertions to the /tools/; those >assertions are the source of quite a few subtle problems.
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2017-03-11 17:20 -0500 |
| Message-ID | <7ut8cc5skslbauhbn6gjel66h9cng6i41v@4ax.com> |
| In reply to | #26016 |
On Sat, 11 Mar 2017 14:28:01 -0500, George Neuner <gneuner2@comcast.net> wrote: Sorry ... hit the wrong key. George
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2017-03-12 16:26 -0400 |
| Message-ID | <tp7bcctvqbgam21is1la7q0i0oc6ra6522@4ax.com> |
| In reply to | #26010 |
On Sat, 11 Mar 2017 11:13:53 +0000, Tom Gardner <spamjunk@blueyonder.co.uk> wrote: >In the C/C++ /language/, aliasing is a pig resulting in >pessimised code. Typically, unlike other languages, you >have to resort giving extra assertions to the /tools/; those >assertions are the source of quite a few subtle problems. Some problem aliasing is (almost) unavoidable, but the unfortunate truth is that much of the aliasing that *is* a problem in C is self-inflicted by programmers: the idiomatic style that abuses pointers to, e.g., strength reduce address calculations, or "shorten" a long-winded name (e.g., a deep nested struct member), etc. ... that style evolved at a time when compilers did comparatively little optimization and performance of general ALU code was much more sensitive to instruction selection than is true of modern CPUs [e.g., 20 cycles for a multiply vs 2 for an shift, etc.]. Using a modern C compiler, array code written in C using *indices* _can_ achieve, within a few %, similar performance to comparable code written in Fortran. But if the C programmer tries to "optimize" the array code using pointers, it is more likely that the optimizer will be confused and the compiler will produce less than optimal code. [And most programmers are not capable of writing the optimal code without assistance from the compiler.] YMMV, George
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-12 21:46 +0100 |
| Message-ID | <oa4bt1$fqn$1@dont-email.me> |
| In reply to | #26037 |
On 12/03/17 21:26, George Neuner wrote: > On Sat, 11 Mar 2017 11:13:53 +0000, Tom Gardner > <spamjunk@blueyonder.co.uk> wrote: > > >> In the C/C++ /language/, aliasing is a pig resulting in >> pessimised code. Typically, unlike other languages, you >> have to resort giving extra assertions to the /tools/; those >> assertions are the source of quite a few subtle problems. > > Some problem aliasing is (almost) unavoidable, but the unfortunate > truth is that much of the aliasing that *is* a problem in C is > self-inflicted by programmers: the idiomatic style that abuses > pointers to, e.g., strength reduce address calculations, or "shorten" > a long-winded name (e.g., a deep nested struct member), etc. ... that > style evolved at a time when compilers did comparatively little > optimization and performance of general ALU code was much more > sensitive to instruction selection than is true of modern CPUs [e.g., > 20 cycles for a multiply vs 2 for an shift, etc.]. > > > Using a modern C compiler, array code written in C using *indices* > _can_ achieve, within a few %, similar performance to comparable code > written in Fortran. But if the C programmer tries to "optimize" the > array code using pointers, it is more likely that the optimizer will > be confused and the compiler will produce less than optimal code. Good compilers can sometimes follow the source of pointers and other "tweaking", and get the same information as if the programmer had used arrays or structs directly. But yes, it used to be the case that to get the most efficient code, you would do all sorts of "hand optimisation" to your source code in order to help the compiler. Changing array accesses to pointers, using do..while loops instead of for loops, shifts instead of multiplies or divides, etc. And with a good modern compiler, you want to do exactly the opposite! It is nicer to be able to write code as clearly as possible, and let the compiler figure out the details. However, there is still scope for writing better code by giving the compiler more information. A simple example is that careful use of "restrict" can help significantly with aliasing situations. > > [And most programmers are not capable of writing the optimal code > without assistance from the compiler.] Certainly /I/ find a compiler to be invaluable in generating optimal code - or indeed, /any/ code - from my C or C++ source! > > YMMV, > George >
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-03-12 23:15 +0000 |
| Message-ID | <rEkxA.80166$Iy2.46394@fx28.am4> |
| In reply to | #26037 |
On 12/03/17 20:26, George Neuner wrote: > On Sat, 11 Mar 2017 11:13:53 +0000, Tom Gardner > <spamjunk@blueyonder.co.uk> wrote: > > >> In the C/C++ /language/, aliasing is a pig resulting in >> pessimised code. Typically, unlike other languages, you >> have to resort giving extra assertions to the /tools/; those >> assertions are the source of quite a few subtle problems. > > Some problem aliasing is (almost) unavoidable, but the unfortunate > truth is that much of the aliasing that *is* a problem in C is > self-inflicted by programmers: the idiomatic style that abuses > pointers to, e.g., strength reduce address calculations, or "shorten" > a long-winded name (e.g., a deep nested struct member), etc. ... that > style evolved at a time when compilers did comparatively little > optimization and performance of general ALU code was much more > sensitive to instruction selection than is true of modern CPUs [e.g., > 20 cycles for a multiply vs 2 for an shift, etc.]. > > > Using a modern C compiler, array code written in C using *indices* > _can_ achieve, within a few %, similar performance to comparable code > written in Fortran. But if the C programmer tries to "optimize" the > array code using pointers, it is more likely that the optimizer will > be confused and the compiler will produce less than optimal code. > > [And most programmers are not capable of writing the optimal code > without assistance from the compiler.] "You can write Fortran in any language" :) But here's a serious real-world problem... There are people that understand an application domain, and want their computation completed correctly, /with/ /fewest surprises/. A tool which enables /them/ to solve their computational problem is highly beneficial. OTOH, a tool that requires /experts/ to use /correctly/ is bound to be a problem, since such tool experts are very very unlikely to also be the application domain experts. So your manpower is at least doubled, and communication rears its head - even more so when it becomes desirable to include code written by outside people. That's why the necessity of having "language lawyers" to unravel the arcane complexity of modern C/C++ and tools implies that modern C/C++ is part of the problem as much as it is part of the solution. The corollary, to get back to the original question, is that understandability, of the language and of programs written in that language is of key importance.
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2017-03-13 14:14 -0400 |
| Message-ID | <oa6ni5$f9j$1@gioia.aioe.org> |
| In reply to | #26042 |
On 2017-03-12 7:15 PM, Tom Gardner wrote: > That's why the necessity of having "language lawyers" to unravel the > arcane complexity of modern C/C++ and tools implies that modern C/C++ > is part of the problem as much as it is part of the solution. Having been at quite a few WG-14 meetings. C/C++ issues are a combination of some level of compatibility to old tools and dealing with new emerging code generation requirements. Thrown in for good measure was C "Conventional wisdom" (Everyone knows that C does "this") It is hard to advance a language with that type of background. Many things are, "implementation defined", it is difficult to extend the language and many legacy items remained obscure. The open source folks for the most part didn't participate and created their own variation. Conforming test suites have been for the most part have been commercial products that are very useful in creating conforming compilers but the implementation defined and conventional wisdom aspects tends to impact the language portability. C isn't is particularly portable in many applications. w..
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-03-13 18:48 +0000 |
| Message-ID | <5QBxA.76996$9O7.60821@fx22.am4> |
| In reply to | #26052 |
On 13/03/17 18:14, Walter Banks wrote: > On 2017-03-12 7:15 PM, Tom Gardner wrote: >> That's why the necessity of having "language lawyers" to unravel the >> arcane complexity of modern C/C++ and tools implies that modern C/C++ >> is part of the problem as much as it is part of the solution. > > Having been at quite a few WG-14 meetings. C/C++ issues are a > combination of some level of compatibility to old tools and dealing with > new emerging code generation requirements. Thrown in for good measure > was C "Conventional wisdom" (Everyone knows that C does "this") I've heard similar tales from other people; they seemed all too plausible then - and now. > It is hard to advance a language with that type of background. Many > things are, "implementation defined", it is difficult to extend the > language and many legacy items remained obscure. Yes indeed :( Castles built on sand. > The open source folks for the most part didn't participate and created > their own variation. Conforming test suites have been for the most part > have been commercial products that are very useful in creating > conforming compilers but the implementation defined and conventional > wisdom aspects tends to impact the language portability. Oh.... hell. > C isn't is particularly portable in many applications. Agreed. I'm surprised proponents still claim it is portable without adding the necessary caveats. IMNSHO C isn't going to scale well for future massively parallel systems. There will be less awkward languages, but even then it will be interesting to see whether the necessary primitives concepts will be part of the language (e.g. Transputer/Occam, XMOS/xC, Erlang) or library (e.g. Java and Doug Lea's concurrency library). To a great extent I don't care, so long as when I'm using it there are no unpleasant surprises in the tools. (There are enough of those in the applications!)
[toc] | [prev] | [next] | [standalone]
| From | "Brian G. Lucas" <bagel99@gmail.com> |
|---|---|
| Date | 2017-03-13 15:17 -0500 |
| Message-ID | <oa6uj0$fli$1@dont-email.me> |
| In reply to | #26052 |
I have been reading this thread (which has wandered all over the place) because
I'm interested in language design for embedded systems. One nice thing about
no longer being "gainfully employed" is that one has time to experiment. I
have developed my own programming language for implementing operating systems
and drivers. It is a front-end to LLVM and is pretty complete.
<shameless-plug>
Sources for the compiler (written in itself) at
https://github.com/bagel99/esl
Sources for lots of drivers and network stuff at
https://github.com/bagel99/blocks-os
</shameless-plug>
Here's how I approached the device driver question: at what hardware address is
the device? First defining the device register layout:
type UartRegs:
{ dr:
{ data: _uint8; // .00-07
fe: boolean; // .08
pe: boolean; // .09
be: boolean; // .10
oe: boolean; // .11
}: packed, lsb, bits(32), in, out;
lcrh:
{ brk: boolean; // .00
par: (NONE,ODD,_,EVEN); // .01-02
stop: (S1,S2); // .03
fen: boolean; // .04
wlen: (B5,B6,B7,B8); // .05-06
sps: boolean; // .07
}: packed, lsb, bits(32), out;
...
};
// packed - squeeze all the bits into the smallest width
// lsb - the fields start at the least significant bit
// bits[32] - extend the size to 32 bits with zeros
// out - like volatile, but side effects only happen on writes
// in - like volatile, but side effects only happon on reads
Then define the hardware address one of three ways:
var uart0: UartRegs: external(0x4000_0000);
// uart0 address is 0x40000000
var uart1: UartRegs: external("UART1");
// linker supplies address constant UART1=xxx
const uart2: @UartRegs = 0x4000_2000;
// define a constant pointer to the device
And assigning device bits without using masks:
uart0.lcrh = {.brk=false, .par=NONE, .stop=S1, .wlen=B8 };
// fields not specified take the zero value
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2017-03-13 23:17 +0200 |
| Message-ID | <eioginF36ilU1@mid.individual.net> |
| In reply to | #26054 |
On 17-03-13 22:17 , Brian G. Lucas wrote:
> I have been reading this thread (which has wandered all over the place) because
> I'm interested in language design for embedded systems. One nice thing about
> no longer being "gainfully employed" is that one has time to experiment. I
> have developed my own programming language for implementing operating systems
> and drivers. It is a front-end to LLVM and is pretty complete.
>
> <shameless-plug>
> Sources for the compiler (written in itself) at
> https://github.com/bagel99/esl
> Sources for lots of drivers and network stuff at
> https://github.com/bagel99/blocks-os
> </shameless-plug>
Hm. In the spirit of language ecumenics and comparison, I translate your
example to Ada, below. I try to use your identifiers as such, although
Ada convention would use Title_Style capitalisation.
> Here's how I approached the device driver question: at what hardware address is
> the device? First defining the device register layout:
>
> type UartRegs:
> { dr:
> { data: _uint8; // .00-07
> fe: boolean; // .08
> pe: boolean; // .09
> be: boolean; // .10
> oe: boolean; // .11
> }: packed, lsb, bits(32), in, out;
> lcrh:
> { brk: boolean; // .00
> par: (NONE,ODD,_,EVEN); // .01-02
> stop: (S1,S2); // .03
> fen: boolean; // .04
> wlen: (B5,B6,B7,B8); // .05-06
> sps: boolean; // .07
> }: packed, lsb, bits(32), out;
> ...
> };
-- The "dr" register type:
type dr_t is record
data : interfaces.unsigned_8;
fe : boolean;
pe : boolean;
be : boolean;
oe : boolean;
end record
with volatile, size => 32, bit_order => system.low_order_first;
--
-- I would not usually make the _type_ volatile, because
-- that could slow down operations on all variables of
-- the type, even if they are not mapped to control
-- registers. I would mark as volatile (or atomic) only
-- the variables mapped to registers.
-- Its structure on the bit level (I could also have said
-- just "pack", but this is safer and more explicit):
for dr_t use record
data at 0 range 0 .. 7;
fe at 0 range 8 .. 8;
pe at 0 range 9 .. 9;
be at 0 range 10 .. 10;
oe at 0 range 11 .. 11;
end record
-- The "lchr" register type(s):
type par_t is (NONE, ODD, EVEN);
for par_t use (NONE => 0, ODD => 1, EVEN => 3);
type stop_t is (S1, S2);
-- Or it could be:
-- type stop_t is range 1 .. 2;
-- for compilers that support offset encoding.
type wlen_t is (B5, B6, B7, B8);
-- Or it could be:
-- type wlen_t is range 5 .. 8;
-- for compilers that support offset encoding.
type lcrh_t is record
brk : boolean;
par : par_t;
stop : stop_t;
fen : boolean;
wlen : wlen_t;
sps : boolean;
end record
with volatile, size => 32, bit_order => system.low_order_first;
for lchr_t use record
brk at 0 range 0 .. 0;
par at 0 range 1 .. 2;
stop at 0 range 3 .. 3;
fen at 0 range 4 .. 4;
wlen at 0 range 5 .. 6;
sps at 0 range 7 .. 7;
end record;
-- The combination:
type UartRegs is record
dr : dr_t;
lchr : lchr_t;
end record
with pack;
-- The "pack" aspect corresponds to your "packed".
-- Of course we could also give a bit-level lay-out
-- specification for UartRegs, as above.
> Then define the hardware address one of three ways:
>
> var uart0: UartRegs: external(0x4000_0000);
> // uart0 address is 0x40000000
uart0 : UartRegs
with address => to_address (16#4000_0000#);
> var uart1: UartRegs: external("UART1");
> // linker supplies address constant UART1=xxx
uart1 : UartRegs with link_name => "UART1";
> const uart2: @UartRegs = 0x4000_2000;
> // define a constant pointer to the device
type UartRegs_ref is access all UartRegs;
uart2 : constant UartRegs_ref :=
to_pointer (to_address (16#4000_2000#));
-- (I omitted some boilerplate here; the function
-- "to_pointer" is a generic one, and must be
-- instantiated for each necessary pointer type.)
> And assigning device bits without using masks:
>
> uart0.lcrh = {.brk=false, .par=NONE, .stop=S1, .wlen=B8 };
> // fields not specified take the zero value
uart0.lchr := (
brk => false, par => NONE, stop => S1, wlen => B8,
others => false);
-- All fields must be listed, or an "others" can be used.
-- Bit of luck here that all the "others" fields are
-- of the same type (boolean) which is required for the
-- "others" to be legal.
In summary, the only semantic difference is that the Ada "volatile"
aspect cannot be separated into "in" and "out" parts, as in your language.
Syntactically Ada needs more lines, because enumerations and sub-records
must be defined as types. Does your language use "structural
equivalence" for types? That is, if one register field is defined as the
enumeration (A, B, C), and another register field is also defined as the
enumeration (A, B, C), are these fields of the same type?
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
[toc] | [prev] | [next] | [standalone]
Page 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web