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 | 11 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 7 of 7 — ← Prev page 1 2 3 4 5 6 [7]
| From | Tim Wescott <tim@seemywebsite.com> |
|---|---|
| Date | 2017-02-10 10:41 -0600 |
| Message-ID | <DL-dndWssNeBcADFnZ2dnUU7-S-dnZ2d@giganews.com> |
| In reply to | #446506 |
On Mon, 06 Feb 2017 15:43:44 -0800, dagmargoodboat 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>: > 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. This is like saying that wheelbarrows are better than trucks because one specific model and brand of Semi has undergone a recall. If you're using a _decent_ optimizing compiler, then you should be able to just state your intent reasonably clearly, then stand back and let the optimizer do its business. If you're using a _broken_ compiler with _crappy_ libraries, then you should first try to fix that situation. If you simply cannot then yes, you would need to do things the old fashioned way. -- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.com
[toc] | [prev] | [next] | [standalone]
| From | dagmargoodboat@yahoo.com |
|---|---|
| Date | 2017-02-11 07:06 -0800 |
| Message-ID | <a24dc676-737c-4cb7-bd9c-3c724da99860@googlegroups.com> |
| In reply to | #447170 |
On Friday, February 10, 2017 at 11:41:11 AM UTC-5, Tim Wescott wrote: > On Mon, 06 Feb 2017 15:43:44 -0800, dagmargoodboat 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>: [...] > > 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. > > This is like saying that wheelbarrows are better than trucks because one > specific model and brand of Semi has undergone a recall. > > If you're using a _decent_ optimizing compiler, then you should be able > to just state your intent reasonably clearly, then stand back and let the > optimizer do its business. > > If you're using a _broken_ compiler with _crappy_ libraries, then you > should first try to fix that situation. If you simply cannot then yes, > you would need to do things the old fashioned way. It's ultimately gcc, a well-regarded compiler. The difficulty I have with the whole thing is this paradigm of abstraction, blindly applied to isolate workers from their task. In this case I've shown the Arduino IDE and gcc both, in separate examples, impeded rather than aided. Cheers, James Arthur
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-02-11 17:09 +0000 |
| Message-ID | <CzHnA.293744$he2.266442@fx22.am4> |
| In reply to | #447288 |
On 11/02/17 15:06, dagmargoodboat@yahoo.com wrote:
> On Friday, February 10, 2017 at 11:41:11 AM UTC-5, Tim Wescott wrote:
>> On Mon, 06 Feb 2017 15:43:44 -0800, dagmargoodboat 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>:
> [...]
>>> 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.
>>
>> This is like saying that wheelbarrows are better than trucks because one
>> specific model and brand of Semi has undergone a recall.
>>
>> If you're using a _decent_ optimizing compiler, then you should be able
>> to just state your intent reasonably clearly, then stand back and let the
>> optimizer do its business.
>>
>> If you're using a _broken_ compiler with _crappy_ libraries, then you
>> should first try to fix that situation. If you simply cannot then yes,
>> you would need to do things the old fashioned way.
>
> It's ultimately gcc, a well-regarded compiler. The difficulty I have
> with the whole thing is this paradigm of abstraction, blindly applied
> to isolate workers from their task.
>
> In this case I've shown the Arduino IDE and gcc both, in separate
> examples, impeded rather than aided.
One of the main points about abstraction and libraries
is that they should allow you to
- ignore what it isn't necessary to think about in
detail
- concentrate where you can uniquely add value
It has /always/ been the case that
- there is a learning curve with abstractions and
libraries
- they can hide too much for your application
Those continue to be standard engineering tradeoffs,
and the choice depends on the individual application
and the individual.
My main objection is where the toolset adds to what
I need to understand, rather than minimises it.
C (and especially C++) is now in that category.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-13 16:28 +0100 |
| Message-ID | <o7sj82$4o2$1@dont-email.me> |
| In reply to | #447170 |
On 10/02/17 17:41, Tim Wescott wrote: > On Mon, 06 Feb 2017 15:43:44 -0800, dagmargoodboat wrote: > >> 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. > > This is like saying that wheelbarrows are better than trucks because one > specific model and brand of Semi has undergone a recall. > > If you're using a _decent_ optimizing compiler, then you should be able > to just state your intent reasonably clearly, then stand back and let the > optimizer do its business. > > If you're using a _broken_ compiler with _crappy_ libraries, then you > should first try to fix that situation. If you simply cannot then yes, > you would need to do things the old fashioned way. > The compiler is fine - it is gcc, and certainly counts as a decent optimising compiler, and it is /not/ broken. (Code generation for the avr is not always optimal, but is usually at least "decent".) The OP had two problems here - one was the level of abstraction through inefficient Arduino libraries, the other was a misunderstanding of how "bool" works (aided by unclear documentation and information from Arduino).
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <tim@seemywebsite.com> |
|---|---|
| Date | 2017-02-14 09:59 -0600 |
| Message-ID | <c_adnU0ZfJfJtD7FnZ2dnUU7-UOdnZ2d@giganews.com> |
| In reply to | #446506 |
On Mon, 06 Feb 2017 15:43:44 -0800, dagmargoodboat 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>: > 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 I haven't read the whole thread, but clearly there are one or two elements missing from "get a trustworthy compiler and a trustworthy set of libraries, then trust the optimizer". (And it's not "trust the optimizer"). -- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.com
[toc] | [prev] | [next] | [standalone]
| From | dagmargoodboat@yahoo.com |
|---|---|
| Date | 2017-02-14 13:46 -0800 |
| Message-ID | <13338043-8eab-470f-b41d-966b1acc03dc@googlegroups.com> |
| In reply to | #447647 |
On Tuesday, February 14, 2017 at 10:59:24 AM UTC-5, Tim Wescott wrote: > On Mon, 06 Feb 2017 15:43:44 -0800, dagmargoodboat 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): > > <...> > > 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. > > > > I haven't read the whole thread, but clearly there are one or two > elements missing from "get a trustworthy compiler and a trustworthy set > of libraries, then trust the optimizer". (And it's not "trust the > optimizer"). I was mostly posting about the output quality of the tool chain, and only incidentally about the compiler bug (that seems to have captured all the attention). I still maintain the compiler's wrong to only let me modify (at most) one bit of a boolean, but then later *itself* use all eight bits to decide if the variable is 'true' or 'false.' I'll have more time to comment on this later--I've just powered up the instrument this is all in, a pulse gadget with four computer-set HV power supplies. It's like a mad chihuahua--vicious, but cute. Cheers, James Arthur
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-15 10:04 +0100 |
| Message-ID | <o815fq$d18$1@dont-email.me> |
| In reply to | #447663 |
On 14/02/17 22:46, dagmargoodboat@yahoo.com wrote: > On Tuesday, February 14, 2017 at 10:59:24 AM UTC-5, Tim Wescott wrote: >> On Mon, 06 Feb 2017 15:43:44 -0800, dagmargoodboat 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): >>> > <...> >>> 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. >>> >> >> I haven't read the whole thread, but clearly there are one or two >> elements missing from "get a trustworthy compiler and a trustworthy set >> of libraries, then trust the optimizer". (And it's not "trust the >> optimizer"). > > I was mostly posting about the output quality of the tool chain, and only > incidentally about the compiler bug (that seems to have captured all the > attention). And you were wrong on both accounts. You got inefficient code, and you had a bug in your code. That's fair enough - not many people write perfect code every time, and sometimes it is hard to figure out what went wrong. But you blamed the toolchain quality and compiler bugs - the toolchain (compiler, library, assembler, linker) is not at fault here. First, your inefficient code for port output is due to the Arduino system's abstraction layers. That is part of the cost of using the flexible Arduino system. You can well say that the Arduino libraries are less efficient than they could be, or less well documented than they should be - I have no argument there. But you cannot compare assembly for setting a fixed output pin to code that uses run-time configurable choices of pins. It is an apples to grocery shop comparison. For the same task - turning on a fixed output pin - the compiler will generate the same optimal code as you would write by hand in assembly. Secondly, your "compiler error" was your misunderstanding of how "bool" works in C++ (or _Bool in C), leading to a mistake in sanitizing data from an external source. Again, the Arduino system may have made it harder to figure out the problem, but the compiler was not at fault. Development is hard - sometimes we hit problems that we do not understand. But the way forward is to ask "why is this happening?", not complain "/I/ can't be wrong - the tools are bad". > > I still maintain the compiler's wrong to only let me modify (at most) one > bit of a boolean, but then later *itself* use all eight bits to decide if > the variable is 'true' or 'false.' No, you are wrong here. Complain to the C standards committee that wrote C99, or the C++ designers that introduced "bool" (which C's _Bool copies). You actually would have to go back a bit and complain to Denis Ritchie, since the idea that the C compiler should believe what you tell it, based on the C language, is there from the start of the C story. > > I'll have more time to comment on this later--I've just powered up the > instrument this is all in, a pulse gadget with four computer-set HV > power supplies. It's like a mad chihuahua--vicious, but cute. > It's good that you have got it all sorted out in the end. But if you don't learn from the mistakes here, you will make them again.
[toc] | [prev] | [next] | [standalone]
| From | dagmargoodboat@yahoo.com |
|---|---|
| Date | 2017-02-15 05:57 -0800 |
| Message-ID | <d4442049-ab60-4633-a881-a4f7b09eee53@googlegroups.com> |
| In reply to | #447722 |
On Wednesday, February 15, 2017 at 4:04:44 AM UTC-5, David Brown wrote: > On 14/02/17 22:46, dagmargoodboat@yahoo.com wrote: > > On Tuesday, February 14, 2017 at 10:59:24 AM UTC-5, Tim Wescott wrote: > >> On Mon, 06 Feb 2017 15:43:44 -0800, dagmargoodboat 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): > >>> > > <...> > >>> 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. > >>> > >> > >> I haven't read the whole thread, but clearly there are one or two > >> elements missing from "get a trustworthy compiler and a trustworthy set > >> of libraries, then trust the optimizer". (And it's not "trust the > >> optimizer"). > > > > I was mostly posting about the output quality of the tool chain, and only > > incidentally about the compiler bug (that seems to have captured all the > > attention). > > And you were wrong on both accounts. You got inefficient code, and you > had a bug in your code. That's fair enough - not many people write > perfect code every time, and sometimes it is hard to figure out what > went wrong. But you blamed the toolchain quality and compiler bugs - > the toolchain (compiler, library, assembler, linker) is not at fault here. > > First, your inefficient code for port output is due to the Arduino > system's abstraction layers. No it isn't. The example I gave was, that's true. But having looked at more of the generated code, it's not particularly efficient on this 8-bit machine. > That is part of the cost of using the > flexible Arduino system. You can well say that the Arduino libraries > are less efficient than they could be, or less well documented than they > should be - I have no argument there. But you cannot compare assembly > for setting a fixed output pin to code that uses run-time configurable > choices of pins. It is an apples to grocery shop comparison. For the > same task - turning on a fixed output pin - the compiler will generate > the same optimal code as you would write by hand in assembly. > > Secondly, your "compiler error" was your misunderstanding of how "bool" > works in C++ (or _Bool in C), leading to a mistake in sanitizing data > from an external source. Again, the Arduino system may have made it > harder to figure out the problem, but the compiler was not at fault. > > Development is hard - sometimes we hit problems that we do not > understand. But the way forward is to ask "why is this happening?", not > complain "/I/ can't be wrong - the tools are bad". > > > > > I still maintain the compiler's wrong to only let me modify (at most) one > > bit of a boolean, but then later *itself* use all eight bits to decide if > > the variable is 'true' or 'false.' > > No, you are wrong here. Complain to the C standards committee that > wrote C99, or the C++ designers that introduced "bool" (which C's _Bool > copies). Assume 'b' contains 0xff. What should the following code segment print? bool b; word w; w = (word) b; w &= 1; println(w); > You actually would have to go back a bit and complain to Denis > Ritchie, since the idea that the C compiler should believe what you tell > it, based on the C language, is there from the start of the C story. > > > > > I'll have more time to comment on this later--I've just powered up the > > instrument this is all in, a pulse gadget with four computer-set HV > > power supplies. It's like a mad chihuahua--vicious, but cute. > > > > It's good that you have got it all sorted out in the end. > > But if you don't learn from the mistakes here, you will make them again. Cheers, James Arthur
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-15 16:02 +0100 |
| Message-ID | <o81qdt$n4p$1@dont-email.me> |
| In reply to | #447730 |
On 15/02/17 14:57, dagmargoodboat@yahoo.com wrote: > On Wednesday, February 15, 2017 at 4:04:44 AM UTC-5, David Brown wrote: >> On 14/02/17 22:46, dagmargoodboat@yahoo.com wrote: >>> On Tuesday, February 14, 2017 at 10:59:24 AM UTC-5, Tim Wescott wrote: >>>> On Mon, 06 Feb 2017 15:43:44 -0800, dagmargoodboat wrote: >>>> <snip> >>>> >>>> I haven't read the whole thread, but clearly there are one or two >>>> elements missing from "get a trustworthy compiler and a trustworthy set >>>> of libraries, then trust the optimizer". (And it's not "trust the >>>> optimizer"). >>> >>> I was mostly posting about the output quality of the tool chain, and only >>> incidentally about the compiler bug (that seems to have captured all the >>> attention). >> >> And you were wrong on both accounts. You got inefficient code, and you >> had a bug in your code. That's fair enough - not many people write >> perfect code every time, and sometimes it is hard to figure out what >> went wrong. But you blamed the toolchain quality and compiler bugs - >> the toolchain (compiler, library, assembler, linker) is not at fault here. >> >> First, your inefficient code for port output is due to the Arduino >> system's abstraction layers. > > No it isn't. The example I gave was, that's true. But having looked at > more of the generated code, it's not particularly efficient on this > 8-bit machine. There are certainly some areas where the code generated by avr-gcc is not as good as it could be. Part of that is limitations of the AVR architecture (inefficient pointers, no SP+index addressing), part of it is limitations of the gcc architecture (such as register allocation being done in "int" sizes, leading to sub-optimal register usage for 8-bit data), and part of it is due to there only being a few people working on the avr port of gcc, and they simply don't have the capacity to tune the compiler as well as they would like. It is also the case that code generation can be quite sensitive to a number of compiler options - perhaps the Arduino software hides these. Anyway, all I can say for sure here is that the inefficient code sample you gave is primarily due to Arduino's abstraction layers, and that when I change a port output in my own AVR C code, the generated assembly is optimal. > >> That is part of the cost of using the >> flexible Arduino system. You can well say that the Arduino libraries >> are less efficient than they could be, or less well documented than they >> should be - I have no argument there. But you cannot compare assembly >> for setting a fixed output pin to code that uses run-time configurable >> choices of pins. It is an apples to grocery shop comparison. For the >> same task - turning on a fixed output pin - the compiler will generate >> the same optimal code as you would write by hand in assembly. >> >> Secondly, your "compiler error" was your misunderstanding of how "bool" >> works in C++ (or _Bool in C), leading to a mistake in sanitizing data >> from an external source. Again, the Arduino system may have made it >> harder to figure out the problem, but the compiler was not at fault. >> >> Development is hard - sometimes we hit problems that we do not >> understand. But the way forward is to ask "why is this happening?", not >> complain "/I/ can't be wrong - the tools are bad". >> >>> >>> I still maintain the compiler's wrong to only let me modify (at most) one >>> bit of a boolean, but then later *itself* use all eight bits to decide if >>> the variable is 'true' or 'false.' >> >> No, you are wrong here. Complain to the C standards committee that >> wrote C99, or the C++ designers that introduced "bool" (which C's _Bool >> copies). > > Assume 'b' contains 0xff. What should the following code segment print? > I can't assume "b" contains 0xff, because at this point there is no "b". > bool b; > word w; > > w = (word) b; > w &= 1; > > println(w); If this is within a function, then "b" is not initialised - I expect to see a warning indicating this on the "w = (word) b;" line. (If the Arduino software does not make it extremely simple to enable -Wall warnings, then it is a poor system indeed.) I expect "w &= 1;" to do nothing, assuming optimisation is enabled. The call to "println(w)" will therefore write whatever happened to be in the registers at the time. Of course, the compiler is also free to omit the call entirely - the program has undefined behaviour, and the compiler can do anything it wants. What you do not understand here is that there is /no/ way to make "b" contain 0xff in a legal C program. It can't happen. You have to cheat - and if you cheat, you cannot expect the compiler to see that. It is /your/ responsibility to ensure that a variable is properly initialised before you attempt to read from it. This can be done by normal C initialisation or assignment. If you use pointer casts, memcpy, inline assembly, unions, and other methods to set the variable such a way that you have put an invalid value in the variable, then your program is broken - /you/ broke it by allowing undefined behaviour. You cannot expect the compiler to figure out how /you/ broke the rules behind its back, and then to take that into account.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-15 17:15 +0100 |
| Message-ID | <o81uo9$6up$1@dont-email.me> |
| In reply to | #447740 |
On 15/02/17 16:02, David Brown wrote:
> On 15/02/17 14:57, dagmargoodboat@yahoo.com wrote:
>> On Wednesday, February 15, 2017 at 4:04:44 AM UTC-5, David Brown wrote:
>>> On 14/02/17 22:46, dagmargoodboat@yahoo.com wrote:
>>>> On Tuesday, February 14, 2017 at 10:59:24 AM UTC-5, Tim Wescott wrote:
>>>>> On Mon, 06 Feb 2017 15:43:44 -0800, dagmargoodboat wrote:
>>>>>
> <snip>
>>>>>
>>>>> I haven't read the whole thread, but clearly there are one or two
>>>>> elements missing from "get a trustworthy compiler and a trustworthy set
>>>>> of libraries, then trust the optimizer". (And it's not "trust the
>>>>> optimizer").
>>>>
>>>> I was mostly posting about the output quality of the tool chain, and only
>>>> incidentally about the compiler bug (that seems to have captured all the
>>>> attention).
>>>
>>> And you were wrong on both accounts. You got inefficient code, and you
>>> had a bug in your code. That's fair enough - not many people write
>>> perfect code every time, and sometimes it is hard to figure out what
>>> went wrong. But you blamed the toolchain quality and compiler bugs -
>>> the toolchain (compiler, library, assembler, linker) is not at fault here.
>>>
>>> First, your inefficient code for port output is due to the Arduino
>>> system's abstraction layers.
>>
>> No it isn't. The example I gave was, that's true. But having looked at
>> more of the generated code, it's not particularly efficient on this
>> 8-bit machine.
>
> There are certainly some areas where the code generated by avr-gcc is
> not as good as it could be. Part of that is limitations of the AVR
> architecture (inefficient pointers, no SP+index addressing), part of it
> is limitations of the gcc architecture (such as register allocation
> being done in "int" sizes, leading to sub-optimal register usage for
> 8-bit data), and part of it is due to there only being a few people
> working on the avr port of gcc, and they simply don't have the capacity
> to tune the compiler as well as they would like. It is also the case
> that code generation can be quite sensitive to a number of compiler
> options - perhaps the Arduino software hides these.
>
> Anyway, all I can say for sure here is that the inefficient code sample
> you gave is primarily due to Arduino's abstraction layers, and that when
> I change a port output in my own AVR C code, the generated assembly is
> optimal.
>
>>
>>> That is part of the cost of using the
>>> flexible Arduino system. You can well say that the Arduino libraries
>>> are less efficient than they could be, or less well documented than they
>>> should be - I have no argument there. But you cannot compare assembly
>>> for setting a fixed output pin to code that uses run-time configurable
>>> choices of pins. It is an apples to grocery shop comparison. For the
>>> same task - turning on a fixed output pin - the compiler will generate
>>> the same optimal code as you would write by hand in assembly.
>>>
>>> Secondly, your "compiler error" was your misunderstanding of how "bool"
>>> works in C++ (or _Bool in C), leading to a mistake in sanitizing data
>>> from an external source. Again, the Arduino system may have made it
>>> harder to figure out the problem, but the compiler was not at fault.
>>>
>>> Development is hard - sometimes we hit problems that we do not
>>> understand. But the way forward is to ask "why is this happening?", not
>>> complain "/I/ can't be wrong - the tools are bad".
>>>
>>>>
>>>> I still maintain the compiler's wrong to only let me modify (at most) one
>>>> bit of a boolean, but then later *itself* use all eight bits to decide if
>>>> the variable is 'true' or 'false.'
>>>
>>> No, you are wrong here. Complain to the C standards committee that
>>> wrote C99, or the C++ designers that introduced "bool" (which C's _Bool
>>> copies).
>>
>> Assume 'b' contains 0xff. What should the following code segment print?
>>
>
> I can't assume "b" contains 0xff, because at this point there is no "b".
>
>> bool b;
>> word w;
>>
>> w = (word) b;
>> w &= 1;
>>
>> println(w);
>
> If this is within a function, then "b" is not initialised - I expect to
> see a warning indicating this on the "w = (word) b;" line. (If the
> Arduino software does not make it extremely simple to enable -Wall
> warnings, then it is a poor system indeed.)
>
> I expect "w &= 1;" to do nothing, assuming optimisation is enabled.
>
> The call to "println(w)" will therefore write whatever happened to be in
> the registers at the time. Of course, the compiler is also free to omit
> the call entirely - the program has undefined behaviour, and the
> compiler can do anything it wants.
>
> What you do not understand here is that there is /no/ way to make "b"
> contain 0xff in a legal C program. It can't happen. You have to cheat
> - and if you cheat, you cannot expect the compiler to see that. It is
> /your/ responsibility to ensure that a variable is properly initialised
> before you attempt to read from it. This can be done by normal C
> initialisation or assignment. If you use pointer casts, memcpy, inline
> assembly, unions, and other methods to set the variable such a way that
> you have put an invalid value in the variable, then your program is
> broken - /you/ broke it by allowing undefined behaviour. You cannot
> expect the compiler to figure out how /you/ broke the rules behind its
> back, and then to take that into account.
>
>
>
Just for fun, I've downloaded the latest Atmel packaging of avr-gcc
(version 3.5.4, with avr-gcc version 4.9.2). I tested this source,
compiled with:
avr-gcc -c b.c -Wall -Wextra -Os -Wa,-ahlsd=b.lst
Look at the generated object code. No matter how much you add
"volatile", or try to muck about with forcing an invalid value into "b",
the "w &= 1;" is omitted as redundant. The compiler generates a warning
message for test1:
b.c: In function 'test1':
b.c:13:4: warning: 'b' is used uninitialized in this function
[-Wuninitialized]
w = (word) b;
The listing file below shows the generated assembly. It is entirely
correct, with the only inefficiency being the loading of r24:r25 with 0
in test1 (the compiler could have skipped that).
// b.c
#include <stdbool.h>
#include <stdint.h>
typedef uint16_t word;
extern void println(word w);
void test1(void) {
bool b;
word w;
w = (word) b;
w &= 1;
println(w);
}
void test2(void) {
extern bool bx;
word w;
w = (word) bx;
w &= 1;
println(w);
}
void test3(void) {
extern volatile bool bv;
word w;
w = (word) bv;
w &= 1;
println(w);
}
void test4(void) {
extern volatile bool bv;
word w;
*(volatile uint8_t*) &bv = 2;
w = (word) bv;
w &= 1;
println(w);
}
void test5(void) {
volatile union { bool b; uint8_t u; } bu;
word w;
bu.u = 2;
w = (word) bu.b;
w &= 1;
println(w);
}
GAS LISTING /tmp/ccVWdIy0.s page 1
1 .file "b.c"
2 __SP_H__ = 0x3e
3 __SP_L__ = 0x3d
4 __SREG__ = 0x3f
5 __tmp_reg__ = 0
6 __zero_reg__ = 1
7 .text
8 .global test1
10 test1:
11 /* prologue: function */
12 /* frame size = 0 */
13 /* stack size = 0 */
14 .L__stack_usage = 0
15 0000 80E0 ldi r24,0
16 0002 90E0 ldi r25,0
17 0004 00C0 rjmp println
19 .global test2
21 test2:
22 /* prologue: function */
23 /* frame size = 0 */
24 /* stack size = 0 */
25 .L__stack_usage = 0
26 0006 8091 0000 lds r24,bx
27 000a 90E0 ldi r25,0
28 000c 00C0 rjmp println
30 .global test3
32 test3:
33 /* prologue: function */
34 /* frame size = 0 */
35 /* stack size = 0 */
36 .L__stack_usage = 0
37 000e 8091 0000 lds r24,bv
38 0012 90E0 ldi r25,0
39 0014 00C0 rjmp println
41 .global test4
43 test4:
44 /* prologue: function */
45 /* frame size = 0 */
46 /* stack size = 0 */
47 .L__stack_usage = 0
48 0016 82E0 ldi r24,lo8(2)
49 0018 8093 0000 sts bv,r24
50 001c 8091 0000 lds r24,bv
51 0020 90E0 ldi r25,0
52 0022 00C0 rjmp println
54 .global test5
56 test5:
57 0024 CF93 push r28
58 0026 DF93 push r29
59 0028 1F92 push __zero_reg__
60 002a CDB7 in r28,__SP_L__
61 002c DEB7 in r29,__SP_H__
62 /* prologue: function */
63 /* frame size = 1 */
64 /* stack size = 3 */
65 .L__stack_usage = 3
66 002e 82E0 ldi r24,lo8(2)
GAS LISTING /tmp/ccVWdIy0.s page 2
67 0030 8983 std Y+1,r24
68 0032 8981 ldd r24,Y+1
69 0034 90E0 ldi r25,0
70 0036 00D0 rcall println
71 /* epilogue start */
72 0038 0F90 pop __tmp_reg__
73 003a DF91 pop r29
74 003c CF91 pop r28
75 003e 0895 ret
77 .ident "GCC: (AVR_8_bit_GNU_Toolchain_3.5.4_1709)
4.9.2"
GAS LISTING /tmp/ccVWdIy0.s page 3
DEFINED SYMBOLS
*ABS*:0000000000000000 b.c
/tmp/ccVWdIy0.s:2 *ABS*:000000000000003e __SP_H__
/tmp/ccVWdIy0.s:3 *ABS*:000000000000003d __SP_L__
/tmp/ccVWdIy0.s:4 *ABS*:000000000000003f __SREG__
/tmp/ccVWdIy0.s:5 *ABS*:0000000000000000 __tmp_reg__
/tmp/ccVWdIy0.s:6 *ABS*:0000000000000001 __zero_reg__
/tmp/ccVWdIy0.s:10 .text:0000000000000000 test1
/tmp/ccVWdIy0.s:21 .text:0000000000000006 test2
/tmp/ccVWdIy0.s:32 .text:000000000000000e test3
/tmp/ccVWdIy0.s:43 .text:0000000000000016 test4
/tmp/ccVWdIy0.s:56 .text:0000000000000024 test5
UNDEFINED SYMBOLS
println
bx
bv
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <tim@seemywebsite.com> |
|---|---|
| Date | 2017-02-16 14:19 -0600 |
| Message-ID | <za6dnWmFjqvElDvFnZ2dnUU7-aednZ2d@giganews.com> |
| In reply to | #447730 |
On Wed, 15 Feb 2017 05:57:03 -0800, dagmargoodboat wrote: > On Wednesday, February 15, 2017 at 4:04:44 AM UTC-5, David Brown wrote: >> On 14/02/17 22:46, dagmargoodboat@yahoo.com wrote: >> > On Tuesday, February 14, 2017 at 10:59:24 AM UTC-5, Tim Wescott >> > wrote: >> >> On Mon, 06 Feb 2017 15:43:44 -0800, dagmargoodboat 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): >> >>> >> > <...> >> >>> 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. >> >>> >> >>> >> >> I haven't read the whole thread, but clearly there are one or two >> >> elements missing from "get a trustworthy compiler and a trustworthy >> >> set of libraries, then trust the optimizer". (And it's not "trust >> >> the optimizer"). >> > >> > I was mostly posting about the output quality of the tool chain, and >> > only incidentally about the compiler bug (that seems to have captured >> > all the attention). >> >> And you were wrong on both accounts. You got inefficient code, and you >> had a bug in your code. That's fair enough - not many people write >> perfect code every time, and sometimes it is hard to figure out what >> went wrong. But you blamed the toolchain quality and compiler bugs - >> the toolchain (compiler, library, assembler, linker) is not at fault >> here. >> >> First, your inefficient code for port output is due to the Arduino >> system's abstraction layers. > > No it isn't. The example I gave was, that's true. But having looked at > more of the generated code, it's not particularly efficient on this > 8-bit machine. There's two issues here that I know of. The first is that the optimizer is constrained by the difference between the target machine and how closely it resembles a C ideal machine. The C ideal machine has at least 16 bit integers, 8-bit 'puters don't. The second is that if you're going to write code that's fast on odd word size machines (and 8 bits _is_ odd word size for C), then you need to tell the compiler your intentions. Heavy use of int_fast8_t is indicated, particularly if you want the code to be efficient on both an 8-bit machine and wider word-width machines. If the processor you're using is _truly_ not a good fit for the C ideal machine (i.e., if it's a PIC or something), then any fully-compliant C is going to be less efficient than assembly. I'm not user that the AVR really fits that category. -- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.com
[toc] | [prev] | [standalone]
Page 7 of 7 — ← Prev page 1 2 3 4 5 6 [7]
Back to top | Article view | sci.electronics.design
csiph-web