C program flow control - Very Basic Question.
in [Embedded]
|
Prev: ready to run 32bit controller
Next: ARM7
From: Tim Wescott on 6 Jun 2010 14:08 On 06/05/2010 09:34 PM, Paul Keinanen wrote: > On Wed, 02 Jun 2010 08:35:24 -0600, hamilton<hamilton(a)nothere.com> > wrote: > >> On 6/2/2010 6:24 AM, Royston Vasey wrote: > >>> Using assembly I would have used "goto" to steer execution where I wanted >>> it, but how is it approached in C? >> >> There is no "goto" in C. >> >> "goto" in C is bad (very bad) practice. > > Up to the 1960's usually the only way to alter the program execution > was some kind of jump/branch/goto instructions and some primitive loop > constructs on some high level languages (such as the DO loop in > Fortran IV), thus gotos had to be used almost exclusively. > > With languages containing some structured features that are easy to > use, the need for gotos was significantly reduced, but not eliminated > completely. > > The C-language lacks several features such as loop naming (allowing > exiting multiple nested loops at once) or switch/case style error > handlers at the end of module and thus gotos are still required. > > I would consider the slogan "goto considered harmful" as a harmful > statement, since applying it blindly has created a lot of unreadable > and hence unmaintainable code (such as weird status variables or very > deeply nested if-statements) instead of using one or two well placed > gotos to simplify the program structure. > > After all the Dijkstra/Wirth slogan "goto considered harmful" was > intended to advocate the structured programming model and languages > based on that model. A better slogan is "Goto almost always harmful", which basically means that it's a really useful too after you've gone through a gun safety course on the thing. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
From: George Neuner on 7 Jun 2010 15:05 On Sun, 06 Jun 2010 13:40:40 +0200, David Brown <david.brown(a)hesbynett.removethisbit.no> wrote: >George Neuner wrote: >> On Fri, 4 Jun 2010 12:08:28 +0800, "Royston Vasey" <royston(a)vasey.com> >> wrote: >> >>> "Albert van der Horst" <albert(a)spenarnc.xs4all.nl> wrote >>>> Royston Vasey <royston(a)vasey.com> wrote: >>>> >>>>> I'm teaching myself C using Microchip's C18 compiler. >>>> Although this is c.l.e I would recommend using Turbo C 2.0 to learn >>>> C. If you can get it. No distraction from the language itself. >>> >>> Thanks Albert, but I'm using C18 as my objective is to created an embedded >>> device and the direct route suits me best. >> >> I get that you want to dive into hardware, but you'd really be better >> off learning the language *before* you try to use it for an embedded >> project. The problem with C is that it _looks_ simple - the truth is >> that it will be quite a while before you will be able to write >> reliable programs. >> >> Compilers for small MPUs, DSPs and PICs (the generic "PIC") tend to >> have non-standard features, weird limitations and just more plain old >> bugs than compilers for popular desktop OSes. And cross-compiling for >> an embedded target creates build and test issues that desktop systems >> don't have. All these things are confusing distractions that you >> don't need while you're trying to learn a language. >> >> There are decent, free compilers available for just about any OS. >> Except for GCC, most won't be C99 compilers, but any ANSI compiler >> will do for learning. >> >> George > >I disagree with that advice. Your prerogative. > Programming C on a "big system" and >programming C on an embedded system are very different. People who have >learned C by reading books (or doing courses) and programming on >Windows, Linux, or whatever, often have a lot of unlearning to do before >they can write decent embedded software. They'll use "int" everywhere >with no consideration for the underlying cpu and they'll use floating >point, memory space, "printf" and "malloc" as though they were as cheap >as on a PC. They will miss out all understanding of interrupts, >volatiles, hardware access, resource limitations, etc. I don't disagree with anything you're saying, but, in my experience it is difficult enough for many (maybe most) people to learn programming _well_ without screwing around with an embedded programming environment. [IMO, many "professional" software developers should find another profession and the majority of people should never try to write software ... but those are topics for other threads.] Learning is definitely more fun when you can make things light up, sing, move, etc., but too many of the people I've met who learned to program by screwing around are also among the worst software developers I've met. IMO, learning a programming language and learning to program to the idiosyncrasies of a non-standard target should be separate issues. A good programmer with a solid grasp of the language (usually) can make the switch - a lousy programmer is lousy on any target. George
From: D Yuniskis on 7 Jun 2010 15:39 Hi George, George Neuner wrote: > On Sun, 06 Jun 2010 13:40:40 +0200, David Brown > <david.brown(a)hesbynett.removethisbit.no> wrote: > >> George Neuner wrote: >>> On Fri, 4 Jun 2010 12:08:28 +0800, "Royston Vasey" <royston(a)vasey.com> >>> wrote: >>> >>> I get that you want to dive into hardware, but you'd really be better >>> off learning the language *before* you try to use it for an embedded >>> project. The problem with C is that it _looks_ simple - the truth is >>> that it will be quite a while before you will be able to write >>> reliable programs. >>> >>> Compilers for small MPUs, DSPs and PICs (the generic "PIC") tend to >>> have non-standard features, weird limitations and just more plain old >>> bugs than compilers for popular desktop OSes. And cross-compiling for >>> an embedded target creates build and test issues that desktop systems >>> don't have. All these things are confusing distractions that you >>> don't need while you're trying to learn a language. >>> >>> There are decent, free compilers available for just about any OS. >>> Except for GCC, most won't be C99 compilers, but any ANSI compiler >>> will do for learning. >> >> I disagree with that advice. > > Your prerogative. > >> Programming C on a "big system" and >> programming C on an embedded system are very different. People who have >> learned C by reading books (or doing courses) and programming on >> Windows, Linux, or whatever, often have a lot of unlearning to do before >> they can write decent embedded software. They'll use "int" everywhere >> with no consideration for the underlying cpu and they'll use floating >> point, memory space, "printf" and "malloc" as though they were as cheap >> as on a PC. They will miss out all understanding of interrupts, >> volatiles, hardware access, resource limitations, etc. > > I don't disagree with anything you're saying, but, in my experience it > is difficult enough for many (maybe most) people to learn programming > _well_ without screwing around with an embedded programming > environment. Yes. There are, too often, quirks/extensions that are present in the tools used for (many) embedded platforms. Sometimes to get around quirks in the processor, sometimes to (ahem) "add value" to the toolchain (read as: tie customer to vendor), etc. > [IMO, many "professional" software developers should find another > profession and the majority of people should never try to write > software ... but those are topics for other threads.] <grin> > Learning is definitely more fun when you can make things light up, > sing, move, etc., but too many of the people I've met who learned to > program by screwing around are also among the worst software > developers I've met. This was particularly true when processors first started seeing use as "logic replacements" many decades ago. Too often, an EE would be assigned the job of writing the code (after all, it *is* an electronic device, eh?). Without any formal training on how to approach this, he'd (eventually) get things to work -- just barely. And, only if you didn't look too hard at them! Can anyone spell "Therac"? > IMO, learning a programming language and learning to program to the > idiosyncrasies of a non-standard target should be separate issues. A > good programmer with a solid grasp of the language (usually) can make > the switch - a lousy programmer is lousy on any target. Agreed. Learn what the language is *intended* to do and then you're in a better position to kick and scream about what the particular toolchain *doesn't* do (or does poorly) -- and you will have a better feel for *why* it had to make those tradeoffs. E.g., write a "genuine" printf() and you can see why many embedded platforms have "itoa()"-ish alternatives! :> [N.B. For yucks, try something like: printf("% 0#*.*g\n", INT_MAX, INT_MAX / 5, PI); assuming I have remembered all the proper flags :-/ ] --don
From: David Brown on 7 Jun 2010 16:39 George Neuner wrote: > On Sun, 06 Jun 2010 13:40:40 +0200, David Brown > <david.brown(a)hesbynett.removethisbit.no> wrote: > >> George Neuner wrote: >>> On Fri, 4 Jun 2010 12:08:28 +0800, "Royston Vasey" <royston(a)vasey.com> >>> wrote: >>> >>>> "Albert van der Horst" <albert(a)spenarnc.xs4all.nl> wrote >>>>> Royston Vasey <royston(a)vasey.com> wrote: >>>>> >>>>>> I'm teaching myself C using Microchip's C18 compiler. >>>>> Although this is c.l.e I would recommend using Turbo C 2.0 to learn >>>>> C. If you can get it. No distraction from the language itself. >>>> Thanks Albert, but I'm using C18 as my objective is to created an embedded >>>> device and the direct route suits me best. >>> I get that you want to dive into hardware, but you'd really be better >>> off learning the language *before* you try to use it for an embedded >>> project. The problem with C is that it _looks_ simple - the truth is >>> that it will be quite a while before you will be able to write >>> reliable programs. >>> >>> Compilers for small MPUs, DSPs and PICs (the generic "PIC") tend to >>> have non-standard features, weird limitations and just more plain old >>> bugs than compilers for popular desktop OSes. And cross-compiling for >>> an embedded target creates build and test issues that desktop systems >>> don't have. All these things are confusing distractions that you >>> don't need while you're trying to learn a language. >>> >>> There are decent, free compilers available for just about any OS. >>> Except for GCC, most won't be C99 compilers, but any ANSI compiler >>> will do for learning. >>> >>> George >> I disagree with that advice. > > Your prerogative. It would be a boring thread if everyone agreed! > >> Programming C on a "big system" and >> programming C on an embedded system are very different. People who have >> learned C by reading books (or doing courses) and programming on >> Windows, Linux, or whatever, often have a lot of unlearning to do before >> they can write decent embedded software. They'll use "int" everywhere >> with no consideration for the underlying cpu and they'll use floating >> point, memory space, "printf" and "malloc" as though they were as cheap >> as on a PC. They will miss out all understanding of interrupts, >> volatiles, hardware access, resource limitations, etc. > > I don't disagree with anything you're saying, but, in my experience it > is difficult enough for many (maybe most) people to learn programming > _well_ without screwing around with an embedded programming > environment. I /almost/ agree with you here. Learning to program should, as you say below, be separate from learning the idiosyncrasies of a particular language, toolset or target. My point of disagreement is that programming on (small) embedded systems is so significantly different from most programming on big systems that I don't think learning on big systems is a help. A clear indication of that is that on big systems, unless you are doing time-critical or low-level programming (not beginners topics), you'd almost certainly use a higher level language than C. You are not too impressed about the quality of most software developers - I agree, and I think it also applies to most books and courses that teach software development. I think the average "teach yourself Visual C++" course/book is worse than useless, especially for someone looking at embedded development. For someone wanting to learn to write good embedded software, I'd recommend starting with assembly. You have to get to understand the low level of your processor. If you want to write C code that will compile into small, fast and efficient target code, you've got to have a feeling of the sort of target code you will get. It doesn't much matter which target you use - learn assembly on "nice" cpu like the AVR or the msp430 rather than a PIC. But you'll have a solid foundation for your skills, rather than forever feeling that your embedded system is a cut-down or limited environment. > [IMO, many "professional" software developers should find another > profession and the majority of people should never try to write > software ... but those are topics for other threads.] > > Learning is definitely more fun when you can make things light up, > sing, move, etc., but too many of the people I've met who learned to > program by screwing around are also among the worst software > developers I've met. > > IMO, learning a programming language and learning to program to the > idiosyncrasies of a non-standard target should be separate issues. A > good programmer with a solid grasp of the language (usually) can make > the switch - a lousy programmer is lousy on any target. > > George
From: George Neuner on 7 Jun 2010 22:09
On Mon, 07 Jun 2010 12:39:54 -0700, D Yuniskis <not.going.to.be(a)seen.com> wrote: >Can anyone spell "Therac"? In my sleep. I once threatened to quit a project when the customer demanded the software monitor solvent tank levels to prevent both running dry and overflow spillage. I demanded hardware interlocks shut down the machine if either situation were imminent. It wasn't that software couldn't handle the situation - it could have easily. The issue was that the solvent was dangerous and I didn't want to have liability in the event of a spill. Also a factor was that this project already needed FDA certification and I didn't want to deal with EPA reviews on top of that. The hardware wasn't my department so all I had to do was write a letter saying there was no software responsibility for solvent handling. George |