Why do you have to “migrate to higher level platforms and languages”? Assembly is perfectly valid for this application.
The cell modem he is using already has a 32 arm cpu maybe even multi-core.
32bit it the new 8bit.
C is the new assembly for 99% of code. You can drop to assembly for the 1% where it matter.
not tied to the processor architecture and thus can switch to a better/cheaper cpu easily.
I did a embedded project on 8051 like that, we had the legacy code 100% in asm and we moved to C. In the end I think we had about 10-20 lines of asm and everything else in C.
You are right switching cpu and thus all the peripheral is major headache, not something to take lightly.
In fact I find that learning new high level packages much harder.
With C, you just need to rewrite the device drivers (because your business logic is portable and unit tested, right?!). In assembly, it's time to throw it all away and start again.
For a trivial programme like read the ADC and do something like alert on a UART, that's not so bad. But some products are a lot more complex than that.
The bonus being able to continue using well tuned, mature routines.
An emulation done once, would bring the whole works onto a new CPU.
There's a careful value judgement to be made there. For example, if you have many products all in some dying 8-bit architecture, and it's easier to write the emulator once and then all the products are rescued, then good. If you spend 6 months writing the emulator to save yourself from 6 weeks of porting one simple program, less good.
This is when "hey wouldn't it be really cool if" meets the cold realities of commercial engineering.
I took this particular case to mean there are lots of products.
Could also just put the CPU into an FPGA, which would be a choice I would look hard at personally. Many 8 bitters are out there, some cycle exact.
Then one has a hardware solution to build. Could go quicker.
I personally would emulate.
Over all, the take away is portability has more flex in it than is often recognized.
Or it might not be. If it's just a simple loop, probably fine. If you have to move a custom assembly RTOS and an entire stack of business logic, maybe it's going to be very painful, project-risky and error-prone. Whereas if it was C, you just need to port drivers (which may already be provided by the manufacturer) and maybe do the RTOS port (if not already done). That could be days to weeks of work. A rewrite in a new assembly language could be months, at the end of which, to a customer, you have the exact same product you had before, except without a proven track record for any single byte of code.
Like everything, it depends on the project.
This year especially, it's going to be hard enough to stay alive by just shipping anything at all while competitors go to the wall under the double whammy of customer hesitancy and component shortages that can cut an established product of at the knees. And the last thing a company needs then is a long and expensive rewrite blocking shipping.
Not only that, if the chips you rewrote for end up on 100 week lead times (and thats not even the longest I've seen this month), you're completely dead in the water.
I'd be interested in knowing how they did that as it was all x86..!