[C] bitni operator

Karkoli vržeš v oklepaje bo prevajalnik skušal prevesti v logično izjavo, torej ja.

Probi tkole:

if (int_reg && 0x01)

if (karkoli_različno_od_nič) {} //true
else {} //false

Kaj je pa s starim dobrim == narobe?:)

Sam tko ... a to kako name leti al kaj?

Sicer pa, v C in C++ testiraš naprimer 5-ti bit x TOČNO na tale način if (x && 32) ...

Kdor tega ne ve in ne pozna ... se je lahko zdej naučil.

Ne, ni.

To je pač bitwise AND, ki NE spremeni vrednosti x-a. Samo če ima x na petem bitu 1, bo to večje od 0, sicer ne.

C in C++ sta smotkana v tem smislu, da ne podpirata direktnih testiranj bitov, pač pa je treba it na ta način.

Ja?

Ja, ja, maš prav.

Tale && v C++ (v dialektih kjer pač obstaja) zreducira vrednost števila na 1 ali 0 in potem naredi operacijo AND.

Maš prav, jest mam narobe.

Kako ni testiranja bitov? Ne razumem... Seveda je.

V bistvu ni elementarna.

CPU to interno vedno naredi paralelno, vsaj pisanje v RAM, pa verjetno tudi v register. Ne moreš v enem šusu vpisati samo nekaj bitov v besedi.
No, bili so VRAM-i, kjer se je to dalo in mogoče kje kak RAM to tudi danes omogoča (kak SGRAM ?) pisanje skozi masko, a načeloma tega ni.

Pri današnjih frekvencah procesorjev se kak BSET x,REGy ne razlikuje dosti od OR XYZW, REGa.

O.K. Operand je daljši, zato pa lahko setiraš poljubno kombinacijo bitov.

Če ni direktne funkcije, jo pač napišeš.

bool IsBitOn(int number, int position)
{
	return (number &= (1 << position)) > 0;
}

Ta en sam ukaz lahko traja enako ali več kot read + or.

Največ te tu stane bralni cikel iz pomnilnika, tisti OR pa skorajda nič.

JA, tudi meni se zdi čudno, da ni bitne manipulacije, ampak ni velike izgube.


Bolj čudno se mi zdi pakiranje bitov. Ne samo pakiranje ampak nedefiniranost zaporedja "packageov".

Kot sem jaz videl, standard ne govori nič o tem, kje bo kakšen bit. To pa je neuporabno za definicijo bitov kakega I/O registra itd.

BT, bit test, ponuca 4 clock cikle pri delu v registru. Isto, kot samo za shift, kje je še drugo?

Biti in operacije z njimi so vse bolj pomembna reč, celi byte, word ... itd. pa precej "umetne tvorbe".

C tukaj - ne zaostaja - zaostal je davno!

Biti in operacije z njimi so vse bolj pomembna reč, celi byte, word ... itd. pa precej "umetne tvorbe".


Vendar pomnilnik operira v chunkih od bytea itd. (ajde, tudi nibble, če iščeš).
Če pišeš enoto, manjšo od chunka, te to stane več, saj moraš vsebino spremeniti tako,d askombiniraš novo s staro.

Si ziher ?

neisem se zadnje čase toliko poglabljal v to, samo to malo težko pogoltnem.

Maš kak link pri roki ?

Kot mi je znano, je tu ozko grlo /vsaj pri recimo Opteronu dekoder. Ta lahko dekodira v vsaskemciklu do tri integer ukaze iz cachelinea.

Jasno je, da je recimo OR immediate_konst, REG lahko daljši od BSET X, REG zaradi tega, ker je ukaz daljši.

Ampak to je faktor samo ob prvem zajemu ukaza. Ko je stvar v L1 cachelineu iz katerega zajema dekoder, je ta davek plačan.

Vsa naslednja izvajanja bi morala biti izvedena v 1 ciklu, če takoj za ukazom ni skokov itd.

Shift link.

Bit test link.

No, tole je bl novo.

Sem se spomnu ja, da ker tako neumno dela tale dvojni ampersant, ga nismo vključili v Critticall.

Čaki mal, kaj neumno dela? Pač logični operator v nasprotju z bitnim &. Drugo je kaj C vzame za logično, boolovo vrednost, ker nima posebnega tipa za te stvari.

Dvomim, da obstaja kakšen višjenivojski jezik, ki ima logični in definiran drugače.

IMHO zato, ker dvojni and sploh ni namenjen temu, za kar ga skušaš uporabit.

Je le za clever bližnice,da ti ni treba pisat if else if else if else if ...

bitwise: 1 & 4 = 0
logično: 1 && 4 = 1
Ima pa to drugo bol mal veze s samim operatorjem in več s pojmovanjem logičnih vrednosti v C-ju. Operator hoče imet logične vredosti na vhodu in vrne logično vrednost na izhodu. 1 ni logična vrednost in se prevede v nek 'true', ki je definiran le v kompajlerju, isto velja za 4. Rezultat je isto kompajlerski 'true' (pri tem da operator izpusti izračun druge vrednosti kadar je rezultat znan že po prvi). Ko ga pa ti sraviš v nek C tip, recimo int, pa rata 1. Čudno? Neumno? Simple kot pasulj.

Pri C++ je malo drugače, ker dejansko imaš bool tip, vendar je operator zaradi kompatibilnosti podedoval C pretvorbo int vrednosti v bool.

Thomas, operato&& ne le da ni neumen, tudi zelo uporaben je. Ne vem kaj ti delaš brez njega ampak očitno se mučiš z & za brezveze. Čisto druga vrsta geekovstva. Če je pa bolj spoštovanja vredna...

Se pa strinjam s tabo do neke mere (se mi zdi da razmišljaš v tej smeri), in mi je recimo veliko bolj všeč, če je napisano if (a > 0), kot if (a)

Zakaj OR vseh bitov ravno v 0-ti bit, kadar se sprašujemo, če je nek integer (ali kakšen drug tip) true?

Ta dogovor, potegne za seboj nesimetričnost bitnega stringa.

Tile se tud sekirajo zaradi tega.

In to rešujejo na svojski način. +0 in -0.

Tretji spe raje rečejo, da true je -1. Ki ima vse bite na 1 in ni nesimetrije.

> To da so se, ko so načrtovali C, odločili proti uporabi dedicated bool tipa, je po moje slabo.

Absolutno slabo.

> To da so se odločili zakodirat bool v int tako, da je 0 false in vse ostalo true je pa še najboljša možna alternativa.

Boljš bi blo - v sicer že zamočeni situaciji - da ima true vse bite postavljene na 1. False pa vse na 0(, kot aktualno ima).

"Vmes" pa nič, ker sta samo dve različni vrednosti booleana. "3 && 5" je nesmisel.

Gundlof, hotel sem rect da vsi te ifi (tut tvoji) odpovejo pri floatih.. je pa definitivno boljs x!=0 kot x>0 ce zamenjujes if(x)

Čeprav ne vem, če res odpove, če mu notri daš float.

Odpove lahko, če imaš numerično nestabilen problem in si blizu 0.

> Aja, kaj je tvoja nova ideja, da postane '&' kar ekvivalenten '&=' ?

Ne. Moja "nova ideja" je ta, da "strict C", ki ga pozna Critticall je dovolj. Vse je prevedljivo vanj.

Sej nič hudega, če se noben ne strinja, to je moje stališče, ki pa ga nisem niti pripravljen braniti, ker nekaterih reči nisem pripravljen razlagati

Ampak če že vprašaš.