Modifying SSP on the 'c5515

John,

You should be able to modify the SSP according to the C55x v3.x CPU Ref Guide (http;//www-s.ti.com/sc/techlit/swpu073), sec 2.6.7.  I've never tried to do this myself.  What are you seeing?

I looked in the Mnemonic Assembly Language User Guide (http://www-s.ti.com/sc/techlit/swpuo67), Table 4-1, page 4-21 and it seems like your second example should work.

Regards.

Tommy,

Yes - I agree that:

mov *sp(#3), t3
mov t3, *ssp(#1)

should work - but it doesn't.

Thanks,
John W.

John,

Can you be more specific about what doesn't work means?  Better yet can you send me a simple project that demonstrates the problem?

Regards.

TommyG,

This is pretty easy to reproduce - just put the following into an assembly file and try to compile:

mov *sp(#3), t3
mov t3, *ssp(#1)

You'll have to be in mneumonic (normal) mode and you'll  have to have direct addressing enabled.

The compiler will spew out at least 3 errors - I will include that in a subsequent post if that will be helpful.

Thanks,
John W.

John,

I think I misunderstood what you are trying to do.  I was paying attention to the words and not the code.  You want to modify the contents of the memory pointed to by the SP/SSP and not register contents themselves correct?  If that is the case, then what you are proposing will not work. 

You can access the stack contents using stack mode direct addressing (CPL=1), but your instruction would look like:
          mov #3, t3. 
The address generator will automatically use the SP for the base address, then add an offset of 3.  See http://www-s.ti.com/sc/techlit/swpu067, sec 3.3.2

For the memory pointed to by the SSP you don't have a similar addressing mode.  You would need to copy the contents of the SSP to an auxillary register, then use indirect address mode to modify the memory location with the contents of T3 from above.  Something like:
          mov SSP, AR1
          mov t3, *AR1

Regards.
    

TommyG correctly points out that the basic issue is that there are no address modes to address SSP+offset, so you need to use one of the auxiliary registers to do the addressing.  I have two additional comments.

First, unless you know AR1 and SSP are both always addressing the same memory page, you will need to do 

      mov  XSSP, XAR0   ;  get all 23 bits of the system stack pointer
      mov  T3, *AR0         ;    (or, I think in your example, mov T3, *AR0(#1))

Second, the CPU manual (swpu067) seems to give precious little information on what the assembler syntax is for the direct addressing modes (sec 3.3).

SP Direct Addressing Mode, available when CPL=1, is written as *SP(#k).
DP Direct Addressing Mode, available when CPL=0, is written as @#k

You can tell the assembler which mode will be in effect at runtime using the .CPL_ON and .CPL_OFF directives.  If neither of these directives has been given both of the above forms of operand are accepted.  When one of the directives has been given only the corresponding form of the operand is accepted by the assembler until another directive appears.  Of course, no matter what is written in the assembly language what actually happens at runtime depends on the setting of the CPL status bit.

TommyG,

OK - I guess that should be easy enough to do - I thought maybe there was some *SSP(#offset) commands (or syntax) that was available - I will try this (AUX register method) and report back to you.

Thanks!
John W.

Paul,

Yes - thanks for pointing this out, I will certainly make sure all instructions are pointing to memory that are on the same page.

I agree that there is precious little information on the assembler syntax for direct addressing.

I will likewise report my results to this thread.

Thanks!
John W. 

Hello Paul and TommyG,

The auxiliary register indexing works fine for SSP - thanks for suggesting that - seems something like

mov *sp(#1), *ssp(#1) should work - 

Have another quick question - why won't something like this work:

mov *sp(#-1), ar0 ?  I thought you could index negatively as well as positively - but I guess not.

Thanks,
John W.

John,

There is a better explanation of how the address generator works in the CPU Reference Guide (http://www-s.ti.com/sc/techlit/swpu073), sec 6.3.2.  The offset can only be a number from 0-127.  Just the way the HW works.

Regards.

You can use a signed constant offset with AR indirect operands like *ARn(#K16).  But as TommyG points out the address mode that allows you to address offset relative to the SP only takes a 7-bit unsigned offset, thus covering a range of 0..127.  If this were a signed offset seven bits would support a range -64..63.  But a negative offsets relative to the SP is of very little use.  This is primarily due to the fact that interrupts, which of course occur asynchronously with respect to the program flow, use the SP (and sometimes the SSP) stack to save and restore state.  Thus, anything a program might store at a negative offset from the SP could be overwritten if an interrupt occured while the program was executing.  This makes addressing negative offsets relative to the SP pretty much useless.

Hello TommyG,

OK - thanks again - I will review that.  Can't expect the hardware to do something it wasn't designed to handle.

Best Regards,
John W.

Paul,

I agree with you.

When I am doing this stack 'fix-up' - interrupts are of course disabled.  Otherwise, no stack fix-up really makes any sense.

Of course, non-maskable IRQ's can still occur - but that is always true.

Thanks,
John W. 

So you can see why some of those addressing modes are not there.

On C55x opcode encoding space is already filled up with lots (and lots) of specialized, high-performance instructions, so spending some of that space to encode negative offsets relative to SP just did not have much of a priority.  From the compiler writers point of view, we wish the *SP(k7) would have had even more bits for the constant, but after the tradeoffs were made we got seven.

Paul,

Yes, I can understand why having negative offsets relative to the SP didn't have much of a priority.

It would have been nice to get more than 0..127 for the offset, I agree.

Do you work in the tools group, then?

Thanks!
John W.