Blumen fuer Peter Dannegger

Ich find ihn auch genial! Seine 1-Wire Routinen sind echt super. Hab 
zwar immer wieder mal Probleme seinen Code zu verstehen, aber man lernt 
ja nie aus, gell?
Vor allem lässt er sich auch nicht unterkriegen wenn er mal wieder von 
anderen Neidern angepi...t wird!

Just my 2Cents!

Gruß - Markus

Markus _neu wrote:

> Hab
> zwar immer wieder mal Probleme seinen Code zu verstehen, aber man lernt
> ja nie aus, gell?

Naja, Peter hat eine gewisse Tendenz, write-only Code zu schreiben. ;-)
Meine Vermutung ist, dass er sich sowas bei einer früheren Version
eines C-Compilers angewöhnt hat, der man praktisch den gesamten Code
mit der Hand voroptimieren musste...

Nichtsdestotrotz, auch wenn ich ihn nicht bis zu Ende versucht habe
zu verstehen, habe ich beispielsweise seinen Code für den Gray-Encoder
auch schon selbst benutzt.  Man muss ja nicht jedes Fahrrad neu
erfinden.

Jörg Wunsch wrote:
> Meine Vermutung ist, dass er sich sowas bei einer früheren Version
> eines C-Compilers angewöhnt hat, der man praktisch den gesamten Code
> mit der Hand voroptimieren musste...

Ne, ich hab erstmal viel Assembler gemacht und da versucht man dann 
sprungvermeidend zu schreiben, z.B.:

1

w = y;

2

if( x )

3

  w = z;

Der Keil C51 hat dann auch ganz pragmatisch alles so gelassen, was er 
selber nicht besser machen konnte.

Nur der AVR-GCC muß immer seinen Kopf durchzusetzen und den Code 
aufblähen.


Peter

Peter Dannegger wrote:

> Der Keil C51 hat dann auch ganz pragmatisch alles so gelassen, was er
> selber nicht besser machen konnte.

Der Keil hat praktisch nichts optimiert und nahezu alles gelassen,
wie es war.  Habe ihn vor Jahren selbst auf einem mc68020 benutzen
dürfen... hat er immer noch den Bug drin, dass er den Stack
verwurschtelt, wenn man in einem verschachtelten Block eine Variable
definiert?  Das hat mich damals Tage gekostet.

Heutige Compiler (nicht nur der GCC, IAR macht das in sehr ähnlicher
Weise) optimieren einfach viel großräumiger, als das die Compiler von
vor ca. 20 Jahren getan haben.  Die machen auch aus lesbarem C-Code
durchaus optimalen Assemblercode. :-)

Dass der AVR bei GCC eine eher untegeordnete Rolle spielt, ist ein
anderes Ding.  Das liegt insbesondere auch daran, dass es keinen
gescheiten Opensource-Simulator gibt, den man den GCC-Entwicklern so
hinlegen könnte, dass sie auf diese Weise den AVR routinemäßig mit
checken können.  Dadurch lassen sich Verschlechterungen im
Optimierungsverhalten nicht sofort erkennen, sondern lediglich durch
das anschließende Melden via Bugreport, was natürlich eine viel
größere Rückkopplungsschleife verursacht.