1806 Adaptation – Ugly On the Inside
I noted that the 1806 hardware subroutine call and return operation use the stack a bit differently than my software implementation. A matter of whether you decrement the stack pointer before you store or after. I chose before and they chose after. I remember thinking long and hard about this and deciding my way was better – oh well. It’s essentially arbitrary but because parameters and local variables are stored on the stack, I have to pick one regime and stick to it. As a short term kludge i am attempting to paper over the differences as follows:
- Before each SCAL instruction I decrement the stack pointer so it’s pointing to free memory. On entry to each function i increment the stack pointer to reverse this.
- Before each return I decrement the stack again and after each I increment it (the after case is embedded in the ccall macro).
This is awful but I think it will work in the short term to keep me going. When I get home with the text available I’ll attempt to unwind this and do the right thing: changing my push/pop regime; changing the offsets from the stack pointer for variables and parameters.
;the 1806 SCAL does not decrement SP before pushing the return address ;and the SRET increments it before reloading it ;to accommodate my convention I bracket call/returns with inc/dec as required ;note that the function prolog contains a call to adjspfor1806 which completes the cycle adjspfor1806: macro ;need to inc the stack to accommodate 1806 - kludge if MOMCPU=$1805 inc 2 ;leaves sp pointing to last byte of return address endif endm Ccall: macro target if MOMCPU=$1805 sex 2 dec 2 SCAL 6 dw target inc 2 else sep RCALL dw target endif endm Cretn: macro if MOMCPU=$1805 dec 2 sret 6 else sep RRET endif endm
I always want the last word so that wordpress doesn’t eat my code!