Forums

side effects problem.

Started by leilei December 7, 2008
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.
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
"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" <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

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
"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:

> "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: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
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.

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