Dlaczego zwracana wartość funkcji unsigned char zajmuje dwa bajty w GCC?
gcc, unsigned char itd.
From: "T.M.F." <tfrancuz_at_nospam_nospam.mp.pl>
Subject: gcc, unsigned char itd.
Date: Sat, 06 May 2006 21:49:24 +0200
Witam!
Definiuje sobie funkcje:
unsigned char funkcja();
Z tego co mi wiadomo uchar miesci sie w jednym bajcie, logiczne jest
wiec, ze wartosc zwracana przez funkcje zwracana jest w jakims
rejestrze. Kompiluje sobie program, patrze w disassemblerze jak to
wyglada i o dziwo wartosc funkcji zwracana jest w dwoch bajtach!
Dlaczego tak jest?
Pozdrawiam,
T.M.F.
--
Inteligentny dom - http://idom.wizzard.one.pl
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz sie do projektu.
Date: Sun, 07 May 2006 21:36:45 +0200
From: =?ISO-8859-2?Q?Adam_G=F3rski?=
Subject: Re: gcc, unsigned char itd.
Użytkownik T.M.F. napisał:
Witam!
Definiuje sobie funkcje:
unsigned char funkcja();
Z tego co mi wiadomo uchar miesci sie w jednym bajcie, logiczne jest
wiec, ze wartosc zwracana przez funkcje zwracana jest w jakims
rejestrze. Kompiluje sobie program, patrze w disassemblerze jak to
wyglada i o dziwo wartosc funkcji zwracana jest w dwoch bajtach!
Dlaczego tak jest?
Pozdrawiam,
T.M.F.
Witam,
A na jakiej platformie ?
Adam
From: Zbych <abuse_at_nospam_onet.pl>
Subject: Re: gcc, unsigned char itd.
Date: Sun, 07 May 2006 21:52:47 +0200
T.M.F. przemówił ludzkim głosem:
Definiuje sobie funkcje:
unsigned char funkcja();
Kompiluje sobie program, patrze w disassemblerze jak to
wyglada i o dziwo wartosc funkcji zwracana jest w dwoch bajtach!
Dlaczego tak jest?
Gcc po prostu tak ma i już, jeśli bardzo ci to przeszkadza i nie
potrzebujesz w programie zmiennych całkowitych dłuższych niż 16-bitów to
dodaj opcję -mint8 przy kompilacji źródeł.
From: "T.M.F." <tfrancuz_at_nospam_nospam.mp.pl>
Subject: Re: gcc, unsigned char itd.
Date: Sun, 07 May 2006 22:53:28 +0200
Kompiluje sobie program, patrze w disassemblerze jak to wyglada i o
dziwo wartosc funkcji zwracana jest w dwoch bajtach!
Dlaczego tak jest?
Gcc po prostu tak ma i już, jeśli bardzo ci to przeszkadza i nie
potrzebujesz w programie zmiennych całkowitych dłuższych niż 16-bitów to
dodaj opcję -mint8 przy kompilacji źródeł.
Troche przeszkadza, bo wydluza kod. Kompiluje sobie na ATMega8 i pamieci
nie mam za wiele, a mam pare funkcji zwracajacych wartosc typu bool
(zdefiniowana jako uchar, bo nie moge jakos znalezc pliku naglowkowego
definiujacego bool, true i false).
Dzieki za wskazowke z tym -mint8, sprawdze i potestuje. Jak wtedy
zachowuja sie typy long itd. ?
--
Inteligentny dom - http://idom.wizzard.one.pl
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz sie do projektu.
From: Zbych <abuse_at_nospam_onet.pl>
Subject: Re: gcc, unsigned char itd.
Date: Sun, 07 May 2006 23:03:42 +0200
T.M.F. przemówił ludzkim głosem:
Dzieki za wskazowke z tym -mint8, sprawdze i potestuje. Jak wtedy
zachowuja sie typy long itd. ?
int - 8-bitów, long 16-bitów. Lepiej jednak używać definicji
(u)int8/16_t wtedy długości zmiennych nie zmieniają się (oczywiście
(u)int32_t przestaje być rozpoznawane).
From: arkadiusz.antoniak_at_nospam_wp.pl
Subject: Re: gcc, unsigned char itd.
Date: 7 May 2006 13:14:34 -0700
T.M.F. wrote:
Z tego co mi wiadomo uchar miesci sie w jednym bajcie, logiczne jest
Nie jest to prawda, bywa roznie.
From: "T.M.F." <tfrancuz_at_nospam_nospam.mp.pl>
Subject: Re: gcc, unsigned char itd.
Date: Sun, 07 May 2006 22:51:22 +0200
Z tego co mi wiadomo uchar miesci sie w jednym bajcie, logiczne jest
Nie jest to prawda, bywa roznie.
Hmm, moze. Mozesz podac przyklad platformy na ktorej uchar ma wiecej niz
8 bitow?
--
Inteligentny dom - http://idom.wizzard.one.pl
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz sie do projektu.
From: Adam Dybkowski <adybkows123_at_nospam_amwaw.edu.pl>
Subject: Re: gcc, unsigned char itd.
Date: Sun, 07 May 2006 23:15:03 +0200
T.M.F. napisaĹ(a):
Z tego co mi wiadomo uchar miesci sie w jednym bajcie, logiczne jest
Nie jest to prawda, bywa roznie.
Hmm, moze. Mozesz podac przyklad platformy na ktorej uchar ma wiecej niz
8 bitow?
SzczegĂłlnÄ
grupÄ
procesorĂłw sÄ
DSP, w ktĂłrych wszystko nie robi siÄ tak
aby byĹo wygodnie pisaÄ programy (patrz np. ARM), ale w celu
maksymalizacji wydajnoĹci. Na przykĹad w texasowych procesorach
TMS320VC54xx magistrala pamiÄci jest 16-bitowa. Prawie wszystkie
rejestry sÄ
16-bitowe (poza dwoma akumulatorami). PamiÄÄ SRAM w Ĺrodku
procesora jest 16-bitowa. I na zewnÄ
trz teĹź musi byÄ. Procesor nie ma
fizycznej moĹźliwoĹci zaadresowania oktetu. W tych DSPkach bajt po prostu
ma 16 bitĂłw (nie myliÄ z oktetem, ktĂłry jest zawsze 8-bitowy). Tablica 8
wartoĹci [unsigned] char zajmuje 8 sĹĂłw 16b. Nie muszÄ chyba tĹumaczyÄ,
jak upierdliwe jest przenoszenie kodu w jÄzyku C z normalnego procesora
(np. AVR czy ARM) na DSP. Z drugiej strony, jeĹźeli od razu siÄ pisze na
texasa to moĹźna siÄ przyzwyczaiÄ.
--
Adam Dybkowski
http://www.amwaw.edu.pl/~adybkows/
Uwaga: przed wysĹaniem do mnie maila usuĹ "123" z adresu.
From: "Piotr Wyderski" <wyderskiREMOVE_at_nospam_ii.uni.wroc.pl>
Subject: Re: gcc, unsigned char itd.
Date: Mon, 8 May 2006 19:46:20 +0200
T.M.F. wrote:
Hmm, moze. Mozesz podac przyklad platformy na ktorej uchar ma wiecej niz
8 bitow?
Co z tego, ze taka obecnie nie istnieje, skoro standard C nie mówi, ile
bitów ma char? Ma miec tylko sizeof() = 1 (umowne 1, niekoniecznie bajt)
i byc dostatecznie duzy do pomieszczenia znaczków.
Pozdrawiam
Piotr Wyderski
From: Adam Dybkowski <adybkows123_at_nospam_amwaw.edu.pl>
Subject: Re: gcc, unsigned char itd.
Date: Mon, 08 May 2006 22:51:43 +0200
Piotr Wyderski napisał(a):
Hmm, moze. Mozesz podac przyklad platformy na ktorej uchar ma wiecej niz
8 bitow?
Co z tego, ze taka obecnie nie istnieje, skoro standard C nie mówi, ile
bitów ma char? Ma miec tylko sizeof() = 1 (umowne 1, niekoniecznie bajt)
i byc dostatecznie duzy do pomieszczenia znaczków.
Istnieje, patrz np. kompilatory C dla DSP'ków. Na texasach minimalną
adresowaną jednostką jest słowo 16b i bajt zajmuje tam 16 bitów. Tyle
samo co słowo typu [unsigned] int. Kompilator jednak dba o to, aby
wartość zmiennej typu unsigned char mieściła się w zwyczajowo przyjętym
zakresie (0-255) i przed każdym zapisem do pamięci robi operację "AND"
ze stałą 0xff. W przypadku typu ze znakiem (char) dodatkowo rozszerza
bit znaku. Dlatego też operacje na wartościach typu [unsigned] char dają
znacznie dłuższy kod wynikowy niż gdyby odbywały się na [unsigned] int.
BTW: Całkiem ciekawe jest przeprowadzanie operacji na wartościach
32-bitowych. Dwa akumulatory istniejące w TMS320VC5416 mają po 32 bity
każdy, ale asembler pozwala w gruncie rzeczy na niewiele natywnych
operacji na takich porcjach danych. Dane leżące w pamięci muszą być
wyrównane do adresu parzystego (adresowanie dotyczy zawsze słów
16-bitowych) co wydaje się oczywiste. Ale DSP pobierając wartość 32b
spod adresu nieparzystego nie wykrzaczy się (nie ma wyjątków itp) tylko
zamieni połówki słowa pobieranego. :-) Na szczęście kompilator C zwykle
na to zwraca uwagę alokując odpowiednio zmienne w RAMie i na stosie.
Trzeba tylko uważać z rzutowaniem.
--
Adam Dybkowski
http://www.amwaw.edu.pl/~adybkows/
Uwaga: przed wysłaniem do mnie maila usuń "123" z adresu.