If you're working in C/C++ then there is no difference in the logic of your program between *any* CPU, not only AVR vs ARM, but also x86, RISC-V, MIPS etc etc.
This is actually only true in very simple cases.
A primary example of hardware differences encountered in C has to do with the processor width.
For example, an `int` on most AVR compilers is a different size than it is on most ARM compilers.
Further, even for explicitly sized types such as `int8_t` and `int32_t` behavior differs. On the 8-bit core, using a wider type than necessary costs extra memory and operations. While on a 32-bit core, using an 8-bit type where a larger one would work can force an extra step to mask off only the required bits.
On an 8-bit machine, a 16 bit volatile counter exported from an ISR to the main loop needs a locking mechanism to avoid having it change between the two required memory read operations; on a 32-bit machine it does not need that.
And then there are issues with unaligned memory access.
And struct packing
Or endianness, though that happens to match here.
Fortunately once these issues are
understood it's possible to target either situation.
Then there are things that get more specifically hardware-involved - anything to do with interrupts or peripherals.
Also differences between true and modified Harvard architectures determine if you can perform transparent access to flash memory (ie, via true pointers) on not. And if you can write to code memory, if you need to force cache consistency.