4 ms·

So what's the catch? We have been developing memory architectures, and embedded systems, and OS's for decades now. So if the solution is as simple as this post

So what's the catch? We have been developing memory architectures, and embedded systems, and OS's for decades now. So if the solution is as simple as this post says, why hasn't it ever been implemented before? I am hoping there are experts here that can shed some light on this

zurn 13y ago
A mix of technological and cultural path dependence, cowboy attitude to performance/optimization, and inability to quantify risks. (Somewhat interrelated, eg cowboy attitude -> C, path dependency in C usage -> hard to reason about programs -> hard to quantify risks)
- pjmlp 13y ago
  I liked your "cowboy attitude -> C". Everyone is a C expert, except when they happen to be a tiny cog in a big coding machine. "I know where all my pointers are memory allocations are!". Sure, but does everyone on your 20+ people team from the intern up to the senior guys know? Then things like this are bound to happen.
- sfk 13y ago
  C is used in such applications precisely because it is one of the few languages that allow you to reason about things like stack usage. Try that in Python, Ruby (or ML for that matter).
- diydsp 13y ago
  This. I've done consulting in embedded for years and years. The discipline of modern desktop/web development has not reached the embedded world, except in a few high-margin areas (such as military and transportation). There are 1,001 reasons for this, ranging from people who didn't learn source control, open source and unit-testing doing much of the coding (iow people from other disciplines besides software engineering and people who don't keep their skillset current), to the fact that cross-compiling is much harder/slower to debug than workstation debugging to the fact that resources are more limited in embedded, so code is more terse, with fewer convenient debugging functions. Other problems are with management- they see embedded code as a "write it and forget about it" schedule item, not a continuous improvement one. Much of this is due to the fact that embedded code is not as portable as workstation code. All of these shortcomings sufficed when the number of time pressure of embedded projects was much smaller 5-10 years ago. Now that embedded has exploded in ubiquity, its requirements are increasing and it's getting less time to be perfected in most markets. So yeah, I guess it's safe to say the embedded world is in a bit of crisis at the moment.
  - seren 13y ago
    Having work in a similar environment, I know at least one company where most managers have a hardware/electronics background, because their product was mostly HW when they started to work 20 years ago. But now, the split is more akin to 80%SW/ 20%HW and they are managing SW developers without having much idea of what SW development consists of. I know at least of one example of a top engineering manager not understanding what version control was : "Please merge all the features but not the bugs from branch X". (Which is a noble goal in itself, but might be hard to attain !)
  - vonmoltke 13y ago
    > The discipline of modern desktop/web development has not reached the embedded world, except in a few high-margin areas (such as military and transportation). My experience is that it hasn't penetrated very far there, either. Sure, we had version control and code reviews. The process was so warped and bastardized from industry standards, though, that it became a CYA/box-checking burden to keep the SQAs who really didn't understand code happy than a tool to improve development. Plus, most of the managing and systems engineers were hardware types[1] who didn't really understand what the software groups were doing or how they operated. [1] Important note: I'm a hardware type, too. I'm just a hardware type that actually got and wrote software. Made the situation doubly frustrating.
weland 13y ago
This has been, and typically is, implemented. There are various ways to ensure your stack doesn't thrash your data, and this is one of them. Why Toyota hasn't is not something I can answer, but the principle that the article describes is well-known. As for the last part of the article, there are ways to get around this issue when using operating systems, too. Some of them depend on certain hardware features being present, of course, and what should be inferred from this is that, where such protection features are critical, hardware should be picked accordingly. Edit: I've seen a lot of posts here blaming C and the unmanaged runtimes. While a managed runtime can provide some amount of protection, it's worth noting that: * It requires a MMU. These aren't smartphones folks. An MCU with a MMU isn't cheap. * In the absence of correct memory management from the kernel (and that also requires a MMU!), it's perfectly possible to smash data regions with overgrown stacks, even on managed runtimes. * You can achieve a good amount of protection using special compiler features. That requires no special hardware support.

zurn 13y ago

A mix of technological and cultural path dependence, cowboy attitude to performance/optimization, and inability to quantify risks. (Somewhat interrelated, eg cowboy attitude -> C, path dependency in C usage -> hard to reason about programs -> hard to quantify risks)

pjmlp 13y ago
I liked your "cowboy attitude -> C". Everyone is a C expert, except when they happen to be a tiny cog in a big coding machine. "I know where all my pointers are memory allocations are!". Sure, but does everyone on your 20+ people team from the intern up to the senior guys know? Then things like this are bound to happen.
sfk 13y ago
C is used in such applications precisely because it is one of the few languages that allow you to reason about things like stack usage. Try that in Python, Ruby (or ML for that matter).
diydsp 13y ago
This. I've done consulting in embedded for years and years. The discipline of modern desktop/web development has not reached the embedded world, except in a few high-margin areas (such as military and transportation). There are 1,001 reasons for this, ranging from people who didn't learn source control, open source and unit-testing doing much of the coding (iow people from other disciplines besides software engineering and people who don't keep their skillset current), to the fact that cross-compiling is much harder/slower to debug than workstation debugging to the fact that resources are more limited in embedded, so code is more terse, with fewer convenient debugging functions. Other problems are with management- they see embedded code as a "write it and forget about it" schedule item, not a continuous improvement one. Much of this is due to the fact that embedded code is not as portable as workstation code. All of these shortcomings sufficed when the number of time pressure of embedded projects was much smaller 5-10 years ago. Now that embedded has exploded in ubiquity, its requirements are increasing and it's getting less time to be perfected in most markets. So yeah, I guess it's safe to say the embedded world is in a bit of crisis at the moment.
- seren 13y ago
  Having work in a similar environment, I know at least one company where most managers have a hardware/electronics background, because their product was mostly HW when they started to work 20 years ago. But now, the split is more akin to 80%SW/ 20%HW and they are managing SW developers without having much idea of what SW development consists of. I know at least of one example of a top engineering manager not understanding what version control was : "Please merge all the features but not the bugs from branch X". (Which is a noble goal in itself, but might be hard to attain !)
- vonmoltke 13y ago
  > The discipline of modern desktop/web development has not reached the embedded world, except in a few high-margin areas (such as military and transportation). My experience is that it hasn't penetrated very far there, either. Sure, we had version control and code reviews. The process was so warped and bastardized from industry standards, though, that it became a CYA/box-checking burden to keep the SQAs who really didn't understand code happy than a tool to improve development. Plus, most of the managing and systems engineers were hardware types[1] who didn't really understand what the software groups were doing or how they operated. [1] Important note: I'm a hardware type, too. I'm just a hardware type that actually got and wrote software. Made the situation doubly frustrating.

weland 13y ago

This has been, and typically is, implemented. There are various ways to ensure your stack doesn't thrash your data, and this is one of them. Why Toyota hasn't is not something I can answer, but the principle that the article describes is well-known. As for the last part of the article, there are ways to get around this issue when using operating systems, too. Some of them depend on certain hardware features being present, of course, and what should be inferred from this is that, where such protection features are critical, hardware should be picked accordingly. Edit: I've seen a lot of posts here blaming C and the unmanaged runtimes. While a managed runtime can provide some amount of protection, it's worth noting that: * It requires a MMU. These aren't smartphones folks. An MCU with a MMU isn't cheap. * In the absence of correct memory management from the kernel (and that also requires a MMU!), it's perfectly possible to smash data regions with overgrown stacks, even on managed runtimes. * You can achieve a good amount of protection using special compiler features. That requires no special hardware support.