If it uses the conventional SFR's then it uses the conventional I/O mechanism (peripheral) as well, else there wouldn't be an point in having the SFR.

If the I/O mechanism is absent, then the code using it shouldn't be there either.

I can't imagine using an SFR in any other way. Maybe I'm asleep.

Now, the standard SFR's refer to features of the standard peripherals. Extended SFR's of which there are many, for example, in the DS89C4x0 family, and probably in those SIlabs parts you like so well, Erik, are needed to support the extended peripheral functions. If they're not there, their SFR's shouldn't be, either. If that's the case, then the SFR's can be redefined in accordance with whatever hardware changes have been implemented.

If there's no hardware that uses the SFR's, which is hard to imagine, since the peripherals are mapped into the SFR space, which, by another name, can be called I/O space, then there's no I/O. OTOH, if there's no standard serial port and no standard timers, then the associated SFR's certainly aren't needed, even if the parallel ports are there.

Now, as for that "minor" change I was/am considering for the serial port TI/RI bit(s). If it is present and (1) indicates that a transmit or receive operation is complete, or (2) generates an interrupt, then if writing/reading the serial data buffer clears the bit, which was the initial thing I asked about, nothing should be harmed. If you are using "old" code, and it then clears the bit, who cares? It's already cleared. If the code does care, for some reason, then the code clearly will not be useable as-is, but it actually saves some time, meaning that there's a chance that mode 0 could become useful for synchronous communication, which, presently, it's not.

Do you see a problem with that?

RE