> In the 1980s everything was written in assembly and you depending on the clock speed. However these days embedded should have learned that the CPU you write for will go out of production and so you should write portable code except for the small shim layers that talk to the real hardware.
Ah... the illusions of "portability". A lot of the reason you want to test your code is that there may be behaviors specific to the target platform (either in the hardware itself, in the compiler, in the runtime, or in support libraries/frameworks). You may well write with the intent to be portable, but you test for the reality that you never really are.
Testing on a desktop machine with many cores is not a good simulation of that environment. You run your tests on your local machine as much as possible. Then you run on the real production hardware enough tests to be confident.
I don't work automotive, but my application is very similar - an embedded display running ARM CPUs. I do a lot of testing on x86-64 and only rarely encounter portability issues. When I do discover such things they have always been things that I need real hardware to debug on not something an ARM desktop would help with.
I have they are rare though. once ever 10 years for a good sized project seems right. Where they habpen I wouldn't expect anything other than the exact hardware to reproduce them so I'm still not wanting a workstation live the target.
I've run into tons of optimizer bugs. While it's possible they would require the exact hardware to reproduce them, that has never been the case. Generally you just need something to run the actual output of the optimizer. You can even reproduce the bugs in emulators, it just takes way longer.
Most optimizer bugs are about the optimizer making assumptions about properties of the source code, not assumptions about properties of the hardware. Certainly it can go both ways, but of course you want to test the actual output of the optimizer. Doing otherwise is not at all what I'd call standard practice.
Ah... the illusions of "portability". A lot of the reason you want to test your code is that there may be behaviors specific to the target platform (either in the hardware itself, in the compiler, in the runtime, or in support libraries/frameworks). You may well write with the intent to be portable, but you test for the reality that you never really are.