+TheBF Posted February 23, 2021 Share Posted February 23, 2021 Just now, Lee Stewart said: should be * * POP * MOV *SP+,Rn ...lee Thank you! Quote Link to comment Share on other sites More sharing options...
apersson850 Posted February 23, 2021 Share Posted February 23, 2021 Yes, these two/one instruction(s) are what I typically use for PUSH and POP. I prefer letting the stack grow towards lower addresses, since there is auto-increment, but not decrement, in the repertoire. It also means you can copy the value at TOS by just accessing *SP, since the stack pointer always points at top of stack. If you write an operating system, or utilities for others to use, then you may want to check for stack overflow. If you write a specific program for yourself, and just push return links, not large data structures, to the stack, then it's not worth the overhead. If you do get a stack overflow in such a case, you have either severely underestimated the stack space you need, or you have created some bug which causes values to just PUSH, not POP. Writing macros for the PUSH and POP functions reduce the risk you forget a "+", like in the example above. I frequently used macros for Branch with Link to Stack and ReTurn with Link from Stack, i.e. instructions including the push and branch for a call and pop and branch for a return. 2 Quote Link to comment Share on other sites More sharing options...
adel314 Posted May 13, 2021 Share Posted May 13, 2021 (edited) On 2/22/2021 at 1:32 AM, TheBF said: I have never used the XOP instructions but that seems like a lot of code to do PUSH and POP plus the BLWP/RTWP overhead. I suppose if the Assembler does not support macros this provides some abstraction. (?) Push can be two instructions and pop can be one instruction on 9900. Could that work on your system? Just re-reading your comment on never having used XOP instructions, I thought I would pass my latest use of them on, which might be of interest to the community. Why I never thought of this before is surprising, and would have saved me months of debugging time over the years, but there you go. For example, if you define an XOP as say DEBUG using code similar to DXOP DEBUG,15 Then, in your programme code that needs to be debugged you can add the following: . . 014E 0200 0003 LI R0,3 0152 0201 0006 LI R1,6 0156 8040 C R0,R1 0158 2FE0 0208 DEBUG @TRACE_BUF 015C 8001 C R1,R0 015E 2FE0 0228 DEBUG @TRACE_BUF 0162 0A10 SLA R0,1 0164 2FE0 0248 DEBUG @TRACE_BUF . . 0200 TRACE_BUF: BSS 36 ;Used to store the trace data . and the code in DEBUG(XOP) can produce, during execution, something such as this: PC = 015C ST = 1004 R0 =0003 R1 =0006 R2 =0088 R3 =0000 R4 =0500 R5 =7285 R6 =8D77 R7 =574D R8 =F2C0 R9 =01C6 R10=0204 R11=9044 R12=8000 R13=D411 R14=1C7B R15=0004 PC = 0162 ST = D004 R0 =0003 R1 =0006 R2 =0088 R3 =0000 R4 =0500 R5 =7285 R6 =8D77 R7 =574D R8 =F2C0 R9 =01C6 R10=0204 R11=9044 R12=8000 R13=D411 R14=1C7B R15=0004 PC = 0168 ST = C004 R0 =0006 R1 =0006 R2 =0088 R3 =0000 R4 =0500 R5 =7285 R6 =8D77 R7 =574D R8 =F2C0 R9 =01C6 R10=0204 R11=9044 R12=8000 R13=D411 R14=1C7B R15=0004 The DEBUG XOP 15 code is simply (the formatting code is left out but if anyone is interested I can post it), ; ; NOW SAVE THE TRACE DATA ; XOP15: EE30 CECE MOV R14,*R11+ ;STORE PROGRAMME COUNTER FIRST EE32 CECF MOV R15,*R11+ ;STORE STATUS REGISTER EE34 0208 0010 LI R8,16 ;16 REGISTERS EE38 CEFD XOP_LOOP: MOV *R13+,*R11+ ;COPY REGISTERS EE3A 0608 DEC R8 EE3C 16FD JNE XOP_LOOP EE3E 022D FFE0 AI R13,-32 ;RESTOR WORKSPACE REGISTER LOCATION Edited May 14, 2021 by adel314 Additional comment 5 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.