side effects problem.

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.

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

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

Here is a link to an earlier similar discussion:

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

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

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

Exactly. Until somebody else changes something else...

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

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.

You are good.

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:

The Lizard

... snip ...

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

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