Instructions for 8 bitters are indeed smaller and generally have a smaller binary. So assume that the code will get bigger.
However, 8 bitters also produce much less efficient code than 32 bitters. So the key is how skilled the person who wrote the original program was. Have they streamlined the source to work well on an 8 bit MCU? Some things to look for:
- Is it using
uint8_t
/uint_fast8_t
where appropriate, or is it just PC slop with int
all over the place?
- Is it treating implicit promotions with great care, such as using casts back to
uint8_t
after an operation with implicit int promotions present?
- Is it avoiding 16 or 32 bit arithmetic?
- Is it avoiding PC programming nonsense such as
stdio.h
or floating point arithmetic?
- Is it avoiding excessive standard library calls in general?
If you find no traces of a skilled C programmer, like in the above examples, then the code might actually end up more compact if ported to 32 bit, if it is calculation-intensive code. It's much easier to program professional C for 32-bit than for 8-bit.
Also - and this has a very big impact: almost all 8 bitters out there are archaic architectures from the 1980s and 1990s, that very often come with very bad C compilers. Compilers that do a really poor job at optimizing the code. Modern 32-bitters like Cortex M are almost certain to have much better compilers. So check if optimizations were at all enabled in the original source and if you plan to use them after porting - it's fairly common that embedded systems don't have optimizations enabled, particularly older ones - and this is because of bad old compilers with optimizer bugs.
On the other hand, if the code is mainly hardware drivers with lots of register writes, it will likely end up much larger on 32 bit, since hardware peripheral registers are 8 bit on 8/16 bit cores but 32 bit on 32 bit cores. But you'll have to rewrite these drivers anyway, so it's hard to compare.
In addition, you can look for explicit "ROM memory over execution speed" optimizations. For example, if there is a CRC, is it implemented with lots of loops and shifts rather than a fast look-up table? Such things might be indications of the programmer keeping the flash size down on purpose.
Then of course stuff like LCD fonts, string tables etc are big chunks taking up lots of flash, but they do so independently of 8 vs 32 bit core.