Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

powerpc sync and eieio instructions

1 view
Skip to first unread message

lc....@gmail.com

unread,
Apr 18, 2008, 4:13:24 AM4/18/08
to
Hi all.
I have some problems with PowerPC syncronization instructions. In
particular I would know when sync and eieio instructions must be used.
I have the source code of a real time operating system for a single
processor board (MVME6100 with MPC7457) and I have notice the use of
sync, isync and eieio instructions. The question is: the
syncronization instruction should be used only in a multiprocessor
context, or not?
I have read the Reference Manual and the Programming Environments
guide but I'm confused.
Can someone explain to me why sync and eieio should be used or suggest
me a link?

Thanks!

Michael N. Moran

unread,
Apr 18, 2008, 8:34:03 AM4/18/08
to
lc....@gmail.com wrote:
> The question is:
> the syncronization instruction should be used only in a
> multiprocessor context, or not?

Don't you want to know about caches, too? ;)

Here is an imprecise non-authoritative summary:

eieio - prevents the CPU from reordering memory accesses.
The best example is when a program needs to update
peripheral registers in a particular order.

sync - ensures that the effects of instructions
have completed with respect to external devices
(e.g. other CPUs and peripherals)

In answer to the multiprocessor part is this ...
peripherals are "processors" ... especially DMA
controllers when they don't snoop the bus. These
instructions are also important in multi-threading.

> I have read the Reference
> Manual and the Programming Environments guide but I'm
> confused.

Read it again ... and again ... the terminology
is "interesting" and worth understanding.


--
Michael N. Moran (h) 770 516 7918
5009 Old Field Ct. (c) 678 521 5460
Kennesaw, GA, USA 30144 http://mnmoran.org

"So often times it happens, that we live our lives in chains
and we never even know we have the key."
"Already Gone" by Jack Tempchin (recorded by The Eagles)

The Beatles were wrong: 1 & 1 & 1 is 1

Didi

unread,
Apr 18, 2008, 9:09:16 AM4/18/08
to

What sync does is make sure that all previous instructions have
finished doing what they have been doing ("retired", as they have it).

For example, if you want to disable the interrupts and subsequently
do something, if you just change the flag in the MSR you may
still be interrupted a few cycles after the "move to MSR" opcode
has been executed (i.e. subsequent opcodes will execute before
the flag change takes effect).
So you have to change the flag, execute a "sync", after which
you will know interrupts are masked.

Dimiter

------------------------------------------------------
Dimiter Popoff Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

Original message: http://groups.google.com/group/comp.arch.embedded/msg/631ace07a6a295b1?dmode=source


Didi

unread,
Apr 18, 2008, 12:32:54 PM4/18/08
to
Just to check how long this will take - my former
message took hours before it appeared in google
groups - apparently they have a posting delay
at the moment, trying to measure it - now it
is 16:33 GMT.

Dimiter

Didi

unread,
Apr 18, 2008, 1:59:41 PM4/18/08
to

Got it at 17:58 GMT, may have appeared up to 30
minutes earlier (time between checks).

Dimiter

CBFalconer

unread,
Apr 18, 2008, 1:39:54 PM4/18/08
to

Here it shows as posted at 12:32 PM, EDT, and it was propagated to
teranews.com server and received here by roughly 1:30 PM EDT. FYI.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.


** Posted from http://www.teranews.com **

Didi

unread,
Apr 18, 2008, 5:25:54 PM4/18/08
to
CBFalconer wrote:
> Didi wrote:
> >
> > Just to check how long this will take - my former message took
> > hours before it appeared in google groups - apparently they have
> > a posting delay at the moment, trying to measure it - now it is
> > 16:33 GMT.
>
> Here it shows as posted at 12:32 PM, EDT, and it was propagated to
> teranews.com server and received here by roughly 1:30 PM EDT. FYI.
>

Thanks, shows about the same delay - probably google posting is
slow for some reason. Perhaps they are trying to wrestle the spamwave,
in a futile way judging by the amount we keep on getting. Frankly I
would not mind typing in a captcha per posting (per group on
crossposts!) if that would help.

Dimiter

Original message: http://groups.google.com/group/comp.arch.embedded/msg/972a3db9b6835cb6?dmode=source

CBFalconer

unread,
Apr 19, 2008, 1:45:29 AM4/19/08
to
Didi wrote:
> CBFalconer wrote:
>> Didi wrote:
>>>
>>> Just to check how long this will take - my former message took
>>> hours before it appeared in google groups - apparently they have
>>> a posting delay at the moment, trying to measure it - now it is
>>> 16:33 GMT.
>>
>> Here it shows as posted at 12:32 PM, EDT, and it was propagated to
>> teranews.com server and received here by roughly 1:30 PM EDT. FYI.
>
> Thanks, shows about the same delay - probably google posting is
> slow for some reason. Perhaps they are trying to wrestle the
> spamwave, in a futile way judging by the amount we keep on getting.
> Frankly I would not mind typing in a captcha per posting (per group
> on crossposts!) if that would help.

All that showed was that the delay was no more than roughly one
hour. The time of pickup depended on my decision to download.

lc....@gmail.com

unread,
Apr 28, 2008, 11:57:35 AM4/28/08
to
> Here is an imprecise non-authoritative summary:
>
> eieio- prevents the CPU from reordering memory accesses.

> The best example is when a program needs to update
> peripheral registers in a particular order.
>

Hi, I've read some references about eieio instruction use but I've
still some doubts.

The code that confused me is that (about MMU initialization):

Page Table Updates (from MPC7450UM -> 5.5.3)

Thus the following code should be used:
/* Code for Modifying a Page Table Entry */
/* First delete the current page table entry */
PTEV <- 0/* (other fields don’t matter) */
sync /* ensure update completed */
tlbie(old_EA) /* invalidate old translation */
eieio /* order tlbie before tlbsync */
tlbsync /* ensure tlbie completed on all processors */
sync /* ensure tlbsync completed */
/* Then add new PTE over old */
PTERPN,R,C,WIMG,PP <- new values
eieio /* order 1st PTE update before 2nd */
PTEVSID,API,H,V <- new values (V=1)
sync /* ensure updates completed */

And also this explanation:
(from MPC7450UM -> 3.3.3.5 Enforcing Store Ordering with Respect to
Loads)

The PowerPC architecture specifies that an eieio instruction must be
used to ensure sequential ordering of
loads with stores.
The MPC7450 guarantees that any load followed by any store is
performed in order (with respect to each
other). The reverse, however, is not guaranteed. An eieio instruction
must be inserted between a store
followed by a load to ensure sequential ordering between that store
and that load. Also note that setting
HID0[SPD] does not prevent loads from bypassing stores.

I've one processor, why should I use tlbsync instruction in page table
updates? And why should I use eieio instruction in this context?

Thanks a lot.

0 new messages