Learn C as a second language?

[RyanLeaf]

Hello,
I am currently learning (or really just begun) Assembly (my first programming language, by the way) and am wondering once I become somewhat good at Assembly, should I start picking up the C language. I know that several languages are based upon it, and I am even planning on doing work in the Objective-C language (i think it's a Macintosh-specific language), which states C as a pre-requisite. Java and C# are also based upon C, which I think means if I learn C I'll have an easier time picking these languages up.

If yes, what are some good resources / books that are useful for a beginner in C.

Thanks,
Ryan Leaf

[Ancient Dragon]

See the Read Me Starting "C" at the top of this board. You posted right over it.

Its good that you are studying assembly language but I would not have picked it as my first programming language because assembly is not considered a good way to program. That is, the language is chucked full of jumps and gotos. You will have to unlearn all that in order to code effectively in any of the higher-level languages. In other words, assembly language teaches you a lot of bad habbits.

The second reason not to learn assembly as a first language is that there are very few people who actually program in that language any more. Most programmers code for years without even seeing any assembly language code.

[Salem]

http://www.daniweb.com/forums/thread122847.html

[jephthah]

i learned assembly years ago as my first language (not counting BASIC, Pascal and Fortran, which i never did anything meaningful with)...

in the early 90's it was important to know Assembly to do embedded programming, because the C compilers for embedded controllers were terribly inefficient -- and expensive if you were a student or hobbyist. the "Assembly is Better" mindset continued even into this decade.

But now the C compilers rock, and only the most specialized apps or processors would ever need such low-level programming.

so, as some one who learned on assembly, and loved all its peculiarities.... I hate to say it... stay away from Assembly if at all possible. at the very least, don't start learning to program on it, for reasons Dragon pointed out already.

do yourself a favor and learn C and learn C++... C is especially suited for microcontroller and embedded work, while C++ in particular will give you the Object-Oriented foundation on which you can expand in any other direction as needed.

dont bother with C# unless you are immediately going to go work in a Microsoft shop. Definitely do not get bogged down in some Macintosh "objective c".... no one uses Macintosh for C programming in the industry, that I've ever seen. i mean, if you want an object-oriented version of C... it's already here: it's called C++. And it's portable to any OS. Vendors reinvent the wheel because they want to lock you into their proprietary hardware or software. don't do it. if you know C++ you can easily pick up C# or "Objective-C" if the need ever arises.

if you learn C you'll always have a skill in high demand. if you learn C++ you'll have the additional benefit of understanding Object-Oriented programming, and can take that knowledge and apply it to any number of languages, such as C# and Java, and can likely get hired based on your C++ background even if you dont have the specific OO language they prefer.

.

[Ancient Dragon]

i learned assembly years ago as my first language (not counting BASIC, Pascal and Fortran, which i never did anything meaningful with)...

That is a big contridictory sentence :) Assembly could not have been your first language if you had learned others prior to that.

[Ancient Dragon]

I think the only people who write in assembly to day are either 1) compiler writers, or 2) program EPROMs.

[jephthah]

i should have qualified "assembly was the first language in which i did any meaningful work" ... i just played with the others. Basic/Pascal/Fortran are, for all intents and purposes, completely useless languages -- unless you're an Excel Programmer (Basic) or a Nuclear Engineer (Fortran)

...

i was going to say that i program eeproms using C... if driving external hardware to manipulate data bit-by-bit, counts... probably not. i guess you've still got to understand basics of low level assembly programming.

but that should all be secondary to first learning the higher level languages like C/C++ ... assembly should come later.

.

[Colin Mac]

Microcontrollers are mainly programmed in assembly still. C has advantages when it comes to things like decision making. Assembly has advantages when you need precise delays. Other times, the program would just end up one liner C statements anyway, so there isn't much point.

[jephthah]

im not sure what kind of microcontrollers you mean, but the ones i deal with ... scientific instrumentation and medical products ... are all programmed in C.

now there's always an occasional macro in assembly, but they're short and sweet, and few and far between.

assembly programming is a rare skill these days, because the demand is but a fraction of what it was 10 or 15 years ago.

[Colin Mac]

The most popular ones such as PICs and 8051 derivatives are mainly programmed in assembly.

[jephthah]

PICs and 8051 derivatives are mainly programmed in assembly.

i dont mean to keep carrying this off into a tangent, but that's just plain not true

8051 derivatives have been being programmed in C as far back as 15 years ago, starting with the old Keil compiler. and thats just as far back as I remember.

sure, there are still sunday-afternoon hobbyists and students in poorly-funded classrooms who may program blinking-LED projects for their PIC's in assembly

but as far as industry goes... tons of embedded apps use PICs, 8051s and similar GP controllers in complex applications ... and it would be absolute *suicide* for any competitive company to try and program them in Assembly. you'd never get your product to market in any reasonable time, and maintenance would be cost-prohibitive

think about it, when a C compiler costs a few hundred dollars, what kind of business would be crazy enough to pay the manhours required for a staff of assembly coders?

look im not saying there arent any Assembly coders out there gainfully employed. but they're the exception, not the rule. the majority of assembly you see these days are short little macros, sparsely placed

[Colin Mac]

When debugging embedded systems, logic analyzers display timing diagrams, hex or in the good ones asm code. Sometimes you need to check your hex file for errors. Sometimes you need to create delays based on how may machines cycles an instruction takes. My point is you can't be a good programmer using those chips with out knowing the instruction set and those programmers can't keep asm in the back of their minds like desktop programmers can.

When writing a program, the question is still should/can the program be coded in a language other than the processor's native one, though the answer is usually yes. Even so, the programmer still thinks about what the uC is doing at the machine level. It makes no odds if 3/4 of your micro program is going to be C expressions like port1 = 0; as opposed to assembly lines
like mov port1, 0. It doesn't matter if you're a student blinking leds or a hired programmer writing a program to control the led display in your microwave.

[Colin Mac]

Lastly, my brother programs PICs as part of his job. I hang out in micro forums and see nothing but assembly code. To be fair I don't know if assembly is used more, I just have reason to believe so.
It's just this comment I take exception to.

"in the early 90's it was important to know Assembly to do embedded programming"

because it's false to think it still isn't true regardless of what language is used.
Learning the hardware and learning the instruction set are one in the same.

[jephthah]

okay, i agree with you on what i think are your points:

(1) there are still some people, somewhere, doing meaningful work in assembly.
(2) programming microcontrollers does require some "understanding" of how it works at the assembly level (but NOT for programming entire functions in assembly)
(3) there will always be a need for the occasional macros, such as precision timing, to be coded in assembly

but the point im trying to make, relative to the OP's question on which language to learn, is that

Assembly should be learned only after you have a solid command of the C and C++ fundamentals.

because, unlike 15 years ago, C compilers today produce highly efficient machine code for embedded microcontrollers in a way that has made 95% of the Assembly programmers and their arcane bag of tricks completely redundant.

the beginner will get the most return on their investment by learning C and C++. ... virtually no one hires entry-level assembly programmers. they do hire entry level C and C++ programmers. so learn to crawl, walk, and run before you learn to fly.

another very important thing Dragon noted earlier, is that if you learn Assembly first, you have to UNLEARN all those techniques that are useful only in Assembly, and make horrible, horrible practice for C and C++ ... like the heavy use of jumps and gotos, for instance.

.

[Colin Mac]

I don't disagree if x86 assembly is the question. I don't see many reasons other than interest why people program those animals in assembly.

[hammerhead]

I have to agree with jephthah, I have programmed AVR and 8051 both in C. Though there is option to program in assembly but when sometimes it becomes difficult to learn the instruction set especially if you want to program many microcontrollers.

Furthermore, in the end both the assembly and the C code gets converted to .hex or .eeprom that is used to burn onto the microcontroller and I dont think it makes much of a differenc on what language you code(correct me if I am wrong).

[Colin Mac]

I have to agree with jephthah, I have programmed AVR and 8051 both in C.

You agree we can be serious 8051 programmers and not ever learn the instruction set? If so, could you explain how to create a delay of exactly 20us in Keil C for the 8051, if my two timers are already used?

Furthermore, in the end both the assembly and the C code gets converted to .hex or .eeprom that is used to burn onto the microcontroller and I dont think it makes much of a differenc on what language you code(correct me if I am wrong).

Sure. It wouldn't be a C compiler if it didn't convert the source to object code.

[jephthah]

look... the QUESTION that the original poster asks is, essentially, should he learn Assembly or should he learn C.

I'm saying this:

you can be a good C/C++ programmer, and do a lot of "real" work -- embedded or otherwise -- without having to know the deep dirty secrets of Assembly programming

Contrariwise, you can NOT just be a good Assembly programmer, and reasonably expect to do any meaningful projects in the real world, without having solid C skills.

C is therefore *primary* to Assembly and should be emphasized with prejudice over Assembly.

15 years ago (maybe even 10) the world was a different place. You could still argue the primacy of assembly over C for embedded. But the world has changed, and the changing technology of C compilers has caused a complete paradigm shift.

you can either move along with the change or get left behind.

so my advice to beginners is: learn C now, worry about assembly later. And this is coming from someone who learned (and loved) assembly first.

that is all.

.

[hammerhead]

You agree we can be serious 8051 programmers and not ever learn the instruction set? If so, could you explain how to create a delay of exactly 20us in Keil C for the 8051, if my two timers are already used?

Perhaps I did not make my statement clearly. I agree with jephthah that assembly should be learned after C/C++ . I dont have much experience at microcontroller programming but I did try my hand at both assembly and C and found C more comfortable.

Perhaps at later stages I will need to use assembly, but surely my first priority would be solving the problem in C. I will answer your first question after I have acquired considerable experience.

[jephthah]

could you explain how to create a delay of exactly 20us in Keil C for the 8051, if my two timers are already used?

you cut-and-paste a teeny-tiny little delay macro that already exists in a million places on various 8051 boards, tweaking it if necessary.

as for the remaining 99.9% of your embedded code, you continue programming in C.

that's how you do it.

what you DON'T do, is become an Assembly Guru and learn every deprecated assembly programming technique from the early 1990's.

[Colin Mac]

look... the QUESTION that the original poster asks is, essentially, should he learn Assembly or should he learn C.

We've establised he would be better off learning C. I've wen't one step further and gave my
opinion there isn't much point in learning assembly, unless you're interested providing we're talking about
a desktop environment. The thread went off topic when embedded systems were mentioned, in my opinion, seeing as the OP never mentioned them, and the fact that learning x86 asm isn't related to becoming
an embedded systems programmer.

I'm saying this:
you can be a good C/C++ programmer, and do a lot of "real" work -- embedded or otherwise -- without having to know the deep dirty secrets of Assembly programming

I know what you're saying. The statement is so vague though, you may be possibly correct, depending on the environment in which the programmer is placed. I'm saying though, if someone's hands you an 8051 or PIC, you're going to need more knowledge than C if you wish to make it do something useful.

Contrariwise, you can NOT just be a good Assembly programmer, and reasonably expect to do any meaningful projects in the real world,

Again vague. If it's x86 assembly, I totally agree. If it's assembly for an 8-bit/16-bit microcontroller, my brother for one would disagree. He works
for a TV company and writes PIC assembly programs to send commands around his studio.
The PIC has 35 instructions, the programs are small, he doesn't need to use a HLL.

you cut-and-paste a teeny-tiny little delay macro that already exists in a million places on various 8051 boards, tweaking it if necessary.
as for the remaining 99.9% of your embedded code, you continue programming in C.
that's how you do it.

You'd say that in an interview? What you really do, is use inline assembly
and your knowledge.

You have a hex file, you need to check the opcodes to see if the program is correct before you download it to the chip?
You're using a logic analyzer, assembly mnemonics are popping up on the screen.
They need to be interpreted? (keeping in mind logic analyzers are extensively used).

But I'll leave it there.

[sDJh]

I also learned Assembly years before I started really using C. C is still for me the language that I struggle most with. What I don't like about C is:
- type-casting
- pointers
- platform specific code
These three points are much, much easier in ASM, because the assembler doesn't restrict any casts. A value is a value and the programmer decides what to do with it.

I'm also working with microcontrollers (ATMEL). When writing normal codes (loops, conditions, output) I always use assembly, because I'm much quicker than in C. Even my friends who are all working in C are not faster than I am.

And I don't feel like an old animal =).

[jephthah]

i'm glad it works for you, but those aren't good arguments.

okay, YOU may be (or think you may be) faster, but may the gods help the poor slobs who have to go behind you after you leave your job. what typically happens in these circumstances, is maintainers hack at your original code for a while, then eventually it's thrown away and rewritten from scratch in a language the rest of the world understands.

two other observations I'd suggest may be applicable:

(1) IMO, the reason why you "struggle" so much with concepts in C is exactly related to the fact that you learned Assembly first, and now have issues (emotional, mostly) in trying to unlearn those habits that lend themselves so poorly to higher-level languages.

(2) I'd also say your perception of relative speed is either invalid or is an isolated case. All other things being equal, C programmers are necessarily faster than Assembly programmers... so I'd suggest that one or more might be the case here: (a) your friends kind of suck (b) you're something of a demigod among men (c) the applications you're writing are out there in the ~1% periphery where Assembly really might be a better choice ....

.

[Colin Mac]

The question in relation to uCs is answered here if you're interested.
http://www.electro-tech-online.com/micro-controllers/25846-best-programming-language.html?highlight=assembly