A person who is spending his lifetime trying to perfect a solution to a specific problem can probably implement a solution in just about any language. A person who knows a specific language can probably not implement the solution because of lack of understanding of the required algorithm.


A competent jazz musician does not imply a competent techno musician. Same thing with programming. If you write the software for burglar alarms, your language knowledge will not help you if you instead need to write the controlling application for a HDD. The major factor for quality, code size, processor load etc is still the knowledge about the specific problem. It can take years to be on the fore-front in a specific area - and you will have to start from scratch if changing to a different area. Just see how much problems an experienced PC programmer may have writing the code to control a stepper motor with dynamic acceleration/retardation. But the same goes for an embedded programmer who moves to a differnt area of products. How do you implement the calculations inside a GPS? How do you control the fuel injection and ignition of a car? How do you implement the processing in a bar code reader that supports multiple bar-code styles?

Without knowledge in the application field, you are going to crash and burn however many HLL languages you know or however many processor architectures you can program in assembler. The majority of customers wants knowledge in their field, not knowledge with a specific chip. And quite a number of customers expects to be able to move their sw investment to new hardware. But the optimum chip for this new hardware may be of a completely different architecture.

Look at the prices of the chips. My customers don't care if they get a 8051 or an ARM. They get a quote for a working product that solves their problems. They pay for a solution. And even if the chip costs $0.50 more, the correlation with the life-time cost of the product will be very low - quite possibly even negative! Shaving cents from the hardware may be relevant if the product is sold in 100k volumes or more every year. But in the end, the end-user price or the per-unit profit is often controlled by other factors.


I know that there are no simple linear correlation between instructions/second or kB of RAM and processor cost - and even less correlation with product cost. In some situations, the customer may focus on minimum unit costs. In some situations, they may focus on delivery time. In some situations on the ability to redesign and create new products. In the other direction, the supplier must factor in the availability of people. And the possiblity of code reuse. The probailities of spin-off products. In the end, management looks at total cost/total profit. Not at the number of kB or MIPS. The term for management who do look at kB or MIPS is micromanagement - no pun intended.


Exactly. No one have said that it isn't possible to do things in assembler. The problem here is that you are ready to spend an arm and a leg to say that anything not written in assembler is crap. Or leads to a higher total cost.


I'm not talking about information in the source code. I'm talking about needed space in the chip. A specific problem described in byte code can consume way less space in your flash than the same problem described in machine instructions, because the byte code can be designed to fit a specific problem. That is also a reason why there exists processors with reprogrammable instruction sets. This was an example about algorithmic choices.


The chip price will most probably vary more moving from one manufacturer to another, or from one architecture to another, than it will vary from doubling the code space. If the code is written in assembler, then the next larger chip must be from the same family or a very closely related family. With C, even very large projects can be moved to a completely new architecture in quite short time spans. If a customer comes and says that an existing product should be extended to get four instead of two CAN interfaces, or USB OTG instead of just a normal USB slave then the best choice of processor from the hardware perspective may completely invalidate your assembler code.

I had one generation of a product with an 8-bit processor with 4 or 8kB of flash. Because of a number of other needs, it got replaced with a 32-bit processor with 256kB of flash with about the same price. The assembler program got thrown away. I had the choice if I should store the new C application low or high or multiple times. So while most of the flash is empty, the new product was cheaper despite adding a number of new hardware features. If I could have ended up with an assembly program only consuming 60-70% of the C program is obviously totally irrelevant. I already have room for several copies of the application - getting space for yet one or two more would not matter. And the time to fill the chip is not on a critical path in the factory, so a space save will not reduce the manufacturing costs.


Most good programmers I have met can work quite well in teams. It is only when it is unclear which one who is responsible for the design that it may get a bit problematic :)


The bigger problem is managers who orders that software should be written and/or shipped while skipping on the documentation - planning on doing that when spin 2 or whatever is ordered. The biggest problem is managesr or sails staff who sells things without having managed to get a proper specification of what functionality that represents an acceptable customer delivery.


If the customer buys a unit that costs $500, then it doesn't matter so much if a processor costs $3 or $4. And if 10k units is produced in total, then the $10k in materials may be regained in development time. Especially if the $4 processor brings in bonus features. Remember that 1000 lines of C can do more than 1000 lines of assembler.