#1009 Is it possible to add support for MCS-251?
A Chinese company, Hefei Macrosilicon Technology Co.,LTD, produces a range of chips based on 80251 (Intel C251). The most popular model, STC32G12K128, has passed automotive-grade testing, while the higher-end STC32G144K246 is currently in the process of tape-out.
Taking STC32G12K128 as an example: besides the common 128B RAM (data) and 128B IRAM (idata), it also includes 4KB XRAM (xdata) and 8KB ERAM (edata); it also has a built-in 128KB Flash (ROM), which can also be used as EEPROM; its operating voltage range is 1.9V-5.5V, with a recommended operating temperature of -20℃~65℃ and a maximum operating temperature of -40℃~125℃; it is equipped with a built-in 1T 35MHz (up to 44MHz) IRC; 49 interrupt sources; 5x16Bit timers; 4xUARTs; 2x 16Bit 8CH HSPWM; 3xSPI (1 set independent, 2x multiplexed UARTs); 3xLIN (1 set independent, 2x multiplexed UARTs); 2xCAN; 1xI2C; 15CH x12Bit ADC; 1xUSB2.0/1.1 (6 Bi-EP x 64Bytes Cache); up to 60 GPIOs, supporting independent interrupts, with a built-in programmable 4K ohm pull-up resistor; built-in RTC, WDT, MDU32, supporting 8080/6800 8B/16B parallel bus interfaces, etc.
All of the above costs less than 0.5 USD. Here is its documentation link: Unfortunately, it currently only supports Chinese. I really love this chip, but SDCC doesn't support it at the moment. Is there any possibility of adding support for it in the future?
In all honesty, considering the limited (human) resources of the project, an SDCC port natively targeting the enhanced feature set of the MCS-51 architecture is at the very least not something I see happening any time soon.
However, since MCS-251 is reportedly fully backwards compatible with MCS-51, there is a viable pathway to get a somewhat enhanced solution:
Since SDCC uses a library of support functions for many things exceeding basic 8-bit integer arithmetic and logic, an external contributor, who needs no compiler development experience, could create a version of this support library optimized for the MCS-251 architecture.
The same applies to the C library, where e.g. widespread string functions could be optimized.
It's probably harder than that: currently SDCC targets effectively only 8-bit processors, with a very limited number of registers, and the "more interesting" features of that 251 seem to be 16/32-bit instructions with a lot of registers, which, as far as I understand, is just not what SDCC code is currently designed for.
I fully understand that this does not align with the original intention of SDCC. The MCS-251 architecture is in a rather awkward position, as there are other better architectures available for 32-bit microcontrollers.
Even so, I still believe that developing a toolchain based on SDCC is easier than one based on GCC. I once wanted to modify it myself, but found that the complexity of SDCC far exceeds my programming proficiency. So I came here to seek help from experts.
Looking at MCS-251 documentation, I see some similarities to the Rabbit 4000:
I think, for register allocation and code generation the approach similar to the r4k port could work:
So SDCC could treat this as an MCS-51 with additional instructions, and ignore the additional registers.
However, one complication is that AFAIK, the mcs51 port in SDCC is little-endian, while MCS-251 is big endian.
The 4KB XRAM of this chip can be used as a stack, which is highly suitable for real-time operating systems such as FreeRTOS or μC/OS-II. If it is merely regarded as an MCS-51 core with additional instructions, I believe porting it would be extremely challenging and would waste its performance.
I don't see a problem with the stack. We already have multiple memory models, and the --xstack option, I think we could add some point in the future add another option to fully use the wider stack pointer of the MCS-251. But I am not familiar enough with MCS-251 yet for all the details.
At first sight, treating it as a MCS-51 with additional instructions. would just mean not being able to use registers R8-R15, WR8-WR30, DR8-DR28.
AFAIK, DR56 and DR60 have a special role, since they alias with the data and stack pointers, so we'd actually be using those as an alternative way to access these, where doing so is more efficient than via sfr.
Okay, let me give it another try!
No matter which way this goes (standard lib only, as @roybaer proposed, mcs51 variant, as I proposed, totally separate cs251 port, or just using mcs51 as-is), the first step would be to have MCS-251 support in the assembler (needed for everything), the second step would be support in uCsim (needed for regression testing, and thus any type of SDCC port).
Even just having MCS-251 support in the sdas assembler would already be a benefit to STC32 users, since they could use hand-written MCS-251 asm for speed-critical parts in what is otherwise a program compiled by SDCC targeting MCS-51.
Assuming this would be a variant of the mcs51 port: IMO the mcs51 port needs a rewrite to use the new register allocator, which would also bring substantial changes in code generation. I wouldn't want to add support for mcs51 before that. Also AFAIK, SDCC developers will be busy with rabbit and TLCS support, and some other tasks for this and next year. So assuming everything goes according to plans, we'd see work on changes int eh mcs51 port at the earliest in late 2026, probably rather in 2027. An mcs251 port would come after that.
But we might note the MCS-251 at https://sourceforge.net/p/sdcc/wiki/8051%20Variants/ to keep it in mind.