LINUX

[ide.ne.irj at freemail.hu]

Thus spake Fuzesi Arnold:

> 1, Kerdes az ido, kerdes az architektura

Nem, az ido nem volt kerdes. Masok kavartak bele kesobb.

> 2, VLIW prociknal boven elofordulHAT, hogy csak azt hiszed az a
> legoptimalisabb megoldas amit kezzel irsz.
> Gondolom neked felesleges reszletezni milyen mikor az ember 4 utasitast ir
> le egy sorban es a kovetkezoben ezek eredmenyet hasznalja fel. Vagy az utana
> kovetkezoben, mert meg nincs kesz. A SHARC ezeknek a prociknak kb. a
> legkisebb
> kepviseloje.

Miert hinnem? Ehhez nem kell VLIW, minden pipeline procinal igy van.
Az, hogy feltetelezed hogy ennek vegiggondolasa emberi aggyal lehetetlen,
csak azt bizonyitja, amit amugy is tudtunk, hogy nem ertesz hozza.
Valakinek az volt a gondja, hogy sok proci az ugro utasitas utani utasitast
is vegrehajtja az ugras elott, es hat ezt mar csak a forditok tudjak
kihasznalni. (SH, Sharc) Kerdezz korbe a listan olyan embereket, akik
nem csak olvastak errol, hanem probaltak is! Semmi gond vele. Masnak a 32
regiszter volt gaz, az mar szornyu sok, lehetetlen fejbentartani.
Semmi problemat nem okoz, en sok ev asm programozas utan kifejezetten
szeretem az ilyen procikat, sokkal optimalisabb kodot tudok ra irni, mint
egy akkumulatoros procira. Most meg ez az utasitas sorrend tema...
Az Amineten megtalalod az mp3 kitomoritos hangkartya projectemet,
forrassal egyutt. Az adatfeldolgozo ciklusok belseje 100% optimalizalva
van utasitas-sorrendre, hogy ne alljon a pipeline, mert varni kell az elozo
eredmenyre! Valamikor 99 kornyeken kezdtem irni...
Ezek mind olyan dolgok, mely a laikusoknak lehet hogy szornyen hangzik,
valojaban semmi problemat nem okoz. At kell latni a mukodest, alaposan at
kell olvasni a doksikat, es esetleg tobb elvileg lenyegesen kulonbozo
konstrukciot is ki kell probalni. Neha nagyon gyorsan megy, maskor el kell
szorakozni vele egy darabig, de vegul nagyon csunyan meg lehet verni
barmely forditot.
Kiveve ha a fordito az abszolut optimalis kodot generalja. De olyan nincs.
Kezzel viszont elerheto!!

> 3, Azert jo, mert szabvanyos. Mert nincs az hogy az asm kod elejen meg igy
> adtad at a parametert a verembe a vegen meg ugy.Meg ezer mas dolog. Van sok

Verembe? Kizart, asm-ben nem jellemzo. Ez egyebkent processzortol fugg.
Az m68k-nak van { es } utasitasa is :) (link/unlk)
Valamint tamogatja a veremben parameteratadast. (retd)
Erdekes modon a C forditok sem nagyon hasznaljak, link/unlk meg szokott
lenni a leforditott progiban, retd soha.
Asm-bol azert nem praktikus a veremben atadni a parametereket, mert ahogy
irod, el lehet baxni, ha csak nem definial es hasznal kovetkezetesen egy
strukturat az ember. Azt pedig a veremben forditva kell felepiteni, ezt
en makrokkal nem tudtam normalisan megoldani. (Pl a struktura meret
kiszamitasa nem megy) De a statikus valtozok veremben tarolasaval
probalkoztam, erre pelda a szinten Amineten megtalalhato Copper-Demon
progi, ami az Amiga egyik grafikus koprocesszora segitsegevel 24 bites
szivarvany-szeru szinatmeneteket varazsol a hatterbe. Kesobb leszamoltam
ezzel a megoldassal.

> Tovabba team-ben dolgozva sokkal kisebb az esely a hibazasra.
> (tudom itt a listan senki nem dolgozik csapatban....senkinek nem revizaljak
> a kodjat, es senki nem ir ujrafelhasznalhato kodot, es senki nem tanult
> programozni)

En dolgozom csapatban is, termeszetesen C-ben programozok.
Pontosabban szerintem csak en programozok C-ben, a tobbiek C++.
Mukodne asm-ben is, termeszetesen, mert nem egy fajlon dolgozunk, a
kommunikacio szabvanyos interfeszeken zajlik, hogy mogotte milyen
nyelvben keszult a progi, teljesen lenyegtelen.
BASIC is lehetne, ami a tobbiek munkajat illeti, sajna nekem mindig a
hardverkozeli kommunikacio es a matek marad, ami az egesz program
teljesitmenyet lenyegesen meghatarozza, ezert nekem optimalizalnom kell.

> 4-5,  marad az asm ezekszerint. :)

Csak ahol szukseges.

> Arnold

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