Cleanup for cryptographic algorithms vs. compiler optimizations
ticso at cicely7.cicely.de
Sun Jun 13 16:28:55 UTC 2010
On Sun, Jun 13, 2010 at 06:14:11PM +0200, Dag-Erling Smørgrav wrote:
> Bernd Walter <ticso at cicely7.cicely.de> writes:
> > Dag-Erling Smørgrav <des at des.no> writes:
> > > Bernd Walter <ticso at cicely7.cicely.de> writes:
> > > > Amazing - this is one of the things which can get nasty if you try
> > > > some kind of microtuning.
> > > Only if you break the rules. Bad code is always bad, even if it
> > > sometimes works by accident.
> > To expect that function calls are replaced with other functions isn't a
> > very obvious rule.
> You don't need to know that gcc replaces printf() with puts(). That's
> the whole point of the as-if rule: the compiler can only modify the
> program in ways that do not change observable behavior.
Well in ways the compiler _thinks_ it is not observeable.
I'm not saying that it is doing wrong per definition, but if it is really
not observeable and obvious we wouldn't need to talk about it.
> The only way you can tell that gcc did it is if you break the rules,
> such as by defining your own version of printf() or puts().
Our loader stages do this for good reasons.
And in microcontroller programming (surely out of FreeBSD scope) it
is done very regulary.
All I say is that the rules are not obvious in many cases.
Most people using compilers don't have the deep knowledge as you have.
Of course we are talking about corner cases which most people also
never have to face.
In any case - I've learned something new.
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
More information about the freebsd-current