On Sun, 7 Dec 2008 13:31:39 -0500, "Jujitsu Lizard"
<jujitsu.lizard@gmail.com> wrote:

>"leilei" <huxuelei630@gmail.com> wrote in message 
>news:f60b5048-0254-45e1-88ae-b83f1fb0e468@g1g2000pra.googlegroups.com...
>> Hi, I am reading <Linux Device Drivers, 3rd Edition>,
>> In section 9.1.1, it described the side effect about memory access:
>> The main difference between I/O registers and RAM is that I/O
>> operations have side effects, while memory operations have none: the
>> only effect of a memory write is storing a value to a location, and a
>> memory read returns the last value written there. Because memory
>> access speed is so critical to CPU performance, the no-side-effects
>> case has been optimized in several ways: values are cached and read/
>> write instructions are reordered.
>>
>> But I can not understand what the I/O operations's side effect is.
>> Could anyone give me some tips.
>
>I think the text you quoted may not reflect what the author intended.  I 
>think he is hinting at the classic "volatile" issue that was discussed a few 
>days ago here and elsewhere.

Especially when using peripherals originally intended for separate I/O
space is used in a memory mapped I/O system, you may have completely
different actions for read and write. 

For example writing to memory location 100 would send a new character
out from the UART, while reading location 100 will return the
character received from the UART in a full duplex protocol. Reading
location 101 could return the status register, while writing to
location 101 will update the control register .e.g. set the number of
bits etc. You can not optimize away a read after write in such
situations.

Paul

CBFalconer wrote:

> Vladimir Vassilevsky wrote:
> 
> ... snip ...
> 
>>BTW there is the opposite problem also: if a CPU read or write
>>cycle was interrupted, then it could be repeated once again upon
>>the return from the interrupt. That has to do with the pipeline
>>operation.  If the location was the I/O register, the result may
>>be a mess. It takes a lot of effort to troubleshoot the bugs like
>>that.
> 
> 
> I know of no system in which an i/o read or write can be
> interrupted.  Do you, and if so what system is it?

ADI BlackFin. Interrupts and DMA requests are handled at the units 
smaller then one instruction.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

Vladimir Vassilevsky wrote:
> 
... snip ...
> 
> BTW there is the opposite problem also: if a CPU read or write
> cycle was interrupted, then it could be repeated once again upon
> the return from the interrupt. That has to do with the pipeline
> operation.  If the location was the I/O register, the result may
> be a mess. It takes a lot of effort to troubleshoot the bugs like
> that.

I know of no system in which an i/o read or write can be
interrupted.  Do you, and if so what system is it?

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

"Vladimir Vassilevsky" <antispam_bogus@hotmail.com> wrote in message 
news:gPX_k.7801$as4.361@nlpi069.nbdc.sbc.com...
>
>> If they can be troubleshooted (or is that troubleshot?) at all ...
>>
>> I've had a lot of experience with interrupt-related bugs (but not the one 
>> you describe--the more obvious IPC issues).  My experience has been that 
>> if a software developer lacks the training to understand the bug, they 
>> tend to change things until the software seems to work most of the time. 
>> The changes may be rationalized somehow, but what usually happens is that 
>> enough changes are made that the window of vulnerability is moved out of 
>> alignment with when an interrupt can occur.
>
> Exactly. Until somebody else changes something else...

You are good!  That one is right on the money.

A long, long time ago in a galaxy far, far away a vehicle module was handed 
off to me.  The software developer had quit to go and develop cash register 
software for K-mart (no joke--I couldn't make this stuff up).

The module had intermittent bugs, and the software developer was so 
superstitious about it that he had put the module (a circuit board) on 
standoffs because he reasoned that his anti-static mat had something to do 
with it.

Anyway, the problem ended up to be that there was an RMW instruction used to 
clear a control register (improper), and if the interrupt (from an 
input-capture kind of device) became active during the RMW instruction, an 
interrupt would be cleared before it ever was processed by the hardware or 
software.  The data book specifically cautioned against this.

I ended up driving around behind a certain bowling alley (the external input 
was a hall effect sensor on a driveshaft), and I could get the problem to 
occur with amazing regularity at about 35-45 MPH.  It amazed me because it 
was a really narrow window to hit (less than one machine instruction).

When I contacted the software developer during my first few weeks of working 
on the product, his response was "How did you get this number?" and "Don't 
call me again.".  I'm convinced that some of his frustration was the 
interrupt-related issue, which he could not find.  Thank goodness I finally 
found it.

I think in the product involved the issue would have been hard to mask 
(because it was asynchronous input with respect to the software), but with a 
lot of interrupt-related issues random software changes will mask them.

> Exactly. Until somebody else changes something else...

You are good.

>
>> You'd be surprised how many of these things may exist in any consumer 
>> product you buy ...
>>
>> The Lizard
>
> Hey Lizard,
>
> I second what you wrote here. BTW, that joke about kittens was very nice 
> indeed. The problem is that NOT only the consumer stuff is built in that 
> way. To the contrary, only the things which were produced in the 
> quantities and for long enough time can be relatively clean from bugs.

I'm kind of going kitten crazy here.  A couple months ago I adopted a stray 
mom and two feral kittens.  The kittens were about six weeks old at the time 
I captured them.  Anyway, mom had been around people before.  She has been 
spayed and is a great pet of my downstairs neighbors.

The male kitten was adopted by a wonderful family about 40 miles away.  They 
are very happy with him.

I'm probably looking at a return on the female kitten (gotta find her a home 
again).  Her philosophy is that a person should be climbed like a tree (and 
the darned claws hurt) to get to whatever food they're eating or because she 
wants to be petted.  She believes that all manner of power cords and 
computer cords are meant to be climbed and bitten.

I purchased a spray bottle today and it is filled with water.  Let the 
kitten taming begin.

The reason the owner isn't happy is because he has to be up early in the 
morning.  The kitten wants to be with him, but she is nocturnal and very 
active at night (keeps him up).  But if he locks her out she whines and 
cries.  And then there is the electrical cord thing.

He likes her but the kitten behavior is driving him batty.

We'll see what final decision he makes.

Here is the monster:

http://blog.dtashley.com/?p=606

http://blog.dtashley.com/?p=597 (she is the short-haired one).

The Lizard

Jujitsu Lizard wrote:

> "Vladimir Vassilevsky" <antispam_bogus@hotmail.com> wrote in message 
> news:wpW_k.6159$pr6.1663@flpi149.ffdc.sbc.com...
> 
>> Jujitsu Lizard wrote:
>>
>>> "leilei" <huxuelei630@gmail.com> wrote in message 
>>> news:f60b5048-0254-45e1-88ae-b83f1fb0e468@g1g2000pra.googlegroups.com...
>>>
>>
>>>> But I can not understand what the I/O operations's side effect is.
>>>> Could anyone give me some tips.
>>>
>>>
>>> Writing the same RAM location with 2 then subsequently with 3 means 
>>> that the 2 can be discarded (why bother?).  This would either be done 
>>> by an optimizing compiler or by a cache, which won't actually get 
>>> around to sending the "2" out to RAM.
>>
>>
>> BTW there is the opposite problem also: if a CPU read or write cycle 
>> was interrupted, then it could be repeated once again upon the return 
>> from the interrupt. That has to do with the pipeline operation.  If 
>> the location was the I/O register, the result may be a mess. It takes 
>> a lot of effort to troubleshoot the bugs like that.
> 
> 
> If they can be troubleshooted (or is that troubleshot?) at all ...
> 
> I've had a lot of experience with interrupt-related bugs (but not the 
> one you describe--the more obvious IPC issues).  My experience has been 
> that if a software developer lacks the training to understand the bug, 
> they tend to change things until the software seems to work most of the 
> time.  The changes may be rationalized somehow, but what usually happens 
> is that enough changes are made that the window of vulnerability is 
> moved out of alignment with when an interrupt can occur.

Exactly. Until somebody else changes something else...

> You'd be surprised how many of these things may exist in any consumer 
> product you buy ...
> 
> The Lizard

Hey Lizard,

I second what you wrote here. BTW, that joke about kittens was very nice 
indeed. The problem is that NOT only the consumer stuff is built in that 
way. To the contrary, only the things which were produced in the 
quantities and for long enough time can be relatively clean from bugs.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

"Vladimir Vassilevsky" <antispam_bogus@hotmail.com> wrote in message 
news:wpW_k.6159$pr6.1663@flpi149.ffdc.sbc.com...
>
>
> Jujitsu Lizard wrote:
>> "leilei" <huxuelei630@gmail.com> wrote in message 
>> news:f60b5048-0254-45e1-88ae-b83f1fb0e468@g1g2000pra.googlegroups.com...
>>
>
>>> But I can not understand what the I/O operations's side effect is.
>>> Could anyone give me some tips.
>>
>>
>> Writing the same RAM location with 2 then subsequently with 3 means that 
>> the 2 can be discarded (why bother?).  This would either be done by an 
>> optimizing compiler or by a cache, which won't actually get around to 
>> sending the "2" out to RAM.
>
> BTW there is the opposite problem also: if a CPU read or write cycle was 
> interrupted, then it could be repeated once again upon the return from the 
> interrupt. That has to do with the pipeline operation.  If the location 
> was the I/O register, the result may be a mess. It takes a lot of effort 
> to troubleshoot the bugs like that.

If they can be troubleshooted (or is that troubleshot?) at all ...

I've had a lot of experience with interrupt-related bugs (but not the one 
you describe--the more obvious IPC issues).  My experience has been that if 
a software developer lacks the training to understand the bug, they tend to 
change things until the software seems to work most of the time.  The 
changes may be rationalized somehow, but what usually happens is that enough 
changes are made that the window of vulnerability is moved out of alignment 
with when an interrupt can occur.

You'd be surprised how many of these things may exist in any consumer 
product you buy ...

The Lizard 

Jujitsu Lizard wrote:
> "leilei" <huxuelei630@gmail.com> wrote in message 
> news:f60b5048-0254-45e1-88ae-b83f1fb0e468@g1g2000pra.googlegroups.com...
> 

>> But I can not understand what the I/O operations's side effect is.
>> Could anyone give me some tips.
> 
> 
> Writing the same RAM location with 2 then subsequently with 3 means that 
> the 2 can be discarded (why bother?).  This would either be done by an 
> optimizing compiler or by a cache, which won't actually get around to 
> sending the "2" out to RAM.

BTW there is the opposite problem also: if a CPU read or write cycle was 
interrupted, then it could be repeated once again upon the return from 
the interrupt. That has to do with the pipeline operation.  If the 
location was the I/O register, the result may be a mess. It takes a lot 
of effort to troubleshoot the bugs like that.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

"leilei" <huxuelei630@gmail.com> wrote in message 
news:f60b5048-0254-45e1-88ae-b83f1fb0e468@g1g2000pra.googlegroups.com...
> Hi, I am reading <Linux Device Drivers, 3rd Edition>,
> In section 9.1.1, it described the side effect about memory access:
> The main difference between I/O registers and RAM is that I/O
> operations have side effects, while memory operations have none: the
> only effect of a memory write is storing a value to a location, and a
> memory read returns the last value written there. Because memory
> access speed is so critical to CPU performance, the no-side-effects
> case has been optimized in several ways: values are cached and read/
> write instructions are reordered.
>
> But I can not understand what the I/O operations's side effect is.
> Could anyone give me some tips.

I think the text you quoted may not reflect what the author intended.  I 
think he is hinting at the classic "volatile" issue that was discussed a few 
days ago here and elsewhere.

Substitute "I/O register read or write" for "I/O operation" and you may have 
the author's intent.

Writing the same RAM location with 2 then subsequently with 3 means that the 
2 can be discarded (why bother?).  This would either be done by an 
optimizing compiler or by a cache, which won't actually get around to 
sending the "2" out to RAM.

Here is a link to an earlier similar discussion:

http://groups.google.com/group/comp.arch.embedded/browse_thread/thread/258ddd162fad2a60

It is possible that I'm misunderstanding intent, but I think the author was 
speaking about the classic "volatile" thing.  A side effect of reading an 
I/O register may be clearing a flag in the register (a read cycle may do 
this automatically).  A write operation to an I/O register may start an A/D 
conversion or a disk seek or something going.  The compiler and cache can't 
remove these things (and still have a logically correct program).

The Lizard 

"leilei" <huxuelei630@gmail.com> wrote in message
news:f60b5048-0254-45e1-88ae-b83f1fb0e468@g1g2000pra.googlegroups.com...

> The main difference between I/O registers and RAM is that I/O
> operations have side effects, while memory operations have none: the
> only effect of a memory write is storing a value to a location, and a
> memory read returns the last value written there. Because memory
> access speed is so critical to CPU performance, the no-side-effects
> case has been optimized in several ways: values are cached and read/
> write instructions are reordered.
>
> But I can not understand what the I/O operations's side effect is.
> Could anyone give me some tips.

I/O reads or writes can be destructive. So, they should be done only once
and in the correct sequence. For example, reading of the UART status
register automatically clears some status bits. Another example: reading or
writing the hardware FIFO register promotes the whole queue. This is what
meant by the "side effects" of I/O.

Vladimir Vassilevsky
DSP and Mixed Signal Consultant
www.abvolt.com

leilei wrote:

>Hi, I am reading <Linux Device Drivers, 3rd Edition>,
>In section 9.1.1, it described the side effect about memory access:
>The main difference between I/O registers and RAM is that I/O
>operations have side effects, while memory operations have none: the
>only effect of a memory write is storing a value to a location, and a
>memory read returns the last value written there. Because memory
>access speed is so critical to CPU performance, the no-side-effects
>case has been optimized in several ways: values are cached and read/
>write instructions are reordered.
>
>But I can not understand what the I/O operations's side effect is.
>Could anyone give me some tips.

The way I read that statement is that I/O operations' side effects are
the hardware's responses.  E.g., LEDs get lit or extinguished, UARTs
transmit data, etc.

-- 
========================================================================
          Michael Kesti            |  "And like, one and one don't make
                                   |   two, one and one make one."
    mrkesti at hotmail dot com     |          - The Who, Bargain