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 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-02-07 08:07 +0000 |
| Message-ID | <9ffmA.672070$SP.84039@fx43.am4> |
| In reply to | #446584 |
On 07/02/17 02:47, dagmargoodboat@yahoo.com wrote: > Don't underestimate people. Everyone I know got started writing assembly, > or worse, toggling front panel switches. From what I can make out, precisely nobody does that now. Hell's teeth, even *30* years ago too many didn't have a clue about what a compiler emitted. I had a standard interview question: given int foo; float baz; char bat = foo(baz, bar); what *kind* of instructions would you expect a processor to execute. Too many couldn't describe push/jsr/pop instructions. Nowadays I've seen people developing soft realtime telecom systems only dimly recall FSMs are something you have in compilers :(
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-07 04:01 -0500 |
| Message-ID | <o7c29k$10v$1@dont-email.me> |
| In reply to | #446612 |
On 2/7/2017 3:07 AM, Tom Gardner wrote: > On 07/02/17 02:47, dagmargoodboat@yahoo.com wrote: >> Don't underestimate people. Everyone I know got started writing >> assembly, >> or worse, toggling front panel switches. > > From what I can make out, precisely nobody does that now. > > Hell's teeth, even *30* years ago too many didn't have > a clue about what a compiler emitted. I had a standard > interview question: given > int foo; > float baz; > char bat = foo(baz, bar); > what *kind* of instructions would you expect a processor > to execute. Too many couldn't describe push/jsr/pop > instructions. I would have a hard time describing the call sequence when foo is declared as an integer and used as a function. ??? Was that supposed to be int bar; ? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-02-07 09:40 +0000 |
| Message-ID | <5CgmA.726614$vP3.574180@fx45.am4> |
| In reply to | #446618 |
On 07/02/17 09:01, rickman wrote: > On 2/7/2017 3:07 AM, Tom Gardner wrote: >> On 07/02/17 02:47, dagmargoodboat@yahoo.com wrote: >>> Don't underestimate people. Everyone I know got started writing >>> assembly, >>> or worse, toggling front panel switches. >> >> From what I can make out, precisely nobody does that now. >> >> Hell's teeth, even *30* years ago too many didn't have >> a clue about what a compiler emitted. I had a standard >> interview question: given >> int foo; >> float baz; >> char bat = foo(baz, bar); >> what *kind* of instructions would you expect a processor >> to execute. Too many couldn't describe push/jsr/pop >> instructions. > > I would have a hard time describing the call sequence when foo is declared as an > integer and used as a function. ??? Was that supposed to be int bar; ? There are two responses I can give: 1) I would expect a candidate to comment on those flaws 2) oh, picky picky picky I'm not going to say which is more appropriate :)
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-07 05:52 -0500 |
| Message-ID | <o7c8qc$msa$1@dont-email.me> |
| In reply to | #446624 |
On 2/7/2017 4:40 AM, Tom Gardner wrote: > On 07/02/17 09:01, rickman wrote: >> On 2/7/2017 3:07 AM, Tom Gardner wrote: >>> On 07/02/17 02:47, dagmargoodboat@yahoo.com wrote: >>>> Don't underestimate people. Everyone I know got started writing >>>> assembly, >>>> or worse, toggling front panel switches. >>> >>> From what I can make out, precisely nobody does that now. >>> >>> Hell's teeth, even *30* years ago too many didn't have >>> a clue about what a compiler emitted. I had a standard >>> interview question: given >>> int foo; >>> float baz; >>> char bat = foo(baz, bar); >>> what *kind* of instructions would you expect a processor >>> to execute. Too many couldn't describe push/jsr/pop >>> instructions. >> >> I would have a hard time describing the call sequence when foo is >> declared as an >> integer and used as a function. ??? Was that supposed to be int bar; ? > > There are two responses I can give: > 1) I would expect a candidate to comment on those flaws > 2) oh, picky picky picky > > I'm not going to say which is more appropriate :) In an interview once I was asked how many multipliers were used in a CIC filter. I had to think for a moment to make myself believe I wasn't messing this up before I said, I didn't know there were any multipliers in one. I must have had a funny look on my face because the interviewer looked rather sheepish and said, yes, they don't use multipliers, in fact that is the main reason they are used. I felt I had embarrassed him somehow. Maybe he didn't have many candidates who didn't screw that one up. As to your example, I find it confusing because there are different ways this could be correct, some requiring more than one error. But if this was intentional on and interview question I would not put it past an interviewer to do throw multiple mistakes in. I should have said, "There won't be any instructions generated by the compiler." Then I would just side step the issue of exactly what was wrong with the code perhaps. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-02-07 11:26 +0000 |
| Message-ID | <6aimA.732867$Ww5.95431@fx42.am4> |
| In reply to | #446633 |
On 07/02/17 10:52, rickman wrote: > On 2/7/2017 4:40 AM, Tom Gardner wrote: >> On 07/02/17 09:01, rickman wrote: >>> On 2/7/2017 3:07 AM, Tom Gardner wrote: >>>> On 07/02/17 02:47, dagmargoodboat@yahoo.com wrote: >>>>> Don't underestimate people. Everyone I know got started writing >>>>> assembly, >>>>> or worse, toggling front panel switches. >>>> >>>> From what I can make out, precisely nobody does that now. >>>> >>>> Hell's teeth, even *30* years ago too many didn't have >>>> a clue about what a compiler emitted. I had a standard >>>> interview question: given >>>> int foo; >>>> float baz; >>>> char bat = foo(baz, bar); >>>> what *kind* of instructions would you expect a processor >>>> to execute. Too many couldn't describe push/jsr/pop >>>> instructions. >>> >>> I would have a hard time describing the call sequence when foo is >>> declared as an >>> integer and used as a function. ??? Was that supposed to be int bar; ? >> >> There are two responses I can give: >> 1) I would expect a candidate to comment on those flaws >> 2) oh, picky picky picky >> >> I'm not going to say which is more appropriate :) > > In an interview once I was asked how many multipliers were used in a CIC > filter. I had to think for a moment to make myself believe I wasn't messing > this up before I said, I didn't know there were any multipliers in one. I must > have had a funny look on my face because the interviewer looked rather sheepish > and said, yes, they don't use multipliers, in fact that is the main reason they > are used. I felt I had embarrassed him somehow. Maybe he didn't have many > candidates who didn't screw that one up. > > As to your example, I find it confusing because there are different ways this > could be correct, some requiring more than one error. But if this was > intentional on and interview question I would not put it past an interviewer to > do throw multiple mistakes in. > > I should have said, "There won't be any instructions generated by the > compiler." Then I would just side step the issue of exactly what was wrong with > the code perhaps. And that would be an interesting response, because it hints that a candidate had used an optimising compiler in anger, or even just liked to assure themselves that they understood what was happening "under the hood". I could probably have an interesting conversation with such a candidate :)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-07 12:58 +0100 |
| Message-ID | <o7ccm4$3ub$1@dont-email.me> |
| In reply to | #446634 |
On 07/02/17 12:26, Tom Gardner wrote: > On 07/02/17 10:52, rickman wrote: >> On 2/7/2017 4:40 AM, Tom Gardner wrote: >>> On 07/02/17 09:01, rickman wrote: >>>> On 2/7/2017 3:07 AM, Tom Gardner wrote: >>>>> On 07/02/17 02:47, dagmargoodboat@yahoo.com wrote: >>>>>> Don't underestimate people. Everyone I know got started writing >>>>>> assembly, >>>>>> or worse, toggling front panel switches. >>>>> >>>>> From what I can make out, precisely nobody does that now. >>>>> >>>>> Hell's teeth, even *30* years ago too many didn't have >>>>> a clue about what a compiler emitted. I had a standard >>>>> interview question: given >>>>> int foo; >>>>> float baz; >>>>> char bat = foo(baz, bar); >>>>> what *kind* of instructions would you expect a processor >>>>> to execute. Too many couldn't describe push/jsr/pop >>>>> instructions. >>>> >>>> I would have a hard time describing the call sequence when foo is >>>> declared as an >>>> integer and used as a function. ??? Was that supposed to be int >>>> bar; ? >>> >>> There are two responses I can give: >>> 1) I would expect a candidate to comment on those flaws >>> 2) oh, picky picky picky >>> >>> I'm not going to say which is more appropriate :) >> >> In an interview once I was asked how many multipliers were used in a CIC >> filter. I had to think for a moment to make myself believe I wasn't >> messing >> this up before I said, I didn't know there were any multipliers in >> one. I must >> have had a funny look on my face because the interviewer looked rather >> sheepish >> and said, yes, they don't use multipliers, in fact that is the main >> reason they >> are used. I felt I had embarrassed him somehow. Maybe he didn't have >> many >> candidates who didn't screw that one up. >> >> As to your example, I find it confusing because there are different >> ways this >> could be correct, some requiring more than one error. But if this was >> intentional on and interview question I would not put it past an >> interviewer to >> do throw multiple mistakes in. >> >> I should have said, "There won't be any instructions generated by the >> compiler." Then I would just side step the issue of exactly what was >> wrong with >> the code perhaps. > > And that would be an interesting response, because it > hints that a candidate had used an optimising > compiler in anger, or even just liked to assure themselves > that they understood what was happening "under the hood". They don't have to be familiar with optimising compilers (not that there are many compilers that /don't/ optimise). They just need to be familiar with compilers that require valid C code in order to generate assembly instructions instead of error messages. The code, as given, cannot possibly compile - thus no instructions would be generated. > > I could probably have an interesting conversation with > such a candidate :) >
[toc] | [prev] | [next] | [standalone]
| From | Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> |
|---|---|
| Date | 2017-02-09 14:52 -0500 |
| Message-ID | <o7ih54$kcq$1@dont-email.me> |
| In reply to | #446634 |
On 02/07/2017 06:26 AM, Tom Gardner wrote: > On 07/02/17 10:52, rickman wrote: >> On 2/7/2017 4:40 AM, Tom Gardner wrote: >>> On 07/02/17 09:01, rickman wrote: >>>> On 2/7/2017 3:07 AM, Tom Gardner wrote: >>>>> On 07/02/17 02:47, dagmargoodboat@yahoo.com wrote: >>>>>> Don't underestimate people. Everyone I know got started writing >>>>>> assembly, >>>>>> or worse, toggling front panel switches. >>>>> >>>>> From what I can make out, precisely nobody does that now. >>>>> >>>>> Hell's teeth, even *30* years ago too many didn't have >>>>> a clue about what a compiler emitted. I had a standard >>>>> interview question: given >>>>> int foo; >>>>> float baz; >>>>> char bat = foo(baz, bar); >>>>> what *kind* of instructions would you expect a processor >>>>> to execute. Too many couldn't describe push/jsr/pop >>>>> instructions. >>>> >>>> I would have a hard time describing the call sequence when foo is >>>> declared as an >>>> integer and used as a function. ??? Was that supposed to be int >>>> bar; ? >>> >>> There are two responses I can give: >>> 1) I would expect a candidate to comment on those flaws >>> 2) oh, picky picky picky >>> >>> I'm not going to say which is more appropriate :) >> >> In an interview once I was asked how many multipliers were used in a CIC >> filter. I had to think for a moment to make myself believe I wasn't >> messing >> this up before I said, I didn't know there were any multipliers in >> one. I must >> have had a funny look on my face because the interviewer looked rather >> sheepish >> and said, yes, they don't use multipliers, in fact that is the main >> reason they >> are used. I felt I had embarrassed him somehow. Maybe he didn't have >> many >> candidates who didn't screw that one up. >> >> As to your example, I find it confusing because there are different >> ways this >> could be correct, some requiring more than one error. But if this was >> intentional on and interview question I would not put it past an >> interviewer to >> do throw multiple mistakes in. >> >> I should have said, "There won't be any instructions generated by the >> compiler." Then I would just side step the issue of exactly what was >> wrong with >> the code perhaps. > > And that would be an interesting response, because it > hints that a candidate had used an optimising > compiler in anger, or even just liked to assure themselves > that they understood what was happening "under the hood". > > I could probably have an interesting conversation with > such a candidate :) > When I interviewed at HP Labs many years ago, they asked me to derive the Fresnel formulae for reflection of a plane wave at a dielectric interface. I said, "Well, I won't crank through all the math, but here's how the derivation goes...." and talked about how phase matching in the plane restricted the directions of the outgoing waves, and then how continuity of tangential E and perpendicular D gave a 2x2 matrix equation for the relative amplitudes in both polarization cases. The interviewers seemed very happy. (Probably they'd had to watch various others go through the math, which would have been about as interesting as watching paint dry, especially on the Nth repeat.) That's about the only question of that sort I've ever been asked in an interview. 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 | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-02-09 22:47 +0000 |
| Message-ID | <pk6nA.784508$SV2.343796@fx39.am4> |
| In reply to | #447057 |
On 09/02/17 19:52, Phil Hobbs wrote: > On 02/07/2017 06:26 AM, Tom Gardner wrote: >> On 07/02/17 10:52, rickman wrote: >>> On 2/7/2017 4:40 AM, Tom Gardner wrote: >>>> On 07/02/17 09:01, rickman wrote: >>>>> On 2/7/2017 3:07 AM, Tom Gardner wrote: >>>>>> On 07/02/17 02:47, dagmargoodboat@yahoo.com wrote: >>>>>>> Don't underestimate people. Everyone I know got started writing >>>>>>> assembly, >>>>>>> or worse, toggling front panel switches. >>>>>> >>>>>> From what I can make out, precisely nobody does that now. >>>>>> >>>>>> Hell's teeth, even *30* years ago too many didn't have >>>>>> a clue about what a compiler emitted. I had a standard >>>>>> interview question: given >>>>>> int foo; >>>>>> float baz; >>>>>> char bat = foo(baz, bar); >>>>>> what *kind* of instructions would you expect a processor >>>>>> to execute. Too many couldn't describe push/jsr/pop >>>>>> instructions. >>>>> >>>>> I would have a hard time describing the call sequence when foo is >>>>> declared as an >>>>> integer and used as a function. ??? Was that supposed to be int >>>>> bar; ? >>>> >>>> There are two responses I can give: >>>> 1) I would expect a candidate to comment on those flaws >>>> 2) oh, picky picky picky >>>> >>>> I'm not going to say which is more appropriate :) >>> >>> In an interview once I was asked how many multipliers were used in a CIC >>> filter. I had to think for a moment to make myself believe I wasn't >>> messing >>> this up before I said, I didn't know there were any multipliers in >>> one. I must >>> have had a funny look on my face because the interviewer looked rather >>> sheepish >>> and said, yes, they don't use multipliers, in fact that is the main >>> reason they >>> are used. I felt I had embarrassed him somehow. Maybe he didn't have >>> many >>> candidates who didn't screw that one up. >>> >>> As to your example, I find it confusing because there are different >>> ways this >>> could be correct, some requiring more than one error. But if this was >>> intentional on and interview question I would not put it past an >>> interviewer to >>> do throw multiple mistakes in. >>> >>> I should have said, "There won't be any instructions generated by the >>> compiler." Then I would just side step the issue of exactly what was >>> wrong with >>> the code perhaps. >> >> And that would be an interesting response, because it >> hints that a candidate had used an optimising >> compiler in anger, or even just liked to assure themselves >> that they understood what was happening "under the hood". >> >> I could probably have an interesting conversation with >> such a candidate :) >> > > When I interviewed at HP Labs many years ago, they asked me to derive the > Fresnel formulae for reflection of a plane wave at a dielectric interface. I > said, "Well, I won't crank through all the math, but here's how the derivation > goes...." and talked about how phase matching in the plane restricted the > directions of the outgoing waves, and then how continuity of tangential E and > perpendicular D gave a 2x2 matrix equation for the relative amplitudes in both > polarization cases. The interviewers seemed very happy. (Probably they'd had > to watch various others go through the math, which would have been about as > interesting as watching paint dry, especially on the Nth repeat.) That's a lovely kind of answer, since it demonstrates you know how the maths is supporting and clarifying the physics and objectives.
[toc] | [prev] | [next] | [standalone]
| From | bitrex <bitrex@de.lete.earthlink.net> |
|---|---|
| Date | 2017-02-09 14:00 -0500 |
| Message-ID | <a%2nA.21204$tE7.5006@fx36.iad> |
| In reply to | #446633 |
On 02/07/2017 05:52 AM, rickman wrote: > On 2/7/2017 4:40 AM, Tom Gardner wrote: >> On 07/02/17 09:01, rickman wrote: >>> On 2/7/2017 3:07 AM, Tom Gardner wrote: >>>> On 07/02/17 02:47, dagmargoodboat@yahoo.com wrote: >>>>> Don't underestimate people. Everyone I know got started writing >>>>> assembly, >>>>> or worse, toggling front panel switches. >>>> >>>> From what I can make out, precisely nobody does that now. >>>> >>>> Hell's teeth, even *30* years ago too many didn't have >>>> a clue about what a compiler emitted. I had a standard >>>> interview question: given >>>> int foo; >>>> float baz; >>>> char bat = foo(baz, bar); >>>> what *kind* of instructions would you expect a processor >>>> to execute. Too many couldn't describe push/jsr/pop >>>> instructions. >>> >>> I would have a hard time describing the call sequence when foo is >>> declared as an >>> integer and used as a function. ??? Was that supposed to be int bar; ? >> >> There are two responses I can give: >> 1) I would expect a candidate to comment on those flaws >> 2) oh, picky picky picky >> >> I'm not going to say which is more appropriate :) > > In an interview once I was asked how many multipliers were used in a CIC > filter. I had to think for a moment to make myself believe I wasn't > messing this up before I said, I didn't know there were any multipliers > in one. I must have had a funny look on my face because the interviewer > looked rather sheepish and said, yes, they don't use multipliers, in > fact that is the main reason they are used. I felt I had embarrassed > him somehow. Maybe he didn't have many candidates who didn't screw that > one up. > > As to your example, I find it confusing because there are different ways > this could be correct, some requiring more than one error. But if this > was intentional on and interview question I would not put it past an > interviewer to do throw multiple mistakes in. > > I should have said, "There won't be any instructions generated by the > compiler." Then I would just side step the issue of exactly what was > wrong with the code perhaps. > These type of "trick" interview questions, where you have to divine WTF the interviewer is asking for, are BS. I have seen no evidence that asking these type of interview questions actually helps companies hire better candidates. Like the story of the interviewer who asks a coding candidate to write a C function that returns a sum of the first 50 integers. Okay, she writes a perfectly acceptable function that uses a loop to sum them. And she gets turned down because "Well, she didn't use the closed form n(n+1)/2 formula to generate the result." Do we actually have any idea whether she can write good code at this point? None whatsoever. Was the interviewer looking to hire a good coder, or a fucking number theorist?
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <seemywebsite@myfooter.really> |
|---|---|
| Date | 2017-02-09 13:24 -0600 |
| Message-ID | <QridnUTEKOV7XAHFnZ2dnUU7-Q-dnZ2d@giganews.com> |
| In reply to | #447041 |
On Thu, 09 Feb 2017 14:00:21 -0500, bitrex wrote:
> On 02/07/2017 05:52 AM, rickman wrote:
>> On 2/7/2017 4:40 AM, Tom Gardner wrote:
>>> On 07/02/17 09:01, rickman wrote:
>>>> On 2/7/2017 3:07 AM, Tom Gardner wrote:
>>>>> On 07/02/17 02:47, dagmargoodboat@yahoo.com wrote:
>>>>>> Don't underestimate people. Everyone I know got started writing
>>>>>> assembly,
>>>>>> or worse, toggling front panel switches.
>>>>>
>>>>> From what I can make out, precisely nobody does that now.
>>>>>
>>>>> Hell's teeth, even *30* years ago too many didn't have a clue about
>>>>> what a compiler emitted. I had a standard interview question: given
>>>>> int foo;
>>>>> float baz;
>>>>> char bat = foo(baz, bar);
>>>>> what *kind* of instructions would you expect a processor to execute.
>>>>> Too many couldn't describe push/jsr/pop instructions.
>>>>
>>>> I would have a hard time describing the call sequence when foo is
>>>> declared as an integer and used as a function. ??? Was that
>>>> supposed to be int bar; ?
>>>
>>> There are two responses I can give:
>>> 1) I would expect a candidate to comment on those flaws 2) oh, picky
>>> picky picky
>>>
>>> I'm not going to say which is more appropriate :)
>>
>> In an interview once I was asked how many multipliers were used in a
>> CIC filter. I had to think for a moment to make myself believe I
>> wasn't messing this up before I said, I didn't know there were any
>> multipliers in one. I must have had a funny look on my face because
>> the interviewer looked rather sheepish and said, yes, they don't use
>> multipliers, in fact that is the main reason they are used. I felt I
>> had embarrassed him somehow. Maybe he didn't have many candidates who
>> didn't screw that one up.
>>
>> As to your example, I find it confusing because there are different
>> ways this could be correct, some requiring more than one error. But if
>> this was intentional on and interview question I would not put it past
>> an interviewer to do throw multiple mistakes in.
>>
>> I should have said, "There won't be any instructions generated by the
>> compiler." Then I would just side step the issue of exactly what was
>> wrong with the code perhaps.
>>
>>
> These type of "trick" interview questions, where you have to divine WTF
> the interviewer is asking for, are BS. I have seen no evidence that
> asking these type of interview questions actually helps companies hire
> better candidates.
>
> Like the story of the interviewer who asks a coding candidate to write a
> C function that returns a sum of the first 50 integers. Okay, she writes
> a perfectly acceptable function that uses a loop to sum them. And she
> gets turned down because "Well, she didn't use the closed form n(n+1)/2
> formula to generate the result."
>
> Do we actually have any idea whether she can write good code at this
> point? None whatsoever. Was the interviewer looking to hire a good
> coder, or a fucking number theorist?
Back when I worked for da man, and helped hire, we had a multi-step
question that started with algebra (find the length of a line, in pixels,
that equals a certain measurement, in radians, if you know the field of
view of the image on the screen), proceeded through simple coding ("now
write a C function that does that"), then made things harder ("OK, our
processor doesn't support floating point"), then finally made things
_really_ hard ("Do you see anything wrong here?" (because we'd arranged
the numbers so that the integers would overflow)).
The average interviewee took around 45 minutes to get through the ordeal,
and we learned a LOT about their suitability for the job. We had very
few people who would get through the whole thing without coaching -- but
part of what we were looking for was how well someone could TAKE coaching
from their colleagues.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
I'm looking for work -- see my website!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-07 10:52 +0100 |
| Message-ID | <o7c58v$ban$1@dont-email.me> |
| In reply to | #446584 |
On 07/02/17 03:47, dagmargoodboat@yahoo.com wrote: > 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. > It's in the file Arduino.h, line 125 <https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/cores/arduino/Arduino.h> I don't know if you have easy access to such headers from the Arduino IDE, or if it is one of the things that the IDE hides to be "helpful" or "user-friendly".
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-07 10:50 +0100 |
| Message-ID | <o7c55n$b1u$1@dont-email.me> |
| In reply to | #446518 |
On 07/02/17 01:08, bitrex wrote: > On 02/06/2017 06:43 PM, dagmargoodboat@yahoo.com wrote: >> 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. The error, I think (I'm hoping James will confirm it), was in his declaration of the type of U.dat.flg. > > BTW the numerical representation of using bitwise operators when one of > the arguments is a signed integer is "implementation defined" in C/C++. > The numerical representation of signed integers is implementation defined - the bitwise operators are fully defined. But that's a minor detail - usually you only want to apply these operators to unsigned data, and typically to the fixed size types like uint8_t.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-06 19:49 -0500 |
| Message-ID | <o7b5g1$usc$1@dont-email.me> |
| In reply to | #446506 |
On 2/6/2017 6: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. > > 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. Maybe you are using the wrong language. https://www.google.com/search?q=arduino+forth&ie=utf-8&oe=utf-8 -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | "David Eather" <eather@tpg.com.au> |
|---|---|
| Date | 2017-02-07 12:45 +1000 |
| Message-ID | <op.yu9q9zs5wei6gd@fx-6300> |
| In reply to | #446506 |
On Tue, 07 Feb 2017 12:44:37 +1000, David Eather <eather@tpg.com.au> wrote: > On Tue, 07 Feb 2017 09:43:44 +1000, <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. >> >> 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. > > > On arduino that shouldn't that be (0xff && 1)? > > > >> >> 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 > > -- Using Opera's mail client: http://www.opera.com/mail/
[toc] | [prev] | [next] | [standalone]
| From | dagmargoodboat@yahoo.com |
|---|---|
| Date | 2017-02-06 18:51 -0800 |
| Message-ID | <abc1035b-5e82-4f4b-a1bc-ce751106f222@googlegroups.com> |
| In reply to | #446583 |
On Monday, February 6, 2017 at 9:45:30 PM UTC-5, David Eather wrote: > On Tue, 07 Feb 2017 12:44:37 +1000, David Eather <eather@tpg.com.au> wrote: > > > On Tue, 07 Feb 2017 09:43:44 +1000, <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. > >> > >> 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. > > > > > > On arduino that shouldn't that be (0xff && 1)? > > > > > > > >> > >> 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 > > > > > > > -- > Using Opera's mail client: http://www.opera.com/mail/ No, I was trying to mask the upper bits. But logical operations didn't work either -- both 0xff and 0xfe are considered 'true' in most contexts. Cheers, James Arthur
[toc] | [prev] | [next] | [standalone]
| From | "David Eather" <eather@tpg.com.au> |
|---|---|
| Date | 2017-02-08 06:35 +1000 |
| Message-ID | <op.yva4sm0iwei6gd@fx-6300> |
| In reply to | #446585 |
On Tue, 07 Feb 2017 12:51:02 +1000, <dagmargoodboat@yahoo.com> wrote: > On Monday, February 6, 2017 at 9:45:30 PM UTC-5, David Eather wrote: >> On Tue, 07 Feb 2017 12:44:37 +1000, David Eather <eather@tpg.com.au> >> wrote: >> >> > On Tue, 07 Feb 2017 09:43:44 +1000, <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. >> >> >> >> 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. >> > >> > >> > On arduino that shouldn't that be (0xff && 1)? >> > >> > >> > >> >> >> >> 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 >> > >> > >> >> >> -- >> Using Opera's mail client: http://www.opera.com/mail/ > > No, I was trying to mask the upper bits. But logical operations > didn't work either -- both 0xff and 0xfe are considered 'true' in > most contexts. > > Cheers, > James Arthur yes - not 0 is true -- Using Opera's mail client: http://www.opera.com/mail/
[toc] | [prev] | [next] | [standalone]
| From | "David Eather" <eather@tpg.com.au> |
|---|---|
| Date | 2017-02-08 06:44 +1000 |
| Message-ID | <op.yva48esnwei6gd@fx-6300> |
| In reply to | #446678 |
On Wed, 08 Feb 2017 06:43:51 +1000, David Eather <eather@tpg.com.au> wrote: > On Wed, 08 Feb 2017 06:43:06 +1000, David Eather <eather@tpg.com.au> > wrote: > >> On Tue, 07 Feb 2017 12:51:02 +1000, <dagmargoodboat@yahoo.com> wrote: >> >>> On Monday, February 6, 2017 at 9:45:30 PM UTC-5, David Eather wrote: >>>> On Tue, 07 Feb 2017 12:44:37 +1000, David Eather <eather@tpg.com.au> >>>> wrote: >>>> >>>> > On Tue, 07 Feb 2017 09:43:44 +1000, <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. >>>> >> >>>> >> 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. >>>> > >>>> > >>>> > On arduino that shouldn't that be (0xff && 1)? >>>> > >>>> > >>>> > >>>> >> >>>> >> 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 >>>> > >>>> > >>>> >>>> >>>> -- >>>> Using Opera's mail client: http://www.opera.com/mail/ >>> >>> No, I was trying to mask the upper bits. But logical operations >>> didn't work either -- both 0xff and 0xfe are considered 'true' in >>> most contexts. >>> >>> Cheers, >>> James Arthur >> >> yes - not 0 is true > > -- Using Opera's mail client: http://www.opera.com/mail/
[toc] | [prev] | [next] | [standalone]
| From | M Philbrook <jamie_ka1lpa@charter.net> |
|---|---|
| Date | 2017-02-07 17:11 -0500 |
| Message-ID | <MPG.3304102aef021e2c98a005@news.eternal-september.org> |
| In reply to | #446585 |
In article <abc1035b-5e82-4f4b-a1bc-ce751106f222@googlegroups.com>, dagmargoodboat@yahoo.com says... > > >> 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. > > > > > > > > > On arduino that shouldn't that be (0xff && 1)? > > > > > > > > > > > >> > > >> 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 > > > > > > > > > > > > -- > > Using Opera's mail client: http://www.opera.com/mail/ > > No, I was trying to mask the upper bits. But logical operations > didn't work either -- both 0xff and 0xfe are considered 'true' in > most contexts. > > > that is how Bools operate, 0 = False, any other value is true... Compilers may use what ever value they wish to set a bool to TRUE, but for better background control, the value 1 is usually the value used when directly assigning a bool. Maybe Type casting your variable to a BYTE, and doing the bitwise operations will yield the results you are looking for. Back in the day, we used to use return values for both bools and value. If the return was false than it's false, otherwise if it's true then the same value is also used for some sort of condition information.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-08 12:40 +0100 |
| Message-ID | <o7evvu$fuu$1@dont-email.me> |
| In reply to | #446694 |
On 07/02/17 23:11, M Philbrook wrote:
> In article <abc1035b-5e82-4f4b-a1bc-ce751106f222@googlegroups.com>,
> dagmargoodboat@yahoo.com says...
>> No, I was trying to mask the upper bits. But logical operations
>> didn't work either -- both 0xff and 0xfe are considered 'true' in
>> most contexts.
>>
>>
>>
>
> that is how Bools operate,
>
> 0 = False, any other value is true...
>
> Compilers may use what ever value they wish to set a
> bool to TRUE, but for better background control, the value
> 1 is usually the value used when directly assigning a bool.
No, they cannot. 1 is the only valid "true" value that can be assigned
to a bool (or _Bool in C). If you write "bool b = 23;", the compiler
/must/ assign 1 to b (or act as though it assigned 1 to it -
optimisations may let it do something else as long as the effect of the
program is as though it assigned 1 to b).
This is the key difference between a "bool" (_Bool) and just using a
uint8_t or char to store your flags.
>
> Maybe Type casting your variable to a BYTE, and doing the
> bitwise operations will yield the results you are looking for.
As I heard recently, "type casting" is what happens to film stars -
"casting" is what you do in C.
But no, casting your bool to a byte (uint8_t) will not help. The
compiler knows the possible values of the bool (0 or 1), and thus knows
the possible values the uint8_t will have after the cast (0 or 1).
>
> Back in the day, we used to use return values for both bools and
> value. If the return was false than it's false, otherwise if it's true
> then the same value is also used for some sort of condition information.
>
That is a completely different matter. A conditional statement ("if",
"while", etc.) compares its argument to 0 (in C) or "contextually
converts to bool" (in C++) - thus any non-false value is considered "true".
[toc] | [prev] | [next] | [standalone]
| From | pcdhobbs@gmail.com |
|---|---|
| Date | 2017-02-08 07:01 -0800 |
| Message-ID | <865e7bc1-f9a3-40a4-b1b5-c48867fa1d74@googlegroups.com> |
| In reply to | #446767 |
>That is a completely different matter. A conditional statement ("if",
>"while", etc.) compares its argument to 0 (in C) or "contextually
>converts to bool" (in C++) - thus any non-false value is considered "true".
Back in the late '70s (iirc) the Forth standard changed to make TRUE = -1 instead of 1, causing massive breakage. The rationale was that on a twos-complement machine that made every bit of the word 1, so you could use TRUE and FALSE in bitwise operations too.
Nice idea, if they'd thought of it the first time round. :(
Cheers
Phil Hobbs
[toc] | [prev] | [next] | [standalone]
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
Back to top | Article view | sci.electronics.design
csiph-web