#3123 Implement missing __sfr16 load / fix __sfr16 store

[Free-PDK]

As reported in forum, the __sfr16 load is unimplemented and __sfr16 storemight have alignment problems: https://www.eevblog.com/forum/blog/eevblog-1144-padauk-programmer-reverse-engineering/msg3262818/#msg3262818

Suggested (safe) implementation:
Use the virtual p register (word aligned memory location) for ldt16/sst16 instructions and copy byte wise the result.
__sfr16 load could be implemented with this sequence:

ldt16 p
mov a, p
mov <dest>, a
mov a, p+1
mov <dest>+1, a

same logic for __sfr16 store.

Since loading / storing the 16 bit timer is a very seldom thing to do I think using 5 instructions for it and avoid any kind of alignment problems seems to be the best scenario.

[Free-PDK]

add: with this method many / all? of the "TODOs" in "pdk/gen.c" could be handled.

[Philipp Klaus Krause]

__sft16 store already works for values < 256.

However, a general solution is more complicated:

Currently, SDCC only uses the p register. p + 1 is always kept at 0. For idxm, p + 1 should be 0 according to Padauk documentation. So we'd need to zero it after use. More important, we could no longer rely on it being 0 in the interrupt handler, so we'd have to save and restore it, increasing interrupt latency.

[Free-PDK]

I did some tests with IDXM and some other values in hi byte of 16 bit index...
=> And of course it wraps around (like everything else on this IC).

So unless you have some strong indication that there will be an IC with >256 byte RAM in future the "p+1" can just be any value. It simply is ignored.

Not sure where this comment in datasheet initialy came from. For sure it is copied from datasheet to datasheet for no reason.

I vote for "p" as a general purpose register, ignoring the idxm hi byte "should be zero" comment which I tested is NOT required...

[Free-PDK]

I checked some more "stuff" from PADAUK and for some reason they also always init the hi part of IDXM pointer to 0 ... so maybe there is a requirement for this on some ICs.