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 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2017-03-08 20:33 -0600 |
| Message-ID | <o9qeue$1r0a$1@gioia.aioe.org> |
| In reply to | #25933 |
On 2017-03-08 3:46 AM, David Brown wrote: > 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. I saw it as an abstract question. My comment was a clean simple way to directly interface to the machine completely separate from the language proper. Developers in a surprising number of languages have found some round about way to accomplish this demonstrating its need. The C constant pointer Kludge although functionally similar generally misses out having proper symbolic debugging support. uint8_t REG @ 0x1234; is just as viable a declaration without the volatile. Many if not most non open source compilers for embedded systems some form @. The concept as I have found is just as useful in many languages I have used. w..
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-09 11:08 +0100 |
| Message-ID | <o9r9dl$3f6$1@dont-email.me> |
| In reply to | #25943 |
On 09/03/17 03:33, Walter Banks wrote: > On 2017-03-08 3:46 AM, David Brown wrote: >> 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. > > > I saw it as an abstract question. My comment was a clean simple way to > directly interface to the machine completely separate from the language > proper. Developers in a surprising number of languages have found some > round about way to accomplish this demonstrating its need. > > The C constant pointer Kludge although functionally similar generally > misses out having proper symbolic debugging support. Far and away the most common reason to need variables at specific addresses is to access hardware registers. In such cases, the C "constant pointer kludge" is perfectly good, and decent compilers will generate solid code for it. (Often they will be able to generate more optimal code than if you use alternatives such as symbols in assembly or linker-defined addresses.) It is true that the variable is not a normal variable available for symbolic debugging - but you don't /want/ it to be available in the debugger like a normal variable, because it is /not/ a normal variable. With normal variables, you want to be able to hover your mouse over the variable "nextCharacter" in your code and have the debugger show you the value. But you absolutely do not want that to happen when you hover over "UART_DATA_REG", because reading it could trigger a move from a FIFO, setting a CTS signal, or whatever. An IDE for embedded development will usually have a window for "registers" or "IO registers" - /that/ is where you want to see this sort of thing, because that window and the software behind it should be aware of details about what can be read or written in different ways. > > uint8_t REG @ 0x1234; is just as viable a declaration without the volatile. But what use is that? > > Many if not most non open source compilers for embedded systems some > form @. No, they don't. /Some/ have a type of "@" syntax. /Some/ have other extensions to declare something as an I/O register at a fixed address. And other compilers have nothing of the sort, but rely on standard¹ C and/or linker scripts. The "@" form is most common in compilers for brain-dead 8-bit CISC architectures, which are rapidly becoming a thing of the past. With more modern cpu architectures, it is usually more efficient to access peripherals as structs with a base address, rather than a series of explicit addresses. In many compliers, the "@" syntax or other special I/O register syntax is tightly tied to fundamental types - you can use it for uint8_t, uint16_t and perhaps uint32_t, but not for "struct uart_t". It is certainly possible that compilers for modern cpus /could/ have a "@" syntax that works on structs, arrays, and other types. But there is /nothing/ that could be done with that syntax that could not also be done perfectly well with the "constant pointer kludge". And since these definitions are almost always buried inside an automatically generated chip-specific header file, "ugly" is of little relevance. ¹ I say "standard C", with the proviso that the C standards say that "what constitutes a volatile access is implementation dependent". > > The concept as I have found is just as useful in many languages I have > used. > Other languages that don't have something equivalent to the "C constant pointer kludge" may need an extension of some sort to efficiently access I/O registers. But which languages would that be, and are they actually used in embedded programming?
[toc] | [prev] | [next] | [standalone]
| From | Britt <britt.snodgrass@gmail.com> |
|---|---|
| Date | 2017-03-09 07:04 -0800 |
| Message-ID | <77e6e550-dd0c-4cb8-9bed-09d83b40b823@googlegroups.com> |
| In reply to | #25948 |
On Thursday, March 9, 2017 at 5:08:35 AM UTC-5, David Brown wrote:
> Other languages that don't have something equivalent to the "C constant
> pointer kludge" may need an extension of some sort to efficiently access
> I/O registers. But which languages would that be, and are they actually
> used in embedded programming?
In Ada (actually used in embedded programming), it is always as simple as this:
Some_IO_Reg : Some_IO_Reg_Type; -- type defined as appropriate
for Some_IO_Reg'Address use 16#0000_0800#; -- or whatever value is needed
so no kludge is required anywhere. Register types are easily and clearly described using bit level record representation clauses. In fact, pointers are almost never needed (and that is a very good thing).
-Britt
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-09 16:36 +0100 |
| Message-ID | <o9rsl6$7g4$1@dont-email.me> |
| In reply to | #25950 |
On 09/03/17 16:04, Britt wrote: > On Thursday, March 9, 2017 at 5:08:35 AM UTC-5, David Brown wrote: > >> Other languages that don't have something equivalent to the "C constant >> pointer kludge" may need an extension of some sort to efficiently access >> I/O registers. But which languages would that be, and are they actually >> used in embedded programming? > > In Ada (actually used in embedded programming), it is always as simple as this: > > Some_IO_Reg : Some_IO_Reg_Type; -- type defined as appropriate > > for Some_IO_Reg'Address use 16#0000_0800#; -- or whatever value is needed > > so no kludge is required anywhere. Register types are easily and > clearly described using bit level record representation clauses. In > fact, pointers are almost never needed (and that is a very good thing). > I only know a little Ada, and haven't used it for anything serious, but I remember having seen something like that. So no need for an "@" extension there. I don't feel there is much wrong with the standard C method of making constant pointers such as I described. Walter called it a "kludge" - I specifically use quotation marks because I don't see it as a kludge. The only problem I see is that it defines the names as macros which don't obey scope.
[toc] | [prev] | [next] | [standalone]
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2017-03-09 16:11 +0000 |
| Message-ID | <o9ruro$5vs$1@reader1.panix.com> |
| In reply to | #25951 |
On 2017-03-09, David Brown <david.brown@hesbynett.no> wrote:
> I don't feel there is much wrong with the standard C method of making
> constant pointers such as I described. Walter called it a "kludge" - I
> specifically use quotation marks because I don't see it as a kludge.
> The only problem I see is that it defines the names as macros which
> don't obey scope.
Agreed. Apart from the scope issue, I don't see any problems with the
standard C "kludge".
--
Grant Edwards grant.b.edwards Yow! Do you have exactly
at what I want in a plaid
gmail.com poindexter bar bat??
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2017-03-09 12:06 -0600 |
| Message-ID | <o9s5jf$i6c$1@gioia.aioe.org> |
| In reply to | #25951 |
On 2017-03-09 9:36 AM, David Brown wrote: > Walter called it a "kludge" - I specifically use quotation marks > because I don't see it as a kludge. The only problem I see is that it > defines the names as macros which don't obey scope. I referred it it as a kludge because it declares a variable as a pointer to an address expecting the compiler to optimize it as an address reference and in many compilers/linkers fails to provide the source level debugging support I would like. I wasn't using "kludge" as an insult but as a less than optimal way of describing what is desired. w..
[toc] | [prev] | [next] | [standalone]
| From | Hans-Bernhard Bröker <HBBroeker@t-online.de> |
|---|---|
| Date | 2017-03-09 19:26 +0100 |
| Message-ID | <eidl42Fsgk3U1@mid.dfncis.de> |
| In reply to | #25951 |
Am 09.03.2017 um 16:36 schrieb David Brown: > I don't feel there is much wrong with the standard C method of making > constant pointers such as I described. Well, here is one detail: it's not entirely standard, because it involves the explicitly implementation-defined conversion of an integer constant to a pointer. I.e. in principle the same construct on two different C compilers could yield different results. > The only problem I see is that it defines the names as macros which > don't obey scope. And given the fact that a hardware register, pretty much by definition, _is_ an entirely scope-less, global object, that's not much of an obstacle, either. If one were truly worried about scope, it would always be possible to encapsulate all accesses in an accessor module --- at the likely cost of at least one function call overhead.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-09 22:08 +0100 |
| Message-ID | <o9sg3q$s86$1@dont-email.me> |
| In reply to | #25956 |
On 09/03/17 19:26, Hans-Bernhard Bröker wrote: > Am 09.03.2017 um 16:36 schrieb David Brown: > >> I don't feel there is much wrong with the standard C method of making >> constant pointers such as I described. > > Well, here is one detail: it's not entirely standard, because it > involves the explicitly implementation-defined conversion of an integer > constant to a pointer. I.e. in principle the same construct on two > different C compilers could yield different results. > That's true (and I have been a bit imprecision about distinguishing between "standard C method" meaning "the method used by most people in C" and "standard C" meaning "fully defined by the C standards"). But any "sane" compiler will, in practice, implement these things in the same way - so it is a much more portable solution than an @ extension. >> The only problem I see is that it defines the names as macros which >> don't obey scope. > > And given the fact that a hardware register, pretty much by definition, > _is_ an entirely scope-less, global object, that's not much of an > obstacle, either. If one were truly worried about scope, it would > always be possible to encapsulate all accesses in an accessor module --- > at the likely cost of at least one function call overhead. Yes.
[toc] | [prev] | [next] | [standalone]
| From | Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> |
|---|---|
| Date | 2017-03-09 19:04 +0000 |
| Message-ID | <o9s8vr$n0o$1@dont-email.me> |
| In reply to | #25950 |
On 2017-03-09, Britt <britt.snodgrass@gmail.com> wrote: > On Thursday, March 9, 2017 at 5:08:35 AM UTC-5, David Brown wrote: > >> Other languages that don't have something equivalent to the "C constant >> pointer kludge" may need an extension of some sort to efficiently access >> I/O registers. But which languages would that be, and are they actually >> used in embedded programming? > > In Ada (actually used in embedded programming), it is always as simple as this: > > Some_IO_Reg : Some_IO_Reg_Type; -- type defined as appropriate > > for Some_IO_Reg'Address use 16#0000_0800#; -- or whatever value is needed > > so no kludge is required anywhere. Register types are easily and clearly > described using bit level record representation clauses. In fact, pointers > are almost never needed (and that is a very good thing). > Since Don asked for new useful features, there's new Ada functionality in this area currently working it's way through the Ada standards committee and currently looks like it might be ratified for the next version of Ada. Representing register bitfields as Ada bitfields currently has one major limitation in that you cannot directly update multiple register bitfields in Ada in a single R-M-W sequence without either using a temporary variable or resorting to C style bitmasks. In my original proposal, which is currently working it's way through the ARG, you would be able to specify multiple bitfields to be updated as part of a single assignment statement which would be translated into a single R-M-W sequence by the compiler. No C style bitmasks or temporary variables required. See http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0127-1.txt?rev=1.10&raw=N for details. If the formal language at the beginning puts you off, then skip down to the appendix section which contains my original proposal. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2017-03-09 15:34 -0700 |
| Message-ID | <o9sl57$evk$1@dont-email.me> |
| In reply to | #25957 |
On 3/9/2017 12:04 PM, Simon Clubley wrote:
> On 2017-03-09, Britt <britt.snodgrass@gmail.com> wrote:
>> On Thursday, March 9, 2017 at 5:08:35 AM UTC-5, David Brown wrote:
>>
>>> Other languages that don't have something equivalent to the "C constant
>>> pointer kludge" may need an extension of some sort to efficiently access
>>> I/O registers. But which languages would that be, and are they actually
>>> used in embedded programming?
>>
>> In Ada (actually used in embedded programming), it is always as simple as this:
>>
>> Some_IO_Reg : Some_IO_Reg_Type; -- type defined as appropriate
>>
>> for Some_IO_Reg'Address use 16#0000_0800#; -- or whatever value is needed
>>
>> so no kludge is required anywhere. Register types are easily and clearly
>> described using bit level record representation clauses. In fact, pointers
>> are almost never needed (and that is a very good thing).
>
> Since Don asked for new useful features, there's new Ada functionality
> in this area currently working it's way through the Ada standards
> committee and currently looks like it might be ratified for the next
> version of Ada.
I use "new" only in the sense of something that was *new* (for you)
when you were exposed to it. My interest is more on *value* than
newness and/or novelty.
E.g., replacing the i4004's JMS/BBL with the i8008's CALL/RET was
a yawn... stack depth was still severely constrained (though doubled!).
OTOH, the 8080's addition of PUSH/POP was *hugely* (YUGELY?) valuable
as it made a pronounced difference in what was suddenly "realistic" in
terms of managing application implementation complexity.
"You mean I can push *any* register (pair)? And, as many as I want
ALONG WITH subroutine invocations??"
> Representing register bitfields as Ada bitfields currently has one
> major limitation in that you cannot directly update multiple
> register bitfields in Ada in a single R-M-W sequence without either
> using a temporary variable or resorting to C style bitmasks.
But, does that really buy you much -- unless you are sorely resource
(time/space) constrained? (Granted, this can be seen as a different
case of the PUSH/POP issue, above -- e.g., building a synchronization
primitive to wrap a set of *discrete* accesses, etc.)
[One of my gripes about Ada is that it's too "big" of a language]
One can always come up with new "features" that can have some merit
in some cases. What I'm looking for are the "wow" moments when some
feature made a radical difference in how you approach(ed) problems.
Like moving from the 8's JMS to the 11's JSR opening the door for
recursive routines.
Or, having direct access to the "status word" allowing a multitasking
executive to restore the *entire* machine state, etc.
> In my original proposal, which is currently working it's way through
> the ARG, you would be able to specify multiple bitfields to be updated
> as part of a single assignment statement which would be translated into
> a single R-M-W sequence by the compiler. No C style bitmasks or
> temporary variables required.
>
> See http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0127-1.txt?rev=1.10&raw=N
> for details. If the formal language at the beginning puts you off, then
> skip down to the appendix section which contains my original proposal.
This looks like you are trying to tackle atomic updates on a larger (wider)
scale than just bitfields (?).
If not, then you seem to be creating a huge bias (in the mind of the developer)
to opt for a "set of bitfields" representation of certain structures that
might inadvertently lead to a sort of premature optimization ("Damn! If
I let the individual fields grow 'just a tad', then I lose the value of
this feature, here...")
[Disclaimer: I've not looked at Ada for more than 15 years... :< ]
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2017-03-09 15:40 -0700 |
| Message-ID | <o9slf4$evk$2@dont-email.me> |
| In reply to | #25960 |
On 3/9/2017 3:34 PM, Don Y wrote: >> See >> http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0127-1.txt?rev=1.10&raw=N >> for details. If the formal language at the beginning puts you off, then >> skip down to the appendix section which contains my original proposal. > > This looks like you are trying to tackle atomic updates on a larger (wider) > scale than just bitfields (?). Sorry, in concentrating on the "meat" of the examples, I glossed over the _aggregates_ reference. <:-(
[toc] | [prev] | [next] | [standalone]
| From | Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> |
|---|---|
| Date | 2017-03-10 14:19 +0000 |
| Message-ID | <o9ucm3$1fj$1@dont-email.me> |
| In reply to | #25960 |
On 2017-03-09, Don Y <blockedofcourse@foo.invalid> wrote: > On 3/9/2017 12:04 PM, Simon Clubley wrote: >> Representing register bitfields as Ada bitfields currently has one >> major limitation in that you cannot directly update multiple >> register bitfields in Ada in a single R-M-W sequence without either >> using a temporary variable or resorting to C style bitmasks. > > But, does that really buy you much -- unless you are sorely resource > (time/space) constrained? (Granted, this can be seen as a different > case of the PUSH/POP issue, above -- e.g., building a synchronization > primitive to wrap a set of *discrete* accesses, etc.) > Some things you get with being able to update multiple fields within one assignment statement without having to use bitmasks: It allows you to update multiple fields in a device register as part of a single R-M-W sequence without having to use bitmasks or temporary variables. It allows the compiler to do additional error checks on what you are trying to do, which it can't do if you are changing what appears to the compiler as an opaque integer. It makes the code more readable and more robust. > > One can always come up with new "features" that can have some merit > in some cases. What I'm looking for are the "wow" moments when some > feature made a radical difference in how you approach(ed) problems. > Understood. Sometimes Don, the problem with these discussions is that you don't provide sufficient guidelines on what you are looking for so people have to guess and as such quite often don't give you the kinds of answers you are looking for. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2017-03-10 11:10 -0700 |
| Message-ID | <o9uq1n$nrd$1@dont-email.me> |
| In reply to | #25973 |
On 3/10/2017 7:19 AM, Simon Clubley wrote:
>> One can always come up with new "features" that can have some merit
>> in some cases. What I'm looking for are the "wow" moments when some
>> feature made a radical difference in how you approach(ed) problems.
>
> Understood. Sometimes Don, the problem with these discussions is that
> you don't provide sufficient guidelines on what you are looking for
> so people have to guess and as such quite often don't give you the
> kinds of answers you are looking for.
What *I'm* looking for isn't important. I'm interested in hearing
what *others* "looked for" (by way of "language features") and
how they've rationalized their "value".
E.g., some folks look for "features" that make debugging easier;
some that make the application "terser"; some that make it more
robust; etc.
If I was interested in which language features...
... facilitate debugging...
... make for terser applications...
... enhance the durability of the application...
etc., then I'd have asked those *specific* questions, right?
By asking in more abstract terms ("valuable"), I let others
decide what is important (in terms of criteria) AND, then,
what features they deem "best suiting" THAT particular goal.
My followup comments are merely to draw out more detail and
"backup" for how they came to that conclusion, not as an
assessment *of* their conclusion ("what's your favorite
color, and why?")
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2017-03-10 11:49 -0700 |
| Message-ID | <o9usag$i2$1@dont-email.me> |
| In reply to | #25974 |
On 3/10/2017 11:10 AM, Don Y wrote:
> By asking in more abstract terms ("valuable"), I let others
> decide what is important (in terms of criteria) AND, then,
> what features they deem "best suiting" THAT particular goal.
>
> My followup comments are merely to draw out more detail and
> "backup" for how they came to that conclusion, not as an
> assessment *of* their conclusion ("what's your favorite
> color, and why?")
E.g., one reply that I received (elsewhere) resulted in a
lengthy discussion as to deficiencies in "list" implementations;
why lists were valuable to some types of use (application) but
problematic for others (in the discussion) because of implementation
shortcomings.
This sort of back-and-forth refines the "value" that is being
placed (or not!) on the "feature" in the minds of the different
folks discussing it.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2017-03-09 18:00 -0600 |
| Message-ID | <o9spuk$1d5$1@dont-email.me> |
| In reply to | #25943 |
Walter Banks wrote: > On 2017-03-08 3:46 AM, David Brown wrote: >> 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. > > > I saw it as an abstract question. My comment was a clean simple way to > directly interface to the machine completely separate from the language > proper. Developers in a surprising number of languages have found some > round about way to accomplish this demonstrating its need. > > The C constant pointer Kludge although functionally similar generally > misses out having proper symbolic debugging support. > That's kind of not what const is for in 'C', although it's a way. > uint8_t REG @ 0x1234; is just as viable a declaration without > the volatile. > So what you really want is for the toolchain to assign these values at address fixup time - in the linker or later. You use #pragmas to assign a block in a seperate segment, then the linker fixes it up for you. That way if he FPGA decodes at a different address for different projects, you're covered and don't have to maintain seperate copies of that source code. > Many if not most non open source compilers for embedded systems some > form @. > > The concept as I have found is just as useful in many languages I have > used. > > w.. > > - Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2017-03-09 17:54 -0600 |
| Message-ID | <o9spjo$fg$1@dont-email.me> |
| In reply to | #25929 |
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. [1] think of a shared module that's a "driver" for an FPGA and is common to three projects, but all three targets have a different base addresses for said FPGA. Now, all that being said - for some kinds of debugging, it's darn handy to have the same variables at the same locations. It's just better done in the linker or with a locater. > 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... > w.. > > -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2017-03-09 18:54 -0600 |
| Message-ID | <o9stfm$1sgi$1@gioia.aioe.org> |
| In reply to | #25962 |
On 2017-03-09 5:54 PM, Les Cargill wrote: > > Hi Walter! No offense, but... > > This is utterly 1) inappropriate and 2) unnecessary. It's a > *terrible* extension. Maybe "terrible" but a lot cleaner than a pointer to constant that is expected to be optimized by a compiler to a simple load store. > it very nearly destroys the portability of code that uses it... and I assume that constant pointer doesn't destroy portability. C specifically rarely has portable applications. Better that applications be completely contained and either have include files to define application specific information. The original role of linkers was to be able to compiler large programs on small computers. The current state of especially open source compilers is an awful lot of duplication between the compiler and linkers in the tool sets. Better that a lot of the linker information be processed much earlier to develop compile strategies. This is even more true in some of the more interesting ISA that are currently being developed. I am working on a project that can have hundreds or potentially thousands of heterogeneous processors being compiled to from a single application. Address setting from application/processor specific header files allows compilers to be written with far more flexibility and that is far less computationally intensive. w..
[toc] | [prev] | [next] | [standalone]
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2017-03-10 04:07 +0000 |
| Message-ID | <o9t8ps$ga1$1@reader1.panix.com> |
| In reply to | #25965 |
On 2017-03-10, Walter Banks <walter@bytecraft.com> wrote: > On 2017-03-09 5:54 PM, Les Cargill wrote: >> >> Hi Walter! No offense, but... >> >> This is utterly 1) inappropriate and 2) unnecessary. It's a >> *terrible* extension. > > Maybe "terrible" but a lot cleaner than a pointer to constant that is > expected to be optimized by a compiler to a simple load store. Huh? The common method for accessing memory-mapped registers in C that's been discussed doesn't involve a "pointer to a constant". -- Grant
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2017-03-10 08:07 -0600 |
| Message-ID | <o9uc01$4tp$1@gioia.aioe.org> |
| In reply to | #25966 |
On 2017-03-09 10:07 PM, Grant Edwards wrote: > Huh? The common method for accessing memory-mapped registers in C > that's been discussed doesn't involve a "pointer to a constant". Absolutely true it is a constant pointer. w..
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-10 13:59 +0100 |
| Message-ID | <o9u7qa$l5c$1@dont-email.me> |
| In reply to | #25965 |
On 10/03/17 01:54, Walter Banks wrote: > On 2017-03-09 5:54 PM, Les Cargill wrote: >> >> Hi Walter! No offense, but... >> >> This is utterly 1) inappropriate and 2) unnecessary. It's a >> *terrible* extension. > > Maybe "terrible" but a lot cleaner than a pointer to constant that is > expected to be optimized by a compiler to a simple load store. First, no one is using a "pointer to a constant" - they are using a constant pointer to a volatile: #define REG (*((volatile uint8_t*) 0x1234)) Secondly, the syntax here is not particularly bad, and it should be clear to anyone who understands C. And since in almost all cases, this sort of thing comes in pre-written headers, the developer is rarely going to have to write it themselves. Yes, I expect a compiler to optimise the use of such a REG. This is not 1980 - even the simplest compilers do a reasonable job on such common constructs. And the compiler has /exactly/ the same information here as it would have with an @ definition - there is no reason why it should be able to optimise one better than the other. (It is different for registers whose address is defined by linker scripts - there, the compiler has less information and cannot generate as optimal code.) > >> it very nearly destroys the portability of code that uses it... > > and I assume that constant pointer doesn't destroy portability. C > specifically rarely has portable applications. Some C code is massively portable, other C code is tied tightly to a particular compiler and particular target - C covers a wide span here. The use of the cast constant pointer is portable to any compiler that supports the appropriate types, and has the same interpretation of casting an integer literal to a pointer, and has the same concept of "volatile access". That covers pretty much every C compiler ever written - certainly anything for embedded systems (baring possible limitations on type sizes). The use of @ is limited to a few specific compilers, most of which are for outdated and limited cpu cores. > > Better that applications be completely contained and either have include > files to define application specific information. The original role of > linkers was to be able to compiler large programs on small computers. Linkers do a lot more than that - but that is a different argument. I agree that it is nicest to have as much as possible defined as part of the C code and header files, rather than in the linker file (though I accept that some people like to put their fixed addresses in a linker file). The standard method of defining hardware registers using cast pointers puts the addresses in a header file (or occasionally a C file). So again, the @ method gives absolutely no benefit over the standard method. > > The current state of especially open source compilers is an awful lot of > duplication between the compiler and linkers in the tool sets. Can you give specifics here, or is it just your prejudice against open source tools? > Better > that a lot of the linker information be processed much earlier to > develop compile strategies. If the compiler knows the addresses of the fixed registers at compile time, it can use that information to generate better code. If it knows that REG1 is at 0x1001, and REG2 is at 0x1002, then it can load a cpu pointer register X with 0x1001, and access these two hardware registers at X+0 and X+1 rather than working with their absolute addresses. This is absolutely true, and particularly relevant on more modern cpus with longer addresses and more registers where this sort of optimisation makes a bigger difference. That is why it makes sense to use the standard cast pointer syntax, the "kludge", rather than putting all your hardware addresses in a linker file. And that is one of the reasons why almost everyone /does/ define their hardware addresses that way. There is absolutely /nothing/ here to give any reason to suspect a difference between open source compilers and closed source compilers. And again, the @ method gives you absolutely /nothing/ here that you don't also get with standard C. > > This is even more true in some of the more interesting ISA that are > currently being developed. I am working on a project that can have > hundreds or potentially thousands of heterogeneous processors being > compiled to from a single application. > > Address setting from application/processor specific header files allows > compilers to be written with far more flexibility and that is far less > computationally intensive. > Again, the @ method gives you absolutely /nothing/ here that you don't also get with standard C. The @ syntax is a relic from the days of brain-dead compilers with poor optimisation and limited support for normal standard C, usually targeting brain-dead cpus that are also a relic. It is a little neater than the standard C method - defining macros is always ugly, as are pointer casts. But there are /no/ benefits from using the @ syntax like this for a decent compiler. The @ syntax does not give the compiler any more information, and it does not allow any more optimisation. The way it is implemented is often less flexible, since it is often limited to variables of a few specific types, and may require specific fixed formats for the address.
[toc] | [prev] | [next] | [standalone]
Page 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web