This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: asm volatile("":::"memory) uncertainty.


Hi David and Andrew,

On 5/10/2016 8:44 AM, David Brown wrote:
On 10/05/16 11:24, Andrew Haley wrote:
On 09/05/16 22:40, Tom Udale wrote:

My confusion is whether or not the memory cobberer prevents movement of
statements in addition to flushing any values that may be in registers
before the compiler_barrier() line.  i.e. it is unclear if there is any
control over what statements the memory being flushed is attached to (if
this makes any sense).

Memory barriers only prevent code which accesses memory from being
moved.

It's not going to be easy to do what you're asking for in the
presence of optimization.  GCC orders instruction generation by
dependency.  I'd simply put all the code you want to time into a
separate function in a separate compilation unit and do this:

   start = starttime();  foo();  end = endtime();

Alteratively, it might be possible to define asm inputs and outputs
so that your asm barriers depend on the statements you're trying
to measure.

Andrew.


An easy way is to make sure your "do some stuff" has at least one thing
that it depends on, and at least one result.  You can even make the
dependencies completely artificial.  But the key is to make this bits
volatile:

volatile unsigned ct;
volatile unsigned time;
volatile unsigned v1;
volatile unsigned v2;

{
	ct = CNT;
	v2 = doSomeStuff(v1);
	time = CNT - ct;
}


I had a feeling that volatile would solve a lot of this. I was hoping there was something a little less of a sledgehammer. volatile unfortunately conflates code movement (which in this instance I care about) with memory caching (which in this instance is fine).

But from what Andrew said it looks like anything that does not touch memory is subject to movement anyway.

Interestingly the code I am struggling with is indeed exclusively memory accesses (to my understanding at least):

while(1)
{
        ct=CNT;
        //...
        // Do a bunch of other stuff.
        //...
        // Record the actual voltage/dacval we programmed above.
        // We want that so we will have a consistent data set
        // for p_calcLoad next time around the loop.
        calcLoad_vDes=vDes;
        calcLoad_vDesShortProt = vDesShortProt;
        calcLoad_rawDacVal32 = rawDacVal32;

        // Increment counters.
        loopIndex++;
        status->stimLoopIndex=loopIndex;
        nextCycleTime+=DBUS_LOOP_TIME;
        status->checkSum=CalcStimStatusCheckSum(status);

        // Record total loop time.
        COMPILER_BARRIER();
        status->stimLoopTime=CNT-ct;
}

The resulting asm is:

 341:cpx_stimdriver.cogc ****   COMPILER_BARRIER();
 627              		.loc 2 341 0
 342:cpx_stimdriver.cogc ****   status->stimLoopTime=CNT-ct;
 628              		.loc 2 342 0
 629 0514 0000BCA0 		mov	r7, CNT
 630 0518 0000BCA0 		mov	r5, r14
 631 051c 0000BC84 		sub	r7, r8
 632 0520 1800FC80 		add	r5, #24
 633 0524 1800FCA0 		mov	r4, #24
 634 0528 0000BC80 		add	r4, sp
 337:cpx_stimdriver.cogc ****   nextCycleTime+=DBUS_LOOP_TIME;
 635              		.loc 2 337 0
 636 052c 0000BCA0 		mov	r8, r13
 637              	.LVL65
 332:cpx_stimdriver.cogc ****   calcLoad_rawDacVal32 = rawDacVal32;
 638              		.loc 2 332 0
 639 0530 0000BCA0 		mov	r10, r12
 342:cpx_stimdriver.cogc ****   status->stimLoopTime=CNT-ct;
 640              		.loc 2 342 0
 641 0534 00003C08 		wrlong	r7, r5
 331:cpx_stimdriver.cogc ****   calcLoad_vDesShortProt = vDesShortProt;
 642              		.loc 2 331 0
 643 0538 0800FCA0 		mov	r5, #8
 644 053c 0000BC80 		add	r5, sp
 645 0540 00003C08 		wrlong	r11, r5
 211:cpx_stimdriver.cogc **** /*<*/   vDes=src->desiredV;
 646              		.loc 2 211 0
 647 0544 0400FCA0 		mov	r7, #4
 648 0548 1C00FCA0 		mov	r5, #28
 649 054c 0000BC08 		rdlong	r6, sp
 650 0550 0000BC80 		add	r7, sp
 651 0554 0000BC80 		add	r5, sp
 652 0558 00003C08 		wrlong	r6, r7
 653 055c 0000BC08 		rdlong	r1, r4
 654 0560 0000BC08 		rdlong	lr, r5
 655 0564 00007C5C 		jmp	#.L12



To my mind, the only reason that these would not be considered "memory references" is because the compiler has already decided to put the memory into registers (true these are mostly automatic variables so they can easily be put into registers). But from an abstract machine standpoint a=b is a memory read and a memory write is it not (or is that a totally incorrect statement)? It seems odd therefore that a register allocation choice can fundamentally alter program behavior.

It appears that the "memory" clobberer is operating at a level much lower than the C statement which means you _really_ need to be careful with it since what is memory and what is not could easily change with the addition or removal of reference (i.e. something that once was held in memory is not any longer because a removed reference made another variable be better suited to the stack allowing the one-time memory variable the better candidate for a register).






You can also use inline assembly to force dependency calculations:

// Ensure that "val" has been calculated before next volatile access
// by requiring it as an assembly input.  Note that only volatiles are
ordered!
#define forceDependency(val) \
		asm volatile("" :: "" (val) : )


So this pretty much creates a NOP reference to val that will ensure it is cannot be moved after forceDependency?

I know that only volatile variables are ordered and can be interleaved with non-volatiles. But your macro works even for non-volatile vals right? My logic being that "asm volatile" prevents the forceDependency from moving. And the reference to val forces val to be fully stored before forceDependency, even if it is a register. No?


As a digression, I guess what is actually needed to solve this problem _completely_ is an explicit keyword that enforces the barrier so no code or data movement occurs.

Would such a thing be difficult to implement? Or is the architecture of GCC aligned against it?

I ask because I think this issue might be a real problem for this target. The timing example I am complaining about above is not the real deal breaker for this target. This is:

// do stuff
doSomthingThatWeMustWaitFor();
waitcnt(CNT+SOMETIMEWEMUSTWAIT);
// do other stuff

or if you are trying to minimize stalled CPU time:

// do stuff
doSomthingThatWeMustWaitFor();
ct=CNT;
// do a little stuff
waitcnt(ct+SOMETIMEWEMUSTWAIT);
// do other stuff


waitcnt waits for clock cycles, so SOMETIMEWEMUSTWAIT can be very small (i.e. you can use it to wait for SPI/I2C clock periods and such). If you waitcnt for a time in the past however, the thread locks until a 0xFFFFFFFF cycles have elapsed. Even at 80MHz, this is a while. Thus if the compiler decides to put a bunch of stuff between the read of CNT and the call to waitcnt, it can lock the thread for about a minute. That would be annoying to discover in a less taken branch. Both CNT and waitcnt are compiler intrinsics that decay to a single opcode so wrapping it all in a noinline function would be a hit.

This is a tremendously common idiom that you see all over code for this target so one can imagine that subtle bugs could creep in easily.

Even making lots of things volatile does not help because even a single non-volatile could sneak in there. You have to make _everything_ non-volatile which would be a tremendous space and time hit.

So having a keyword that would just kill code movement across it would be excellent:

doSomthingThatWeMustWaitFor();
__codeBarrier;
waitcnt(CNT+SOMETIMEWEMUSTWAIT);
__codeBarrier;


If it is not a complete impossibility I might suggest it to the propeller guys.


Anyway, thank you both for your comments and advice.



Best regards,

Tom










Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]