In my work, I often come across a younger generation of engineers who are interested to write software. When asked on tips on how to be a better programmer, I often tell them to study assembly. The result is usually a mixture of shock and incredulity.
Assembly programming is taught as a matter of course, in any electronics engineering program worth it’s salt. It is a very important skill to learn as it is one of the key areas of programming that require a certain level of technical engineering knowledge to understand. Therefore, as engineers, we have no excuse to be afraid of assembly programming.
Most of the time, these people are coding in C/C++ and not one of the sexier languages. I often remind them that C was only invented around 1970 and humans were perfectly capable of writing complex software in assembly, well before that. Today, many people still write assembly code when they’re forced to deal with certain hardware registers or because there isn’t a suitable C/C++ construct to access specialised features of the processor.
It is in this realm that the electronics engineer comes in handy – to work on software that runs close to bare-metal.
Therefore, it saddens me to think that the younger generation of electronics engineers today think that embedded systems programming means using something like the Arduino. While I think that the Arduino is an absolutely useful tool for developing embedded systems, it is not a great tool to teach it to electronics engineers because it abstracts everything away.
In fact, learning to read and write assembly is an absolutely amazing way of improving one’s programming skills in any language. After doing it enough times, one can truly appreciate how all the software constructs are reduced to machine operations. It basically teaches a person to think like a compiler and allows us to truly instruct the machine to do what we want it to do.
It feels like magic.
PS: Look at the amount of code that was written in the past. Think at how much work went into that. Lines of code? Try volumes of code.
I spent the afternoon trying out the C++ Lab experiments today. I’ve finished 6 of the exercises and I’ve managed to catch a few potential problems:
- Emacs is configured with Syntax Highlighting disabled. I had to enable it each time I started Emacs. I don’t use any custom emacs startup scripts. So, this is a global problem.
- The XCC tool used as a compile/debug environment has a mouse-over focus. So, the cursor needs to be on the stdin/stdout area in order for the programme to receive user input. This is not stated in the handout.
- The instruction for accessing the Animation is inaccurate. It requires a little navigating before the actual link is found. This might confuse some students.
- The XCC environment hung a few times, while running the programme halfway (at random points). There may be a stability issue with the XCC.
UPDATE@2355: I finished up to exercise 8 and found a major problem.
- Missing GLUE library.
I’ve notified TL about it and he has taken action to fix the problems.
I’ve just received a reply from TL with regards to the C++ labs as he had just recently returned from holiday. This is August, the month when everyone except research students go off on holidays. He had promised to send me the relevant handouts/labnotes soon and he has sent them all to me via UMS. I guess that I’ll need to do the following:
- Ensure that the GCC toolchains still work.
- Ensure that the example code snippets are accurate.
- Ensure that the experiment instructions are clear.
- Familiarise myself with all the different experiments.
So, I will go through them one by one, before I go off on my break. I’d normally do this for any new experiment that I was introduced to anyway. It’s important to not only go through the motions but to also try to imagine the problems that students might face while doing it. Hopefully, with my experience in programming, it would not be too difficult to get through. I’m a little rusty on C++ as I’ve been mostly programming in low-level C for the last couple of years.
I’m a little confused at the idea of doing a C++ experiment though. I did not learn programming through formal methods. So, I’ve always been partial to the hack-n-slash school of thought. It would be interesting to see how they develop programming concepts through structured experiments. I guess that there will be experiments on assignments, control structures, loops and more interesting stuff like arrays, data structures, pointers and objects.
I look forward to trying them out.