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 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | bitrex <bitrex@de.lete.earthlink.net> |
|---|---|
| Date | 2017-02-06 19:08 -0500 |
| Message-ID | <Od8mA.118$Rm6.94@fx21.iad> |
| In reply to | #446506 |
On 02/06/2017 06:43 PM, 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>: > 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. The built-in functions "digitalWrite" and "digitalRead" are known to be slow. They're designed for ease of use and abstraction, not speed. If one desperately needs speed you do it the "old fashioned way." "Premature optimization is the root of all evil." > 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. What was the error and workaround? There isn't any "Arduino Compiler", it's a front-end to avr-gcc with some abstraction libraries. Something that low level sounds like it must be a compiler error with gcc. BTW the numerical representation of using bitwise operators when one of the arguments is a signed integer is "implementation defined" in C/C++. > 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 > Better than doing nothing, which if the only option were to write everything in AVR assembly is certainly what they'd be doing...;-)
[toc] | [prev] | [next] | [standalone]
| From | dagmargoodboat@yahoo.com |
|---|---|
| Date | 2017-02-06 18:47 -0800 |
| Message-ID | <8e009733-967e-49af-8d0f-0e6f2833d021@googlegroups.com> |
| In reply to | #446518 |
On Monday, February 6, 2017 at 7:08:23 PM UTC-5, bitrex wrote: > On 02/06/2017 06:43 PM, 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>: > > 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. > > The built-in functions "digitalWrite" and "digitalRead" are known to be > slow. They're designed for ease of use and abstraction, not speed. If > one desperately needs speed you do it the "old fashioned way." > > "Premature optimization is the root of all evil." > > > 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. > > What was the error and workaround? See above. > There isn't any "Arduino Compiler", > it's a front-end to avr-gcc with some abstraction libraries. Something > that low level sounds like it must be a compiler error with gcc. I'm not sure it isn't Arduino's pre-processing--I'm not sure who defined the 'boolean' type. I plowed through the stdint.h and didn't see it. But understand it's not my goal to be an Arduino expert, nor divine the inner workings of gcc. I'm trying to use it as supplied as a tool to do a small part of a big job, nothing more. > BTW the numerical representation of using bitwise operators when one of > the arguments is a signed integer is "implementation defined" in C/C++. > > > 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 > > > > Better than doing nothing, which if the only option were to write > everything in AVR assembly is certainly what they'd be doing...;-) Don't underestimate people. Everyone I know got started writing assembly, or worse, toggling front panel switches. Cheers, James Arthur
[toc] | [prev] | [next] | [standalone]
| From | bitrex <bitrex@de.lete.earthlink.net> |
|---|---|
| Date | 2017-02-06 21:51 -0500 |
| Message-ID | <7DamA.29016$J93.12017@fx39.iad> |
| In reply to | #446584 |
On 02/06/2017 09:47 PM, dagmargoodboat@yahoo.com wrote: > On Monday, February 6, 2017 at 7:08:23 PM UTC-5, bitrex wrote: >> On 02/06/2017 06:43 PM, 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>: >>> 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. >> >> The built-in functions "digitalWrite" and "digitalRead" are known to be >> slow. They're designed for ease of use and abstraction, not speed. If >> one desperately needs speed you do it the "old fashioned way." >> >> "Premature optimization is the root of all evil." >> >>> 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. >> >> What was the error and workaround? > > See above. > >> There isn't any "Arduino Compiler", >> it's a front-end to avr-gcc with some abstraction libraries. Something >> that low level sounds like it must be a compiler error with gcc. > > I'm not sure it isn't Arduino's pre-processing--I'm not sure who defined > the 'boolean' type. I plowed through the stdint.h and didn't see it. > > But understand it's not my goal to be an Arduino expert, nor divine the > inner workings of gcc. I'm trying to use it as supplied as a tool to > do a small part of a big job, nothing more. Looks like whatever this issue is (I didn't read the entire thread) was noted and fixed in a more recent release: https://github.com/arduino/Arduino/issues/2147 >> BTW the numerical representation of using bitwise operators when one of >> the arguments is a signed integer is "implementation defined" in C/C++. >> >>> 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 >>> >> >> Better than doing nothing, which if the only option were to write >> everything in AVR assembly is certainly what they'd be doing...;-) > > Don't underestimate people. Everyone I know got started writing assembly, > or worse, toggling front panel switches. > > Cheers, > James Arthur > AVR assembly is a lot more obtuse than say, PDP-8 assembly. The ISA was supposedly designed to allow optimal compilation of C code, after all...
[toc] | [prev] | [next] | [standalone]
| From | dagmargoodboat@yahoo.com |
|---|---|
| Date | 2017-02-06 20:39 -0800 |
| Message-ID | <b6bee586-a155-4df3-955d-da2fc4e2ad6d@googlegroups.com> |
| In reply to | #446586 |
On Monday, February 6, 2017 at 9:51:50 PM UTC-5, bitrex wrote: > On 02/06/2017 09:47 PM, dagmargoodboat@yahoo.com wrote: > > On Monday, February 6, 2017 at 7:08:23 PM UTC-5, bitrex wrote: > >> On 02/06/2017 06:43 PM, 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>: > >>> 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. > >> > >> The built-in functions "digitalWrite" and "digitalRead" are known to be > >> slow. They're designed for ease of use and abstraction, not speed. If > >> one desperately needs speed you do it the "old fashioned way." > >> > >> "Premature optimization is the root of all evil." > >> > >>> 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. > >> > >> What was the error and workaround? > > > > See above. > > > >> There isn't any "Arduino Compiler", > >> it's a front-end to avr-gcc with some abstraction libraries. Something > >> that low level sounds like it must be a compiler error with gcc. > > > > I'm not sure it isn't Arduino's pre-processing--I'm not sure who defined > > the 'boolean' type. I plowed through the stdint.h and didn't see it. > > > > But understand it's not my goal to be an Arduino expert, nor divine the > > inner workings of gcc. I'm trying to use it as supplied as a tool to > > do a small part of a big job, nothing more. > > Looks like whatever this issue is (I didn't read the entire thread) was > noted and fixed in a more recent release: > > https://github.com/arduino/Arduino/issues/2147 I saw that they've been having problems with this, and had tried to fix it in the past. My version's only a month or two old though, so, there's a decent chance the damn thing's just plain broken. > >> BTW the numerical representation of using bitwise operators when one of > >> the arguments is a signed integer is "implementation defined" in C/C++. > >> > >>> 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 > >>> > >> > >> Better than doing nothing, which if the only option were to write > >> everything in AVR assembly is certainly what they'd be doing...;-) > > > > Don't underestimate people. Everyone I know got started writing assembly, > > or worse, toggling front panel switches. > > > > Cheers, > > James Arthur > > > > AVR assembly is a lot more obtuse than say, PDP-8 assembly. The ISA was > supposedly designed to allow optimal compilation of C code, after all... It's super simple, I think. The VAX was *complicated*, and some of the other big machines quirky and weird; the AVR's actually pretty clean. Cheers, James Arthur (who once programmed a breakpointing debugger that single-stepped through EPROM & talked RS-232 through two port pins, in ~160 lines of 8051 assembly, taking up 1/3rd of a 1k processor and 6 of its 64 bytes of RAM.)
[toc] | [prev] | [next] | [standalone]
| From | dagmargoodboat@yahoo.com |
|---|---|
| Date | 2017-02-06 20:55 -0800 |
| Message-ID | <f59b2cdb-c3d8-4297-8836-b17fcb1fce16@googlegroups.com> |
| In reply to | #446601 |
On Monday, February 6, 2017 at 11:39:34 PM UTC-5, dagmarg...@yahoo.com wrote: > On Monday, February 6, 2017 at 9:51:50 PM UTC-5, bitrex wrote: > > AVR assembly is a lot more obtuse than say, PDP-8 assembly. The ISA was > > supposedly designed to allow optimal compilation of C code, after all... > > It's super simple, I think. The VAX was *complicated*, and some of the > other big machines quirky and weird; the AVR's actually pretty clean. > > Cheers, > James Arthur > (who once programmed a breakpointing debugger that single-stepped through > EPROM & talked RS-232 through two port pins, in ~160 lines of 8051 assembly, > taking up 1/3rd of a 1k processor and 6 of its 64 bytes of RAM.) Oops, make that ~320 lines ... I just counted 8 screens of 40 lines each. Cheers, James Arthur
[toc] | [prev] | [next] | [standalone]
| From | Clifford Heath <no.spam@please.net> |
|---|---|
| Date | 2017-02-07 20:05 +1100 |
| Message-ID | <58998dee$0$53141$c3e8da3$fdf4f6af@news.astraweb.com> |
| In reply to | #446604 |
On 07/02/17 15:55, dagmargoodboat@yahoo.com wrote: > On Monday, February 6, 2017 at 11:39:34 PM UTC-5, dagmarg...@yahoo.com wrote: >> On Monday, February 6, 2017 at 9:51:50 PM UTC-5, bitrex wrote: > >>> AVR assembly is a lot more obtuse than say, PDP-8 assembly. The ISA was >>> supposedly designed to allow optimal compilation of C code, after all... >> >> It's super simple, I think. The VAX was *complicated*, and some of the >> other big machines quirky and weird; the AVR's actually pretty clean. >> >> Cheers, >> James Arthur >> (who once programmed a breakpointing debugger that single-stepped through >> EPROM & talked RS-232 through two port pins, in ~160 lines of 8051 assembly, >> taking up 1/3rd of a 1k processor and 6 of its 64 bytes of RAM.) > > Oops, make that ~320 lines ... I just counted 8 screens of 40 lines each. Likewise. My DL11 debugger for the HC11 had a "talker" which fitted into the 256 bytes of RAM that were universally available; including the stack, variables, and room for all registers during a breakpoint. Or you could use that to put the talker in EEPROM, of course. I had a version of the talker written in C++ at one point, still in 256 bytes... and we're talking more than 20 years ago... The whole system was developed using a single bare chip that I bought with a copy of the "pink book" - I did everything else. That's why I'm a little scornful of people who weren't even born then, now being proud of their successes in the comparatively cushy Arduino environment. 32 *kilo-*bytes - we would have put the compiler in that :) Clifford Heath.
[toc] | [prev] | [next] | [standalone]
| From | bitrex <bitrex@de.lete.earthlink.net> |
|---|---|
| Date | 2017-02-08 12:26 -0500 |
| Message-ID | <BxImA.23738$mm1.17403@fx09.iad> |
| In reply to | #446619 |
On 02/07/2017 04:05 AM, Clifford Heath wrote: > On 07/02/17 15:55, dagmargoodboat@yahoo.com wrote: >> On Monday, February 6, 2017 at 11:39:34 PM UTC-5, dagmarg...@yahoo.com >> wrote: >>> On Monday, February 6, 2017 at 9:51:50 PM UTC-5, bitrex wrote: >> >>>> AVR assembly is a lot more obtuse than say, PDP-8 assembly. The ISA was >>>> supposedly designed to allow optimal compilation of C code, after >>>> all... >>> >>> It's super simple, I think. The VAX was *complicated*, and some of the >>> other big machines quirky and weird; the AVR's actually pretty clean. >>> >>> Cheers, >>> James Arthur >>> (who once programmed a breakpointing debugger that single-stepped >>> through >>> EPROM & talked RS-232 through two port pins, in ~160 lines of 8051 >>> assembly, >>> taking up 1/3rd of a 1k processor and 6 of its 64 bytes of RAM.) >> >> Oops, make that ~320 lines ... I just counted 8 screens of 40 lines each. > > Likewise. My DL11 debugger for the HC11 had a "talker" which fitted > into the 256 bytes of RAM that were universally available; including > the stack, variables, and room for all registers during a breakpoint. > Or you could use that to put the talker in EEPROM, of course. > > I had a version of the talker written in C++ at one point, still in > 256 bytes... and we're talking more than 20 years ago... > > The whole system was developed using a single bare chip that I bought > with a copy of the "pink book" - I did everything else. That's why > I'm a little scornful of people who weren't even born then, now being > proud of their successes in the comparatively cushy Arduino environment. > > 32 *kilo-*bytes - we would have put the compiler in that :) > > Clifford Heath. > The ATMega project I'm working on now will probably be a couple thousand lines of code when it's all done. You can definitely do a lot with "only" 32k...
[toc] | [prev] | [next] | [standalone]
| From | bitrex <bitrex@de.lete.earthlink.net> |
|---|---|
| Date | 2017-02-08 12:32 -0500 |
| Message-ID | <4DImA.19498$VV2.16985@fx33.iad> |
| In reply to | #446802 |
On 02/08/2017 12:26 PM, bitrex wrote: > On 02/07/2017 04:05 AM, Clifford Heath wrote: >> On 07/02/17 15:55, dagmargoodboat@yahoo.com wrote: >>> On Monday, February 6, 2017 at 11:39:34 PM UTC-5, dagmarg...@yahoo.com >>> wrote: >>>> On Monday, February 6, 2017 at 9:51:50 PM UTC-5, bitrex wrote: >>> >>>>> AVR assembly is a lot more obtuse than say, PDP-8 assembly. The ISA >>>>> was >>>>> supposedly designed to allow optimal compilation of C code, after > >>>>> all... >>>> >>>> It's super simple, I think. The VAX was *complicated*, and some of the >>>> other big machines quirky and weird; the AVR's actually pretty clean. >>>> >>>> Cheers, >>>> James Arthur >>>> (who once programmed a breakpointing debugger that single-stepped >>>> through >>>> EPROM & talked RS-232 through two port pins, in ~160 lines of 8051 >>>> assembly, >>>> taking up 1/3rd of a 1k processor and 6 of its 64 bytes of RAM.) >>> >>> Oops, make that ~320 lines ... I just counted 8 screens of 40 lines >>> each. >> >> Likewise. My DL11 debugger for the HC11 had a "talker" which fitted >> into the 256 bytes of RAM that were universally available; including >> the stack, variables, and room for all registers during a breakpoint. >> Or you could use that to put the talker in EEPROM, of course. >> >> I had a version of the talker written in C++ at one point, still in >> 256 bytes... and we're talking more than 20 years ago... >> >> The whole system was developed using a single bare chip that I bought >> with a copy of the "pink book" - I did everything else. That's why >> I'm a little scornful of people who weren't even born then, now being >> proud of their successes in the comparatively cushy Arduino environment. >> >> 32 *kilo-*bytes - we would have put the compiler in that :) >> >> Clifford Heath. >> > > The ATMega project I'm working on now will probably be a couple thousand > lines of code when it's all done. You can definitely do a lot with > "only" 32k... > Why scornful? What's wrong with cushy? Abstractions and working at a high-level is great, the compiler does a great job of crunching it down to size. The example given by the OP of the assembler output of function used to write a pin is a pathological one, as the C++ code was written to be maximally generic. If you just want something fast and simple like a basic port write or math function in my experience it makes little difference if you write the code in C or ASM; the compiler is so good that it's very hard to beat the ASM it generates in most circumstances.
[toc] | [prev] | [next] | [standalone]
| From | Clifford Heath <no.spam@please.net> |
|---|---|
| Date | 2017-02-09 08:31 +1100 |
| Message-ID | <589b8e38$0$57906$c3e8da3$c8b7d2e6@news.astraweb.com> |
| In reply to | #446805 |
On 09/02/17 04:32, bitrex wrote: > On 02/08/2017 12:26 PM, bitrex wrote: >> On 02/07/2017 04:05 AM, Clifford Heath wrote: >>> On 07/02/17 15:55, dagmargoodboat@yahoo.com wrote: >>>> On Monday, February 6, 2017 at 11:39:34 PM UTC-5, dagmarg...@yahoo.com >>>> wrote: >>>>> On Monday, February 6, 2017 at 9:51:50 PM UTC-5, bitrex wrote: >>>> >>>>>> AVR assembly is a lot more obtuse than say, PDP-8 assembly. The ISA >>>>>> was >>>>>> supposedly designed to allow optimal compilation of C code, after >> >>>>>> all... >>>>> >>>>> It's super simple, I think. The VAX was *complicated*, and some of >>>>> the >>>>> other big machines quirky and weird; the AVR's actually pretty clean. >>>>> >>>>> Cheers, >>>>> James Arthur >>>>> (who once programmed a breakpointing debugger that single-stepped >>>>> through >>>>> EPROM & talked RS-232 through two port pins, in ~160 lines of 8051 >>>>> assembly, >>>>> taking up 1/3rd of a 1k processor and 6 of its 64 bytes of RAM.) >>>> >>>> Oops, make that ~320 lines ... I just counted 8 screens of 40 lines >>>> each. >>> >>> Likewise. My DL11 debugger for the HC11 had a "talker" which fitted >>> into the 256 bytes of RAM that were universally available; including >>> the stack, variables, and room for all registers during a breakpoint. >>> Or you could use that to put the talker in EEPROM, of course. >>> >>> I had a version of the talker written in C++ at one point, still in >>> 256 bytes... and we're talking more than 20 years ago... >>> >>> The whole system was developed using a single bare chip that I bought >>> with a copy of the "pink book" - I did everything else. That's why >>> I'm a little scornful of people who weren't even born then, now being >>> proud of their successes in the comparatively cushy Arduino environment. >>> >>> 32 *kilo-*bytes - we would have put the compiler in that :) >>> >>> Clifford Heath. >>> >> >> The ATMega project I'm working on now will probably be a couple thousand >> lines of code when it's all done. You can definitely do a lot with >> "only" 32k... >> > > Why scornful? The ratio between "difficulty" and "pride" has limits. Some people get inordinately proud of their crappy little Arduino project, even though it was piss-easy and badly done. I scorn the pride, not the success. > What's wrong with cushy? Hey, I'd do the same, I like to make things cushy too. I just try not to be indecently proud of my successes. >Abstractions and working at a > high-level is great, the compiler does a great job of crunching it down > to size. The example given by the OP of the assembler output of function > used to write a pin is a pathological one, as the C++ code was written > to be maximally generic. I don't think it is C++, just C. I investigated the same function a few months back, and recall finding the source code. The size of the function is because of the need to use special opcodes to extract entries from Flash; it's not directly addressable because of the Harvard architecture. > If you just want something fast and simple like a basic port write or > math function in my experience it makes little difference if you write > the code in C or ASM; the compiler is so good that it's very hard to > beat the ASM it generates in most circumstances. My bugbear with the C in this case is that there is a bit-set and bit-clear instruction that only has a 5-bit addressing range. If the C compiler doesn't know the address, it will emit a much longer instruction instead, and the linker doesn't optimize that. When I wanted to do it in a C++ template, I couldn't find a way to cleanly tell the compiler that the register structure has a fixed physical address without hiding that in a separate source file; then it emits the long-form opcode. Clifford Heath.
[toc] | [prev] | [next] | [standalone]
| From | Clifford Heath <no.spam@please.net> |
|---|---|
| Date | 2017-02-09 08:21 +1100 |
| Message-ID | <589b8bda$0$43792$c3e8da3$5e5e430d@news.astraweb.com> |
| In reply to | #446802 |
On 09/02/17 04:26, bitrex wrote: > On 02/07/2017 04:05 AM, Clifford Heath wrote: >> On 07/02/17 15:55, dagmargoodboat@yahoo.com wrote: >>> On Monday, February 6, 2017 at 11:39:34 PM UTC-5, dagmarg...@yahoo.com >>> wrote: >>>> On Monday, February 6, 2017 at 9:51:50 PM UTC-5, bitrex wrote: >>> >>>>> AVR assembly is a lot more obtuse than say, PDP-8 assembly. The ISA >>>>> was >>>>> supposedly designed to allow optimal compilation of C code, after > >>>>> all... >>>> >>>> It's super simple, I think. The VAX was *complicated*, and some of the >>>> other big machines quirky and weird; the AVR's actually pretty clean. >>>> >>>> Cheers, >>>> James Arthur >>>> (who once programmed a breakpointing debugger that single-stepped >>>> through >>>> EPROM & talked RS-232 through two port pins, in ~160 lines of 8051 >>>> assembly, >>>> taking up 1/3rd of a 1k processor and 6 of its 64 bytes of RAM.) >>> >>> Oops, make that ~320 lines ... I just counted 8 screens of 40 lines >>> each. >> >> Likewise. My DL11 debugger for the HC11 had a "talker" which fitted >> into the 256 bytes of RAM that were universally available; including >> the stack, variables, and room for all registers during a breakpoint. >> Or you could use that to put the talker in EEPROM, of course. >> >> I had a version of the talker written in C++ at one point, still in >> 256 bytes... and we're talking more than 20 years ago... >> >> The whole system was developed using a single bare chip that I bought >> with a copy of the "pink book" - I did everything else. That's why >> I'm a little scornful of people who weren't even born then, now being >> proud of their successes in the comparatively cushy Arduino environment. >> >> 32 *kilo-*bytes - we would have put the compiler in that :) >> >> Clifford Heath. >> > > The ATMega project I'm working on now will probably be a couple thousand > lines of code when it's all done. You can definitely do a lot with > "only" 32k... Right - my last MSP430 project was 4000 lines of C, which fit in the 4K flash.
[toc] | [prev] | [next] | [standalone]
| From | Lasse Langwadt Christensen <langwadt@fonz.dk> |
|---|---|
| Date | 2017-02-08 13:33 -0800 |
| Message-ID | <f2587dda-6113-494e-862f-c31c06db0739@googlegroups.com> |
| In reply to | #446868 |
Den onsdag den 8. februar 2017 kl. 22.22.16 UTC+1 skrev Clifford Heath: > On 09/02/17 04:26, bitrex wrote: > > On 02/07/2017 04:05 AM, Clifford Heath wrote: > >> On 07/02/17 15:55, dagmargoodboat@yahoo.com wrote: > >>> On Monday, February 6, 2017 at 11:39:34 PM UTC-5, dagmarg...@yahoo.com > >>> wrote: > >>>> On Monday, February 6, 2017 at 9:51:50 PM UTC-5, bitrex wrote: > >>> > >>>>> AVR assembly is a lot more obtuse than say, PDP-8 assembly. The ISA > >>>>> was > >>>>> supposedly designed to allow optimal compilation of C code, after > > > >>>>> all... > >>>> > >>>> It's super simple, I think. The VAX was *complicated*, and some of the > >>>> other big machines quirky and weird; the AVR's actually pretty clean. > >>>> > >>>> Cheers, > >>>> James Arthur > >>>> (who once programmed a breakpointing debugger that single-stepped > >>>> through > >>>> EPROM & talked RS-232 through two port pins, in ~160 lines of 8051 > >>>> assembly, > >>>> taking up 1/3rd of a 1k processor and 6 of its 64 bytes of RAM.) > >>> > >>> Oops, make that ~320 lines ... I just counted 8 screens of 40 lines > >>> each. > >> > >> Likewise. My DL11 debugger for the HC11 had a "talker" which fitted > >> into the 256 bytes of RAM that were universally available; including > >> the stack, variables, and room for all registers during a breakpoint. > >> Or you could use that to put the talker in EEPROM, of course. > >> > >> I had a version of the talker written in C++ at one point, still in > >> 256 bytes... and we're talking more than 20 years ago... > >> > >> The whole system was developed using a single bare chip that I bought > >> with a copy of the "pink book" - I did everything else. That's why > >> I'm a little scornful of people who weren't even born then, now being > >> proud of their successes in the comparatively cushy Arduino environment. > >> > >> 32 *kilo-*bytes - we would have put the compiler in that :) > >> > >> Clifford Heath. > >> > > > > The ATMega project I'm working on now will probably be a couple thousand > > lines of code when it's all done. You can definitely do a lot with > > "only" 32k... > > Right - my last MSP430 project was 4000 lines of C, which fit > in the 4K flash. https://hackaday.io/contest/18215-the-1kb-challenge
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-02-07 08:15 +0000 |
| Message-ID | <BmfmA.304805$3L.279395@fx26.am4> |
| In reply to | #446601 |
On 07/02/17 04:39, dagmargoodboat@yahoo.com wrote: > I saw that they've been having problems with this, and had tried to > fix it in the past. My version's only a month or two old though, so, > there's a decent chance the damn thing's just plain broken. Quite possibly, but starting from C/C++ makes it easy to be broken. Consider how many subtle traps are outlined in in the Frequently Questioned Answers http://yosefk.com/c++fqa/ IMNSHO, C/C++ is a very bad starting point for a beginner - because C/C++ is so insanely complex that even its *designers* didn't realise what they had created! "Discovered" is the accurate frightening word in "Historically TMP is something of an accident; it was discovered during the process of standardizing the C++ language that its template system happens to be Turing-complete" https://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP
[toc] | [prev] | [next] | [standalone]
| From | dagmargoodboat@yahoo.com |
|---|---|
| Date | 2017-02-09 05:51 -0800 |
| Message-ID | <ae266097-f3bf-4c83-bc5b-238304255ceb@googlegroups.com> |
| In reply to | #446613 |
On Tuesday, February 7, 2017 at 3:15:33 AM UTC-5, Tom Gardner wrote: > On 07/02/17 04:39, dagmargoodboat@yahoo.com wrote: > > I saw that they've been having problems with this, and had tried to > > fix it in the past. My version's only a month or two old though, so, > > there's a decent chance the damn thing's just plain broken. > > Quite possibly, but starting from C/C++ makes it > easy to be broken. > > Consider how many subtle traps are outlined in > in the Frequently Questioned Answers > http://yosefk.com/c++fqa/ > > IMNSHO, C/C++ is a very bad starting point for > a beginner - because C/C++ is so insanely complex > that even its *designers* didn't realise what they > had created! "Discovered" is the accurate frightening > word in > "Historically TMP is something of an accident; it > was discovered during the process of standardizing > the C++ language that its template system happens > to be Turing-complete" > https://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP 'C' leaving so much to be defined later outside the language has had dizzying effect, all this flowing from a coupla' guys trying to keep their simple hacking tool simple. Simple choices can have immensely complex ramifications. Cheers, James Arthur
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-02-09 16:22 +0000 |
| Message-ID | <iH0nA.181266$6N1.162809@fx09.am4> |
| In reply to | #447005 |
On 09/02/17 13:51, dagmargoodboat@yahoo.com wrote: > On Tuesday, February 7, 2017 at 3:15:33 AM UTC-5, Tom Gardner wrote: >> On 07/02/17 04:39, dagmargoodboat@yahoo.com wrote: >>> I saw that they've been having problems with this, and had tried to >>> fix it in the past. My version's only a month or two old though, so, >>> there's a decent chance the damn thing's just plain broken. >> >> Quite possibly, but starting from C/C++ makes it >> easy to be broken. >> >> Consider how many subtle traps are outlined in >> in the Frequently Questioned Answers >> http://yosefk.com/c++fqa/ >> >> IMNSHO, C/C++ is a very bad starting point for >> a beginner - because C/C++ is so insanely complex >> that even its *designers* didn't realise what they >> had created! "Discovered" is the accurate frightening >> word in >> "Historically TMP is something of an accident; it >> was discovered during the process of standardizing >> the C++ language that its template system happens >> to be Turing-complete" >> https://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP > > 'C' leaving so much to be defined later outside the language has had > dizzying effect, all this flowing from a coupla' guys trying to keep > their simple hacking tool simple. > > Simple choices can have immensely complex ramifications. I can't fault Ritchie and Thompson for the original C concepts and limitations. I do fault people for pushing that tool into areas where it is not fit for purpose. The committees had an impossible task, and failed. I'd have been perfectly happy if either c/C++ had retained its focus on - low-level "firmware/system" applications, /or/ - high-level "general purpose" applications In the event Java deservedly won the latter. I wish there was a simpler more predictable tool for the former. Makes me want to use Forth :)
[toc] | [prev] | [next] | [standalone]
| From | bitrex <bitrex@de.lete.earthlink.net> |
|---|---|
| Date | 2017-02-09 16:45 -0500 |
| Message-ID | <Sp5nA.16143$S26.12573@fx31.iad> |
| In reply to | #447023 |
On 02/09/2017 11:22 AM, Tom Gardner wrote: > On 09/02/17 13:51, dagmargoodboat@yahoo.com wrote: >> On Tuesday, February 7, 2017 at 3:15:33 AM UTC-5, Tom Gardner wrote: >>> On 07/02/17 04:39, dagmargoodboat@yahoo.com wrote: >>>> I saw that they've been having problems with this, and had tried to >>>> fix it in the past. My version's only a month or two old though, so, >>>> there's a decent chance the damn thing's just plain broken. >>> >>> Quite possibly, but starting from C/C++ makes it >>> easy to be broken. >>> >>> Consider how many subtle traps are outlined in >>> in the Frequently Questioned Answers >>> http://yosefk.com/c++fqa/ >>> >>> IMNSHO, C/C++ is a very bad starting point for >>> a beginner - because C/C++ is so insanely complex >>> that even its *designers* didn't realise what they >>> had created! "Discovered" is the accurate frightening >>> word in >>> "Historically TMP is something of an accident; it >>> was discovered during the process of standardizing >>> the C++ language that its template system happens >>> to be Turing-complete" >>> https://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP >>> >> >> 'C' leaving so much to be defined later outside the language has had >> dizzying effect, all this flowing from a coupla' guys trying to keep >> their simple hacking tool simple. >> >> Simple choices can have immensely complex ramifications. > > I can't fault Ritchie and Thompson for the original C > concepts and limitations. > > I do fault people for pushing that tool into areas > where it is not fit for purpose. The committees had > an impossible task, and failed. > > I'd have been perfectly happy if either c/C++ had > retained its focus on > - low-level "firmware/system" applications, /or/ > - high-level "general purpose" applications > > In the event Java deservedly won the latter. I > wish there was a simpler more predictable tool > for the former. Makes me want to use Forth :) Makes me want to use one of the two dozen "Me too!" complied non-VM languages that have as their mission statement something like "We're endeavoring to create a language with the speed of C/C++ and the ease of use, flexibility, and unambiguous syntax of an interpreted language."
[toc] | [prev] | [next] | [standalone]
| From | bitrex <bitrex@de.lete.earthlink.net> |
|---|---|
| Date | 2017-02-09 16:51 -0500 |
| Message-ID | <fv5nA.34742$Yc.14732@fx27.iad> |
| In reply to | #447075 |
On 02/09/2017 04:45 PM, bitrex wrote: > On 02/09/2017 11:22 AM, Tom Gardner wrote: >> On 09/02/17 13:51, dagmargoodboat@yahoo.com wrote: >>> On Tuesday, February 7, 2017 at 3:15:33 AM UTC-5, Tom Gardner wrote: >>>> On 07/02/17 04:39, dagmargoodboat@yahoo.com wrote: >>>>> I saw that they've been having problems with this, and had tried to >>>>> fix it in the past. My version's only a month or two old though, so, >>>>> there's a decent chance the damn thing's just plain broken. >>>> >>>> Quite possibly, but starting from C/C++ makes it >>>> easy to be broken. >>>> >>>> Consider how many subtle traps are outlined in >>>> in the Frequently Questioned Answers >>>> http://yosefk.com/c++fqa/ >>>> >>>> IMNSHO, C/C++ is a very bad starting point for >>>> a beginner - because C/C++ is so insanely complex >>>> that even its *designers* didn't realise what they >>>> had created! "Discovered" is the accurate frightening >>>> word in >>>> "Historically TMP is something of an accident; it >>>> was discovered during the process of standardizing >>>> the C++ language that its template system happens >>>> to be Turing-complete" >>>> https://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP >>>> >>>> >>> >>> 'C' leaving so much to be defined later outside the language has had >>> dizzying effect, all this flowing from a coupla' guys trying to keep >>> their simple hacking tool simple. >>> >>> Simple choices can have immensely complex ramifications. >> >> I can't fault Ritchie and Thompson for the original C >> concepts and limitations. >> >> I do fault people for pushing that tool into areas >> where it is not fit for purpose. The committees had >> an impossible task, and failed. >> >> I'd have been perfectly happy if either c/C++ had >> retained its focus on >> - low-level "firmware/system" applications, /or/ >> - high-level "general purpose" applications >> >> In the event Java deservedly won the latter. I >> wish there was a simpler more predictable tool >> for the former. Makes me want to use Forth :) > > Makes me want to use one of the two dozen "Me too!" complied non-VM > languages that have as their mission statement something like "We're > endeavoring to create a language with the speed of C/C++ and the ease of > use, flexibility, and unambiguous syntax of an interpreted language." > Maybe not two dozen, we got C#, Objective-C, D, Delphi, Crystal, Go, Rust, Swift, Haskell, Scala...
[toc] | [prev] | [next] | [standalone]
| From | Clifford Heath <no.spam@please.net> |
|---|---|
| Date | 2017-02-10 09:11 +1100 |
| Message-ID | <589ce911$0$59736$c3e8da3$460562f1@news.astraweb.com> |
| In reply to | #447077 |
On 10/02/17 08:51, bitrex wrote: > On 02/09/2017 04:45 PM, bitrex wrote: >> On 02/09/2017 11:22 AM, Tom Gardner wrote: >>> On 09/02/17 13:51, dagmargoodboat@yahoo.com wrote: >>>> On Tuesday, February 7, 2017 at 3:15:33 AM UTC-5, Tom Gardner wrote: >>>>> On 07/02/17 04:39, dagmargoodboat@yahoo.com wrote: >>>>>> I saw that they've been having problems with this, and had tried to >>>>>> fix it in the past. My version's only a month or two old though, so, >>>>>> there's a decent chance the damn thing's just plain broken. >>>>> >>>>> Quite possibly, but starting from C/C++ makes it >>>>> easy to be broken. >>>>> >>>>> Consider how many subtle traps are outlined in >>>>> in the Frequently Questioned Answers >>>>> http://yosefk.com/c++fqa/ >>>>> >>>>> IMNSHO, C/C++ is a very bad starting point for >>>>> a beginner - because C/C++ is so insanely complex >>>>> that even its *designers* didn't realise what they >>>>> had created! "Discovered" is the accurate frightening >>>>> word in >>>>> "Historically TMP is something of an accident; it >>>>> was discovered during the process of standardizing >>>>> the C++ language that its template system happens >>>>> to be Turing-complete" >>>>> https://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP >>>>> >>>>> >>>>> >>>> >>>> 'C' leaving so much to be defined later outside the language has had >>>> dizzying effect, all this flowing from a coupla' guys trying to keep >>>> their simple hacking tool simple. >>>> >>>> Simple choices can have immensely complex ramifications. >>> >>> I can't fault Ritchie and Thompson for the original C >>> concepts and limitations. >>> >>> I do fault people for pushing that tool into areas >>> where it is not fit for purpose. The committees had >>> an impossible task, and failed. >>> >>> I'd have been perfectly happy if either c/C++ had >>> retained its focus on >>> - low-level "firmware/system" applications, /or/ >>> - high-level "general purpose" applications >>> >>> In the event Java deservedly won the latter. I >>> wish there was a simpler more predictable tool >>> for the former. Makes me want to use Forth :) >> >> Makes me want to use one of the two dozen "Me too!" complied non-VM >> languages that have as their mission statement something like "We're >> endeavoring to create a language with the speed of C/C++ and the ease of >> use, flexibility, and unambiguous syntax of an interpreted language." >> > > Maybe not two dozen, we got C#, Objective-C, D, Delphi, Crystal, Go, > Rust, Swift, Haskell, Scala... C# uses the DotNET VM. Scala is just Java in a gorilla suit. There are lots of obscure languages though, I'm sure "two dozen" is well below the mark. Also... quite a few languages have an LLVM front end, which allows them to be fully compiled.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-02-09 22:45 +0000 |
| Message-ID | <Qh6nA.784507$SV2.662550@fx39.am4> |
| In reply to | #447075 |
On 09/02/17 21:45, bitrex wrote: > On 02/09/2017 11:22 AM, Tom Gardner wrote: >> On 09/02/17 13:51, dagmargoodboat@yahoo.com wrote: >>> On Tuesday, February 7, 2017 at 3:15:33 AM UTC-5, Tom Gardner wrote: >>>> On 07/02/17 04:39, dagmargoodboat@yahoo.com wrote: >>>>> I saw that they've been having problems with this, and had tried to >>>>> fix it in the past. My version's only a month or two old though, so, >>>>> there's a decent chance the damn thing's just plain broken. >>>> >>>> Quite possibly, but starting from C/C++ makes it >>>> easy to be broken. >>>> >>>> Consider how many subtle traps are outlined in >>>> in the Frequently Questioned Answers >>>> http://yosefk.com/c++fqa/ >>>> >>>> IMNSHO, C/C++ is a very bad starting point for >>>> a beginner - because C/C++ is so insanely complex >>>> that even its *designers* didn't realise what they >>>> had created! "Discovered" is the accurate frightening >>>> word in >>>> "Historically TMP is something of an accident; it >>>> was discovered during the process of standardizing >>>> the C++ language that its template system happens >>>> to be Turing-complete" >>>> https://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP >>>> >>>> >>> >>> 'C' leaving so much to be defined later outside the language has had >>> dizzying effect, all this flowing from a coupla' guys trying to keep >>> their simple hacking tool simple. >>> >>> Simple choices can have immensely complex ramifications. >> >> I can't fault Ritchie and Thompson for the original C >> concepts and limitations. >> >> I do fault people for pushing that tool into areas >> where it is not fit for purpose. The committees had >> an impossible task, and failed. >> >> I'd have been perfectly happy if either c/C++ had >> retained its focus on >> - low-level "firmware/system" applications, /or/ >> - high-level "general purpose" applications >> >> In the event Java deservedly won the latter. I >> wish there was a simpler more predictable tool >> for the former. Makes me want to use Forth :) > > Makes me want to use one of the two dozen "Me too!" complied non-VM languages > that have as their mission statement something like "We're endeavoring to create > a language with the speed of C/C++ and the ease of use, flexibility, and > unambiguous syntax of an interpreted language." That's a valid point. I keep looking, but nothing has made me jump, yet. I suspect my next foray into code will be on the XMOS devices, since the compiler guarantees timings and the language and processors are based around CSP-style comms mechanisms. (Not surprising, since one of the founders was heavily involved in OCCAM/transputers.
[toc] | [prev] | [next] | [standalone]
| From | bitrex <bitrex@de.lete.earthlink.net> |
|---|---|
| Date | 2017-02-15 10:11 -0500 |
| Message-ID | <Vc_oA.20997$Rm6.2838@fx21.iad> |
| In reply to | #447088 |
On 02/09/2017 05:45 PM, Tom Gardner wrote: > On 09/02/17 21:45, bitrex wrote: >> On 02/09/2017 11:22 AM, Tom Gardner wrote: >>> On 09/02/17 13:51, dagmargoodboat@yahoo.com wrote: >>>> On Tuesday, February 7, 2017 at 3:15:33 AM UTC-5, Tom Gardner wrote: >>>>> On 07/02/17 04:39, dagmargoodboat@yahoo.com wrote: >>>>>> I saw that they've been having problems with this, and had tried to >>>>>> fix it in the past. My version's only a month or two old though, so, >>>>>> there's a decent chance the damn thing's just plain broken. >>>>> >>>>> Quite possibly, but starting from C/C++ makes it >>>>> easy to be broken. >>>>> >>>>> Consider how many subtle traps are outlined in >>>>> in the Frequently Questioned Answers >>>>> http://yosefk.com/c++fqa/ >>>>> >>>>> IMNSHO, C/C++ is a very bad starting point for >>>>> a beginner - because C/C++ is so insanely complex >>>>> that even its *designers* didn't realise what they >>>>> had created! "Discovered" is the accurate frightening >>>>> word in >>>>> "Historically TMP is something of an accident; it >>>>> was discovered during the process of standardizing >>>>> the C++ language that its template system happens >>>>> to be Turing-complete" >>>>> https://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP >>>>> >>>>> >>>>> >>>> >>>> 'C' leaving so much to be defined later outside the language has had >>>> dizzying effect, all this flowing from a coupla' guys trying to keep >>>> their simple hacking tool simple. >>>> >>>> Simple choices can have immensely complex ramifications. >>> >>> I can't fault Ritchie and Thompson for the original C >>> concepts and limitations. >>> >>> I do fault people for pushing that tool into areas >>> where it is not fit for purpose. The committees had >>> an impossible task, and failed. >>> >>> I'd have been perfectly happy if either c/C++ had >>> retained its focus on >>> - low-level "firmware/system" applications, /or/ >>> - high-level "general purpose" applications >>> >>> In the event Java deservedly won the latter. I >>> wish there was a simpler more predictable tool >>> for the former. Makes me want to use Forth :) >> >> Makes me want to use one of the two dozen "Me too!" complied non-VM >> languages >> that have as their mission statement something like "We're endeavoring >> to create >> a language with the speed of C/C++ and the ease of use, flexibility, and >> unambiguous syntax of an interpreted language." > > That's a valid point. > > I keep looking, but nothing has made me jump, yet. > > I suspect my next foray into code will be on the XMOS > devices, since the compiler guarantees timings and the > language and processors are based around CSP-style > comms mechanisms. (Not surprising, since one of > the founders was heavily involved in OCCAM/transputers. Rust seems to be the popular "modern compiled" language-du-jour among the code guys I know who stay on the ball with these things...;-)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-07 10:57 +0100 |
| Message-ID | <o7c5is$c91$1@dont-email.me> |
| In reply to | #446601 |
On 07/02/17 05:39, dagmargoodboat@yahoo.com wrote: > On Monday, February 6, 2017 at 9:51:50 PM UTC-5, bitrex wrote: >> >> Looks like whatever this issue is (I didn't read the entire thread) was >> noted and fixed in a more recent release: >> >> https://github.com/arduino/Arduino/issues/2147 > > I saw that they've been having problems with this, and had tried to > fix it in the past. My version's only a month or two old though, so, > there's a decent chance the damn thing's just plain broken. It appears to be fixed by #include <stdbool.h> in the Arduino.h header, rather than incorrectly and confusingly trying to make "boolean" an "uint8_t" in C and "bool" in C++. It would appear from this issue that Arduino originally used uint8_t for "boolean" even in C++, which is daft.
[toc] | [prev] | [next] | [standalone]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | sci.electronics.design
csiph-web