LINUX

[ide.ne.irj at freemail.hu]

Thus spake hwsw famulus:

>>> A dolog egyetlen hatulutoje a GC (garbage collection) azaz az automatikus
>>> memeoria felszabaditas,
>
>> Nem csak az.
>
> Hanem...?
> Mit nem nem tudnak még az (USA beli)
> egyetemi kutato csoportban ezzel fogalkozo
> es sajat realtime java forditot fejleszto bamba egyedek...

Mar irtam, ti is elismertetek: hardverkozeli programozas, gyors reakcioidot
igenylo alkalmazasok, 8 bites mikrovezerlok, stb...

>> Elony? Miert?
>
> Nem kell foglalkozni a leggyakoribb
> programozoi hibat okozo dologgal
> a memoria felszabaditassal.

:))) Erre nem tudok mit mondani. Ezt a hibat en nem szoktam elkovetni.
Millio mast igen, de ezt nem. Nem ertem miert jo emiatt lelassitani az
egesz rendszert... Aki huzamosabb ideig programozott asm-ben, mexokja
hogy a szalakat el kell varrni. Mert feltuno hogy van olyan eset, amikor
elszallhat a progi. Pl nem sikerul egy memoria-foglalas stb...
A C elkeni az ilyesmit, szinte sugallja a programozonak hogy ne foglalkozzon
vele. Az asm progibol ordit hogy fennal a hiba lehetosege.

Ha egyszer van MMU, es azt mar kifejlesztettek, megcsinaltak gyorsra,
akkor mi ertelme van a GC-nek?

>>> (A cuccos JVM kiepitestol fuggoen 61-89 K flash-t es <32 K RAM-ot ker.)
>
>> Ok, emiatt kilove az egesz.
>
> ...marmint nalad gondolom

Igen. A 'hello world' szintu alkalmazasokhoz lehet hogy jo, ha lassu is.

> Futasidore es mint a tabella mutatja
> a GCC a viszonyitasi alap

Nem irtad hogy futasido, de nem baj.

[..]

> Ellenben igazat annak azt mondta, hogy
> van a C-nel jobb JVM, amit Te kontraztal...

Kontrazom tovabbra is. Csak az derul ki, hogy a GCC-nel van gyorsabb
fordito. Siman elhiszem. A GCC szar. Nem is hasznalom.

>> De ezek az eredmenyek gondolom nem az ATmega-ra vonatkoznak, ugye?
>
> Ezek PC alapon merodtek.

Akkor vedd figyelembe, hogy a dinamikus atforditas, hotspot meg egyebek
egy Harward architekturas mikrovezerlon (AVR, PIC, 8051, stb...) nem
mukodnek, mert nem tudnak RAM-bol programot futtatni.
Tehat a PC-n mert eredmenyek nem erdekesek egy mikrovezerlon, ami kizarolag
interpreteres mukodesu lehet. Vagy binarist kell forditani a Java-bol...
Ebben a GCC-t esetleg meg lehet verni, mas forditot lehet hogy nem.
Bytecode futtatassal, interpreterrel biztos nem.
De ez megint az a fajta csusztatas, amit Arnold is elkovetett: indul a
vita valami mikrovezerlos vagy kommersz procis, DSP-s temaval, nehany
level mulva mar a teljesen specialis, nagygepek szamara kifejlesztett
prociknal tartunk. Te meg a PC-n mert eredmenyeket gondolkodas nelkul
atviszed a mikrovezerlore. Igy nem lehet vitatkozni...

> Vegul is nem a nyelv a donto....

Nem, hanem az hogy milyen kapcsolatban van a hardver altal kozvetlenul
vegrehajthato program strukturajaval.
Ha a ketto hasonlit, egyszeruen keszitheto jo hatasfoku fordito.
Ha tavol allnak, meg nagyon intelligens forditoval is nehez.

> A magasszintu forditok vegul is ASM macro hivasok :-)))

Ha az 'optimalizalas' nincs bekapcsolva, igen.
Ha be van, akkor valamivel tobb.

> Innen pedig minden nyelvben, minden megoldhato,

Csak a hatekonysag kulonbozik.

> Ezert baratom a BASCOM is az AVR-en, mert
> minke szarakodjak egy timer/pwm kezeleshez ot-hat
> regiszterrel amikor egy config timer utasitasban
> megmondhatom vilagosan es feladathoz illeszkedoen,
> hogy mit is akarok eppen....

Ugyanigy asm-ben. Megirod a kis makroidat, fuggvenyeidet, utana ugyanugy
hasznalhatod oket mint a BASIC utasitasokat.

> KJ

-- 
Valenta Ferenc <vf at elte.hu>   Visit me at http://ludens.elte.h u/~vf/
"A hosszu elet titka: legyen nalad bicska!"