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 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | mrdarrett@gmail.com |
|---|---|
| Date | 2017-02-06 15:59 -0800 |
| Message-ID | <6874e8a4-6ce5-4a89-a97c-3eb829d6a232@googlegroups.com> |
| In reply to | #446506 |
On Monday, February 6, 2017 at 3:43:55 PM UTC-8, dagmarg...@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. > > 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 O.O Michael
[toc] | [prev] | [next] | [standalone]
| From | Lasse Langwadt Christensen <langwadt@fonz.dk> |
|---|---|
| Date | 2017-02-06 16:04 -0800 |
| Message-ID | <f616d86a-c284-426c-a41e-d097adefd90a@googlegroups.com> |
| In reply to | #446506 |
Den tirsdag den 7. februar 2017 kl. 00.43.55 UTC+1 skrev dagmarg...@yahoo.com: > I've heard the kids here opine compilers are so good > these days that assembly makes no sense. > > There's lots to be said for high-level languages. But > I disassembled some Arduino code--here's the output to > write a port pin (a built-in function): > that is to say the least comparing apples to oranges, the build in function handles all the checks if it is valid pin, possibly controlled with a timer etc. so it work on multiple platforms without you needing to know much about the underlaying HW you can write directly to PORTD on the AVR if you like
[toc] | [prev] | [next] | [standalone]
| From | dagmargoodboat@yahoo.com |
|---|---|
| Date | 2017-02-06 18:41 -0800 |
| Message-ID | <dc20a840-4790-4552-9b5f-88aa1efbc806@googlegroups.com> |
| In reply to | #446516 |
On Monday, February 6, 2017 at 7:04:15 PM UTC-5, Lasse Langwadt Christensen wrote: > Den tirsdag den 7. februar 2017 kl. 00.43.55 UTC+1 skrev dagmarg...@yahoo.com: > > I've heard the kids here opine compilers are so good > > these days that assembly makes no sense. > > > > There's lots to be said for high-level languages. But > > I disassembled some Arduino code--here's the output to > > write a port pin (a built-in function): > > > > that is to say the least comparing apples to oranges, the build in > function handles all the checks if it is valid pin, possibly controlled > with a timer etc. so it work on multiple platforms without you needing > to know much about the underlaying HW > > you can write directly to PORTD on the AVR if you like Yes, understood. But isn't that always the problem? The compiler's always generating for some general case, which the assembly programmer need not do. It wasn't just the digitalWrite() -- lots of pushes and pops, subroutine calls to subroutine calls, etc. for my regular code. The CPU's plenty fast enough and there are heaps of memory, so in practice it won't generally matter. It's just a little distressing to see folks piling abstraction on abstraction on abstraction, with documentation that doesn't give parameter and return value types, 27^3 kinds of 'portable' integers, ready to all fall down. Cheers, James Arthur
[toc] | [prev] | [next] | [standalone]
| From | Clifford Heath <no.spam@please.net> |
|---|---|
| Date | 2017-02-07 14:08 +1100 |
| Message-ID | <58993a1f$0$25382$b1db1813$e2fc9064@news.astraweb.com> |
| In reply to | #446579 |
On 07/02/17 13:41, dagmargoodboat@yahoo.com wrote: > On Monday, February 6, 2017 at 7:04:15 PM UTC-5, Lasse Langwadt Christensen wrote: >> Den tirsdag den 7. februar 2017 kl. 00.43.55 UTC+1 skrev dagmarg...@yahoo.com: >>> I've heard the kids here opine compilers are so good >>> these days that assembly makes no sense. >>> >>> There's lots to be said for high-level languages. But >>> I disassembled some Arduino code--here's the output to >>> write a port pin (a built-in function): >>> >> >> that is to say the least comparing apples to oranges, the build in >> function handles all the checks if it is valid pin, possibly controlled >> with a timer etc. so it work on multiple platforms without you needing >> to know much about the underlaying HW >> >> you can write directly to PORTD on the AVR if you like > > Yes, understood. But isn't that always the problem? The compiler's > always generating for some general case, which the assembly programmer > need not do. No, that's not the problem. The problem is that digitalWrite takes a *logical* pin number, which is meant to map to the Arduino footprint for a range of different Arduino types, even though those bring a different port pin to that logical pin. If you had written (not checked, but like): *((uint8_t*)PORTD) = 0; or *((uint8_t*)PORTD) |= 0x1; Then you would get the appropriate minimal I/O instructions from any recent Arduino gcc compiler. > It wasn't just the digitalWrite() -- lots of pushes and pops, subroutine > calls to subroutine calls, etc. for my regular code. Use of subroutine calls is your prerogative, neither gcc nor asm can really circumvent those decisions... however... Did you use a high optimisation level? gcc is pretty good at inlining code if and when it can see that's possible. > The CPU's plenty fast enough and there are heaps of memory, so in practice > it won't generally matter. > > It's just a little distressing to see folks piling abstraction on > abstraction on abstraction, with documentation that doesn't give > parameter and return value types, 27^3 kinds of 'portable' integers, > ready to all fall down. The Arduino APIs are far from well-designed, for the most part. But thats not the fault of gcc nor of compiles in general. Clifford Heath.
[toc] | [prev] | [next] | [standalone]
| From | dagmargoodboat@yahoo.com |
|---|---|
| Date | 2017-02-06 20:14 -0800 |
| Message-ID | <b09fadc6-3f9e-42cc-b66d-36e7751d1afd@googlegroups.com> |
| In reply to | #446589 |
On Monday, February 6, 2017 at 10:08:19 PM UTC-5, Clifford Heath wrote: > On 07/02/17 13:41, dagmargoodboat@yahoo.com wrote: > > On Monday, February 6, 2017 at 7:04:15 PM UTC-5, Lasse Langwadt Christensen wrote: > >> Den tirsdag den 7. februar 2017 kl. 00.43.55 UTC+1 skrev dagmarg...@yahoo.com: > >>> I've heard the kids here opine compilers are so good > >>> these days that assembly makes no sense. > >>> > >>> There's lots to be said for high-level languages. But > >>> I disassembled some Arduino code--here's the output to > >>> write a port pin (a built-in function): > >>> > >> > >> that is to say the least comparing apples to oranges, the build in > >> function handles all the checks if it is valid pin, possibly controlled > >> with a timer etc. so it work on multiple platforms without you needing > >> to know much about the underlaying HW > >> > >> you can write directly to PORTD on the AVR if you like > > > > Yes, understood. But isn't that always the problem? The compiler's > > always generating for some general case, which the assembly programmer > > need not do. > > No, that's not the problem. The problem is that digitalWrite takes > a *logical* pin number, which is meant to map to the Arduino footprint > for a range of different Arduino types, even though those bring a > different port pin to that logical pin. > > If you had written (not checked, but like): > > *((uint8_t*)PORTD) = 0; > or > *((uint8_t*)PORTD) |= 0x1; > > Then you would get the appropriate minimal I/O instructions from > any recent Arduino gcc compiler. You're not understanding--I'm fully aware that I can go so far as to embed assembly if I choose. The fact that the compiler is jumping though hoops to map virtual pin numbers to physical ports and pins is exactly my point: it's solving problems that a human programmer wouldn't have to. I'd just read-modify-write the port with the appropriate mask. BUT, what the naive users have and use, is layers and layers abstracted from the hardware doing the actual work. > > It wasn't just the digitalWrite() -- lots of pushes and pops, subroutine > > calls to subroutine calls, etc. for my regular code. > > Use of subroutine calls is your prerogative, neither gcc nor asm can > really circumvent those decisions... however... Not so--it's using all sorts of calls to functions within functions as part of its standard environment. Thank heaven I'm not short on stack space! > Did you use a high optimisation level? gcc is pretty good at inlining > code if and when it can see that's possible. I can't control it. The IDE controls the build process from start to finish. It might've been easier for me to skip the Arduino IDE and write straight gcc, or even bare assembly, but the Arduino environment is a lot less intimidating for the customer. > > The CPU's plenty fast enough and there are heaps of memory, so in practice > > it won't generally matter. > > > > It's just a little distressing to see folks piling abstraction on > > abstraction on abstraction, with documentation that doesn't give > > parameter and return value types, 27^3 kinds of 'portable' integers, > > ready to all fall down. > > The Arduino APIs are far from well-designed, for the most part. It's cute, and has gotten a lot of hobbyists started. Lots of enthusiasm. It's the 'encouraging hacking' aspect--poking, prodding, and fiddling instead of planning--that's unfortunate. It teaches the next generation of programmers to be sloppy. > But thats not the fault of gcc nor of compiles in general. Of course not. > Clifford Heath. Cheers, James Arthur
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-02-07 08:00 +0000 |
| Message-ID | <48fmA.157015$6N1.154146@fx09.am4> |
| In reply to | #446595 |
On 07/02/17 04:14, dagmargoodboat@yahoo.com wrote: > On Monday, February 6, 2017 at 10:08:19 PM UTC-5, Clifford Heath wrote: > You're not understanding--I'm fully aware that I can go so far as to embed > assembly if I choose. > > The fact that the compiler is jumping though hoops to map virtual pin numbers > to physical ports and pins is exactly my point: it's solving problems that > a human programmer wouldn't have to. I'd just read-modify-write the port > with the appropriate mask. > > BUT, what the naive users have and use, is layers and layers abstracted from > the hardware doing the actual work. That's a major objective of libraries and environments in general. When I wanted to design something very simple where I had control of power consumption, I looked at and decided to avoid Arduino and similar systems. I strongly suspected, based on experiences *decades* ago, that I would end up spending too much time discovering and circumventing the environments' unstated assumptions. So: plus ca change, plus c'est la meme chose! > It's cute, and has gotten a lot of hobbyists started. Lots of enthusiasm. > It's the 'encouraging hacking' aspect--poking, prodding, and fiddling > instead of planning--that's unfortunate. It teaches the next generation > of programmers to be sloppy. Beginners are *always* going to be hackers; it goes with the territory. If you try and force "good development practices" on them, you will put them off. The decent ones will hack, become aware of the limitations of what they have done, and find ways to do better in the future. The other ones can't be saved by *any* technology, as exemplified by the obvious generalisation of "You can write FORTRAN in any language"
[toc] | [prev] | [next] | [standalone]
| From | dagmargoodboat@yahoo.com |
|---|---|
| Date | 2017-02-09 05:42 -0800 |
| Message-ID | <fbe16b9e-6b68-44fd-a42a-025b2b55c232@googlegroups.com> |
| In reply to | #446611 |
On Tuesday, February 7, 2017 at 3:00:05 AM UTC-5, Tom Gardner wrote: > On 07/02/17 04:14, dagmargoodboat@yahoo.com wrote: > > On Monday, February 6, 2017 at 10:08:19 PM UTC-5, Clifford Heath wrote: > > > You're not understanding--I'm fully aware that I can go so far as to embed > > assembly if I choose. > > > > The fact that the compiler is jumping though hoops to map virtual pin numbers > > to physical ports and pins is exactly my point: it's solving problems that > > a human programmer wouldn't have to. I'd just read-modify-write the port > > with the appropriate mask. > > > > BUT, what the naive users have and use, is layers and layers abstracted from > > the hardware doing the actual work. > > That's a major objective of libraries and > environments in general. To an extent, true. More often my aim in using a pre-written function is to avoid repeating the work, not avoiding understanding the task. 'C' was conceived as a portable assembly language, so it's bizarre and ironic that this portable 'assembly' doesn't guarantee the size of its basic variables--that's one of the most basic elements of assembly-level programming. > When I wanted to design something very simple where > I had control of power consumption, I looked at and > decided to avoid Arduino and similar systems. > > I strongly suspected, based on experiences *decades* > ago, that I would end up spending too much time > discovering and circumventing the environments' > unstated assumptions. Your fears were justified. I think this foray will still be a net plus-- the customer is already using the Arduino, and will be comfortable maintaining the code. But it is a little scary having this 1.1kV hardware on my desk (next to my keyboard) under Arduino control. Gladly, I included several safeties. > So: plus ca change, plus c'est la meme chose! > > > > It's cute, and has gotten a lot of hobbyists started. Lots of enthusiasm. > > It's the 'encouraging hacking' aspect--poking, prodding, and fiddling > > instead of planning--that's unfortunate. It teaches the next generation > > of programmers to be sloppy. > > Beginners are *always* going to be hackers; it > goes with the territory. If you try and force > "good development practices" on them, you will > put them off. That's a more hopeful take on it, thanks. > > The decent ones will hack, become aware of the > limitations of what they have done, and find ways > to do better in the future. > > The other ones can't be saved by *any* technology, as > exemplified by the obvious generalisation of "You > can write FORTRAN in any language" Cheers, James Arthur
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-09 15:07 +0100 |
| Message-ID | <o7hsv8$48r$1@dont-email.me> |
| In reply to | #447004 |
On 09/02/17 14:42, dagmargoodboat@yahoo.com wrote: > > 'C' was conceived as a portable assembly language, so it's bizarre and > ironic that this portable 'assembly' doesn't guarantee the size of its > basic variables--that's one of the most basic elements of assembly-level > programming. No, C was never a "portable assembly language". Some people think so - they are wrong, and the result is that they are unable to write good C code because they completely misunderstand the language. C was designed to remove the need to write so much code in assembly. It was designed to /replace/ assembly for many purposes, not to be a new kind of assembly. One of the points of C is that it isolated most programmers from the need to deal with details such as the size of its basic types, thus making it easier to write code that works on a wide variety of systems. At the same time, it placed a strong emphasis on "implementation defined" behaviour - the C language does not define the sizes of its basic types, but any given C implementation /does/ define them. So you can write code that is portable across many systems, and you can also write code that is dependent on the details of a particular target. (C99 included types that make it easier to write portable code that needs to rely on some of these details.) It is a myth that C is a "portable assembly language" or anything of the sort. It is a misunderstanding to think that when using C, you do not have guarantees about the sizes of basic types or their representation.
[toc] | [prev] | [next] | [standalone]
| From | Lasse Langwadt Christensen <langwadt@fonz.dk> |
|---|---|
| Date | 2017-02-09 09:54 -0800 |
| Message-ID | <230c276e-f829-435b-be47-f07b24216da9@googlegroups.com> |
| In reply to | #447007 |
Den torsdag den 9. februar 2017 kl. 15.07.23 UTC+1 skrev David Brown: > On 09/02/17 14:42, dagmargoodboat@yahoo.com wrote: > > > > > 'C' was conceived as a portable assembly language, so it's bizarre and > > ironic that this portable 'assembly' doesn't guarantee the size of its > > basic variables--that's one of the most basic elements of assembly-level > > programming. > > No, C was never a "portable assembly language". Some people think so - > they are wrong, and the result is that they are unable to write good C > code because they completely misunderstand the language. > > C was designed to remove the need to write so much code in assembly. It > was designed to /replace/ assembly for many purposes, not to be a new > kind of assembly. > > One of the points of C is that it isolated most programmers from the > need to deal with details such as the size of its basic types, thus > making it easier to write code that works on a wide variety of systems. > At the same time, it placed a strong emphasis on "implementation > defined" behaviour - the C language does not define the sizes of its > basic types, but any given C implementation /does/ define them. So you > can write code that is portable across many systems, and you can also > write code that is dependent on the details of a particular target. > (C99 included types that make it easier to write portable code that > needs to rely on some of these details.) > > It is a myth that C is a "portable assembly language" or anything of the > sort. > > It is a misunderstanding to think that when using C, you do not have > guarantees about the sizes of basic types or their representation. it is a balancing act between portable code and portable language while keeping up performance
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-02-09 15:55 +0000 |
| Message-ID | <Wh0nA.89206$8K.21381@fx46.am4> |
| In reply to | #447004 |
On 09/02/17 13:42, dagmargoodboat@yahoo.com wrote: > On Tuesday, February 7, 2017 at 3:00:05 AM UTC-5, Tom Gardner wrote: >> On 07/02/17 04:14, dagmargoodboat@yahoo.com wrote: >>> On Monday, February 6, 2017 at 10:08:19 PM UTC-5, Clifford Heath wrote: >> >>> You're not understanding--I'm fully aware that I can go so far as to embed >>> assembly if I choose. >>> >>> The fact that the compiler is jumping though hoops to map virtual pin numbers >>> to physical ports and pins is exactly my point: it's solving problems that >>> a human programmer wouldn't have to. I'd just read-modify-write the port >>> with the appropriate mask. >>> >>> BUT, what the naive users have and use, is layers and layers abstracted from >>> the hardware doing the actual work. >> >> That's a major objective of libraries and >> environments in general. > > To an extent, true. More often my aim in using a pre-written function is > to avoid repeating the work, not avoiding understanding the task. > > 'C' was conceived as a portable assembly language, so it's bizarre and > ironic that this portable 'assembly' doesn't guarantee the size of its > basic variables--that's one of the most basic elements of assembly-level > programming. Porting C code has /always/ been very difficult, and required arcane knowledge and extreme care; start by considering "porting" from twos complement to ones complement machines. But from the late 80s onwards it has been unsuccessfully straddling two stools: that of a general purpose high level language for applications and also for low-level near-the-silicon "system/firmware" code. Consider that multithreading behaviour is (was?) explicitly left undefined or implementation dependent, but POSIX thread implementations relied on that behaviour. Maybe having a memory model will help, but it is astoundingly difficult to get that right across multiple architectures. Even the Java JVM's memory model was reworked in the light of experience. Until ~1993 I vaguely followed the standards, but the eternal and /unresolvable/ "cast away constness" discussions convinced me that C (and doubly C++) was becoming a problem more than a solution. You mustn't be able to cast away constness, since that might affect correctness. You must be able to cast away constness for some efficiency hacks and for things like debuggers. That's unresolvable. C++ is worse; the designers *discovered* they'd created a monstrosity where you can cause the compiler to emit the sequence of prime numbers during compilation. The designers didn't believe it until someone demonstrated it! No, nowadays C++ is beyond mortal's comprehension, and C isn't much better. Shame. >> When I wanted to design something very simple where >> I had control of power consumption, I looked at and >> decided to avoid Arduino and similar systems. >> >> I strongly suspected, based on experiences *decades* >> ago, that I would end up spending too much time >> discovering and circumventing the environments' >> unstated assumptions. > > Your fears were justified. I think this foray will still be a net plus-- > the customer is already using the Arduino, and will be comfortable maintaining > the code. > > But it is a little scary having this 1.1kV hardware on my desk (next to my > keyboard) under Arduino control. Gladly, I included several safeties. Presuming the software works (yes, I know), I would still be concerned about the mechanical suitability of normal arduino hardware in an industrial setting. >> So: plus ca change, plus c'est la meme chose! >> >> >>> It's cute, and has gotten a lot of hobbyists started. Lots of enthusiasm. >>> It's the 'encouraging hacking' aspect--poking, prodding, and fiddling >>> instead of planning--that's unfortunate. It teaches the next generation >>> of programmers to be sloppy. >> >> Beginners are *always* going to be hackers; it >> goes with the territory. If you try and force >> "good development practices" on them, you will >> put them off. > > That's a more hopeful take on it, thanks. A rare occasion where I am optimistic ;} > >> >> The decent ones will hack, become aware of the >> limitations of what they have done, and find ways >> to do better in the future. >> >> The other ones can't be saved by *any* technology, as >> exemplified by the obvious generalisation of "You >> can write FORTRAN in any language"
[toc] | [prev] | [next] | [standalone]
| From | dagmargoodboat@yahoo.com |
|---|---|
| Date | 2017-02-09 08:46 -0800 |
| Message-ID | <0f8336cf-70f6-43c5-806e-6458d80dde0a@googlegroups.com> |
| In reply to | #447021 |
On Thursday, February 9, 2017 at 10:55:41 AM UTC-5, Tom Gardner wrote: > On 09/02/17 13:42, dagmargoodboat@yahoo.com wrote: > > But it is a little scary having this 1.1kV hardware on my desk (next to my > > keyboard) under Arduino control. Gladly, I included several safeties. > > Presuming the software works (yes, I know), I would > still be concerned about the mechanical suitability > of normal arduino hardware in an industrial setting. It's not an actual Arduino. I designed an ATmega-based controller, but made it Arduino-compatible. The hardware is much tougher than an Arduino, but yes, I'm programming it over USB using the Arduino IDE. Cheers, James Arthur
[toc] | [prev] | [next] | [standalone]
| From | Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> |
|---|---|
| Date | 2017-02-09 14:42 -0500 |
| Message-ID | <o7igiu$fdg$2@dont-email.me> |
| In reply to | #447027 |
On 02/09/2017 11:46 AM, dagmargoodboat@yahoo.com wrote: > On Thursday, February 9, 2017 at 10:55:41 AM UTC-5, Tom Gardner wrote: >> On 09/02/17 13:42, dagmargoodboat@yahoo.com wrote: > >>> But it is a little scary having this 1.1kV hardware on my desk (next to my >>> keyboard) under Arduino control. Gladly, I included several safeties. >> >> Presuming the software works (yes, I know), I would >> still be concerned about the mechanical suitability >> of normal arduino hardware in an industrial setting. > > It's not an actual Arduino. I designed an ATmega-based controller, but > made it Arduino-compatible. The hardware is much tougher than an Arduino, > but yes, I'm programming it over USB using the Arduino IDE. > > Cheers, > James Arthur > Does the Arduino IDE support gdb yet? The reason I dropped it long ago was that the burn-and-crash development model was so 1980. I had full source-level debug in Microsoft C 5.0 in about 1988. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.net
[toc] | [prev] | [next] | [standalone]
| From | dagmargoodboat@yahoo.com |
|---|---|
| Date | 2017-02-11 06:54 -0800 |
| Message-ID | <4d785ffd-a83d-4263-afd4-f5d7038071d2@googlegroups.com> |
| In reply to | #447056 |
On Thursday, February 9, 2017 at 2:42:08 PM UTC-5, Phil Hobbs wrote: > On 02/09/2017 11:46 AM, dagmargoodboat@yahoo.com wrote: > > On Thursday, February 9, 2017 at 10:55:41 AM UTC-5, Tom Gardner wrote: > >> On 09/02/17 13:42, dagmargoodboat@yahoo.com wrote: > > > >>> But it is a little scary having this 1.1kV hardware on my desk (next to my > >>> keyboard) under Arduino control. Gladly, I included several safeties. > >> > >> Presuming the software works (yes, I know), I would > >> still be concerned about the mechanical suitability > >> of normal arduino hardware in an industrial setting. > > > > It's not an actual Arduino. I designed an ATmega-based controller, but > > made it Arduino-compatible. The hardware is much tougher than an Arduino, > > but yes, I'm programming it over USB using the Arduino IDE. > > > > > Does the Arduino IDE support gdb yet? The reason I dropped it long ago > was that the burn-and-crash development model was so 1980. I don't know if gdb is supported. At bottom the Arduino IDE is just a pre-processor to gcc (written in Java!), so I don't see that the tool chain would preclude it. But it all runs in FLASH, which might make break-pointing a bit of a bear. Ages ago, the 300-odd line debugger I wrote single-stepped the 8051 through EPROM by setting an interrupt before passing control to the user program. That causes the 8051 to execute the next instruction, before it handles the interrupt. The debugger, thus, could step execution one step, then regain control. That's pretty useless for debugging code running in real time though-- ISTM you'd need an emulator at that point. > I had full source-level debug in Microsoft C 5.0 in about 1988. Yep, me too. Cheers, James Arthur
[toc] | [prev] | [next] | [standalone]
| From | pcdhobbs@gmail.com |
|---|---|
| Date | 2017-02-11 07:31 -0800 |
| Message-ID | <e76e2ab0-486b-4b5c-8d99-e1020f7f0124@googlegroups.com> |
| In reply to | #447287 |
>> Does the Arduino IDE support gdb yet? The reason I dropped it long ago >> was that the burn-and-crash development model was so 1980. >I don't know if gdb is supported. At bottom the Arduino IDE is just a >pre-processor to gcc (written in Java!), so I don't see that the tool >chain would preclude it. But it all runs in FLASH, which might make >break-pointing a bit of a bear. You can do it in AVR Studio. Cheers Phil Hobbs
[toc] | [prev] | [next] | [standalone]
| From | dagmargoodboat@yahoo.com |
|---|---|
| Date | 2017-02-11 07:59 -0800 |
| Message-ID | <3bf37366-5f72-4932-ab35-48f0ce63adc0@googlegroups.com> |
| In reply to | #447290 |
On Saturday, February 11, 2017 at 10:31:33 AM UTC-5, pcdh...@gmail.com wrote: > >> Does the Arduino IDE support gdb yet? The reason I dropped it long ago > >> was that the burn-and-crash development model was so 1980. > > >I don't know if gdb is supported. At bottom the Arduino IDE is just a > >pre-processor to gcc (written in Java!), so I don't see that the tool > >chain would preclude it. But it all runs in FLASH, which might make > >break-pointing a bit of a bear. > > You can do it in AVR Studio. ICE -- that's nice. http://www.atmel.com/Microsite/atmel-studio/debugging-simulation.aspx I remember single-stepping in QuickBasic. That was a damn fine compiler. Cheers, James Arthur
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-02-11 17:01 +0000 |
| Message-ID | <4sHnA.804391$SV2.363690@fx39.am4> |
| In reply to | #447293 |
On 11/02/17 15:59, dagmargoodboat@yahoo.com wrote: > On Saturday, February 11, 2017 at 10:31:33 AM UTC-5, pcdh...@gmail.com wrote: >>>> Does the Arduino IDE support gdb yet? The reason I dropped it long ago >>>> was that the burn-and-crash development model was so 1980. >> >>> I don't know if gdb is supported. At bottom the Arduino IDE is just a >>> pre-processor to gcc (written in Java!), so I don't see that the tool >>> chain would preclude it. But it all runs in FLASH, which might make >>> break-pointing a bit of a bear. >> >> You can do it in AVR Studio. > > ICE -- that's nice. > http://www.atmel.com/Microsite/atmel-studio/debugging-simulation.aspx I used the Atmel Studio with AVR Dragon plus "jtag" for single stepping through C and the generated asm. It worked well, apart from being windows only. That was equivalent to the enormous (size, price) Z80 etc ICE systems I used in the early 80s. The only difference was a couple of orders reduction in size and price of both the MCU and the dev kit. I'm still schizophrenic about wwjetjer to be delighted or appalled by the lack of change in >30 years.
[toc] | [prev] | [next] | [standalone]
| From | pcdhobbs@gmail.com |
|---|---|
| Date | 2017-02-11 12:52 -0800 |
| Message-ID | <5779a938-cf4c-485a-b1f0-f7094d5df4e6@googlegroups.com> |
| In reply to | #447293 |
>ICE -- that's nice. http://www.atmel.com/Microsite/atmel-studio/debugging-simulation.aspx That's been available since before Arduino, which is why I find their burn-and-crash model so ridiculous. >I remember single-stepping in QuickBasic. That was a damn fine compiler. Not nearly as good as HP Basic, which had al sorts of cool instrument control stuff. Cheers Phil Hobbs I used to like Quick C too.
[toc] | [prev] | [next] | [standalone]
| From | krw@notreal.com |
|---|---|
| Date | 2017-02-11 18:46 -0500 |
| Message-ID | <tb8v9cd9eipegntlvl6vghd4ag3tmnq09u@4ax.com> |
| In reply to | #447314 |
On Sat, 11 Feb 2017 12:52:56 -0800 (PST), pcdhobbs@gmail.com wrote: >>ICE -- that's nice. >http://www.atmel.com/Microsite/atmel-studio/debugging-simulation.aspx > >That's been available since before Arduino, which is why I find their burn-and-crash model so ridiculous. > >>I remember single-stepping in QuickBasic. That was a damn fine compiler. >Not nearly as good as HP Basic, which had al sorts of cool instrument control stuff. Tek BASIC was pretty nice too, with "waverform" variables and "primatives" like INT, DIF, FFT, etc.). The hardware was on the expensive side ($1/4M, in 1977 bought a pretty nice system ;-).
[toc] | [prev] | [next] | [standalone]
| From | Clifford Heath <no.spam@please.net> |
|---|---|
| Date | 2017-02-12 10:20 +1100 |
| Message-ID | <589f9c3e$0$2316$c3e8da3$9deca2c3@news.astraweb.com> |
| In reply to | #447287 |
On 12/02/17 01:54, dagmargoodboat@yahoo.com wrote: > On Thursday, February 9, 2017 at 2:42:08 PM UTC-5, Phil Hobbs wrote: >> Does the Arduino IDE support gdb yet? The reason I dropped it long ago >> was that the burn-and-crash development model was so 1980. > > I don't know if gdb is supported. At bottom the Arduino IDE is just a > pre-processor to gcc (written in Java!), so I don't see that the tool > chain would preclude it. But it all runs in FLASH, which might make > break-pointing a bit of a bear. All AVRs have hardware breakpoint support, and many have data breakpoints too. <http://www.atmel.com/webdoc/avrdragon/avrdragon.using_ocd_introduction.html>
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-13 16:07 +0100 |
| Message-ID | <o7si10$9o$2@dont-email.me> |
| In reply to | #447056 |
On 09/02/17 20:42, Phil Hobbs wrote: > On 02/09/2017 11:46 AM, dagmargoodboat@yahoo.com wrote: >> On Thursday, February 9, 2017 at 10:55:41 AM UTC-5, Tom Gardner wrote: >>> On 09/02/17 13:42, dagmargoodboat@yahoo.com wrote: >> >>>> But it is a little scary having this 1.1kV hardware on my desk (next >>>> to my >>>> keyboard) under Arduino control. Gladly, I included several safeties. >>> >>> Presuming the software works (yes, I know), I would >>> still be concerned about the mechanical suitability >>> of normal arduino hardware in an industrial setting. >> >> It's not an actual Arduino. I designed an ATmega-based controller, but >> made it Arduino-compatible. The hardware is much tougher than an >> Arduino, >> but yes, I'm programming it over USB using the Arduino IDE. >> >> Cheers, >> James Arthur >> > > Does the Arduino IDE support gdb yet? The reason I dropped it long ago > was that the burn-and-crash development model was so 1980. > Certainly gdb debugging works fine on the AVR using other IDE's - I use Eclipse. (Of course there are limitations from the hardware, such as a limited number of hardware breakpoints.) > I had full source-level debug in Microsoft C 5.0 in about 1988. > > Cheers > > Phil Hobbs >
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | sci.electronics.design
csiph-web