The same header files come with Simplicity Studio. But it seems only mcs51 is highly affected, so I can live with further restricting the use of this macro. But please at least mention its deprecation in the release notes.
AFAIK ds400 is a ds390 with some extra peripherals.
The old IDE can display multibyte variables in proper endianness, where Simplicity Studio cannot. And it can invoke SDCC which Studio can't. Of course changing one header file is much easier than all the rest that is required for suppoting SDCC. And any user could change the file as well. But this change is required by every user who downloads the files. And again after every update. And all this to please your feeling about standard compliance. And without warning of deprecation when building with...
I would not mind for this SDCC_PARMS_IN_BANK1 to be replaced by a standard-compliant one. I very much doubt anyone uses it. I even expect the whole option can be removed without anyone noticing.
Is it really too hard to type r9887 between brackets [r9887] instead?
I worked hard to get Silicon Labs to support SDCC in the past and managed to get them to deploy compiler independent header files by the use of this SDCC macro. In the meantime they changed their IDE to an Eclipse based one and it's once again Keil only. Can I assume that you will convince them to update their header files? Or can we expect this change to be the final push for them to abandon SDCC completely?
I expect (haven't checked) the cast to give higher register pressure than letting genPlus() do the sign extension. The downside could be that we can't do CSE on it. Laziness to implement something in all backends is hardly a good reason if there is efficiency to be gained. But for that we must first find out if it really is more efficient. I wonder how this fix affected Z80 code with its IX+<nn> access instructions. Isn't <nn> a signed char here?
Philipp, why are you so strong about removing this one important macro? This was the first macro to indicate the SDCC version to the code being compiled. There is a lot of code out there that depends on it. I suggest it to be reinserted. It already was only issued when sdcc extensions were enabled.