połączenie dwóch zmiennych typy byte na jedną typu int w C

Jurek Szczesiul · Postautor: **Jurek Szczesiul** » 25 paź 2005, o 17:33

cała ta dyskusja o optymalizację i pisanie tego tak czy tak jest bez sensu.

To jakoś samo wyszło

Było pytanie, padło kilka propozycji i jak zwykle poszło o to, która lepsza

BTW z bezsensem podglądania kompilatora zgodzę się tylko częściowo. Jak ma sie do
dyspozycji bezpłatne narzędzie z różnymi słabszymi punktami - to chyba warto je
rozpoznać i potem starać się unikać. Poza tym różne takie małe wprawki pozwalają na
łatwiejsze powiązanie C z asm co w małych kostkach przydaje się bez porównania
bardziej niż w PC ( mówię oczywiście tylko z punktu widzenia własnych mizernych
umiejętności programowania ).
Oczywiście żadnego przekonywania na siłę, natomiast im więcej różnych zdań
na forum tym IMHO lepiej.

Pozdrowienia - mam nadzieję, że nie przynudzam

Jurek S.

[ Dodano: 25-10-2005, 19:16 ]

...I drugiego dnia stworzyła bogini przesunięcia bitowe. I widziała bogini, że są dobre....

A trzeciego chciała tak samo zrobić unsigned long z 4 bajtów i zaznała kilku
niespodzianek

NMSP - ale to żadne przytyki!! Tylko przypomnienie dla pierwszego pytającego, że C ma
swoje ficzery

Pozdrowienia Jurek S.

Sławek5 · Postautor: **Sławek5** » 26 paź 2005, o 05:36

Poczytałem sobie troszkę o tych rzutowaniach i typie volatile.
Jeśli chodzi o tą deklarację:
#define LCDPORT (*(volatile unsigned char *)0x38) // PORT

to szczerze powiem, ze nie wiem czemu ma to służyć, gdyż dowiedziałem się też, że kompilator nie optymalizuje na dostępie do portów i traktuje dostęp do nich jak właśnie była by to zmienna z deklaracją volatile.
Chyba że jest inny powód którego nie dostrzegam ???

bis · Postautor: **bis** » 26 paź 2005, o 07:47

Sławek5. Sa kompilatory i kompilatory. W jednych jest zaszyta wiedza o konkretnych procesorach, wraz z dokładną mapą ich zasobów i robią wszystko(?) "same" a inne są trochę mniej "inteligentne" i trzeba im pomagać. Taki zapis pozwala na dużo większą przenośność kodu pomiędzy róznymi kompilatorami (może kiedyś użyjesz innego). Tu konkretnie widać że procesor posiada zunifikowaną przestrzeń adresową w której, w róznych obszarach adresowych umieszczone są różne zasoby. Pamięci ulotne i nieulotne, porty sterujące i statusowe zintegrowanych z procesorem peryferiali. Nie każdy kompilator "wie" które adresy są portami a które pamięcią. Ddostęp do do tych każdego z zasobów może byc zrealizowany tymi samymi instrukcjami maszynowymi. Taki zapis pozwala "czysto" zdefiniować jak kompilator ma traktować konkretne odwołania niezależnie ok aktualnych opcji i możliwości optymalizacji. W innych architekturach (np. Z80, 8051 ) przestrzeń portów może być oddzielną jednostką o odmiennym adresowniu (inne rozkazy maszynowe operują na portach a inne na poszczególnych typach pamięci) Dla takich architektur kompilatory stosują dodatkowe modyfikatory w deklaracji typu (ale są to "rozszerzenia" względem standardu języka "C").

tomek_j · Postautor: **tomek_j** » 26 paź 2005, o 07:56

cała ta dyskusja o optymalizację i pisanie tego tak czy tak jest bez sensu.
..... z bezsensem podglądania kompilatora zgodzę się tylko częściowo. Jak ma sie do
dyspozycji bezpłatne narzędzie z różnymi słabszymi punktami - to chyba warto je
rozpoznać i potem starać się unikać. Poza tym różne takie małe wprawki pozwalają na
łatwiejsze powiązanie C z asm co w małych kostkach przydaje się bez porównania
bardziej niż w PC ( mówię oczywiście tylko z punktu widzenia własnych mizernych
umiejętności programowania )......
Pozdrowienia Jurek S.

Racja to jest oczywiście jak trzymasz sie jednej rodziny procesora i znasz dobrze liste rozkazów, pisałeś, lub piszesz trochę (sporo) w asemblerze...... A co jeżeli bierzesz inną zupełnie nie znaną rodzinę, a potem następną, to nie masz czasu i ochoty uczyć sie nawet listy rozkazów ( to herezja dla niektórych). Potrzeba ci tylko znajomości niezbednych peryferii, ukladu przerwań itp. Po pewnym czasie zapominasz co to jest asembler, tak jak uzytkownicy PC-ta raczej go nie znają. Kiedyś wstawki asemblerowe uznawałem z cos koniecznego, ale teraz ich nie uzywam, bo w paru przypadkach programuje procesory których lista rozkazów nie jest mi znana.
To dlatego pozwoliłem sobie postawić teze, ze analizowanie kodu wynikowego kompilatora ma niewielki sens praktyczny, ale może mieć dydaktyczny. Oczywiście postrzeganie tego problemu może byc zupełnie inne

Jurek Szczesiul · Postautor: **Jurek Szczesiul** » 26 paź 2005, o 08:13

Poczytałem sobie troszkę o tych rzutowaniach i typie volatile.
Jeśli chodzi o tą deklarację:
#define LCDPORT (*(volatile unsigned char *)0x38) // PORT

to szczerze powiem, ze nie wiem czemu ma to służyć, gdyż dowiedziałem się też, że kompilator nie optymalizuje na dostępie do portów i traktuje dostęp do nich jak właśnie była by to zmienna z deklaracją volatile.
Chyba że jest inny powód którego nie dostrzegam ???

Nie optymalizuje, ale jeśli wie,że chodzi o port ( czy ogólnie SFR ).
Jeśli zapisać po prostu :
#define LCDPORT PORTB
to żadne dodatkowe "wytyczne" nie są potrzebne ( wszystko, łącznie z założeniem
volatle jest wbudowane w mechanizm definiowania SFR - dla ciekawości możesz
zajrzeć do nagłówka /avr/include/avr/sfr-defs.h )
Natomiast "goły" adres 0x38 - trzeba samodzielnie uzupełnić
potrzebnymi informacjami.

Pozdrowienia Jurek S.

Sławek5 · Postautor: **Sławek5** » 26 paź 2005, o 11:50

A jak można sprawdzic czy kompilator dokonuje uproszczen (optymalizacji) na zmiennych lub na portach, czy jest jakis sposob.

Guru · Postautor: **Guru** » 26 paź 2005, o 13:34

Otóż ja jestem jak najbardziej zwolennikiem zaglądania do kodu w asm.
Bo filozofia typu "że jak mi zabraknie to wezmę procesor z większymi zasobami" prowadzi bardzo szybko do nikąd.
Do Sławek5 i to jest właśnie optymalizacja jeżeli to samo działanie kompilator zapisze przy pomocy 20 czy 40 bajtów i to też można zobaczyć podglądając kod w asm.
A bez znajomości chociaż podstawowej architektury systemu i asemblera, można napisać aplikację:

"HELLO WORLD" -
,-----------------,
| Zamknij mnie |
'------------------'

w Windowsie

a_antoniak · Postautor: **a_antoniak** » 26 paź 2005, o 13:51

To może inaczej: działanie zależy od zaistniałej potrzeby.
Czasami warto zajrzeć w asm po kompilacji i niewiele zmienić w kodzie w C tak aby uzyskać lepszy wynik w asm. Ale tylko wtedy gdy naprawdę jest taka potrzeba. Zdecydowanie nie warto wertować skompilowanego kodu w celu "optymalizacji" kodu źródłowego w C kierując się zasadą "sztuka dla sztuki".
Natomiast w sytuacjach, w których pewne (zwykle niewielkie) fragmenty programu muszą być po prostu szybkie to warto zastosować technikę programowania hybrydowego.

[ Dodano: 26-10-2005, 13:57 ]

Kiedyś wstawki asemblerowe uznawałem z cos koniecznego, ale teraz ich nie uzywam, bo w paru przypadkach programuje procesory których lista rozkazów nie jest mi znana.

No, to akurat niezbyt dobra argumentacja.

tasza · Postautor: **tasza** » 26 paź 2005, o 13:58

Guru
ależ w asm też można, równie ładne jak w C to wyjdzie....

Kod: Zaznacz cały

.386                   
.model flat, stdcall   
option casemap:none    

; Win32 stuff
include    \masm32\include\windows.inc
include    \masm32\include\kernel32.inc
include    \masm32\include\user32.inc
includelib \masm32\lib\user32.lib
includelib \masm32\lib\kernel32.lib

.data
HelloCaption db  "Hello world...",0
HelloText    db  "Zamknij mnie",0

.code
HelloWorldApp:
  invoke  MessageBox, 0, ADDR HelloCaption, ADDR HelloText, MB_OK
  invoke  ExitProcess, 0    
end HelloWorldApp

to MASM32....

a_antoniak · Postautor: **a_antoniak** » 26 paź 2005, o 14:18

Powstają frakcje:
- lewica - ci, którzy ciągle chcą grzebać w asm;
- prawica - ci, którzy w ogóle nie chcą grzebać w asm;
- centrum, czyli ja

.

To może wybierzemy sobie marszałka?

tomek_j · Postautor: **tomek_j** » 26 paź 2005, o 14:48

Kiedyś wstawki asemblerowe uznawałem z cos koniecznego, ale teraz ich nie uzywam, bo w paru przypadkach programuje procesory których lista rozkazów nie jest mi znana.
No, to akurat niezbyt dobra argumentacja.

To akurat nie argumentacja za lub przeciw, tylko efekt przejścia przez pewne etapy. Brak znajomości listy rozkazów nie jest wynikiem lenistwa czy braku ciekawości świata, ale cisnieniem zewnętrznym. Brak listy rozkazów nie spowodował niemożności stworzenia wydajnej działającej aplikacji. Co ciekawe wśród moich znajomych również zaczyna dominować ta tendencja. Moim skromnym zdaniem czas fachowca od procesora X, ktory potrafi wycisnąc z niego (procesora) ostanie poty kończy sie bezpowrotnie.
Ale Arek pewnie sie z tym nie zgodzi

a_antoniak · Postautor: **a_antoniak** » 26 paź 2005, o 15:00

Oczywiście, że się zgodzę, czy ja wyglądam na polityka?

. Tyle razy pisałem na tym forum o potrzebie bycia elastycznym i szybkiego uczenia się nowych rzeczy, że aż mdli. Przywiązanie się do uP serii X i trzymanie się pazurami to zaścianek.
Tyle, że znajomość asemblera i programowanie hybrydowe (w razie potrzeby) to bardzo dobra technika, bo pozwala w pełni wykorzystać to co dany uP oferuje - i nie chodzi tu o "ostatnie poty".

pajaczek · Postautor: **pajaczek** » 26 paź 2005, o 18:32

Powstają frakcje:
- lewica - ci, którzy ciągle chcą grzebać w asm;
- prawica - ci, którzy w ogóle nie chcą grzebać w asm;
- centrum, czyli ja .

To może wybierzemy sobie marszałka?

Marszalkiem bede ja... ja pisze ostatnio tylko w ASM

Otóż ja jestem jak najbardziej zwolennikiem zaglądania do kodu w asm.
Bo filozofia typu "że jak mi zabraknie to wezmę procesor z większymi zasobami" prowadzi bardzo szybko do nikąd.

Nie... to prowadzi do Shitdowsa i pochodnych.

a_antoniak · Postautor: **a_antoniak** » 26 paź 2005, o 18:39

Marszalkiem bede ja... ja pisze ostatnio tylko w ASM

hmm... ciekawe co na to prawica?

. Wygląda na to, że koalicja nie powstanie ;P

pajaczek · Postautor: **pajaczek** » 26 paź 2005, o 18:49

Po co nam parwica... po co nam koalicja... rzady beda autokratywne i tyle

A jak nie to dam Wam wina, dam Wam wodki. Dobrze bedzie.

Jak mawiaja znajomi... lepiej to nie bedzie, ale za to bedzie smieszniej.

a_antoniak · Postautor: **a_antoniak** » 26 paź 2005, o 19:22

Jak mawiaja znajomi... lepiej to nie bedzie, ale za to bedzie smieszniej.

Tak mawiał Pietrzak jakieś 10-15 lat temu. Dziś to mi już nie do śmiechu

tomek_j · Postautor: **tomek_j** » 27 paź 2005, o 10:23

Otóż ja jestem jak najbardziej zwolennikiem zaglądania do kodu w asm.
Bo filozofia typu "że jak mi zabraknie to wezmę procesor z większymi zasobami" prowadzi bardzo szybko do nikąd.

To nie jest moja filozofia, tylko producentów układów. Jeżeli mogę dzisiaj mieć procesor 32bitowy, z dobrymi peryferiami, małym poborem mocy, dostępnymi tanimi lub bezpłatnymi narzędziami, starter kitami itp za pieniądze porównywalne z ceną wypasionego 8-bitowca, to po co kombinować z wstawkami, wydajnością itp bo 8 bitowy zaczyna mi sie nie wyrabiać..... Wiem, zę ten pogląd oburzy wielu mających wysokie mniemanie o sobie specjalistów od wyrafinowanych technik programistycznych wymagających specjalistycznej wąskiej wiedzy, ale trudno. Co maja zrobić fachowcy od Camaca, TTL i tablic Karnaugha, Marquanda itp? Że można wszystko zrobic w ten sposób....można. Przy tym tępie rozwoju techniki kto mi zabroni przypuszczac, ze za pare lat nie bede miał procesora z rdzeniem ARM9, 10Mb flash i 1Mb SRAM, taktowanego 200MHz z peryferiami i pobierającym np 20mA przy pełnej prędkości za 30PLN????
Dzisiaj bardziej mi się opłaca do rozwojowych projektów zastosować na przykład LPC Philipsa niz najbardziej wypasionego PIC18 czy ATmegę. A do asemblera jeszcze nie zaglądałem niestety.....
Pozdrawiam
T.J.

bis · Postautor: **bis** » 27 paź 2005, o 11:39

Jeżeli będziemy patrzec wyłącznie z punktu efektywności pracy mierzonej szybkością uzyskania koncowego efektu to całkowicie zgadzam sie z Tomkiem_i. Optymalizacja jest zawsze końcowym etapem pracy. Jednak są conajmniej dwa powody dla których wiedza "jak to naprawdę działa" jest przydatna. Jeden to taki że pewne techniki optymalizacji obejmują już podstawowe założenia wg których nalezy tworzyć projekt od początku (np. omawiany tu sposób dostępu do kluczowych zmiennych) Drugim powodem jest konieczność rozwiązywania różnych problemów technicznych pojawiających na bieżąco przy pracy z danym prockiem i narzędziami do niego (np. wolne działanie I/O w ARM Philipsa albo "tajemnicze" puchnięcie kodu czy nadmierna allokacja pamieci RAM). Aby poradzic sobie z błędami/niedoskonałościami kompilatorów i zlokalizowaniem przyczyn dla których "napisałem dobrze ale to nie działa" głębsza wiedza jest przydatna. No i pozostaje obszar który mozna nazwać "ciekawością pasjonata". Mnie nie wystarcza radość z faktu że coś działa, ja po prostu lubię wiedzieć dalczego i jak to się stało.

a_antoniak · Postautor: **a_antoniak** » 27 paź 2005, o 11:52

Żrecie się jak stado szczeniaków. Działania dostosowuje się do celu jaki mają przynieść, i tyle. Jeśli można tanio i bez innych przeszkód użyć lepszej platformy - bierzemy i nie bawimy się w pierdoły. Ale jeśli sytuacja jest taka, że sięgniećie po coś mocniejszego jest z różnych względów niekorzystne, a to co mamy można wykorzystać przy niewielkim wejrzeniu w pierdoły - to poświęcamy chwilkę na pierdoły i sprawa załatwiona.

tomek_j · Postautor: **tomek_j** » 27 paź 2005, o 12:24

Żrecie się jak stado szczeniaków.

Prosze nie mieszać w to naszej ukochanej codzienności. Wymieniamy poglądy akademicko z samej potrzeby ich wymieniania

Zresztą bardziej stosowne byłoby ornitologiczne porównanie. Na przykład dziobiecie sie jak......

połączenie dwóch zmiennych typy byte na jedną typu int w C

Kto jest online