Windows98

[Thomas Findeisen]

> >Da fällt mir spontan was ein, vielleicht hat einer ein paar gedanken dazu
> >(Lutz ?). Aus seligen alten 6502 und 65816 - AssemblerZeiten kenne ich noch
> >diverse DisAssembler, speziell fuer den 6502 gab es da echt gute Sachen, ich
> >hatte damals sogar einen eigenen geschrieben der immerhin sogar versucht
> >hatte Dokumentationen zu dem erstellten Quelltext zu ergänzen (z.B. auch
> >Label erfand etc.). Ist es von der Theorie nicht auch möglich C oder C++
> >Quelltexte wieder in den SourceCode zu wandeln ?
> 
> Es gibt derartige Decompiler. I.d.R. sind die Compiler nämlich so schlecht,
> daß die Strukturen rückauflösbar sind. Sind auch noch Debug Infos dabei,
> kommt man zielich weit. (Abgesehen von Verlusten durch den Optimierer)

der Optimierer ist der Punkt, ich nehme echt an dass die meisten nur auf
Bibliotheken rückgreifen und man die sehr gut wieder auflösen könnte, man
muesste nur den Compiler kennen.
> 
> >schauen können ;-).  Wobei ich immernoch behaupten will dass reiner AssCode
> >immer schneller bleibt als optimiertes Compilat (auch mit
> >RunTime-Berechnungen etc.).
> 
> Dazu gab es in comp.lang.ada einen Thread vor einigen Monaten. Ergebnis:
> Theoretisch kann der Programmierer einfach den Compileroutput verbessern und
> ist so immer besser. Andererseits kann der Compiler viele Optimierungen
> durchführen, die dem Programmierer zu aufwendig bleiben müssen (z.B.
> Registerzuordnungen).

Das mit dem Compileroutput is ne' gute idee....hmm, waer'n Projekt, fuer
meinen Geschmack waren die Dinger nur immer viel zuuuu gross, wenn ich sehe
dass man in <30 Byte nen kompletten MB rotieren kann, und dann sehe dass mein
C++ Programm 
echo "hallo ihr da" mit VC++ 6.0 ganze 110 k erzeugt (na gut, mit libs... aber
ohne auch noch im k Bereich), dann weiss ich nicht ob ich damit leben
könnte... Respekt vor denen die den pgcc rausgebracht haben, sind vermutlich
Leute die im Grenzbereich arbeiten und noch jedes Bit einzeln durchzaehlen.
Mich traf ja schon damals der Schock als ich hoerte dass selbstmodifizierende
Schleifen/Codes nicht mit Cache laufen... aaargh, damit kann man Welten an
Zeit sparen (und mem), war vermutlich kein unwesentlicher Grund nicht mit ass
neu anzufangen... und die liebe Zeit, die fehlt halt auch...

>  - Die 80/20 Regel: 80% der Rechenzeit werden von 20% des Codes verbraten.
>    Rekursiv angewendet (das darf man!) gilt: 64% der Rechenzeit wird in
>    4% des Codes verbraten, 51% der Zeit in 0.8% des Codes, ...
>    Ab einem gewissen Punkt könnte man dann optimieren, jedoch zeigt sich,
>    das mit der Änderung des Algorithmus diese 0.8% Code nur noch 1% der
>    Rechenzeit ausmachen.

ja, das mehr theorie... das ist wie meine Cpu-Anzeige, die zeigt mir im Moment
2 Prozent an, ich kann mir nicht vorstellen dass der Prozessor 98% nix macht,
und wenn er nur 98% an nop's verraucht, alles Theorie (wenn auch feine).   8-]

> Mehr dazu in Donald E. Knuth. The Art of Computer Programming

Mal in der biblio' schaun... gibts das auch in deutsch ?

bye, ihr's... Thomas Findeisen