Hi, Stephan
Here is a post about LDREX and STREX,
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka8404.html
it is said that:
1: The Snoop Control Unit allows a cache line accessed by an LDREX instruction
to exist in only one L1 data cache in the MPCore - in MESI Modified state.
Is this statement correct?
Thanks!
Zhiguo
-----Original Message-----
From: GE ZHIGUO
Sent: Tuesday, October 08, 2013 11:34 AM
To: 'Stephan Diestelhorst'; gem5-users@gem5.org
Cc: sa...@umich.edu
Subject: RE: [gem5-users] About LoadLockReq packet attribute
Hi,Stephan
Thanks for your reply!
Sorry that I did not show all the code of the implementation of spin_lock. The
barriers are there and
they are in the right place as you suggested.
Can you please continue to advise?
The detailed implementation of spin_lock and spin_unlock are:
#define DATA_MEMORY_BARRIER \
{\
Unsigned int temp = 0; \
__asm {MCR p15, 0, temp, c7, c10, 5};\
}
Inline void spin_lock(volatile unsigned int *plock)
{
Int temp, lockvalue = 1, result;
Int I = 0; j = 1;
Int r = 0;
Do {
__asm {LDREX, temp, [plock]};
If (temp == 0) {
__asm {STREX result, lockvalue, [plock]};
If(result == 0) {
break; //succeed
}
}
} while (1);
DATA_MEMORY_BARRIER
}
Inline void spin_unlock(volatile unsigned int* plock) {
DATA_MEMORY_BARRIER;
*plock = 0;
}
When compile the above code with --O0 flag using armcc, the generated assembly
codes of
Spin_lock and spon_unlock are:
spin_lock:
27c: PUSH {r4-r7, lr}
........
294: LDREX r1, [r0]
298: CMP r1, #0
29c: BNE 0x2b0 //RELOAD
2a0: STREX r2, r3, [r0]
2a4: CMP r2, #0
2a8: BNE 0x2b0 //RELOAD
2ac: B 0x2b4 //succeed lock
2b0: B 0x294
2b4: NOP
2b8: MOV r4, #0
2bc: MCRp15, #0x0, r4, c7, c10, #5 //barrier
2c0: POP {r4-r7,pc}
spin_unlock:
2c4: MOV r1, #0
2c8: MCR P15, #0x0, r1, c7, c10, #5 //barrier
2cc: STR r1, [r0, #0]
2d0: BX lr
Best regards,
Zhiguo
-----Original Message-----
From: Stephan Diestelhorst [mailto:stephan.diestelho...@arm.com]
Sent: Tuesday, October 08, 2013 12:02 AM
To: gem5-users@gem5.org
Cc: GE ZHIGUO; sa...@umich.edu
Subject: Re: [gem5-users] About LoadLockReq packet attribute
Hi,
you need to properly order the lock acquisition with the counter
manipulations, for example as below (or see
http://lxr.free-electrons.com/source/arch/arm/include/asm/spinlock.h
or
http://blogs.arm.com/software-enablement/188-locks-swps-and-two-smoking-barriers-part-2/
)
On Monday 07 October 2013 02:54:08 GE ZHIGUO wrote:
> The disassembly codes of the spin_lock are like follows:
>
> LDREX r1, [r0]
Option 1) Use an LDAEX here (but is a v8 thing)
> CMP r1, #0
> BNE RELOAD
> STREX r2, r3, [r0]
> CMP r2, #0
> BNE RELOAD
Option 2) (v7) Use a DMB here.
> B LOCK_SUCCESSFUL
...
Freeing the lock:
Option 1) (v8) Use STL to free the lock
Option 2) (v7) Use a DMB here, and then store.
[...]
> I set each CPU does about 10000 iterations and the final value of the
> counter should be 20000, however, The actual number is not 20000, but
> around 19999, or 19997.
Can you please re-test with the changes suggested above? (v7 for now in
Gem5).
> I debugged and found that in some cases, two CPUs can obtain the mutex
> simultaneously and both CPUs enter the critical section.
That should not happen, regardless of the counter breakage. How did you
debug this?
Thanks,
Stephan
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered
in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
