4 ms·

I remember during EE course we had an assigned project to write some software for 8051 microcontroller, in assembly. I organized my code into small "functions"

I remember during EE course we had an assigned project to write some software for 8051 microcontroller, in assembly. I organized my code into small "functions" and used a consistent stack-based calling convention with pushing all the resisters on the stack and restoring them back on exit, just as if it was generated by a C compiler. The teacher looked at this and said "huh, look, this is not a CS lab. We do not do things like this in embedded software. Why don't you just keep everything global and use absolute addressing instead those crazy push/pop calls? And you should be reusing registers..." Anyways, it was lot of fun.

robomartin 13y ago
On a resource and computing-power constrained system used for a very specific function it would not be too far off if one said something like that(with caveats). Anything past that category and he would be dead wrong. In other words, if you only have 2K or RAM to play with, a limited stack depth, a CPU clock of, say, 12MHz and a 12 clock instruction cycle you have no choice but to get very clever. Pushing and popping a bunch of registers on every function call could rob you of much needed performance and resources. In fact, on such a system that alone could cause unintended side effects and introduce potential safety issues (talking real-time systems with a requirement for deterministic response). You could also have a situation where you overflow the stack and things go from bad to worst very quickly. BTW, this, among other things, is one of the reasons I abandoned such small, 8-bit, resource-constrained architectures for most embedded projects a long time ago. The 8051 derivatives (Silicon Labs) have always been some of my favorites. I might still use them for small projects such as small control panels or simple sensor pre-processing. These days you can buy 32 bit processors running in the tens to hundreds of MHz for $10 or less. These provide you with the ability to write "proper" embedded software with all the luxuries of greatly increased resources and operating speed.
- hfsktr 13y ago
  I like the way you explained it. The way it was written above seems like he was just told he's wrong but not any of the reasons why. Might just be my lack of knowledge in the area but it made the teacher's response more understandable.
  - pkolaczk 13y ago
    There's a huge difference between answering "beware of blowing up the stack" and "in embedded we don't do like that".
    - makomk 13y ago
      Of course, Toyota failed to make sure they didn't blow up the stack as well as using a ridiculous number of global variables and poorly organised code.
    - hfsktr 13y ago
      I think we are in agreement here. I had assumed one of the reasons it's "not done like that" is "blowing up the stack" but only half of that was given at the time. Maybe I misunderstood altogether. I just appreciated that there are real reasons for things, especially when they make sense.
- pkolaczk 13y ago
  You're perfectly right, but performance of my system was fine without any further optimisation and there was no point in doing some dirty tricks to get more performance, even though the system had 32k or 64k RAM (I don't remember now). Also, often it is enough to optimise just a few critical places, not the whole thing.
AYBABTME 13y ago
Before starting my software engineering (SEG) degree, I did some technical EE in Cégep [1] . We first learned assembly and coded in that for a year. Then we had a course of C and I was so confused as to why everything was push/pop at every call, when in most situations it was useless and seemed like a waste of cycles. Luckily, between this EE thing and my SEG education, I went in the army for 5 years so I forgot about this whole question and came looking at SEG with fresh eyes. [1] Cégep (they call it in Québec) is a mandatory step in between high-school and university. They offer pre- university training (2 years) and technical/skilled- worker training (3 years). In the case of 'technical EE', you spend 3 years doing that and you can go to a university for a EE/CEG/SEG[2] degree after (2-3 years), or just go work. [2] CEG; computer engineering, SEG; software engineering.

robomartin 13y ago

On a resource and computing-power constrained system used for a very specific function it would not be too far off if one said something like that(with caveats). Anything past that category and he would be dead wrong. In other words, if you only have 2K or RAM to play with, a limited stack depth, a CPU clock of, say, 12MHz and a 12 clock instruction cycle you have no choice but to get very clever. Pushing and popping a bunch of registers on every function call could rob you of much needed performance and resources. In fact, on such a system that alone could cause unintended side effects and introduce potential safety issues (talking real-time systems with a requirement for deterministic response). You could also have a situation where you overflow the stack and things go from bad to worst very quickly. BTW, this, among other things, is one of the reasons I abandoned such small, 8-bit, resource-constrained architectures for most embedded projects a long time ago. The 8051 derivatives (Silicon Labs) have always been some of my favorites. I might still use them for small projects such as small control panels or simple sensor pre-processing. These days you can buy 32 bit processors running in the tens to hundreds of MHz for $10 or less. These provide you with the ability to write "proper" embedded software with all the luxuries of greatly increased resources and operating speed.

hfsktr 13y ago
I like the way you explained it. The way it was written above seems like he was just told he's wrong but not any of the reasons why. Might just be my lack of knowledge in the area but it made the teacher's response more understandable.
- pkolaczk 13y ago
  There's a huge difference between answering "beware of blowing up the stack" and "in embedded we don't do like that".
  - makomk 13y ago
    Of course, Toyota failed to make sure they didn't blow up the stack as well as using a ridiculous number of global variables and poorly organised code.
  - hfsktr 13y ago
    I think we are in agreement here. I had assumed one of the reasons it's "not done like that" is "blowing up the stack" but only half of that was given at the time. Maybe I misunderstood altogether. I just appreciated that there are real reasons for things, especially when they make sense.
pkolaczk 13y ago
You're perfectly right, but performance of my system was fine without any further optimisation and there was no point in doing some dirty tricks to get more performance, even though the system had 32k or 64k RAM (I don't remember now). Also, often it is enough to optimise just a few critical places, not the whole thing.

AYBABTME 13y ago

Before starting my software engineering (SEG) degree, I did some technical EE in Cégep [1] . We first learned assembly and coded in that for a year. Then we had a course of C and I was so confused as to why everything was push/pop at every call, when in most situations it was useless and seemed like a waste of cycles. Luckily, between this EE thing and my SEG education, I went in the army for 5 years so I forgot about this whole question and came looking at SEG with fresh eyes. [1] Cégep (they call it in Québec) is a mandatory step in between high-school and university. They offer pre- university training (2 years) and technical/skilled- worker training (3 years). In the case of 'technical EE', you spend 3 years doing that and you can go to a university for a EE/CEG/SEG[2] degree after (2-3 years), or just go work. [2] CEG; computer engineering, SEG; software engineering.