Various questions

Thread Starter

atferrari

Joined Jan 6, 2004
4,764
Let me tell in advance that I work with PIC micros (currently 18F family) in Assembly only. Tried to learn C, some 20 years ago and abandoned due to difficulties to understand pointers.

BASIC was part of my approach to these matters with an Timex Sinclair in 1983 and 84. I have no formal (whatever that means) education in Electronics / programming and connected subjects.

Visual Basic, I learnt it but never used in a serious application.

I am 100% selft taught. (And I regret it. Too much time spent in trying/learning with no guidance.)

These are my questions (?) if you like to call them like that:

a) Teams writing C compilers (or whatever high level language for the case) for embedded design are supposed to know the hardware of related micros VERY WELL, probably better than common users. Is it true?

b) Read many times pejorative comments about, GOTO and resulting "spaghetti code" which does not happen with HLLs. (There is an article writen by one of the fathers of C, demolishing the GOTO approach).

May I presume that all the GOTO, BRA and the like, DO exist in the HLL in question, BUT under the hood? The writer of the compiler did the dirty job already. Is it right?

c) In line with b), I've read a comment that the typical MAIN loop used in Assembly doesn't exist in HLLs. May I presume that also here, it is running under the hood again. From my lack of experience I can not see how a micro expecting things to happen could do it if not repeating a minimal list of checks or "waiting" along a string of time slots in a loop. Even more, if it actually has to do repetitive things like updating a display or just blinking a LED.

Program counters basically move on all the times, isn't it?

d) From the beginning I use detailed flowcharts for all my desgins, with increasing levels of detail. (I would no try anything without them).
Using the "bottom" ones, (maximum detail), when I write the respective code, I find myself virtually "translating", line by line, what is detailed in those charts.
Additionally, I convinced my self to comment 99% of the lines. Thanks to that, I can revise code quite easily. Or revisit it, years later with little difficulties. Not to speak about debugging!!.

(The sole case in 20 years I wrote code without them, was this year when studying the 18F4585 for CANbus applications. Initializing the CAN module was simply made following the sequence somewhere outlined in the datasheet.) (It worked in all modes, BTW). :)

Nobody seems to mention that flow chart approach. Is it too "childish"? Do not be affraid of being sincere here.

-------------
Could you please reply following the order of my questions? For my own sanity, I need that.

And please note: This is not an attempt to start another STUPID c / Assembler war (which I hate).

Gracias.
 

Caveman

Joined Apr 15, 2008
471
a) Teams writing C compilers (or whatever high level language for the case) for embedded design are supposed to know the hardware of related micros VERY WELL, probably better than common users. Is it true?
Teas writing good compilers do know the hardware very well. This is because they have to efficiently translate the input high-level code to the assembly language of the particular embedded processor. It is critical that this is done well because of the limited resources (flash and ram space) of embedded systems. If the compiler is not efficient, the designer will have to buy a more expensive part for the same functionality. I once changed compilers and halved my code space! Saved about $1 per unit by going to a processor with less memory. At 100,000 units/yr. (which is what we were selling), that is significant.

b) Read many times pejorative comments about, GOTO and resulting "spaghetti code" which does not happen with HLLs. (There is an article writen by one of the fathers of C, demolishing the GOTO approach).

May I presume that all the GOTO, BRA and the like, DO exist in the HLL in question, BUT under the hood? The writer of the compiler did the dirty job already. Is it right?
You have to separate HLL theory from assembly language. In assembly, GOTO or BRA are needed. The problem in HLL is that you are dealing in a higher logical level. The code is more complex, but good code structure helps us to keep track of it all. goto breaks that structure. The goto that the writer was talking about was the C goto operator.

However, it does exist for a reason. Very rarely, it can be used to actually make code simpler to read. There are no absolutes.
c) In line with b), I've read a comment that the typical MAIN loop used in Assembly doesn't exist in HLLs. May I presume that also here, it is running under the hood again. From my lack of experience I can not see how a micro expecting things to happen could do it if not repeating a minimal list of checks or "waiting" along a string of time slots in a loop. Even more, if it actually has to do repetitive things like updating a display or just blinking a LED.
You are just misinformed here. All embedded systems have an infinite main loop. Sometimes they are hidden under an operating system, but they are always there. It's not under the hood, but directly in C.

Actually, even Windows has an infinite loop for programs that you are running. And it is likely written in C or C++. And Windows itself has a form of infinite loop that the operating system runs.

Program counters basically move on all the times, isn't it?
Yup.

d) From the beginning I use detailed flowcharts for all my desgins, with increasing levels of detail. (I would no try anything without them).
Using the "bottom" ones, (maximum detail), when I write the respective code, I find myself virtually "translating", line by line, what is detailed in those charts.
Additionally, I convinced my self to comment 99% of the lines. Thanks to that, I can revise code quite easily. Or revisit it, years later with little difficulties. Not to speak about debugging!!.

(The sole case in 20 years I wrote code without them, was this year when studying the 18F4585 for CANbus applications. Initializing the CAN module was simply made following the sequence somewhere outlined in the datasheet.) (It worked in all modes, BTW). :)
Flowcharts are just one way of getting straight in your head exactly what you are doing. Or you could write pseudocode which is basically the algorithm you are doing in english. I write so much C that my pseudocode looks like C even when I write assembly code. The higher-level guys use UML to figure out their code, but they are writing on a much grander scale than embedded guys. To understand their point of view, I once mentioned C to one of them, and his response was, "Geez! You may as well write it in assembly!"

As far as which you use, that is up to you. I personally don't use flowcharts because they require too much paper space. Also, I can open a notepad file and pseudocode quickly.

Oh and keep commenting your code. You've already surpassed 60-70% of your peers in that regard.;)
 

Mark44

Joined Nov 26, 2007
628
You have to separate HLL theory from assembly language. In assembly, GOTO or BRA are needed. The problem in HLL is that you are dealing in a higher logical level. The code is more complex, but good code structure helps us to keep track of it all. goto breaks that structure. The goto that the writer was talking about was the C goto operator.
The writer was Edsger Dijkstra, who wrote a paper in 1965, that culminated in a letter to the ACM written in 1968 ("Go to Statement Considered Harmful") by Niklaus Wirth, the creator of Algol-60, Pascal, and Modula-2.

Since C didn't come along until 1972, Dijkstra wasn't talking about goto in that language, but more likely in languages like FORTRAN.
Mark
 

Caveman

Joined Apr 15, 2008
471
The writer was Edsger Dijkstra, who wrote a paper in 1965, that culminated in a letter to the ACM written in 1968 ("Go to Statement Considered Harmful") by Niklaus Wirth, the creator of Algol-60, Pascal, and Modula-2.

Since C didn't come along until 1972, Dijkstra wasn't talking about goto in that language, but more likely in languages like FORTRAN.
Mark
He's not the only one that has stated this, but definitely was the first. In any case, his logic holds for all high level languages. It basically was that goto breaks the structure of the code. That is, it negates one of the primary advantages of high level languages.
 

Mark44

Joined Nov 26, 2007
628
Let me tell in advance that I work with PIC micros (currently 18F family) in Assembly only. Tried to learn C, some 20 years ago and abandoned due to difficulties to understand pointers.
Your comment about C and pointers is very surprising to me, coming from someone who codes in assembler. I don't know anything about PIC assembly--I'm more knowledgeable in x86 assembly--but if you do anything with indirect addressing, you're dealing with what C and some other higher-level languages call pointers. A pointer is nothing more than a variable (or register or memory location) that holds a value that represents the address of some other memory location. You can use the value as-is, or you can dereference that value to get access to that memory location being pointed to.

With regard to high-level languages, C is something of an unusual beast. It was designed in the early 70s (by Brian Kernighan and Dennis Ritchie) primarily to be used to write operating systems. As such, some of its features are more akin to assembly language than to higher-level languages. Some of the statements in C translate pretty much one-for-one to lines of assembly code, such as shifts and boolean ands, ors, and nots. C has been called by many a high-level assembly language for that reason.

Additionally, I convinced my self to comment 99% of the lines. Thanks to that, I can revise code quite easily. Or revisit it, years later with little difficulties. Not to speak about debugging!!.
I hope some of the posters who have asked questions this week about assembly coding are paying attention to what you say!

Hasta luego,
Mark
 

Mark44

Joined Nov 26, 2007
628
I question the statement:
I had thought that Kernighan & Ritchie were so oppressed by the GOTO in interpreted BASIC that they were compelled to develop C.
If so, then why would they include it among the C keywords?

As I said earlier, the primary motivation behind C was to create a language that could be used to write operating systems, including statements that would get down to the hardware more easily. Interpreted BASIC had PEEK and POKE (at least on the Apple II, not sure if it was part of ABASIC or GWBASIC on the IBM PC), but nothing more powerful than those, if memory serves.

With C you could move bytes and such around pretty rapidly using pointers, and read from and write to ports, set and clear individual bits, all of which were difficult or impossible in the various flavors of BASIC.
 

Caveman

Joined Apr 15, 2008
471
goto is definitely included in C. I've heard C described as a language for experienced developers because it gives you just enough rope to hang yourself.
 

Caveman

Joined Apr 15, 2008
471
And the converse works too. You can write good solid structured assembly. (Even with gotos...:p)

However, if you ever read Jack Ganssle's articles, he is a proponent of languages like Ada that apparently limit mechanisms that cause trouble like pointers.

Me, I like pointers. What can I say? I like to live on the edge.
 

Mark44

Joined Nov 26, 2007
628
And the converse works too. You can write good solid structured assembly. (Even with gotos...:p)

However, if you ever read Jack Ganssle's articles, he is a proponent of languages like Ada that apparently limit mechanisms that cause trouble like pointers.

Me, I like pointers. What can I say? I like to live on the edge.
Yeah, I like pointers, too.

Speaking of Ada, I haven't heard much about it lately. Do you know if there is still much code written in it? Back about 12 - 15 years ago, the DoD decreed that any code written under contract (or some significant percentage) "shall be written in Ada." I used to do contract work at Boeing, teaching a class in C to Boeing engineers, so I would hear them talk about it, but I'm not in teaching at all any more. I haven't even heard Ada mentioned in years until this thread, but then I'm out of that loop.
Mark
 

beenthere

Joined Apr 20, 2004
15,819
I think it's still around, but not in the military. I think too many processors came up and there just weren't enough monkeys around to keep writing the compilers. Imagine the committee that had to come up with every possible global variable.

It doesn't get any more fun than working in assembler with an 8 bit system. especially the blank screen that informs you that it's time to write that debugger.
 

Mark44

Joined Nov 26, 2007
628
Reminds me of the Dilbert cartoon where Dilbert and Wally were talking about how it was in the "old days" and Dilbert had to write a word processor using only 1s and 0s. Then Wally one-upped him with, "What? You had 1s? We only had 0s when I started programming!"
 

beenthere

Joined Apr 20, 2004
15,819
Pretty much my case. We literally did not know of computer languages (I was in the Navy). To program, you used the instruction repertoire and wrote machine code on yellow TTY paper. While sitting on a tall stool, you punched the code into the A register, 30 bits at a time, and manually stepped them into core memory - all 32K (77777 octal).
 

Caveman

Joined Apr 15, 2008
471
Writing code on paper is definitely before my time. But I do like the low-level stuff.

My current favorite processor is the PIC10F series. They have 33 instructions, a 2-deep hardware stack, 256 or 512 instruction memory, and 16 or 24 bytes of SRAM. Comes in a 6-pin SOT package. Good stuff!
 
Top