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 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-08 17:25 +0100 |
| Message-ID | <o7fgmo$e0m$3@dont-email.me> |
| In reply to | #446776 |
On 08/02/17 16:01, pcdhobbs@gmail.com wrote:
>> That is a completely different matter. A conditional statement
>> ("if", "while", etc.) compares its argument to 0 (in C) or
>> "contextually converts to bool" (in C++) - thus any non-false value
>> is considered "true".
>
> Back in the late '70s (iirc) the Forth standard changed to make TRUE
> = -1 instead of 1, causing massive breakage. The rationale was that
> on a twos-complement machine that made every bit of the word 1, so
> you could use TRUE and FALSE in bitwise operations too.
>
> Nice idea, if they'd thought of it the first time round. :(
>
It is not entirely unreasonable to standardise on -1 for "true". But C
(and C++) standardised on 1, and that's the way it is. (It's a better
choice anyway - it has the same representation in all integer types, no
matter what size or signedness.)
[toc] | [prev] | [next] | [standalone]
| From | jack4747@gmail.com |
|---|---|
| Date | 2017-02-09 06:51 -0800 |
| Message-ID | <bf33f3d7-1702-4d37-a030-7d22ae46d7ba@googlegroups.com> |
| In reply to | #446785 |
Il giorno mercoledì 8 febbraio 2017 17:25:43 UTC+1, David Brown ha scritto:
> On 08/02/17 16:01, pcdhobbs@gmail.com wrote:
> >> That is a completely different matter. A conditional statement
> >> ("if", "while", etc.) compares its argument to 0 (in C) or
> >> "contextually converts to bool" (in C++) - thus any non-false value
> >> is considered "true".
> >
> > Back in the late '70s (iirc) the Forth standard changed to make TRUE
> > = -1 instead of 1, causing massive breakage. The rationale was that
> > on a twos-complement machine that made every bit of the word 1, so
> > you could use TRUE and FALSE in bitwise operations too.
> >
> > Nice idea, if they'd thought of it the first time round. :(
> >
>
> It is not entirely unreasonable to standardise on -1 for "true". But C
> (and C++) standardised on 1, and that's the way it is. (It's a better
> choice anyway - it has the same representation in all integer types, no
> matter what size or signedness.)
nope.
C per definition has 0 == FALSE, and TRUE is anything different from FALSE.
Bye Jack
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-09 16:41 +0100 |
| Message-ID | <o7i2fv$ptm$1@dont-email.me> |
| In reply to | #447011 |
On 09/02/17 15:51, jack4747@gmail.com wrote:
> Il giorno mercoledì 8 febbraio 2017 17:25:43 UTC+1, David Brown ha scritto:
>> On 08/02/17 16:01, pcdhobbs@gmail.com wrote:
>>>> That is a completely different matter. A conditional statement
>>>> ("if", "while", etc.) compares its argument to 0 (in C) or
>>>> "contextually converts to bool" (in C++) - thus any non-false value
>>>> is considered "true".
>>>
>>> Back in the late '70s (iirc) the Forth standard changed to make TRUE
>>> = -1 instead of 1, causing massive breakage. The rationale was that
>>> on a twos-complement machine that made every bit of the word 1, so
>>> you could use TRUE and FALSE in bitwise operations too.
>>>
>>> Nice idea, if they'd thought of it the first time round. :(
>>>
>>
>> It is not entirely unreasonable to standardise on -1 for "true". But C
>> (and C++) standardised on 1, and that's the way it is. (It's a better
>> choice anyway - it has the same representation in all integer types, no
>> matter what size or signedness.)
>
> nope.
You are wrong - and if you don't believe me, look it up in the C standards.
> C per definition has 0 == FALSE, and TRUE is anything different from FALSE.
>
C has no identifier "FALSE", nor an identifier "TRUE" - and if it did,
the "TRUE" would have to be defined to a particular fixed value.
There are three contexts in which C (and C++, which is the language in
question) have a concept of "true" or "false".
1. The boolean types. In C++, this is "bool" - in C from C99 onwards,
it is "_Bool". In C++, "bool" is the type and "true" and "false" are
keywords. In C, "_Bool" is the type and "true" and "false" are macros
defined to 1 and 0 respectively, with "bool" being a macro defined to
"_Bool" (all this is in <stdbool.h>). Prior to C99, C has no boolean
type and no true or false identifiers.
The type _Bool (or bool) may only store 0 or 1. If you convert from
another type to "bool", then any value that does not compare equal to 0
is converted to 1.
2. The relational operators (==, !=, <, >, <=, >=). These evaluate to 0
for false, 1 for true.
3. Conditional statements and expressions ("if", "while", and the
control clause of "for", as well as the conditional operator and the
logical "not", "and" and "or" operators). In C, given "if (x)" then the
condition is considered "true" if x does not compare equal to 0. In
C++, x is "contextually converted to bool". Unless you are doing
something weird with conversion operators, this usually means much the
same thing.
So in C, false is 0, true is 1. Boolean types cannot legally hold any
other value. Any time the compiler is asked to consider a non-boolean
expression in a boolean context, then an expression that does not
compare equal to 0 is converted to 1.
In pre-C99 C code, there is no "_Bool" type standardised (though
implementations may have one as an extension). It was common to use
either an "int" or an "unsigned char" for holding boolean flags, and to
define "true" and "false" as macros meaning 1 and 0. Occasionally
people used an enumerated type with the same effect. Then there were no
guarantees about these variables being restricted to 0 and 1. And some
people would define their "true" (or "TRUE") macro to be -1 instead of 1
- but that was their personal C code - it has never been part of the C
language.
[toc] | [prev] | [next] | [standalone]
| From | M Philbrook <jamie_ka1lpa@charter.net> |
|---|---|
| Date | 2017-02-09 19:44 -0500 |
| Message-ID | <MPG.3306d70f8e22567698a009@news.eternal-september.org> |
| In reply to | #447019 |
In article <o7i2fv$ptm$1@dont-email.me>, david.brown@hesbynett.no
says...
>
> You are wrong - and if you don't believe me, look it up in the C standards.
>
> > C per definition has 0 == FALSE, and TRUE is anything different from FALSE.
> >
>
> C has no identifier "FALSE", nor an identifier "TRUE" - and if it did,
> the "TRUE" would have to be defined to a particular fixed value.
>
> There are three contexts in which C (and C++, which is the language in
> question) have a concept of "true" or "false".
>
> 1. The boolean types. In C++, this is "bool" - in C from C99 onwards,
> it is "_Bool". In C++, "bool" is the type and "true" and "false" are
> keywords. In C, "_Bool" is the type and "true" and "false" are macros
> defined to 1 and 0 respectively, with "bool" being a macro defined to
> "_Bool" (all this is in <stdbool.h>). Prior to C99, C has no boolean
> type and no true or false identifiers.
>
> The type _Bool (or bool) may only store 0 or 1. If you convert from
> another type to "bool", then any value that does not compare equal to 0
> is converted to 1.
>
> 2. The relational operators (==, !=, <, >, <=, >=). These evaluate to 0
> for false, 1 for true.
>
> 3. Conditional statements and expressions ("if", "while", and the
> control clause of "for", as well as the conditional operator and the
> logical "not", "and" and "or" operators). In C, given "if (x)" then the
> condition is considered "true" if x does not compare equal to 0. In
> C++, x is "contextually converted to bool". Unless you are doing
> something weird with conversion operators, this usually means much the
> same thing.
>
>
> So in C, false is 0, true is 1. Boolean types cannot legally hold any
> other value. Any time the compiler is asked to consider a non-boolean
> expression in a boolean context, then an expression that does not
> compare equal to 0 is converted to 1.
>
>
> In pre-C99 C code, there is no "_Bool" type standardised (though
> implementations may have one as an extension). It was common to use
> either an "int" or an "unsigned char" for holding boolean flags, and to
> define "true" and "false" as macros meaning 1 and 0. Occasionally
> people used an enumerated type with the same effect. Then there were no
> guarantees about these variables being restricted to 0 and 1. And some
> people would define their "true" (or "TRUE") macro to be -1 instead of 1
> - but that was their personal C code - it has never been part of the C
> language.
I am glad you dont do any coding work for me or anyone I deal with..
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-13 16:14 +0100 |
| Message-ID | <o7sidg$291$1@dont-email.me> |
| In reply to | #447115 |
On 10/02/17 01:44, M Philbrook wrote:
> In article <o7i2fv$ptm$1@dont-email.me>, david.brown@hesbynett.no
> says...
>>
>> You are wrong - and if you don't believe me, look it up in the C standards.
>>
>>> C per definition has 0 == FALSE, and TRUE is anything different from FALSE.
>>>
>>
>> C has no identifier "FALSE", nor an identifier "TRUE" - and if it did,
>> the "TRUE" would have to be defined to a particular fixed value.
>>
>> There are three contexts in which C (and C++, which is the language in
>> question) have a concept of "true" or "false".
>>
>> 1. The boolean types. In C++, this is "bool" - in C from C99 onwards,
>> it is "_Bool". In C++, "bool" is the type and "true" and "false" are
>> keywords. In C, "_Bool" is the type and "true" and "false" are macros
>> defined to 1 and 0 respectively, with "bool" being a macro defined to
>> "_Bool" (all this is in <stdbool.h>). Prior to C99, C has no boolean
>> type and no true or false identifiers.
>>
>> The type _Bool (or bool) may only store 0 or 1. If you convert from
>> another type to "bool", then any value that does not compare equal to 0
>> is converted to 1.
>>
>> 2. The relational operators (==, !=, <, >, <=, >=). These evaluate to 0
>> for false, 1 for true.
>>
>> 3. Conditional statements and expressions ("if", "while", and the
>> control clause of "for", as well as the conditional operator and the
>> logical "not", "and" and "or" operators). In C, given "if (x)" then the
>> condition is considered "true" if x does not compare equal to 0. In
>> C++, x is "contextually converted to bool". Unless you are doing
>> something weird with conversion operators, this usually means much the
>> same thing.
>>
>>
>> So in C, false is 0, true is 1. Boolean types cannot legally hold any
>> other value. Any time the compiler is asked to consider a non-boolean
>> expression in a boolean context, then an expression that does not
>> compare equal to 0 is converted to 1.
>>
>>
>> In pre-C99 C code, there is no "_Bool" type standardised (though
>> implementations may have one as an extension). It was common to use
>> either an "int" or an "unsigned char" for holding boolean flags, and to
>> define "true" and "false" as macros meaning 1 and 0. Occasionally
>> people used an enumerated type with the same effect. Then there were no
>> guarantees about these variables being restricted to 0 and 1. And some
>> people would define their "true" (or "TRUE") macro to be -1 instead of 1
>> - but that was their personal C code - it has never been part of the C
>> language.
>
> I am glad you dont do any coding work for me or anyone I deal with..
>
Why? Is it just because I explained things in a lot of detail, or do
you think any of what I wrote is incorrect? If so, give me the details
and references to the section numbers in a C standard (the N1570 draft
of C11 is the modern one) and I will see if we can sort out the
differences in understandings.
[toc] | [prev] | [next] | [standalone]
| From | John Devereux <john@devereux.me.uk> |
|---|---|
| Date | 2017-02-16 12:57 +0000 |
| Message-ID | <8760kae1j8.fsf@devereux.me.uk> |
| In reply to | #447549 |
David Brown <david.brown@hesbynett.no> writes:
> On 10/02/17 01:44, M Philbrook wrote:
>> In article <o7i2fv$ptm$1@dont-email.me>, david.brown@hesbynett.no
>> says...
>>>
>>> You are wrong - and if you don't believe me, look it up in the C standards.
>>>
>>>> C per definition has 0 == FALSE, and TRUE is anything different from FALSE.
>>>>
>>>
>>> C has no identifier "FALSE", nor an identifier "TRUE" - and if it did,
>>> the "TRUE" would have to be defined to a particular fixed value.
>>>
>>> There are three contexts in which C (and C++, which is the language in
>>> question) have a concept of "true" or "false".
>>>
>>> 1. The boolean types. In C++, this is "bool" - in C from C99 onwards,
>>> it is "_Bool". In C++, "bool" is the type and "true" and "false" are
>>> keywords. In C, "_Bool" is the type and "true" and "false" are macros
>>> defined to 1 and 0 respectively, with "bool" being a macro defined to
>>> "_Bool" (all this is in <stdbool.h>). Prior to C99, C has no boolean
>>> type and no true or false identifiers.
>>>
>>> The type _Bool (or bool) may only store 0 or 1. If you convert from
>>> another type to "bool", then any value that does not compare equal to 0
>>> is converted to 1.
>>>
>>> 2. The relational operators (==, !=, <, >, <=, >=). These evaluate to 0
>>> for false, 1 for true.
>>>
>>> 3. Conditional statements and expressions ("if", "while", and the
>>> control clause of "for", as well as the conditional operator and the
>>> logical "not", "and" and "or" operators). In C, given "if (x)" then the
>>> condition is considered "true" if x does not compare equal to 0. In
>>> C++, x is "contextually converted to bool". Unless you are doing
>>> something weird with conversion operators, this usually means much the
>>> same thing.
>>>
>>>
>>> So in C, false is 0, true is 1. Boolean types cannot legally hold any
>>> other value. Any time the compiler is asked to consider a non-boolean
>>> expression in a boolean context, then an expression that does not
>>> compare equal to 0 is converted to 1.
>>>
>>>
>>> In pre-C99 C code, there is no "_Bool" type standardised (though
>>> implementations may have one as an extension). It was common to use
>>> either an "int" or an "unsigned char" for holding boolean flags, and to
>>> define "true" and "false" as macros meaning 1 and 0. Occasionally
>>> people used an enumerated type with the same effect. Then there were no
>>> guarantees about these variables being restricted to 0 and 1. And some
>>> people would define their "true" (or "TRUE") macro to be -1 instead of 1
>>> - but that was their personal C code - it has never been part of the C
>>> language.
>>
>> I am glad you dont do any coding work for me or anyone I deal with..
>>
>
> Why? Is it just because I explained things in a lot of detail, or do
> you think any of what I wrote is incorrect? If so, give me the details
> and references to the section numbers in a C standard (the N1570 draft
> of C11 is the modern one) and I will see if we can sort out the
> differences in understandings.
David, you are an expert.
We've had enough of experts....
--
John Devereux
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-02-16 14:11 +0000 |
| Message-ID | <_pipA.466518$sc6.88819@fx25.am4> |
| In reply to | #447850 |
On 16/02/17 12:57, John Devereux wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 10/02/17 01:44, M Philbrook wrote: >>> >>> I am glad you dont do any coding work for me or anyone I deal with.. >>> >> >> Why? Is it just because I explained things in a lot of detail, or do >> you think any of what I wrote is incorrect? If so, give me the details >> and references to the section numbers in a C standard (the N1570 draft >> of C11 is the modern one) and I will see if we can sort out the >> differences in understandings. > > David, you are an expert. > > We've had enough of experts.... There are two possible translations of that 1) we don't like people that use facts to point out where our gut feelings are wrong 2) we shouldn't need experts (of this kind) to implement systems. The former is disreputable and the realm of snake-oil salesman. The latter is either wishful thinking, or a statement that this toolset and associated /necessary/ "language lawyer" mentality is unacceptable. I tend to the latter. It will be interesting to see if C/C++ survives[1] any move towards legal regulation of software (cf civil engineering). One perspective: https://www.schneier.com/essays/archives/2017/01/click_here_to_kill_e.html it will be interesting to see if it gains traction. [1] short term of course it will survive. But long term is less clear, particularly as better tool arrive.
[toc] | [prev] | [next] | [standalone]
| From | John Devereux <john@devereux.me.uk> |
|---|---|
| Date | 2017-02-16 14:40 +0000 |
| Message-ID | <871suydwrp.fsf@devereux.me.uk> |
| In reply to | #447857 |
Tom Gardner <spamjunk@blueyonder.co.uk> writes: > On 16/02/17 12:57, John Devereux wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> On 10/02/17 01:44, M Philbrook wrote: >>>> >>>> I am glad you dont do any coding work for me or anyone I deal with.. >>>> >>> >>> Why? Is it just because I explained things in a lot of detail, or do >>> you think any of what I wrote is incorrect? If so, give me the details >>> and references to the section numbers in a C standard (the N1570 draft >>> of C11 is the modern one) and I will see if we can sort out the >>> differences in understandings. >> >> David, you are an expert. >> >> We've had enough of experts.... > > There are two possible translations of that > 1) we don't like people that use facts to point > out where our gut feelings are wrong That is the one I was going for. Along the lines of, we have our own alternative facts. It was of course an excellent post, informative as always from David! > 2) we shouldn't need experts (of this kind) to > implement systems. > The former is disreputable and the realm of > snake-oil salesman. > > The latter is either wishful thinking, or a > statement that this toolset and associated > /necessary/ "language lawyer" mentality is > unacceptable. I tend to the latter. I have been programming in C for a long time in embedded systems, but it is only a small part of my job. I don't consider myself an "expert" and certainly not a language lawyer. I find that sticking to a few conventions and idioms is enough to avoid issues like the OP had with bool and so forth. In this case, as David says, don't lie to the compiler. Be hyper-vigilent when writing a cast, it is very likely the wrong way to do things and usually dangerous and not necessary. I find C to be fairly pleasant and surprise-free in use. > It will be interesting to see if C/C++ > survives[1] any move towards legal regulation of > software (cf civil engineering). > One perspective: > https://www.schneier.com/essays/archives/2017/01/click_here_to_kill_e.html > it will be interesting to see if it gains > traction. > > [1] short term of course it will survive. > But long term is less clear, particularly > as better tool arrive. -- John Devereux
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-16 15:58 +0100 |
| Message-ID | <o84eit$nqp$1@dont-email.me> |
| In reply to | #447859 |
On 16/02/17 15:40, John Devereux wrote: > Tom Gardner <spamjunk@blueyonder.co.uk> writes: > >> On 16/02/17 12:57, John Devereux wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>> >>>> On 10/02/17 01:44, M Philbrook wrote: >>>>> >>>>> I am glad you dont do any coding work for me or anyone I deal with.. >>>>> >>>> >>>> Why? Is it just because I explained things in a lot of detail, or do >>>> you think any of what I wrote is incorrect? If so, give me the details >>>> and references to the section numbers in a C standard (the N1570 draft >>>> of C11 is the modern one) and I will see if we can sort out the >>>> differences in understandings. >>> >>> David, you are an expert. >>> >>> We've had enough of experts.... >> >> There are two possible translations of that >> 1) we don't like people that use facts to point >> out where our gut feelings are wrong > > That is the one I was going for. Along the lines of, we have our own > alternative facts. That is a strong tradition in s.e.d. :-) > > It was of course an excellent post, informative as always from David! Thank you - it was intended to be helpful. Of course, "expert" is a relative term. I know more of the details of C standards, compilers, and "legalese" than most C programmers, and most people in this group - but over in comp.lang.c I am much lower in the rankings. (And my "expertise" is by no means infallible - the C11 draft standard N1570 is freely available online.) > >> 2) we shouldn't need experts (of this kind) to >> implement systems. > > >> The former is disreputable and the realm of >> snake-oil salesman. >> >> The latter is either wishful thinking, or a >> statement that this toolset and associated >> /necessary/ "language lawyer" mentality is >> unacceptable. I tend to the latter. > > I have been programming in C for a long time in embedded systems, but it > is only a small part of my job. I don't consider myself an "expert" and > certainly not a language lawyer. > > I find that sticking to a few conventions and idioms is enough to avoid > issues like the OP had with bool and so forth. I do the same - I just like to know why the idioms work. > In this case, as David > says, don't lie to the compiler. Yes - it's a good rule. > Be hyper-vigilent when writing a cast, > it is very likely the wrong way to do things and usually dangerous and > not necessary. True, in general. However, the cast was not the problem here - it was not even necessary. There is no difference between "word w; w = (word) b;" and "word w; w = b;" or simply "word w = b;". There are only two reasons for using a cast here - either the programmer doesn't really understand casts and conversions in C, or the programmer wants to make the conversion abundantly clear to the reader by adding it explicitly as a sort of documentation. > > I find C to be fairly pleasant and surprise-free in use. It usually is, unless you try to push it and break the rules, or unless you think the compiler is supposed to translate your source line-by-line into assembly. > >> It will be interesting to see if C/C++ >> survives[1] any move towards legal regulation of >> software (cf civil engineering). > >> One perspective: >> https://www.schneier.com/essays/archives/2017/01/click_here_to_kill_e.html >> it will be interesting to see if it gains >> traction. >> >> [1] short term of course it will survive. >> But long term is less clear, particularly >> as better tool arrive. > >
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-02-16 15:56 +0000 |
| Message-ID | <zYjpA.47205$Zt.31090@fx43.am4> |
| In reply to | #447859 |
On 16/02/17 14:40, John Devereux wrote: > Tom Gardner <spamjunk@blueyonder.co.uk> writes: > >> On 16/02/17 12:57, John Devereux wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>> >>>> On 10/02/17 01:44, M Philbrook wrote: >>>>> >>>>> I am glad you dont do any coding work for me or anyone I deal with.. >>>>> >>>> >>>> Why? Is it just because I explained things in a lot of detail, or do >>>> you think any of what I wrote is incorrect? If so, give me the details >>>> and references to the section numbers in a C standard (the N1570 draft >>>> of C11 is the modern one) and I will see if we can sort out the >>>> differences in understandings. >>> >>> David, you are an expert. >>> >>> We've had enough of experts.... >> >> There are two possible translations of that >> 1) we don't like people that use facts to point >> out where our gut feelings are wrong > > That is the one I was going for. Along the lines of, we have our own > alternative facts. > > It was of course an excellent post, informative as always from David! > >> 2) we shouldn't need experts (of this kind) to >> implement systems. > > >> The former is disreputable and the realm of >> snake-oil salesman. >> >> The latter is either wishful thinking, or a >> statement that this toolset and associated >> /necessary/ "language lawyer" mentality is >> unacceptable. I tend to the latter. > > I have been programming in C for a long time in embedded systems, but it > is only a small part of my job. I don't consider myself an "expert" and > certainly not a language lawyer. My career trajectory meant I was a heavy user of C in the early-late 80s, but in the 90s I moved onto software for which C was a less good fit. In the noughties I saw some truly horrific commercial code in C/C++, much of it written by youngsters that hadn't grown up with it - and who had little conception of what was happening "under the hood". Even FSMs and caches were things they were only vaguely aware of :( In such cases, a more modern higher level language tended to enable systems with fewer /undiagnosed/ surprises lurking in the undergrowth. Such surprises, if not dealt with by they programmer, were at least visible in the source code. > I find that sticking to a few conventions and idioms is enough to avoid > issues like the OP had with bool and so forth. In this case, as David > says, don't lie to the compiler. Be hyper-vigilent when writing a cast, > it is very likely the wrong way to do things and usually dangerous and > not necessary. Agreed; that's my experience when writing small applications in C. But when I can't write all the code myself I have to rely on the competence of unknown other programmers. And that's a real problem given my observations above! I don't have experience of MISRA-based systems, and I don't know how many of the fun and games outlined in the FQA are trapped out. > I find C to be fairly pleasant and surprise-free in use. It gets /much/ nastier on machines with multiple levels of memory hierarchy, including caches, local memory and remote memory - and, of course, multiprocessors. When considering those factors, the compiler writers and compiler users have difficulty agreeing what is "meant" by the source code. Doubly so when different (generations of) compiler are used. >> It will be interesting to see if C/C++ >> survives[1] any move towards legal regulation of >> software (cf civil engineering). > >> One perspective: >> https://www.schneier.com/essays/archives/2017/01/click_here_to_kill_e.html >> it will be interesting to see if it gains >> traction. >> >> [1] short term of course it will survive. >> But long term is less clear, particularly >> as better tool arrive.
[toc] | [prev] | [next] | [standalone]
| From | John Devereux <john@devereux.me.uk> |
|---|---|
| Date | 2017-02-16 16:45 +0000 |
| Message-ID | <87wpcqcceg.fsf@devereux.me.uk> |
| In reply to | #447864 |
Tom Gardner <spamjunk@blueyonder.co.uk> writes: > On 16/02/17 14:40, John Devereux wrote: >> Tom Gardner <spamjunk@blueyonder.co.uk> writes: >> >>> On 16/02/17 12:57, John Devereux wrote: >>>> David Brown <david.brown@hesbynett.no> writes: >>>> >>>>> On 10/02/17 01:44, M Philbrook wrote: >>>>>> >>>>>> I am glad you dont do any coding work for me or anyone I deal with.. >>>>>> >>>>> >>>>> Why? Is it just because I explained things in a lot of detail, or do >>>>> you think any of what I wrote is incorrect? If so, give me the details >>>>> and references to the section numbers in a C standard (the N1570 draft >>>>> of C11 is the modern one) and I will see if we can sort out the >>>>> differences in understandings. >>>> >>>> David, you are an expert. >>>> >>>> We've had enough of experts.... >>> >>> There are two possible translations of that >>> 1) we don't like people that use facts to point >>> out where our gut feelings are wrong >> >> That is the one I was going for. Along the lines of, we have our own >> alternative facts. >> >> It was of course an excellent post, informative as always from David! >> >>> 2) we shouldn't need experts (of this kind) to >>> implement systems. >> >> >>> The former is disreputable and the realm of >>> snake-oil salesman. >>> >>> The latter is either wishful thinking, or a >>> statement that this toolset and associated >>> /necessary/ "language lawyer" mentality is >>> unacceptable. I tend to the latter. >> >> I have been programming in C for a long time in embedded systems, but it >> is only a small part of my job. I don't consider myself an "expert" and >> certainly not a language lawyer. > > My career trajectory meant I was a heavy user of C > in the early-late 80s, That is when I learned all the bad habits I later had to unlearn - using C on crappy 8 bit processors with only a few registers and not much help with optimisation from the inefficient buggy compilers. So the shortage of RAM and index registers meant my code had lots of global 8bit variables for "efficiency", since the CPUs could not do indexed or stack based addressing at all well. So code was faster and shorter with variables in fixed absolute addresses. Stack was limited so one tended towards long functions instead of breaking things up into shorter ones. Etc. The I used the AVR of the thread. This was slightly more modern but still not perfectly suited for C. For example its 8-bit registers are a poor match for C's general arithmetic types and the different types of memory area require some nasty kludges IIRC. I think the current day cortex M CPUs are probably more like the minicomputers C was designed for (but much faster). C and c++ are a perfect match here, with gcc an excellent and free compiler. >but in the 90s I moved onto > software for which C was a less good fit. > > In the noughties I saw some truly horrific commercial > code in C/C++, much of it written by youngsters that > hadn't grown up with it - and who had little conception > of what was happening "under the hood". Even FSMs and > caches were things they were only vaguely aware of :( > > In such cases, a more modern higher level language > tended to enable systems with fewer /undiagnosed/ > surprises lurking in the undergrowth. Such surprises, > if not dealt with by they programmer, were at least > visible in the source code. > > >> I find that sticking to a few conventions and idioms is enough to avoid >> issues like the OP had with bool and so forth. In this case, as David >> says, don't lie to the compiler. Be hyper-vigilent when writing a cast, >> it is very likely the wrong way to do things and usually dangerous and >> not necessary. > > Agreed; that's my experience when writing small > applications in C. But when I can't write all the > code myself I have to rely on the competence of > unknown other programmers. And that's a real > problem given my observations above! > > I don't have experience of MISRA-based systems, > and I don't know how many of the fun and games > outlined in the FQA are trapped out. > > >> I find C to be fairly pleasant and surprise-free in use. > > It gets /much/ nastier on machines with multiple levels > of memory hierarchy, including caches, local memory > and remote memory - and, of course, multiprocessors. I tend to use C on devices using up to ~256k code, so far. > When considering those factors, the compiler writers > and compiler users have difficulty agreeing what is > "meant" by the source code. Doubly so when different > (generations of) compiler are used. -- John Devereux
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-02-16 17:18 +0000 |
| Message-ID | <c9lpA.806957$A_3.553540@fx37.am4> |
| In reply to | #447872 |
On 16/02/17 16:45, John Devereux wrote: > Tom Gardner <spamjunk@blueyonder.co.uk> writes: > >> On 16/02/17 14:40, John Devereux wrote: >>> Tom Gardner <spamjunk@blueyonder.co.uk> writes: >>> >>>> On 16/02/17 12:57, John Devereux wrote: >>>>> David Brown <david.brown@hesbynett.no> writes: >>>>> >>>>>> On 10/02/17 01:44, M Philbrook wrote: >>>>>>> >>>>>>> I am glad you dont do any coding work for me or anyone I deal with.. >>>>>>> >>>>>> >>>>>> Why? Is it just because I explained things in a lot of detail, or do >>>>>> you think any of what I wrote is incorrect? If so, give me the details >>>>>> and references to the section numbers in a C standard (the N1570 draft >>>>>> of C11 is the modern one) and I will see if we can sort out the >>>>>> differences in understandings. >>>>> >>>>> David, you are an expert. >>>>> >>>>> We've had enough of experts.... >>>> >>>> There are two possible translations of that >>>> 1) we don't like people that use facts to point >>>> out where our gut feelings are wrong >>> >>> That is the one I was going for. Along the lines of, we have our own >>> alternative facts. >>> >>> It was of course an excellent post, informative as always from David! >>> >>>> 2) we shouldn't need experts (of this kind) to >>>> implement systems. >>> >>> >>>> The former is disreputable and the realm of >>>> snake-oil salesman. >>>> >>>> The latter is either wishful thinking, or a >>>> statement that this toolset and associated >>>> /necessary/ "language lawyer" mentality is >>>> unacceptable. I tend to the latter. >>> >>> I have been programming in C for a long time in embedded systems, but it >>> is only a small part of my job. I don't consider myself an "expert" and >>> certainly not a language lawyer. >> >> My career trajectory meant I was a heavy user of C >> in the early-late 80s, > > That is when I learned all the bad habits I later had to unlearn - using > C on crappy 8 bit processors with only a few registers and not much help > with optimisation from the inefficient buggy compilers. > > So the shortage of RAM and index registers meant my code had lots of > global 8bit variables for "efficiency", since the CPUs could not do > indexed or stack based addressing at all well. So code was faster and > shorter with variables in fixed absolute addresses. Stack was limited so > one tended towards long functions instead of breaking things up into > shorter ones. Etc. > > The I used the AVR of the thread. This was slightly more modern but > still not perfectly suited for C. For example its 8-bit registers are a > poor match for C's general arithmetic types and the different types of > memory area require some nasty kludges IIRC. > > I think the current day cortex M CPUs are probably more like the > minicomputers C was designed for (but much faster). C and c++ are a > perfect match here, with gcc an excellent and free compiler. I don't have many quibbles with that, but problems begin to creep in when A9 (etc) come into the equation. Even mid-range FPGAs have dual-core A class processor in them nowadays. However, I've just deleted an email titled "Preconfigured Cloud Solutions Get Your IoT Project to Market Easier" That is an indication that the imperative is towards use-and-forget-without-understanding where subtle bugs will lie for youngsters without the time/inclination to learn when PHBs are breathing down their neck. No, I don't like that either. >> but in the 90s I moved onto >> software for which C was a less good fit. >> >> In the noughties I saw some truly horrific commercial >> code in C/C++, much of it written by youngsters that >> hadn't grown up with it - and who had little conception >> of what was happening "under the hood". Even FSMs and >> caches were things they were only vaguely aware of :( >> >> In such cases, a more modern higher level language >> tended to enable systems with fewer /undiagnosed/ >> surprises lurking in the undergrowth. Such surprises, >> if not dealt with by they programmer, were at least >> visible in the source code. >> >> >>> I find that sticking to a few conventions and idioms is enough to avoid >>> issues like the OP had with bool and so forth. In this case, as David >>> says, don't lie to the compiler. Be hyper-vigilent when writing a cast, >>> it is very likely the wrong way to do things and usually dangerous and >>> not necessary. >> >> Agreed; that's my experience when writing small >> applications in C. But when I can't write all the >> code myself I have to rely on the competence of >> unknown other programmers. And that's a real >> problem given my observations above! >> >> I don't have experience of MISRA-based systems, >> and I don't know how many of the fun and games >> outlined in the FQA are trapped out. >> >> >>> I find C to be fairly pleasant and surprise-free in use. >> >> It gets /much/ nastier on machines with multiple levels >> of memory hierarchy, including caches, local memory >> and remote memory - and, of course, multiprocessors. > > I tend to use C on devices using up to ~256k code, so far. C/C++ is touted as being suitable for everything. Those that have had to debug foul problems in other people's code disagree. >> When considering those factors, the compiler writers >> and compiler users have difficulty agreeing what is >> "meant" by the source code. Doubly so when different >> (generations of) compiler are used.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-17 14:59 +0100 |
| Message-ID | <o86vg0$4k4$1@dont-email.me> |
| In reply to | #447879 |
On 16/02/17 18:18, Tom Gardner wrote: > On 16/02/17 16:45, John Devereux wrote: >> Tom Gardner <spamjunk@blueyonder.co.uk> writes: >> >>> On 16/02/17 14:40, John Devereux wrote: >>>> Tom Gardner <spamjunk@blueyonder.co.uk> writes: >>>> >>>>> On 16/02/17 12:57, John Devereux wrote: >>>>>> David Brown <david.brown@hesbynett.no> writes: >>>>>> >>>>>>> On 10/02/17 01:44, M Philbrook wrote: >>>>>>>> >>>>>>>> I am glad you dont do any coding work for me or anyone I deal >>>>>>>> with.. >>>>>>>> >>>>>>> >>>>>>> Why? Is it just because I explained things in a lot of detail, >>>>>>> or do >>>>>>> you think any of what I wrote is incorrect? If so, give me the >>>>>>> details >>>>>>> and references to the section numbers in a C standard (the N1570 >>>>>>> draft >>>>>>> of C11 is the modern one) and I will see if we can sort out the >>>>>>> differences in understandings. >>>>>> >>>>>> David, you are an expert. >>>>>> >>>>>> We've had enough of experts.... >>>>> >>>>> There are two possible translations of that >>>>> 1) we don't like people that use facts to point >>>>> out where our gut feelings are wrong >>>> >>>> That is the one I was going for. Along the lines of, we have our own >>>> alternative facts. >>>> >>>> It was of course an excellent post, informative as always from David! >>>> >>>>> 2) we shouldn't need experts (of this kind) to >>>>> implement systems. >>>> >>>> >>>>> The former is disreputable and the realm of >>>>> snake-oil salesman. >>>>> >>>>> The latter is either wishful thinking, or a >>>>> statement that this toolset and associated >>>>> /necessary/ "language lawyer" mentality is >>>>> unacceptable. I tend to the latter. >>>> >>>> I have been programming in C for a long time in embedded systems, >>>> but it >>>> is only a small part of my job. I don't consider myself an "expert" and >>>> certainly not a language lawyer. >>> >>> My career trajectory meant I was a heavy user of C >>> in the early-late 80s, >> >> That is when I learned all the bad habits I later had to unlearn - using >> C on crappy 8 bit processors with only a few registers and not much help >> with optimisation from the inefficient buggy compilers. >> >> So the shortage of RAM and index registers meant my code had lots of >> global 8bit variables for "efficiency", since the CPUs could not do >> indexed or stack based addressing at all well. So code was faster and >> shorter with variables in fixed absolute addresses. Stack was limited so >> one tended towards long functions instead of breaking things up into >> shorter ones. Etc. >> >> The I used the AVR of the thread. This was slightly more modern but >> still not perfectly suited for C. For example its 8-bit registers are a >> poor match for C's general arithmetic types and the different types of >> memory area require some nasty kludges IIRC. >> >> I think the current day cortex M CPUs are probably more like the >> minicomputers C was designed for (but much faster). C and c++ are a >> perfect match here, with gcc an excellent and free compiler. > > I don't have many quibbles with that, but problems begin > to creep in when A9 (etc) come into the equation. Even > mid-range FPGAs have dual-core A class processor in > them nowadays. > I have worked with low-level programming on dual-core processors with caches. There are things that you need to take into account, but it is perfectly possible to write C (or C++) on them. The key point is to realise that "volatile" does /not/ mean "make the chip do what I want". Then you need to learn how caches and interaction between the cores and the hardware work, and what magic incantations are needed to get the communication in the right order. If you are lucky, you have an RTOS and you use the functions from that. Less lucky, and you use library functions or compiler built-in functions. Unlucky, and you write your own inline assembly functions and use them.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-02-17 14:24 +0000 |
| Message-ID | <mIDpA.399355$fs3.70023@fx14.am4> |
| In reply to | #447998 |
On 17/02/17 13:59, David Brown wrote: > On 16/02/17 18:18, Tom Gardner wrote: >> On 16/02/17 16:45, John Devereux wrote: >>> Tom Gardner <spamjunk@blueyonder.co.uk> writes: >>> >>>> On 16/02/17 14:40, John Devereux wrote: >>>>> Tom Gardner <spamjunk@blueyonder.co.uk> writes: >>>>> >>>>>> On 16/02/17 12:57, John Devereux wrote: >>>>>>> David Brown <david.brown@hesbynett.no> writes: >>>>>>> >>>>>>>> On 10/02/17 01:44, M Philbrook wrote: >>>>>>>>> >>>>>>>>> I am glad you dont do any coding work for me or anyone I deal >>>>>>>>> with.. >>>>>>>>> >>>>>>>> >>>>>>>> Why? Is it just because I explained things in a lot of detail, >>>>>>>> or do >>>>>>>> you think any of what I wrote is incorrect? If so, give me the >>>>>>>> details >>>>>>>> and references to the section numbers in a C standard (the N1570 >>>>>>>> draft >>>>>>>> of C11 is the modern one) and I will see if we can sort out the >>>>>>>> differences in understandings. >>>>>>> >>>>>>> David, you are an expert. >>>>>>> >>>>>>> We've had enough of experts.... >>>>>> >>>>>> There are two possible translations of that >>>>>> 1) we don't like people that use facts to point >>>>>> out where our gut feelings are wrong >>>>> >>>>> That is the one I was going for. Along the lines of, we have our own >>>>> alternative facts. >>>>> >>>>> It was of course an excellent post, informative as always from David! >>>>> >>>>>> 2) we shouldn't need experts (of this kind) to >>>>>> implement systems. >>>>> >>>>> >>>>>> The former is disreputable and the realm of >>>>>> snake-oil salesman. >>>>>> >>>>>> The latter is either wishful thinking, or a >>>>>> statement that this toolset and associated >>>>>> /necessary/ "language lawyer" mentality is >>>>>> unacceptable. I tend to the latter. >>>>> >>>>> I have been programming in C for a long time in embedded systems, >>>>> but it >>>>> is only a small part of my job. I don't consider myself an "expert" and >>>>> certainly not a language lawyer. >>>> >>>> My career trajectory meant I was a heavy user of C >>>> in the early-late 80s, >>> >>> That is when I learned all the bad habits I later had to unlearn - using >>> C on crappy 8 bit processors with only a few registers and not much help >>> with optimisation from the inefficient buggy compilers. >>> >>> So the shortage of RAM and index registers meant my code had lots of >>> global 8bit variables for "efficiency", since the CPUs could not do >>> indexed or stack based addressing at all well. So code was faster and >>> shorter with variables in fixed absolute addresses. Stack was limited so >>> one tended towards long functions instead of breaking things up into >>> shorter ones. Etc. >>> >>> The I used the AVR of the thread. This was slightly more modern but >>> still not perfectly suited for C. For example its 8-bit registers are a >>> poor match for C's general arithmetic types and the different types of >>> memory area require some nasty kludges IIRC. >>> >>> I think the current day cortex M CPUs are probably more like the >>> minicomputers C was designed for (but much faster). C and c++ are a >>> perfect match here, with gcc an excellent and free compiler. >> >> I don't have many quibbles with that, but problems begin >> to creep in when A9 (etc) come into the equation. Even >> mid-range FPGAs have dual-core A class processor in >> them nowadays. >> > > I have worked with low-level programming on dual-core processors with > caches. There are things that you need to take into account, but it is > perfectly possible to write C (or C++) on them. The key point is to > realise that "volatile" does /not/ mean "make the chip do what I want". No surprises there! But "perfectly possible" doesn't change any of the points I've been making. In practice I would want to examine the compiler's output and compare it with (my understanding of) the hardware. Rinse and repeat for different architectures and compilers. > Then you need to learn how caches and interaction between the cores and > the hardware work, and what magic incantations are needed to get the > communication in the right order. If you are lucky, you have an RTOS > and you use the functions from that. Less lucky, and you use library > functions or compiler built-in functions. Unlucky, and you write your > own inline assembly functions and use them. My preference has been to use RTOSs, but even there there can be problems. I once had to diagnose a problem (probably unrelated to this discussion, but I'll never know) by disassembling what I could see happening on the bus. One value "entered" the RTOS, and later on another "emerged". Fun fun fun.
[toc] | [prev] | [next] | [standalone]
| From | Tauno Voipio <tauno.voipio@notused.fi.invalid> |
|---|---|
| Date | 2017-02-17 21:07 +0200 |
| Message-ID | <o87hia$8vq$1@dont-email.me> |
| In reply to | #448001 |
On 17.2.17 16:24, Tom Gardner wrote: > On 17/02/17 13:59, David Brown wrote: >> On 16/02/17 18:18, Tom Gardner wrote: >>> On 16/02/17 16:45, John Devereux wrote: >>>> Tom Gardner <spamjunk@blueyonder.co.uk> writes: >>>> >>>>> On 16/02/17 14:40, John Devereux wrote: >>>>>> Tom Gardner <spamjunk@blueyonder.co.uk> writes: >>>>>> >>>>>>> On 16/02/17 12:57, John Devereux wrote: >>>>>>>> David Brown <david.brown@hesbynett.no> writes: >>>>>>>> >>>>>>>>> On 10/02/17 01:44, M Philbrook wrote: >>>>>>>>>> >>>>>>>>>> I am glad you dont do any coding work for me or anyone I deal >>>>>>>>>> with.. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Why? Is it just because I explained things in a lot of detail, >>>>>>>>> or do >>>>>>>>> you think any of what I wrote is incorrect? If so, give me the >>>>>>>>> details >>>>>>>>> and references to the section numbers in a C standard (the N1570 >>>>>>>>> draft >>>>>>>>> of C11 is the modern one) and I will see if we can sort out the >>>>>>>>> differences in understandings. >>>>>>>> >>>>>>>> David, you are an expert. >>>>>>>> >>>>>>>> We've had enough of experts.... >>>>>>> >>>>>>> There are two possible translations of that >>>>>>> 1) we don't like people that use facts to point >>>>>>> out where our gut feelings are wrong >>>>>> >>>>>> That is the one I was going for. Along the lines of, we have our own >>>>>> alternative facts. >>>>>> >>>>>> It was of course an excellent post, informative as always from David! >>>>>> >>>>>>> 2) we shouldn't need experts (of this kind) to >>>>>>> implement systems. >>>>>> >>>>>> >>>>>>> The former is disreputable and the realm of >>>>>>> snake-oil salesman. >>>>>>> >>>>>>> The latter is either wishful thinking, or a >>>>>>> statement that this toolset and associated >>>>>>> /necessary/ "language lawyer" mentality is >>>>>>> unacceptable. I tend to the latter. >>>>>> >>>>>> I have been programming in C for a long time in embedded systems, >>>>>> but it >>>>>> is only a small part of my job. I don't consider myself an >>>>>> "expert" and >>>>>> certainly not a language lawyer. >>>>> >>>>> My career trajectory meant I was a heavy user of C >>>>> in the early-late 80s, >>>> >>>> That is when I learned all the bad habits I later had to unlearn - >>>> using >>>> C on crappy 8 bit processors with only a few registers and not much >>>> help >>>> with optimisation from the inefficient buggy compilers. >>>> >>>> So the shortage of RAM and index registers meant my code had lots of >>>> global 8bit variables for "efficiency", since the CPUs could not do >>>> indexed or stack based addressing at all well. So code was faster and >>>> shorter with variables in fixed absolute addresses. Stack was >>>> limited so >>>> one tended towards long functions instead of breaking things up into >>>> shorter ones. Etc. >>>> >>>> The I used the AVR of the thread. This was slightly more modern but >>>> still not perfectly suited for C. For example its 8-bit registers are a >>>> poor match for C's general arithmetic types and the different types of >>>> memory area require some nasty kludges IIRC. >>>> >>>> I think the current day cortex M CPUs are probably more like the >>>> minicomputers C was designed for (but much faster). C and c++ are a >>>> perfect match here, with gcc an excellent and free compiler. >>> >>> I don't have many quibbles with that, but problems begin >>> to creep in when A9 (etc) come into the equation. Even >>> mid-range FPGAs have dual-core A class processor in >>> them nowadays. >>> >> >> I have worked with low-level programming on dual-core processors with >> caches. There are things that you need to take into account, but it is >> perfectly possible to write C (or C++) on them. The key point is to >> realise that "volatile" does /not/ mean "make the chip do what I want". > > No surprises there! But "perfectly possible" doesn't > change any of the points I've been making. In practice > I would want to examine the compiler's output and > compare it with (my understanding of) the hardware. > Rinse and repeat for different architectures and > compilers. > > >> Then you need to learn how caches and interaction between the cores and >> the hardware work, and what magic incantations are needed to get the >> communication in the right order. If you are lucky, you have an RTOS >> and you use the functions from that. Less lucky, and you use library >> functions or compiler built-in functions. Unlucky, and you write your >> own inline assembly functions and use them. > > My preference has been to use RTOSs, but even there there > can be problems. I once had to diagnose a problem (probably > unrelated to this discussion, but I'll never know) by > disassembling what I could see happening on the bus. One > value "entered" the RTOS, and later on another "emerged". > Fun fun fun. Even knowing the instruction sequence in processor code memory does not guarantee the order of bus sequences in modern processors. You need memory barrier instructions to guarantee the sequence, but you'll mess with the processing performance then. -- -TV
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-02-17 20:16 +0000 |
| Message-ID | <NSIpA.84158$VH6.3517@fx46.am4> |
| In reply to | #448034 |
On 17/02/17 19:07, Tauno Voipio wrote: > On 17.2.17 16:24, Tom Gardner wrote: >> On 17/02/17 13:59, David Brown wrote: >>> On 16/02/17 18:18, Tom Gardner wrote: >>>> On 16/02/17 16:45, John Devereux wrote: >>>>> Tom Gardner <spamjunk@blueyonder.co.uk> writes: >>>>> >>>>>> On 16/02/17 14:40, John Devereux wrote: >>>>>>> Tom Gardner <spamjunk@blueyonder.co.uk> writes: >>>>>>> >>>>>>>> On 16/02/17 12:57, John Devereux wrote: >>>>>>>>> David Brown <david.brown@hesbynett.no> writes: >>>>>>>>> >>>>>>>>>> On 10/02/17 01:44, M Philbrook wrote: >>>>>>>>>>> >>>>>>>>>>> I am glad you dont do any coding work for me or anyone I deal >>>>>>>>>>> with.. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Why? Is it just because I explained things in a lot of detail, >>>>>>>>>> or do >>>>>>>>>> you think any of what I wrote is incorrect? If so, give me the >>>>>>>>>> details >>>>>>>>>> and references to the section numbers in a C standard (the N1570 >>>>>>>>>> draft >>>>>>>>>> of C11 is the modern one) and I will see if we can sort out the >>>>>>>>>> differences in understandings. >>>>>>>>> >>>>>>>>> David, you are an expert. >>>>>>>>> >>>>>>>>> We've had enough of experts.... >>>>>>>> >>>>>>>> There are two possible translations of that >>>>>>>> 1) we don't like people that use facts to point >>>>>>>> out where our gut feelings are wrong >>>>>>> >>>>>>> That is the one I was going for. Along the lines of, we have our own >>>>>>> alternative facts. >>>>>>> >>>>>>> It was of course an excellent post, informative as always from David! >>>>>>> >>>>>>>> 2) we shouldn't need experts (of this kind) to >>>>>>>> implement systems. >>>>>>> >>>>>>> >>>>>>>> The former is disreputable and the realm of >>>>>>>> snake-oil salesman. >>>>>>>> >>>>>>>> The latter is either wishful thinking, or a >>>>>>>> statement that this toolset and associated >>>>>>>> /necessary/ "language lawyer" mentality is >>>>>>>> unacceptable. I tend to the latter. >>>>>>> >>>>>>> I have been programming in C for a long time in embedded systems, >>>>>>> but it >>>>>>> is only a small part of my job. I don't consider myself an >>>>>>> "expert" and >>>>>>> certainly not a language lawyer. >>>>>> >>>>>> My career trajectory meant I was a heavy user of C >>>>>> in the early-late 80s, >>>>> >>>>> That is when I learned all the bad habits I later had to unlearn - >>>>> using >>>>> C on crappy 8 bit processors with only a few registers and not much >>>>> help >>>>> with optimisation from the inefficient buggy compilers. >>>>> >>>>> So the shortage of RAM and index registers meant my code had lots of >>>>> global 8bit variables for "efficiency", since the CPUs could not do >>>>> indexed or stack based addressing at all well. So code was faster and >>>>> shorter with variables in fixed absolute addresses. Stack was >>>>> limited so >>>>> one tended towards long functions instead of breaking things up into >>>>> shorter ones. Etc. >>>>> >>>>> The I used the AVR of the thread. This was slightly more modern but >>>>> still not perfectly suited for C. For example its 8-bit registers are a >>>>> poor match for C's general arithmetic types and the different types of >>>>> memory area require some nasty kludges IIRC. >>>>> >>>>> I think the current day cortex M CPUs are probably more like the >>>>> minicomputers C was designed for (but much faster). C and c++ are a >>>>> perfect match here, with gcc an excellent and free compiler. >>>> >>>> I don't have many quibbles with that, but problems begin >>>> to creep in when A9 (etc) come into the equation. Even >>>> mid-range FPGAs have dual-core A class processor in >>>> them nowadays. >>>> >>> >>> I have worked with low-level programming on dual-core processors with >>> caches. There are things that you need to take into account, but it is >>> perfectly possible to write C (or C++) on them. The key point is to >>> realise that "volatile" does /not/ mean "make the chip do what I want". >> >> No surprises there! But "perfectly possible" doesn't >> change any of the points I've been making. In practice >> I would want to examine the compiler's output and >> compare it with (my understanding of) the hardware. >> Rinse and repeat for different architectures and >> compilers. >> >> >>> Then you need to learn how caches and interaction between the cores and >>> the hardware work, and what magic incantations are needed to get the >>> communication in the right order. If you are lucky, you have an RTOS >>> and you use the functions from that. Less lucky, and you use library >>> functions or compiler built-in functions. Unlucky, and you write your >>> own inline assembly functions and use them. >> >> My preference has been to use RTOSs, but even there there >> can be problems. I once had to diagnose a problem (probably >> unrelated to this discussion, but I'll never know) by >> disassembling what I could see happening on the bus. One >> value "entered" the RTOS, and later on another "emerged". >> Fun fun fun. > > > Even knowing the instruction sequence in processor code memory > does not guarantee the order of bus sequences in modern processors. > > You need memory barrier instructions to guarantee the sequence, but > you'll mess with the processing performance then. It was on a 68020, so I nearly had that problem. I did have to manually figure out which instructions and memory reads seen on the bus actually had an effect. Later processors would have been worse, of course.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-17 23:28 +0100 |
| Message-ID | <o87ta4$kjr$1@dont-email.me> |
| In reply to | #448034 |
On 17/02/17 20:07, Tauno Voipio wrote: > Even knowing the instruction sequence in processor code memory > does not guarantee the order of bus sequences in modern processors. > > You need memory barrier instructions to guarantee the sequence, but > you'll mess with the processing performance then. > You also need the right kind of memory barrier - there are many levels of ordering for a modern processor. You have the compiler level (volatile is enough to force an ordering there with respect to other volatile accesses - but not with respect to non-volatile accesses). Then you might have write buffers in the cpu core, then caches with write-back, possibly cross-switches with buffering, then memory controllers with buffering and re-ordering. Fortunately, it is very rare that you actually /need/ a particular sequence of accesses on the final memory bus. Usually you only need it on internal peripherals on a SoC, and that is easier if you have your MMU set up correctly to skip caches and buffers.
[toc] | [prev] | [next] | [standalone]
| From | Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> |
|---|---|
| Date | 2017-02-17 10:21 -0500 |
| Message-ID | <kPmdnSvq3aV_iTrFnZ2dnUU7-cGdnZ2d@supernews.com> |
| In reply to | #447998 |
On 02/17/2017 08:59 AM, David Brown wrote: > On 16/02/17 18:18, Tom Gardner wrote: >> On 16/02/17 16:45, John Devereux wrote: >>> Tom Gardner <spamjunk@blueyonder.co.uk> writes: >>> >>>> On 16/02/17 14:40, John Devereux wrote: >>>>> Tom Gardner <spamjunk@blueyonder.co.uk> writes: >>>>> >>>>>> On 16/02/17 12:57, John Devereux wrote: >>>>>>> David Brown <david.brown@hesbynett.no> writes: >>>>>>> >>>>>>>> On 10/02/17 01:44, M Philbrook wrote: >>>>>>>>> >>>>>>>>> I am glad you dont do any coding work for me or anyone I deal >>>>>>>>> with.. >>>>>>>>> >>>>>>>> >>>>>>>> Why? Is it just because I explained things in a lot of detail, >>>>>>>> or do >>>>>>>> you think any of what I wrote is incorrect? If so, give me the >>>>>>>> details >>>>>>>> and references to the section numbers in a C standard (the N1570 >>>>>>>> draft >>>>>>>> of C11 is the modern one) and I will see if we can sort out the >>>>>>>> differences in understandings. >>>>>>> >>>>>>> David, you are an expert. >>>>>>> >>>>>>> We've had enough of experts.... >>>>>> >>>>>> There are two possible translations of that >>>>>> 1) we don't like people that use facts to point >>>>>> out where our gut feelings are wrong >>>>> >>>>> That is the one I was going for. Along the lines of, we have our own >>>>> alternative facts. >>>>> >>>>> It was of course an excellent post, informative as always from David! >>>>> >>>>>> 2) we shouldn't need experts (of this kind) to >>>>>> implement systems. >>>>> >>>>> >>>>>> The former is disreputable and the realm of >>>>>> snake-oil salesman. >>>>>> >>>>>> The latter is either wishful thinking, or a >>>>>> statement that this toolset and associated >>>>>> /necessary/ "language lawyer" mentality is >>>>>> unacceptable. I tend to the latter. >>>>> >>>>> I have been programming in C for a long time in embedded systems, >>>>> but it >>>>> is only a small part of my job. I don't consider myself an "expert" and >>>>> certainly not a language lawyer. >>>> >>>> My career trajectory meant I was a heavy user of C >>>> in the early-late 80s, >>> >>> That is when I learned all the bad habits I later had to unlearn - using >>> C on crappy 8 bit processors with only a few registers and not much help >>> with optimisation from the inefficient buggy compilers. >>> >>> So the shortage of RAM and index registers meant my code had lots of >>> global 8bit variables for "efficiency", since the CPUs could not do >>> indexed or stack based addressing at all well. So code was faster and >>> shorter with variables in fixed absolute addresses. Stack was limited so >>> one tended towards long functions instead of breaking things up into >>> shorter ones. Etc. >>> >>> The I used the AVR of the thread. This was slightly more modern but >>> still not perfectly suited for C. For example its 8-bit registers are a >>> poor match for C's general arithmetic types and the different types of >>> memory area require some nasty kludges IIRC. >>> >>> I think the current day cortex M CPUs are probably more like the >>> minicomputers C was designed for (but much faster). C and c++ are a >>> perfect match here, with gcc an excellent and free compiler. >> >> I don't have many quibbles with that, but problems begin >> to creep in when A9 (etc) come into the equation. Even >> mid-range FPGAs have dual-core A class processor in >> them nowadays. >> > > I have worked with low-level programming on dual-core processors with > caches. There are things that you need to take into account, but it is > perfectly possible to write C (or C++) on them. The key point is to > realise that "volatile" does /not/ mean "make the chip do what I want". Really? ;) 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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-17 16:34 +0100 |
| Message-ID | <o87530$psb$1@dont-email.me> |
| In reply to | #448004 |
On 17/02/17 16:21, Phil Hobbs wrote: > On 02/17/2017 08:59 AM, David Brown wrote: >> >> I have worked with low-level programming on dual-core processors with >> caches. There are things that you need to take into account, but it is >> perfectly possible to write C (or C++) on them. The key point is to >> realise that "volatile" does /not/ mean "make the chip do what I want". > > Really? ;) > It's amazing how many people seem to think that is what volatile does. You want to transfer data between threads (or interrupts and main loop code)? Use volatile - it is the same as synchronisation. You want to be sure that your transfer of 32-bit values on an 8-bit system are atomic? Use volatile - it implies atomicity. You want to make sure a calculation is done outside of a critical section? Use volatile - it forces an ordering on your calculations. You want to make sure that the DMA sees the same data as your cpu despite the cache? Use volatile - it forces cache coherency. You want to make the compiler forget what it knows about your "bool" variable? Use volatile - it tells the compiler that you are breaking the rules. And so on. Assuming that "volatile" has superpowers is almost as common as forgetting to use it when it is needed, and then claiming the compiler's optimiser is broken.
[toc] | [prev] | [next] | [standalone]
| From | M Philbrook <jamie_ka1lpa@charter.net> |
|---|---|
| Date | 2017-02-09 19:43 -0500 |
| Message-ID | <MPG.3306d6c5d8f3386798a008@news.eternal-september.org> |
| In reply to | #447011 |
In article <bf33f3d7-1702-4d37-a030-7d22ae46d7ba@googlegroups.com>,
jack4747@gmail.com says...
>
> Il giorno mercoledì 8 febbraio 2017 17:25:43 UTC+1, David Brown ha scritto:
> > On 08/02/17 16:01, pcdhobbs@gmail.com wrote:
> > >> That is a completely different matter. A conditional statement
> > >> ("if", "while", etc.) compares its argument to 0 (in C) or
> > >> "contextually converts to bool" (in C++) - thus any non-false value
> > >> is considered "true".
> > >
> > > Back in the late '70s (iirc) the Forth standard changed to make TRUE
> > > = -1 instead of 1, causing massive breakage. The rationale was that
> > > on a twos-complement machine that made every bit of the word 1, so
> > > you could use TRUE and FALSE in bitwise operations too.
> > >
> > > Nice idea, if they'd thought of it the first time round. :(
> > >
> >
> > It is not entirely unreasonable to standardise on -1 for "true". But C
> > (and C++) standardised on 1, and that's the way it is. (It's a better
> > choice anyway - it has the same representation in all integer types, no
> > matter what size or signedness.)
>
> nope.
> C per definition has 0 == FALSE, and TRUE is anything different from FALSE.
>
> Bye Jack
Yes, Finally, someone knows what's going on ;)
Actually, that holds TRUE in most languages I deal with ..
Jamie
[toc] | [prev] | [next] | [standalone]
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
Back to top | Article view | sci.electronics.design
csiph-web