A kódomban bitenkénti műveleteket (&, |, ^, >> stb.) ...

Programozás

...nem használok.
26% (106 szavazat)
...csak akkor használok, ha csak magamnak írom a kódot.
3% (13 szavazat)
...használok, de erősen magyarázom őket kommentekkel.
13% (54 szavazat)
...használok, és alanyi jogon elvárom komment nélkül, hogy aki olvassa a kódom, az megértse.
44% (179 szavazat)
Nem tudok róla, hogy kódolnék olyan nyelvben, amiben van ilyen.
13% (53 szavazat)
Összes szavazat: 405

( Jason v | 2011. 12. 22., cs – 13:50 )

"használok, de erősen magyarázom őket kommentekkel."

mert basznak felfogni, s engem nyaggatnak.

( gabek | 2011. 12. 22., cs – 14:01 )

csak akkor használok, ha csak magamnak írom a kódot.

lehet fáradt vagyok, de szerintem a bitműveletek használata nem ezen múlik.

( wachag | 2011. 12. 22., cs – 14:03 )

4. pont, igaz, verilog nyelven szoktam írogatni :-)

A napokban a jcifs-et hackeltem, és messziről látni a kódról, hogy jó C-programozók próbálnak meg java-zni.
Na ott van bitwise művelet dögivel. Valahogy úgy vagyok vele, hogy ha már java, akkor legyen attrs.isReadOnly(), mintsem (attrs & ATTR_READONLY)!=0...

--
"A herceg én vagyok."

( srrrgei | 2011. 12. 22., cs – 14:06 )

Akkor használom, ha értelmes használni. Kommentben max. azt írom oda, hogy "miért" (ha nem egyértelmű). Ha valaki nem érti (hogy "mit"), az menjen vissza az iskolapadba.

( Replaced | 2011. 12. 22., cs – 14:08 )

foo |= bar;-t csak ne kelljen mar magyarazni, ami meg bonyi oda termeszetesen odairom az intenciot

--
NetBSD - Simplicity is prerequisite for reliability

ha bonyolult, akkor akar egy for ciklushoz / ternary operatorhoz is odairom kommentbe, hogy mi a faszt csinal ez a sor, nem azon mulik, hogy bitwise operator vagy nem. Tokmindegy, mirol van szo, ha komplex a cucc (pl. lusta vagyok leirni egy while-ciklust es inkabb megcsinalom egy for headerbe), akkor odairom, mit csinal, mas esetben nem vagyok hajlando kommentelni (doxygenen kivul persze, az mindenhova megy). Ha valaki elolvassa a kodom, akkor tiszteljen mar meg azzal, hogy legalabb olvasni tud az adott nyelvvel, ne az en idomet pazarolja azzal, hogy minden sort kommentelnem kell vagy elmagyarazni mindent. Cserebe igenyesen, szepen, tisztan, olvashatoan kommentelek, es doxygen-kompatibilis kommentet irok minden classhoz es methodhoz, author taggel egyutt, ha megis van problema, tudja, kit kell keresni.
--------------------------------
http://r1pp3rj4ck.wordpress.com/

( Tyra3l | 2011. 12. 22., cs – 14:24 )

bitmaszkolasnal szoktam, altalaban fuzok azert hozza megjegyzest.

Tyrael

( Dgzt | 2011. 12. 22., cs – 14:25 )

Általában a páratlan szám nézésnél szoktam ( szám&1 ), máshol csak néha, ha nagyon adja magát.
---------------------------
Oszt jónapot!

( tetra | 2011. 12. 22., cs – 14:31 )

"...használok, és alanyi jogon elvárom komment nélkül, hogy aki olvassa a kódom, az megértse."

Ezt egy kicsit hangulatkeltőnek érzem (vagy hogy mondod ezt, elfogult?). Igenis értse meg aki olvassa a kódot, hiszen járt iskolába, ellenben csak ott használok bitműveleteket, ahol ez szemantikailag logikus. Lásd lent, párosság ellenőrzésére, kettőhatványokkal való műveletekhez nem, bitmaszkolásra, hashszámoláshoz igen.

Szóval bitműveletekre szükség van, és ezt nem érzem hátránynak. Aki telerakja a kódját ilyenekkel, és nem hardverközeli szinten dolgozik, azt simán ki kell rúgni, mert szar programozó.
----
Hülye pelikán

( locsemege v | 2011. 12. 22., cs – 14:32 )

Nem is igazán értem, hogy az and, or, xor, shift operátorok miben mások, mint teszem azt, az összeadás. Azért vannak, hogy használjuk őket. Én sokszor mikrokontrollerre programozom assembly-ben, így nekem nagyon kézreállnak ezek. Tegyük hozzá, PC-re írt kódnál sokszor szerencsésebb, ha nem arra optimalizál az ember, hogy megspórol fél byte-ot a RAM-ban, meg két órajelciklust, itt nagyobb érték, ha a kód jól érthető, önkommentelő, általános, hordozható. Hardware-re - amire itt történt utalás, tehát például CPLD, FPGA -, mikrokontrollerre más szempontok az irányadók. Ott minden bit, órajel, makrocella, flip-flop számít, amit valahogyan megspórolunk.

PC-n le merem írni azt, hogy

a *= 8;

Ugyanakkor mikrokontrlleren ezt szinte biztos, hogy így intézem:

a <<= 3;

Vagy például:

rlf valami
rlf valami
rlf valami
movlw 0xf8
andwf valami, f

Ha pl. PIC-ről van szó.

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

( wachag | 2011. 12. 22., cs – 14:34 )

Különben Java programoknál tisztátalannak érezném magam bitenkénti műveletek elvégzése után.
Szerintem fogalmazd át ezt a szavazást.

Almos konyv szerint (Java Puzzlers) Java-ban csak indokolt esetben es kommentelve javasolt a bitmuveletek hasznalata. Van ott egy par pelda is, hogy hogyan lehet konnyen bugot tenni veluk a kodba.
Pl.:
boolean a, b;
a && b es az a & b kozott az a kulonbseg, hogy az elso lazy a masodik eager kiertekelesu.
Masik pelda amikor shiftelesnel bejatszik widening es/vagy narrowing primitive conversion es akkor csak les a programozo, hogy mi tortenik. Stb.

Ez f*szság. Aki a Java Puzzlers-t írta, nem tudja, mi a különbség a logikai és a bit szerinti és művelet között. mellesleg a "hivatalos" doksi szerint is így van: http://docs.oracle.com/javase/tutorial/java/nutsandbolts/opsummary.html

Csak hogy értsd: a=2, b=4
a && b = 1 (true)
a & b = 6
semmi köze a lusta és teljes kiértékeléshez (ennek ui. csak logikai kifejezéseknél van értelme, bitenkénti műveletnél nincs).

Nem tudom milyen nyelvu a kodod, de biztos nem java (&& nem adhato ki intekre), itt meg javarol volt szo.
En errol beszeltem, hogy ertsd (ez lefordul, de mig az elso sysout megy, addig a masodik NPE-t ad): 


        Boolean a = false;
        Boolean b = null;
        System.out.println(a && b);
        System.out.println(a & b);

Az altalad linkelt doksi helyes. A &, | bitwise operatorok nem engedelyezettek booleanre. Boolean eseten viszont van ket operator, amiknek ugyancsak &, | a jele, de a jelentesuk mas. Ezek logikai operatorok. A && meg || pedig felteteles operator. Es bizony hogy a &, | eager a &&, || meg lazy.
De pont errol szol a hiba, hogy a legtobb programozonak errol lovese sincs (vagy ami rosszabb tudja, csak rosszul).
Ezek mennek meg a baranyfelhok.

( Csab | 2011. 12. 22., cs – 14:46 )

Nem a bitenkénti műveletek szorulnak magyarázatra:

int b = (int)(exp(a*log(2.0))+0.5); // Idióta vagyok és az 1 << a művelet meghaladja a képességeimet

:)

Amúgy ilyen gyakran kell. Például definiálok egy boolean változót egy bitre. Amíg bit művelettel hivatkozom, nincs is baj vele, de ha maszkkal, akkor épp erre van szükség. Teszem azt, eben a változóban három bitet állítanék 1-be:

movlw 1 << egyik | 1 << masik | 1 << harmadik
iorwf flags, f

Különben az a gyanúm, az assembler nem ismeri az exp() és ln() függvényeket.

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

Úgy emlékszem 486-os óta ismeri, amikor belekerült a koprocesszor minden gépbe.

http://siyobik.info/main/reference

De mondjuk mialatt a SHIFT 1-2 órajel alatt végbemegy, addig a lebegőpontos processzor műveletei már nem.
Mintapélda, hogy hogyan lehet elcseszni a teljesítményt.

Nem volt definiálva, hogy milyen assembly, ezért feltételeztem, hogy AMD/Intel.

Nyilván, ha a processzor nem tartalmaz lebegőpontos hardvergyorsítást, akkor még nagyobb a gáz.
Kb. 50-100-szoros lehet a sebessége a lebegőpontos processzornak, összevetve a szoftveres megoldásokkal.

8 tizedesjegy pontosságnál a log/exp kb. 8 szorzást és 8 összeadást igényel.
A fenti művelet kb. 35 lebegőpontos összeadás/szorzás eredménye.

Általánosságban beszéltem, az iorwf-ről még nem hallottam.
A kód úgy néz ki, mintha fordítási időben lenne feloldva. Az

a = (1 >> C1)|(1 >> C2 )|(1 >> C3)

az ekvivalens azzal, hogy

a = 7

ha C1=1, C2=2, C3=3. Futtatási időben semmi sem történik, pusztán jobban olvasható. A fent említett operátorok movlw-nél vannak, így biztos, hogy konstans kifejezés és nem a PIC-en fut le.

Amit írtál, balra shifttel jobb lesz. ;) Az 'a' pedig 14.

Persze, fordítási időben kiértékelődik. Viszobt nem csak a kód olvashatósága az egyedüli cél. Ha vaéamiért másik bitpozícióra teszem az illető boolean változót, akkor sem borul meg a kód. Ugyanakkor, ha bedrótozom a kódba a maszkot, az anyja sem ismer rá, hiszen a maszkból ugyan látszik, melyik bittel mi történik, de az nem, hogy melyik bitpozíció melyik változó, valamint a változók pozíciójának megváltoztatása után összedől az egész program.

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

Na ezt nem kellett volna elsütnöd, mert itt villamosmérnökök is vannak.

Amikor bemész egy elektronikai boltba, hogy csókolom 10k-s potmétert szeretnék, a következő kérdést kapod vissza:
- lineárisat, vagy logaritmikusat?

A füled a hangerősséget logaritmikusan és nem lineárisan érzékeli, ezért kell a logaritmikus potméter.
És még ezer más helyen használnak logaritmikus jeleket az elektronikában, márpedig a mikrokontrollerek fő alkalmazási területe az elektronika.

(a potméter változtatható ellenállás, tekerővel csavargatod)

Te, kitekerem a nyakad! :) Villamosmérnök vagyok, analóg és digitális elektronikák fejlesztésével egyaránt foglalkozom. Ugyanakkor az assemblernek semmi köze a logaritmus függvényhez, szögfüggvényekhez. Ha konstansként kell, kiszámolod valamilyen scripttel, számológéppel, bármivel. Ha futásidőben kell számolni, lehet implementálni akár lebegőpontos aritmetikát is - többnyire megúszható -, de akkor a dolog egy sima szubrutin hívás azok után, hogy a megfelelő paramétereket átadta az ember. Az assembler nem is tud arról, hogy az illető rutin logaritmust vagy szinuszt számol.

Ezeknek a függvényeknek többnyire float a kimenete, amelyet byte-on ábrázolni ritkán érdemes. Tudom, le lehet írni akár ilyesmit is:

valami equ 127*sin(barmi*pi()/180)

Ha ilyesmi kell, többnyire táblázatot használ az ember, amelyet egy script generál önálló file-ba, s ezt include-olom be.

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

Hát, mondjuk a hangerőszabályzáshoz nem használnék táblázatot. Még az sem gáz, ha 1 másodperc kiszámolni a log függvényt.

Ha pedig emlékszel a C64-re, az 5 byte-os lebegőpontos aritmetika 1 MHz-en még nem volt olyan nagyon lassú. Lehetett számolni vele. A log függvény gyorsan konvergál.

Az sqrt függvénnyel már cselezni kell, mert 1 közelében a konvergencia már rohadt lassú. Azt csináltam, hogy konstansokkal osztottam/szoroztam a számot, hogy gyorsabban konvergáló részbe átrakjam. Magyarul: osztod 1.1-gyel, a végeredményt meg szorzod sqrt(1.1)-gyel.

:)

Egyébként lehetnek területek, ahol hardvertámogatás is szükséges lehet egy mikrokontrollerben a gyors lebegőpontos műveletekhez. Nem lehet mindig bitenként shift-elni egy hülye szorzáshoz / osztáshoz.

Inkább most hagyd abba, mert egyre rosszabb :-).

Ha az 1 mp 99 %-ban idle-ben (sleep-ben) van az MCU, máris sokkal kevesebbet fogyaszt, vagy használhatsz kisebb teljesítményű kontrollert, vagy más feature-t rakhatsz bele. Ez nem a mai PC, amikor jóformán tök mindegy, mit hogyan csinálsz. Ide tudás is kell (fú, mekkora flame lesz ebből :-) ).

Szóval, jó, hogy végül nem villamosmérnök lettél :-).

Te is hagyd abba. Tudod én nem fogok táblázatból logaritmust számolni, ha

float f = log(c);

-vel megoldok mindent. És rohadtul nem érdekel, hogy táblázatból 0.001us, míg anélkül meg 10 us, várjon 10 us-t a felhasználó a hangerőállításnál.
Táblázatból 1 nap lenne, anélkül meg 10 másodperc megírni, a felhasználók meg nem veszik észre, hogy 10 us-t késik a hangerő állítása.

Inkább hagyjuk a féligazságokat. Amit leírtál, abból az következik, hogy 10 mA-es táp is bőven elég neked, mert ugye az MCU úgyis 99%-ban nem csinál semmit.

Maradjunk annyiban, hogy nem mindig éri meg vadászgéppel lövöldözni a verebeket, néha a csúzli könnyebben célhoz visz.

Tény, hogy sokszor nem foglalkozunk a fogyasztással. De kéne.
Különben táblázatból nem nagy etwaß. Fogod, beírod a megfelelő értékekhez a konstansokat (akár le is generáltathatod, ha akarod), azt kalap, kabát. Régen rossz, ha ez egy nap.
És igen, pont volt egy olyan feladatom, hogy sinusjelet szintetizálni DSP-vel (egyszerű "zongora" létrehozása). És igen, a lebegőpontos sin számítás nem volt jó nekünk hozzá (igaz, fixpontos aritmetikájú BlackFin volt).
És nem, nem azt írtam, hogy 99 %-ban nem csinál semmit. Hanem hogy nem egy olyan minimális hülyeség, hogy hangerőszabályozás viszi el a proci jelentős idejét. Tudod, ez sokszor számít. Kisebb fogyasztással sokszor kisebb tápegységet, vagy kisebb kihasználtság miatt kisebb MCU-t vehetsz, ezzel súlyos pénzeket lefaragva a tömeggyártásból jövő költségekből. És ebben az esetben pont nem akkora nagy meló a dolog (főleg, mert egyszer megírod, aztán kész).

Inkább nem vitázom tovább, végülis nekem lesz ez a munkám, ha még ezek után felvesznek engem valahová :-).

Különben nem sértegetni szándékozom, remélem, átjön, ezért szoktam vigyorizni. Néha lehet, hogy szűkmarkúan teszem.

"nem érdekel, hogy táblázatból 0.001us, míg anélkül meg 10 us"
Ez egy telefonon vagy MP3 játszón lehet ,hogy igaz.
A felhasználó azt is kibírja ha a 100% mcu terhelés miatt a hang is megakad.
Bár a felhasználó azt sem venné észre ha ,nem log szabályozást használnál.
Ez egy camac-nál megengedhetetlen , ott már az esemény elment , és mi lemaradtunk.
Hogy mikor milyen algoritmust választunk , az erősen hardware és feladat függő.

Jaj, megfájdítottad a szívem! Van neked lelked? Hát hogy írhatsz ilyet? :))

Egyrészt az MCU-kban jellemzően nincs lebegőpontos hardware támogatás. Legtöbbször még fixpontos szorzás, osztás sincs. Van összeadás, shiftelés, rotálás, bitenkénti and, or, xor, adatmozgatás. Úgy nagyjából. A memória kevés, szóval mire megírnád a lebegőpontos aritmetikát, nem marad hely a feladatra.

Lehet, hogy a futásidőd is kevés. Például E1 trunk-ön jönnek a hangminták egy 2.048 Mb/s-os stream-en, s valamit nagyon kellene velük csinálni, mert a sok ember csak telefonál, csacsog vég nélkül, s generálja a hangmintákat. :)

Aztán van olyan helyzet, hogy a villanyod kevés. 10 mA? Melléd települt Paks? Amit legutóbb csináltam, az 130 µA-t vett fel, de ebből úgy 100 µA-t a tápegység. Szégyelltem is magam, hogy ennyit eszik, de normális, kis fogyasztású tápegységből csak bontatlan 5000 db-os csomagot akartak eladni.

Feladatfüggő erősen, hogy mire optimalizálunk. Amit te írtál, az az emberi erőforrásra minimalizálás esete. Hamar, olcsón megvan a fejlesztés, viszont sallang a kód, nagy, lassú, felesleges, sokat fogyaszt.

Aztán lehet optimalizálni kód memóriára, adat memóriára, futásidőre, fogyasztásra. Sokszor ezek közül többre. Nem mindig mondanak ezek egymásnak ellent, bár néha igen. A fizikai sebesség a fogyasztásnak eléggé ellent mond. Tehát ilyenkor kell futásidőre optimális kódot faragni, hogy ne kelljen az eszközt gyorsan hajtani. Vagy eleve nem tudod gyorsan, mert az már egy drága eszköz lenne, s szeretnél egy pici, egyszerűbe beleférni.

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

Az emberi munka általában költségesebb a villamosenergiánál, meg a jó hardvernél.

Az olcsó tömegcikkeknél még érdemes optimalizálni, de kis tételben nem. Lehet vagy 500ft különbség egy erős és egy kicsi mikrokontroller között.

A komolyabb AVR-ekben van lebegőpontos hardver aritmetika és a 32-384k nem olyan kevés memória.

Nyilván priorizálni kell, mi mennyit ér. A fejlesztés viszont egyszer lesz drága, míg ezután a termék minden példánya jó.

Ami a fogyasztást illeti, elég kellemetlen megmagyarázni a felhasználónak, hogy az elemes szerkezetében - pl. TV távirányító - miért kell 2 havonta elemet cserélni. Ilyen hibás döntéssel nagyon el lehet szúrni egy terméket. Inkább a fejlesztő agyaljon rajta 5 munkanappal többet, de lehet akár 2 hét is, de az a termék legyen jó.

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

Az, hogy mit bír ki, s az, hogy ebből mit használsz ki, két külön dolog. Nyilván sokat fog fogyasztani, ha egy LED-et kell meghajtanod.

Amit írsz, az általában úgy van megadva, hogy az adott portlábra definiálnak egy maximális áramot, ezen felül külön megadják, hogy mekkora áramot folyathatsz be a táplábon, s mekkorát folyathatsz ki a GND-n. Ebből az is jön, hogy egyszerre nem terhelheted a portokat akkora árammal, mint amekkorával külön-külön. Ez nem ellentmondás, hiszen sokszor csak 2-3 portlábra kell a nagy áram, lehet, hogy a többit bemenetnek használod, vagy kimenetnek, de valamilyen CMOS vezérléshez akár. Ha minden portra kell a nagy áram, akkor valamilyen illesztőt kell használni.

Tehát például egy portlábat terhelhetsz 25 mA-rel, van mondjuk 13 portlábad, de a GND-be legfeljebb 150 mA-t lehet folyatni. Ebből le kell vonni az IC saját maximális fogyasztását, marad mondjuk 146 mA. Maximális árammal így 5 portlábat terhelhetsz egyidőben, kisebb árammal viszont többet is.

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

"A komolyabb AVR-ekben van lebegőpontos hardver aritmetika és a 32-384k nem olyan kevés memória."
Ez azért nagyon erős túlzás. Csak néhány AVR-32-ben XMegában van fpu, pedig egy mega128 se olyan vacak, de abban csak egész szorzás van pluszban, az is ha jól emlékszem 5 órajel (míg a legtöbb utasítás 1 órajel).

( bbandi | 2011. 12. 22., cs – 14:46 )

Mikrokontroller programozásban (c-ben) elvárható, hogy az olvasó is megértse.

( saxus | 2011. 12. 22., cs – 16:07 )

Használom, de csak ott, ahol valóban bitműveletet akarok végezni.

----------------
Lvl86 Troll

( BaT | 2011. 12. 22., cs – 17:22 )

"...használok, és alanyi jogon elvárom komment nélkül, hogy aki olvassa a kódom, az megértse."

Erre nyomtam, mert általában amire használom az elég triviális. (Bitmaszkolás, shiftelések, ilyesmi.) Aztán eszembe jutott, hogy egyszer össze kellett dobnom gyorsan egy kódot valamire, és a nagy sietségben a kommentelésre sem maradt időm. Egy kis challenge: mit csinál a kód? http://pastebin.com/Eh8rjPzR

--
Don't be an Ubuntard!

( Qcsaba | 2011. 12. 22., cs – 17:36 )

DMX vezérlőknél , MIDI muxoknál , Camac rendszereknél szinte csak bit müveletek vannak.
Itt nincs nagy értelme a kommentelésnek , tehát vagy érted vagy nem érted.
Az adott firmware kötelező flow diagramja sokkal nagyobb segítség.
Kevés a kód újra hasznosítás , mert ritkán kell azonos hardware-re másik kódot irni.
De ez kifejezetten hardware programozás.

Hát igen, a kommentelés akkor kell, ha van információ tartalma, különben elvész a lényeg.

/* this is a 'for' cycle which iterates i from 0 to 9 */
for(int i=0; i < 10; i++ ) /* i++ increments variable i by one */
{ /* section start */
  printf("%i", i); /* writes out the value of i */
} /* section end */

Sajnos láttam már hasonló szellemiségben kommentezett kódot.
A sok komment még nem jelent jól dokumentált kódot.

:)

( lgb | 2011. 12. 22., cs – 18:05 )

6502 assembly-ben minden nap hasznalok egy csomot :D Meg persze C-ben.

Hat ha ugy erted, hogy mint "aktiv a mindennapi ember szamara" dolog, ugy nyilvan kihalt, egy atlag felhasznalo nem fog pl C64-et hasznalni PC helyett ma mar :) Nyilvan ott el ez a dolog, akinek ez hobby, ilyen szinten meg lehet, hogy sose fog kihalni, akar ezer ev mulva is erdekes (bar sokak szamara erthetetlen) hobby lehet (megjegyzem: a hobbynak nem feltetlen van konkret logikus oka es/vagy celja). Tehat a lenyeg: konkret celom nincs vele, csak hobby, ahogy mas 8 bites cuccokkal valo foglalatossag is (pont ezert is erdeklodtem itt egy masik comment nyoman az FPGA-krol, ilyesmi projecthez - is - kellene).

Nem minden ág halt ki az 1980-as évekből.

http://www.hestore.hu/cat_436.html

A linken egy Z80-as mikroproceszort látsz, 440 Ft-ba kerül, lehet kapni, használják.
Nem is drága, kb. max 10000 Ft-ból felépíthetsz egy ZX Spectrum szintű számítógépet magadnak.

A 6502-es ág kihalt, a Motorola nem fejlesztette tovább. A Zilog viszont elérte, hogy a Z80-as processzor "szabvánnyá" váljon, ha valaki sürgősen 8 bites gépet akar építeni valamilyen okból.

Állítólag MP3 / WMA lejátszókban találni ilyen procit más név alatt.

Ez igaz. Viszont ahova közvetlen memória hozzáférés kell manapság, oda elég sovány az a 4 MHz úgy, hogy a NOP utasítás 4 órajel, a SET 6, (IY+valami) meg 23 órajel. Egy mikrokontrollerrel valamilyen soros porton - akár USB-n - nagyobb sávszélességet lehet biztosítani, mint Z80-on DMA-zva. Tanulni persze jó. Azokban az időkben ZX Spectrum-om volt. :)

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

Jó, az is érdekes, mit nevezünk Z80-nak. Én azt, amit a Zilog valaha csinált. Mai technológiával az sem nagyon lepne meg, ha 10 GHz-es is lenne. Ha jobban belegondolunk, a gépemben lévő Phenom II. X4 955-nek, amely 3.2 GHz-ről jár maximum, van némi halvány rokonsága a Z80-nal. Igen halvány, talán a 8080 környékéről. ;)

Meg aztán egy Z80 CPU-t egy FPGA-val is meg lehet valósítani. Mondom, semmi bajom nincs vele, nagyon szerettem, de eljárt felette az idő. Éppen azért írom, mert programoztam sokat Z80-ra is, keveset 80C32-re - illetve Dallas 80C320-ra -, meg többféle PIC-re.

Az előbbiek CISC-ek, az utóbbi inkább RISC. Érzésből azt mondanám, mivel hardware-esen sokkal több mindent megcsinál egy CISC, gyorsabb, s rövidebb lesz a kód. A tapasztalat erre rácáfol. Valahogy a RISC-kel hatékonyabban megoldhatók a feladatok.

Kis PIC-eken nincs adat stack. Az elején féltem tőle, hogyan fogom menteni a regisztereimet. Aztán kiderült, nem is hiányzik, kell a fenének, csak egy kis szemléletváltás kell, amelyben az ember tudomásul veszi, hogy nincs PUSH és POP utasítás. Meg EX (SP), HL. A nyereség viszont az, hogy a sok PUSH és POP a rutinok elején, végén lassú volt, ahol ez nincs, az nem is tud lassú lenni.

Aztán a Z80-ban hamar elfogytak a regiszterek, azokat stack-re vagy memóriára kellett tenni, az adatmozgatás meg lassú. PIC-en fileregiszterek vannak, így lényegében az egész RAM egy-egy lapja elérhető direkt címzéssel gyorsan, tehát bármelyik cím regiszterként kezelődik. Egy PIC butább, egyszerűbb a core, viszont jobban kitalált. Szigorúbb, de tisztább gondolkodást igényel. Mondjuk ez szubjektív, de így érzem.

Ami meg a 80C32-t illeti... Az meg milyen, hogy 16 bites pointert tud inkrementálni, ugyanakkor dekrementálni nem, így arra pici szubrutint kell írni, s azt hívogatni? Jaj... :(

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

Ez attól függ, miben állapodsz meg magaddal. Egyrészt az

EX AF, AF'
EXX

rekurzívan nem jó, mint a PUSH, POP. Aztán például a ZX Spectrum a lebegőpontos aritmetikához regiszterekben tárolta az operandusokat, hogy gyorsabb legyen, így másra használni bizonyos esetekben nem lehetett.

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

A korabeli gépek órajelét általában az határozta meg, hogy a PAL/NTSC jelet könnyű legyen belőle előállítani (az NTSC c64 pl gyorsabb mint a PAL). Még az első IBM PC-k órajele is innen jött (CGA átvett pár dolgot az NTSC-ből)
Egyébként wiki szerint a z80 utáni betű határozza meg az órajelet. A Z80 2.5MHz, a nagyon elterjedt Z80A 4MHz, stb. CMOS verziók 20 MHz-ig mentek. Ami 50MHz-t tud, az csak kompatibilis (eZ80), és állítólag azonos órajelen 4x gyorsabb a Z80-nál.

A 6510-es (C64) is 2MHz-et bírt, de 1MHz-n pörgött.

Bár C64 alatt a dolog kicsit bonyolultabb volt, mert a videokártya időnként DMA-zott, szóval a sebesség grafikusmód függő volt. Ha letiltottad teljesen a képernyőt, akkor volt 1 MHz. A Plus4 meg még brutálisabb volt, mert 1.76 MHz-n ment a képernyőkeret rajzolásánál, 0.88MHz-en ment a látható terület rajzolásánál.

Manapság már teljesen szokatlan a grafikusmód függő órajel, de akkor még tipikus volt.

( Hijaszu | 2011. 12. 22., cs – 18:21 )

Ha bonyolult, akkor talán szét kellene emelni érthető részekre. Ha a sebesség is számít akkor meg makróval és nem függvényekkel. A megjegyzés az a rész, amit senki sem szokott frissíteni, mikor változtatja a kódot (sok olyan megjegyzést láttam már, amely zseniálisan leírt valamit az utána következő kódra - amely teljesen mást csinált már). És igen, elvárom még egy juniortól is, hogy legalább el tudjon olvasni egy kódot, mert azért van a szoftverkód, hogy leírja, hogy mit kell csinálni (a megjegyzés meg azért van, hogy lehetőleg kerüljük el a használatát, mert nem írja le, hogy mit kell csinálni, hiszen a fordító rögtön kidobja). Tessék értelmes változó és függvény neveket választani :D

Egy junior kódertől is elvárom, hogy kommentekkel lássa el a forrást, és azokat tartsa is karban. Ugyanis az is a forráskód része.
Ha valamely rész tudottan problémás, nem felel meg 100%-ban a kódolási konvencióknak, de valamilyen okból mégis meg kell hagyni, akkor pl. FIXME megjegyzést várok el a kérdéses kódrészlet előtt, ha tudottan bugos, vagy bizonyos esetben hibásan működik egy rész, akkor BUGBUG legyen ott (javítás után meg törölje onnan), satöbbi.
A verziókezelőbe küldéskor meg a commit megjegyzésbe kerüljön bele a hibajegy száma.

( b | 2011. 12. 22., cs – 19:42 )

Előszeretettel használom még ott is ahol nem teljesen indokolt a használata lol.

--
GPLv3-as hozzászólás.

Lehet, hogy én nem értem a bitwise operátorokat, de a linkelt kódban gyakorlatilag nem csak a kettő hatványaival való szorzás-osztásra használod ezeket? Ha igen, akkor ez ilyen jelentős különbséget produkál a *Math.pow(2,shift)-hez képest? (egyébként kétségkívül amint rászokik az ember szeme, olvashatóbb annál.)
Btw jól fest. :)

int getRandomNumber() { return 4; }  // ← aláírás
//szabályos kockadobással választva. garantáltan véletlenszerű.  xkcd

http://www.javascripter.net/faq/arithmet.htm
A szabvany szerint js-ben a szamok floating pointban tarolodnak, de ha bitshiftet hasznalsz, 32 bites intte alakitja, utana meg vissza. Szoval egyaltalan nem biztos, hogy ne lehetne enelkul js-ben gyors terkepeszeti alkalmazast irni, butabb js interpreter/JIT eseten valoszinuleg epp enelkul lehet (okosabb meg ugyis kioptimalizalja barmelyiket is irod).

Egyebkent jopofa ez a minimap. Egyetlen idegesito tulajdonsaga, hogy zoomnal nem az egermutatohoz zoomol (pl. google maps), hanem a terkep bal felso sarkahoz.

--
Das "N" in RTL steht für Niveau... -Tuamo/Reel (?)

( GerzSonka | 2011. 12. 23., p – 06:32 )

2 sor kód, 10 sor komment. Aki nem így kódol, még soha nem tartott karban uszkve kétmillió soros komment-mentes terméket.
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

Az ugye megvan, hogy a kifejezesed erteke nem 7?

Amugy kommentek menjenek a fenebe, semmit nem ernek, menkuhosszu valtozonevek es egyeb kotelezo kodolasi szabalyok sokkal tobbet.

Tudom, az elet szerintem is 2 millio sor felett kezdodik,ellenben lattam mar agyonkommentezett kodot, aminel jobban jartunk volna ertelmes valtozonevekkel, kiirt triplaoperatorral (? : ) esatobbi.

Szerintem meg de :-P tucat/2=6, 6++ az meg hét :-) Ahol én hegesztettem kód, ott a kommentekre is volt egy kötelező minimum. Mivel minden modult legalább ketten átnéztek, így ha valami valakinek nem volt 100%-ban érthető/tiszta, akkor oda ment plusz magyarázat a forrásba.
Pl. egy select .... decode(...) esetén oda kellett rakni, hogy honnan jön, hol van definiálva az eredeti értékkészlete a mezőnek, amit adott select esetében emberi fogyasztásra alkalmas formára hozunk.

A (tucat/2)++ alapvetően nem értelmezhető művelet, ugyanis egy temporálist használ lvalueként. De tegyük fel, hogy megoldod. Ekkor is a kifejezés értéke 6 lesz, hiszen a posztfix operátor kifejezésének értéke az eredeti érték, és a háttérben növeli meg azt.
----
Hülye pelikán

Hat en ezektol hisztit kapok pl.:


/** adds two integer numbers to a given instance
* @param instance_id The instance of the given id
* @param number_a The first number to add
* @param number_b The second number to add
*/
public void addTwo(ID instance_id, int number_a, int number_b){
...
}

Mindig azt szoktam mondani, hogy ez itt szep, de a meghivas helyen nem lesz ott, nyilvan az IDE majd kirakja mouseoverre, de ettol meg ha adna neki egy ertelmes nevet, akkor olvashato lenne a dolog anelkul is.

Ha kotelezove teszed a kommentelest a programozoknak, azok Mr. Obvious kommenteket fognak irni, es volt mar nem egyszer, hogy 120 oldalas api-doksiban egyetlen dolog nem volt obvious, de az is ugyanugy volt talalva mintha az volna.

Egymásnak és magunknak írtuk a kommenteket, úgyhogy senkinek semokozott agyrohadást az, ha normálisan le lett írva egy-egy modulról illetve eljárásról, hogy milyen paramétereket vár, mit csinál, mi a kimenete, és melyik taszkhoz, ki készítette, mik a függőségei (dblink, tábla, eljárás, illetve függvény).

Sok "rizsa"? Lehet. Viszont egy helyen ott volt minden infó az adott csomagról, ami a használatához, módosításához, megértéséhez szükséges volt. A "miért"-ekre meg ott volt a válasz a hivatkozott taszk leírásában.

API-t tervezni kell. Ha fölveszel 100 gurut, azok is eltolják.

- az egyiknél false ha hiba van
- a másiknál nem 0, hanem egy szám
- a harmadik mindig exceptiont dob

Windows API az egyik elrettentő példa. Hol a 0 az oké, hol az 1.

Le kell ülni és logikusan átgondolni a teljes felületet, ami a felhasználó felé van.

Az, hogy a felhasználó időnként std::string-et, máskor char *-ot unsigned-del kombinálva kell, hogy átadjon tragikus.

Előző munkahelyemen volt csapat, aki az API-t tervezte. Nem a leghülyébbekre bízták. Ha változtatni kellett az API-n, az kizárólag rajtuk keresztül történhetett.

Mondjuk volt hátránya is, mert a kód tele lett hirtelen reflection-nel, mert néha jobban tudták, hogy mi kell a fejlesztőknél. Végül a főnökkel beszéltem, hogy létszi, ne private gettert, az úgy nem megy...

Végül eltávolítódott az összes reflection, csak értelmes embert kellett találni.

Na az a szép, amikor teleszemetelik az emberek a forráskódot idióta commentekkel, ahelyett, hogy élnének
a programozási nyelv adta egyéb lehetőségekkel: beszédes változó nevek(nem hungarian notation meg nem myVariable!), függvény elnevezések,
strukturálási lehetőségek stb.

Tiszta és olvasható kódot kell írni és kész ahelyett, hogy megjegyzésekben magyaráznánk el, hogy mit miért csinálunk...

Egyetértek. Üzemeltettem más által írt sz@rul kommentezett kódot, rémálom. Nem azért, mert nem értem azt, ami az orrom előtt van, hanem mert megtalálni szinte képtelenség benne valamit.
Ez nyilván nem a hatsoros pilinckákra igaz, de egy több tízezer soros kódnál inkább azt is elmagyarázom két sorban, hogy a nap keleten kel fel, minthogy valaki pont ezzel a számomra triviális dologgal szívjon akár csak 10 percet is, amikor egy élesen üzemelő rendszerben meg akar találni valamit.

http://haxel.hu/wodehouse-konyvek.html

Mindent normalisan le kell dokumentalni, hogy third-party ugyfel is megtalalja az API-ban azt, amit akar, masreszt addig ne kerdezzen, amig nem olvasta el, mert RTFM. Belsos cuccban meg kell lenni valami konvencionak, ami alapjan azert a kollegak el tudjak olvasni egymas kodjat anelkul, hogy leirnad, hol kel fel a nap.
--------------------------------
http://r1pp3rj4ck.wordpress.com/

( hrgy84 | 2011. 12. 24., szo – 13:00 )

Hasznalok, de egyertelmu helyeken, ha nem egyertelmu, konstansok bevezetesevel segitem a megertest.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal