🚀 go-pugleaf

Marek Kotowski <mkot@imm.org.pl> napisal
[...]

>   First things first: mnie nie chodzilo o uniwersalnosc
> (o tym nizej), ale zeby rzecz zapisac w postaci
> makroinstrukcji, a nie operacji przypisania. W dodatku
> uzyl Pan nazwy SET_ALL_BITS, co jest forma czasownikowa

Jezyk angielski znam bardzo slabo.
Moze byc ALL_BITS ? :)

[...]

> 2. Rozsadne tez jest (chociaz nie zawsze tak robilem)
> odseparowac te tablice od reszty programu. Dostep
> do tablicy realizowany jest przez zestaw funkcji
> manipulacji na bitach:
> 
> void SetBit(int Bit);
> void ClearBit(int Bit);
> int  IsBitSet(int Bit);
> void SwitchBit(int Bit);
> void SetAllBits(void);
> void ClearAllBits(void);

Wszystko pieknie, tylko ze zazwyczaj masek bitowych uzywa 
sie tak gdzie efektywnosc jest wazna, a koszt wywolania funkcji
moze byc niekiedy zbyt duzym balastem w stosunku do efektu
(ustawienia bitu).
I jeszcze jedna wada w tym kontekscie. Aby ustawic lub 
skasowac kilka bitow jednoczesnie trzeba kilkukrotnie 
wywolac odpowiednie funkcje.

-- 
Pozdrawiam                                         Adam Karpierz   
mailto:karpierz@intertele.pl
http://www.intertele.pl/users/karpierz 

Marek Kotowski <mkot@imm.org.pl> napisal
> Karpierz wrote (w watku "Rezerwacja pamieci"):
[...]
> > Nie powiem wprost ale zostawie to w formie zagadki 
>> dla wszystkich:
> 
> > Prosze sprawdzic:
> 
> > typedef unsigned int uint;      // taka moja fanaberia
> 
> > int  a =  ~0;      // lub dowolna wartosc ujemna
> > uint b = ~0;      //
> 
> ....
> 
> > printf ("\n%ld  %ld", (long) a, (long) b);
> 
> > Wydaje sie ze powinno to dac identyczne dwie wartosci, 
> > prawda ?
> 
> Nie wydaje sie. :-)

Nie zgodze sie :). Sa dwie rozne wartosci, ale _wydaje_ sie
(przynajmniej mnie), ze powinny byc identyczne.
Osobiscie w/w klopoty czy brak oczywistosci w rzutach
to zrodlo masy bledow i jest to jedna z niewatpliwych wad C.

> > Przeciez rzutujemy _jawnie_ zarowno a jak i b na long.
> 
> Rzecz jest w promocji typu. Inaczej promowany do long
> jest typ int (znak jest powielany), inaczej typ 
> unsigned int (znak nie jest powielany).

Ponawiam prosbe o odpowiedz jak to ujmuje standard ?
Jaka jest ogolna zasada przy tego typu sytuacjach ?

[...]

-- 
Pozdrawiam                                         Adam Karpierz   
mailto:karpierz@intertele.pl
http://www.intertele.pl/users/karpierz 

Karpierz wrote:
> > void SetBit(int Bit);
> > void ClearBit(int Bit);
> > int  IsBitSet(int Bit);
> > void SwitchBit(int Bit);
> > void SetAllBits(void);
> > void ClearAllBits(void);
> 
> Wszystko pieknie, tylko ze zazwyczaj masek bitowych uzywa
> sie tak gdzie efektywnosc jest wazna, a koszt wywolania funkcji
> moze byc niekiedy zbyt duzym balastem w stosunku do efektu
> (ustawienia bitu).

Tu nasze doswiadczenia sie roznia. "Masek bitowych", jak Pan
to ujal, uzywa sie w bardzo roznych sytuacjach (aplikacjach)
i nie musi to miec zadnego zwiazku z efektywnoscia. 

> I jeszcze jedna wada w tym kontekscie. Aby ustawic lub
> skasowac kilka bitow jednoczesnie trzeba kilkukrotnie
> wywolac odpowiednie funkcje.

Istotnie. Ale jak Pan w jednej operacji chce ustawic bity
78-y, 92-i, i 125-y? :-)

  Pozdrawiam

  Marek Kotowski

Karpierz wrote:
> 
> Marek Kotowski <mkot@imm.org.pl> napisal
> > Karpierz wrote (w watku "Rezerwacja pamieci"):
> [...]
> > > Nie powiem wprost ale zostawie to w formie zagadki
> >> dla wszystkich:
> >
> > > Prosze sprawdzic:
> >
> > > typedef unsigned int uint;      // taka moja fanaberia
> >
> > > int  a =  ~0;      // lub dowolna wartosc ujemna
> > > uint b = ~0;      //
> >
> > ....
> >
> > > printf ("\n%ld  %ld", (long) a, (long) b);
> >
> > > Wydaje sie ze powinno to dac identyczne dwie wartosci,
> > > prawda ?
> >
> > Nie wydaje sie. :-)
> 
> Nie zgodze sie :). Sa dwie rozne wartosci, ale _wydaje_ sie
> (przynajmniej mnie), ze powinny byc identyczne.

I są identyczne, w środowiku w którym pracuję sizeof(long) ==
sizeof(int) :)

Oczywiście po zamianie int na char wartości są różne i tak 
powinno być.


> Osobiscie w/w klopoty czy brak oczywistosci w rzutach
> to zrodlo masy bledow i jest to jedna z niewatpliwych wad C.
> 
> > > Przeciez rzutujemy _jawnie_ zarowno a jak i b na long.
> >
> > Rzecz jest w promocji typu. Inaczej promowany do long
> > jest typ int (znak jest powielany), inaczej typ
> > unsigned int (znak nie jest powielany).
> 
> Ponawiam prosbe o odpowiedz jak to ujmuje standard ?
> Jaka jest ogolna zasada przy tego typu sytuacjach ?
> 

Odpowiedź już masz powyżej, ale może badziej szczegółowo :

Założe dla ułatwienia, żę sizeof(int) ==2 i sizeof(long) == 4

int a;
unsigned int b;

1. (long)a - a jest signed, więc bit znaku jest propagowany na
starsze słowo, a a jest kopiowane do młodszego

2. (long)b - b jest kopiowane do młodszego słowa.

3. (unsigned long)a - z moich doświadczeń wynika, że jest 
    równoważne (unsigned long)(long)a.

Sam jestem ciekawy czy jakiś standard to precyzuje (zwłaszcza punt 3.).

Pozdrawiam
Adam

PS.

Przyjąłem konkretne nazwy typów tylko dlatego, że tak mi było 
łatwiej wyjaśnić.
A.

-- 
 Adam Jancewicz 
 mailto: adash@obop.com.pl

Adam Jancewicz <adash@obop.com.pl> napisal
Karpierz wrote:
> 
> Marek Kotowski <mkot@imm.org.pl> napisal
> > Karpierz wrote (w watku "Rezerwacja pamieci"):
 [...]
> > > typedef unsigned int uint;      // taka moja fanaberia
> >
> > > int  a =  ~0;      // lub dowolna wartosc ujemna
> > > uint b = ~0;      //
> >
> > ....
> >
> > > printf ("\n%ld  %ld", (long) a, (long) b);
> >
> > > Wydaje sie ze powinno to dac identyczne dwie wartosci,
> > > prawda ?
> >
> > Nie wydaje sie. :-)
> 
> Nie zgodze sie :). Sa dwie rozne wartosci, ale _wydaje_ sie
> (przynajmniej mnie), ze powinny byc identyczne.

>I są identyczne, w środowiku w którym pracuję sizeof(long) ==
>sizeof(int) :)

Wlasnie, to jeszcze jeden kwiatek do korzucha w C.
Raz sa rowne a raz nie....

[...]

> 1. (long)a - a jest signed, więc bit znaku jest propagowany na
> starsze słowo, a a jest kopiowane do młodszego

>2. (long)b - b jest kopiowane do młodszego słowa.

to jest dla mnie jasne 

>3. (unsigned long)a - z moich doświadczeń wynika, że jest 
>    równoważne (unsigned long)(long)a.

Wlasnie, to jest ten problem o ktorym mowilem.
Wiem ze tak jest. Chociaz trudno sie chyba zgodzic, ze
zapis (unsigned long) to sugeruje, raczej wprost przeciwnie :(. 
Czyli faktycznie o propagacji znaku decyduje nie typ na ktory
rzutujemy ale typ wartosci rzutowanej, ale czy zawsze czy tylko 
w przypadku wartosci long i int:
Czy podobna zasada obowiazuje rowniez dla innych typow 
calkowitych ?
Wydaje sie ze tak ale czy mozna byc na 100% pewnym, i czy
jest to gdzies wyraznie napisane ?.

>Sam jestem ciekawy czy jakiś standard to precyzuje (zwłaszcza punt 3.).

Ja tez. Dokladnie o ten przypadek mi chodzi.
Dla C++ jest to troche dokladniej okreslone (promocja calkowita to sie
nazywa).
Ale dla K&R C jest wyrazna luka i dlatego pytalem poprzednio jak to 
precyzuje standard.
Szczegolnie chodzi mi o przypadek.

(long) a  i (unsigned long) a 

gdzie a jest typu short lub unsigned short i char i unsigned char

/przy zalozeniu ze sizeof(long) > sizeof (int) > sizeof (short)/

-----
Pozdrawiam (rowniez)
Adam (rowniez)

On Thu, 29 Jan 1998 11:56:29 +0100, Marek Kotowski <mkot@imm.org.pl>
wrote:

>Teraz o operacjach na bitach.
>1. Nie pomyslalem o long, bo chyba nigdy nie uzywalem
(...)
>I zazwyczaj tworzylem "tablice bitow". Oto przyklad
>
>#define BITS_NUMBER 100  /* TYLE BITOW MA BYC
>                            OBSLUGIWANYCH */
>
>#define ARRAY_SIZE ((BITS_NUMBER+CHAR_BIT-1)/CHAR_BIT)
>
>unsigned char Bits[ARRAY_SIZE];  /* PELNI ROLE TABLICY
>                                    BITOW */
>
>I np. ustawienie N-tego bitu (makroinstrukcja):
>
>#define SET_BIT(N) (Bits[N/CHAR_BIT] |= (1 << \
>    N%CHAR_BIT))
>
>Pisze to z pamieci (trzeba by sprawdzic).
>
>2. Rozsadne tez jest (chociaz nie zawsze tak robilem)
>odseparowac te tablice od reszty programu. Dostep
>do tablicy realizowany jest przez zestaw funkcji
>manipulacji na bitach:
>
>void SetBit(int Bit);
>void ClearBit(int Bit);
>int  IsBitSet(int Bit);
>void SwitchBit(int Bit);
>void SetAllBits(void);
>void ClearAllBits(void);
>3. Jesli program wymaga kilku tablic bitow ustawianych/
>testowanych osobno, mozna wprowadzic funkcje alokujaca
>tablice bitow:
>
>BIT_ARRAY *AllocBitArray(int NumberOfBits);

 I wlasnie w ten sposob powstaja w pelni przenosne kobyly powolne jak
nagla krew ! Implementacja bitow na tablicy bajtow ! O tempora, o
mores !

milosz danielewski

On Fri, 30 Jan 1998, milosz danielewski wrote:

> >
> >BIT_ARRAY *AllocBitArray(int NumberOfBits);
> 
>  I wlasnie w ten sposob powstaja w pelni przenosne kobyly powolne jak
> nagla krew ! Implementacja bitow na tablicy bajtow ! O tempora, o
> mores !
> 
> milosz danielewski
> 
> 

nie qmam
gdzie Ty tu widzisz narzut ??????

-------------------------------------.
Codematic                            |            
 code@beta.cku.pwr.wroc.pl           |
 mmochol@elka.pw.edu.pl              |
http://home.elka.pw.edu.pl/~mmochol  |
-------------------------------------'

milosz danielewski wrote:
> >I np. ustawienie N-tego bitu (makroinstrukcja):
> >
> >#define SET_BIT(N) (Bits[N/CHAR_BIT] |= (1 << \
> >    N%CHAR_BIT))
> >
> >3. Jesli program wymaga kilku tablic bitow ustawianych/
> >testowanych osobno, mozna wprowadzic funkcje alokujaca
> >tablice bitow:
> >
> >BIT_ARRAY *AllocBitArray(int NumberOfBits);
> 
>  I wlasnie w ten sposob powstaja w pelni przenosne kobyly powolne jak
> nagla krew ! Implementacja bitow na tablicy bajtow ! O tempora, o
> mores !

1. Co do przenosnosci: dotyczyly tego tylko dwie sprawy:
   stala CHAR_BIT (char moze miec wiecej bitow niz 8) oraz
   obudowanie funkcji operujacych na bitach, a takze na
   owych strukturach BIT_ARRAY. Jest to wprawdzie technika
   z dziedziny programowania obiektowego, ale programisci
   kodujacy w C czesto ja stosuja. Tablica bajtow sama w
   sobie nie jest zadna szczegolnie przenosna konstrukcja.

2. Operacja opisana za pomoca makroinstrukcji SET_BIT(N)
   jest bardzo szybka (jedno wyrazenie zmiany elementu tablicy).
   Ale rozumiem, ze to dla Pana zbyt powolne.

3. Bardzo prosze opisac nam, jak Pan by "zaimplementowal bity"
   (Panski termin) inaczej niz za pomoca tablicy zmiennych
   integralnych (mozna tu tez uzyc int)), zeby w dodatku operacje
   na bitach wykonywaly sie znacznie szybciej.

   Mowa oczywiscie o tablicach kilkudziesieciu, kilkuset czy
   nawet kilku tysiecy bitow.


   Pozdrawiam

   Marek Kotowski

Karpierz wrote:
> 
> Adam Jancewicz <adash@obop.com.pl> napisal
> Karpierz wrote:
> >
> > Marek Kotowski <mkot@imm.org.pl> napisal
> > > Karpierz wrote (w watku "Rezerwacja pamieci"):
>  [...]
> > > > typedef unsigned int uint;      // taka moja fanaberia
> > >
> > > > int  a =  ~0;      // lub dowolna wartosc ujemna
> > > > uint b = ~0;      //
> > >
> > > ....
> > >
> > > > printf ("\n%ld  %ld", (long) a, (long) b);
> > >
> > > > Wydaje sie ze powinno to dac identyczne dwie wartosci,
> > > > prawda ?
> > >
> > > Nie wydaje sie. :-)
> >
> > Nie zgodze sie :). Sa dwie rozne wartosci, ale _wydaje_ sie
> > (przynajmniej mnie), ze powinny byc identyczne.
> 
> >I są identyczne, w środowiku w którym pracuję sizeof(long) ==
> >sizeof(int) :)
> 
> Wlasnie, to jeszcze jeden kwiatek do korzucha w C.
> Raz sa rowne a raz nie....
> 
C nie gwarantuje przecierz rozmiaru np. inta.
Problem występuje przy zmianie reprenacji (liczby bitów) 
rzutowanego typu. Przy jednakowym rozmiaże rzutowanie
to tylko rzecz interpretacji ciągu bitów.

BTW Co to jest korzuch (korzucha) ?)

> [...]
> 
> > 1. (long)a - a jest signed, więc bit znaku jest propagowany na
> > starsze słowo, a a jest kopiowane do młodszego
> 
> >2. (long)b - b jest kopiowane do młodszego słowa.
> 
> to jest dla mnie jasne
> 
> >3. (unsigned long)a - z moich doświadczeń wynika, że jest
> >    równoważne (unsigned long)(long)a.
> 
> Wlasnie, to jest ten problem o ktorym mowilem.
> Wiem ze tak jest. Chociaz trudno sie chyba zgodzic, ze
> zapis (unsigned long) to sugeruje, raczej wprost przeciwnie :(.
> Czyli faktycznie o propagacji znaku decyduje nie typ na ktory
> rzutujemy ale typ wartosci rzutowanej, ale czy zawsze czy tylko
> w przypadku wartosci long i int:
> Czy podobna zasada obowiazuje rowniez dla innych typow
> calkowitych ?

Przy innych też, ja to sprawdzałem na (long)char itp. 

> Wydaje sie ze tak ale czy mozna byc na 100% pewnym, i czy
> jest to gdzies wyraznie napisane ?.
> 
> >Sam jestem ciekawy czy jakiś standard to precyzuje (zwłaszcza punt 3.).
> 
> Ja tez. Dokladnie o ten przypadek mi chodzi.
> Dla C++ jest to troche dokladniej okreslone (promocja calkowita to sie
> nazywa).
> Ale dla K&R C jest wyrazna luka i dlatego pytalem poprzednio jak to
> precyzuje standard.

Podejrzewam że nic tego nie precyzuje. 

Konwersja signed char (bajt) na int (2 bajty) była/jest 
realizowana na Intelach poprzez instrukcję CBW (convert byte to word) 
procesora, która działa właśnie tak, że powiela bit znaku na starszy
bajt. 
natomiast w przypadku typu unsigned jest realizowana inaczej. Myśle, że 
na innych architeturach jest podobnie.

Nie wiem jak to jest w przypadku dłuższych typów, ale skutek jest
analogiczny. 

> Szczegolnie chodzi mi o przypadek.
> 
> (long) a  i (unsigned long) a
> 
> gdzie a jest typu short lub unsigned short i char i unsigned char
> 
> /przy zalozeniu ze sizeof(long) > sizeof (int) > sizeof (short)/
> 

Uważam, że zasada jest taka że rzut jest realizowany tylko
ze względu na typ elementu rzutowanego. I potem interpretowany
jako signed lub unsigned. To chyba jedyny sensowny sposób. 


Adam
-- 
 Adam Jancewicz 
 mailto: adash@obop.com.pl

On Fri, 30 Jan 1998, Adam Jancewicz wrote:

> Karpierz wrote:
> > 
> > Wlasnie, to jeszcze jeden kwiatek do korzucha w C.
> > Raz sa rowne a raz nie....
> > 
> C nie gwarantuje przecierz rozmiaru np. inta.
> Problem występuje przy zmianie reprenacji (liczby bitów) 
> rzutowanego typu. Przy jednakowym rozmiaże rzutowanie
> to tylko rzecz interpretacji ciągu bitów.
> 
> BTW Co to jest korzuch (korzucha) ?)

A rozmiaż (rozmiaże)? ;-)))

_______________________________________________________________________________
Michał Kaczmarczyk  mailto:mik@iname.com http://student.uci.agh.edu.pl/~kaczmar

Adam Jancewicz <adash@obop.com.pl> napisal
Karpierz wrote:
[...]
>> Wlasnie, to jeszcze jeden kwiatek do korzucha w C.
>> Raz sa rowne a raz nie....
>> 
>C nie gwarantuje przecierz rozmiaru np. inta.
>Problem występuje przy zmianie reprenacji (liczby bitów) 
>rzutowanego typu. Przy jednakowym rozmiaże rzutowanie
>to tylko rzecz interpretacji ciągu bitów.
>
>BTW Co to jest korzuch (korzucha) ?)

No coz... walnalem byka.. ma byc kozuch :)
Ale, ale...
Co to jest 'zmiana reprenacji' ?
I cos mi sie nie podoba to: 'jednakowym rozmiaze'

Mam propozycje :) Zostawmy Miodkowi co miodkowe ok ? :))

>> Ale dla K&R C jest wyrazna luka i dlatego pytalem poprzednio jak to
>> precyzuje standard.
>
>Podejrzewam że nic tego nie precyzuje. 

Wlasnie dlatego pytam, mysle ze jednak ANSI C to precyzuje.
/przynajmniej powinno../

>Konwersja signed char (bajt) na int (2 bajty) była/jest 
>realizowana na Intelach poprzez instrukcję CBW (convert byte to word) 
>procesora, która działa właśnie tak, że powiela bit znaku na starszy
>bajt. 
>natomiast w przypadku typu unsigned jest realizowana inaczej. 

po prostu XOR AH,AH

/ale tylko dla 16 bitow oczywiscie /.

>Myśle, że na innych architeturach jest podobnie.

Nie chodzi o konkretna architekture, ale o zasade jaka powinna 
obowiazywac na _kazdej_ architekturze.

>Uważam, że zasada jest taka że rzut jest realizowany tylko
>ze względu na typ elementu rzutowanego. I potem interpretowany
>jako signed lub unsigned. To chyba jedyny sensowny sposób. 

Tez wlasnie dokladnie ta zasade stosuje ale jednak luka pozostaje 
luka ... Dalej nie jestesmy pewni na 100%.

A.K.

Adam Jancewicz <adash@obop.com.pl> wrote:
: Karpierz wrote:
: > > > Prosze sprawdzic:
: > > > typedef unsigned int uint;      // taka moja fanaberia
: > > > int  a =  ~0;      // lub dowolna wartosc ujemna
: > > > uint b = ~0;      //
: > > ....
: > > > printf ("\n%ld  %ld", (long) a, (long) b);
: > >
: > > > Wydaje sie ze powinno to dac identyczne dwie wartosci,
: > > > prawda ?
: > >
: > > Nie wydaje sie. :-)
: > 
: > Nie zgodze sie :). Sa dwie rozne wartosci, ale _wydaje_ sie
: > (przynajmniej mnie), ze powinny byc identyczne.

: I są identyczne, w środowiku w którym pracuję sizeof(long) ==
: sizeof(int) :)

I myslisz ze 
if ( (long)a == (long)b ) printf ("rowne");

wypisze cos na ekran, czy nie ? :-)

J.

On Fri, 30 Jan 1998 15:56:01 +0100, Marek Kotowski <mkot@imm.org.pl>
wrote:

>3. Bardzo prosze opisac nam, jak Pan by "zaimplementowal bity"
>   (Panski termin) 

 Prawda, ze udany ?

>   inaczej niz za pomoca tablicy zmiennych
>   integralnych (mozna tu tez uzyc int)), zeby w dodatku operacje
>   na bitach wykonywaly sie znacznie szybciej.
>
>   Mowa oczywiscie o tablicach kilkudziesieciu, kilkuset czy
>   nawet kilku tysiecy bitow.

 Ja bym zaimplementowal na typie "float" bo koprocesor jest szybszy :)

 Mowiac powaznie, zaproponowane przez ciebie rozwiazanie jest
oczywiscie sensowne i poprawne ale dla faktycznie duzej ilosci flag (
choc nie jestem w stanie wymyslec praktycznego zastosowania - z kilku
tysiecy przerzutnikow to juz mozna maly mikroprocesor zbudowac ). Dla
malej ilosci bitow ( <= sizof (unsigned) ), twoje rozwiazanie jest
nadal poprawne ale malo sensowne ( brzytwa Ockhama !), a np. w
systemach sterowania opartych o mikrokontrolery, gdzie flagi bitowe sa
najczesciej wykorzystywane, jest w ogole wykluczone ( narzut czasowy i
pamieciowy ).
Podsumowujac: to co proponujesz jest formalnie OK, jednak w 90%
przypadkow bedzie przerostem formy nad trescia.

milosz danielewski

On 29 Jan 1998, Karpierz wrote:

> >3. (unsigned long)a - z moich doświadczeń wynika, że jest 
> >    równoważne (unsigned long)(long)a.
> 
> Wlasnie, to jest ten problem o ktorym mowilem.
> Wiem ze tak jest. Chociaz trudno sie chyba zgodzic, ze
> zapis (unsigned long) to sugeruje, raczej wprost przeciwnie :(. 
> Czyli faktycznie o propagacji znaku decyduje nie typ na ktory
> rzutujemy ale typ wartosci rzutowanej,
[...]

Nie wiem, jak to jest oficjalnie, ale trudno mi nie uznać tego, co jest,
za logiczne i naturalne. Nie warto zastanawiać się, "czy propagacja bitu
znaku zależy od typu konwertowanego, czy od typu wynikowego"!

Kiedy konwertujemy na unsigned long liczbę nieujemną, to efekt jest
jedyny możliwy, niezależnie od wewnętrznego sposobu przeprowadzania
konwersji, prawda?

Więc można się zająć liczbami ujemnymi. Ich nie da się skonwertować na
unsigned long bez straty. Są dwie możliwości (załóżmy na chwilę, że
sizeof (int) == 2, sizeof (long) == 4). Albo (unsigned long) (int) (-1)
jest równe 0xFFFFFFFF, albo 0xFFFF. Twierdzę, że pierwsza jest o wiele
logiczniejsza.

Otóż konwertujemy -1 na unsigned long. Wszystko jedno, jakiego dokładnie
typu jest to -1. Ważne, że to jest dokładnie -1 i chcemy to zapisać w
unsigned long. "Najbliższą" minus jedynce wartością typu unsigned long
jest 0xFFFFFFFF, więc tak zostanie zapisane, niezależnie od tego, skąd
ta -1 się wzięła.

Innymi słowy, teoretycznie taką konwersję można przeprowadzić w
następujący sposób: konwertujemy daną liczbę na liczbę nieskończonej
prezycji, a potem obcinamy do żądanej liczby bitów. Obie operacje są
proste do zdefiniowania. Pierwsza w przypadku liczby bez znaku uzupełnia
nieskończoną liczbą zer, a w przypadku liczby ze znakiem powiela
nieskończenie wiele razy bit znaku. Druga po prostu obcina. W ten sposób
sprowadziliśmy konwersje w obrębie liczb całkowitych różnej wielkości do
operacji dwóch typów, których definicja jest jedyna możliwa. Proste i
naturalne. Dlaczego miałoby być jakoś inaczej?

-- 
                                 QRCZAK
    __("<              Marcin Kowalczyk
    \__/              qrczak@knm.org.pl
     ^^      http://qrczak.home.ml.org/

milosz danielewski wrote:
> 
> >3. Bardzo prosze opisac nam, jak Pan by "zaimplementowal bity"
> >   (Panski termin)
> 

>  Prawda, ze udany ?

  Srednio.
> 
>  Ja bym zaimplementowal na typie "float" bo koprocesor jest szybszy :)

  To niech Pan tak robi. :-) W koncu Panskie programy, nie moje.

> 
>  Mowiac powaznie, zaproponowane przez ciebie rozwiazanie jest
 oczywiscie sensowne i poprawne ale dla faktycznie duzej ilosci flag (
> choc nie jestem w stanie wymyslec praktycznego zastosowania - z kilku
> tysiecy przerzutnikow to juz mozna maly mikroprocesor zbudowac ).

  Bity czesto funkcjonuja
jako zmienne okreslajace stany innych zmiennych dwustanowych.
Przyklad: system rejestracji czasu pracy przechowuje 
rejestracje pracownikow. W raportach trzeba wiedziec m.in., czy
z danego dnia roku (liczonego od poczatku) sa rejestracje, czy nie.
Najlepiej te informacje zalatwic za pomoca tablicy 366 bitow. 

> malej ilosci bitow ( <= sizof (unsigned) ), twoje rozwiazanie jest
> nadal poprawne ale malo sensowne ( brzytwa Ockhama !), a np. w
> systemach sterowania opartych o mikrokontrolery, gdzie flagi bitowe sa
> najczesciej wykorzystywane, jest w ogole wykluczone ( narzut czasowy i
> pamieciowy ).
> Podsumowujac: to co proponujesz jest formalnie OK, jednak w 90%
> przypadkow bedzie przerostem formy nad trescia.

  Niech Pan wreszcie zacznie dyskutowac, a nie a to pokrzykiwac,
a to odwracac kota ogonem. Przeciez wyraznie powiedzialem, ze
chodzi o duze liczby bitow. 
 
  I jeszcze jedno. Napisal Pan dla
"malej ilosci bitow ( <= sizof (unsigned) ),"

  sizeof (unsigned int) jest rowne 2 dla liczb 16 bitowych,
a 4 dla - 32 bitowych. sizeof(unsigned) nie rowna sie
bynajmniej liczbie bitow w zmiennej unsigned int.
Moze Pan sprawdzic. :-) 

  Pozdrawiam

  Marek Kotowski

Marek Kotowski wrote:
>   Bity czesto funkcjonuja
> jako zmienne okreslajace stany innych zmiennych dwustanowych.
                                                  ^^^^^^^^^^^^
  Autopoprawka: oczywiscie slowa "dwustanowych" tu byc nie powinno. 

  Marek Kotowski

Qrczak <qrczak@knm.org.pl> napisal
> On 29 Jan 1998, Karpierz wrote:
[...]
> Więc można się zająć liczbami ujemnymi. Ich nie da się skonwertować na
> unsigned long bez straty. Są dwie możliwości (załóżmy na chwilę, że
> sizeof (int) == 2, sizeof (long) == 4). Albo (unsigned long) (int) (-1)
> jest równe 0xFFFFFFFF, albo 0xFFFF. Twierdzę, że pierwsza jest o wiele
> logiczniejsza.
> 
> Otóż konwertujemy -1 na unsigned long. Wszystko jedno, jakiego dokładnie
> typu jest to -1. Ważne, że to jest dokładnie -1 i chcemy to zapisać w
> unsigned long. "Najbliższą" minus jedynce wartością typu unsigned long
> jest 0xFFFFFFFF, więc tak zostanie zapisane, niezależnie od tego, skąd
> ta -1 się wzięła.

Otoz wlasnie nie jest wszystko jedno jakiego typu jest -1;
Musisz pamietac o tym ze -1 to nie to samo co -1U. 

Wiec np:

int               a = -1;
unsigned int b = -1;

(unsigned long) a   jest rowne 0xFFFFFFFF  
(unsigned long) b   jest rowne 0x0000FFFF

czyli wlasnie wg zasady ktara napisalem wczesniej:

"Czyli faktycznie o propagacji znaku decyduje nie typ na ktory
rzutujemy ale typ wartosci rzutowanej"

Wniosek z calej tej dyskusji przynajmniej dla mnie jest jeden.
Nie wszystko jest takie oczywiste jak sie na pierwszy rzut oka 
wydaje i do konca madrych tu nie ma jesli cos w raporcie 
jezyka /nie wiem jak w ANSI, ja mowie o K&R/
nie jest do konca scisle okreslone.
Nie chodzi mi tu o ([unsigned] int) -> ([unsigned] long), to akurat jest,
ale glownie o ([unsigned] short) -> ([unsigned] long) i o 
i o ([unsigned] char) -> ([unsigned] long). 

Przy nauce C i w praktyce wiele mi to zawsze sprawialo
klopotow i wiele ukrytych bledow tez temu zawdzieczam
i dlatego poruszylem ten temat.
Inn sprawa ze napewno nie wart jest on tak rozbudowanej
dyskusji, ale.. jakos tak wyszlo ..:))
Moze damy pokoj juz tym rzutom ? :)
Jest tyle ciekawszych tematow... 

-- 
Pozdrawiam                                         Adam Karpierz   
mailto:karpierz@intertele.pl
http://www.intertele.pl/users/karpierz 

On 31 Jan 1998, Karpierz wrote:

> Otoz wlasnie nie jest wszystko jedno jakiego typu jest -1;
> Musisz pamietac o tym ze -1 to nie to samo co -1U. 

Przecież -1u to wcale nie jest -1 (jak liczba bez znaku może być
ujemna?), tylko 0xFFFF (zakładając dwubajtowy int). Za to w każdym
typie, w którym -1 istnieje, tzn. signed char, short, int, long, nie ma
znaczenia, którym konkretnie typem to jest.

> czyli wlasnie wg zasady ktara napisalem wczesniej:
> 
> "Czyli faktycznie o propagacji znaku decyduje nie typ na ktory
> rzutujemy ale typ wartosci rzutowanej"

Nie podoba mi się to sformułowanie, bo sugeruje, że mogłoby być
odwrotnie. A odwrotnie byłoby mniej sensu, bo ważna byłaby kolejność
pośrednich konwersji nawet wtedy, kiedy każda zachowuje konwertowaną
wartość bez strat. Teraz możeby przejść dowolną ścieżką i zawsze
dostaniemy ten sam wynik, o ile po drodze nie było przycinania wartości
spoza zakresu do węższego typu.

> Wniosek z calej tej dyskusji przynajmniej dla mnie jest jeden.
> Nie wszystko jest takie oczywiste jak sie na pierwszy rzut oka 
> wydaje i do konca madrych tu nie ma jesli cos w raporcie 
> jezyka /nie wiem jak w ANSI, ja mowie o K&R/
> nie jest do konca scisle okreslone.

Stanowczo się nie zgodzę. Dla mnie wszystko jest jasne i jest zrobione w
jedyny sensowny sposób. Oczywiście spośród rzeczy dyskutowanych, bo np.
nie jest już oczywiste, jakiego typu powinno być (int) + (unsigned).
Zdaje się, że standard żąda w takim przypadku unsigned.

> Nie chodzi mi tu o ([unsigned] int) -> ([unsigned] long), to akurat jest,
> ale glownie o ([unsigned] short) -> ([unsigned] long) i o 
> i o ([unsigned] char) -> ([unsigned] long).

Nie widzę tam żadnych niejednoznaczności!

> Przy nauce C i w praktyce wiele mi to zawsze sprawialo klopotow i
> wiele ukrytych bledow tez temu zawdzieczam i dlatego poruszylem ten
> temat.

A, różnie bywa. Ja na przykład nie mogę się przekonać do sensowności
programowania obiektowego :-)

> Inn sprawa ze napewno nie wart jest on tak rozbudowanej
> dyskusji, ale.. jakos tak wyszlo ..:))
> Moze damy pokoj juz tym rzutom ? :)

Dobra. Po prostu reaguję na zdania, z którymi się wybitnie nie zgadzam.

> Jest tyle ciekawszych tematow... 

Jakie na przykład?

-- 
                                 QRCZAK
    __("<              Marcin Kowalczyk
    \__/              qrczak@knm.org.pl
     ^^      http://qrczak.home.ml.org/

On Sat, 31 Jan 1998 11:28:11 +0100, Marek Kotowski <mkot@imm.org.pl>
wrote:
>> Podsumowujac: to co proponujesz jest formalnie OK, jednak w 90%
>> przypadkow bedzie przerostem formy nad trescia.
>
>  Niech Pan wreszcie zacznie dyskutowac, a nie a to pokrzykiwac,
>a to odwracac kota ogonem. Przeciez wyraznie powiedzialem, ze
>chodzi o duze liczby bitow. 

 Faktycznie, napisales ze chodzi o wieksza ilosc bitow ( konkretnie
wieksza od 16 ). Moje przeoczenie. Wycofuje sie z wczesniejszych
zarzutow. Co prawda nadal mnie dziwi po co ci funkcja
ustawiajaca/kasujaca bit (dwukrotna strata czasu i pamieci), skoro
wczesniej napisales juz #define do tego celu, ale jest to kwestia
mniej istotna.

> 
>  I jeszcze jedno. Napisal Pan dla
>"malej ilosci bitow ( <= sizof (unsigned) ),"
>
>  sizeof (unsigned int) jest rowne 2 dla liczb 16 bitowych,
>a 4 dla - 32 bitowych. sizeof(unsigned) nie rowna sie
>bynajmniej liczbie bitow w zmiennej unsigned int.

 Niektorzy mniej kulturalni ludzie powiedzieliby, ze jestes
"upierdliwy", ja ogranicze sie do stwierdzenia ze jestes malostkowy.
No bo chyba sens mojej wypowiedzi zrozumiales ( podobnie jak
"implementacji bitow" ) ?

milosz danielewski

Dnia 29 Jan 1998 18:35:29 GMT "Karpierz" <karpierz@inter.intertele.pl> napisal tak:

>Czyli faktycznie o propagacji znaku decyduje nie typ na ktory
>rzutujemy ale typ wartosci rzutowanej, ale czy zawsze czy tylko 
>w przypadku wartosci long i int:
>Czy podobna zasada obowiazuje rowniez dla innych typow 
>calkowitych ?
>Wydaje sie ze tak ale czy mozna byc na 100% pewnym, i czy
>jest to gdzies wyraznie napisane ?.

>>Sam jestem ciekawy czy jakiś standard to precyzuje (zwłaszcza punt 3.).

Precyzuje to standard ANSI ;-). Jego sens jest taki:

1. Promocje calkowite.

   char, short, pole bitowe i wyliczenie przeksztalca sie na
   int - o ile sie zmiesci, jak nie zmiesci, to na unsigned int

2. Przeksztlacenia calkowite.

2.1 Do typu bez znaku (do unsigned cos tam)

   Bardzo proste ;-) : Wartosc calkowita zamieniana jest na najmniejsza
   nieujemna wartosc, ktora jest przystajaca do tej wartosci modulo
   najwieksza wartosc reprezentowana w danym typie zwiekszona o 1.

   W uzupelnieniach do 2 sprowadza sie to do:
   
   Jesli typ docelowy krotszy: obciecie bitow z lewej strony
   Jesli typ docelowy dluzszy: uzupelniamy zerami lub jedynkami zaleznie
                               od znaku liczby przeksztalcanej

2.2. Do typu ze znakiem (do [signed] cos tam)

   Jesli wartosc liczby nalezy do zakresu typu docelowego, to sie nie
   zmienia. Logiczne.

   Jesli wartosc liczby nie miesci sie w zakresie typu docelowego, to
   zalezy. A od czego zalezy? Ano - od implementacji.

Zycze wielu owocnych rzutowan!

VANITAS VANITATUM ET OMNIA VANITAS

Mechanik

Dnia Sat, 31 Jan 1998 19:38:58 +0100 Qrczak <qrczak@knm.org.pl> napisal tak:

>A, różnie bywa. Ja na przykład nie mogę się przekonać do sensowności
>programowania obiektowego :-)

A jakie masz - ze sie tak wyraze - obiekcje?

VANITAS VANITATUM ET OMNIA VANITAS

Mechanik

Jaroslaw Lis wrote:
> 
> Adam Jancewicz <adash@obop.com.pl> wrote:
> : Karpierz wrote:
> : > > > Prosze sprawdzic:
> : > > > typedef unsigned int uint;      // taka moja fanaberia
> : > > > int  a =  ~0;      // lub dowolna wartosc ujemna
> : > > > uint b = ~0;      //
> : > > ....
> : > > > printf ("\n%ld  %ld", (long) a, (long) b);
> : > >
> : > > > Wydaje sie ze powinno to dac identyczne dwie wartosci,
> : > > > prawda ?
> : > >
> : > > Nie wydaje sie. :-)
> : >
> : > Nie zgodze sie :). Sa dwie rozne wartosci, ale _wydaje_ sie
> : > (przynajmniej mnie), ze powinny byc identyczne.
> 
> : I są identyczne, w środowiku w którym pracuję sizeof(long) ==
> : sizeof(int) :)
> 
> I myslisz ze
> if ( (long)a == (long)b ) printf ("rowne");
> 
> wypisze cos na ekran, czy nie ? :-)

Wypisze (wypisuje), dlaczego uważasz że powinno być inaczej?

Adam
-- 
 Adam Jancewicz 
 mailto: adash@obop.com.pl

milosz danielewski wrote:
> >  I jeszcze jedno. Napisal Pan dla
> >"malej ilosci bitow ( <= sizof (unsigned) ),"
> >
> >  sizeof (unsigned int) jest rowne 2 dla liczb 16 bitowych,
> >a 4 dla - 32 bitowych. sizeof(unsigned) nie rowna sie
> >bynajmniej liczbie bitow w zmiennej unsigned int.
> 
>  Niektorzy mniej kulturalni ludzie powiedzieliby, ze jestes
> "upierdliwy", ja ogranicze sie do stwierdzenia ze jestes malostkowy.
> No bo chyba sens mojej wypowiedzi zrozumiales ( podobnie jak
> "implementacji bitow" ) ?

  "Implementacja bitow" to termin, gorszy czy lepszy - niewazne.
Natomiast fragment o "malej ilosci bitow" dowodzi, ze Pan nie
rozumie jak dziala operator sizeof. Jesli dla Pana zwracanie
uwagi na taki "szczegol" to malostkowosc - to jestem malostkowy,
tak samo jak "malostkowy" jest czy powinien byc kazdy programista. 
Moge sobie tylko wyobrazic, jakie sa Panskie programy, skoro
dzialanie sizeof to dla Pana - jak widac - problem nieistotny.

  A w ogole, czytajac Panska wypowiedz, i przypominajac sobie
inne podobne, Panskie i innych, pomyslalem sobie: Po co w ogole
dystkutowac? Po co sie narazac na kolejne uwagi takie jak
powyzsza? Po co kogos uczyc, skoro najwyrazniej nie chce?
Ma Pan swoje "wiedze", ktorej dal Pan dobitny wyraz takze w kilku
innych wypowiedziach, jest Pan jej pewien, ma Pan "jasnosc",
co jest wazne, a co nie. Niech Pan programuje jak Pan chce.
W koncu panskie programy, nie moje. 

  Marek Kotowski

On Mon, 02 Feb 1998 10:57:55 +0100, Marek Kotowski <mkot@imm.org.pl>
wrote:

>milosz danielewski wrote:
>> >  I jeszcze jedno. Napisal Pan dla
>> >"malej ilosci bitow ( <= sizof (unsigned) ),"
>> >
>> >  sizeof (unsigned int) jest rowne 2 dla liczb 16 bitowych,
>> >a 4 dla - 32 bitowych. sizeof(unsigned) nie rowna sie
>> >bynajmniej liczbie bitow w zmiennej unsigned int.
>> 
>>  Niektorzy mniej kulturalni ludzie powiedzieliby, ze jestes
>> "upierdliwy", ja ogranicze sie do stwierdzenia ze jestes malostkowy.
>> No bo chyba sens mojej wypowiedzi zrozumiales ( podobnie jak
>> "implementacji bitow" ) ?
>
>  "Implementacja bitow" to termin, gorszy czy lepszy - niewazne.
>Natomiast fragment o "malej ilosci bitow" dowodzi, ze Pan nie
>rozumie jak dziala operator sizeof.

 Ciesze sie, ze Ty za to rozumiesz swietnie. Nie dodales tylko, ze
jeszcze zapomnialem o sredniku na koncu linii. Bezwzglednie powinienes
zwrocic uwage na ten niezmiernie istotny dla sensu wypowiedzi szczegol
! 

> Jesli dla Pana zwracanie
>uwagi na taki "szczegol" to malostkowosc - to jestem malostkowy,
>tak samo jak "malostkowy" jest czy powinien byc kazdy programista. 

 Nie pisalem programu tylko list. Chcesz zebym posylal odpowiedzi w
assemblerze ?

>Ma Pan swoje "wiedze", ktorej dal Pan dobitny wyraz takze w kilku
>innych wypowiedziach, jest Pan jej pewien, ma Pan "jasnosc",
>co jest wazne, a co nie. 

 W odroznieniu od niektorych, oprocz "wiedzy" mam jeszcze wiedze.

>Niech Pan programuje jak Pan chce.

 Dziekuje za laskawe pozwolenie.

>W koncu panskie programy, nie moje. 

 No i cale szcescie...

milosz danielewski

milosz danielewski wrote:
> 
> >W koncu panskie programy, nie moje.
> 
>  No i cale szcescie...

  I tu jestesmy calkowicie zgodni. :-)
  Zawsze uwazalem, ze z kazdym da sie osiagnac
consensus. :-) Na tym, jak rozumiem, dyskusje 
zamykamy.

  Pozdrawiam

  Marek Kotowski

On Fri, 30 Jan 1998, Michal Kaczmarczyk wrote:

> On Fri, 30 Jan 1998, Adam Jancewicz wrote:
> 
> > Karpierz wrote:
> > > 
> > > Wlasnie, to jeszcze jeden kwiatek do korzucha w C.
> > > Raz sa rowne a raz nie....
> > > 
> > C nie gwarantuje przecierz rozmiaru np. inta.
> > Problem występuje przy zmianie reprenacji (liczby bitów) 
> > rzutowanego typu. Przy jednakowym rozmiaże rzutowanie
> > to tylko rzecz interpretacji ciągu bitów.
> > 
> > BTW Co to jest korzuch (korzucha) ?)
> 
> A rozmiaż (rozmiaże)? ;-)))

A przecierz i reprenacja ? ;-)

-------------------------------------.
Codematic                            |            
 code@beta.cku.pwr.wroc.pl           |
 mmochol@elka.pw.edu.pl              |
http://home.elka.pw.edu.pl/~mmochol  |
-------------------------------------'

Karpierz wrote:
> 
> Adam Jancewicz <adash@obop.com.pl> napisal
> Karpierz wrote:
> [...]
> >> Wlasnie, to jeszcze jeden kwiatek do korzucha w C.
> >> Raz sa rowne a raz nie....
> >>
> >C nie gwarantuje przecierz rozmiaru np. inta.
> >Problem występuje przy zmianie reprenacji (liczby bitów)
> >rzutowanego typu. Przy jednakowym rozmiaże rzutowanie
> >to tylko rzecz interpretacji ciągu bitów.
> >
> >BTW Co to jest korzuch (korzucha) ?)
> 
> No coz... walnalem byka.. ma byc kozuch :)
> Ale, ale...
> Co to jest 'zmiana reprenacji' ?
> I cos mi sie nie podoba to: 'jednakowym rozmiaze'

Punkt (nawet dwa) dla Ciebie, nie cgciałem się czepiać,
pierwszy rqaz spotkałem się z takim określeniem i nie wiedziałem
czy to miał być kożuch czy też coś innego.

> 
> Mam propozycje :) Zostawmy Miodkowi co miodkowe ok ? :))
> 
ok

> >> Ale dla K&R C jest wyrazna luka i dlatego pytalem poprzednio jak to
> >> precyzuje standard.
> >
> >Podejrzewam że nic tego nie precyzuje.
> 
> Wlasnie dlatego pytam, mysle ze jednak ANSI C to precyzuje.
> /przynajmniej powinno../
> 
> >Konwersja signed char (bajt) na int (2 bajty) była/jest
> >realizowana na Intelach poprzez instrukcję CBW (convert byte to word)
> >procesora, która działa właśnie tak, że powiela bit znaku na starszy
> >bajt.
> >natomiast w przypadku typu unsigned jest realizowana inaczej.
> 
> po prostu XOR AH,AH
> 
> /ale tylko dla 16 bitow oczywiscie /.
> 
> >Myśle, że na innych architeturach jest podobnie.
> 
> Nie chodzi o konkretna architekture, ale o zasade jaka powinna
> obowiazywac na _kazdej_ architekturze.
> 
> >Uważam, że zasada jest taka że rzut jest realizowany tylko
> >ze względu na typ elementu rzutowanego. I potem interpretowany
> >jako signed lub unsigned. To chyba jedyny sensowny sposób.
> 
> Tez wlasnie dokladnie ta zasade stosuje ale jednak luka pozostaje
> luka ... Dalej nie jestesmy pewni na 100%.
> 
> A.K.

Już nie będę się rowodził, w każdym razie doszedłem
do wniosków zgodnych z tym co napisał Qrczak.


Pozdrawiam,
Adam
-- 
 Adam Jancewicz 
 mailto: adash@obop.com.pl