p4040 memory barrier related query.

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

p4040 memory barrier related query.

ソリューションへジャンプ
786件の閲覧回数
vasanthsri
Contributor III

Dear All,

We have few packs of application source code written in PowerPC set in which an instruction eieio is heavily used. In this new core (e500mc), the eieio instruction opcode executes as mbar. Could someone help us with below queries.

1. Any additional overhead on executing mbar instead eieio?

2. Any easy way to set?replace this instruction with M0=1 ? Unfortunately, we don"t have HID bit as like we had in previous e500vx cores :smileysad:

Changing the asm code will be heavy task as there are many number of lines which needs to be replaced such.

Thanks.

ラベル(1)
タグ(3)
0 件の賞賛
1 解決策
500件の閲覧回数
scottwood
NXP Employee
NXP Employee

I don't know of any way to make mbar trap.  Even if you could, that might add more overhead than mbar 1 would remove.

Note that on e500v2 there is an erratum regarding mbar 1 ("mbar MO = 1" instruction fails to order caching-inhibited guarded loads and

stores), which may be why the EIEIO_EN bit was dropped.

元の投稿で解決策を見る

0 件の賞賛
4 返答(返信)
500件の閲覧回数
scottwood
NXP Employee
NXP Employee

1. Yes, as indicated in section 5.5.5.2 "Forcing Load and Store Ordering (Memory Barriers)" of the e500mc reference manual, mbar 1 performs better than sync or mbar 0.  You'll have to benchmark your application to determine if the difference is significant.

2. I don't know of any hardware mechanism to accomplish this, though maybe you could automate the change to your source code, or use a preprocessor define.

Which HID bit are you thinking of?  I don't see a relevant HID bit on e500v2.

500件の閲覧回数
vasanthsri
Contributor III

Thank you Scott.

1. Yes, as indicated in section 5.5.5.2 "Forcing Load and Store Ordering (Memory Barriers)" of the e500mc reference manual, mbar 1 performs better than sync or mbar 0. 

So , I assume theoretically EIEIO (mbar 1) is better than MBAR instruction. 

You'll have to benchmark your application to determine if the difference is significant.

Yes. I am in process of writing standalone tool which makes use of both the instruction to profile the actual difference in terms of instruction latency.

2. I don't know of any hardware mechanism to accomplish this, though maybe you could automate the change to your source code, or use a preprocessor define.

I understand this instruction is user level, but anyway to make this instruction(MBAR) execution to trap ..?

Which HID bit are you thinking of?  I don't see a relevant HID bit on e500v2.

Sorry, It was my assumption that EIEIO_EN bit is supported on e500v2.

EREF Manual section 4.6.4.1

Eieio synchronization enable. Allows mbar instructions to provide the same synchronization semantics

as the eieio instruction from PowerPC 1.xx architectures.

0 The synchronization provided by the mbar instruction is performed in the PowerISA manner.

Additional forms of synchronization, if implemented, are determined by the value in the MO field.

1 The synchronization provided by the mbar instruction is equivalent to PowerPC 1.xx eieio

synchronization. The MO field is ignored.

I am in need of this bit on e500mc and same is unfortunately not available :smileysad:

0 件の賞賛
501件の閲覧回数
scottwood
NXP Employee
NXP Employee

I don't know of any way to make mbar trap.  Even if you could, that might add more overhead than mbar 1 would remove.

Note that on e500v2 there is an erratum regarding mbar 1 ("mbar MO = 1" instruction fails to order caching-inhibited guarded loads and

stores), which may be why the EIEIO_EN bit was dropped.

0 件の賞賛
500件の閲覧回数
vasanthsri
Contributor III

I don't know of any way to make mbar trap.  Even if you could, that might add more overhead than mbar 1 would remove.

Yea., the overhead will be high as compare to MBAR , but thought of self modifying code.

Note that on e500v2 there is an erratum regarding mbar 1 ("mbar MO = 1" instruction fails to order caching-inhibited guarded loads and

stores), which may be why the EIEIO_EN bit was dropped.

I was a little bit late on reading the application note AN3441 in which this erratum is explained. Thanks a lot for your replies. :smileyhappy:

0 件の賞賛