Does anyone know what the undocumented RL78 SFR located at 0xffff8 is and/or what it does ?
The CRT longjmp() function appears to store the address of the jmp_buf argument into this address at the start of the function execution.
Regards,
Steven J. Ackerman
ACS, Sarasota, Florida
Which compiler are you using?
Can you provide a screen-shot of what you are observing?
I don't see this behavior using CC-RL, which is where I would expect to find any "hidden" SFR usage if there was any. As this is a lib-function, it is not specific to G14 so this would seem very unlikely behavior.
Thanks for your reply.
Using CC-RL v1.10. Experimenting with some 'coroutines' done using setjmp/longjmp. The code basically works, but I was interested in seeing what the overhead was, so I examined the code for the two functions:
setjmp:
000051df: movw de, ax ; point to jmp_buf arg
000051e0: movw ax, sp ; save sp into jmp_buf[0]
000051e2: movw [de], ax
000051e3: movw ax, [sp] ; save return address into jmp_buf[1]
000051e5: movw [de+2], ax
000051e7: movw ax, [sp+2]
000051e9: movw [de+4], ax
000051eb: clrw ax ; return zero
000051ec: ret
longjmp:
00005146: movw de, ax ; special treatment of jmp_buf[0] arg…
00005147: movw ax, [de]
00005148: movw 0xffff8, ax ; is this accessing the sp ?
0000514a: movw ax, [de+2] ; restore return address from jmp_buf[1]
0000514c: movw [sp], ax
0000514e: movw ax, [de+4]
00005150: movw [sp+2], ax
00005152: movw ax, bc ; check val == 0, and return 1 instead
00005153: cmpw ax, #0
00005156: sknz
00005158: incw ax
00005159: ret
Hello,
Yes, this is the address stack pointer register:
https://www.renesas.com/us/en/document/mah/rl78-family-users-manual-software-rev230
Also, I would recommend updating to the latest CC-RL 1.13.
Thank you.
I had this manual, but didn't look in it for this SFR. This table of fixed SFRs doesn't appear in the G13 or G14 hardware manuals.
I wonder why this addressing mode was used instead of MOVW SP, AX...
Oh well, thanks for clearing that up.
I believe what you are seeing is a result of the disassembler rather than using a different insn.
00005148: movw 0xffff8, ax ; is this accessing the sp ?0000514a: movw ax, [de+2] ; restore return address from jmp_buf[1]
It would appear that the insn "movw 0xFFF8,ax" is only 2-bytes (0x514a - 0x5148), which tells me that the disassembler has interpreted the "movw sp,ax" as what was displayed. If you can view the opcode / operand this could be confirmed. Opcode "BE" is the 2-byte insn for "movw sfr,AX" while the "BF" opcode would be the 3-byte insn "movw !addr16,ax".