kodtabla

[ide.ne.irj at freemail.hu]

Thus spake Rancz Lajos:

>> Ez erdekes, egy sima C fordito a library fuggvenyekhez pl hozza sem
>> nyul. Meghivja egy call-lal, akkor is ha 6 byte hosszu.
>
> Ha ez probléma, akkor ne használj C library-t! Nem pont az a lényeg, hogy azért használunk vmit mert könnyebb, gyorsabb, egyszerûbb használni?

Ez azt jelenti, hogy nem tudsz szorozni. A * operator nem mukodik.
Szoval enyhen szolva szukseges, csak szar kod lesz belole...

> Common subexpression elimination
> Redundant re-evaluation of common subexpressions is by default eliminated at
> optimization levels Medium and High. This optimization normally reduces both code
> size and execution time. However, the resulting code might be difficult to debug.
> Note: This option has no effect at optimization levels Low and None.
> To read more about the command line option, see --no_cse, page 190.

Nem vilagos, hogy ha a kozos reszeket megkeresi es kirakja szubrutinba,
akkor miert lesz gyorsabb? Egy rcall/ret egy csomo ciklus.
Itt valami masrol lesz szo...

> Function inlining
> Function inlining means that a simple function, whose definition is known at compile
> time, is integrated into the body of its caller to eliminate the overhead of the call. This

Ez az inverze a fentinek. GCC is megcsinalja -o3 opcioval, de amikor a
multkor teszteltuk itt a listan hogy mit fordit, nem csinalta meg...
Lehet hogy library fuggvenyeket nem rak be inline?

> Code motion
> Evaluation of loop-invariant expressions and common subexpressions are moved to
> avoid redundant re-evaluation. This optimization, which is performed at optimization

Ez regi dolog, ez az amit meg egyes assemblerek is megcsinalnak, mint
kiderult.

> Type-based alias analysis
> When two or more pointers reference the same memory location, these pointers are said
> to be aliases for each other. The existence of aliases makes optimization more difficult
> because it is not necessarily known at compile time whether a particular value is being
> changed.
> Type-based alias analysis optimization assumes that all accesses to an object will take
> place using its declared type or as a char type. This assumption lets the compiler detect
> whether pointers may reference the same memory location or not.

Ez csak egy C specifikus problema. Asm-ben nem gond.
A tobbi ugyszinten.
Kerdes, hogy mit akarsz ezekkel bizonyitani?
Ismetlem, amig kulon meg kell irni a programot barrel shifterrel rendelkezo
es anelkuli, hardver szorzoval rendelkezo es anelkuli stb... procikra,
addig semmi eselye a forditoknak.
Az hogy kijavit 10000 aprosagot, amit asm-ben programozva eszebe sem jut
az embernek elkovetni, nem sokat segit.

>> Jaja... Fokozatosan jutottunk el ide a kezdeti vad kijelenteseid
>> utan. Melyeket, miutan keresedre visszaideztem, megtagadtal :)
>
> Ejnye-ejnye már megint kezdünk személyeskedni és cinikusan kikacsingatni. Cöcö.

Ez nem cinizmus, ezek a tenyek. Sajna :(

> Ezt írtam:

Meg meg sokminden mast is. Kell ideznem?

> Mi ebben a durva? Menyiben tér el ez a fent idézett optimalizációs lehetõségektõl?

Semmiben, de ez az egesz amit felsoroltal, NULLA. Aprosagok.
Olyan dolgok, hogy amikor az ember asm-ben programozik, eszebe sem jut
elkovetni ezeket a hibakat, teljesen mas szinten gondolkozik.
Abban a fordito meg nem segit... Szart fordit. Mar C szinten meg kell neki
mondani hogy mit csinaljon, mert magatol nem jon ra.
Pl latogass el a kovetkezo oldalra:
http://tirnanog.ls.fi.upm.es/Servicios/Software/ap_crypt/indice.html
Toltsd le a DES-LEVY progit, olvasd el a commenteket az elejen.
Majd ha ezt automatikusan megcsinaljak a forditok, akkor tudnak
optimalizalni. En arra tippelek, hogy soha nem fogjak tudni...
Ha bovebben erdekel a tema, nezz meg hasonlo matekozo progikat.
Rengeteg peldat talalsz ra.

>     Lajos

-- 
Valenta Ferenc <vf at elte.hu>   Visit me at http://ludens.elte.h u/~vf/
Ha Murphy torvenye tevesnek bizonyulhat, akkor fog is.