SDCC has three Rabbit-supporting ports: r2k for the Rabbit 2000, r2ka for the Rabbit 2000A, 2000B, 2000C and 3000, r3ka for the Rabbit 3000A. The instruction set of the Rabbit 2000 to Rabbit 3000 is the same, and a subset of the Rabbit 3000A instruction set. Code from the r2k backend will work on Rabbit 2000 to 3000A and code from the r2ka backend will work on Rabbit 2000A to 3000A. In some hardware configurations (see below), code from the r2ka backend will work on the Rabbit 2000. Typically, code from the r3ka backend will be faster and smaller than code from the r2ka backend, and code from the r2ka backend will be faster and smaller than code from the r2k backend.
There are multiple wait state bugs present in some of the the Rabbits. The difference between the r2k and r2ka port is in additional wait state bug workarounds. If all memory used has zero wait states, code from the r2ka backend can be safely run on the original Rabbit 2000.
Note that The r2k and r2ka port assume that the whole stack has the same number of wait states (code from the r2k and r2ka ports can fail is the stack spans memories with a different amount of wait states).
The Rabbit 2000 has some wait state bugs that SDCC does not work around. These bugs result in the number of wait states used being one less than configured for some instructions. The workaround has to be supplied by the user, by configuring all memories that do use wait states to use on additional wait state.
For all Rabbit ports, SDCC assumes that all data memory is at least as fast (i.e. does not need more wait states) as all code memory. Code where this is not the case (e.g. code in fast Flash writing into slow battery-backed SRAM) will have to be written in assembler by hand.