Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > sci.electronics.design > #446506 > unrolled thread
| Started by | dagmargoodboat@yahoo.com |
|---|---|
| First post | 2017-02-06 15:43 -0800 |
| Last post | 2017-02-16 14:19 -0600 |
| Articles | 20 on this page of 131 — 18 participants |
Back to article view | Back to sci.electronics.design
Arduino / compilers on uC dagmargoodboat@yahoo.com - 2017-02-06 15:43 -0800
Re: Arduino / compilers on uC Clifford Heath <no.spam@please.net> - 2017-02-07 10:58 +1100
Re: Arduino / compilers on uC bitrex <bitrex@de.lete.earthlink.net> - 2017-02-06 19:09 -0500
Re: Arduino / compilers on uC dagmargoodboat@yahoo.com - 2017-02-06 18:30 -0800
Re: Arduino / compilers on uC bitrex <bitrex@de.lete.earthlink.net> - 2017-02-06 21:43 -0500
Re: Arduino / compilers on uC dagmargoodboat@yahoo.com - 2017-02-06 19:02 -0800
Re: Arduino / compilers on uC bitrex <bitrex@de.lete.earthlink.net> - 2017-02-06 23:26 -0500
Re: Arduino / compilers on uC dagmargoodboat@yahoo.com - 2017-02-06 21:05 -0800
Re: Arduino / compilers on uC Clifford Heath <no.spam@please.net> - 2017-02-07 13:55 +1100
Re: Arduino / compilers on uC dagmargoodboat@yahoo.com - 2017-02-06 20:00 -0800
Re: Arduino / compilers on uC Clifford Heath <no.spam@please.net> - 2017-02-07 19:31 +1100
Re: Arduino / compilers on uC David Brown <david.brown@hesbynett.no> - 2017-02-07 10:29 +0100
Re: Arduino / compilers on uC dagmargoodboat@yahoo.com - 2017-02-07 07:39 -0800
Re: Arduino / compilers on uC David Brown <david.brown@hesbynett.no> - 2017-02-08 12:24 +0100
Re: Arduino / compilers on uC dagmargoodboat@yahoo.com - 2017-02-09 08:36 -0800
Re: Arduino / compilers on uC Clifford Heath <no.spam@please.net> - 2017-02-10 08:15 +1100
Re: Arduino / compilers on uC David Brown <david.brown@hesbynett.no> - 2017-02-13 15:37 +0100
Re: Arduino / compilers on uC David Brown <david.brown@hesbynett.no> - 2017-02-13 15:35 +0100
Re: Arduino / compilers on uC dagmargoodboat@yahoo.com - 2017-02-07 08:05 -0800
Re: Arduino / compilers on uC David Brown <david.brown@hesbynett.no> - 2017-02-08 12:30 +0100
Re: Arduino / compilers on uC mrdarrett@gmail.com - 2017-02-06 15:59 -0800
Re: Arduino / compilers on uC Lasse Langwadt Christensen <langwadt@fonz.dk> - 2017-02-06 16:04 -0800
Re: Arduino / compilers on uC dagmargoodboat@yahoo.com - 2017-02-06 18:41 -0800
Re: Arduino / compilers on uC Clifford Heath <no.spam@please.net> - 2017-02-07 14:08 +1100
Re: Arduino / compilers on uC dagmargoodboat@yahoo.com - 2017-02-06 20:14 -0800
Re: Arduino / compilers on uC Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-02-07 08:00 +0000
Re: Arduino / compilers on uC dagmargoodboat@yahoo.com - 2017-02-09 05:42 -0800
Re: Arduino / compilers on uC David Brown <david.brown@hesbynett.no> - 2017-02-09 15:07 +0100
Re: Arduino / compilers on uC Lasse Langwadt Christensen <langwadt@fonz.dk> - 2017-02-09 09:54 -0800
Re: Arduino / compilers on uC Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-02-09 15:55 +0000
Re: Arduino / compilers on uC dagmargoodboat@yahoo.com - 2017-02-09 08:46 -0800
Re: Arduino / compilers on uC Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-02-09 14:42 -0500
Re: Arduino / compilers on uC dagmargoodboat@yahoo.com - 2017-02-11 06:54 -0800
Re: Arduino / compilers on uC pcdhobbs@gmail.com - 2017-02-11 07:31 -0800
Re: Arduino / compilers on uC dagmargoodboat@yahoo.com - 2017-02-11 07:59 -0800
Re: Arduino / compilers on uC Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-02-11 17:01 +0000
Re: Arduino / compilers on uC pcdhobbs@gmail.com - 2017-02-11 12:52 -0800
Re: Arduino / compilers on uC krw@notreal.com - 2017-02-11 18:46 -0500
Re: Arduino / compilers on uC Clifford Heath <no.spam@please.net> - 2017-02-12 10:20 +1100
Re: Arduino / compilers on uC David Brown <david.brown@hesbynett.no> - 2017-02-13 16:07 +0100
Re: Arduino / compilers on uC Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-02-09 14:16 -0500
Re: Arduino / compilers on uC Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-02-09 22:39 +0000
Re: Arduino / compilers on uC David Brown <david.brown@hesbynett.no> - 2017-02-13 16:06 +0100
Re: Arduino / compilers on uC Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-02-13 15:29 +0000
Re: Arduino / compilers on uC David Brown <david.brown@hesbynett.no> - 2017-02-13 16:49 +0100
Re: Arduino / compilers on uC Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-02-13 10:55 -0500
Re: Arduino / compilers on uC Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-02-13 17:09 +0000
Re: Arduino / compilers on uC David Brown <david.brown@hesbynett.no> - 2017-02-14 09:49 +0100
Re: Arduino / compilers on uC Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-02-13 16:07 +0000
Re: Arduino / compilers on uC David Brown <david.brown@hesbynett.no> - 2017-02-14 10:01 +0100
Re: Arduino / compilers on uC Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-02-14 09:49 +0000
Re: Arduino / compilers on uC Clifford Heath <no.spam@please.net> - 2017-02-17 04:21 +1100
Re: Arduino / compilers on uC pcdhobbs@gmail.com - 2017-02-16 14:47 -0800
Re: Arduino / compilers on uC Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-02-17 00:17 +0000
Re: Arduino / compilers on uC Clifford Heath <no.spam@please.net> - 2017-02-07 19:49 +1100
Re: Arduino / compilers on uC dagmargoodboat@yahoo.com - 2017-02-09 06:22 -0800
Re: Arduino / compilers on uC David Brown <david.brown@hesbynett.no> - 2017-02-07 10:42 +0100
Re: Arduino / compilers on uC dagmargoodboat@yahoo.com - 2017-02-09 06:57 -0800
Re: Arduino / compilers on uC David Brown <david.brown@hesbynett.no> - 2017-02-09 16:12 +0100
Re: Arduino / compilers on uC Clifford Heath <no.spam@please.net> - 2017-02-10 08:24 +1100
Re: Arduino / compilers on uC bitrex <bitrex@de.lete.earthlink.net> - 2017-02-06 19:08 -0500
Re: Arduino / compilers on uC dagmargoodboat@yahoo.com - 2017-02-06 18:47 -0800
Re: Arduino / compilers on uC bitrex <bitrex@de.lete.earthlink.net> - 2017-02-06 21:51 -0500
Re: Arduino / compilers on uC dagmargoodboat@yahoo.com - 2017-02-06 20:39 -0800
Re: Arduino / compilers on uC dagmargoodboat@yahoo.com - 2017-02-06 20:55 -0800
Re: Arduino / compilers on uC Clifford Heath <no.spam@please.net> - 2017-02-07 20:05 +1100
Re: Arduino / compilers on uC bitrex <bitrex@de.lete.earthlink.net> - 2017-02-08 12:26 -0500
Re: Arduino / compilers on uC bitrex <bitrex@de.lete.earthlink.net> - 2017-02-08 12:32 -0500
Re: Arduino / compilers on uC Clifford Heath <no.spam@please.net> - 2017-02-09 08:31 +1100
Re: Arduino / compilers on uC Clifford Heath <no.spam@please.net> - 2017-02-09 08:21 +1100
Re: Arduino / compilers on uC Lasse Langwadt Christensen <langwadt@fonz.dk> - 2017-02-08 13:33 -0800
Re: Arduino / compilers on uC Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-02-07 08:15 +0000
Re: Arduino / compilers on uC dagmargoodboat@yahoo.com - 2017-02-09 05:51 -0800
Re: Arduino / compilers on uC Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-02-09 16:22 +0000
Re: Arduino / compilers on uC bitrex <bitrex@de.lete.earthlink.net> - 2017-02-09 16:45 -0500
Re: Arduino / compilers on uC bitrex <bitrex@de.lete.earthlink.net> - 2017-02-09 16:51 -0500
Re: Arduino / compilers on uC Clifford Heath <no.spam@please.net> - 2017-02-10 09:11 +1100
Re: Arduino / compilers on uC Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-02-09 22:45 +0000
Re: Arduino / compilers on uC bitrex <bitrex@de.lete.earthlink.net> - 2017-02-15 10:11 -0500
Re: Arduino / compilers on uC David Brown <david.brown@hesbynett.no> - 2017-02-07 10:57 +0100
Re: Arduino / compilers on uC Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-02-07 08:07 +0000
Re: Arduino / compilers on uC rickman <gnuarm@gmail.com> - 2017-02-07 04:01 -0500
Re: Arduino / compilers on uC Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-02-07 09:40 +0000
Re: Arduino / compilers on uC rickman <gnuarm@gmail.com> - 2017-02-07 05:52 -0500
Re: Arduino / compilers on uC Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-02-07 11:26 +0000
Re: Arduino / compilers on uC David Brown <david.brown@hesbynett.no> - 2017-02-07 12:58 +0100
Re: Arduino / compilers on uC Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-02-09 14:52 -0500
Re: Arduino / compilers on uC Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-02-09 22:47 +0000
Re: Arduino / compilers on uC bitrex <bitrex@de.lete.earthlink.net> - 2017-02-09 14:00 -0500
Re: Arduino / compilers on uC Tim Wescott <seemywebsite@myfooter.really> - 2017-02-09 13:24 -0600
Re: Arduino / compilers on uC David Brown <david.brown@hesbynett.no> - 2017-02-07 10:52 +0100
Re: Arduino / compilers on uC David Brown <david.brown@hesbynett.no> - 2017-02-07 10:50 +0100
Re: Arduino / compilers on uC rickman <gnuarm@gmail.com> - 2017-02-06 19:49 -0500
Re: Arduino / compilers on uC "David Eather" <eather@tpg.com.au> - 2017-02-07 12:45 +1000
Re: Arduino / compilers on uC dagmargoodboat@yahoo.com - 2017-02-06 18:51 -0800
Re: Arduino / compilers on uC "David Eather" <eather@tpg.com.au> - 2017-02-08 06:35 +1000
Re: Arduino / compilers on uC "David Eather" <eather@tpg.com.au> - 2017-02-08 06:44 +1000
Re: Arduino / compilers on uC M Philbrook <jamie_ka1lpa@charter.net> - 2017-02-07 17:11 -0500
Re: Arduino / compilers on uC David Brown <david.brown@hesbynett.no> - 2017-02-08 12:40 +0100
Re: Arduino / compilers on uC pcdhobbs@gmail.com - 2017-02-08 07:01 -0800
Re: Arduino / compilers on uC David Brown <david.brown@hesbynett.no> - 2017-02-08 17:25 +0100
Re: Arduino / compilers on uC jack4747@gmail.com - 2017-02-09 06:51 -0800
Re: Arduino / compilers on uC David Brown <david.brown@hesbynett.no> - 2017-02-09 16:41 +0100
Re: Arduino / compilers on uC M Philbrook <jamie_ka1lpa@charter.net> - 2017-02-09 19:44 -0500
Re: Arduino / compilers on uC David Brown <david.brown@hesbynett.no> - 2017-02-13 16:14 +0100
Re: Arduino / compilers on uC John Devereux <john@devereux.me.uk> - 2017-02-16 12:57 +0000
Re: Arduino / compilers on uC Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-02-16 14:11 +0000
Re: Arduino / compilers on uC John Devereux <john@devereux.me.uk> - 2017-02-16 14:40 +0000
Re: Arduino / compilers on uC David Brown <david.brown@hesbynett.no> - 2017-02-16 15:58 +0100
Re: Arduino / compilers on uC Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-02-16 15:56 +0000
Re: Arduino / compilers on uC John Devereux <john@devereux.me.uk> - 2017-02-16 16:45 +0000
Re: Arduino / compilers on uC Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-02-16 17:18 +0000
Re: Arduino / compilers on uC David Brown <david.brown@hesbynett.no> - 2017-02-17 14:59 +0100
Re: Arduino / compilers on uC Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-02-17 14:24 +0000
Re: Arduino / compilers on uC Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2017-02-17 21:07 +0200
Re: Arduino / compilers on uC Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-02-17 20:16 +0000
Re: Arduino / compilers on uC David Brown <david.brown@hesbynett.no> - 2017-02-17 23:28 +0100
Re: Arduino / compilers on uC Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-02-17 10:21 -0500
Re: Arduino / compilers on uC David Brown <david.brown@hesbynett.no> - 2017-02-17 16:34 +0100
Re: Arduino / compilers on uC M Philbrook <jamie_ka1lpa@charter.net> - 2017-02-09 19:43 -0500
Re: Arduino / compilers on uC Tim Wescott <tim@seemywebsite.com> - 2017-02-10 10:41 -0600
Re: Arduino / compilers on uC dagmargoodboat@yahoo.com - 2017-02-11 07:06 -0800
Re: Arduino / compilers on uC Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-02-11 17:09 +0000
Re: Arduino / compilers on uC David Brown <david.brown@hesbynett.no> - 2017-02-13 16:28 +0100
Re: Arduino / compilers on uC Tim Wescott <tim@seemywebsite.com> - 2017-02-14 09:59 -0600
Re: Arduino / compilers on uC dagmargoodboat@yahoo.com - 2017-02-14 13:46 -0800
Re: Arduino / compilers on uC David Brown <david.brown@hesbynett.no> - 2017-02-15 10:04 +0100
Re: Arduino / compilers on uC dagmargoodboat@yahoo.com - 2017-02-15 05:57 -0800
Re: Arduino / compilers on uC David Brown <david.brown@hesbynett.no> - 2017-02-15 16:02 +0100
Re: Arduino / compilers on uC David Brown <david.brown@hesbynett.no> - 2017-02-15 17:15 +0100
Re: Arduino / compilers on uC Tim Wescott <tim@seemywebsite.com> - 2017-02-16 14:19 -0600
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
| From | Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> |
|---|---|
| Date | 2017-02-09 14:16 -0500 |
| Message-ID | <gKqdnaxgR_VvIgHFnZ2dnUU7-K3NnZ2d@supernews.com> |
| In reply to | #447021 |
On 02/09/2017 10:55 AM, Tom Gardner wrote: > > You mustn't be able to cast away constness, since that > might affect correctness. You must be able to cast away > constness for some efficiency hacks and for things like > debuggers. > > That's unresolvable. I disagree profoundly. There are different definitions of constness, all useful in different situations, but the compiler enforces only one: bitwise constness. That means that if I have some object that has invisible internal state, such as a reference-counted string, it can never be const unless I can cast away constness (or use _mutable_ in c++, once that came along). Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.net
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-02-09 22:39 +0000 |
| Message-ID | <mc6nA.277013$dT1.141339@fx16.am4> |
| In reply to | #447043 |
On 09/02/17 19:16, Phil Hobbs wrote: > On 02/09/2017 10:55 AM, Tom Gardner wrote: >> >> You mustn't be able to cast away constness, since that >> might affect correctness. You must be able to cast away >> constness for some efficiency hacks and for things like >> debuggers. >> >> That's unresolvable. > > I disagree profoundly. There are different definitions of constness, all useful > in different situations, but the compiler enforces only one: bitwise constness. > > That means that if I have some object that has invisible internal state, such as > a reference-counted string, it can never be const unless I can cast away > constness (or use _mutable_ in c++, once that came along). Quite possibly they have resolved it one way or the other since I was keeping an eye on it. My conclusion remains that the language has become so complex that it becomes part of the problem rather than part of the solution. Listening to sage people that have not been at the sharp end of diagnosing problems but also part of Working Groups does nothing to dispel the conclusion. Languages should be easily understandable by humans, if humans are to stand a chance of writing reasonably correct programs. Libraries are different, of course, since arbitrary people create them and that can't be controlled. But at least a solid language definition should enable good tool support. For all its disadvantages, Java is streets ahead in those respects. Comprehensive "control-space" completion and comprehensive refactoring browsers are a significant advance.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-13 16:06 +0100 |
| Message-ID | <o7shtm$9o$1@dont-email.me> |
| In reply to | #447021 |
On 09/02/17 16:55, Tom Gardner wrote: > On 09/02/17 13:42, dagmargoodboat@yahoo.com wrote: >> On Tuesday, February 7, 2017 at 3:00:05 AM UTC-5, Tom Gardner wrote: >>> On 07/02/17 04:14, dagmargoodboat@yahoo.com wrote: >>>> On Monday, February 6, 2017 at 10:08:19 PM UTC-5, Clifford Heath wrote: >>> >>>> You're not understanding--I'm fully aware that I can go so far as to >>>> embed >>>> assembly if I choose. >>>> >>>> The fact that the compiler is jumping though hoops to map virtual >>>> pin numbers >>>> to physical ports and pins is exactly my point: it's solving >>>> problems that >>>> a human programmer wouldn't have to. I'd just read-modify-write the >>>> port >>>> with the appropriate mask. >>>> >>>> BUT, what the naive users have and use, is layers and layers >>>> abstracted from >>>> the hardware doing the actual work. >>> >>> That's a major objective of libraries and >>> environments in general. >> >> To an extent, true. More often my aim in using a pre-written function is >> to avoid repeating the work, not avoiding understanding the task. >> >> 'C' was conceived as a portable assembly language, so it's bizarre and >> ironic that this portable 'assembly' doesn't guarantee the size of its >> basic variables--that's one of the most basic elements of assembly-level >> programming. > > Porting C code has /always/ been very difficult, and required > arcane knowledge and extreme care; start by considering > "porting" from twos complement to ones complement machines. No, porting C code is not necessarily difficult. C makes it quite clear what behaviour is full specified by the C standards, what is implementation-specified (i.e., different compiler implementations can do things in different ways, but they have to tell you their choices in their documentation), and what is undefined (i.e., the standards make no comment on what happens). If your code relies only on standards specified behaviour, and you use conforming compilers, "porting" is just a matter of re-compiling. If your code relies on implementation-defined behaviour, then porting is a matter of checking that the new compiler fits your requirements. If your code relies on undefined behaviour, you should fix the code before you even think about porting. Now, it is certainly the case that a good deal of code relies on implementation-dependent behaviour. And much of that does so in a /bad/ way (such as making assumptions about the size of an "int"), making code porting difficult, rather than in a /good/ way (such as using implementation-dependent sized integer types). That is a problem with the way C code is written, rather than a problem with C itself - and C99 included useful changes to make it easier to write good portable code. > > But from the late 80s onwards it has been unsuccessfully > straddling two stools: that of a general purpose high level > language for applications and also for low-level near-the-silicon > "system/firmware" code. Consider that multithreading behaviour > is (was?) explicitly left undefined or implementation dependent, > but POSIX thread implementations relied on that behaviour. C has been, and continues to be, remarkably successful for such an "unsuccessful" language. > > Maybe having a memory model will help, but it is astoundingly > difficult to get that right across multiple architectures. That is why much of it is left undefined by the C standards. Nonetheless, people seem to manage. > Even the Java JVM's memory model was reworked in the light > of experience. > > Until ~1993 I vaguely followed the standards, but the > eternal and /unresolvable/ "cast away constness" discussions > convinced me that C (and doubly C++) was becoming a problem > more than a solution. > > You mustn't be able to cast away constness, since that > might affect correctness. You must be able to cast away > constness for some efficiency hacks and for things like > debuggers. > > That's unresolvable. It is resolvable in some cases, unresolvable in others. C++ takes an alternative approach in some ways, which make it easier to be correct but sometimes needs duplication in the source code. > > C++ is worse; the designers *discovered* they'd created > a monstrosity where you can cause the compiler to emit > the sequence of prime numbers during compilation. The > designers didn't believe it until someone demonstrated it! The flexibility of templates was unintentional, but it is not a "monstrosity" - it opened a new set of possibilities in the language. The fact that you can compute prime numbers at compile-time with templates does not mean that you /must/ compute prime numbers at compile-time with templates - it is not a disadvantage in any way. Many assemblers have powerful enough macro languages to let you generate primes at compile time - no one makes a big deal out of that. With C++11, the language designers realised that powerful compile-time computation functionality was actually very useful, but templates were a cumbersome and inefficient way to do it - so they introduced constexpr to make it easier. C++14 made it even more flexible and convenient. > > No, nowadays C++ is beyond mortal's comprehension, and > C isn't much better. Perhaps it is beyond /your/ comprehension. Certainly C++ is a large and complex language, and you can write code in it that is difficult to understand without a good deal of experience. But it is just a skill - you can study it and learn it, if you have enough natural aptitude and dedication. Kind of like most other tasks in life. > > Shame. >
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-02-13 15:29 +0000 |
| Message-ID | <WhkoA.440018$sc6.92372@fx25.am4> |
| In reply to | #447547 |
On 13/02/17 15:06, David Brown wrote: > On 09/02/17 16:55, Tom Gardner wrote: >> On 09/02/17 13:42, dagmargoodboat@yahoo.com wrote: >>> On Tuesday, February 7, 2017 at 3:00:05 AM UTC-5, Tom Gardner wrote: >>>> On 07/02/17 04:14, dagmargoodboat@yahoo.com wrote: >>>>> On Monday, February 6, 2017 at 10:08:19 PM UTC-5, Clifford Heath wrote: >>>> >>>>> You're not understanding--I'm fully aware that I can go so far as to >>>>> embed >>>>> assembly if I choose. >>>>> >>>>> The fact that the compiler is jumping though hoops to map virtual >>>>> pin numbers >>>>> to physical ports and pins is exactly my point: it's solving >>>>> problems that >>>>> a human programmer wouldn't have to. I'd just read-modify-write the >>>>> port >>>>> with the appropriate mask. >>>>> >>>>> BUT, what the naive users have and use, is layers and layers >>>>> abstracted from >>>>> the hardware doing the actual work. >>>> >>>> That's a major objective of libraries and >>>> environments in general. >>> >>> To an extent, true. More often my aim in using a pre-written function is >>> to avoid repeating the work, not avoiding understanding the task. >>> >>> 'C' was conceived as a portable assembly language, so it's bizarre and >>> ironic that this portable 'assembly' doesn't guarantee the size of its >>> basic variables--that's one of the most basic elements of assembly-level >>> programming. >> >> Porting C code has /always/ been very difficult, and required >> arcane knowledge and extreme care; start by considering >> "porting" from twos complement to ones complement machines. > > No, porting C code is not necessarily difficult. C makes it quite clear > what behaviour is full specified by the C standards, what is > implementation-specified (i.e., different compiler implementations can > do things in different ways, but they have to tell you their choices in > their documentation), and what is undefined (i.e., the standards make no > comment on what happens). > > If your code relies only on standards specified behaviour, and you use > conforming compilers, "porting" is just a matter of re-compiling. > > If your code relies on implementation-defined behaviour, then porting is > a matter of checking that the new compiler fits your requirements. > > If your code relies on undefined behaviour, you should fix the code > before you even think about porting. > > Now, it is certainly the case that a good deal of code relies on > implementation-dependent behaviour. And much of that does so in a /bad/ > way (such as making assumptions about the size of an "int"), making code > porting difficult, rather than in a /good/ way (such as using > implementation-dependent sized integer types). That is a problem with > the way C code is written, rather than a problem with C itself - and C99 > included useful changes to make it easier to write good portable code. While true, that argument has always struck me as unhelpfully splitting hairs. Gurus are different, of course, but are in limited supply. >> But from the late 80s onwards it has been unsuccessfully >> straddling two stools: that of a general purpose high level >> language for applications and also for low-level near-the-silicon >> "system/firmware" code. Consider that multithreading behaviour >> is (was?) explicitly left undefined or implementation dependent, >> but POSIX thread implementations relied on that behaviour. > > C has been, and continues to be, remarkably successful for such an > "unsuccessful" language. Strawman argument: I've never said C is "unsuccessful", and I didn't above. >> Maybe having a memory model will help, but it is astoundingly >> difficult to get that right across multiple architectures. > > That is why much of it is left undefined by the C standards. > Nonetheless, people seem to manage. Emphasis on "seem", especially with XP and TDD programming practices. Multithreading errors are notoriously difficult to reliably provoke during testing. As a hardware engineer, it has always surprised me how many such errors are made by most programmers. >> C++ is worse; the designers *discovered* they'd created >> a monstrosity where you can cause the compiler to emit >> the sequence of prime numbers during compilation. The >> designers didn't believe it until someone demonstrated it! > > The flexibility of templates was unintentional, but it is not a > "monstrosity" - it opened a new set of possibilities in the language. > The fact that you can compute prime numbers at compile-time with > templates does not mean that you /must/ compute prime numbers at > compile-time with templates - it is not a disadvantage in any way. Many > assemblers have powerful enough macro languages to let you generate > primes at compile time - no one makes a big deal out of that. > > With C++11, the language designers realised that powerful compile-time > computation functionality was actually very useful, but templates were a > cumbersome and inefficient way to do it - so they introduced constexpr > to make it easier. C++14 made it even more flexible and convenient. That's a strawman argument that avoids the point, to wit: "... the designers *discovered* they'd created ..." and "The designers didn't believe it until someone demonstrated it" I prefer languages to be designed, not uncovered.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-13 16:49 +0100 |
| Message-ID | <o7ske5$9su$1@dont-email.me> |
| In reply to | #447553 |
On 13/02/17 16:29, Tom Gardner wrote: > On 13/02/17 15:06, David Brown wrote: >> On 09/02/17 16:55, Tom Gardner wrote: >>> On 09/02/17 13:42, dagmargoodboat@yahoo.com wrote: >>>> On Tuesday, February 7, 2017 at 3:00:05 AM UTC-5, Tom Gardner wrote: >>>>> On 07/02/17 04:14, dagmargoodboat@yahoo.com wrote: >>>>>> On Monday, February 6, 2017 at 10:08:19 PM UTC-5, Clifford Heath >>>>>> wrote: >>>>> >>>>>> You're not understanding--I'm fully aware that I can go so far as to >>>>>> embed >>>>>> assembly if I choose. >>>>>> >>>>>> The fact that the compiler is jumping though hoops to map virtual >>>>>> pin numbers >>>>>> to physical ports and pins is exactly my point: it's solving >>>>>> problems that >>>>>> a human programmer wouldn't have to. I'd just read-modify-write the >>>>>> port >>>>>> with the appropriate mask. >>>>>> >>>>>> BUT, what the naive users have and use, is layers and layers >>>>>> abstracted from >>>>>> the hardware doing the actual work. >>>>> >>>>> That's a major objective of libraries and >>>>> environments in general. >>>> >>>> To an extent, true. More often my aim in using a pre-written >>>> function is >>>> to avoid repeating the work, not avoiding understanding the task. >>>> >>>> 'C' was conceived as a portable assembly language, so it's bizarre and >>>> ironic that this portable 'assembly' doesn't guarantee the size of its >>>> basic variables--that's one of the most basic elements of >>>> assembly-level >>>> programming. >>> >>> Porting C code has /always/ been very difficult, and required >>> arcane knowledge and extreme care; start by considering >>> "porting" from twos complement to ones complement machines. >> >> No, porting C code is not necessarily difficult. C makes it quite clear >> what behaviour is full specified by the C standards, what is >> implementation-specified (i.e., different compiler implementations can >> do things in different ways, but they have to tell you their choices in >> their documentation), and what is undefined (i.e., the standards make no >> comment on what happens). >> >> If your code relies only on standards specified behaviour, and you use >> conforming compilers, "porting" is just a matter of re-compiling. >> >> If your code relies on implementation-defined behaviour, then porting is >> a matter of checking that the new compiler fits your requirements. >> >> If your code relies on undefined behaviour, you should fix the code >> before you even think about porting. >> >> Now, it is certainly the case that a good deal of code relies on >> implementation-dependent behaviour. And much of that does so in a /bad/ >> way (such as making assumptions about the size of an "int"), making code >> porting difficult, rather than in a /good/ way (such as using >> implementation-dependent sized integer types). That is a problem with >> the way C code is written, rather than a problem with C itself - and C99 >> included useful changes to make it easier to write good portable code. > > While true, that argument has always struck me as unhelpfully > splitting hairs. If you write code that assumes it is safe to store a pointer in an int, then you will have more problems porting it than if you store your pointer in an intptr_t. If you write code that assumes an int is 32-bits, then you will have more problems than if you use an int32_t (or your own home-made equivalent type pre-C99 - then you only need to change one definition in your code). > > Gurus are different, of course, but are in limited supply. > > >>> But from the late 80s onwards it has been unsuccessfully >>> straddling two stools: that of a general purpose high level >>> language for applications and also for low-level near-the-silicon >>> "system/firmware" code. Consider that multithreading behaviour >>> is (was?) explicitly left undefined or implementation dependent, >>> but POSIX thread implementations relied on that behaviour. >> >> C has been, and continues to be, remarkably successful for such an >> "unsuccessful" language. > > Strawman argument: I've never said C is "unsuccessful", and > I didn't above. Fair enough. You said it "has been unsuccessfully straddling two stools". However, it has, in fact, been remarkably successful for both purposes. It has been pushed out from many "general purpose high-level language for application" uses - mainly because there are alternatives that give far better productivity rather than because C is so bad for the purpose. And C reigns supreme for "low-level near-the-silicon" code. > > >>> Maybe having a memory model will help, but it is astoundingly >>> difficult to get that right across multiple architectures. >> >> That is why much of it is left undefined by the C standards. >> Nonetheless, people seem to manage. > > Emphasis on "seem", especially with XP and TDD programming > practices. Multithreading errors are notoriously difficult > to reliably provoke during testing. As a hardware engineer, > it has always surprised me how many such errors are made > by most programmers. You can't get multi-threading correct by trial and error - you have to know what you are doing. That applies in all languages. C gives you no help there (though some C compilers do, with tools like gcc/clang's sanitizers), and certainly some other languages make it easier to get multi-threading right. > > >>> C++ is worse; the designers *discovered* they'd created >>> a monstrosity where you can cause the compiler to emit >>> the sequence of prime numbers during compilation. The >>> designers didn't believe it until someone demonstrated it! >> >> The flexibility of templates was unintentional, but it is not a >> "monstrosity" - it opened a new set of possibilities in the language. >> The fact that you can compute prime numbers at compile-time with >> templates does not mean that you /must/ compute prime numbers at >> compile-time with templates - it is not a disadvantage in any way. Many >> assemblers have powerful enough macro languages to let you generate >> primes at compile time - no one makes a big deal out of that. >> >> With C++11, the language designers realised that powerful compile-time >> computation functionality was actually very useful, but templates were a >> cumbersome and inefficient way to do it - so they introduced constexpr >> to make it easier. C++14 made it even more flexible and convenient. > > That's a strawman argument that avoids the point, to wit: > "... the designers *discovered* they'd created ..." and > "The designers didn't believe it until someone demonstrated > it" > > I prefer languages to be designed, not uncovered. > With any tool sufficiently complex, uses will be found beyond those conceived by the original designers.
[toc] | [prev] | [next] | [standalone]
| From | Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> |
|---|---|
| Date | 2017-02-13 10:55 -0500 |
| Message-ID | <2ImdnXcSYNtISzzFnZ2dnUU7-c_NnZ2d@supernews.com> |
| In reply to | #447556 |
On 02/13/2017 10:49 AM, David Brown wrote: > On 13/02/17 16:29, Tom Gardner wrote: >> On 13/02/17 15:06, David Brown wrote: >>> On 09/02/17 16:55, Tom Gardner wrote: >>>> On 09/02/17 13:42, dagmargoodboat@yahoo.com wrote: >>>>> On Tuesday, February 7, 2017 at 3:00:05 AM UTC-5, Tom Gardner wrote: >>>>>> On 07/02/17 04:14, dagmargoodboat@yahoo.com wrote: >>>>>>> On Monday, February 6, 2017 at 10:08:19 PM UTC-5, Clifford Heath >>>>>>> wrote: >>>>>> >>>>>>> You're not understanding--I'm fully aware that I can go so far as to >>>>>>> embed >>>>>>> assembly if I choose. >>>>>>> >>>>>>> The fact that the compiler is jumping though hoops to map virtual >>>>>>> pin numbers >>>>>>> to physical ports and pins is exactly my point: it's solving >>>>>>> problems that >>>>>>> a human programmer wouldn't have to. I'd just read-modify-write the >>>>>>> port >>>>>>> with the appropriate mask. >>>>>>> >>>>>>> BUT, what the naive users have and use, is layers and layers >>>>>>> abstracted from >>>>>>> the hardware doing the actual work. >>>>>> >>>>>> That's a major objective of libraries and >>>>>> environments in general. >>>>> >>>>> To an extent, true. More often my aim in using a pre-written >>>>> function is >>>>> to avoid repeating the work, not avoiding understanding the task. >>>>> >>>>> 'C' was conceived as a portable assembly language, so it's bizarre and >>>>> ironic that this portable 'assembly' doesn't guarantee the size of its >>>>> basic variables--that's one of the most basic elements of >>>>> assembly-level >>>>> programming. >>>> >>>> Porting C code has /always/ been very difficult, and required >>>> arcane knowledge and extreme care; start by considering >>>> "porting" from twos complement to ones complement machines. >>> >>> No, porting C code is not necessarily difficult. C makes it quite clear >>> what behaviour is full specified by the C standards, what is >>> implementation-specified (i.e., different compiler implementations can >>> do things in different ways, but they have to tell you their choices in >>> their documentation), and what is undefined (i.e., the standards make no >>> comment on what happens). >>> >>> If your code relies only on standards specified behaviour, and you use >>> conforming compilers, "porting" is just a matter of re-compiling. >>> >>> If your code relies on implementation-defined behaviour, then porting is >>> a matter of checking that the new compiler fits your requirements. >>> >>> If your code relies on undefined behaviour, you should fix the code >>> before you even think about porting. >>> >>> Now, it is certainly the case that a good deal of code relies on >>> implementation-dependent behaviour. And much of that does so in a /bad/ >>> way (such as making assumptions about the size of an "int"), making code >>> porting difficult, rather than in a /good/ way (such as using >>> implementation-dependent sized integer types). That is a problem with >>> the way C code is written, rather than a problem with C itself - and C99 >>> included useful changes to make it easier to write good portable code. >> >> While true, that argument has always struck me as unhelpfully >> splitting hairs. > > If you write code that assumes it is safe to store a pointer in an int, > then you will have more problems porting it than if you store your > pointer in an intptr_t. If you write code that assumes an int is > 32-bits, then you will have more problems than if you use an int32_t (or > your own home-made equivalent type pre-C99 - then you only need to > change one definition in your code). > >> >> Gurus are different, of course, but are in limited supply. >> >> >>>> But from the late 80s onwards it has been unsuccessfully >>>> straddling two stools: that of a general purpose high level >>>> language for applications and also for low-level near-the-silicon >>>> "system/firmware" code. Consider that multithreading behaviour >>>> is (was?) explicitly left undefined or implementation dependent, >>>> but POSIX thread implementations relied on that behaviour. >>> >>> C has been, and continues to be, remarkably successful for such an >>> "unsuccessful" language. >> >> Strawman argument: I've never said C is "unsuccessful", and >> I didn't above. > > Fair enough. You said it "has been unsuccessfully straddling two > stools". However, it has, in fact, been remarkably successful for both > purposes. It has been pushed out from many "general purpose high-level > language for application" uses - mainly because there are alternatives > that give far better productivity rather than because C is so bad for > the purpose. And C reigns supreme for "low-level near-the-silicon" code. > >> >> >>>> Maybe having a memory model will help, but it is astoundingly >>>> difficult to get that right across multiple architectures. >>> >>> That is why much of it is left undefined by the C standards. >>> Nonetheless, people seem to manage. >> >> Emphasis on "seem", especially with XP and TDD programming >> practices. Multithreading errors are notoriously difficult >> to reliably provoke during testing. As a hardware engineer, >> it has always surprised me how many such errors are made >> by most programmers. > > You can't get multi-threading correct by trial and error - you have to > know what you are doing. That applies in all languages. C gives you no > help there (though some C compilers do, with tools like gcc/clang's > sanitizers), and certainly some other languages make it easier to get > multi-threading right. Thread support is finally getting someplace reasonable, it looks like. BITD you just had to use 'volatile' and boatloads of mutexes, and hope the undefined behaviour you were forced to rely on stayed consistent from release to release. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.net
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-02-13 17:09 +0000 |
| Message-ID | <_KloA.810509$SP.403937@fx43.am4> |
| In reply to | #447558 |
On 13/02/17 15:55, Phil Hobbs wrote: > On 02/13/2017 10:49 AM, David Brown wrote: >> On 13/02/17 16:29, Tom Gardner wrote: >>> On 13/02/17 15:06, David Brown wrote: >>>> On 09/02/17 16:55, Tom Gardner wrote: >>>>> On 09/02/17 13:42, dagmargoodboat@yahoo.com wrote: >>>>>> On Tuesday, February 7, 2017 at 3:00:05 AM UTC-5, Tom Gardner wrote: >>>>>>> On 07/02/17 04:14, dagmargoodboat@yahoo.com wrote: >>>>>>>> On Monday, February 6, 2017 at 10:08:19 PM UTC-5, Clifford Heath >>>>>>>> wrote: >>>>>>> >>>>>>>> You're not understanding--I'm fully aware that I can go so far as to >>>>>>>> embed >>>>>>>> assembly if I choose. >>>>>>>> >>>>>>>> The fact that the compiler is jumping though hoops to map virtual >>>>>>>> pin numbers >>>>>>>> to physical ports and pins is exactly my point: it's solving >>>>>>>> problems that >>>>>>>> a human programmer wouldn't have to. I'd just read-modify-write the >>>>>>>> port >>>>>>>> with the appropriate mask. >>>>>>>> >>>>>>>> BUT, what the naive users have and use, is layers and layers >>>>>>>> abstracted from >>>>>>>> the hardware doing the actual work. >>>>>>> >>>>>>> That's a major objective of libraries and >>>>>>> environments in general. >>>>>> >>>>>> To an extent, true. More often my aim in using a pre-written >>>>>> function is >>>>>> to avoid repeating the work, not avoiding understanding the task. >>>>>> >>>>>> 'C' was conceived as a portable assembly language, so it's bizarre and >>>>>> ironic that this portable 'assembly' doesn't guarantee the size of its >>>>>> basic variables--that's one of the most basic elements of >>>>>> assembly-level >>>>>> programming. >>>>> >>>>> Porting C code has /always/ been very difficult, and required >>>>> arcane knowledge and extreme care; start by considering >>>>> "porting" from twos complement to ones complement machines. >>>> >>>> No, porting C code is not necessarily difficult. C makes it quite clear >>>> what behaviour is full specified by the C standards, what is >>>> implementation-specified (i.e., different compiler implementations can >>>> do things in different ways, but they have to tell you their choices in >>>> their documentation), and what is undefined (i.e., the standards make no >>>> comment on what happens). >>>> >>>> If your code relies only on standards specified behaviour, and you use >>>> conforming compilers, "porting" is just a matter of re-compiling. >>>> >>>> If your code relies on implementation-defined behaviour, then porting is >>>> a matter of checking that the new compiler fits your requirements. >>>> >>>> If your code relies on undefined behaviour, you should fix the code >>>> before you even think about porting. >>>> >>>> Now, it is certainly the case that a good deal of code relies on >>>> implementation-dependent behaviour. And much of that does so in a /bad/ >>>> way (such as making assumptions about the size of an "int"), making code >>>> porting difficult, rather than in a /good/ way (such as using >>>> implementation-dependent sized integer types). That is a problem with >>>> the way C code is written, rather than a problem with C itself - and C99 >>>> included useful changes to make it easier to write good portable code. >>> >>> While true, that argument has always struck me as unhelpfully >>> splitting hairs. >> >> If you write code that assumes it is safe to store a pointer in an int, >> then you will have more problems porting it than if you store your >> pointer in an intptr_t. If you write code that assumes an int is >> 32-bits, then you will have more problems than if you use an int32_t (or >> your own home-made equivalent type pre-C99 - then you only need to >> change one definition in your code). >> >>> >>> Gurus are different, of course, but are in limited supply. >>> >>> >>>>> But from the late 80s onwards it has been unsuccessfully >>>>> straddling two stools: that of a general purpose high level >>>>> language for applications and also for low-level near-the-silicon >>>>> "system/firmware" code. Consider that multithreading behaviour >>>>> is (was?) explicitly left undefined or implementation dependent, >>>>> but POSIX thread implementations relied on that behaviour. >>>> >>>> C has been, and continues to be, remarkably successful for such an >>>> "unsuccessful" language. >>> >>> Strawman argument: I've never said C is "unsuccessful", and >>> I didn't above. >> >> Fair enough. You said it "has been unsuccessfully straddling two >> stools". However, it has, in fact, been remarkably successful for both >> purposes. It has been pushed out from many "general purpose high-level >> language for application" uses - mainly because there are alternatives >> that give far better productivity rather than because C is so bad for >> the purpose. And C reigns supreme for "low-level near-the-silicon" code. >> >>> >>> >>>>> Maybe having a memory model will help, but it is astoundingly >>>>> difficult to get that right across multiple architectures. >>>> >>>> That is why much of it is left undefined by the C standards. >>>> Nonetheless, people seem to manage. >>> >>> Emphasis on "seem", especially with XP and TDD programming >>> practices. Multithreading errors are notoriously difficult >>> to reliably provoke during testing. As a hardware engineer, >>> it has always surprised me how many such errors are made >>> by most programmers. >> >> You can't get multi-threading correct by trial and error - you have to >> know what you are doing. That applies in all languages. C gives you no >> help there (though some C compilers do, with tools like gcc/clang's >> sanitizers), and certainly some other languages make it easier to get >> multi-threading right. > > Thread support is finally getting someplace reasonable, it looks like. > BITD you just had to use 'volatile' and boatloads of mutexes, and hope > the undefined behaviour you were forced to rely on stayed consistent > from release to release. Yes, and let's hope so - but in this respect I'm a "kick the tyres" guy. I suspect it will be quite a few years before the problems are apparent and ironed out. It is notable that Java, even though having a much better starting point and more decades of experiences, had to revise its memory model after ~10 years. Very few developers noticed.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-14 09:49 +0100 |
| Message-ID | <o7ug6m$vg2$1@dont-email.me> |
| In reply to | #447558 |
On 13/02/17 16:55, Phil Hobbs wrote: > On 02/13/2017 10:49 AM, David Brown wrote: >> >> You can't get multi-threading correct by trial and error - you have to >> know what you are doing. That applies in all languages. C gives you no >> help there (though some C compilers do, with tools like gcc/clang's >> sanitizers), and certainly some other languages make it easier to get >> multi-threading right. > > Thread support is finally getting someplace reasonable, it looks like. > BITD you just had to use 'volatile' and boatloads of mutexes, and hope > the undefined behaviour you were forced to rely on stayed consistent > from release to release. > That depends on the processor and the target architecture - with a simple enough system, "volatile" can be enough if you use it correctly. But usually you need some implementation-specific features - such as inline assembly for memory barriers, cache flushes, "sync" instructions, etc. Or you use an RTOS with this done for you. With C11/C++11 there are atomics, which can make it easier to get things right. But you still need to know what you are doing, especially if your target is multi-core, super-scaler with caches, buffers and the rest of it.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-02-13 16:07 +0000 |
| Message-ID | <9RkoA.318418$a22.98578@fx28.am4> |
| In reply to | #447556 |
On 13/02/17 15:49, David Brown wrote: > On 13/02/17 16:29, Tom Gardner wrote: >> On 13/02/17 15:06, David Brown wrote: >>> On 09/02/17 16:55, Tom Gardner wrote: >>>> On 09/02/17 13:42, dagmargoodboat@yahoo.com wrote: >>>>> On Tuesday, February 7, 2017 at 3:00:05 AM UTC-5, Tom Gardner wrote: >>>>>> On 07/02/17 04:14, dagmargoodboat@yahoo.com wrote: >>>>>>> On Monday, February 6, 2017 at 10:08:19 PM UTC-5, Clifford Heath >>>>>>> wrote: >>>>>> >>>>>>> You're not understanding--I'm fully aware that I can go so far as to >>>>>>> embed >>>>>>> assembly if I choose. >>>>>>> >>>>>>> The fact that the compiler is jumping though hoops to map virtual >>>>>>> pin numbers >>>>>>> to physical ports and pins is exactly my point: it's solving >>>>>>> problems that >>>>>>> a human programmer wouldn't have to. I'd just read-modify-write the >>>>>>> port >>>>>>> with the appropriate mask. >>>>>>> >>>>>>> BUT, what the naive users have and use, is layers and layers >>>>>>> abstracted from >>>>>>> the hardware doing the actual work. >>>>>> >>>>>> That's a major objective of libraries and >>>>>> environments in general. >>>>> >>>>> To an extent, true. More often my aim in using a pre-written >>>>> function is >>>>> to avoid repeating the work, not avoiding understanding the task. >>>>> >>>>> 'C' was conceived as a portable assembly language, so it's bizarre and >>>>> ironic that this portable 'assembly' doesn't guarantee the size of its >>>>> basic variables--that's one of the most basic elements of >>>>> assembly-level >>>>> programming. >>>> >>>> Porting C code has /always/ been very difficult, and required >>>> arcane knowledge and extreme care; start by considering >>>> "porting" from twos complement to ones complement machines. >>> >>> No, porting C code is not necessarily difficult. C makes it quite clear >>> what behaviour is full specified by the C standards, what is >>> implementation-specified (i.e., different compiler implementations can >>> do things in different ways, but they have to tell you their choices in >>> their documentation), and what is undefined (i.e., the standards make no >>> comment on what happens). >>> >>> If your code relies only on standards specified behaviour, and you use >>> conforming compilers, "porting" is just a matter of re-compiling. >>> >>> If your code relies on implementation-defined behaviour, then porting is >>> a matter of checking that the new compiler fits your requirements. >>> >>> If your code relies on undefined behaviour, you should fix the code >>> before you even think about porting. >>> >>> Now, it is certainly the case that a good deal of code relies on >>> implementation-dependent behaviour. And much of that does so in a /bad/ >>> way (such as making assumptions about the size of an "int"), making code >>> porting difficult, rather than in a /good/ way (such as using >>> implementation-dependent sized integer types). That is a problem with >>> the way C code is written, rather than a problem with C itself - and C99 >>> included useful changes to make it easier to write good portable code. >> >> While true, that argument has always struck me as unhelpfully >> splitting hairs. > > If you write code that assumes it is safe to store a pointer in an int, > then you will have more problems porting it than if you store your > pointer in an intptr_t. If you write code that assumes an int is > 32-bits, then you will have more problems than if you use an int32_t (or > your own home-made equivalent type pre-C99 - then you only need to > change one definition in your code). That's been a well-known error for >35 years, and is probably taught in schools :) Unfortunately there are far too many more subtle traps that continue to catch out experienced programmers. >> Gurus are different, of course, but are in limited supply. >> >> >>>> But from the late 80s onwards it has been unsuccessfully >>>> straddling two stools: that of a general purpose high level >>>> language for applications and also for low-level near-the-silicon >>>> "system/firmware" code. Consider that multithreading behaviour >>>> is (was?) explicitly left undefined or implementation dependent, >>>> but POSIX thread implementations relied on that behaviour. >>> >>> C has been, and continues to be, remarkably successful for such an >>> "unsuccessful" language. >> >> Strawman argument: I've never said C is "unsuccessful", and >> I didn't above. > > Fair enough. You said it "has been unsuccessfully straddling two > stools". However, it has, in fact, been remarkably successful for both > purposes. It has been pushed out from many "general purpose high-level > language for application" uses - mainly because there are alternatives > that give far better productivity rather than because C is so bad for > the purpose. Not just productivity. More modern and more closely specified languages enable the correct construction of far more complex and ambitious systems, including by typical programmers. Which enables them to make new classes of cockup :( (But as I taught my daughter, "let's make new mistakes") > And C reigns supreme for "low-level near-the-silicon" code. Agreed. But there are other's coming along in the that domain; maybe some will succeed. C will never disappear, just as Cobol and PDP11s are still around. >>>> Maybe having a memory model will help, but it is astoundingly >>>> difficult to get that right across multiple architectures. >>> >>> That is why much of it is left undefined by the C standards. >>> Nonetheless, people seem to manage. >> >> Emphasis on "seem", especially with XP and TDD programming >> practices. Multithreading errors are notoriously difficult >> to reliably provoke during testing. As a hardware engineer, >> it has always surprised me how many such errors are made >> by most programmers. > > You can't get multi-threading correct by trial and error - you have to > know what you are doing. That applies in all languages. C gives you no > help there (though some C compilers do, with tools like gcc/clang's > sanitizers), and certainly some other languages make it easier to get > multi-threading right. Of course. But C goes further by actively stating that such considerations are outside the scope of C and are the libraries' responsibility. Which would be fine except that the libraries have to rely on things that C avoids specifying. (Caveat: maybe not the latest incarnations) Consequence: either the compiler+libraries must be a unit, or there might be subtle errors lurking in corners. And "compiler" means the specific version of a compiler, since they change over time. >>>> C++ is worse; the designers *discovered* they'd created >>>> a monstrosity where you can cause the compiler to emit >>>> the sequence of prime numbers during compilation. The >>>> designers didn't believe it until someone demonstrated it! >>> >>> The flexibility of templates was unintentional, but it is not a >>> "monstrosity" - it opened a new set of possibilities in the language. >>> The fact that you can compute prime numbers at compile-time with >>> templates does not mean that you /must/ compute prime numbers at >>> compile-time with templates - it is not a disadvantage in any way. Many >>> assemblers have powerful enough macro languages to let you generate >>> primes at compile time - no one makes a big deal out of that. >>> >>> With C++11, the language designers realised that powerful compile-time >>> computation functionality was actually very useful, but templates were a >>> cumbersome and inefficient way to do it - so they introduced constexpr >>> to make it easier. C++14 made it even more flexible and convenient. >> >> That's a strawman argument that avoids the point, to wit: >> "... the designers *discovered* they'd created ..." and >> "The designers didn't believe it until someone demonstrated >> it" >> >> I prefer languages to be designed, not uncovered. >> > > With any tool sufficiently complex, uses will be found beyond those > conceived by the original designers. Sure, but that's not the point, is it!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-14 10:01 +0100 |
| Message-ID | <o7ugtl$20f$1@dont-email.me> |
| In reply to | #447563 |
On 13/02/17 17:07, Tom Gardner wrote: > On 13/02/17 15:49, David Brown wrote: >> On 13/02/17 16:29, Tom Gardner wrote: >> <snip> >> Fair enough. You said it "has been unsuccessfully straddling two >> stools". However, it has, in fact, been remarkably successful for both >> purposes. It has been pushed out from many "general purpose high-level >> language for application" uses - mainly because there are alternatives >> that give far better productivity rather than because C is so bad for >> the purpose. > > Not just productivity. > > More modern and more closely specified languages enable > the correct construction of far more complex and > ambitious systems, including by typical programmers. > Yes, but these go hand-in-hand. In C, I could write code for an efficient and leak-free string indexed hash table. But in Python, I can use "ht = dict()" and it's done. (In C++, I could look up the right headers and the convoluted template syntax, and it is done in half a dozen lines - it's a compromise.) The greater productivity means I can write more advanced systems. (I mostly use C on embedded systems, and mostly Python on PC's.) > Which enables them to make new classes of cockup :( > (But as I taught my daughter, "let's make new mistakes") > It's called "learning by experience" :-) And it's more enjoyable than making the same mistakes again and again. > >> And C reigns supreme for "low-level near-the-silicon" code. > > Agreed. But there are other's coming along in the that > domain; maybe some will succeed. C++ is taking over more, and we are seeing more embedded systems written in higher-level code than before (use an 800 MHz ARM running Linux and Python instead of a 40 MHz ARM running C or C++). But it will be a long time before any of the newcomers like Go or Rust are realistic for the low-level code. > > C will never disappear, just as Cobol and PDP11s > are still around. No - C is still popular, unlike Cobol and PDP11's. New stuff is written in C. Its longevity, portability and stability are some of its key selling points. > > >>>>> Maybe having a memory model will help, but it is astoundingly >>>>> difficult to get that right across multiple architectures. >>>> >>>> That is why much of it is left undefined by the C standards. >>>> Nonetheless, people seem to manage. >>> >>> Emphasis on "seem", especially with XP and TDD programming >>> practices. Multithreading errors are notoriously difficult >>> to reliably provoke during testing. As a hardware engineer, >>> it has always surprised me how many such errors are made >>> by most programmers. >> >> You can't get multi-threading correct by trial and error - you have to >> know what you are doing. That applies in all languages. C gives you no >> help there (though some C compilers do, with tools like gcc/clang's >> sanitizers), and certainly some other languages make it easier to get >> multi-threading right. > > Of course. > > But C goes further by actively stating that such > considerations are outside the scope of C and are > the libraries' responsibility. Which would be fine > except that the libraries have to rely on things > that C avoids specifying. (Caveat: maybe not the > latest incarnations) > > Consequence: either the compiler+libraries must > be a unit, or there might be subtle errors lurking > in corners. And "compiler" means the specific > version of a compiler, since they change over time. > Yes. This has always been the way of C. The language is specifically designed for two different types of coding - portable coding written to match the standards-defined behaviour so that the same code can be used on a wide variety of systems, and implementation-specific coding written to get the best out of a particular target or to use features that cannot be portable.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-02-14 09:49 +0000 |
| Message-ID | <ooAoA.320053$he2.176095@fx22.am4> |
| In reply to | #447624 |
On 14/02/17 09:01, David Brown wrote:
> On 13/02/17 17:07, Tom Gardner wrote:
>> On 13/02/17 15:49, David Brown wrote:
>>> On 13/02/17 16:29, Tom Gardner wrote:
>>>
> <snip>
Neatly and accurately snipped :)
>>> Fair enough. You said it "has been unsuccessfully straddling two
>>> stools". However, it has, in fact, been remarkably successful for both
>>> purposes. It has been pushed out from many "general purpose high-level
>>> language for application" uses - mainly because there are alternatives
>>> that give far better productivity rather than because C is so bad for
>>> the purpose.
>>
>> Not just productivity.
>>
>> More modern and more closely specified languages enable
>> the correct construction of far more complex and
>> ambitious systems, including by typical programmers.
>>
>
> Yes, but these go hand-in-hand. In C, I could write code for an
> efficient and leak-free string indexed hash table. But in Python, I can
> use "ht = dict()" and it's done. (In C++, I could look up the right
> headers and the convoluted template syntax, and it is done in half a
> dozen lines - it's a compromise.) The greater productivity means I can
> write more advanced systems.
I was spoiled by using Smalltalk when it came to
container classes. I was dismayed, but not surprised,
at how difficult they are to do well in C++ - and at
how many years it took before the first (not very usable)
implementations became available.
With Java I was pleased, but not /too/ surprised, at how
quickly high quality libraries were available from many
many sources. The contrast with C++ was compelling.
> (I mostly use C on embedded systems, and mostly Python on PC's.)
Choosing the right tool for the job - one of the
key attributes of an engineer :)
I've used a bit of Python, and it seems OK, except that
pretty print reformatting is unreliable /by design/.
I remember makefiles, where the invisible difference
between tabs and spaces was semantically crucial :(
>> Which enables them to make new classes of cockup :(
>> (But as I taught my daughter, "let's make new mistakes")
>>
>
> It's called "learning by experience" :-) And it's more enjoyable than
> making the same mistakes again and again.
Just so :)
>>> And C reigns supreme for "low-level near-the-silicon" code.
>>
>> Agreed. But there are other's coming along in the that
>> domain; maybe some will succeed.
>
> C++ is taking over more, and we are seeing more embedded systems written
> in higher-level code than before (use an 800 MHz ARM running Linux and
> Python instead of a 40 MHz ARM running C or C++). But it will be a long
> time before any of the newcomers like Go or Rust are realistic for the
> low-level code.
>
>>
>> C will never disappear, just as Cobol and PDP11s
>> are still around.
>
> No - C is still popular, unlike Cobol and PDP11's. New stuff is written
> in C. Its longevity, portability and stability are some of its key
> selling points.
True, but has it reached an inflection point?
I wonder if INFOSEC will turn out to be a significant
pressure. Time will tell.
>>>>>> Maybe having a memory model will help, but it is astoundingly
>>>>>> difficult to get that right across multiple architectures.
>>>>>
>>>>> That is why much of it is left undefined by the C standards.
>>>>> Nonetheless, people seem to manage.
>>>>
>>>> Emphasis on "seem", especially with XP and TDD programming
>>>> practices. Multithreading errors are notoriously difficult
>>>> to reliably provoke during testing. As a hardware engineer,
>>>> it has always surprised me how many such errors are made
>>>> by most programmers.
>>>
>>> You can't get multi-threading correct by trial and error - you have to
>>> know what you are doing. That applies in all languages. C gives you no
>>> help there (though some C compilers do, with tools like gcc/clang's
>>> sanitizers), and certainly some other languages make it easier to get
>>> multi-threading right.
>>
>> Of course.
>>
>> But C goes further by actively stating that such
>> considerations are outside the scope of C and are
>> the libraries' responsibility. Which would be fine
>> except that the libraries have to rely on things
>> that C avoids specifying. (Caveat: maybe not the
>> latest incarnations)
>>
>> Consequence: either the compiler+libraries must
>> be a unit, or there might be subtle errors lurking
>> in corners. And "compiler" means the specific
>> version of a compiler, since they change over time.
>>
>
> Yes. This has always been the way of C. The language is specifically
> designed for two different types of coding - portable coding written to
> match the standards-defined behaviour so that the same code can be used
> on a wide variety of systems, and implementation-specific coding written
> to get the best out of a particular target or to use features that
> cannot be portable.
A question is then whether an employer can obtain
the relevant skills for design implementation /and/
/maintenance/.
Everything I've seen and heard indicates that while
it /appears/ possible, in practice there are latent
faults that will bit you.
Mind you, I've seen crap written in many languages.
One project I've seen wasn't at all concerned about
a liberal injection of
try {
...
} (catch NullPointerException) {
// nothing here!
}
used to solve the problem of unit tests failing.
[toc] | [prev] | [next] | [standalone]
| From | Clifford Heath <no.spam@please.net> |
|---|---|
| Date | 2017-02-17 04:21 +1100 |
| Message-ID | <58a61fa6$0$32665$b1db1813$19ace300@news.astraweb.com> |
| In reply to | #447547 |
On 14/02/17 02:06, David Brown wrote: > On 09/02/17 16:55, Tom Gardner wrote: > With C++11, the language designers realised that powerful compile-time > computation functionality was actually very useful, but templates were a > cumbersome and inefficient way to do it - so they introduced constexpr > to make it easier. C++14 made it even more flexible and convenient. > >> No, nowadays C++ is beyond mortal's comprehension, and >> C isn't much better. > > Perhaps it is beyond /your/ comprehension. Certainly C++ is a large and > complex language, and you can write code in it that is difficult to > understand without a good deal of experience. Overheard today: "The 11 in C++11 refers to the number of legs that have now been nailed onto the dog whilst attempting to build a better octopus." :)
[toc] | [prev] | [next] | [standalone]
| From | pcdhobbs@gmail.com |
|---|---|
| Date | 2017-02-16 14:47 -0800 |
| Message-ID | <1de8eb05-befe-42cf-bc58-ad4fb66b811a@googlegroups.com> |
| In reply to | #447918 |
On Thursday, February 16, 2017 at 4:54:50 PM UTC-5, Clifford Heath wrote: > On 14/02/17 02:06, David Brown wrote: > > On 09/02/17 16:55, Tom Gardner wrote: > > With C++11, the language designers realised that powerful compile-time > > computation functionality was actually very useful, but templates were a > > cumbersome and inefficient way to do it - so they introduced constexpr > > to make it easier. C++14 made it even more flexible and convenient. > > > >> No, nowadays C++ is beyond mortal's comprehension, and > >> C isn't much better. > > > > Perhaps it is beyond /your/ comprehension. Certainly C++ is a large and > > complex language, and you can write code in it that is difficult to > > understand without a good deal of experience. > > Overheard today: "The 11 in C++11 refers to the number of legs that have > now been nailed onto the dog whilst attempting to build a better octopus." > > :) As the man said (paraphrasing Shakespeare), "First let's kill all the language lawyers." ;) Cheers Phil Hobbs
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-02-17 00:17 +0000 |
| Message-ID | <airpA.72762$qT.824@fx45.am4> |
| In reply to | #447929 |
On 16/02/17 22:47, pcdhobbs@gmail.com wrote: > On Thursday, February 16, 2017 at 4:54:50 PM UTC-5, Clifford Heath wrote: >> On 14/02/17 02:06, David Brown wrote: >>> On 09/02/17 16:55, Tom Gardner wrote: >>> With C++11, the language designers realised that powerful compile-time >>> computation functionality was actually very useful, but templates were a >>> cumbersome and inefficient way to do it - so they introduced constexpr >>> to make it easier. C++14 made it even more flexible and convenient. >>> >>>> No, nowadays C++ is beyond mortal's comprehension, and >>>> C isn't much better. >>> >>> Perhaps it is beyond /your/ comprehension. Certainly C++ is a large and >>> complex language, and you can write code in it that is difficult to >>> understand without a good deal of experience. >> >> Overheard today: "The 11 in C++11 refers to the number of legs that have >> now been nailed onto the dog whilst attempting to build a better octopus." >> >> :) > As the man said (paraphrasing Shakespeare), "First let's kill all the language lawyers." ;) I'd prefer to "dispose of" the reason they are necessary :(
[toc] | [prev] | [next] | [standalone]
| From | Clifford Heath <no.spam@please.net> |
|---|---|
| Date | 2017-02-07 19:49 +1100 |
| Message-ID | <58998a2d$0$29547$c3e8da3$c8b7d2e6@news.astraweb.com> |
| In reply to | #446595 |
On 07/02/17 15:14, dagmargoodboat@yahoo.com wrote: > On Monday, February 6, 2017 at 10:08:19 PM UTC-5, Clifford Heath wrote: >> On 07/02/17 13:41, dagmargoodboat@yahoo.com wrote: >>> On Monday, February 6, 2017 at 7:04:15 PM UTC-5, Lasse Langwadt Christensen wrote: >>>> Den tirsdag den 7. februar 2017 kl. 00.43.55 UTC+1 skrev dagmarg...@yahoo.com: >>>>> I've heard the kids here opine compilers are so good >>>>> these days that assembly makes no sense. >>>>> >>>>> There's lots to be said for high-level languages. But >>>>> I disassembled some Arduino code--here's the output to >>>>> write a port pin (a built-in function): >>>>> >>>> >>>> that is to say the least comparing apples to oranges, the build in >>>> function handles all the checks if it is valid pin, possibly controlled >>>> with a timer etc. so it work on multiple platforms without you needing >>>> to know much about the underlaying HW >>>> >>>> you can write directly to PORTD on the AVR if you like >>> >>> Yes, understood. But isn't that always the problem? The compiler's >>> always generating for some general case, which the assembly programmer >>> need not do. >> >> No, that's not the problem. The problem is that digitalWrite takes >> a *logical* pin number, which is meant to map to the Arduino footprint >> for a range of different Arduino types, even though those bring a >> different port pin to that logical pin. >> >> If you had written (not checked, but like): >> >> *((uint8_t*)PORTD) = 0; >> or >> *((uint8_t*)PORTD) |= 0x1; >> >> Then you would get the appropriate minimal I/O instructions from >> any recent Arduino gcc compiler. > > You're not understanding--I'm fully aware that I can go so far as to embed > assembly if I choose. I wasn't suggesting that. You blamed the digitalWrite problem on the compiler, and I'm showing that it's the Arduino API you should be blaming, that's all. The above C fragments should be hidden as C++ inlined template functions, which would make them beautifully clean yet still just a single opcode. > The fact that the compiler is jumping though hoops to map virtual pin numbers > to physical ports and pins is exactly my point: it's solving problems that > a human programmer wouldn't have to. The compiler is not doing that. The designers of the Arduino API did that. It would be just as bad if they did it in assembly code. > BUT, what the naive users have and use, is layers and layers abstracted from > the hardware doing the actual work. Only the naive users use those layers, and those who know but who don't need to care. >>> It wasn't just the digitalWrite() -- lots of pushes and pops, subroutine >>> calls to subroutine calls, etc. for my regular code. >> >> Use of subroutine calls is your prerogative, neither gcc nor asm can >> really circumvent those decisions... however... > Not so--it's using all sorts of calls to functions within functions as > part of its standard environment. Again, this is primarily the Arduino API, not the compiler. >> Did you use a high optimisation level? gcc is pretty good at inlining >> code if and when it can see that's possible. > I can't control it. The IDE controls the build process from start to > finish. Yes, you can, see my other message. > It might've been easier for me to skip the Arduino IDE and write straight > gcc, or even bare assembly, but the Arduino environment is a lot less > intimidating for the customer. Swings, roundabouts. If you use libraries built by careless incompetent amateurs, you pay the price. >> The Arduino APIs are far from well-designed, for the most part. > It's cute, and has gotten a lot of hobbyists started. Lots of enthusiasm. Yes. But the same goals could have been achieved without writing so much rubbish code. I expect to get back to Arduino code soon, and that will mean finishing my C++ template library that handles port pins properly, among other things. I'll make it public when I'm happy with it. Clifford Heath.
[toc] | [prev] | [next] | [standalone]
| From | dagmargoodboat@yahoo.com |
|---|---|
| Date | 2017-02-09 06:22 -0800 |
| Message-ID | <a101f9c2-ac43-465c-95bc-2b6115e9663f@googlegroups.com> |
| In reply to | #446617 |
On Tuesday, February 7, 2017 at 3:49:52 AM UTC-5, Clifford Heath wrote: > On 07/02/17 15:14, dagmargoodboat@yahoo.com wrote: > > On Monday, February 6, 2017 at 10:08:19 PM UTC-5, Clifford Heath wrote: > >> On 07/02/17 13:41, dagmargoodboat@yahoo.com wrote: > >>> On Monday, February 6, 2017 at 7:04:15 PM UTC-5, Lasse Langwadt Christensen wrote: > >>>> Den tirsdag den 7. februar 2017 kl. 00.43.55 UTC+1 skrev dagmarg...@yahoo.com: > >>>>> I've heard the kids here opine compilers are so good > >>>>> these days that assembly makes no sense. > >>>>> > >>>>> There's lots to be said for high-level languages. But > >>>>> I disassembled some Arduino code--here's the output to > >>>>> write a port pin (a built-in function): > >>>>> > >>>> > >>>> that is to say the least comparing apples to oranges, the build in > >>>> function handles all the checks if it is valid pin, possibly controlled > >>>> with a timer etc. so it work on multiple platforms without you needing > >>>> to know much about the underlaying HW > >>>> > >>>> you can write directly to PORTD on the AVR if you like > >>> > >>> Yes, understood. But isn't that always the problem? The compiler's > >>> always generating for some general case, which the assembly programmer > >>> need not do. > >> > >> No, that's not the problem. The problem is that digitalWrite takes > >> a *logical* pin number, which is meant to map to the Arduino footprint > >> for a range of different Arduino types, even though those bring a > >> different port pin to that logical pin. > >> > >> If you had written (not checked, but like): > >> > >> *((uint8_t*)PORTD) = 0; > >> or > >> *((uint8_t*)PORTD) |= 0x1; > >> > >> Then you would get the appropriate minimal I/O instructions from > >> any recent Arduino gcc compiler. > > > > You're not understanding--I'm fully aware that I can go so far as to embed > > assembly if I choose. > > I wasn't suggesting that. You blamed the digitalWrite problem on > the compiler, and I'm showing that it's the Arduino API you > should be blaming, that's all. > > The above C fragments should be hidden as C++ inlined template > functions, which would make them beautifully clean yet still just > a single opcode. > > > The fact that the compiler is jumping though hoops to map virtual pin numbers > > to physical ports and pins is exactly my point: it's solving problems that > > a human programmer wouldn't have to. > > The compiler is not doing that. The designers of the Arduino API did > that. It would be just as bad if they did it in assembly code. Well you're right, I've been loosely referring to the development environment as a monolithic thing, which we all know it is not. So I suppose I should've phrased my original lament as "look at the systems upcoming programmers are relying on to generate code these days." > > BUT, what the naive users have and use, is layers and layers abstracted from > > the hardware doing the actual work. > > Only the naive users use those layers, and those who know but > who don't need to care. "Those who say, don't know; those who know, don't say." --Lao Tzu > >>> It wasn't just the digitalWrite() -- lots of pushes and pops, subroutine > >>> calls to subroutine calls, etc. for my regular code. > >> > >> Use of subroutine calls is your prerogative, neither gcc nor asm can > >> really circumvent those decisions... however... > > Not so--it's using all sorts of calls to functions within functions as > > part of its standard environment. > > Again, this is primarily the Arduino API, not the compiler. There was a fair load from calling C++ constructors, also. > >> Did you use a high optimisation level? gcc is pretty good at inlining > >> code if and when it can see that's possible. > > I can't control it. The IDE controls the build process from start to > > finish. > > Yes, you can, see my other message. > > > It might've been easier for me to skip the Arduino IDE and write straight > > gcc, or even bare assembly, but the Arduino environment is a lot less > > intimidating for the customer. > > Swings, roundabouts. If you use libraries built by careless > incompetent amateurs, you pay the price. > > >> The Arduino APIs are far from well-designed, for the most part. > > It's cute, and has gotten a lot of hobbyists started. Lots of enthusiasm. > > Yes. But the same goals could have been achieved without writing > so much rubbish code. > > I expect to get back to Arduino code soon, and that will mean > finishing my C++ template library that handles port pins properly, > among other things. I'll make it public when I'm happy with it. That would be a magnanimous gesture. Perhaps the biggest service Arduino has done is providing a platform whereby one person can make a contribution like that, and benefit millions. That's incredible leverage. Let's hope mankind uses all of this leverage to make the world a better, safer place, and not for interfacing IEDs with cellphones. Cheers, James Arthur
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-07 10:42 +0100 |
| Message-ID | <o7c4nm$9nj$1@dont-email.me> |
| In reply to | #446595 |
On 07/02/17 05:14, dagmargoodboat@yahoo.com wrote: > On Monday, February 6, 2017 at 10:08:19 PM UTC-5, Clifford Heath wrote: >> On 07/02/17 13:41, dagmargoodboat@yahoo.com wrote: >>> On Monday, February 6, 2017 at 7:04:15 PM UTC-5, Lasse Langwadt Christensen wrote: >>>> Den tirsdag den 7. februar 2017 kl. 00.43.55 UTC+1 skrev dagmarg...@yahoo.com: >>>>> I've heard the kids here opine compilers are so good >>>>> these days that assembly makes no sense. >>>>> >>>>> There's lots to be said for high-level languages. But >>>>> I disassembled some Arduino code--here's the output to >>>>> write a port pin (a built-in function): >>>>> >>>> >>>> that is to say the least comparing apples to oranges, the build in >>>> function handles all the checks if it is valid pin, possibly controlled >>>> with a timer etc. so it work on multiple platforms without you needing >>>> to know much about the underlaying HW >>>> >>>> you can write directly to PORTD on the AVR if you like >>> >>> Yes, understood. But isn't that always the problem? The compiler's >>> always generating for some general case, which the assembly programmer >>> need not do. >> >> No, that's not the problem. The problem is that digitalWrite takes >> a *logical* pin number, which is meant to map to the Arduino footprint >> for a range of different Arduino types, even though those bring a >> different port pin to that logical pin. >> >> If you had written (not checked, but like): >> >> *((uint8_t*)PORTD) = 0; >> or >> *((uint8_t*)PORTD) |= 0x1; >> >> Then you would get the appropriate minimal I/O instructions from >> any recent Arduino gcc compiler. > > You're not understanding--I'm fully aware that I can go so far as to embed > assembly if I choose. No assembly is needed - the compiler can generate optimal code from that source. > > The fact that the compiler is jumping though hoops to map virtual pin numbers > to physical ports and pins is exactly my point: it's solving problems that > a human programmer wouldn't have to. I'd just read-modify-write the port > with the appropriate mask. You are blaming the wrong thing - and therefore will not make progress. It is /not/ the compiler that is doing this mapping - it is the Arduino API. This is designed to be simple for hobby users trying to make an LED turn on and off when you press a switch - efficiency is almost irrelevant to the Arduino tool designers. If you are looking for efficient code, don't use Arduino. > > BUT, what the naive users have and use, is layers and layers abstracted from > the hardware doing the actual work. That is what /Arduino/ users get. If you want efficient code, just use "normal" AVR development tools. The easiest is to get the AVR Studio package from Atmel, which includes an IDE, debugger, and an installation of avr-gcc (the same compiler as used with Arduino, but without the Arduino layers). For Linux, you can get a package of avr-gcc from Atmel (including libraries, headers, etc.) and use Eclipse and Linux-based avr debugger tools. > >>> It wasn't just the digitalWrite() -- lots of pushes and pops, subroutine >>> calls to subroutine calls, etc. for my regular code. >> >> Use of subroutine calls is your prerogative, neither gcc nor asm can >> really circumvent those decisions... however... > > Not so--it's using all sorts of calls to functions within functions as > part of its standard environment. Thank heaven I'm not short on stack > space! On the AVR, you'll find a certain amount of function calls to support language features that the hardware cannot do directly. Depending on the AVR core, you might have a function call for a simple multiply - you certainly will for division, for floating point, and many other things. But most of what you see here is the Arduino layers of functions and abstractions. These are not written very efficiently - indeed, there are lot of extra nested function calls that could be avoided by a simple template library. > >> Did you use a high optimisation level? gcc is pretty good at inlining >> code if and when it can see that's possible. > > I can't control it. The IDE controls the build process from start to > finish. If you want control, drop Arduino and use the AVR and avr-gcc directly. > > It might've been easier for me to skip the Arduino IDE and write straight > gcc, or even bare assembly, but the Arduino environment is a lot less > intimidating for the customer. The Arduino IDE is designed to be easy to use and friendly, not efficient or flexible. I am not convinced by it - I think it hides and restricts too much. But that's the way it is - you choose to use it or not. (I used to write assembly for the AVRs, but it is a long time since I've done so - the compiler is excellent, and it is far more efficient to write good C or C++ code than assembly.) > >>> The CPU's plenty fast enough and there are heaps of memory, so in practice >>> it won't generally matter. >>> >>> It's just a little distressing to see folks piling abstraction on >>> abstraction on abstraction, with documentation that doesn't give >>> parameter and return value types, 27^3 kinds of 'portable' integers, >>> ready to all fall down. >> >> The Arduino APIs are far from well-designed, for the most part. > > It's cute, and has gotten a lot of hobbyists started. Lots of enthusiasm. > It's the 'encouraging hacking' aspect--poking, prodding, and fiddling > instead of planning--that's unfortunate. It teaches the next generation > of programmers to be sloppy. It's great for hobby use - it is useless for serious work. But it is fine for programmers to start off sloppy, and then learn to write code properly later. My generation learned to program as kids in Basic with gotos, but that didn't hinder us from learning about structured programming later. > >> But thats not the fault of gcc nor of compiles in general. > > Of course not. > >> Clifford Heath. > > Cheers, > James Arthur >
[toc] | [prev] | [next] | [standalone]
| From | dagmargoodboat@yahoo.com |
|---|---|
| Date | 2017-02-09 06:57 -0800 |
| Message-ID | <875378e0-4959-44c6-b761-1b48e5523b81@googlegroups.com> |
| In reply to | #446626 |
On Tuesday, February 7, 2017 at 4:43:00 AM UTC-5, David Brown wrote: > On 07/02/17 05:14, dagmargoodboat@yahoo.com wrote: > > The fact that the compiler is jumping though hoops to map virtual pin numbers > > to physical ports and pins is exactly my point: it's solving problems that > > a human programmer wouldn't have to. I'd just read-modify-write the port > > with the appropriate mask. > > You are blaming the wrong thing - and therefore will not make progress. > > It is /not/ the compiler that is doing this mapping - it is the Arduino > API. This is designed to be simple for hobby users trying to make an > LED turn on and off when you press a switch - efficiency is almost > irrelevant to the Arduino tool designers. I know all that. I meant to illustrate and quantify by example how all these ingenious attempts to coddle and insulate users actually get in the way. I wasn't asking "How can I make efficient code on an Arduino?," but drawing attention to the fact that neophytes using the stock tools are, naively, working through layers of abstraction, and do *not* get efficient code. No slight to gcc intended. Cheers, James Arthur
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-09 16:12 +0100 |
| Message-ID | <o7i0qg$j63$1@dont-email.me> |
| In reply to | #447013 |
On 09/02/17 15:57, dagmargoodboat@yahoo.com wrote: > On Tuesday, February 7, 2017 at 4:43:00 AM UTC-5, David Brown wrote: >> On 07/02/17 05:14, dagmargoodboat@yahoo.com wrote: > >>> The fact that the compiler is jumping though hoops to map virtual pin numbers >>> to physical ports and pins is exactly my point: it's solving problems that >>> a human programmer wouldn't have to. I'd just read-modify-write the port >>> with the appropriate mask. >> >> You are blaming the wrong thing - and therefore will not make progress. >> >> It is /not/ the compiler that is doing this mapping - it is the Arduino >> API. This is designed to be simple for hobby users trying to make an >> LED turn on and off when you press a switch - efficiency is almost >> irrelevant to the Arduino tool designers. > > I know all that. I meant to illustrate and quantify by example how all > these ingenious attempts to coddle and insulate users actually get in > the way. > > I wasn't asking "How can I make efficient code on an Arduino?," but > drawing attention to the fact that neophytes using the stock tools > are, naively, working through layers of abstraction, and do *not* get > efficient code. > > No slight to gcc intended. > OK. Your original post read as quite clearly blaming the compiler (and indeed, railing against all compilers), but maybe it didn't come across as you intended. And I agree that the Arduino does not do an ideal job in making microcontroller programming easy for newbies. It makes some easy tasks easier, but by hiding details of the language while still relying on them, it makes fault-finding or medium-level tasks harder, and advanced tasks almost impossible.
[toc] | [prev] | [next] | [standalone]
| From | Clifford Heath <no.spam@please.net> |
|---|---|
| Date | 2017-02-10 08:24 +1100 |
| Message-ID | <589cde00$0$10580$c3e8da3$5d8fb80f@news.astraweb.com> |
| In reply to | #447013 |
On 10/02/17 01:57, dagmargoodboat@yahoo.com wrote: > ingenious attempts to coddle and insulate users actually get in the way. YES. So much this. The right way to build capability is help the user to take small steps on solid ground, not to give them jet powered boots to leap between mountain tops.
[toc] | [prev] | [next] | [standalone]
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
Back to top | Article view | sci.electronics.design
csiph-web