HN user

rsaxvc

391 karma
Posts3
Comments189
View on HN

Long enough ago I don't remember the business details.

The 4.x compiler line never being patched was a bit of eye opener into commercial toolchain support.

You're eactly right. I saw the blight at Herculaneum, MO in the 2000s - dozers plowing down houses in a slowly expanding circle centered on the smelter.

1 in 5 students had excess blood lead. The schools nearby were scraped down and soil was replaced whenever the lead levels got too high from the dust blowing off the open ore and slag trucks running town. The smelter didn't hit EPA requirements for 25 years, and when faced with enforcement, decided to leave rather than produce lead cleanly, because it is not economical to do so cleanly. Cheap lead offloads the environmental and health effects to someone.

https://health.mo.gov/living/environment/hazsubstancesites/p...

https://www.kbia.org/science-and-technology/2012-08-08/the-e...

You could review their argument: https://www.ftc.gov/system/files/ftc_gov/pdf/YardiSOI-filed%...

Search for "adherence to the agreed-upon Prices", "fix list price", and "Express delegation".

They argue that collusion through delegation counts as price fixing. They argue colluding to set list prices even when there isn't a price floor is price fixing. They argue that replacing the delegation with an algorithm is still price fixing. Most of their arguments are based on already settled cases.

Agreed.

Where it mattered for me was on an ARM core managing a much larger DSP. The DSP consumed most of the memory bandwidth, so fetching a cacheline of instructions or an MMU mapping into the ARM had long and variable latency as it had to wait for the DSP to finish a large burst to or from the shared memory.

Rarely if ever. This isn't about tail-calling, it's about function placement in the final image to enable branch elimination. There's no call between foo and foo0, but many of the requirements for a tail call are also required here

You can structure the code so foo calls foo0, but the compiler and linker have to work together to pull that off and I don't think GCC and clang do so.

If the functions are being built into split sections, generally no.

If they aren't, and foo isn't called nd foo is, I've never seen a tool chain remove just foo but not foo0, which is nice to have.

This was excellent debugging and a great write up.

If the SHAREABLE bit is like on ARM, it won't effect a system running only one core. On some systems this causes memory ordering to that shareable IO memory to be ordered across multiple cores where it might not be otherwise. There's a performance trade off in that additional cache coherency traffic can be a bottleneck, but for something like a UART shouldn't be an issue and could be left shareable.