Get started with C programming

[97hilfel]

Hello everybody,
I'm currently in my final highschool year (in Italy so don't comare it directly to USA or somewhere else).
I wanted to learn how to program on microcontrolers last year in school we learned to program Assamby and a little bit Arduino,
but I want to learn real C.
Currently I'm working on a project and using a Atmel SAM D20 and I'm currently stuck with programming, because I can program but I don't know how to programm efficently on controllers.
I hope somebody can help me.
Felix

[ataradov]

but I don't know how to programm efficently on controllers.

That is something you will have to learn over time, there is not a single piece of advice that can help.

My recommendation is to not use manufacturer libraries (ASF in case of Atmel) and program MCU directly. It is more work upfront, but greater benefit in a long run.

I have a number of very simple starter projects (D20 included) here https://github.com/ataradov/mcu-starter-projects

You can take that and expand it as you need.

[97hilfel]

Well, I still need to get into C programing because Im used to C# on a pc where it doesn't matter how much memory you use (till you be under 2gb)


Gesendet von iPhone mit Tapatalk

[ataradov]

Well, I still need to get into C programing because Im used to C# on a pc where it doesn't matter how much memory you use (till you be under 2gb)

That's easy. Just start with whatever you were doing in C# and you will be forced to come up with better solutions, since your stuff won't fit into the device.

But really, it is not that bad. On the MCU you are limited by the hardware you have, so it is reasonably easy to account for all the things that are consuming memory. In a typical project there will be very few big consumers (like buffers) and it is easy to  calculate memory requirements upfront. Most projects are not that critical to memory and the main constraint is a CPU performance.

There is not much you can do, but start doing things and optimizing as you go.

[MK14]

Hello everybody,
I'm currently in my final highschool year (in Italy so don't comare it directly to USA or somewhere else).
I wanted to learn how to program on microcontrolers last year in school we learned to program Assamby and a little bit Arduino,
but I want to learn real C.
Currently I'm working on a project and using a Atmel SAM D20 and I'm currently stuck with programming, because I can program but I don't know how to programm efficently on controllers.
I hope somebody can help me.
Felix

There are a lot of C program resources on the internet, including many free book(often PDF) downloads.

Some are even Embedded/Microcontroller C

Such as this one:

http://learn.mikroe.com/ebooks/piccprogramming/front-matter/introduction/

http://freecomputerbooks.com/langCBooks.html

Google can be good for finding them.

[RobertGogol]

I would recommend what I did:
Learn C++ specific to program and understand 8bit AVR MCU - most important thing, even more important than learning C++ is how to compile program and upload it to MCU using programmer like simple and cheap Fishl USB - I mean leaving proto board and use standalone MCU with your own projects. It is hard at the beginning (especially working with compiler and AVRdude from... command line) but everything is explained here, and it is cheap and easy:
http://hackaday.com/2010/10/23/avr-programming-introduction/

and first blinking LED on breadboard with atmega16 is so beautifull!!
I've looked at mine over hours
Good luck!

[MSO]

Learning C is one of the most beneficial things you can do for your career. Don't let anyone tell you that it's inefficient or that assembly will run rings around a C program; that's false, even when writing firmware.  A good C complier can produce much better code than even the best assembly language programmers. When it comes to highly optimized code and near universal availability, from the smallest MCU to the largest mainframe computers, no other language comes close. (With the possible exception of C++.)

Pickup a copy of "The C Programming Language" by Brian W. Kernighan & Dennis M. Ritchie and read it from cover to cover, twice. Pay special attention to the difference between the C language itself and its compilers and libraries. Don't, as many new to the language are wont to do, confuse the C language with its compilers and its libraries; the latter two can vary substantially in quality and efficiency but can easily be replaced with better implementation fro different vendors.

http://www.amazon.com/The-Programming-Language-Brian-Kernighan/dp/0131103628

Good luck with your new venture.

[dannyf]

I don't know how to programm efficently on controllers.

The biggest lesson I have learned over the years is to code with a goal to never code it again: whenever you write a piece of code, always think about how you can write it so that it can be reused later for a different project.

To do that, you will need to write modular code; code with well defined inputs and outputs; code that's well debugged, etc. In the end, you learn a lot more than just coding.

[nctnico]

I'd start with programming C and C++ on a PC because it is much easier to test and debug code on a PC. A good excersize is to create a module which emulates the hardware (for example reading data from a file and the results to a file) and a module which is your microcontroller's firmware. This isn't sexy but it is a good step towards unit testing your firmware.

[rx8pilot]

I'd start with programming C and C++ on a PC because it is much easier to test and debug code on a PC. A good excersize is to create a module which emulates the hardware (for example reading data from a file and the results to a file) and a module which is your microcontroller's firmware. This isn't sexy but it is a good step towards unit testing your firmware.

+1

Sent from my horrible mobile....

[Jeroen3]

I don't know how to programm efficently on controllers.

The biggest lesson I have learned over the years is to code with a goal to never code it again: whenever you write a piece of code, always think about how you can write it so that it can be reused later for a different project.

This. The amount of people that blob some code into a single file, pray for it to work, and never look at it again. Is way too high.
The code becomes unmaintainable and only the original writer can make something of it for the next ~2 months.
Any time later it will be cheaper to just start over. Hours are not free.

But to learn code there is only 1 thing you can do: Read code. Other peoples code.
Find reputable C libraries and project, and read the code. See what they are doing, recognize the architecture.

[Brutte]

I'd start with programming C and C++ on a PC

+1

Sent from my horrible mobile....

+2
Sent from my bathroom....

[Karel]

My advice: Forget the crap they call C++ and stick with plain C only.

And buy this book: http://shop.oreilly.com/product/0636920033844.do

And no, I'm not going to let me drag into a C vs. C++ flamewar so I'm not going to explain why C is so much better than C++ (for MCU's).

[Philfreeze]

Well, to learn the C langugage there is only one "true" guide written by one of the creators of C (Ritchie) and prof. Kernighan.
http://www.ime.usp.br/~pf/Kernighan-Ritchie/C-Programming-Ebook.pdf

[legacy]

I sugget to be focused on "design" instead of C coding

[ElektroQuark]

About original work of K&R, don't do C evolve a bit?
Is the K&R book up to date?

 

[97hilfel]

A good C complier can produce much better code than even the best assembly language programmers. When it comes to highly optimized code and near universal availability, from the smallest MCU to the largest mainframe computers, no other language comes close. (With the possible exception of C++.)

Good luck with your new venture.

Well I can program assambly Inlearned it on a AW32 Freescale controller and I hated it... Because you can't implement much in assamby code and can do a lot of errors... I will read trough the rest of the awnsers later after school


Gesendet von iPhone mit Tapatalk

[Philfreeze]

About original work of K&R, don't do C evolve a bit?
Is the K&R book up to date?

It evolved a bit but the the "big" new thing you will have to learn on top of K&R is the whole embedded stuff (register access, interrupts etc.)

[nctnico]

My advice: Forget the crap they call C++ and stick with plain C only.

Noooooo! C++ is the next 'big thing' for microcontrollers because C++ allows to circumvent the parts of C which are so error prone: pointers and you can put an entire module in it's own class so there is much less worry about name clashes with other modules. Also the ability to have fine grained control over which parts of the code can touch which variables is worth a lot because it makes code more predictable. Forget whatever negative is being said about C++ because it is either not true or not a problem in the real world. After all C++ works just fine.

[97hilfel]

Well guys, I don't want to learn Cpp now, I don't even like that language, I got a 1500 page thick book in my bookshelf which I bought for 50 bucks because I taught that Cpp would be the "only way" to write goog PC programms, bit C# does the job... Cpp is way to high for me and currently the market for C programmers (I don't want to programm to earn my money I want ro design PCB) is bigger and C is a bit more universal on small controllers so I do like to start with it. Let the flamwar c vs cpp beginn!
Thanks to everybody who helped me!


Gesendet von iPhone mit Tapatalk

[97hilfel]

And what Im going to do these days:
Finish the asf program and grab my atmega 328PU and code on it a bit (got some of them lying around for my Arduino uno)


Gesendet von iPhone mit Tapatalk

[Dielectric]

I've been writing C for a couple of decades now, and still found this to be helpful when I found it last year:
http://c.learncodethehardway.org/book/

It's a pretty badass way to learn C, and he pulls no punches about how C can really screw you over.

I'm also implementing many of the ideas from Patterns in C:

https://leanpub.com/patternsinc

Having a structured way to attack a problem set is awesome, because IF you're diligent about the implementation, you can come back to it later and understand what you were thinking at the time.  Very important!  I find that a lot of the ideas pulled from OO languages are really useful in C, like function pointers and structures.  There are some pretty good arguments for using C++ for embedded programming (great interview on embedded.fm's podcast, episode 137 with Dan Saks):

http://embedded.fm/episodes/137

Having said that, I actually don't know C++ and have only done a tiny bit of Java and Objective C so I could be totally snowed over and wrong.

[rsjsouza]

I am usually a learner by example, therefore the approach I would take is:

Start with something step-by-step such as:
https://github.com/sagarsp/arduino-blink-c
https://balau82.wordpress.com/arduino-in-c/

Once you have something running you can start understand its functionality, compare its structure with one of the books you bought, exploring and experimenting with it.

BTW, if you don't have a Linux machine and have the bandwidth, you can download VirtualBox and one of the pre-configured images from here. Or download VirtualBox and create your own.

[legacy]

highschool year (in Italy

"ITIS"?
if so, { electronics, telecom, computer science } ?

[97hilfel]

"ITIS"?
if so, { electronics, telecom, computer science } ?

Electronics...


Gesendet von iPhone mit Tapatalk

[Armxnian]

Real men code in binary.

[MK14]

Well guys, I don't want to learn Cpp now, I don't even like that language, I got a 1500 page thick book in my bookshelf which I bought for 50 bucks because I taught that Cpp would be the "only way" to write goog PC programms, bit C# does the job... Cpp is way to high for me and currently the market for C programmers (I don't want to programm to earn my money I want ro design PCB) is bigger and C is a bit more universal on small controllers so I do like to start with it. Let the flamwar c vs cpp beginn!
Thanks to everybody who helped me!


Gesendet von iPhone mit Tapatalk

If it is a relatively weak MCU, with limited RAM size (not that much), a lone programmer, and not that big a task for the MCU to do, in terms of size, complexity and other stuff. Then C, can be considered the best tool, in that situation, by many.

But if it is a massively (overpowered) MCU, with huge amounts of RAM, in an extremely complicated embedded/electronics environment, with hugely complicated and multi-layered network/database communications protocols and storage control systems. Programmed by a HUGE, world wide team, over a VERY long period of time.
Then C++ is then considered as showing significant advantages, by many.

In between, there are all sorts of factors that can be taken into consideration, to help choose between the C or C++.

Don't forget that if you become VERY experienced in programming with C. It is NOT that much of a task, to upgrade yourself to C++. Whether that involves course(s), books, self-taught, etc etc. Is up to you.

If you became very competent and experienced in BOTH C and C++ (Cpp), you would have a tremendous range of jobs. Because you could go for C OR C++ ones.

[MK14]

Real men code in binary.

The trinary patch cords, for my quad Valve/tube, Circa 1941 computer, does NOT count then!

[Boomerang]

A good C complier can produce much better code than even the best assembly language programmers.

No chance. Many many years must pass before people become so dumb and compilers become so intelligent to outperform them... 

[Armxnian]

The trinary patch cords, for my quad Valve/tube, Circa 1941 computer, does NOT count then!

Hmm 1941... seems hardcore enough. I'll let it pass.

[MK14]

A good C complier can produce much better code than even the best assembly language programmers.

No chance. Many many years must pass before people become so dumb and compilers become so intelligent to outperform them... 

+1
As I understand the situation, it's a common myth, that I often hear.

Analogy: if a normal (non-racing) driver, drove their normal car on a very high speed test track. They can probably achieve much faster track times, than when they drive a formula 1 car, and end up spinning out of control all over the place, and messing up the driving completely. Hence achieving a considerably longer track time.

This does NOT mean that their car is considerably faster than a formula 1 car.

It just means they needed to get the stig or a competent formula 1 racing driver to drive it. Then the Formula 1 car will have a considerably better track time.

So yes, I agree that hopeless assembly language programmers, can mess up the programming so badly, that even a C compiler can beat their code.

But just like the stig or a good racing driver, a "real" quality assembly language programmer, can achieve very good results.

I'm NOT sure how much faster a modern day, quality assembly language programmer, could/would beat a good C compiler.

I'd love to know, but don't really have the time to try it (I'd have a partial learning curve as well, maybe eventually), and it is very difficult to get the right people to try it out.

[Karel]

But if it is a massively (overpowered) MCU, with huge amounts of RAM, in an extremely complicated embedded/electronics environment, with hugely complicated and multi-layered network/database communications protocols and storage control systems. Programmed by a HUGE, world wide team, over a VERY long period of time.
Then C++ is then considered as showing significant advantages, by many.

You mean something like the Linux kernel?

[nctnico]

But if it is a massively (overpowered) MCU, with huge amounts of RAM, in an extremely complicated embedded/electronics environment, with hugely complicated and multi-layered network/database communications protocols and storage control systems. Programmed by a HUGE, world wide team, over a VERY long period of time.
Then C++ is then considered as showing significant advantages, by many.

You mean something like the Linux kernel?

Actually the whole Linux kernel is object oriented programming emulated in C. The Linux kernel is the biggest mess I have ever seen and a prime example why you should program object oriented programs (large projects) in C++. If they rewrite the Linux kernel in C++ it will be faster, smaller (both code and binary), less buggy and easier to maintain.

[MK14]

But if it is a massively (overpowered) MCU, with huge amounts of RAM, in an extremely complicated embedded/electronics environment, with hugely complicated and multi-layered network/database communications protocols and storage control systems. Programmed by a HUGE, world wide team, over a VERY long period of time.
Then C++ is then considered as showing significant advantages, by many.

You mean something like the Linux kernel?

Then why bother using C++? Let's use Python, Ruby or Node.js.

There are lots of potentially good languages. But some of the scripting (interpreted) ones, can be rather inefficient at their cpu processing time consumption. But it gets complicated with languages like Java, or others, when they use JIT and stuff, because that can compile it on the fly, to be approaching or maybe even faster (because of late, run time compiling, knowing what is going on), than even compiled C/C++ code.

Anyway, cpus have become so fast that scripting (interpreted) languages, don't matter that much, these days. (For 80/90%+ of software it is good enough (scripting). There are still many things which need/require the full cpu speed, available on properly compiled languages, such as C/C++ and Pascal etc).

It's kind of ironic, that C was a big part of the early (in recent times), computing history. It even still drives much of the internet, at the lowest level.

But most website languages, are NOT C or C++. In fact to use C/C++ to make a website, is not that straight forward.

C/C++ was originally designed at a time, when the internet was NOT known about, or even much predicted. Consequently, C/C++ lacks features to help website/browser/mobile-apps etc. I feel a bit sad for C/C++ in that respect.

E.g. Android phones (when I last checked), much prefer Java to C/C++. Unless you root the phone.

[Howardlong]

My advice: Forget the crap they call C++ and stick with plain C only.

Noooooo! C++ is the next 'big thing' for microcontrollers because C++ allows to circumvent the parts of C which are so error prone: pointers and you can put an entire module in it's own class so there is much less worry about name clashes with other modules. Also the ability to have fine grained control over which parts of the code can touch which variables is worth a lot because it makes code more predictable. Forget whatever negative is being said about C++ because it is either not true or not a problem in the real world. After all C++ works just fine.

The namespace thing certainly has value, but it's all the other nonsense that concerns me: the more things are abstracted, the slower and more bloated things get. Most programmers fresh out of college nowadays have a big disconnect between the code they write and how it works under the hood. The beauty of C in embedded terms is that you're always close to the metal, things tend to be fairly explicit.

Although learning the basics on a PC is a reasonable start, at the same time it should be noted that it's not the same. In particular, you have to be pretty careful about using standard library functions, they are often inappropriate on resource limited embedded platforms. printf, for example, can be quite the beast, and that's generally the first bit of code a C programmer would write on a PC platform.

[legacy]

But if it is a massively (overpowered) MCU, with huge amounts of RAM, in an extremely complicated embedded/electronics environment, with hugely complicated and multi-layered network/database communications protocols and storage control systems. Programmed by a HUGE, world wide team, over a VERY long period of time.
Then C++ is then considered as showing significant advantages, by many.

You mean something like the Linux kernel?

Actually the whole Linux kernel is object oriented programming emulated in C. The Linux kernel is the biggest mess I have ever seen and a prime example why you should program object oriented programs (large projects) in C++. If they rewrite the Linux kernel in C++ it will be faster, smaller (both code and binary), less buggy and easier to maintain.

I agree

[Philfreeze]

Actually the whole Linux kernel is object oriented programming emulated in C. The Linux kernel is the biggest mess I have ever seen and a prime example why you should program object oriented programs (large projects) in C++. If they rewrite the Linux kernel in C++ it will be faster, smaller (both code and binary), less buggy and easier to maintain.

There i fixed it for you.
Just an assumption but I don't think it will be faster or smaller but definetly much much easier to maintain. They should do it though because the speed you lose and the size you gain will be absolutely minimal but it would be much easier to maintain.

[nctnico]

My advice: Forget the crap they call C++ and stick with plain C only.

Noooooo! C++ is the next 'big thing' for microcontrollers because C++ allows to circumvent the parts of C which are so error prone: pointers and you can put an entire module in it's own class so there is much less worry about name clashes with other modules. Also the ability to have fine grained control over which parts of the code can touch which variables is worth a lot because it makes code more predictable. Forget whatever negative is being said about C++ because it is either not true or not a problem in the real world. After all C++ works just fine.

The namespace thing certainly has value, but it's all the other nonsense that concerns me: the more things are abstracted, the slower and more bloated things get. Most programmers fresh out of college nowadays have a big disconnect between the code they write and how it works under the hood. The beauty of C in embedded terms is that you're always close to the metal, things tend to be fairly explicit.

At some point you have to take a look under the hood to see what is creating a lot of code but a C++ class is nothing more than a struct with data elements and functions pointers. All in all it is very efficient and does not contain any nonsense. It is a lot like the assembly versus C debates. People think C is more bloated because they don't know what is happening under the hood and assume the worse based on their fear of change.

Although learning the basics on a PC is a reasonable start, at the same time it should be noted that it's not the same. In particular, you have to be pretty careful about using standard library functions, they are often inappropriate on resource limited embedded platforms. printf, for example, can be quite the beast, and that's generally the first bit of code a C programmer would write on a PC platform.

The concerns about standard library functions is completely unfounded. In order to re-use code one should try to use the standard library functions (POSIX) as much as possible. For embedded platforms there are lightweight libraries. C was developed on very space constrained machines so the API of the standard library functions is very much tailored to keep the memory requirements to a minimum Also keep using printf! The mistake I often see is that people are trying to create their own convoluted string printing functions and while doing so they sooner or later link the printf core in as well besides their own crap functions. If the printf core is too big then the best way around it is to create a minimal printf function which is compatible with the normal printf but can be tailored to your needs if necessary.

Actually the whole Linux kernel is object oriented programming emulated in C. The Linux kernel is the biggest mess I have ever seen and a prime example why you should program object oriented programs (large projects) in C++. If they rewrite the Linux kernel in C++ it will be faster, smaller (both code and binary), less buggy and easier to maintain.

There i fixed it for you.
Just an assumption but I don't think it will be faster or smaller but definetly much much easier to maintain. They should do it though because the speed you lose and the size you gain will be absolutely minimal but it would be much easier to maintain.

I have done quite a bit of hacking in the Linux kernel and there are many places where a compiler would be able to optimise a lot in terms of speed. In many places in the Linux kernel you need to go several stages deep into children/parents in runtime to get to certain information even though that information can be obtained at compile time.

[MK14]

There are lots of potentially good languages. But some of the scripting (interpreted) ones, can be rather inefficient at their cpu processing time consumption. But it gets complicated with languages like Java, or others, when they use JIT and stuff, because that can compile it on the fly, to be approaching or maybe even faster (because of late, run time compiling, knowing what is going on), than even compiled C/C++ code.

That's why I say it is possible to use script languages. I'm a big fan of JIT. I'm now working on a finite element engine that is supposed to support user expression input, and apparently it is not appropriate to run a string expression evaluation program in each iteration on each dynamic material of each meshed unit. Also, this allows me to implement AVX or SSE whenever these extensions are available without forcing the users to know how to program on SIMD. I can not imagine how slow the program is if I did not use JIT (actually bytecode based solution is kinda okay also, but string parsing is just plain horrible), despite I have to say writing a JIT compiler, even only for math expressions, is not easy.

You'd probably find if you write more JIT compiler sub-sections. You would find it gets much quicker and easier each time (hopefully, your mileage may vary).
I'm wondering how good AVX-512 is going to be (ignoring Knights based computers), when it eventually surfaces. Then an even longer wait until it comes to mainstream, I7 etc cpus. (if at all, depending on how Intel are planning on doing things).

Yes, that is an amazing use of JIT. Just the sort of thing, which would give a HUGE speed up factor.

Essentially a typical C/C++ program would re-interpret it each pass. Potentially taking ages. But a high/top end C/C++ programmer, may have ideas, to significantly speed up that process, WITHOUT JIT.
E.g. to translate the reg ex (etc), into what amounts to a large look-up table of function pointers.

So Pass1 (When the C/C++) runs, would interpret the reg-ex into array(s) of function pointers, and stuff.
Then on pass2..etc, the C/C++ can directly access the already interpreted reg-ex, by calling the array of function pointers, directly.

There are other ways of doing it, fast. I may NOT know enough about the specifics of what you are doing, to correctly describe a very fast non-JIT solution. So my apologies in advance. I could easily be misunderstanding your requirements.

There are often/usually MANY ways of doing things quickly and efficiently.

There have been Basic (language) interpreters, which do a similar thing. I.e. as they run through the code (interpreting it), it remembers what it needs to do. So after it has run for a while, it considerably speeds up, as it mostly ignores the source code, and directly does what it needed to do, directly. If I remember correctly, I think it went as far as remembering the actual machine code to perform, for each line. If I'm mistaken then it was a JVM (bytecode) like (p-code), mechanism instead.

BUT I have to concede that if your JIT solution, means that it goes to SSE/AVX/AVX2 (or whatever). It could still potentially beat even a fairly well written C/C++ program. The array of function pointers, is probably significantly slower than JIT compiled code, as the JIT can just put the desired/needed instructions, straight into the new code.

So on second thoughts, this JIT thing, could still be a dramatic speed/efficiency improvement.

[MK14]

You'd probably find if you write more JIT compiler sub-sections. You would find it gets much quicker and easier each time (hopefully, your mileage may vary).
I'm wondering how good AVX-512 is going to be (ignoring Knights based computers), when it eventually surfaces. Then an even longer wait until it comes to mainstream, I7 etc cpus. (if at all, depending on how Intel are planning on doing things).

Yes, that is an amazing use of JIT. Just the sort of thing, which would give a HUGE speed up factor.

Essentially a typical C/C++ program would re-interpret it each pass. Potentially taking ages. But a thigh/top end C/C++ programmer, may have ideas, to significantly speed up that process, WITHOUT JIT.
E.g. to translate the reg ex (etc), into what amounts to a large look-up table of function pointers.

So Pass1 (When the C/C++) runs, would interpret the reg-ex into array(s) of function pointers, and stuff.
Then on pass2..etc, the C/C++ can directly access the already interpreted reg-ex, by calling the array of function pointers, directly.

There are other ways of doing it, fast. I may NOT know enough about the specifics of what you are doing, to correctly describe a very fast non-JIT solution. So my apologies in advance. I could easily be misunderstanding your requirements.

There are often/usually MANY ways of doing things quickly and efficiently.

There have been Basic (language) interpreters, which do a similar thing. I.e. as they run through the code (interpreting it), it remembers what it needs to do. So after it has run for a while, it considerably speeds up, as it mostly ignores the source code, and directly does what it needed to do, directly. If I remember correctly, I think it went as far as remembering the actual machine code to perform, for each line. If I'm mistaken then is was a JVM (bytecode) like (p-code), mechanism instead.

BUT I have to concede that if your JIT solution, means that it goes to SSE/AVX/AVX2 (or whatever). It could still potentially beat even a fairly well written C/C++ program. The array of function pointers, is probably significantly slower than JIT compiled code, as the JIT can just put the desired/needed instructions, straight into the new code.

So on second thoughts, this JIT thing, could still be a dramatic speed/efficiency improvement.

So far the speed is not good -- marginally better than bytecode based solution, because I do memory access on every object at every time (tons of MOV and LEA) -- no optimum register allocation for reusing, I essentially used only few registers to do basic calculations. Memory structure of meshed objects are scalar objects, so they got packed and unpacked in each iteration, and since I'm very unfamiliar with SIMD, I'm only trying to use most basic SSE. On the other hand, GCC managed to optimize my bytecode executing routine well, and since it takes in several objects in and several out, it even manages to auto vectorize my code (of course with lots of assumptions and alignment directives).

I think I need to learn much more in compilers, but maybe not now -- I'm not doing research on compilers at all. I'm pursuing my PhD in power electronic packaging technique, and the only purpose of this simulator is to get me access to FEA tool without having to use out COMSOL workstation.

I have heard that the JIT, and especially JVM, takes ages to sort it self out (while it is compiling etc). So although it eventually reaches a nice high execution speed. IT can take a while, before that happens.
What you are doing sounds like FUN!
There are WAY too many things that you can/should/must learn in with high tech stuff. But because it is changing all the time, and so quickly as well. There is no way (being realistic), us mere humans can keep up.
You may well find, that at various times during your career, you have to make decisions as to go left, stay, right or something.
There is just not enough time in the day, to do everything and learn everything.

tl;dr
So if you had learned/practiced with compilers, you may NOT have had time to learn/practice PID control loops, and/or climb the SSE learning curve.

What annoys me (to an extent), about us humans, is that I learn and use a particular programming language or Electronics related skill, for quite a long while. Then I don't do it for 10 years, for whatever reason.
Then (usually, unless you have brains the size of mars!), you find that you have mostly forgotten how to do it.

E.g. When I was younger. I could partially solve a Rubik's cube, and with a guide book, fairly quickly, solve it completely.

Give me a Rubik's cube now (I have not used one in quite a while), I imagine I would be completely hopeless, and I've mostly forgotten how I did it.

Anyway, good luck with the super duper control stuff and things!
You're making me somewhat jealous!

[Philfreeze]

The concerns about standard library functions is completely unfounded. In order to re-use code one should try to use the standard library functions (POSIX) as much as possible. For embedded platforms there are lightweight libraries. C was developed on very space constrained machines so the API of the standard library functions is very much tailored to keep the memory requirements to a minimum Also keep using printf! The mistake I often see is that people are trying to create their own convoluted string printing functions and while doing so they sooner or later link the printf core in as well besides their own crap functions. If the printf core is too big then the best way around it is to create a minimal printf function which is compatible with the normal printf but can be tailored to your needs if necessary.

I have done quite a bit of hacking in the Linux kernel and there are many places where a compiler would be able to optimise a lot in terms of speed. In many places in the Linux kernel you need to go several stages deep into children/parents in runtime to get to certain information even though that information can be obtained at compile time.

1. if the printf core is too big I would just use the lightweight function (usually you can tell the compiler which version he should use), actually, I would always use the lightweight function on embedded systems. You don't really need more most of the time. (the only thing the lightweight printf can't to which you might need is print a floating point number directly)

2. At least the two c++ compilers I tried actually just kept the jumps as jumps. So as an example if I have foo() in another namespace/class and I use it from my main() the compiler will make a pointer to the function pointer in the namespace/class structure where the actual pointer is stored. This means it needs exactly as many steps as in C but maybe I am just bad with compiler settings 
But as I said, like you I think they should use C++ for the Linux Kernel.

[obiwanjacobi]

Put in the time and make lots of mistakes. That is how you learn anything.

[Karel]

I have more trust in the opinion of Linus Torvalds, a person that leads world's most used operating system.

http://harmful.cat-v.org/software/c++/linus

[nctnico]

I have more trust in the opinion of Linus Torvalds, a person that leads world's most used operating system.

http://harmful.cat-v.org/software/c++/linus

The fact the pope says people shouldn't use condoms doesn't make him right. The same goes for Linus. If you actually cared to read the post then you'd clearly read Linus thinks he is the god of programming and only he is right. That has all the signs of blind religious fanatism which (as history has shown many times) is holding back actual progress. Linux would be better off if Linus stopped being the boss and leave the project to people who are able to carry it into the 21st century. The biggest problem for Linux being useful as a mainstream OS are people like Linus.

[Karel]

The biggest problem for Linux being useful as a mainstream OS are people like Linus.

I'm not aware of that problem. Linux is the most used operating system thanks to it's usefulness,
robustness, reliability and ability to adapt. Credits to people like Torvalds for accomplishing that.

[nctnico]

The biggest problem for Linux being useful as a mainstream OS are people like Linus.

I'm not aware of that problem. Linux is the most used operating system thanks to it's usefulness,
robustness, reliability and ability to adapt. Credits to people like Torvalds for accomplishing that.

Now the downside: due to ever changing APIs, driver models, lack of proper documentation, etc supporting Linux kernel device drivers for their hardware is a real nightmare for any manufacturer. This is one of the severe problems which is holding Linux back and Linus is directly responsible for that.

[Karel]

... severe problems which is holding Linux back and Linus is directly responsible for that.

Becoming the most used operating system in the world isn't something I would call "holding back".

[Philfreeze]

any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel.

That is an argument but I think most of the arguments he makes are just stupid.
(kind of including this one actually)

Nobody says that the Linux Kernel would have to use every feature C++ has and even less does it mean that they have to use the standard library.
I don't think he should use everything C++ can but it would be intelligent to use parts of C++ like classes, private-public syntax, namespaces and some more.
Alone for this things it would be nice to use C++ instead of C.

Problem is, Linus is known to be pretty excentric and he doesn't like being wrong.


P.S.
I don't have anything against C, actually I almost always use C and I don't have that much C++ experience.

[97hilfel]

Well I think I'm going to start with a simple Blink example on a AtMega328 and baybe on a small PIC...


Gesendet von iPhone mit Tapatalk

[MK14]

Well I think I'm going to start with a simple Blink example on a AtMega328 and baybe on a small PIC...


Gesendet von iPhone mit Tapatalk

That's a good idea. You can then progress in iterative stages.

Jumping in TOO deep, especially early on, can be counter productive.

At first, you may find that even the tiniest of programs, has a number of problems to solve. Such as weird compiler errors, and then the fact that it may not work at first.

Press on and be patient. Thing should soon/gradually improve.

Then come back here and argue with mini-flame (Linux/C/C++) wars!

[97hilfel]

Well, its nice to see that Dave got such a big and good community. This Weekend Im going to try some examples, and baybe I try to get a UART module running... Would be a big goal.


Gesendet von iPhone mit Tapatalk

[MSO]

Run time interpreters (RTI) such as BASIC and Java give up speed and compactness in favor of convenience. Instead of edit, compile, link and execute, they offer the edit and execute paradigm which can greatly speed up development.

Most RTIs utilize various strategies to overcome the loss of execution speed. These strategies include pre-compilation to byte codes and/or they will gather statistics during execution that can point out ‘hot spots’ in the code that can be compiled into machine code which is then cached for future use.

Neither of these strategies comes for free. The pre-compilation into byte codes results in a start up delay and the JIT statistics is always sucking up machine cycles in addition to those used by the program itself.  Both, however, can substantially speed up program execution, sometimes even approaching 50% to 60% of the speed of the statically compiled program.

There exist a few cases where JIT can improve upon a statically compiled program such as when pattern matching and regular expressions are the goal of the program.  In these cases, it is the nature of the input data itself that determines execution speed. Since the input data isn’t seen until runtime, the static compiler won’t take the data into account unless it also uses the output of a data profiler while compiling.

Such techniques aren’t often used as with statically compiled programs the vast majority of software would suffer a loss in speed with little to no likelihood of improvement.

An RTI could gain portability by generating a hardware independent byte code that could be distributed to computers with different CPUs. A local RTI could read those byte codes and translate them into machine language for the specific host computer.

All in all, RTIs are doing very well if they can execute programs at half the speed of statically compiled programs.

[Howardlong]

Neither of these strategies comes for free. The pre-compilation into byte codes results in a start up delay and the JIT statistics is always sucking up machine cycles in addition to those used by the program itself.  Both, however, can substantially speed up program execution, sometimes even approaching 50% to 60% of the speed of the statically compiled program.

In certain very rare edge cases and contrived cases possibly, but I can't say I've ever seen any evidence of it in the real world. The slow start up though is an endemic problem. I've never really understood the point of recompiling new code each time you run a program if you're not doing run time profiling. It's not like the magic CPU changing fairies have been out in the middle of the night or they were doing run time profiling the last time the code was run. Certainly Microsoft introduced AOT (ahead of time) compilation very very early on in .NET's life when they found pretty much any non-trivial solution ran so slowly at startup.

There exist a few cases where JIT can improve upon a statically compiled program such as when pattern matching and regular expressions are the goal of the program.  In these cases, it is the nature of the input data itself that determines execution speed. Since the input data isn’t seen until runtime, the static compiler won’t take the data into account unless it also uses the output of a data profiler while compiling.

This has been de rigeur on database engines for a couple of decades, using the data distribution as input to optimisers in near real time which frequently recompiles code in certain scenarios. This is a double edged sword. While it works a lot of the time it also introduces subtleties which makes those times it doesn't work even more difficult to fix and work around to optimise performance. Although very clever, it makes a lot of assumptions, and frequently bases its assumptions on pseudo-randomly selected but non-representative data samples which sometimes leads to bad compilation plans.

Key though is the determinism, or the lack of it. Not only does this frustrate end users, one of the biggest problems in troubleshooting is creating reproducible scenarios. When the rug's being contually being pulled from under your feet when the compiler decides to take a different route depending on a butterfly flapping its wings in Peru, it just makes the task another order of magnitude harder. Sometimes it's a case of less is more.

[Boomerang]

It could be very simple:

1. You compile your source code to some P-code, byte code or whatevere the name is. This is done only once.

2. When you install/deploy the program on specific machine - the byte code is converted to machine code. This is done also only once per machine.

[ade]

C vs C++ is really about two programming styles: modular (C) vs. object-oriented (C++).  They are very different paradigms.

Choosing one style over the other has a fundamental impact on how you design, organize and implement your code, with pros and cons depending on the specific situation.

Many C programmers cannot successfully make the transition to C++.   They end up superficially using C++ constructs like classes, but essentially continue to program in modular style.

On the flip side, as someone mentioned earlier, it's possible to apply object-oriented concepts in plain C, but that requires a lot of manual work.  Many elements the Unix/Linux/BSD kernel are conceptually object-oriented.

Use C when you think modular style is the best style for the problem at hand.  Use C++ when you think object-oriented methods will benefit the design. 

For the younger amongst us, it is advisable to learn both programming styles properly, as well as other programming paradigms such as functional programming.

[nctnico]

C vs C++ is really about two programming styles: modular (C) vs. object-oriented (C++).  They are very different paradigms.

Use C when you think modular style is the best style for the problem at hand.  Use C++ when you think object-oriented methods will benefit the design. 

I disagree. There are many things in C++ which are better than C. For example being able to pass a variable by reference, variable sizes arrays, a proper string type, the STL library, etc. Even if you program modular using the C++ features can help a lot to make a program more robust.
As you wrote you can program modular and object oriented in both C and C++ so the choice between C or C++ isn't driven by the programming paradigm (modular or object based).

[tggzzz]

It could be very simple:

1. You compile your source code to some P-code, byte code or whatevere the name is. This is done only once.

2. When you install/deploy the program on specific machine - the byte code is converted to machine code. This is done also only once per machine.

That is no different to conventional static compilation and optimisation, based on what the compiler is allowed to guess about the code sequences and data accesses. With some languages, C/C++ especially, the possibility of aliased references requires the compiler to make pessimal assumptions - ask anybody in the High Performance Computing community (and that is one reason why they prefer Fortran).

The advantage of dynamic compilation techniques (e.g. HotSpot, Dynamo, database queries) is that the optimisations are based on what is actually happening in your code and data. As with any optimisation technique, there are downsides - but is a significant number of cases the advantages outweigh the disadvantages.

[tggzzz]

Key though is the determinism, or the lack of it. Not only does this frustrate end users, one of the biggest problems in troubleshooting is creating reproducible scenarios. When the rug's being contually being pulled from under your feet when the compiler decides to take a different route depending on a butterfly flapping its wings in Peru, it just makes the task another order of magnitude harder. Sometimes it's a case of less is more.

I presume you do turn off caches, because cache misses (either L1/2/3 or TLB) can cause your program to slow down by an order of magnitude. And that can happen because unrelated processes "evict" your data or virtual addresses from the caches.

[Howardlong]

Key though is the determinism, or the lack of it. Not only does this frustrate end users, one of the biggest problems in troubleshooting is creating reproducible scenarios. When the rug's being contually being pulled from under your feet when the compiler decides to take a different route depending on a butterfly flapping its wings in Peru, it just makes the task another order of magnitude harder. Sometimes it's a case of less is more.

I presume you do turn off caches, because cache misses (either L1/2/3 or TLB) can cause your program to slow down by an order of magnitude. And that can happen because unrelated processes "evict" your data or virtual addresses from the caches.

Absolutely. While you make an important point, that is on very much the micro-level when dealing with an enterprise level system and any cache level issues are way down in the noise and generally not easily configurable if at all at the application layer. These days pretty much everything's on VMs and SANs anyway, the chance of your average VM admin giving a crap about cache hits is very unlikely, but cache is a key reason why things often run slower on VMs to physical boxes. In the physical world, the CPU is usually only sporadically used to full capacity on (relatively) well defined processes, whereas in the VM world it's frequently a race to have the underlying CPUs used as much as possible, particularly in commodity cloud-based services.

This has been one of my major concerns over the use of SANs and VMs in enterprise systems for the past fifteen or so years, that it's very difficult to provide _any_ form of reliable and guaranteed performance metrics as there are just too many unknowns. In general the SAN guys just want to give you JBOD solutions and simply aren't interested in spindle management. Luckily nowadays with tiered SANs the situation is alleviated.

But at the low level, absolutely. I place pinch point code in zero wait state memory and manually tier memory when necessary. That is something a compiler generally knows little about. For less intensive stuff, that can sit in slower cached memory. In general, in an embedded real time situation, you have to be able to guarantee and profile resposnse time, but luckily usually these systems are simple enough that there are a very well defined set of process that run.

Essentially, non-deterministic systems have kept the consultancy side of my business in work for a couple of decades and continue to do so. Most of my experience away from databases has been mostly with distributed systems using .NET rather than JEE in the enterprise, but I do have experience with both. Quite early on in .NET's lifecycle for example, Microsoft  realised that slow start up was a major problem for anything non-trivial, and they released they needed the option of pre-compiling ahead of time. However, at the drop of a hat they will still recompile if the stars are not properly aligned. Unfortunately this also means that after security updates, it is not at all uncommon for all that code to recompile all over again, and this can take tens of minutes, churning your poor CPU cycles - cycles that would not be used if precompiled binaries had been distributed instead.

As a real example of where adaptive compilation doesn't work well is when you have multiple end users (or processes) with differing requirements using the same code. In this instance, the way one user uses the code is different to another user, and in some situations this can lead to serialisation, as there is only one execution plan which is being repeatedly recompiled, and you end up with massive overhead as the same code is recompiled on each context switch/iteration/execution - think in terms of 1,000 slower. This became very apparent, for example, in SQL Server 2000, and remains a problem to this day unless you enforce a per-session execution plan, which is expensive in memory... and, coincidentally, cache of course! I don't know how a Java hot-spot compiler deals with this situation, but it is very real with adaptive run time optimisers. Indeed, I wrote a paper on it at the time. It is exactly this kind of unexpected and unintended performance behaviour which makes me wary, but equally it's given me the opportunity to earn a few quid diagnosing and fixing it when it goes wrong too.

Anyway, these are just my experiences, and as I say I can hardly complain, these kinds of additional complexities and their unintended side effects are exactly what end up paying my bills after all!

[ade]

There are many things in C++ which are better than C. For example being able to pass a variable by reference, variable sizes arrays, a proper string type, the STL library, etc.

Pass by reference is meaningless in modular C, because you don't have overloaded types (which imply objects).  Otherwise it's only syntactic sugar.

Modern C supports variable length arrays (since C99).  It's neither good or bad.  Peruse the Linux kernel and you'll see VLAs being used.

"Proper string type" and "STL" again are entirely meaningless outside object-oriented context.   Type here imply object.  You can't use your "proper string type" without instantiating string objects.   You don't need generics when programming in modular style, as you don't organize by types.

[tggzzz]

I think we ar emostly in violent agreement.

Key though is the determinism, or the lack of it. Not only does this frustrate end users, one of the biggest problems in troubleshooting is creating reproducible scenarios. When the rug's being contually being pulled from under your feet when the compiler decides to take a different route depending on a butterfly flapping its wings in Peru, it just makes the task another order of magnitude harder. Sometimes it's a case of less is more.

I presume you do turn off caches, because cache misses (either L1/2/3 or TLB) can cause your program to slow down by an order of magnitude. And that can happen because unrelated processes "evict" your data or virtual addresses from the caches.

Absolutely. While you make an important point, that is on very much the micro-level when dealing with an enterprise level system and any cache level issues are way down in the noise and generally not easily configurable if at all at the application layer.

While the points you make below are most assuredly important, the reason I chose the L1/L2/L3/TLB caches is that those are at more equivalent level to dynamic compilation. There is little that dynamic or static optimisation can do to affect SAN/network/VM level effects.

These days pretty much everything's on VMs and SANs anyway, the chance of your average VM admin giving a crap about cache hits is very unlikely, but cache is a key reason why things often run slower on VMs to physical boxes.

In my experience they don't even know that L1/L2/L3/TLB caches exist, let alone understanding their significance. Unfortunately most "enterprise level" programmes are little better.

In the physical world, the CPU is usually only sporadically used to full capacity on (relatively) well defined processes, whereas in the VM world it's frequently a race to have the underlying CPUs used as much as possible, particularly in commodity cloud-based services.

My recent experience has been with telecom application servers, and there customers do measure latency (usually mean latency rather than 95th percentile latency, fortunately!).

This has been one of my major concerns over the use of SANs and VMs in enterprise systems for the past fifteen or so years, that it's very difficult to provide _any_ form of reliable and guaranteed performance metrics as there are just too many unknowns. In general the SAN guys just want to give you JBOD solutions and simply aren't interested in spindle management. Luckily nowadays with tiered SANs the situation is alleviated.

That is, of course, when those bodies aren't peddling half-truths and even lies about performance, failure modes, and reliability.

But at the low level, absolutely. I place pinch point code in zero wait state memory and manually tier memory when necessary. That is something a compiler generally knows little about. For less intensive stuff, that can sit in slower cached memory. In general, in an embedded real time situation, you have to be able to guarantee and profile resposnse time, but luckily usually these systems are simple enough that there are a very well defined set of process that run.

For embedded systems that is, to some extent practical (I always liked the i960 in that respect), but I haven't seen a way to do it in application servers.

Essentially, non-deterministic systems have kept the consultancy side of my business in work for a couple of decades and continue to do so. Most of my experience away from databases has been mostly with distributed systems using .NET rather than JEE in the enterprise, but I do have experience with both. Quite early on in .NET's lifecycle for example, Microsoft  realised that slow start up was a major problem for anything non-trivial, and they released they needed the option of pre-compiling ahead of time. However, at the drop of a hat they will still recompile if the stars are not properly aligned. Unfortunately this also means that after security updates, it is not at all uncommon for all that code to recompile all over again, and this can take tens of minutes, churning your poor CPU cycles - cycles that would not be used if precompiled binaries had been distributed instead.

I had presumed, without evidence or searching, that was the reason MS updates were so appallingly slow. Thanks for the solid experience.

As for slow-startup but eventually better performance vs fast-startup but poorer performance, there's a good argument MS made the right choice for the .NET desktop. It is less clear for long-running application servers.

As a real example of where adaptive compilation doesn't work well is when you have multiple end users (or processes) with differing requirements using the same code. In this instance, the way one user uses the code is different to another user, and in some situations this can lead to serialisation, as there is only one execution plan which is being repeatedly recompiled, and you end up with massive overhead as the same code is recompiled on each context switch/iteration/execution - think in terms of 1,000 slower. This became very apparent, for example, in SQL Server 2000, and remains a problem to this day unless you enforce a per-session execution plan, which is expensive in memory... and, coincidentally, cache of course! I don't know how a Java hot-spot compiler deals with this situation, but it is very real with adaptive run time optimisers. Indeed, I wrote a paper on it at the time. It is exactly this kind of unexpected and unintended performance behaviour which makes me wary, but equally it's given me the opportunity to earn a few quid diagnosing and fixing it when it goes wrong too.

Anyway, these are just my experiences, and as I say I can hardly complain, these kinds of additional complexities and their unintended side effects are exactly what end up paying my bills after all!

I've always stayed away from databases, except to get rid of them as being unbeneficially heavyweight for specific telco applications.