Closed spth closed 5 years ago
I see you now added ldsptl and ldspth. Maybe it should be documented that these are undocumented? Also I am wondering if there is also an instruction that loads from a to the stack?
Philipp
I see you now added ldsptl and ldspth. Maybe it should be documented that these are undocumented?
Since all instructions are "undocumented" I see no difference here :-)
While the opcodes corresponding to the instructions are undocumented, there is still a difference: For ldsptl and ldspth, it is even undocumented, that they exist at all, while for the other instructions, the instructions and their behaviour are specified in the datasheets.
Philipp
I created a test program and fully observed the behavior of LDSPTL/LDSPTH.
Documents been updated accordingly.
The documented ltabl and ltabh instructions from the 16-bit instruction set are still missing from the wiki.
Philipp
I noticed your post http://www.eevblog.com/forum/blog/eevblog-1144-padauk-programmer-reverse-engineering/msg1970672/#msg1970672
And the one feature IMO missing the most from the Padauk devices is an efficient way to access the stack. Could ldsptl and ldspth be stack load instructions? If yes, they would be a useful feature for implementing C. By far not as useful as having an sp-relative addressing mode, but still useful. Since there are no arguments, I would assume they transfer a byte between stack and accumulator.
It would make sense to have two (one for the lower byte of the word on the stack, one for the upper byte of the word on the stack): The stack pointer is meant to be increment / decremented by multiples of 2 only (I don't know why, but that is what the datasheets say, even though they insist that the stack pointer is a full 8 bits wide).
Philipp
P.S.: The ldtabh and ldtabl you mentioned in the same post are actually a documented instruction in the 16-bit instruction set. They can be found e.g. in the MCS11, PMC884 and PMC251 datasheets.