[elektro] MCHIP kontra ATMEL

[Lajos Rancz]

Helló!

Nagyrészt egyetértek, de nem teljesen :) Számít egy program teljesítménye,
de ezt nem (csak) ilyen alacsony szintű dolgokkal érik el. A jelenlegi
trend, hogy egyre több magon kell tudni futni, kód változtatás nélkül a
lehető legnagyobb teljesítménnyel, úgy, hogy a kód ép ésszel karbantartható
legyen. Jön a funkcionális programozás kora :)

2016. január 18. 16:07 SZIGETI Szabolcs írta, <szigiszabolcs at gmail.com>:

> Hali!
>
> Semmi. Viszont akik CISC CPU-n nőttek fel, azok nagyon nehezen tudják
> elengedni, hogy ma már nem kézzel piszkáljuk a gépikódot, hanem baromi
> hatékony optimalizáló compilerek meg hasonló kódgeneráló eszközök vannak.
> Ha van esetleg valaki, aki dolgozott VAX (TPA) gépeken, az tudhatja, hogy
> milyen gyönyörű ezeket assemblyben programozni (olyan egzotikumok vannak,
> mint switch utasítás, polinom számoló utasítás vagy éppen listakezelő
> utasítás). A vége mégis az lett, hogy kiderült, ezekre nincs szükség. A
> programok idejük nagy részében regiszterbe töltögetnek, logikai utasítást
> csinálnak vagy éppen feltételesen ugranak. A compiler technológia meg egyre
> fejlődik, a fejlesztők nagy részét nem izgatja, hogy mi van alul, a fordító
> elintézi. Sőt, még jobban is jársz, mert újrafelhasználható a kódod. Még az
> olyan furcsa szerzeteket is, mint a grafikus kártyák, manapság már
> magasszintű nyelven programozzák, pedig ott aztán nem lehet mondani, hogy
> nincs igény a teljesítményre optimalizálásra.
> A cél inkább az, hogy minél inkább elrejtsük az alul lévő dolgokat. A
> legtöbbször nem az a kérdés, hogy a program elindításától a végéig mennyi
> idő telik el, hanem, hogy a szerződés aláírásától a számlázásig meddig.
> Márpedig itt a minél jobb fordítók, kódgenerátorok, RTOS-ok és egyebek a
> lényegesek. Az architektúrának pedig ezeket kell hatékonyan támogatni, nem
> a kézi assemblyt. Ha jól tudom, már az AVR-ben is tervezési cél volt a
> magasszintű nyelvek hatékony támogatása.
>
>
> Szabolcs
>
>
> 2016. január 18. 15:48 hg12345 írta, <hg12345 at freemail.hu>:
>
> > "L. Pásztor" <seasoft at invitel.hu> írta:
> > >És én a sok behuzalozott periférában látom a hatékonyságot.
> > >A sok behuzalozott periféria, a RISC, és a tömör kód ellentmondanak
> > >egymásnak.
> > >Én a RISC-et hagynám el ...
> >
> > azért kiváncsi vagyok mi előnye van egy nem RISC uC-nek?
> >
> >
> > >
> > >---------------------
> > >L. Pásztor
> > >---------------------
> > >
> > >
> > >1/18/2016 3:07 PM keltezéssel, Lajos Rancz írta:
> > >> Helló!
> > >>
> > >> Akkor egyetértünk: kb senkit nem érdekel az architektúra csak a chip
> > >> tervezőket és a compiler írókat. RISC-re könnyebb sok minden (v.ö.
> > Single
> > >> Instruction Computer:
> > >> https://en.wikipedia.org/wiki/One_instruction_set_computer).
> > >>
> > >> Üdv
> > >>
> > >> 2016. január 18. 15:02 L. Pásztor írta, <seasoft at invitel.hu>:
> > >>
> > >>> Én úgy értem:  ma már nem az a hatékony, ami kis memóriában elfér és
> > >>> gyorsan fut.  Amiben kezdtünk, a 8 megás órajel és 8k-s memória
> > >>> világának lassan vége ... az idő lett a legértékesebb.
> > >>> Lehet ezért sokan megköpködnek, de sztem az 512k memória világában,
> és
> > >>> 150MHz-es órajelek mellett tökmindegy mennyire "hatékony" v "kicsi" a
> > >>> lefordult kód, vagy mennyire az a compiler, ha az egyébként helyesen
> > >>> fordít. Nálam (és úgy látom sok más helyen is) a hatékonyság kezdi
> azt
> > >>> jelenti, h 1-1 project mennyi idő alatt van kész, és összesen
> mennyibe
> > >>> kerül ...
> > >>>
> > >>> ----------------------
> > >>> L. Pásztor
> > >>> ----------------------
> > >>>
> > >>>
> > >>>
> > >>> 1/18/2016 2:52 PM keltezéssel, Lajos Rancz írta:
> > >>>> Hi!
> > >>>>
> > >>>> A "nem RISC-es"-t abszolút nem értem. Fordított (nem assembly) nyelv
> > alá
> > >>> az
> > >>>> a hatékony.
> > >>>>
> > >>>> üdv
> > >>>>
> > >>>> 2016. január 18. 14:02 L. Pásztor írta, <seasoft at invitel.hu>:
> > >>>>
> > >>>>> Ok, ok, csak azt nem tudom örüljek-e ennek ...
> > >>>>> Egyébként 5letem sincs minek kell nekik az Atmel?
> > >>>>> - az Atmel-hez kell-e majd az MPLAB ?
> > >>>>> - vagy az Atmel memórát is lapozhatóvá teszik ?
> > >>>>> - esetleg a mikrocsip lesz majd Atmel-árfekvésű ?
> > >>>>> :(((
> > >>>>>
> > >>>>> Sztem kéne már egy egészen új, de nem RISC-es controller, sokféle
> > >>>>> tokban, sok behuzalozott funkcióval, jó RTOS-sel, jó IDE-vel és jó
> > >>>>> compilerrel.
> > >>>>> Amin és amivel gyorsan lehetne fejleszteni, mert a málna és tsai
> csak
> > >>>>> játékok, nem megoldás és nem is alternatíva egy jó controller és
> > >>>>> környezete helyett ...
> > >>>>>
> > >>>>> --------------------
> > >>>>> L. Pásztor
> > >>>>> --------------------
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> 1/18/2016 1:39 PM keltezéssel, hg12345 írta:
> > >>>>>> Megoldódik... MCHIP felvásárlási ajánlatot tett az ATMEL-re :-)
> > >>>>>>
> > >>>>>> -----------------------------------------
> > >>>>>>              elektro[-flame|-etc]
> > >>>>> -----------------------------------------
> > >>>>>             elektro[-flame|-etc]
> > >>>>>
> > >>>> -----------------------------------------
> > >>>>             elektro[-flame|-etc]
> > >>> -----------------------------------------
> > >>>            elektro[-flame|-etc]
> > >>>
> > >> -----------------------------------------
> > >>            elektro[-flame|-etc]
> > >
> > >-----------------------------------------
> > >          elektro[-flame|-etc]
> >
> > -----------------------------------------
> >           elektro[-flame|-etc]
> -----------------------------------------
>           elektro[-flame|-etc]