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 1 of 7 [1] 2 3 4 5 6 7 Next page →
| From | dagmargoodboat@yahoo.com |
|---|---|
| Date | 2017-02-06 15:43 -0800 |
| Subject | Arduino / compilers on uC |
| Message-ID | <4bd745cb-5d48-4573-9a63-a9eec5a39b0d@googlegroups.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):
00001006 <digitalWrite>:
1006: 90 e0 ldi r25, 0x00 ; 0
1008: fc 01 movw r30, r24
100a: e3 52 subi r30, 0x23 ; 35
100c: fd 4f sbci r31, 0xFD ; 253
100e: 34 91 lpm r19, Z
1010: fc 01 movw r30, r24
1012: e7 53 subi r30, 0x37 ; 55
1014: fd 4f sbci r31, 0xFD ; 253
1016: 24 91 lpm r18, Z
1018: fc 01 movw r30, r24
101a: eb 54 subi r30, 0x4B ; 75
101c: fd 4f sbci r31, 0xFD ; 253
101e: e4 91 lpm r30, Z
1020: ee 23 and r30, r30
1022: 09 f4 brne .+2 ; 0x1026 <digitalWrite+0x20>
1024: 3b c0 rjmp .+118 ; 0x109c <digitalWrite+0x96>
1026: 33 23 and r19, r19
1028: 39 f1 breq .+78 ; 0x1078 <digitalWrite+0x72>
102a: 33 30 cpi r19, 0x03 ; 3
102c: 91 f0 breq .+36 ; 0x1052 <digitalWrite+0x4c>
102e: 38 f4 brcc .+14 ; 0x103e <digitalWrite+0x38>
1030: 31 30 cpi r19, 0x01 ; 1
1032: a9 f0 breq .+42 ; 0x105e <digitalWrite+0x58>
1034: 32 30 cpi r19, 0x02 ; 2
1036: 01 f5 brne .+64 ; 0x1078 <digitalWrite+0x72>
1038: 84 b5 in r24, 0x24 ; 36
103a: 8f 7d andi r24, 0xDF ; 223
103c: 12 c0 rjmp .+36 ; 0x1062 <digitalWrite+0x5c>
103e: 37 30 cpi r19, 0x07 ; 7
1040: 91 f0 breq .+36 ; 0x1066 <digitalWrite+0x60>
1042: 38 30 cpi r19, 0x08 ; 8
1044: a1 f0 breq .+40 ; 0x106e <digitalWrite+0x68>
1046: 34 30 cpi r19, 0x04 ; 4
1048: b9 f4 brne .+46 ; 0x1078 <digitalWrite+0x72>
104a: 80 91 80 00 lds r24, 0x0080 ; 0x800080 <__data_load_end+0x7fcf9e>
104e: 8f 7d andi r24, 0xDF ; 223
1050: 03 c0 rjmp .+6 ; 0x1058 <digitalWrite+0x52>
1052: 80 91 80 00 lds r24, 0x0080 ; 0x800080 <__data_load_end+0x7fcf9e>
1056: 8f 77 andi r24, 0x7F ; 127
1058: 80 93 80 00 sts 0x0080, r24 ; 0x800080 <__data_load_end+0x7fcf9e>
105c: 0d c0 rjmp .+26 ; 0x1078 <digitalWrite+0x72>
105e: 84 b5 in r24, 0x24 ; 36
1060: 8f 77 andi r24, 0x7F ; 127
1062: 84 bd out 0x24, r24 ; 36
1064: 09 c0 rjmp .+18 ; 0x1078 <digitalWrite+0x72>
1066: 80 91 b0 00 lds r24, 0x00B0 ; 0x8000b0 <__data_load_end+0x7fcfce>
106a: 8f 77 andi r24, 0x7F ; 127
106c: 03 c0 rjmp .+6 ; 0x1074 <digitalWrite+0x6e>
106e: 80 91 b0 00 lds r24, 0x00B0 ; 0x8000b0 <__data_load_end+0x7fcfce>
1072: 8f 7d andi r24, 0xDF ; 223
1074: 80 93 b0 00 sts 0x00B0, r24 ; 0x8000b0 <__data_load_end+0x7fcfce>
1078: f0 e0 ldi r31, 0x00 ; 0
107a: ee 0f add r30, r30
107c: ff 1f adc r31, r31
107e: e5 55 subi r30, 0x55 ; 85
1080: fd 4f sbci r31, 0xFD ; 253
1082: a5 91 lpm r26, Z+
1084: b4 91 lpm r27, Z
1086: 8f b7 in r24, 0x3f ; 63
1088: f8 94 cli
108a: ec 91 ld r30, X
108c: 61 11 cpse r22, r1
108e: 03 c0 rjmp .+6 ; 0x1096 <digitalWrite+0x90>
1090: 20 95 com r18
1092: 2e 23 and r18, r30
1094: 01 c0 rjmp .+2 ; 0x1098 <digitalWrite+0x92>
1096: 2e 2b or r18, r30
1098: 2c 93 st X, r18
109a: 8f bf out 0x3f, r24 ; 63
109c: 08 95 ret
60 lines.
Assembly takes one or two lines, and is proportionally faster.
Meanwhile, I just spent three days tracking down a compiler error--
the compiler insisted (0xff & 1) = 254. It was no fun tracking down,
and ultimately took a workaround.
Cute system, horrible documentation. I'm afraid it sets a lot of kids
off on the wrong foot, hacking instead of thinking.
YMMV.
Cheers,
James Arthur
[toc] | [next] | [standalone]
| From | Clifford Heath <no.spam@please.net> |
|---|---|
| Date | 2017-02-07 10:58 +1100 |
| Message-ID | <58990d90$0$57736$c3e8da3$5e5e430d@news.astraweb.com> |
| In reply to | #446506 |
On 07/02/17 10:43, dagmargoodboat@yahoo.com wrote: > 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): > > 00001006 <digitalWrite>: > ...snip... > 60 lines. > > Assembly takes one or two lines, and is proportionally faster. Yes, it's horrid, but the assembler version doesn't do the same thing. The digitalWrite function looks up a pin mapping table in flash in order to create an artificial portability across Arduino versions. Accessing flash is awkward because it's Harvard arch. It's a stupid thing to want to do - it could be done at compile time using C++ inlines and templates - but the compiler does a fairly decent job of it. > Meanwhile, I just spent three days tracking down a compiler error-- > the compiler insisted (0xff & 1) = 254. I don't believe you. Show us your code and your compiler version. I bet you did (0xFF & ~1). Clifford Heath.
[toc] | [prev] | [next] | [standalone]
| From | bitrex <bitrex@de.lete.earthlink.net> |
|---|---|
| Date | 2017-02-06 19:09 -0500 |
| Message-ID | <qf8mA.119$Rm6.109@fx21.iad> |
| In reply to | #446512 |
On 02/06/2017 06:58 PM, Clifford Heath wrote: > On 07/02/17 10:43, dagmargoodboat@yahoo.com wrote: >> 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): >> >> 00001006 <digitalWrite>: >> ...snip... >> 60 lines. >> >> Assembly takes one or two lines, and is proportionally faster. > > Yes, it's horrid, but the assembler version doesn't do the same thing. > The digitalWrite function looks up a pin mapping table in flash > in order to create an artificial portability across Arduino versions. > Accessing flash is awkward because it's Harvard arch. It's a stupid > thing to want to do - it could be done at compile time using C++ > inlines and templates - but the compiler does a fairly decent job of it. > >> Meanwhile, I just spent three days tracking down a compiler error-- >> the compiler insisted (0xff & 1) = 254. > > I don't believe you. Show us your code and your compiler version. > I bet you did (0xFF & ~1). > > Clifford Heath. > Something that low level would have to be an error in gcc's own handling of bitwise operators, which seems...unlikely
[toc] | [prev] | [next] | [standalone]
| From | dagmargoodboat@yahoo.com |
|---|---|
| Date | 2017-02-06 18:30 -0800 |
| Message-ID | <a158e0f2-5a6f-4048-8eb1-a6ce4d7a9771@googlegroups.com> |
| In reply to | #446512 |
On Monday, February 6, 2017 at 6:58:13 PM UTC-5, Clifford Heath wrote:
> On 07/02/17 10:43, dagmargoodboat@yahoo.com wrote:
> > 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):
> >
> > 00001006 <digitalWrite>:
> > ...snip...
> > 60 lines.
> >
> > Assembly takes one or two lines, and is proportionally faster.
>
> Yes, it's horrid, but the assembler version doesn't do the same thing.
> The digitalWrite function looks up a pin mapping table in flash
> in order to create an artificial portability across Arduino versions.
> Accessing flash is awkward because it's Harvard arch. It's a stupid
> thing to want to do - it could be done at compile time using C++
> inlines and templates - but the compiler does a fairly decent job of it.
>
> > Meanwhile, I just spent three days tracking down a compiler error--
> > the compiler insisted (0xff & 1) = 254.
>
> I don't believe you. Show us your code and your compiler version.
> I bet you did (0xFF & ~1).
>
> Clifford Heath.
It's pretty messy to document, but the gist is that I wanted to toggle
a boolean flag with the statement
flg = flg ? false : true;
where 'true' == 1, 'false' == 0, Arduino-defined.
It didn't work--the variable was assigned either 0xfe, or 0xff.
Boolean on the AVR is an unsigned byte, flg was initialized to 0xff,
from blank EEPROM (as expected, prior to storing user parameters).
When simple statements didn't work as expected, I added a bunch of print
statements to diagnose the problem (below, with output).
You can see that, with 'boolean' type, output lines 6a., 6b., 7a., 7b.
do not give the expected results.
If I change
11. w = (U.dat.flg) ? true : false; to
11. w = (U.dat.flg) ? false : true;
and w=0xff, line 13. reports that (w & 0x1) == 254.
The upshot was that the compiler generates different code for a 'boolean'
and a 'uint8_t', even though they're both supposed to be unsigned char.
Either type should've been fine for my purposes. Both should've worked.
I tried various gimmicks like casts, forcing conversions, and assigning
to int or word types to try forcing the compiler to treat values
differently, to no avail.
Source:
1. int b,c,i;
2. word w;
3. float v;
4.
5. Serial.print(F(" 1. 'true' = ")); Serial.print(true,HEX); Serial.print(F(" 2. 'false' = ")); Serial.println(false,HEX);
6. Serial.print(F(" 3. 'i = true' =")); Serial.print((i = true),HEX); Serial.print(F(" 4. 'w = false' =")); Serial.println((w = false),HEX);
7. Serial.print(F(" 5. Before toggle, U.dat.flg = ")); Serial.println(U.dat.flg, HEX);
8.
9. i = (int) U.dat.flg;
10. Serial.print(F(" 6a. i = (int) U.dat.flg =")); Serial.println(i,HEX);
11. w = (U.dat.flg) ? true : false;
12.
13. Serial.print(F(" 6b. After assignment by '?' to 'true' : 'false', w = ")); Serial.println(w,HEX);
14.
15. if (U.dat.flg) {
16. w = true;
17. } else {
18. w = false;
19. }
20.
21. Serial.print(F(" 6c. After if-then assignment to 'true' or 'false', w = ")); Serial.println(w,HEX);
22.
23. Serial.print(F(" 7a. i & 1 = ")); Serial.println((i & 1), HEX);
24. Serial.print(F(" 7b. w & 1 = ")); Serial.println((w & (word)1), HEX);
25.
26. Serial.print(F(" 8a. (i & 0x1u) = ")); Serial.println((i & 0x1u), HEX);
27. Serial.print(F(" 8b. (w & 0x1) = ")); Serial.println((w & 0x1), HEX);
28. Serial.print(F(" 8c. (0xff & 0x1) = ")); Serial.println((0xff & 0x1), HEX);
=== Output with U.dat.flg declared 'boolean'===
1. 'true' = 1 2. 'false' = 0
3. 'i = true' =1 4. 'w = false' =0
5. Before toggle, U.dat.flg = FF
6a. i = (int) U.dat.flg =FF
->---> 6b. After 'w = (U.dat.flg) ? true : false', w = FF <--- should be 0x1!!!
6c. After if-then assignment to 'true' or 'false', w = FF <--- should be 0x1 !!
7a. i & 1 = FF <--- should be 0x1 !!
7b. w & 1 = FF <--- should be 0x1 !!
8a. (i & 0x1u) = FF <--- should be 0x1 !!
8b. (w & 0x1) = FF <--- should be 0x1 !!
8c. (0xff & 0x1) = 1
=== Output with U.dat.flg declared 'uint8_t'===
1. 'true' = 1 2. 'false' = 0
3. 'i = true' =1 4. 'w = false' =0
5. Before toggle, U.dat.flg = FF
6a. i = (int) U.dat.flg =FF
---> 6b. After 'w = (U.dat.flg) ? true : false', w = 1 <--- 1 = correct.
6c. After if-then assignment to 'true' or 'false', w = 1
7a. i & 1 = 1
7b. w & 1 = 1
8a. (i & 0x1u) = 1
8b. (w & 0x1) = 1
8c. (0xff & 0x1) = 1
Cheers,
James Arthur
[toc] | [prev] | [next] | [standalone]
| From | bitrex <bitrex@de.lete.earthlink.net> |
|---|---|
| Date | 2017-02-06 21:43 -0500 |
| Message-ID | <cvamA.20$Ck4.8@fx44.iad> |
| In reply to | #446574 |
On 02/06/2017 09:30 PM, dagmargoodboat@yahoo.com wrote: > On Monday, February 6, 2017 at 6:58:13 PM UTC-5, Clifford Heath wrote: >> On 07/02/17 10:43, dagmargoodboat@yahoo.com wrote: >>> 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): >>> >>> 00001006 <digitalWrite>: >>> ...snip... >>> 60 lines. >>> >>> Assembly takes one or two lines, and is proportionally faster. >> >> Yes, it's horrid, but the assembler version doesn't do the same thing. >> The digitalWrite function looks up a pin mapping table in flash >> in order to create an artificial portability across Arduino versions. >> Accessing flash is awkward because it's Harvard arch. It's a stupid >> thing to want to do - it could be done at compile time using C++ >> inlines and templates - but the compiler does a fairly decent job of it. >> >>> Meanwhile, I just spent three days tracking down a compiler error-- >>> the compiler insisted (0xff & 1) = 254. >> >> I don't believe you. Show us your code and your compiler version. >> I bet you did (0xFF & ~1). >> >> Clifford Heath. > > > It's pretty messy to document, but the gist is that I wanted to toggle > a boolean flag with the statement > > flg = flg ? false : true; > > where 'true' == 1, 'false' == 0, Arduino-defined. > > It didn't work--the variable was assigned either 0xfe, or 0xff. > > Boolean on the AVR is an unsigned byte, flg was initialized to 0xff, > from blank EEPROM (as expected, prior to storing user parameters). > > When simple statements didn't work as expected, I added a bunch of print > statements to diagnose the problem (below, with output). > > You can see that, with 'boolean' type, output lines 6a., 6b., 7a., 7b. > do not give the expected results. > > If I change > 11. w = (U.dat.flg) ? true : false; to > 11. w = (U.dat.flg) ? false : true; > > and w=0xff, line 13. reports that (w & 0x1) == 254. > > The upshot was that the compiler generates different code for a 'boolean' > and a 'uint8_t', even though they're both supposed to be unsigned char. > > <snip> "boolean" is not an ISO standard C++ data type - use "bool." Or include <stdbool.h> if you want to use "boolean" and it should behave as expected
[toc] | [prev] | [next] | [standalone]
| From | dagmargoodboat@yahoo.com |
|---|---|
| Date | 2017-02-06 19:02 -0800 |
| Message-ID | <ce8bef96-c5c3-444b-975a-4ca670bc33d3@googlegroups.com> |
| In reply to | #446580 |
On Monday, February 6, 2017 at 9:43:23 PM UTC-5, bitrex wrote: > On 02/06/2017 09:30 PM, dagmargoodboat@yahoo.com wrote: > > On Monday, February 6, 2017 at 6:58:13 PM UTC-5, Clifford Heath wrote: > >> On 07/02/17 10:43, dagmargoodboat@yahoo.com wrote: > >>> 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): > >>> > >>> 00001006 <digitalWrite>: > >>> ...snip... > >>> 60 lines. > >>> > >>> Assembly takes one or two lines, and is proportionally faster. > >> > >> Yes, it's horrid, but the assembler version doesn't do the same thing. > >> The digitalWrite function looks up a pin mapping table in flash > >> in order to create an artificial portability across Arduino versions. > >> Accessing flash is awkward because it's Harvard arch. It's a stupid > >> thing to want to do - it could be done at compile time using C++ > >> inlines and templates - but the compiler does a fairly decent job of it. > >> > >>> Meanwhile, I just spent three days tracking down a compiler error-- > >>> the compiler insisted (0xff & 1) = 254. > >> > >> I don't believe you. Show us your code and your compiler version. > >> I bet you did (0xFF & ~1). > >> > >> Clifford Heath. > > > > > > It's pretty messy to document, but the gist is that I wanted to toggle > > a boolean flag with the statement > > > > flg = flg ? false : true; > > > > where 'true' == 1, 'false' == 0, Arduino-defined. > > > > It didn't work--the variable was assigned either 0xfe, or 0xff. > > > > Boolean on the AVR is an unsigned byte, flg was initialized to 0xff, > > from blank EEPROM (as expected, prior to storing user parameters). > > > > When simple statements didn't work as expected, I added a bunch of print > > statements to diagnose the problem (below, with output). > > > > You can see that, with 'boolean' type, output lines 6a., 6b., 7a., 7b. > > do not give the expected results. > > > > If I change > > 11. w = (U.dat.flg) ? true : false; to > > 11. w = (U.dat.flg) ? false : true; > > > > and w=0xff, line 13. reports that (w & 0x1) == 254. > > > > The upshot was that the compiler generates different code for a 'boolean' > > and a 'uint8_t', even though they're both supposed to be unsigned char. > > > > <snip> > > "boolean" is not an ISO standard C++ data type - use "bool." "bool" is what I started off with, gives the same result as "boolean." I switched to "boolean," since that was listed in Arduino's reference page, and, having made it part of their environment, one would hope they've made full provision for it. https://www.arduino.cc/en/Reference/HomePage When that didn't work, I also quit trusting the values of 'true' and 'false', which is why I started specifying numerical values, all to no effect. This is a lot of abstraction -- it's a byte, nothing more. > Or include <stdbool.h> if you want to use "boolean" and it should behave > as expected Cheers, James Arthur
[toc] | [prev] | [next] | [standalone]
| From | bitrex <bitrex@de.lete.earthlink.net> |
|---|---|
| Date | 2017-02-06 23:26 -0500 |
| Message-ID | <O%bmA.1$gF7.0@fx16.iad> |
| In reply to | #446588 |
On 02/06/2017 10:02 PM, dagmargoodboat@yahoo.com wrote:
> On Monday, February 6, 2017 at 9:43:23 PM UTC-5, bitrex wrote:
>> On 02/06/2017 09:30 PM, dagmargoodboat@yahoo.com wrote:
>>> On Monday, February 6, 2017 at 6:58:13 PM UTC-5, Clifford Heath wrote:
>>>> On 07/02/17 10:43, dagmargoodboat@yahoo.com wrote:
>>>>> 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):
>>>>>
>>>>> 00001006 <digitalWrite>:
>>>>> ...snip...
>>>>> 60 lines.
>>>>>
>>>>> Assembly takes one or two lines, and is proportionally faster.
>>>>
>>>> Yes, it's horrid, but the assembler version doesn't do the same thing.
>>>> The digitalWrite function looks up a pin mapping table in flash
>>>> in order to create an artificial portability across Arduino versions.
>>>> Accessing flash is awkward because it's Harvard arch. It's a stupid
>>>> thing to want to do - it could be done at compile time using C++
>>>> inlines and templates - but the compiler does a fairly decent job of it.
>>>>
>>>>> Meanwhile, I just spent three days tracking down a compiler error--
>>>>> the compiler insisted (0xff & 1) = 254.
>>>>
>>>> I don't believe you. Show us your code and your compiler version.
>>>> I bet you did (0xFF & ~1).
>>>>
>>>> Clifford Heath.
>>>
>>>
>>> It's pretty messy to document, but the gist is that I wanted to toggle
>>> a boolean flag with the statement
>>>
>>> flg = flg ? false : true;
>>>
>>> where 'true' == 1, 'false' == 0, Arduino-defined.
>>>
>>> It didn't work--the variable was assigned either 0xfe, or 0xff.
>>>
>>> Boolean on the AVR is an unsigned byte, flg was initialized to 0xff,
>>> from blank EEPROM (as expected, prior to storing user parameters).
>>>
>>> When simple statements didn't work as expected, I added a bunch of print
>>> statements to diagnose the problem (below, with output).
>>>
>>> You can see that, with 'boolean' type, output lines 6a., 6b., 7a., 7b.
>>> do not give the expected results.
>>>
>>> If I change
>>> 11. w = (U.dat.flg) ? true : false; to
>>> 11. w = (U.dat.flg) ? false : true;
>>>
>>> and w=0xff, line 13. reports that (w & 0x1) == 254.
>>>
>>> The upshot was that the compiler generates different code for a 'boolean'
>>> and a 'uint8_t', even though they're both supposed to be unsigned char.
>>>
>>> <snip>
>>
>> "boolean" is not an ISO standard C++ data type - use "bool."
>
> "bool" is what I started off with, gives the same result as "boolean."
> I switched to "boolean," since that was listed in Arduino's reference
> page, and, having made it part of their environment, one would hope
> they've made full provision for it.
>
> https://www.arduino.cc/en/Reference/HomePage
>
> When that didn't work, I also quit trusting the values of 'true' and
> 'false', which is why I started specifying numerical values, all to
> no effect.
This have any effect?
#ifdef __cplusplus
typedef bool boolean;
#else
typedef uint8_t boolean;
#define false 0
#define true !false
#endif
The text of the bug report said the Arduino libraries futzed around with
the boolean definitions to support C code in the core or somethin'
[toc] | [prev] | [next] | [standalone]
| From | dagmargoodboat@yahoo.com |
|---|---|
| Date | 2017-02-06 21:05 -0800 |
| Message-ID | <7e3d1dc1-865b-49ae-a815-daff058744ff@googlegroups.com> |
| In reply to | #446596 |
On Monday, February 6, 2017 at 11:26:26 PM UTC-5, bitrex wrote: > On 02/06/2017 10:02 PM, dagmargoodboat@yahoo.com wrote: > > On Monday, February 6, 2017 at 9:43:23 PM UTC-5, bitrex wrote: > >> "boolean" is not an ISO standard C++ data type - use "bool." > > > > "bool" is what I started off with, gives the same result as "boolean." > > I switched to "boolean," since that was listed in Arduino's reference > > page, and, having made it part of their environment, one would hope > > they've made full provision for it. > > > > https://www.arduino.cc/en/Reference/HomePage > > > > When that didn't work, I also quit trusting the values of 'true' and > > 'false', which is why I started specifying numerical values, all to > > no effect. > > This have any effect? > > #ifdef __cplusplus > typedef bool boolean; > #else > typedef uint8_t boolean; > #define false 0 > #define true !false > #endif It had the effect of scaring me! Who knows what havoc it might wreak changing assumptions throughout all their libraries & packages! :-) I'm pretty sure I don't want to re-define uint8_t to boolean--that would set my program back to the error condition. Plus we already know that 'bool' is broken in my context--I used up one of my AVR's 10,000 lifetimes to confirm that for you. I appreciate the tips, but I'm satisfied I've solved the instant problem. I've got hardware to get working, that's my main task. > The text of the bug report said the Arduino libraries futzed around with > the boolean definitions to support C code in the core or somethin' Yes, there's a lot of that going on. It's charming on the one hand, and terrifying on the other. ;-) Thanks again, James Arthur
[toc] | [prev] | [next] | [standalone]
| From | Clifford Heath <no.spam@please.net> |
|---|---|
| Date | 2017-02-07 13:55 +1100 |
| Message-ID | <5899371c$0$10817$b1db1813$15bdbe48@news.astraweb.com> |
| In reply to | #446574 |
On 07/02/17 13:30, dagmargoodboat@yahoo.com wrote:
> On Monday, February 6, 2017 at 6:58:13 PM UTC-5, Clifford Heath wrote:
>> On 07/02/17 10:43, dagmargoodboat@yahoo.com wrote:
>>> I've heard the kids here opine compilers are so good
>>> these days that assembly makes no sense.
>>> Meanwhile, I just spent three days tracking down a compiler error--
>>> the compiler insisted (0xff & 1) = 254.
>> I don't believe you. Show us your code and your compiler version.
>> I bet you did (0xFF & ~1).
>> Clifford Heath.
>
> It's pretty messy to document,
Thanks for trying anyway... though you don't show the generated
assembly code, but didn't provide clean enough code for me to do
it either.
Hint: use "gcc -S -fverbose-asm" to get the assembly code into
<file>.s with the original C code in comments.
But see below...
>but the gist is that I wanted to toggle
> a boolean flag with the statement
>
> flg = flg ? false : true;
>
> where 'true' == 1, 'false' == 0, Arduino-defined.
>
> It didn't work--the variable was assigned either 0xfe, or 0xff.
>
> Boolean on the AVR is an unsigned byte, flg was initialized to 0xff,
> from blank EEPROM (as expected, prior to storing user parameters).
I suspect that the EEPROM is operating in "write more zeroes" mode.
Do you get the same problem where the target is not EEPROM?
Clifford Heath.
> When simple statements didn't work as expected, I added a bunch of print
> statements to diagnose the problem (below, with output).
>
> You can see that, with 'boolean' type, output lines 6a., 6b., 7a., 7b.
> do not give the expected results.
>
> If I change
> 11. w = (U.dat.flg) ? true : false; to
> 11. w = (U.dat.flg) ? false : true;
>
> and w=0xff, line 13. reports that (w & 0x1) == 254.
>
> The upshot was that the compiler generates different code for a 'boolean'
> and a 'uint8_t', even though they're both supposed to be unsigned char.
>
> Either type should've been fine for my purposes. Both should've worked.
> I tried various gimmicks like casts, forcing conversions, and assigning
> to int or word types to try forcing the compiler to treat values
> differently, to no avail.
>
>
> Source:
> 1. int b,c,i;
> 2. word w;
> 3. float v;
> 4.
> 5. Serial.print(F(" 1. 'true' = ")); Serial.print(true,HEX); Serial.print(F(" 2. 'false' = ")); Serial.println(false,HEX);
> 6. Serial.print(F(" 3. 'i = true' =")); Serial.print((i = true),HEX); Serial.print(F(" 4. 'w = false' =")); Serial.println((w = false),HEX);
> 7. Serial.print(F(" 5. Before toggle, U.dat.flg = ")); Serial.println(U.dat.flg, HEX);
> 8.
> 9. i = (int) U.dat.flg;
> 10. Serial.print(F(" 6a. i = (int) U.dat.flg =")); Serial.println(i,HEX);
> 11. w = (U.dat.flg) ? true : false;
> 12.
> 13. Serial.print(F(" 6b. After assignment by '?' to 'true' : 'false', w = ")); Serial.println(w,HEX);
> 14.
> 15. if (U.dat.flg) {
> 16. w = true;
> 17. } else {
> 18. w = false;
> 19. }
> 20.
> 21. Serial.print(F(" 6c. After if-then assignment to 'true' or 'false', w = ")); Serial.println(w,HEX);
> 22.
> 23. Serial.print(F(" 7a. i & 1 = ")); Serial.println((i & 1), HEX);
> 24. Serial.print(F(" 7b. w & 1 = ")); Serial.println((w & (word)1), HEX);
> 25.
> 26. Serial.print(F(" 8a. (i & 0x1u) = ")); Serial.println((i & 0x1u), HEX);
> 27. Serial.print(F(" 8b. (w & 0x1) = ")); Serial.println((w & 0x1), HEX);
> 28. Serial.print(F(" 8c. (0xff & 0x1) = ")); Serial.println((0xff & 0x1), HEX);
>
>
> === Output with U.dat.flg declared 'boolean'===
> 1. 'true' = 1 2. 'false' = 0
> 3. 'i = true' =1 4. 'w = false' =0
> 5. Before toggle, U.dat.flg = FF
> 6a. i = (int) U.dat.flg =FF
>
> ->---> 6b. After 'w = (U.dat.flg) ? true : false', w = FF <--- should be 0x1!!!
>
> 6c. After if-then assignment to 'true' or 'false', w = FF <--- should be 0x1 !!
> 7a. i & 1 = FF <--- should be 0x1 !!
> 7b. w & 1 = FF <--- should be 0x1 !!
>
> 8a. (i & 0x1u) = FF <--- should be 0x1 !!
> 8b. (w & 0x1) = FF <--- should be 0x1 !!
> 8c. (0xff & 0x1) = 1
>
>
> === Output with U.dat.flg declared 'uint8_t'===
> 1. 'true' = 1 2. 'false' = 0
> 3. 'i = true' =1 4. 'w = false' =0
> 5. Before toggle, U.dat.flg = FF
> 6a. i = (int) U.dat.flg =FF
>
> ---> 6b. After 'w = (U.dat.flg) ? true : false', w = 1 <--- 1 = correct.
>
> 6c. After if-then assignment to 'true' or 'false', w = 1
> 7a. i & 1 = 1
> 7b. w & 1 = 1
>
> 8a. (i & 0x1u) = 1
> 8b. (w & 0x1) = 1
> 8c. (0xff & 0x1) = 1
>
>
> Cheers,
> James Arthur
>
[toc] | [prev] | [next] | [standalone]
| From | dagmargoodboat@yahoo.com |
|---|---|
| Date | 2017-02-06 20:00 -0800 |
| Message-ID | <d0e5d45c-d759-41e1-a190-7580b47c5d9e@googlegroups.com> |
| In reply to | #446587 |
On Monday, February 6, 2017 at 9:55:52 PM UTC-5, Clifford Heath wrote:
> On 07/02/17 13:30, dagmargoodboat@yahoo.com wrote:
> > On Monday, February 6, 2017 at 6:58:13 PM UTC-5, Clifford Heath wrote:
> >> On 07/02/17 10:43, dagmargoodboat@yahoo.com wrote:
> >>> I've heard the kids here opine compilers are so good
> >>> these days that assembly makes no sense.
> >>> Meanwhile, I just spent three days tracking down a compiler error--
> >>> the compiler insisted (0xff & 1) = 254.
> >> I don't believe you. Show us your code and your compiler version.
> >> I bet you did (0xFF & ~1).
> >> Clifford Heath.
> >
> > It's pretty messy to document,
>
> Thanks for trying anyway... though you don't show the generated
> assembly code, but didn't provide clean enough code for me to do
> it either.
The "clean" code was a simple assignment. All the rest of the mess is a
pile of debugging print statements, using the awkward functions provided
for that purpose.
The generated code is even messier, disassembled from the .elf file.
Booleans, and bools work fine elsewhere in the program, substituting for
one another, doing math, logic, comparisons, and accessing this same
problematic variable. AFAICT it's only this one area in my code--and only
a few statements--where 'bool' and 'boolean' misbehave.
> Hint: use "gcc -S -fverbose-asm" to get the assembly code into
> <file>.s with the original C code in comments.
Can't. Tried. The Arduino IDE won't let you. It compiles and links,
including includes and header files madly, doing God knows what, then
deletes the evidence. It took a miner's hat and a gas lamp to disassemble
what I did.
I tried running gcc from the command line, but I couldn't ever make it
happy.
> But see below...
>
> >but the gist is that I wanted to toggle
> > a boolean flag with the statement
> >
> > flg = flg ? false : true;
> >
> > where 'true' == 1, 'false' == 0, Arduino-defined.
> >
> > It didn't work--the variable was assigned either 0xfe, or 0xff.
> >
> > Boolean on the AVR is an unsigned byte, flg was initialized to 0xff,
> > from blank EEPROM (as expected, prior to storing user parameters).
>
> I suspect that the EEPROM is operating in "write more zeroes" mode.
> Do you get the same problem where the target is not EEPROM?
>
> Clifford Heath.
That's not the case. I loaded 'U.dat.flg' from EEPROM, which initializes
U.dat.flg to 0xff. All operations thereafter are in RAM.
Perhaps the 'boolean' type never anticipated a variable being assigned
an illegal value (neither 1 nor 0) in the first place. Dunno.
A snip of the disassembled code follows.
The two cases use different print() calls, indicating the compiler regards
the expression results as different types, even though they ought to all
be unsigned bytes of whatever type you'd like to call 'em.
Note that the assignment
w = (U.dat.flg) ? true : false;
generates different code in the two cases, and that different Serial.print()
routines are called. It might be that one of those print calls used in
the 'boolean' case trashes R1 where its counterpart in the 'uint8_t'
case doesn't. I don't know.
Like I said before, abstractions piled on abstractions--the compiler's not
protecting me, it's in the way. But it'll all be sweet once it's done,
and easy for the customer to maintain.
Cheers,
James Arthur
============= 'boolean' (does not work) ==================
Serial.print(F(" 5. Before toggle, U.dat.flg = "));
203e: 86 e4 ldi r24, 0x46 ; 70
2040: 9c e0 ldi r25, 0x0C ; 12
2042: 0e 94 6c 0b call Serial.print(F("<string>"))
Serial.println(U.dat.flg, HEX);
2046: 80 91 94 01 lds r24, U.dat.flg ; 0x800194 <UserSetupTable+0x54>
204a: 60 e1 ldi r22, 0x10 ; 16
204c: 70 e0 ldi r23, 0x00 ; 0
204e: 90 e0 ldi r25, 0x00 ; 0
2050: 0e 94 5c 0c call 0x18b8 ; 0x18b8 <_ZN5Print7printlnEii.constprop.16>
i = (int) U.dat.flg;
2054: c0 90 94 01 lds r12, U.dat.flg ; 0x800194 <UserSetupTable+0x54>
2058: d1 2c mov r13, r1
Serial.print(F(" 6a. i = (int) U.dat.flg ="));
205a: 8d e0 ldi r24, 0x0D ; 13
205c: 9c e0 ldi r25, 0x0C ; 12
205e: 0e 94 6c 0b call Serial.print(F("<string>"))
Serial.println(i,HEX);
2062: 60 e1 ldi r22, 0x10 ; 16
2064: 70 e0 ldi r23, 0x00 ; 0
2066: c6 01 movw r24, r12
2068: 0e 94 5c 0c call 0x18b8 ; 0x18b8 <_ZN5Print7printlnEii.constprop.16>
w = (U.dat.flg) ? true : false;
206c: e0 90 94 01 lds r14, U.dat.flg ; 0x800194 <UserSetupTable+0x54>
2070: f1 2c mov r15, r1
Serial.print(F(" 6b. After 'w = (U.dat.flg) ? true : false', w = "));
2072: 8d eb ldi r24, 0xBD ; 189
2074: 9b e0 ldi r25, 0x0B ; 11
2076: 0e 94 6c 0b call Serial.print(F("string"))
Serial.println(w,HEX);
207a: c7 01 movw r24, r14
207c: 0e 94 47 0e call Serial.println(word R25:R24,HEX)
============= uint8_t (works) ==================
Same as above, except U.dat.flg is defined as 'uint8_t', and longer text
in the print statements has moved the addresses down slightly. Setting
this version to back 'boolean' recreates the error, though--the error is
executable-position independent.
Serial.print(F(" 5. Before toggle, U.dat.flg = "));
206e: 86 e4 ldi r24, 0x46 ; 70
2070: 9c e0 ldi r25, 0x0C ; 12
2072: 0e 94 6b 0b call Serial.print(F("<string>"))
Serial.println(U.dat.flg, HEX);
2076: 60 e1 ldi r22, 0x10 ; 16
2078: 70 e0 ldi r23, 0x00 ; 0
207a: 80 91 94 01 lds r24, 0x0194 ; 0x800194 <UserSetupTable+0x54>
207e: 0e 94 19 0c call 0x1832 ; 0x1832 <_ZN5Print7printlnEhi.constprop.19>
i = (int) U.dat.flg;
2082: 10 91 94 01 lds r17, 0x0194 ; 0x800194 <UserSetupTable+0x54>
2086: c1 2e mov r12, r17
2088: d1 2c mov r13, r1
Serial.print(F(" 6a. i = (int) U.dat.flg ="));
208a: 8d e0 ldi r24, 0x0D ; 13
208c: 9c e0 ldi r25, 0x0C ; 12
208e: 0e 94 6b 0b call Serial.print(F("<string>"))
Serial.println(i,HEX);
2092: 60 e1 ldi r22, 0x10 ; 16
2094: 70 e0 ldi r23, 0x00 ; 0
2096: c6 01 movw r24, r12
2098: 0e 94 4d 0e call 0x1c9a ; 0x1c9a <_ZN5Print7printlnEii.constprop.4>
w = (U.dat.flg) ? true : false;
209c: ee 24 eor r14, r14
209e: e3 94 inc r14
20a0: f1 2c mov r15, r1
20a2: 80 91 94 01 lds r24, 0x0194 ; 0x800194 <UserSetupTable+0x54>
20a6: 81 11 cpse r24, r1
20a8: 02 c0 rjmp .+4 ; 0x20ae <main+0x370>
Serial.print(F(" 6b. After 'w = (U.dat.flg) ? true : false', w = "));
20aa: e1 2c mov r14, r1
20ac: f1 2c mov r15, r1
20ae: 8d eb ldi r24, 0xBD ; 189
20b0: 9b e0 ldi r25, 0x0B ; 11
20b2: 0e 94 6b 0b call Serial.print(F("<string>"))
Serial.println(w,HEX);
20b6: c7 01 movw r24, r14
20b8: 0e 94 60 0e call 0x1cc0 ; 0x1cc0 <_ZN5Print7printlnEji.constprop.3>
[toc] | [prev] | [next] | [standalone]
| From | Clifford Heath <no.spam@please.net> |
|---|---|
| Date | 2017-02-07 19:31 +1100 |
| Message-ID | <589985ef$0$10820$b1db1813$15bdbe48@news.astraweb.com> |
| In reply to | #446592 |
On 07/02/17 15:00, dagmargoodboat@yahoo.com wrote: > On Monday, February 6, 2017 at 9:55:52 PM UTC-5, Clifford Heath wrote: >> On 07/02/17 13:30, dagmargoodboat@yahoo.com wrote: >>> On Monday, February 6, 2017 at 6:58:13 PM UTC-5, Clifford Heath wrote: >>>> On 07/02/17 10:43, dagmargoodboat@yahoo.com wrote: >>>>> I've heard the kids here opine compilers are so good >>>>> these days that assembly makes no sense. >>>>> Meanwhile, I just spent three days tracking down a compiler error-- >>>>> the compiler insisted (0xff & 1) = 254. >>>> I don't believe you. Show us your code and your compiler version. >>>> I bet you did (0xFF & ~1). >>>> Clifford Heath. >>> >>> It's pretty messy to document, >> >> Thanks for trying anyway... though you don't show the generated >> assembly code, but didn't provide clean enough code for me to do >> it either. > > The "clean" code was a simple assignment. All the rest of the mess is a > pile of debugging print statements, using the awkward functions provided > for that purpose. > > The generated code is even messier, disassembled from the .elf file. > > Booleans, and bools work fine elsewhere in the program, substituting for > one another, doing math, logic, comparisons, and accessing this same > problematic variable. AFAICT it's only this one area in my code--and only > a few statements--where 'bool' and 'boolean' misbehave. > >> Hint: use "gcc -S -fverbose-asm" to get the assembly code into >> <file>.s with the original C code in comments. > > Can't. Tried. The Arduino IDE won't let you. It compiles and links, > including includes and header files madly, doing God knows what, then > deletes the evidence. It took a miner's hat and a gas lamp to disassemble > what I did. > > I tried running gcc from the command line, but I couldn't ever make it > happy. I did it once, forget how, but this seems to cover the technique: https://github.com/sudar/Arduino-Makefile You can also add compiler options in a config file; look for a file in your Arduino install whose pathname ends in .../hardware/arduino/avr/platform.txt >> I suspect that the EEPROM is operating in "write more zeroes" mode. >> Do you get the same problem where the target is not EEPROM? > That's not the case. I loaded 'U.dat.flg' from EEPROM, which initializes > U.dat.flg to 0xff. All operations thereafter are in RAM. > > Perhaps the 'boolean' type never anticipated a variable being assigned > an illegal value (neither 1 nor 0) in the first place. Dunno. Ok, well, I'm surprised. That would not easily happen through normal gcc development processes, but I suppose that the Arduino team are pretty slipshod in many other ways, so... Clifford Heath.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-07 10:29 +0100 |
| Message-ID | <o7c3tl$72a$1@dont-email.me> |
| In reply to | #446592 |
On 07/02/17 05:00, dagmargoodboat@yahoo.com wrote: > That's not the case. I loaded 'U.dat.flg' from EEPROM, which initializes > U.dat.flg to 0xff. All operations thereafter are in RAM. > > Perhaps the 'boolean' type never anticipated a variable being assigned > an illegal value (neither 1 nor 0) in the first place. Dunno. > How is the type of U (and in particular, U.dat.flg) defined? I assume it is "boolean", since this explains the effects you are seeing. The Arduino makes "boolean" a typedef of "bool", which is a standard C++ type. "true" and "false" are built into C++, and are not Arduino-defined. (Personally, I really dislike the way Arduino tried to "hide" or "simplify" C++.) If the compiler knows that something is a boolean type, then it can assume that it can only ever be 1 (true) or 0 (false). Anything else is undefined behaviour. So if you have declared U.dat.flg to be "boolean" and put 0xff in it, you have lied to the compiler. When the compiler sees "w = (U.dat.flg) ? true : false;", it /knows/ that U.dat.flg is already either 1 or 0 - because you have told it so, in your declaration of the type of U.dat.flg. If it is 1 (true), then w should be set to true - if it is 0 (false), then w should be set to false. Thus the statement can be simplified to "w = U.dat.flg". Similar reasoning gives you the rest of your results. The answer is to declare U.dat.flg as "uint8_t", since it can hold any value in that range.
[toc] | [prev] | [next] | [standalone]
| From | dagmargoodboat@yahoo.com |
|---|---|
| Date | 2017-02-07 07:39 -0800 |
| Message-ID | <e649362c-6a9c-4397-b7ac-2ae1a79e45aa@googlegroups.com> |
| In reply to | #446623 |
On Tuesday, February 7, 2017 at 4:29:06 AM UTC-5, David Brown wrote: > On 07/02/17 05:00, dagmargoodboat@yahoo.com wrote: > > > That's not the case. I loaded 'U.dat.flg' from EEPROM, which initializes > > U.dat.flg to 0xff. All operations thereafter are in RAM. > > > > Perhaps the 'boolean' type never anticipated a variable being assigned > > an illegal value (neither 1 nor 0) in the first place. Dunno. > > > > How is the type of U (and in particular, U.dat.flg) defined? I assume > it is "boolean", since this explains the effects you are seeing. 'boolean', 'bool', or 'uint8_t', as explained in detail above. > The Arduino makes "boolean" a typedef of "bool", which is a standard C++ > type. "true" and "false" are built into C++, and are not > Arduino-defined. (Personally, I really dislike the way Arduino tried to > "hide" or "simplify" C++.) > > If the compiler knows that something is a boolean type, then it can > assume that it can only ever be 1 (true) or 0 (false). Anything else is > undefined behaviour. So if you have declared U.dat.flg to be "boolean" > and put 0xff in it, you have lied to the compiler. It's not my job to guarantee that Atmel/Microchip pre-initialize the EEPROM to please gcc. But I'd tried to compensate by immediately directly writing '0' or '1' to the variable, and other operations that should've brought it to a legal condition. The compiler doesn't follow those instructions, instead either optimizing the operations out entirely, or only toggling the lsb. > When the compiler sees "w = (U.dat.flg) ? true : false;", it /knows/ > that U.dat.flg is already either 1 or 0 - because you have told it so, > in your declaration of the type of U.dat.flg. If it is 1 (true), then w > should be set to true - if it is 0 (false), then w should be set to > false. Thus the statement can be simplified to "w = U.dat.flg". Which is what the compiler did, and, in its wisdom, wouldn't allow me to write 'true' or 'false' to properly initialize a boolean. > Similar reasoning gives you the rest of your results. > > > The answer is to declare U.dat.flg as "uint8_t", since it can hold any > value in that range. Already done & described in posts above. Cheers, James Arthur
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-08 12:24 +0100 |
| Message-ID | <o7ev1u$cod$1@dont-email.me> |
| In reply to | #446642 |
On 07/02/17 16:39, dagmargoodboat@yahoo.com wrote: > On Tuesday, February 7, 2017 at 4:29:06 AM UTC-5, David Brown wrote: >> On 07/02/17 05:00, dagmargoodboat@yahoo.com wrote: >> >>> That's not the case. I loaded 'U.dat.flg' from EEPROM, which initializes >>> U.dat.flg to 0xff. All operations thereafter are in RAM. >>> >>> Perhaps the 'boolean' type never anticipated a variable being assigned >>> an illegal value (neither 1 nor 0) in the first place. Dunno. >>> >> >> How is the type of U (and in particular, U.dat.flg) defined? I assume >> it is "boolean", since this explains the effects you are seeing. > > 'boolean', 'bool', or 'uint8_t', as explained in detail above. I'm trying to help here - giving the relevant information will help me help /you/. And giving it succinctly rather than buried within pages of generated assembly would be far more useful. > >> The Arduino makes "boolean" a typedef of "bool", which is a standard C++ >> type. "true" and "false" are built into C++, and are not >> Arduino-defined. (Personally, I really dislike the way Arduino tried to >> "hide" or "simplify" C++.) >> >> If the compiler knows that something is a boolean type, then it can >> assume that it can only ever be 1 (true) or 0 (false). Anything else is >> undefined behaviour. So if you have declared U.dat.flg to be "boolean" >> and put 0xff in it, you have lied to the compiler. > > It's not my job to guarantee that Atmel/Microchip pre-initialize the EEPROM > to please gcc. It is /your/ job to know the meaning of a type in a programming language before you use it. The Arduino folk might not make that as easy as it should be, by encouraging non-standard types like "boolean" without proper documentation (and even worse, where the semantics apparently vary according to versions). Still, it is /your/ job. Feel free to ask here, or in comp.lang.c or comp.arch.embedded to get help on the matter. Just remember to give the information people ask you for, and to accept that it might be /your/ misunderstanding rather than blaming the compiler. > > But I'd tried to compensate by immediately directly writing '0' or '1' to > the variable, and other operations that should've brought it to a legal > condition. The compiler doesn't follow those instructions, instead > either optimizing the operations out entirely, or only toggling the > lsb. That is correct behaviour on the part of the compiler. The compiler's job is to generate efficient code on the assumption that the code it is given is correct C (or C++ in this case). If you sneak a value of other than 0 or 1 into something declared as "bool", you are breaking your side of the bargain. The compiler is not omnipotent and cannot read your mind or guess what you /really/ meant. And again, I fully understand how you can make this mistake, how the Arduino stuff makes it difficult, and how some aspects of the C language can be hard to understand. That's why I encourage you to /ask/ about it, giving the relevant information, rather than throwing blame around. > >> When the compiler sees "w = (U.dat.flg) ? true : false;", it /knows/ >> that U.dat.flg is already either 1 or 0 - because you have told it so, >> in your declaration of the type of U.dat.flg. If it is 1 (true), then w >> should be set to true - if it is 0 (false), then w should be set to >> false. Thus the statement can be simplified to "w = U.dat.flg". > > Which is what the compiler did, and, in its wisdom, wouldn't allow me > to write 'true' or 'false' to properly initialize a boolean. If U.dat.flg is declared as "bool", then the compiler knows that U.dat.flg is already a properly initialised bool. You would not want the compiler to generate a series of unnecessary instructions doing tests and jumps simply to assign from one bool to another. You lied to your compiler, albeit unknowingly and unintentionally. It bit you. That's what happens when you lie to your compiler. > >> Similar reasoning gives you the rest of your results. >> >> >> The answer is to declare U.dat.flg as "uint8_t", since it can hold any >> value in that range. > > Already done & described in posts above. > Yes, but hopefully you now understand that the compiler did not make any mistakes - the error was in your code. And you know that you have not just "found a workaround" - you understand the problem, and understand the correction to your code error.
[toc] | [prev] | [next] | [standalone]
| From | dagmargoodboat@yahoo.com |
|---|---|
| Date | 2017-02-09 08:36 -0800 |
| Message-ID | <3e6134b9-7c67-461e-919e-2b6c459d4ab4@googlegroups.com> |
| In reply to | #446765 |
On Wednesday, February 8, 2017 at 6:24:32 AM UTC-5, David Brown wrote:
> On 07/02/17 16:39, dagmargoodboat@yahoo.com wrote:
> > On Tuesday, February 7, 2017 at 4:29:06 AM UTC-5, David Brown wrote:
> >> On 07/02/17 05:00, dagmargoodboat@yahoo.com wrote:
> >>
> >>> That's not the case. I loaded 'U.dat.flg' from EEPROM, which initializes
> >>> U.dat.flg to 0xff. All operations thereafter are in RAM.
> >>>
> >>> Perhaps the 'boolean' type never anticipated a variable being assigned
> >>> an illegal value (neither 1 nor 0) in the first place. Dunno.
> >>>
> >>
> >> How is the type of U (and in particular, U.dat.flg) defined? I assume
> >> it is "boolean", since this explains the effects you are seeing.
> >
> > 'boolean', 'bool', or 'uint8_t', as explained in detail above.
>
> I'm trying to help here - giving the relevant information will help me
> help /you/. And giving it succinctly rather than buried within pages of
> generated assembly would be far more useful.
>
> >
> >> The Arduino makes "boolean" a typedef of "bool", which is a standard C++
> >> type. "true" and "false" are built into C++, and are not
> >> Arduino-defined. (Personally, I really dislike the way Arduino tried to
> >> "hide" or "simplify" C++.)
> >>
> >> If the compiler knows that something is a boolean type, then it can
> >> assume that it can only ever be 1 (true) or 0 (false). Anything else is
> >> undefined behaviour. So if you have declared U.dat.flg to be "boolean"
> >> and put 0xff in it, you have lied to the compiler.
> >
> > It's not my job to guarantee that Atmel/Microchip pre-initialize the EEPROM
> > to please gcc.
>
> It is /your/ job to know the meaning of a type in a programming language
> before you use it.
>
> The Arduino folk might not make that as easy as it should be, by
> encouraging non-standard types like "boolean" without proper
> documentation (and even worse, where the semantics apparently vary
> according to versions). Still, it is /your/ job.
>
> Feel free to ask here, or in comp.lang.c or comp.arch.embedded to get
> help on the matter. Just remember to give the information people ask
> you for, and to accept that it might be /your/ misunderstanding rather
> than blaming the compiler.
>
> >
> > But I'd tried to compensate by immediately directly writing '0' or '1' to
> > the variable, and other operations that should've brought it to a legal
> > condition. The compiler doesn't follow those instructions, instead
> > either optimizing the operations out entirely, or only toggling the
> > lsb.
>
> That is correct behaviour on the part of the compiler. The compiler's
> job is to generate efficient code on the assumption that the code it is
> given is correct C (or C++ in this case). If you sneak a value of other
> than 0 or 1 into something declared as "bool", you are breaking your
> side of the bargain. The compiler is not omnipotent and cannot read
> your mind or guess what you /really/ meant.
>
> And again, I fully understand how you can make this mistake, how the
> Arduino stuff makes it difficult, and how some aspects of the C language
> can be hard to understand. That's why I encourage you to /ask/ about
> it, giving the relevant information, rather than throwing blame around.
>
> >
> >> When the compiler sees "w = (U.dat.flg) ? true : false;", it /knows/
> >> that U.dat.flg is already either 1 or 0 - because you have told it so,
> >> in your declaration of the type of U.dat.flg. If it is 1 (true), then w
> >> should be set to true - if it is 0 (false), then w should be set to
> >> false. Thus the statement can be simplified to "w = U.dat.flg".
> >
> > Which is what the compiler did, and, in its wisdom, wouldn't allow me
> > to write 'true' or 'false' to properly initialize a boolean.
>
> If U.dat.flg is declared as "bool", then the compiler knows that
> U.dat.flg is already a properly initialised bool. You would not want
> the compiler to generate a series of unnecessary instructions doing
> tests and jumps simply to assign from one bool to another.
>
> You lied to your compiler, albeit unknowingly and unintentionally.
> It bit you. That's what happens when you lie to your compiler.
I used a 'bool' (then a 'boolean') to represent a boolean quantity. Isn't
that the point of having a boolean type?
If the compiler's code absolutely depends on a variable having certain
values and no others, the compiler should take steps to ensure that the
variable contains a legal value. Instead, it prevented me initializing
the variable to a known condition.
That's a common circumstance--variables aren't initialized to known
conditions when power's applied.
What's the value in having a 'boolean' if you have to ultimately use
bizarre, unsigned, faked, phony types to ultimately represent it with
a byte anyhow?
> >> Similar reasoning gives you the rest of your results.
> >>
> >>
> >> The answer is to declare U.dat.flg as "uint8_t", since it can hold any
> >> value in that range.
> >
> > Already done & described in posts above.
> >
>
> Yes, but hopefully you now understand that the compiler did not make any
> mistakes - the error was in your code. And you know that you have not
> just "found a workaround" - you understand the problem, and understand
> the correction to your code error.
No, the compiler *is* at fault. It optimized out the operation
w = (U.dat.flg ? true : false;)
substituting: U.dat.flg ==> w.
1 2 3
w = (U.dat.flg) ? (true) : (false);
To do that is to assume expression #1 (U.dat.flg != 0) is equivalent to, has
the same range of values as, and is interchangeable with expressions of type
'boolean' #2 & #3.
That's wrong.
Cheers,
James Arthur
[toc] | [prev] | [next] | [standalone]
| From | Clifford Heath <no.spam@please.net> |
|---|---|
| Date | 2017-02-10 08:15 +1100 |
| Message-ID | <589cdbe3$0$1358$c3e8da3$1cbc7475@news.astraweb.com> |
| In reply to | #447025 |
On 10/02/17 03:36, dagmargoodboat@yahoo.com wrote: > If the compiler's code absolutely depends on a variable having certain > values and no others, the compiler should take steps to ensure that the > variable contains a legal value. I agree. This generated code should/could be more defensive. But it's not incorrect, as David has been patiently explaining. > That's a common circumstance--variables aren't initialized to known > conditions when power's applied. That's true, but not in C. The startup code (before main) is expected to initialize all global and static variables to zero, and the compiler is entitled to expect that. (Startup code is not part of the compiler). If you use a union over multiple types, you are entirely responsible for your program's type safety. Clifford Heath
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-13 15:37 +0100 |
| Message-ID | <o7sg71$pda$2@dont-email.me> |
| In reply to | #447073 |
On 09/02/17 22:15, Clifford Heath wrote: > On 10/02/17 03:36, dagmargoodboat@yahoo.com wrote: >> If the compiler's code absolutely depends on a variable having certain >> values and no others, the compiler should take steps to ensure that the >> variable contains a legal value. > > I agree. This generated code should/could be more defensive. No - "more defensive" means "less efficient". I would not want a compiler to generate slow and inefficient code on the basis that some programmer somewhere might have made a mistake. > But it's not incorrect, as David has been patiently explaining. > >> That's a common circumstance--variables aren't initialized to known >> conditions when power's applied. > > That's true, but not in C. The startup code (before main) is expected > to initialize all global and static variables to zero, and the > compiler is entitled to expect that. (Startup code is not part > of the compiler). > > If you use a union over multiple types, you are entirely responsible > for your program's type safety. > > Clifford Heath
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-13 15:35 +0100 |
| Message-ID | <o7sg49$pda$1@dont-email.me> |
| In reply to | #447025 |
On 09/02/17 17:36, dagmargoodboat@yahoo.com wrote: > On Wednesday, February 8, 2017 at 6:24:32 AM UTC-5, David Brown wrote: >> On 07/02/17 16:39, dagmargoodboat@yahoo.com wrote: >>> On Tuesday, February 7, 2017 at 4:29:06 AM UTC-5, David Brown wrote: <snip> >> If U.dat.flg is declared as "bool", then the compiler knows that >> U.dat.flg is already a properly initialised bool. You would not want >> the compiler to generate a series of unnecessary instructions doing >> tests and jumps simply to assign from one bool to another. >> >> You lied to your compiler, albeit unknowingly and unintentionally. >> It bit you. That's what happens when you lie to your compiler. > > I used a 'bool' (then a 'boolean') to represent a boolean quantity. Isn't > that the point of having a boolean type? That is the point of "bool", yes. But you took something that you did not know to be a valid bool, and told the compiler that it /was/ a valid bool - that's a lie. An alternative way to think about this is that the data in the eeprom is external data from an unknown source. You don't know it is valid until you have checked it. If you are writing a web application, and it asks the user for a name, you don't assume that they have entered a valid name. You /check/ the entered data - you don't pass it on to a database query unless you want to create an SQL injection attack. The data in the eeprom is the same - it is unchecked unknown external data, and you have to confirm that it fits your requirements before using it. You can't simply /declare/ to the compiler that it fits your requirements - you have to check it. > > If the compiler's code absolutely depends on a variable having certain > values and no others, the compiler should take steps to ensure that the > variable contains a legal value. The compiler /will/ take steps to make sure that a bool variable holds a legal value - it does so every time it stores something that is not necessary legal. So if you have a uint8_t item that you are storing into a bool, the compiler will convert any non-zero value into 1 before storing it. But in your code, you have told the compiler that you already have a checked, valid bool value - so a simple copy is all the compiler needs to do to be absolutely sure the bool is valid. > Instead, it prevented me initializing > the variable to a known condition. It removed code that was clearly unnecessary based on the information you gave the compiler. > > That's a common circumstance--variables aren't initialized to known > conditions when power's applied. Variables (with program lifetime) are /always/ initialized to a known condition at the start of main(), as far as C is concerned. They are either initialised to an explicit value, or implicitly to 0. If the startup code (as run between reset and main()) does not do this, then that code is lying to the compiler. (I have seen tools that do this - it's a serious PITA.) Local stack data and heap data are not initialized, and the compiler knows this too. > > What's the value in having a 'boolean' if you have to ultimately use > bizarre, unsigned, faked, phony types to ultimately represent it with > a byte anyhow? You don't have to do anything of the sort. You simply have to treat external unknown data as having any value that can physically fit in the space. So if you are mapping data from an eeprom, then use uint8_t for the bytes. Then you can assign that to a bool type if you want. Alternatively, you can have a mechanism that checks and corrects the eeprom data once, then you know it is correct. For example, at program startup you could read the eeprom data as a uint8_t, and if it is not a valid bool, then write a 0 or 1 to it. For my eeprom data, I will often have a checksum to be sure that the data is valid - when starting up, I verify the checksum. If it is correct, then my eeprom data is safe to use (bools, enums, and all). If it is incorrect, then I fill the eeprom structure with a valid default set of values. > >>>> Similar reasoning gives you the rest of your results. >>>> >>>> >>>> The answer is to declare U.dat.flg as "uint8_t", since it can hold any >>>> value in that range. >>> >>> Already done & described in posts above. >>> >> >> Yes, but hopefully you now understand that the compiler did not make any >> mistakes - the error was in your code. And you know that you have not >> just "found a workaround" - you understand the problem, and understand >> the correction to your code error. > > No, the compiler *is* at fault. It optimized out the operation > > w = (U.dat.flg ? true : false;) > > substituting: U.dat.flg ==> w. > > 1 2 3 > w = (U.dat.flg) ? (true) : (false); > > To do that is to assume expression #1 (U.dat.flg != 0) is equivalent to, has > the same range of values as, and is interchangeable with expressions of type > 'boolean' #2 & #3. > > That's wrong. > You have told the compiler that U.dat.flg contains either 0 or 1 - you did this when you declared its type to be "bool". You are asking the compiler to take this value, and if it is 1 then it should store 1 in w, and if it is 0 then it should stor 0 in w. Implicitly, you are also saying that if U.dat.flg is /not/ 0 or 1, then the compiler can do what it wants - including launching nasal daemons. That's how programming works - it is a contract between the programmer and the compiler. When you break your side of the bargain, don't expect the compiler to perform miracles.
[toc] | [prev] | [next] | [standalone]
| From | dagmargoodboat@yahoo.com |
|---|---|
| Date | 2017-02-07 08:05 -0800 |
| Message-ID | <71788526-e087-4b2a-86db-29f4e51ab242@googlegroups.com> |
| In reply to | #446592 |
On Monday, February 6, 2017 at 11:00:56 PM UTC-5, dagmarg...@yahoo.com wrote: > On Monday, February 6, 2017 at 9:55:52 PM UTC-5, Clifford Heath wrote: > > I suspect that the EEPROM is operating in "write more zeroes" mode. > > Do you get the same problem where the target is not EEPROM? > > That's not the case. I loaded 'U.dat.flg' from EEPROM, which initializes > U.dat.flg to 0xff. All operations thereafter are in RAM. > > Perhaps the 'boolean' type never anticipated a variable being assigned > an illegal value (neither 1 nor 0) in the first place. Dunno. > > A snip of the disassembled code follows. > > The two cases use different print() calls, indicating the compiler regards > the expression results as different types, even though they ought to all > be unsigned bytes of whatever type you'd like to call 'em. > > Note that the assignment > w = (U.dat.flg) ? true : false; > > generates different code in the two cases, and that different Serial.print() > routines are called. It might be that one of those print calls used in > the 'boolean' case trashes R1 where its counterpart in the 'uint8_t' > case doesn't. I don't know. [...] Here's the problem--in the 'boolean' case, the compiler has optimized out my assignment of 'true' or 'false' entirely, and has reasoned that it can simply directly load the original, illegally 0xff-valued U.dat.flg into (word) w (=R15:R14): > ============= 'boolean' (does not work) ================== > w = (U.dat.flg) ? true : false; > 206c: e0 90 94 01 lds r14, U.dat.flg ; 0x800194 <UserSetupTable+0x54> > 2070: f1 2c mov r15, r1 The compiler thus defeats my instructions to substitute 'true' or 'false' for whatever odd value U.dat.flg happened to inherit from the EEPROM. If I reverse the positions of 'true' and 'false' in that statement creating a toggle--the original code--the compiler only toggles the lsb, leaving me with w = 0xff, or 0xfe, both still illegal values. By contrast with type 'uint8_t', the compiler generates an actual 0x1, then conditionally assigns that, or 0x0, as the result of the expression: > ============= uint8_t (works) ================== > w = (U.dat.flg) ? true : false; > 209c: ee 24 eor r14, r14 ;R14 = 0 > 209e: e3 94 inc r14 ;R14 = 1 > 20a0: f1 2c mov r15, r1 > 20a2: 80 91 94 01 lds r24, 0x0194 ; load U.dat.flg into R24 > 20a6: 81 11 cpse r24, r1 ; if !=0 > 20a8: 02 c0 rjmp .+4 ; then leave 0x1 in w (R15:R14) > 20aa: e1 2c mov r14, r1 ; else w (R15:R14) = 0. > 20ac: f1 2c mov r15, r1 Cheers, James Arthur
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-08 12:30 +0100 |
| Message-ID | <o7evd4$due$1@dont-email.me> |
| In reply to | #446648 |
On 07/02/17 17:05, dagmargoodboat@yahoo.com wrote: > On Monday, February 6, 2017 at 11:00:56 PM UTC-5, dagmarg...@yahoo.com wrote: >> On Monday, February 6, 2017 at 9:55:52 PM UTC-5, Clifford Heath wrote: > >>> I suspect that the EEPROM is operating in "write more zeroes" mode. >>> Do you get the same problem where the target is not EEPROM? >> >> That's not the case. I loaded 'U.dat.flg' from EEPROM, which initializes >> U.dat.flg to 0xff. All operations thereafter are in RAM. >> >> Perhaps the 'boolean' type never anticipated a variable being assigned >> an illegal value (neither 1 nor 0) in the first place. Dunno. >> >> A snip of the disassembled code follows. >> >> The two cases use different print() calls, indicating the compiler regards >> the expression results as different types, even though they ought to all >> be unsigned bytes of whatever type you'd like to call 'em. >> >> Note that the assignment >> w = (U.dat.flg) ? true : false; >> >> generates different code in the two cases, and that different Serial.print() >> routines are called. It might be that one of those print calls used in >> the 'boolean' case trashes R1 where its counterpart in the 'uint8_t' >> case doesn't. I don't know. > > [...] > > Here's the problem--in the 'boolean' case, the compiler has optimized out > my assignment of 'true' or 'false' entirely, and has reasoned that it can > simply directly load the original, illegally 0xff-valued U.dat.flg into > (word) w (=R15:R14): > >> ============= 'boolean' (does not work) ================== >> w = (U.dat.flg) ? true : false; >> 206c: e0 90 94 01 lds r14, U.dat.flg ; 0x800194 <UserSetupTable+0x54> >> 2070: f1 2c mov r15, r1 > > The compiler thus defeats my instructions to substitute 'true' or > 'false' for whatever odd value U.dat.flg happened to inherit from > the EEPROM. When you program in C (or almost any other programming language, except assembly), you do not give the compiler a list of instructions to be turned into object code. You give a sequence of instructions for an "abstract machine", and the compiler will generate code that has the same visible effect as though it followed the instructions. It is sometimes a subtle distinction, but it is an important one. It means that the compiler can use its knowledge of the program and its state in order to remove or simplify source code. It can re-arrange source code in many ways. It can remove or re-order anything that does not affect /visible/ results - volatile accesses, file I/O, program start and stop, and calling external functions whose effect is unknown (since such functions might have other visible effects). By declaring U.dat.flg to be bool, you have given the compiler information - and it uses that information to generate better code. If that information was not correct, you should not have given it to the compiler. > > If I reverse the positions of 'true' and 'false' in that statement > creating a toggle--the original code--the compiler only toggles the lsb, > leaving me with w = 0xff, or 0xfe, both still illegal values. > > > By contrast with type 'uint8_t', the compiler generates an actual 0x1, > then conditionally assigns that, or 0x0, as the result of the expression: > >> ============= uint8_t (works) ================== >> w = (U.dat.flg) ? true : false; >> 209c: ee 24 eor r14, r14 ;R14 = 0 >> 209e: e3 94 inc r14 ;R14 = 1 >> 20a0: f1 2c mov r15, r1 >> 20a2: 80 91 94 01 lds r24, 0x0194 ; load U.dat.flg into R24 >> 20a6: 81 11 cpse r24, r1 ; if !=0 >> 20a8: 02 c0 rjmp .+4 ; then leave 0x1 in w (R15:R14) >> 20aa: e1 2c mov r14, r1 ; else w (R15:R14) = 0. >> 20ac: f1 2c mov r15, r1 > > Cheers, > James Arthur >
[toc] | [prev] | [next] | [standalone]
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
Back to top | Article view | sci.electronics.design
csiph-web