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 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
| From | "Brian G. Lucas" <bagel99@gmail.com> |
|---|---|
| Date | 2017-03-13 17:27 -0500 |
| Message-ID | <oa767k$cm2$1@dont-email.me> |
| In reply to | #26057 |
On 03/13/2017 04:17 PM, Niklas Holsti wrote: > Hm. In the spirit of language ecumenics and comparison, I translate your > example to Ada, below. I try to use your identifiers as such, although Ada > convention would use Title_Style capitalisation. Great! That was fast. I had assumed that Ada would be able to come close. > ... SNIP ... > > Syntactically Ada needs more lines, because enumerations and sub-records must > be defined as types. Does your language use "structural equivalence" for types? > That is, if one register field is defined as the enumeration (A, B, C), and > another register field is also defined as the enumeration (A, B, C), are these > fields of the same type? There are also more lines because of the separation of "type T is record ..." and "type T use record ...". And yes, records have "structural equivalence". My language does not have as strict types as Ada. In part, that is to allow interoperability with C. Regards, Brian
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2017-03-13 17:10 -0700 |
| Message-ID | <oa7c7h$37f$2@dont-email.me> |
| In reply to | #26062 |
On 3/13/2017 3:27 PM, Brian G. Lucas wrote: > In part, that is to allow interoperability with C. IMO, this sort of reasoning is behind many of the "bad" aspects of "new" innovations. There's a point at which you are better off just ignoring "backward compatibility" and adopting new, *better* ideas.
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2017-03-14 10:11 +0200 |
| Message-ID | <eipmuaF9vvtU1@mid.individual.net> |
| In reply to | #26062 |
On 17-03-14 00:27 , Brian G. Lucas wrote:
> On 03/13/2017 04:17 PM, Niklas Holsti wrote:
>> Hm. In the spirit of language ecumenics and comparison, I translate your
>> example to Ada, below. I try to use your identifiers as such, although Ada
>> convention would use Title_Style capitalisation.
>
> Great! That was fast. I had assumed that Ada would be able to come close.
>
>> ... SNIP ...
>>
>> Syntactically Ada needs more lines, because enumerations and sub-records must
>> be defined as types. Does your language use "structural equivalence" for types?
>> That is, if one register field is defined as the enumeration (A, B, C), and
>> another register field is also defined as the enumeration (A, B, C), are these
>> fields of the same type?
>
> There are also more lines because of the separation of "type T is record ..."
> and "type T use record ...".
I could just have said "... with pack" for each record type, instead of
the "type T use record ...", but IMO it is clearer and safer to give the
bit numbers explicitly. Makes it easy to compare the source code with
the data sheet that shows the register structures.
There was a short discussion recently on the main Ada
language-definition mailing list (ada-comment@ada-auth.org) about a
proposal to allow the record lay-out (bit numbers) to be written in the
record type declaration itself, avoiding these extra lines. It did not
gain support; most responders felt that a separate definition of the
lay-out gave clearer code.
> And yes, records have "structural equivalence". My language does not have as
> strict types as Ada. In part, that is to allow interoperability with C.
I don't see how structural equivalence or weaker typing helps
interoperability. If one cannot use the same source text to declare a
type in C in and in the other language (or use a tool that translates or
compares the two declarations) one must still be very careful to declare
the types in equivalent ways.
For simple C interfacing Ada has a standard predefined package,
Interfaces.C, that defines Ada equivalents for the standard C types int,
long, char, ... However, it does not fully cover the newer C standard
types, such as the integer types of known size. Moreover, as different C
compilers may (in principle) choose different sizes for "int" etc., one
would anyway have to check the actual compatibility of a given C
compiler's types with a given Ada compiler's implementation of Interfaces.C.
The GNU Ada compiler, gnat, has a way to translate a set of C header
files into the "corresponding" Ada package declarations, but the results
may or may not be useful, because of the large semantic gap between the
languages. I tried it once, but the result was so ugly and non-Ada-like,
and cumbersome to use from Ada client code, that I preferred to write
the Ada form manually.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
[toc] | [prev] | [next] | [standalone]
| From | "Brian G. Lucas" <bagel99@gmail.com> |
|---|---|
| Date | 2017-03-14 12:23 -0500 |
| Message-ID | <oa98pl$h3p$1@dont-email.me> |
| In reply to | #26070 |
On 03/14/2017 03:11 AM, Niklas Holsti wrote: > On 17-03-14 00:27 , Brian G. Lucas wrote: > ... SNIP >> And yes, records have "structural equivalence". My language does not have as >> strict types as Ada. In part, that is to allow interoperability with C. > > I don't see how structural equivalence or weaker typing helps interoperability. > If one cannot use the same source text to declare a type in C in and in the > other language (or use a tool that translates or compares the two declarations) > one must still be very careful to declare the types in equivalent ways. You are correct. The structural equivalence is not a cause or effect of interoperability with C. I have experimented with more strict typing and the language could support it, but does not at present. Regards, Brian
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-14 13:27 +0100 |
| Message-ID | <oa8ne7$gto$1@dont-email.me> |
| In reply to | #26052 |
On 13/03/17 19:14, Walter Banks wrote: > On 2017-03-12 7:15 PM, Tom Gardner wrote: >> That's why the necessity of having "language lawyers" to unravel the >> arcane complexity of modern C/C++ and tools implies that modern C/C++ >> is part of the problem as much as it is part of the solution. > > Having been at quite a few WG-14 meetings. C/C++ issues are a > combination of some level of compatibility to old tools and dealing with > new emerging code generation requirements. Thrown in for good measure > was C "Conventional wisdom" (Everyone knows that C does "this") > > It is hard to advance a language with that type of background. Many > things are, "implementation defined", it is difficult to extend the > language and many legacy items remained obscure. > > The open source folks for the most part didn't participate and created > their own variation. Conforming test suites have been for the most part > have been commercial products that are very useful in creating > conforming compilers but the implementation defined and conventional > wisdom aspects tends to impact the language portability. > In the earlier days of C standards, there was not much participation from open source folks. Much of the WG were people with rather specialised focus (look at yourself - your own compilers are mostly aimed at the most C-unfriendly processors around, and are full of non-standard extensions to get the most from such cpus). The standardisation process was slow, it was extremely difficult to get new ideas into the language, it is almost impossible to throw out old compatibilities (such as for one's complement machines), and the bureaucratic factor was high. Those involved in open source compilers (which basically meant "gcc" at the time) were more interested in writing tools that worked, with extensions to suit their users - you could well say they were not mature enough members of the industry to see the importance of the standardisation process. That changed with time, and both gcc and clang folks are involved with language standardisation groups (mainly C++ rather than C, since that is where most of the work is). And both gcc and clang work hard to support the standards (while also supporting a number of extensions). There are no compilers, commercial or open source, that come close to gcc in the standards support for a broad range of targets. Most commercial embedded C compilers struggle enough with C99 and C++03, and haven't considered C11, C++11 or C++14. Most don't even document which C or C++ standards they are close to supporting - it's all just "C" or "C++" to them. Most of them rely on extensions (as distinct from /allowing/ extensions to improve code). And most commercial C compiler developers have never even heard of conformance test suites like Plum Hall, never mind considered using them. (Several companies will provide you with Plum Hall certificates for gcc - for a price. These companies also work to fix any non-conformances they find in gcc.) > C isn't is particularly portable in many applications. > A lot of embedded C code is closely tied to the target - but some parts can be made highly portable. C covers a wide range of possibilities here.
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2017-03-14 13:30 -0400 |
| Message-ID | <oa99bm$1cl0$1@gioia.aioe.org> |
| In reply to | #26075 |
On 2017-03-14 8:27 AM, David Brown wrote: > On 13/03/17 19:14, Walter Banks wrote: >> On 2017-03-12 7:15 PM, Tom Gardner wrote: >>> That's why the necessity of having "language lawyers" to unravel >>> the arcane complexity of modern C/C++ and tools implies that >>> modern C/C++ is part of the problem as much as it is part of the >>> solution. >> >> Having been at quite a few WG-14 meetings. C/C++ issues are a >> combination of some level of compatibility to old tools and dealing >> with new emerging code generation requirements. Thrown in for good >> measure was C "Conventional wisdom" (Everyone knows that C does >> "this") >> >> It is hard to advance a language with that type of background. >> Many things are, "implementation defined", it is difficult to >> extend the language and many legacy items remained obscure. >> >> The open source folks for the most part didn't participate and >> created their own variation. Conforming test suites have been for >> the most part have been commercial products that are very useful in >> creating conforming compilers but the implementation defined and >> conventional wisdom aspects tends to impact the language >> portability. >> > > In the earlier days of C standards, there was not much participation > from open source folks. Much of the WG were people with rather > specialised focus (look at yourself - your own compilers are mostly > aimed at the most C-unfriendly processors around, and are full of > non-standard extensions to get the most from such cpus). The > standardisation process was slow, it was extremely difficult to get > new ideas into the language, it is almost impossible to throw out > old compatibilities (such as for one's complement machines), and the > bureaucratic factor was high. Those involved in open source > compilers (which basically meant "gcc" at the time) were more > interested in writing tools that worked, with extensions to suit > their users - you could well say they were not mature enough members > of the industry to see the importance of the standardisation > process. > > That changed with time, and both gcc and clang folks are involved > with language standardisation groups (mainly C++ rather than C, since > that is where most of the work is). And both gcc and clang work hard > to support the standards (while also supporting a number of > extensions). There are no compilers, commercial or open source, that > come close to gcc in the standards support for a broad range of > targets. Most commercial embedded C compilers struggle enough with > C99 and C++03, and haven't considered C11, C++11 or C++14. Most > don't even document which C or C++ standards they are close to > supporting - it's all just "C" or "C++" to them. Most of them rely > on extensions (as distinct from /allowing/ extensions to improve > code). And most commercial C compiler developers have never even > heard of conformance test suites like Plum Hall, never mind > considered using them. (Several companies will provide you with Plum > Hall certificates for gcc - for a price. These companies also work > to fix any non-conformances they find in gcc.) > > >> C isn't is particularly portable in many applications. >> > > A lot of embedded C code is closely tied to the target - but some > parts can be made highly portable. C covers a wide range of > possibilities here. > > Comments well taken. One of the things you point out is the non-conformance of the tools we develop and sell for embedded systems and I would like to also point out that a lot of my work with WG-14 is to provide a voice to explain the needs and solutions to supporting embedded systems. I have done this with work on the actual standards and on IEC/ISO documents that supplements the WG-14 C standards documents that is part of the WG-14 work. I should also point out the WG-14 mandate is to codify the current practice not to invent or define new standards or syntax. The standards committees will debate and define a resolution of conflicting syntax for new features. I can point to the nonstandard language structures in my work that became part of the standards. WG-14 has several times discovered just how important the need for existing practice is when they have wandered outside that boundary. One essential ingredient to new standards is the need for a body of experience to validate a change. I stand by my comment that the open source people have been for the most part absent from these discussions. w..
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-14 22:03 +0100 |
| Message-ID | <oa9llo$28e$1@dont-email.me> |
| In reply to | #26080 |
On 14/03/17 18:30, Walter Banks wrote: > On 2017-03-14 8:27 AM, David Brown wrote: >> A lot of embedded C code is closely tied to the target - but some >> parts can be made highly portable. C covers a wide range of >> possibilities here. >> >> > > Comments well taken. One of the things you point out is the > non-conformance of the tools we develop and sell for embedded systems > and I would like to also point out that a lot of my work with WG-14 is > to provide a voice to explain the needs and solutions to supporting > embedded systems. I have done this with work on the actual standards and > on IEC/ISO documents that supplements the WG-14 C standards documents > that is part of the WG-14 work. I think it is a good thing that the C standards take this sort of thing into account - C is not just a language for PC-style processors with 8-bit char and 32-bit int. And I fully appreciate that for some targets, a lot of extensions are needed to get the best out of the chip, and it is unlikely that you will need full conformance (who needs wchar_t on a processor with 4K flash?). But I did think it was ironic for you to berate open source folks for "creating their own variation" ! (And note that in several cases, features from these gcc variations have been absorbed into the C or C++ standards. And the C++ standard library is heavily influenced by the open source Boost project.) > > I should also point out the WG-14 mandate is to codify the current > practice not to invent or define new standards or syntax. The standards > committees will debate and define a resolution of conflicting syntax for > new features. I can point to the nonstandard language structures in my > work that became part of the standards. > > WG-14 has several times discovered just how important the need for > existing practice is when they have wandered outside that boundary. One > essential ingredient to new standards is the need for a body of > experience to validate a change. > > I stand by my comment that the open source people have been for the most > part absent from these discussions. >
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2017-03-14 17:24 -0400 |
| Message-ID | <oa9n34$c4f$1@gioia.aioe.org> |
| In reply to | #26085 |
On 2017-03-14 5:03 PM, David Brown wrote: > > (And note that in several cases, features from these gcc variations have > been absorbed into the C or C++ standards. And the C++ standard library > is heavily influenced by the open source Boost project.) > The C standards (WG-14) material from GCC has only happened when there was someone to write up changes and make it part of the formal record. The open source community have been quick to criticize but for the most part have been unwilling to put the effort into participation. WG-14 has been criticized for not looking for standard practice instead of just working from formal presentations. Working on standards is a non trivial commitment of time and resources. If a change is good enough to be included then it needs someone to advocate it's use and be knowledgeable enough to properly represent it in debate. w..
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2017-03-11 07:19 -0600 |
| Message-ID | <oa0tif$9o9$1@gioia.aioe.org> |
| In reply to | #26005 |
On 2017-03-11 3:59 AM, Tom Gardner wrote: > On 11/03/17 02:16, Paul Rubin wrote: >> Tom Gardner <spamjunk@blueyonder.co.uk> writes: >>>> There are at least 2 compilers which do whole program alias >>>> analysis. >>> >>> How do they do that if the program includes a library for which >>> the source is not available, and for which the compiler flags are >>> not known? >> >> "Whole program" means the compiler has all of the source code and >> can munch it all as a single piece. All kinds of added >> optimizations are then possible. > > I thought you would say that. > > It means such alias analysis is impossible in many (most?) > applications. > Yes and no. Libraries can still be precompiled and don't need sources as long as the object format has the information the compiler needs for its analysis. w..
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-03-11 19:43 +0000 |
| Message-ID | <LrYwA.86958$8b6.82259@fx19.am4> |
| In reply to | #26012 |
On 11/03/17 13:19, Walter Banks wrote: > On 2017-03-11 3:59 AM, Tom Gardner wrote: >> On 11/03/17 02:16, Paul Rubin wrote: >>> Tom Gardner <spamjunk@blueyonder.co.uk> writes: >>>>> There are at least 2 compilers which do whole program alias >>>>> analysis. >>>> >>>> How do they do that if the program includes a library for which >>>> the source is not available, and for which the compiler flags are >>>> not known? >>> >>> "Whole program" means the compiler has all of the source code and >>> can munch it all as a single piece. All kinds of added >>> optimizations are then possible. >> >> I thought you would say that. >> >> It means such alias analysis is impossible in many (most?) >> applications. >> > Yes and no. Libraries can still be precompiled and don't need sources > as long as the object format has the information the compiler needs for > its analysis. Very plausible. Does that occur with common tools, or are "specialist" tools required for the entire system being compiled?
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2017-03-12 09:28 -0600 |
| Message-ID | <oa3pfq$14uk$1@gioia.aioe.org> |
| In reply to | #26018 |
On 2017-03-11 1:43 PM, Tom Gardner wrote: > On 11/03/17 13:19, Walter Banks wrote: >> On 2017-03-11 3:59 AM, Tom Gardner wrote: >>> On 11/03/17 02:16, Paul Rubin wrote: >>>> Tom Gardner <spamjunk@blueyonder.co.uk> writes: >>>>>> There are at least 2 compilers which do whole program >>>>>> alias analysis. >>>>> >>>>> How do they do that if the program includes a library for >>>>> which the source is not available, and for which the compiler >>>>> flags are not known? >>>> >>>> "Whole program" means the compiler has all of the source code >>>> and can munch it all as a single piece. All kinds of added >>>> optimizations are then possible. >>> >>> I thought you would say that. >>> >>> It means such alias analysis is impossible in many (most?) >>> applications. >>> >> Yes and no. Libraries can still be precompiled and don't need >> sources as long as the object format has the information the >> compiler needs for its analysis. > > Very plausible. > > Does that occur with common tools, or are "specialist" tools required > for the entire system being compiled? > When we are compiling without linking,libraries can be objects or source. (Actually it is also possible to include pre-compiled code objects) The difference is essentially library functions are only part of the generated code if they are referenced by the application. Most of our tools are used in embedded system applications and are by your definition "specialist" w..
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2017-03-12 15:15 -0400 |
| Message-ID | <ke4bcc9afe18267pfkoaij0jlnuug21g5v@4ax.com> |
| In reply to | #25997 |
On Sat, 11 Mar 2017 01:32:04 +0000, Tom Gardner <spamjunk@blueyonder.co.uk> wrote: >On 11/03/17 01:22, George Neuner wrote: > >> There are at least 2 compilers which do whole program alias analysis. > >How do they do that if the program includes a library >for which the source is not available, and for which >the compiler flags are not known? Obviously "whole" analysis can't be done in that situation. However, in that situation, it isn't needed either. Libary code can see only what data is passed to it: aliasing, if there is any, can only be in function call parameters. Of course, the aliasing may be in parameters to different functions. Aliasing introduced *within* the library, if any, is the fault and concern of the library developer. Typically most libraries *are* compiled pessimistically unless they are deliberately intended for high performance use ... math, image processing, etc. ... and in that case there will be all kinds of documented restrictions on how to use the library functions correctly. If a pessimistic canned library is a critical path for a program, then performance may suffer and there is little the programmer can do about it [other than find another library]. But use of canned libraries doesn't affect better optimization of the rest of the program. In general, it's a mistake to compile a library for distribution using very high optimization settings. It makes the library brittle and hard to use correctly. It is acceptable for applications that require maximum performance, but most applications do not fall under that classification. In general, it is more important that a library be defensive with its input and/or tolerant of user mistakes than it is to provide high performance. [Remember that in the real world outside of C.A.E, the average skill level of a software developer is only slight above novice. I've mentioned occasionally that I believe a lot of so-called "developers" would be doing the world a favor by finding other employment.] YMMV, George
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-03-12 19:38 +0000 |
| Message-ID | <IshxA.68326$PU6.18262@fx13.am4> |
| In reply to | #26035 |
On 12/03/17 19:15, George Neuner wrote: > On Sat, 11 Mar 2017 01:32:04 +0000, Tom Gardner > <spamjunk@blueyonder.co.uk> wrote: > >> On 11/03/17 01:22, George Neuner wrote: >> >>> There are at least 2 compilers which do whole program alias analysis. >> >> How do they do that if the program includes a library >> for which the source is not available, and for which >> the compiler flags are not known? > > Obviously "whole" analysis can't be done in that situation. However, > in that situation, it isn't needed either. > > Libary code can see only what data is passed to it: aliasing, if there > is any, can only be in function call parameters. Of course, the > aliasing may be in parameters to different functions. > > Aliasing introduced *within* the library, if any, is the fault and > concern of the library developer. > > > Typically most libraries *are* compiled pessimistically unless they > are deliberately intended for high performance use ... math, image > processing, etc. ... and in that case there will be all kinds of > documented restrictions on how to use the library functions correctly. > > If a pessimistic canned library is a critical path for a program, then > performance may suffer and there is little the programmer can do about > it [other than find another library]. But use of canned libraries > doesn't affect better optimization of the rest of the program. > > > In general, it's a mistake to compile a library for distribution using > very high optimization settings. It makes the library brittle and > hard to use correctly. It is acceptable for applications that require > maximum performance, but most applications do not fall under that > classification. In general, it is more important that a library be > defensive with its input and/or tolerant of user mistakes than it is > to provide high performance. > > [Remember that in the real world outside of C.A.E, the average skill > level of a software developer is only slight above novice. I've > mentioned occasionally that I believe a lot of so-called "developers" > would be doing the world a favor by finding other employment.] All very plausible. It can be contended that embedded systems have to make full use of the available resources (processor, memory etc). That suggests requiring highly optimised code, and hence requiring that libraries' source code is available. Getting the optimisation/pessimisation compiler flags right for code written by other people is not easy do correctly. It is too easy to get them "almost right" so that they pass the unit and integration tests, but intermittently fail in the field. And that's still true for non-novice developers unfortunately. Not a solid starting point for a system that has to be reliable, IMNSHO.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-03-10 18:08 -0800 |
| Message-ID | <87h930r2ed.fsf@nightsong.com> |
| In reply to | #25996 |
George Neuner <gneuner2@comcast.net> writes: > Now that is an overstatement. It is merely excruciatingly difficult > for a C/C++ compiler to determine aliasing ... it is _not_ impossible. > There are at least 2 compilers which do whole program alias analysis. The general case is assuredly impossible from Rice's theorem. Some compilers may do some conservative analyses that can help specific programs. Or if x and y are of different datatypes, then iirc the compiler is allowed to assume that they aren't aliased. It's probably easier to make use of that in C++ than in C.
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2017-03-11 04:22 -0500 |
| Message-ID | <dcg7cch6th0jau9eodd7c2dd0nljqh088t@4ax.com> |
| In reply to | #25998 |
On Fri, 10 Mar 2017 18:08:26 -0800, Paul Rubin <no.email@nospam.invalid> wrote: >George Neuner <gneuner2@comcast.net> writes: >> Now that is an overstatement. It is merely excruciatingly difficult >> for a C/C++ compiler to determine aliasing ... it is _not_ impossible. >> There are at least 2 compilers which do whole program alias analysis. > >The general case is assuredly impossible from Rice's theorem. Some >compilers may do some conservative analyses that can help specific >programs. Or if x and y are of different datatypes, then iirc the >compiler is allowed to assume that they aren't aliased. It's probably >easier to make use of that in C++ than in C. Yes, that is correct. However you can go quite a long way by taking into account both type and scope of visibility. George
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-03-11 10:02 +0000 |
| Message-ID | <dXPwA.64578$PU6.59964@fx13.am4> |
| In reply to | #26004 |
On 11/03/17 09:22, George Neuner wrote: > On Fri, 10 Mar 2017 18:08:26 -0800, Paul Rubin > <no.email@nospam.invalid> wrote: > >> George Neuner <gneuner2@comcast.net> writes: >>> Now that is an overstatement. It is merely excruciatingly difficult >>> for a C/C++ compiler to determine aliasing ... it is _not_ impossible. >>> There are at least 2 compilers which do whole program alias analysis. >> >> The general case is assuredly impossible from Rice's theorem. Some >> compilers may do some conservative analyses that can help specific >> programs. Or if x and y are of different datatypes, then iirc the >> compiler is allowed to assume that they aren't aliased. It's probably >> easier to make use of that in C++ than in C. > > Yes, that is correct. However you can go quite a long way by taking > into account both type and scope of visibility. Is that a long way to making the program fast or to making it correct? A tool that can mutate a program so that it doesn't have to produce a correct result (as is visible in the source code), is a very simple tool. Even I could write one!
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-03-11 02:22 -0800 |
| Message-ID | <871su4qfj7.fsf@nightsong.com> |
| In reply to | #26006 |
Tom Gardner <spamjunk@blueyonder.co.uk> writes: > Is that a long way to making the program fast or to making it correct? It's for speed. If the compiler can figure out that that *x and *y are in separate memory locations, then it knows updating *x won't change *y. That means more temporaries can be kept in registers, avoiding some memory loads and stores. The speedups are significant.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-03-11 11:07 +0000 |
| Message-ID | <PTQwA.208924$F83.130585@fx38.am4> |
| In reply to | #26007 |
On 11/03/17 10:22, Paul Rubin wrote: > Tom Gardner <spamjunk@blueyonder.co.uk> writes: >> Is that a long way to making the program fast or to making it correct? > > It's for speed. If the compiler can figure out that that *x and *y are > in separate memory locations, then it knows updating *x won't change *y. > That means more temporaries can be kept in registers, avoiding some > memory loads and stores. The speedups are significant. My compiler meets that constraint by producing very fast and very small code. The downside is that the result is always 42 :)
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2017-03-10 14:30 -0600 |
| Message-ID | <o9v2dq$1ffs$1@gioia.aioe.org> |
| In reply to | #25975 |
On 2017-03-10 12:24 PM, Don Y wrote: >> >> If something is important to the correct operation of the program, >> then I like it to be visible in the source code. A useful benefit >> is that the information is easily found and analysed by the IDEs >> and/or other source code manipulation tools around. > > I guess it depends on what you consider "source code". How do you > treat makefiles, linker scripts, etc.? Clearly they are all > important to the *intended* operation of the program -- as are the > actual tools, themselves. > > How much of this cruft do you clutter the "sources" with in the > attempt to ensure they accompany the sources? What about applications > wherein multiple languages are combined; how do you nail down the > "implementation defined" behavior of their interfaces? What order > will your Java/C/Python/foo function build its stack frame? How will > your FORTRAN/Pascal/ASM/bar module interface to it?? There are lots of tools issues that should be re-examined. There is many cases where the tool execution is backwards to what generates the best code. The compile link sequence where some key information about the target ISA or processor architecture is not known until link time sometimes forces the compiler to use a subset of the actual processors ISA rather than take advantage of a specific member feature. The recent discussion of the mill belt length is a good example of how important this is. This type of compiler approach can encapsulate the specific processor variations and make application wide optimizations with relative ease. Switching this around so the compiler is focused on creation code for a well defined target rarely is anything more than including a device specific header file in the application. (as a side effect eliminating the link step) What's wrong with a single set of sources that defines an application, no command line options or linker scripts just an application including the definition of the target, files and libraries it needs. Compilation is both faster by many factors and there is a simple self contained project that can be easily re-created after a decade or more. (The oldest project we have helped customers re-create in the last year was archived by the customer in 1988, we have copies of every released tool set. Start to recreating an identical HEX file < 2 hours from receiving the customer support request email) The brouhaha about "@" and C is really more about having supporting syntax to be able to explain what is desired without needing an indirect definition. That is my real argument not that it can't be done. Most languages have some way to access the underlying machine, fewer of these languages do so in a simple clean way. Don I am not arguing to create a more complex world but in the area of language design why are many tool sets burdened with solutions to the computer limitations of 1980? It is a real eyeopener to spend some time with some of the current crop of programmers who are using what many of us would consider a toy language to actually achieve some pretty remarkable results. It took me a long time to respect what they are doing. w..
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-03-10 13:37 -0800 |
| Message-ID | <87lgscreyh.fsf@nightsong.com> |
| In reply to | #25985 |
Walter Banks <walter@bytecraft.com> writes: > The brouhaha about "@" and C is really more about having supporting > syntax to be able to explain what is desired without needing an > indirect definition. That is my real argument not that it can't be done. It's probably clearest to just call functions to bang on those registers. The compiler can inline them so there shouldn't be overhead. > It is a real eyeopener to spend some time with some of the current crop > of programmers who are using what many of us would consider a toy > language to actually achieve some pretty remarkable results. It took me > a long time to respect what they are doing. Do you mean C?
[toc] | [prev] | [next] | [standalone]
Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web