One of the things that helped a lot in 8048 development was the s48 simulator which allowed me to watch the effect of instructions on memory and ports.

SDCC comes with s51 but this is a CLI simulator. It may be useful in some cases. It also seems to be possible to invoke the simulator through ddd, the GNU GUI debugger frontend, which invokes sdcdb, which invokes s51. The docs say it may not be as smooth as expected.

Lookiing at other free simulators for Linux, mcu8051ide seems to emulate lots of 8051 variants, provide a fairly complete display, but unfortunately I can find no way to load just a hex or binary file, you have to develop using the compiler and assembler that it uses. I'm the kind of person who likes to use a text editor on a C file*. Since it's GPLed open source, I suppose one could add this capability.

Edsim51 is also quite complete, even simulates peripherals, and is written in Java, so cross-platform. But unfortunately again you have to develop using its IDE, I see no way to load a hex or binary file.

I am willing to consider jsim-51 which will run under my WIndows XP in a VM. It can even read both the .ihx and .map files generated by asxxxx, the assembler used by SDCC, to provide a labelled disassembly. However I can't find a way to display registers and memory continuously while simulating, one has to pause, then issue an update display command. Maybe I have to look harder. It's strange as the timers can be monitored continuously. One disadvantage is as it was written ages ago, it only caters for the 8031/8051, not any of the recent variants with more peripherals.

But one good thing about developing in C is that you are one level above assembly instructions and don't have to worry as much about the state of the registers and flags but think in terms of program variables. Subroutines also encourage compartmentalising functionality. But when it comes to low-level operations on ports, it's good to be able to watch.

Oh well, I'll see how I do writing a structured program in C from the start and maybe I won't need to simulate much.

* But I recognise the benefits of and do use the facilities of the Arduino IDE, especially the facts that it handles the variations in AVR CPUs behind the scenes, and brings together many tools, including such things as SPI programming, under its umbrella. One can always edit the .ino file outside of the IDE and then reload in the IDE.