I have run out of the 64K code space on my 8051 processor and need to port to something like the Cortex-M3 with 128K. BUT...with a 32 bit processor, in theory I'd need 256K of program memory just to break even. Does anyone have experience with what the real multiplier is between an 8 bit device and one of these? Can I reasonably expect that I'll have more room for code moving this way?
"in theory I'd need 256K of program memory just to break even"
How on earth did you come to that conclusion?!
I presume you're working on the basis that an 8051 is 8-bit, an ARM is 32-bit, which is 4*8, therefore the code will 4*64K = 256K - yes?
It really doesn't work like that!
That assumes that every 8051 instruction has exactly one equivalent ARM instruction that is exactly four times the size - which is clearly nonsense!
A lot of your 8051 code will be concerned with doing things that simply aren't necessary on an ARM - like loading & reloading DPTR, having to "manually" implement multi-byte operations with single-byte instructions, etc, etc...
And don't forget Thumb mode...
As Andy notes, the little guy has to use a number of instructions to perform some operations since it doesn't have 32-bit registers, multiple address pointers etc. Just think about incrementing a 32-bit integer on an 8-bit and 32-bit processor.
When I play around myself, or work with early prototypes, I normally buy the largest edition of a chip to experiment with. If/when it's time for production, I may then decide to go for a more optimized memory size for them.
One advantage with this approach is that I know that I have extra room for debug code and trace printouts. When ordering 4-10 prototypes of a device, it normally doesn't affect the total price so much to have the factory manually replace the processor before the soldering. Then I can use one prototype with augmented code, and one prototype with production code. The other units may then be used for long-time testing, sent to a test lab or to the customer.