Forums

Hi jmP,

PUSH and POP can take any argument addressible for Format-II instructions; hence you can pass the address of u in your inline assembly like this

asm("PUSH.W &u");

I would caution using this in C though, since the compiler may decide to just optimize away the reference to u.

Tony

TonyKao

I would caution using this in C though

Absolutely!

Quite apart from optimisation, when you program in any High-Level Language (HLL) - including 'C' - you delegate low-level details like stack management to the Compiler.

The Stack is no longer yours to mess with - You can't just go arbitrarily PUSHing and POPping stuff to/from the stack!!

Andy Neil

The Stack is no longer yours to mess with - You can't just go arbitrarily PUSHing and POPping stuff to/from the stack!!

There are still legitimate situations in which you'd have to manually access and modify the stack, for example when you're interfacing C with assembly routines. This can be less perilous if both the compiler and the programmer follow some sort of calling convention (like the ARM EABI), so how both sides interact with the stack is well-defined.

But yes, I agree with you. :)

Tony

For interfacing 'C' with assembly, you would let the compiler do its thing, and have the assembler comply...

Hi all,

You are all right with your answers in the case of a general high-level C++ application: I can't manage the stack for my own.

But my case is a low-level C application, like in ancient automation where inputs and ouputs were scanned and acted in an infinite loop.

Where the stack can be managed? Inside an endless function, typically the main() function. That's what I'm doing.

2 years ago, I implemented my Corth language in an ATtiny85 application, avrgcc compilation, with these PUSH & POP  functions:

static inline void PUSH (uint16_t u)
{
	asm volatile (
		"push %B0" "\n\t"
		"push %A0" "\n\t"
		:
		: "r" (u)
	);
}
static inline uint16_t POP ()
{
	uint16_t result;
	asm volatile (
		"pop %A0" "\n\t"
		"pop %B0" "\n\t"
		: "=r" (result)
	);
	return result;
}

Today, I try doing the same with CCS and a msp430g2231/2553 but it's seam impossible else using the temporary R4 regisgter. It's why I ask for these 2 new intrinsics.

jmP

Hi Tony,

TonyKao

PUSH and POP can take any argument addressible for Format-II instructions; hence you can pass the address of u in your inline assembly like this

1	asm("PUSH.W &u");

I would caution using this in C though, since the compiler may decide to just optimize away the reference to u.

Yes, this is a solution but with one restriction: u must be a global variable. The code is shorter if the regisgter R4 is free and I can use it.

jmP

Jean-Marc Paratte

Today, I try doing the same with CCS and a msp430g2231/2553 but it's seam impossible else using the temporary R4 regisgter. It's why I ask for these 2 new intrinsics.

As I mentioned before, you can directly address the variable with PUSH and POP; just pass the address by reference to the inline asm(). You can pretty much PUSH and POP everything within the 16-bit (20-bit for CPUX) address space of the MSP430.

I do think that this kind of low-level programming is best done in pure assembly instead of inline assembly within C; as Andy mentioned it's really up to the compiler how the stack is managed. Even within a main with no external function calls, there can be lots of push and pop to and from the stack by the compiler, especially if there are more locals than general purpose registers. Your approach can result in unpredictable behaviour in that case.

Tony

Jean-Marc Paratte

Yes, this is a solution but with one restriction: u must be a global variable.

I think you're confusing assembly and C. There's no such thing as a "global variable" in assembly, since there's no scope to speak of. In fact, u is actually passed as R12 if you use IAR since that's their function calling convention for parameters. R12 is also the register used for return values. So what you do is you PUSH and POP R12.

However, and this is the irony, your original "u" before it was passed into PUSH() may already be pushed onto the stack!

Tony

TonyKao

However, and this is the irony, your original "u" before it was passed into PUSH() may already be pushed onto the stack!

Tony

...

inline void PUSH (int16_t u)
{
	_set_R4_register(u);
	asm(" PUSH.W R4");
}
inline int16_t POP ()
{
	asm(" POP.W R4");
	return _get_R4_register();
}

...

...

void main (void)
{
...
	PUSH(0);
	PUSH(0);
...
	for (;;)
	{
...
	}
}

	.dwpsn	file "../2231-uart-half1.c",line 850,column 2,is_stmt
        MOV.W     #0,r15                ; [] |850| 
        MOV.W     r15,R4                ; [] |850| 
	.dwpsn	file "../2231-uart-half1.c",line 851,column 2,is_stmt
 PUSH.W R4
	.dwpsn	file "../2231-uart-half1.c",line 850,column 2,is_stmt
        MOV.W     r15,R4                ; [] |850| 
	.dwpsn	file "../2231-uart-half1.c",line 851,column 2,is_stmt
 PUSH.W R4

	.dwpsn	file "../2231-uart-half1.c",line 850,column 2,is_stmt
        MOV.W     #0,r15                ; [] |850| 
	.dwpsn	file "../2231-uart-half1.c",line 851,column 2,is_stmt
 PUSH.W R15
	.dwpsn	file "../2231-uart-half1.c",line 851,column 2,is_stmt
 PUSH.W R15

Jean-Marc Paratte

But my case is a low-level C application

Example: on MSPGCC (whcih allows for the same inlien assembly syntax your demo code uses), calling printf (with arguments on stack) causes the compiler in maximum speed optimization to not pop the arguments from stack after the call. This is done at the end of a code block. If you push on stack inside the code block and pop after it, you'll pop something you didn't push, and in the meantime things will be assumed on stack yb the compiler which aren't there.

Even if you tell the compielr that your inline code clobbers the stack pointer, it won't prevent the optimizer from crashing the use of your local variables.

If you really want to push something onto a stack, make your own stack for these values. Easily done with an array and an index variable. And if you're lucky it is compiled into something that isn't much longer than a push/pop.

static volatile uint16_t myStack[100];
static volatile char myStackPtr = 0;
static inline void PUSH (uint16_t u) { myStack[myStackPtr++]=u;}
static inline uint16_t POP (void) {u = myStack[--myStackPtr];}

It even implements the possibility of a stack over/underflow :)

Jean-Marc Paratte

Now examine the produced asm file in the region of the twice PUSH(0); :

?

1 2 3 4 5 6 7 8 9

.dwpsn  file "../2231-uart-half1.c",line 850,column 2,is_stmt        MOV.W     #0,r15                ; [] |850|        MOV.W     r15,R4                ; [] |850|    .dwpsn  file "../2231-uart-half1.c",line 851,column 2,is_stmt PUSH.W R4    .dwpsn  file "../2231-uart-half1.c",line 850,column 2,is_stmt        MOV.W     r15,R4                ; [] |850|    .dwpsn  file "../2231-uart-half1.c",line 851,column 2,is_stmt PUSH.W R4

I guarantee you that this is pretty much what AVR-GCC also generated for your code.

In fact, to confirm my hypothesis, I ran your original code for the AVR through AVR-GCC, and this is the disassembly

main:
//PUSH(0);
	ldi r24,lo8(0)
	ldi r25,hi8(0)
	push r25
	push r24

//PUSH(0);
	ldi r24,lo8(0)
	ldi r25,hi8(0)
	push r25
	push r24

Isn't that the same as what you got with the assembly generated for MSP430? The asm volatile syntax for the GCC actually uses temporaries to assign the parameters for the inline assembly, which is no different from using scratch registers.

Again, this is all running circles around the compiler, to prevent the compiler doing what it's supposed to do; I really think you should reconsider your approach.

Tony

TonyKao

I guarantee you that this is pretty much what AVR-GCC also generated for your code.

No,no, don't mess with the stack or do everything on your own (in assembly) from first manipulation until last cleanup.
(Well, that's what I've done with my multitasking module).

P.s.: in the original example of a PUSH(0), the only required assembly instruction is a "PUSH #0" , sicne the MSP can push and pop immediate and indirect and even indexed, and not just registers. (well, pop immediate won't make much sense), since POP is just a post-incremented SP-indexed MOV. (and PUSH the specific counterpart as the MSP doesn't know a pre-decrement indexed source mode)

I would like to have 27, instead of 2, new intrinsics ? One for each machine code. This way we can write machine code in c ;)

Jens-Michael Gross

If you're really unlucky, the compiler was saving R4 on the stack before performing the operation, tehn the push is executed without the compiler knowing that the stack pointer changes, then it tries to load R4 back from stack and instead fetches your pushed value.

Not true, please consider checkbox: Project >> Properties >> Tool Settings >> MSP430 Compiler >> Runtime Model Options >> Reserve a register for use by the user. (--global register) [r4].

jmP 

Jean-Marc Paratte

Not true, please consider checkbox: Project >> Properties >> Tool Settings >> MSP430 Compiler >> Runtime Model Options >> Reserve a register for use by the user. (--global register) [r4].

However, my comment was generic to any compiler, adn actually not limited to R4. Any register that is pushed by the compile rbefoer your push, and pooped before your pop will be clobbered with unpredictable results. It would be pure coincidence or require in-depth knowledge of the currently used compilers inner workings to be sure that no accident happens.

The solution I provided above is 100% safe, portable across compilers, not much less efficient and also plain C (except for the arguments, since access to a processor register is not in the C language scope and therefore requires a compiler-specific intrinsic).