Hacker News Reader

Comment by bigcheesegs | Hacker News Reader

> N.B. Accessing registers modified by the hardware may be treated as a multi-threaded application. Therefore, it is worth considering using std::atomic<T> instead of volatile T.

This is incorrect. Compilers are allowed to reorder and combine atomics as long as they follow the rules. See: https://github.com/jfbastien/no-sane-compiler

View on HN

If I understand correctly, that makes the article grossly wrong. Like, if you have a serial port transmit register and execute

   SERIAL_TX_DATA = 0x01;
   SERIAL_TX_DATA = 0x02;

to enqueue two bytes to transmit, then the compiler is allowed to skip the first write entirely.

A naive implementation of the SERIAL_TX_DATA macro will totally give you behavior like that.

   #define SERIAL_TX_DATA (*((volatile uint32_t *)<addr>))

is pretty naive, and correct. The article's advice seems not to be.

Friend smarter than me ran into a bug where when DMA was active on a multi-core uP you needed to do a read op between two writes to a IO address or the first write wouldn't happen.

I think on an ARM processor if it's normal memory you can't guarantee ordering. But ARM supports a device memory type which disables caching and reordering memory accesses by the hardware.

I think ARM's "strongly-ordered memory" concept is supposed to solve this? Was your friend's problem intended behavior, or a silicon bug?

http://infocenter.arm.com/help/topic/com.arm.doc.dai0321a/DA...

I think the DMA accesses were confusing the memory controller. He said that sort of thing was common on internally developed silicon. They won't do a spin if there is a work around. Also my experience as well. I've had to deal with peripherals with an async clock where access timing becomes important.

Observation: CS appears to teach students that code with side effects is evil. AKA hide you side effects behind os calls. With embedded code side effects are important.

Reply on news.ycombinator.com