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 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2017-03-07 22:10 -0600 |
| Message-ID | <o9o07h$1g6j$1@gioia.aioe.org> |
| In reply to | #25896 |
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. It is language independent and very easy to add to compilers without changing the basic form of the language. w..
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-03-07 20:35 -0800 |
| Message-ID | <87k280crmt.fsf@nightsong.com> |
| In reply to | #25929 |
Walter Banks <walter@bytecraft.com> writes: > The @ in various forms to tie a physical address to a symbolic variable. Do you mean pointer variables, like *x in C? > It is language independent and very easy to add to compilers without > changing the basic form of the language. True in that the input programs can look about the same as before. But it can change the range of behaviours possible to the programs, making them more flexible (maybe good) but less predictable (maybe bad). So it's a trade-off like lots of other things are.
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2017-03-08 20:43 -0600 |
| Message-ID | <o9qffm$1ri4$1@gioia.aioe.org> |
| In reply to | #25930 |
On 2017-03-07 10:35 PM, Paul Rubin wrote: > Walter Banks <walter@bytecraft.com> writes: >> The @ in various forms to tie a physical address to a symbolic >> variable. > > Do you mean pointer variables, like *x in C? > >> It is language independent and very easy to add to compilers >> without changing the basic form of the language. > > True in that the input programs can look about the same as before. > But it can change the range of behaviours possible to the programs, > making them more flexible (maybe good) but less predictable (maybe > bad). So it's a trade-off like lots of other things are. > I was thinking of something functionally similar to the outcome or constant pointers without the baggage. C pointer to (*x) variables can access specific physical locations is not the same as a simple address assignment to a variable with source level debugging and symbol table support to support that variable at that address. I wasn't specifically thinking of C when I posted the comment. It is a valid comment in many languages. w..
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2017-03-07 23:48 -0700 |
| Message-ID | <o9o9bg$sst$1@dont-email.me> |
| In reply to | #25929 |
On 3/7/2017 9:10 PM, 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. I assume you mean the "address of" operator? I.e., "where is 'foo'?" > It is language independent and very easy to add to compilers without > changing the basic form of the language. But, by itself, it is of little use. So, you know *where* something is. But, if you can't dereference the address (pointer), you can't affect any changes to the environment around it (the pointer/referenced object). [You can't *move* 'foo' though you could play games with pointer arithmetic -- but, still impotent if you can't *do* anything with those computed values!]
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2017-03-08 20:48 -0600 |
| Message-ID | <o9qfpm$1ru7$1@gioia.aioe.org> |
| In reply to | #25931 |
On 2017-03-08 12:48 AM, Don Y wrote: > On 3/7/2017 9:10 PM, 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. > > I assume you mean the "address of" operator? I.e., "where is > 'foo'?" > >> It is language independent and very easy to add to compilers >> without changing the basic form of the language. > > But, by itself, it is of little use. So, you know *where* something > is. But, if you can't dereference the address (pointer), you can't > affect any changes to the environment around it (the > pointer/referenced object). Far less complex. A simple way to declare a variable at a specific physical address. Every other variable attribute remains untouched. It is in the symbol table, debug data and can be referenced like any other variable. You can do address of, set a pointer to it assign and read it. w..
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2017-03-08 21:15 -0700 |
| Message-ID | <o9qknv$cgf$1@dont-email.me> |
| In reply to | #25945 |
On 3/8/2017 7:48 PM, Walter Banks wrote: > On 2017-03-08 12:48 AM, Don Y wrote: >> On 3/7/2017 9:10 PM, 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. >> >> I assume you mean the "address of" operator? I.e., "where is >> 'foo'?" >> >>> It is language independent and very easy to add to compilers >>> without changing the basic form of the language. >> >> But, by itself, it is of little use. So, you know *where* something >> is. But, if you can't dereference the address (pointer), you can't >> affect any changes to the environment around it (the >> pointer/referenced object). > > Far less complex. A simple way to declare a variable at a specific > physical address. Every other variable attribute remains untouched. It > is in the symbol table, debug data and can be referenced like any other > variable. You can do address of, set a pointer to it assign and read it. <frown> I'm not sure I link doing that sort of binding in the source code. It ties it too intimately to the target implementation. I like letting the linkage editor do that work along with the (runtime) loader. What's to stop the developer from specifying a "bad" address? Or, overlooking such a declaration embedded in some source file? At least the linkage editor gives the developer a hint as to where to look for such bindings...
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-03-09 01:33 -0800 |
| Message-ID | <87mvcu6bhh.fsf@nightsong.com> |
| In reply to | #25945 |
Walter Banks <walter@bytecraft.com> writes: > Far less complex. A simple way to declare a variable at a specific > physical address. Every other variable attribute remains untouched. Can I ask why you'd want to do that? If it's to point to a memory mapped i/o register, there are a lot of optimizations that the compiler has to be careful not to make, and it's quite hard to get that right. The best way to implement volatile variable operations in C seems to be to treat them like external function calls. If it's for some other reason like having the value show up at a predictable place in crash dumps, I think we've mostly moved past that style of debugging ;-).
[toc] | [prev] | [next] | [standalone]
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2017-03-09 14:47 +0000 |
| Message-ID | <o9rpu2$5pg$1@reader1.panix.com> |
| In reply to | #25945 |
On 2017-03-09, Walter Banks <walter@bytecraft.com> wrote:
> Far less complex. A simple way to declare a variable at a specific
> physical address.
>
> Every other variable attribute remains untouched. It is in the
> symbol table, debug data and can be referenced like any other
> variable. You can do address of, set a pointer to it assign and read
> it.
I leave the dermination of physical addresses up to the linker. If I
want "real variables" at specific addresses, that belongs in the
linker script (IMO).
--
Grant Edwards grant.b.edwards Yow! I'm using my X-RAY
at VISION to obtain a rare
gmail.com glimpse of the INNER
WORKINGS of this POTATO!!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-09 16:40 +0100 |
| Message-ID | <o9rsrg$88f$1@dont-email.me> |
| In reply to | #25949 |
On 09/03/17 15:47, Grant Edwards wrote: > On 2017-03-09, Walter Banks <walter@bytecraft.com> wrote: > >> Far less complex. A simple way to declare a variable at a specific >> physical address. >> >> Every other variable attribute remains untouched. It is in the >> symbol table, debug data and can be referenced like any other >> variable. You can do address of, set a pointer to it assign and read >> it. > > I leave the dermination of physical addresses up to the linker. If I > want "real variables" at specific addresses, that belongs in the > linker script (IMO). > That's okay, if you don't mind the extra overhead because the compiler can't see the address at compile time, and you are happy to declare your registers twice (once in a header for C, and once in the linker file). Of course, this is rarely an issue in practice because in most cases, people use ready-made chip header files from the device manufacturers, and for most processors and compilers these will use casted pointers to volatiles.
[toc] | [prev] | [next] | [standalone]
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2017-03-09 16:15 +0000 |
| Message-ID | <o9rv3e$5vs$2@reader1.panix.com> |
| In reply to | #25952 |
On 2017-03-09, David Brown <david.brown@hesbynett.no> wrote:
> On 09/03/17 15:47, Grant Edwards wrote:
>> On 2017-03-09, Walter Banks <walter@bytecraft.com> wrote:
>>
>>> Far less complex. A simple way to declare a variable at a specific
>>> physical address.
>>>
>>> Every other variable attribute remains untouched. It is in the
>>> symbol table, debug data and can be referenced like any other
>>> variable. You can do address of, set a pointer to it assign and read
>>> it.
>>
>> I leave the dermination of physical addresses up to the linker. If I
>> want "real variables" at specific addresses, that belongs in the
>> linker script (IMO).
>
> That's okay, if you don't mind the extra overhead because the compiler
> can't see the address at compile time, and you are happy to declare your
> registers twice (once in a header for C, and once in the linker file).
Ah, I thought we were talking about variables, not registers. I think
conflating the two is a grave mistake.
> Of course, this is rarely an issue in practice because in most
> cases, people use ready-made chip header files from the device
> manufacturers, and for most processors and compilers these will use
> casted pointers to volatiles.
Again, that's for accessing HW registers, which (IMO) should not be
conflated with variables. Thinking that HW registes are "normal
variables" is an excellent way to loose a foot.
This, of course, raises the question why you would _need_ to place
_variables_ at specific addresses when it's not for accessing HW
registers. That need seems to me to be rare enough that adding a
language feature to support it is foolish.
--
Grant Edwards grant.b.edwards Yow! Are you mentally here
at at Pizza Hut??
gmail.com
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-09 22:04 +0100 |
| Message-ID | <o9sfs4$r39$1@dont-email.me> |
| In reply to | #25954 |
On 09/03/17 17:15, Grant Edwards wrote: > On 2017-03-09, David Brown <david.brown@hesbynett.no> wrote: >> On 09/03/17 15:47, Grant Edwards wrote: >>> On 2017-03-09, Walter Banks <walter@bytecraft.com> wrote: >>> >>>> Far less complex. A simple way to declare a variable at a specific >>>> physical address. >>>> >>>> Every other variable attribute remains untouched. It is in the >>>> symbol table, debug data and can be referenced like any other >>>> variable. You can do address of, set a pointer to it assign and read >>>> it. >>> >>> I leave the dermination of physical addresses up to the linker. If I >>> want "real variables" at specific addresses, that belongs in the >>> linker script (IMO). >> >> That's okay, if you don't mind the extra overhead because the compiler >> can't see the address at compile time, and you are happy to declare your >> registers twice (once in a header for C, and once in the linker file). > > Ah, I thought we were talking about variables, not registers. I think > conflating the two is a grave mistake. Well, Walter did say "declare a /variable/ at a specific physical address" - but far and away the most common need for something at a fixed address is a hardware register. It is very rare that you would want a normal variable at a fixed address (interfacing between separately compiled and linked code, such as a bootloader and a main program, is about the only case I can think of). For a variable, I agree that a linker script might be a way to handle it. More likely, I'd use C extensions to put the variable in a specific named section, and use linker scripts or commands to put the section at a specific address. > >> Of course, this is rarely an issue in practice because in most >> cases, people use ready-made chip header files from the device >> manufacturers, and for most processors and compilers these will use >> casted pointers to volatiles. > > Again, that's for accessing HW registers, which (IMO) should not be > conflated with variables. Thinking that HW registes are "normal > variables" is an excellent way to loose a foot. > > This, of course, raises the question why you would _need_ to place > _variables_ at specific addresses when it's not for accessing HW > registers. That need seems to me to be rare enough that adding a > language feature to support it is foolish. > Agreed.
[toc] | [prev] | [next] | [standalone]
| From | John Devereux <john@devereux.me.uk> |
|---|---|
| Date | 2017-03-10 07:46 +0000 |
| Message-ID | <87bmt98tgl.fsf@devereux.me.uk> |
| In reply to | #25958 |
David Brown <david.brown@hesbynett.no> writes: > On 09/03/17 17:15, Grant Edwards wrote: >> On 2017-03-09, David Brown <david.brown@hesbynett.no> wrote: >>> On 09/03/17 15:47, Grant Edwards wrote: >>>> On 2017-03-09, Walter Banks <walter@bytecraft.com> wrote: >>>> >>>>> Far less complex. A simple way to declare a variable at a specific >>>>> physical address. >>>>> >>>>> Every other variable attribute remains untouched. It is in the >>>>> symbol table, debug data and can be referenced like any other >>>>> variable. You can do address of, set a pointer to it assign and read >>>>> it. >>>> >>>> I leave the dermination of physical addresses up to the linker. If I >>>> want "real variables" at specific addresses, that belongs in the >>>> linker script (IMO). >>> >>> That's okay, if you don't mind the extra overhead because the compiler >>> can't see the address at compile time, and you are happy to declare your >>> registers twice (once in a header for C, and once in the linker file). >> >> Ah, I thought we were talking about variables, not registers. I think >> conflating the two is a grave mistake. > > Well, Walter did say "declare a /variable/ at a specific physical > address" - but far and away the most common need for something at a > fixed address is a hardware register. It is very rare that you would > want a normal variable at a fixed address (interfacing between > separately compiled and linked code, such as a bootloader and a main > program, is about the only case I can think of). There are the variables normally already declared in linker scripts. __bss_start, __end__ and so forth. I have used them occasionally e.g. to replace or instrument memory management or system initialisation functions. But those too are not "normal". > For a variable, I agree that a linker script might be a way to handle > it. More likely, I'd use C extensions to put the variable in a > specific named section, and use linker scripts or commands to put the > section at a specific address. > >> >>> Of course, this is rarely an issue in practice because in most >>> cases, people use ready-made chip header files from the device >>> manufacturers, and for most processors and compilers these will use >>> casted pointers to volatiles. >> >> Again, that's for accessing HW registers, which (IMO) should not be >> conflated with variables. Thinking that HW registes are "normal >> variables" is an excellent way to loose a foot. >> >> This, of course, raises the question why you would _need_ to place >> _variables_ at specific addresses when it's not for accessing HW >> registers. That need seems to me to be rare enough that adding a >> language feature to support it is foolish. >> > > Agreed. > -- John Devereux
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-10 13:21 +0100 |
| Message-ID | <o9u5i4$e2g$1@dont-email.me> |
| In reply to | #25967 |
On 10/03/17 08:46, John Devereux wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 09/03/17 17:15, Grant Edwards wrote: >>> On 2017-03-09, David Brown <david.brown@hesbynett.no> wrote: >>>> On 09/03/17 15:47, Grant Edwards wrote: >>>>> On 2017-03-09, Walter Banks <walter@bytecraft.com> wrote: >>>>> >>>>>> Far less complex. A simple way to declare a variable at a specific >>>>>> physical address. >>>>>> >>>>>> Every other variable attribute remains untouched. It is in the >>>>>> symbol table, debug data and can be referenced like any other >>>>>> variable. You can do address of, set a pointer to it assign and read >>>>>> it. >>>>> >>>>> I leave the dermination of physical addresses up to the linker. If I >>>>> want "real variables" at specific addresses, that belongs in the >>>>> linker script (IMO). >>>> >>>> That's okay, if you don't mind the extra overhead because the compiler >>>> can't see the address at compile time, and you are happy to declare your >>>> registers twice (once in a header for C, and once in the linker file). >>> >>> Ah, I thought we were talking about variables, not registers. I think >>> conflating the two is a grave mistake. >> >> Well, Walter did say "declare a /variable/ at a specific physical >> address" - but far and away the most common need for something at a >> fixed address is a hardware register. It is very rare that you would >> want a normal variable at a fixed address (interfacing between >> separately compiled and linked code, such as a bootloader and a main >> program, is about the only case I can think of). > > There are the variables normally already declared in linker > scripts. __bss_start, __end__ and so forth. I have used them > occasionally e.g. to replace or instrument memory management or system > initialisation functions. But those too are not "normal". Those are not variables - they are linker-defined addresses, such as marking the start and end of sections. Usually you don't need to use them directly, but they are needed for things like the C startup code. You need them if you are writing your own startup code, or for fixing TI's broken compilers that don't clear uninitialised variables at startup. > >> For a variable, I agree that a linker script might be a way to handle >> it. More likely, I'd use C extensions to put the variable in a >> specific named section, and use linker scripts or commands to put the >> section at a specific address. >> >>> >>>> Of course, this is rarely an issue in practice because in most >>>> cases, people use ready-made chip header files from the device >>>> manufacturers, and for most processors and compilers these will use >>>> casted pointers to volatiles. >>> >>> Again, that's for accessing HW registers, which (IMO) should not be >>> conflated with variables. Thinking that HW registes are "normal >>> variables" is an excellent way to loose a foot. >>> >>> This, of course, raises the question why you would _need_ to place >>> _variables_ at specific addresses when it's not for accessing HW >>> registers. That need seems to me to be rare enough that adding a >>> language feature to support it is foolish. >>> >> >> Agreed. >> >
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2017-03-09 17:57 -0600 |
| Message-ID | <o9spon$fg$2@dont-email.me> |
| In reply to | #25954 |
Grant Edwards wrote: > On 2017-03-09, David Brown <david.brown@hesbynett.no> wrote: >> On 09/03/17 15:47, Grant Edwards wrote: >>> On 2017-03-09, Walter Banks <walter@bytecraft.com> wrote: >>> >>>> Far less complex. A simple way to declare a variable at a specific >>>> physical address. >>>> >>>> Every other variable attribute remains untouched. It is in the >>>> symbol table, debug data and can be referenced like any other >>>> variable. You can do address of, set a pointer to it assign and read >>>> it. >>> >>> I leave the dermination of physical addresses up to the linker. If I >>> want "real variables" at specific addresses, that belongs in the >>> linker script (IMO). >> >> That's okay, if you don't mind the extra overhead because the compiler >> can't see the address at compile time, and you are happy to declare your >> registers twice (once in a header for C, and once in the linker file). > > Ah, I thought we were talking about variables, not registers. I think > conflating the two is a grave mistake. > >> Of course, this is rarely an issue in practice because in most >> cases, people use ready-made chip header files from the device >> manufacturers, and for most processors and compilers these will use >> casted pointers to volatiles. > > Again, that's for accessing HW registers, which (IMO) should not be > conflated with variables. Thinking that HW registes are "normal > variables" is an excellent way to loose a foot. > > This, of course, raises the question why you would _need_ to place > _variables_ at specific addresses when it's not for accessing HW > registers. That need seems to me to be rare enough that adding a > language feature to support it is foolish. > One need only go back to the '80s/'90s to find Paradigm Locate, which took Borland C/C++ objects and fixed certain .SEGMENTS[1] at certain locations for this sort of thing. [1] like .BSS, .CODE, .DATA, whatever... -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Tauno Voipio <tauno.voipio@notused.fi.invalid> |
|---|---|
| Date | 2017-03-10 11:16 +0200 |
| Message-ID | <o9tqnl$b0a$1@dont-email.me> |
| In reply to | #25963 |
On 10.3.17 01:57, Les Cargill wrote: > > One need only go back to the '80s/'90s to find Paradigm Locate, which > took Borland C/C++ objects and fixed certain .SEGMENTS[1] at certain > locations for this sort of thing. > > [1] like .BSS, .CODE, .DATA, whatever... In the Intel x86 processor world the word 'segment' has several conflicting and confusing uses. It seems that the confusion has hit here. Paradigm Locate took a configuration file and a MS-DOS 16 bit .exe file and produced an absolute binary file (in many optional output formats, e.g. Intel hex). The MS-DOS exe file is a segment-relocatable format, segment here meaning a 16 byte aligned adddress base by the hardware segment registers (cs, ds, ss, es). It is possible to combine several program sections (.text, .data, .bss, .CODE, etc...) to groups which are addressed with common segment register contents. Paradigm Locate fixes the segments/groups in the exe file to locations determined in the configuration file, creating an absolute binary file. -- -TV PS. I think that I still have the tools somewhere in the back corner of the shed.
[toc] | [prev] | [next] | [standalone]
| From | Jacob Sparre Andersen <jacob@jacob-sparre.dk> |
|---|---|
| Date | 2017-03-10 20:39 +0100 |
| Message-ID | <878tocsyzv.fsf@adaheads.consafe1.org> |
| In reply to | #25945 |
Walter Banks <walter@bytecraft.com> writes: > Far less complex. A simple way to declare a variable at a specific > physical address. Every other variable attribute remains untouched. Definitely a nice feature for embedded applications. <plug> The Ada variant is: Some_Variable : Some_Type with Address => #16#dead_beef#; </plug> Greetings, Jacob -- "Any politician with a live opposition does not understand how to make proper use of the true instruments of politics."
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-03-10 13:32 -0800 |
| Message-ID | <87pohorf5o.fsf@nightsong.com> |
| In reply to | #25981 |
Jacob Sparre Andersen <jacob@jacob-sparre.dk> writes: > The Ada variant is: > Some_Variable : Some_Type with Address => #16#dead_beef#; Do you need something like a volatile declaration? Does Ada have that?
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2017-03-11 14:58 +0200 |
| Message-ID | <eiiaj8Fq7mvU1@mid.individual.net> |
| In reply to | #25987 |
On 17-03-10 23:32 , Paul Rubin wrote:
> Jacob Sparre Andersen <jacob@jacob-sparre.dk> writes:
>> The Ada variant is:
>> Some_Variable : Some_Type with Address => #16#dead_beef#;
A small nit-pick: as the Ada type System.Address is "private" (that is,
opaque), it is necessary to apply the To_Address function to the integer
literal:
... with Address => To_Address (16#dead_beef#);
> Do you need something like a volatile declaration? Does Ada have that?
Yes. This can be specified by adding "Volatile" to the declaration:
Some_Variable : Some_Type
with Volatile, Address => To_Address (16#dead_beef#);
However, for I/O registers it is often desirable to ensure atomic reads
and writes by using the aspect "Atomic" instead of "Volatile". The
Atomic aspect implies the Volatile aspect, so it is not necessary to
specify both.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-13 13:02 +0100 |
| Message-ID | <oa61j6$2c5$1@dont-email.me> |
| In reply to | #26011 |
On 11/03/17 13:58, Niklas Holsti wrote: > On 17-03-10 23:32 , Paul Rubin wrote: >> Jacob Sparre Andersen <jacob@jacob-sparre.dk> writes: >>> The Ada variant is: >>> Some_Variable : Some_Type with Address => #16#dead_beef#; > > A small nit-pick: as the Ada type System.Address is "private" (that is, > opaque), it is necessary to apply the To_Address function to the integer > literal: > > ... with Address => To_Address (16#dead_beef#); > >> Do you need something like a volatile declaration? Does Ada have that? > > Yes. This can be specified by adding "Volatile" to the declaration: > > Some_Variable : Some_Type > with Volatile, Address => To_Address (16#dead_beef#); > > However, for I/O registers it is often desirable to ensure atomic reads > and writes by using the aspect "Atomic" instead of "Volatile". The > Atomic aspect implies the Volatile aspect, so it is not necessary to > specify both. > Interesting - in C11 and C++11 there is an "atomic" qualifier, but it does not imply "volatile". It is fine for the compiler to optimise away an atomic read or write if it is not volatile - but /if/ it makes the access, it must be done atomically.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-08 10:46 +0100 |
| Message-ID | <o9ojo0$p95$1@dont-email.me> |
| In reply to | #25929 |
On 08/03/17 05:10, 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. > > It is language independent and very easy to add to compilers without > changing the basic form of the language. > Do you mean having a compiler extension for: volatile uint8_t REG @ 0x1234; rather than the standard C: #define REG (*((volatile uint8_t*) 0x1234)) Certainly the "@" syntax is neater, and certainly it is nice if means "REG" turns up in the linker map file and debugging data. But it is hardly a breakthrough, and does not allow anything that cannot be done in normal C syntax just as efficiently (assuming the compiler implementation is sane). Most embedded compilers don't have anything equivalent to the "@" syntax - yet people seem to manage to use them perfectly well for "close to the machine" programming.
[toc] | [prev] | [next] | [standalone]
Page 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web