Grzegorz Kurczyk <g...@c...slupsk.pl> napisał(a):
> Zapis ze wskaźnikiem stosowałem w związku z optymalniejszym kodem
> wynikowym avr-gcc. Przy konstrukcji Buff[i++] umieszczonym w pętli w
> kodzie wynikowym za każdym razem był liczony wskaźnik do i-tego elementu
> tablicy. Czyli gdy np elementami tablicy Buff były zmienne typu long, to w
> pętli za każdym przejściem było liczone wskaźnik do elementu wg wzoru ptr
> = adres_bazowy_tablicy_Buff + i * 4; Przy zastosowaniu wskaźnika był on
> ustawiany na adres początku tablicy tylko raz przed pętlą, a potem
> wewnątrz pętli inkrementację wskaźnika załatwiał jeden rozkaz procesora
> ADIW Z, 4
> Pozdrawiam
> Grzegorz

Hm, to ciekawe. Może to przypadłość konkretnej wersji avr-gcc lub kwestia
ustawień kompilacji. Z tego co wiem, współczesne kompilatory na tyle radzą
sobie z optymalizacją, że potrafią wygenerować tak samo szybki kod dla
dostępu wskaźnikowego jak i tablicowego.
http://stackoverflow.com/questions/2305770/efficienc
y-arrays-vs-pointers

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 12 days, 20 hours, 7 minutes and 48 seconds

do góry

W dniu 27.01.2014 21:55, Grzegorz Niemirowski pisze:
> Grzegorz Kurczyk <g...@c...slupsk.pl> napisał(a):
>> Zapis ze wskaźnikiem stosowałem w związku z optymalniejszym kodem
>> wynikowym avr-gcc. Przy konstrukcji Buff[i++] umieszczonym w pętli w
>> kodzie wynikowym za każdym razem był liczony wskaźnik do i-tego
>> elementu tablicy. Czyli gdy np elementami tablicy Buff były zmienne
>> typu long, to w pętli za każdym przejściem było liczone wskaźnik do
>> elementu wg wzoru ptr = adres_bazowy_tablicy_Buff + i * 4; Przy
>> zastosowaniu wskaźnika był on ustawiany na adres początku tablicy
>> tylko raz przed pętlą, a potem wewnątrz pętli inkrementację wskaźnika
>> załatwiał jeden rozkaz procesora ADIW Z, 4
>> Pozdrawiam
>> Grzegorz
>
> Hm, to ciekawe. Może to przypadłość konkretnej wersji avr-gcc lub
> kwestia ustawień kompilacji. Z tego co wiem, współczesne kompilatory na
> tyle radzą sobie z optymalizacją, że potrafią wygenerować tak samo
> szybki kod dla dostępu wskaźnikowego jak i tablicowego.
> http://stackoverflow.com/questions/2305770/efficienc
y-arrays-vs-pointers
>

To nie tylko kwestia kompilatora ale i możliwości procesora. Przykład,
który podałeś tyczy "dużych" procesorów posiadających rozbudowane tryby
adresowania (32bitowy procesor z rodziny 686). On potrafi sobie policzyć
wskaźnik do elementu tablicy w jednym rozkazie i tu faktycznie nie ma
różnicy. W małym AVR-ku już tak słodko nie ma :-( Wyliczenie wskaźnika
do elementu tablicy to już kilka rozkazów. A jak tablica ma elementy
typu rekordowego o "dziwnej" liczbie bajtów w rekordzie, to w
wyliczeniach wskaźnika pojawia się czasochłonne mnożenie.

Pozdrawiam
Grzegorz

do góry

W dniu niedziela, 26 stycznia 2014 18:36:17 UTC-5 użytkownik s...@g...com
napisał:
> Temat zupełnie luźny do dyskusji. Niee, ekspertem Pascala absolutnie nie jestem,
ale zupełnie nieźle poruszam się w tym środowisku programistycznym.
>
> Kto i po jaką cholerę wymiślił C? W zasadzie pisze się programy bardzo
> podobnie jak w Pascalu. Ino, że imho jest to zdecydowanie mniej czytelne
> niż w Pascalu.
>
> A ileż się nasłuchałem, że w C da się zrobić to, czego w Pascalu się nie da.
>
> I w "sieci" też się o tym naczytałem.. Ino CZEGO DO PANI NĘDZY SIĘ nie da??
>

Wycięłem twoje przykłady bo bardziej wskazują na Twoją niewiedzię niż na
braki C. Narzekasz na najmiej istotne róznice, gdzie spora część
programistów uważa że rozwiązanie z C jest lepsze. Tzn. '{' i '}'
są tak samo czytelne jak 'begin' i 'end' ale krótsze. Pętla 'for'
w C jest bardzo wygodna w użyciu, a jak się do niej przyzwyczaisz
to będzie logiczna. W angielskim '&' jest używany jako skrót słowa
'and' więc jego użycie w iloczynie logicznym jest jak najbardziej
logiczne.

Pytasz się dlaczego wymyślono C. Proste, był potrzebny język
z nastepującymi własnościami:
- ma się dać kompilować głupim kompiltorem (pierwsza maszyna na której
chodziło C mała w porównaniu z innymi uwczesnymi maszynami)
- ma pozwalać na zwięzły i czytelny zapis programu
- ma pozwalać na otrzymanie w miarę wydajnego kodu wynikowego
- ma dawać kontrolę nad maszyną

Z tego punktu widzenia najważniejsze w C są:
- operator rzutowania (cast), bo pozwala na różne niskopoziomowe
sztuczki
- arytmetyka adresowa i konwersja tablic do wskaźników bo pozwala
jawnie zapisać manipulacje potrzebne przy dostępie do tablic
i w ten sposób uniknąć wstawiania przez kompilator potencjalnie
powolnego niejawnego kodu
- orientacja na wyrażenia: np. podstawienia w C są wyrażeniami i
mogą być użyte jako części innych wyrażeń co pozwala na zwięzły
zapis
- '++', '--' i ogólniej operatory modyfikacji jak np. '+=', są zwięzłe
i łatwo dla nich generować wydajny kod
- operatory i pola bitowe, pomagają przy programowaniu sprzętu.


Dziś kompilatory optymalizujące dla C są łatwo dostępne, więc można
nie doceniać możliwici użycia prostego kompilatora. Ale w pierwszych
latach C kompilatory dla mini i mikrokomuterów były badziewiate.
Jak komplator optymalizujący (wtedy niedostępny) dałby kod o
czasie wykonania 1 to badziewiaty kompilator C dawał czas
wykonania np. 1.5 a badziewiaty kompilator Frotranu np. 4 i
szła fama że "C jest szybkie". W efekcie C zdobyło sobie
popularność. Dziś większą rolę odgrywa rozpęd: C jest popularne
więc autorzy kompilatorów (i innych narzędzi) się starają.
Ludzie używają C bo są dobre narzędzia.

C ma parę wad w porównaniu z Pascalem. Najważniejsze jest
luźniejsze sprawdzanie typów, kompilator C względnie łatwo
przepuszcza który w Pascalu sygnalizuje bład typu. W efekcie
można się namęczyć z szukaniem błędu który w Pascalu byłby
usunięty przed pierwszym uruchomieniem programu. W bardziej
trywialnych rzeczy ':=' jako podstawienie i '=' jako porównanie
jest niezwykle tródno pomylić, zaś w C napisanie '=' zamiast
'==' jest jednym z częstszych błędów. Nowoczesne kompilatory
C ostrzegają o wielu konstukcjach które choć legalne to
prawdopodobnie są błędem, ale ciągle to mniej niż może
zrobić kompilator Pascala. Inną wadą w podobnym duchu
jest trudność sprawdzania czy indeksy tablic mieszczą się
w zadanym zakresie. Kompilator Pascala wie kiedy ma do czynienia
z tablią i zwykle (z wyjątkiem niekiedy dodawanyc konstrukcji
w stylu C) zna rozmiar tablicy więc może automatycznie wstawić
instrukcje sprawdzające czy indeks mieści się w granicach.
Kompilator C widzi wskaźnik i nie jest jasne jakie są granice
obszaru zawierającego wskazywany element. To powoduje że
automatyczne sprawdzanie zakresu indeksów jest znacznie
trudniejsze (nie znam "normalnego" kompilatora C który by
to robił).

Pascal w zasadzie potrafi to samo co C, choć program może być
nieco dłuższy jeśli skróty w C trzeba wyekspandować (program
w Pascalu może też być krótszy). Ale w C jest de facto standard
pozwalający zrobić sporo niskopoziomowych rzeczy. Np:

/* Diable watchdog timer */
WDTCTL = WDTPW | WDTHOLD;

jest normalnym kodem w C który wstawia wartość do rejestru
WDTCTL (sterowanie watchdoga w MSP430). Dokładniej,
w MSP430 rejestry urządzeń pojawiają się pod magicznymi
adresami pamięci. C ma preprocesor który czyta pliki
nagłówkowe i rozwija makrodefinicje. Plik nagłówkowy dla MSP430
definuje WDTCTL jako makrodeniicję, tak że główna cześć kompilatora
widzi coś w stylu:

*(volatile uint8_t *) 0xsss = 0xzzz | 0xwww;

gdzie '0xsss ' jest magicznym adresem zaś '0xzzz' i '0xwww'
są stałymi. W efekcie kod jest z zasadzie tak samo wydajny
jak kod assemblerowy bezpośrednio piszący do rejestrów
procesora, a czytelność jest znacznie lepsza (można by
chcieć lepszą nazwę niż WDTCT, ale akurat WDTCTL jest
w dokumentacji procesora...). W Pascalu podobna rzecz
wymaga rozszerzeń, najprawdopodobniej manipulacji
na wskaźnikach w stylu C + preprocesor albo 'properties'
w stylu Delphi. Jest spora szansa że jak weźmiesz
współczesny kompilator Pascala to będzie miał jakieś
rozszerzenie pozwalające to zrobić, ale problemem
może być znalezienie choć jednego kompilatora na
daną platformę. Do tego kompilator na inną platformę
może mieć na tyle różne rozszerzenia że będziesz miał
trochę roboty gdybyś chciał przeportować kod.

W sumie: jak masz dobry kompilator Pascala to może on
mieć zalety w porównaniu z C. Ale jest spora szansa
że C wygra ze względu na większą dostępność narzędzi
i bibliotek.

do góry

Użytkownik napisał w wiadomości grup
dyskusyjnych:3a3cc0cf-7519-4efc-b7a1-c307d18b9f33@go
oglegroups.com...
>Wycięłem twoje przykłady bo bardziej wskazują na Twoją niewiedzię niż
>na
>braki C. Narzekasz na najmiej istotne róznice, gdzie spora część

Tu racje ma A.L. - najpierw nauczyc sie w miare dobrze C, potem
narzekac :-)

Trzeba przyznac ze skladnia C jest "bledogenna" - nawet doswiadczony
programista moze sie latwo pomylic.
Wystarczy ze napisze a=b zamiast a==b i nieszczescie gotowe.

Ale lint lub ostrzezenia kompilatora pozwalaja sporo z nich wykryc.

>Pytasz się dlaczego wymyślono C. Proste, był potrzebny język
>z nastepującymi własnościami:
>- ma się dać kompilować głupim kompiltorem (pierwsza maszyna na
>której
> chodziło C mała w porównaniu z innymi uwczesnymi maszynami)

No, C i Pascal to mniej wiecej te same lata, a tych kombinacji w C
tyle, ze kompilator Pascala chyba znacznie prostszy.

>- ma pozwalać na zwięzły i czytelny zapis programu

Juz chyba nie bylo co oszczedzac pojedynczych znakow, a i tak
najwiecej sie na wciecia tracilo :-)
Brak instrukcji "with" w C troche utrudnia zwiezlosc.

>- ma pozwalać na otrzymanie w miarę wydajnego kodu wynikowego

Tego i Pascal nie wyklucza, no moze z wyjatkiem sprawdzania zakresow
tablic.

>- ma dawać kontrolę nad maszyną

Pare rozszerzen made in Borland i oba dawaly taka sama.

>Z tego punktu widzenia najważniejsze w C są:
>- operator rzutowania (cast), bo pozwala na różne niskopoziomowe
>sztuczki

Wirth by sie obrazil, ale to mozna i do Pascala wprowadzic.
Poza tym nie calkiem jest w C okreslone kiedy rzutujesz, a kiedy jest
konwersja.

>- arytmetyka adresowa i konwersja tablic do wskaźników bo pozwala
> jawnie zapisać manipulacje potrzebne przy dostępie do tablic
> i w ten sposób uniknąć wstawiania przez kompilator potencjalnie
> powolnego niejawnego kodu

No, na tej arytmetyce mozna lekko osiwiec :-)

>- orientacja na wyrażenia: np. podstawienia w C są wyrażeniami i
> mogą być użyte jako części innych wyrażeń co pozwala na zwięzły
> zapis

Akurat tego bym nie gloryfikowal, malo uzyteczne.

>- '++', '--' i ogólniej operatory modyfikacji jak np. '+=', są
>zwięzłe
> i łatwo dla nich generować wydajny kod

No, roznie z tym bywalo. Kolega kiedys w Pascalu z uwielbieniem pisal
np a+a, az kiedys spojrzal w kod i sie okazalo ze 2*a jest szybsze.
Fakt ze czesto ulatwia zapis.

>Dziś kompilatory optymalizujące dla C są łatwo dostępne, więc można
>nie doceniać możliwici użycia prostego kompilatora. Ale w pierwszych
>latach C kompilatory dla mini i mikrokomuterów były badziewiate.
>Jak komplator optymalizujący (wtedy niedostępny) dałby kod o
>czasie wykonania 1 to badziewiaty kompilator C dawał czas
>wykonania np. 1.5 a badziewiaty kompilator Frotranu np. 4 i
>szła fama że "C jest szybkie".

No nie, Fortran jak pisalem potrafil dac dobry kod.
Tylko ze on sie nadawal do obliczen, takiej "kontroli nad sprzetem"
jak C absolutnie nie mial.

>W efekcie C zdobyło sobie
>popularność. Dziś większą rolę odgrywa rozpęd: C jest popularne
>więc autorzy kompilatorów (i innych narzędzi) się starają.
>Ludzie używają C bo są dobre narzędzia.

> Inną wadą w podobnym duchu
>jest trudność sprawdzania czy indeksy tablic mieszczą się
>w zadanym zakresie. Kompilator Pascala wie kiedy ma do czynienia
>z tablią i zwykle (z wyjątkiem niekiedy dodawanyc konstrukcji
>w stylu C) zna rozmiar tablicy więc może automatycznie wstawić
>instrukcje sprawdzające czy indeks mieści się w granicach.

Ale to akurat umiarkowana zaleta. To ze program sam sprawdzi indeks i
sie wysypie z bledem jest w gotowym programie niedopuszczalne. Program
nie ma sie wysypywac.
A jak programista doda wlasne sprawdzenie ... to mu to od kompilatora
zupelnie niepotrzebne.

>Kompilator C widzi wskaźnik i nie jest jasne jakie są granice
>obszaru zawierającego wskazywany element.

No, obsluga tablic wielowymiarowych jest w C cokolwiek komiczna :-)

>Pascal w zasadzie potrafi to samo co C, choć program może być
>nieco dłuższy jeśli skróty w C trzeba wyekspandować (program
>w Pascalu może też być krótszy). Ale w C jest de facto standard
>pozwalający zrobić sporo niskopoziomowych rzeczy. Np:
> /* Diable watchdog timer */
> WDTCTL = WDTPW | WDTHOLD;

Akurat tu .. Pascala latwo rozszerzyc o operacje bitowe, zas C nie
gwarantuje jednolitej kompilacji powyzszego.
W obliczu roznych mozliwosci procesora i sprzetowych rejestrow nie
wiadomo jak C to skompiluje.

>W sumie: jak masz dobry kompilator Pascala to może on
>mieć zalety w porównaniu z C. Ale jest spora szansa
>że C wygra ze względu na większą dostępność narzędzi
>i bibliotek.

Biblioteki C w zasadzie mozna by i w Pascalu wykorzystac.

J.

do góry

Użytkownik "Jarosław Sokołowski" napisał w
Pan J.F napisał:
>> A z drugiej strony - uzyles f2c, wiec ominales problem ... ale C++
>> juz
>> sobie dobrze radzi z liczbami zespolonymi ?
>> Bo Fortran raczej nie ma z tym klopotu, ale dawniej kod z C++
>> daleki
>> byl od doskonalosci.

>To mnie zawsze wprawiało w pewną zadumę. Fortran od dziecka rachował
>na liczbach zespolonych jak na każdych innych. Zaś jego bezpośredni
>następcy jeśli już, to dopiero po dopisaniu do nich jakichś
>bibliotek.
>Edisony jakieś te wszystkie języki pisały, czy co?

No wiesz ... numerycy mieli swojego Fortrana i nie prosili o nic
wiecej, inni nie tykali sie numeryki i tez nie prosili i tak sie to
jakos ustalilo :-)

J.

do góry

Użytkownik "JDX" napisał w wiadomości grup
On 2014-01-27 18:34, J.F wrote:
>> A z drugiej strony - uzyles f2c, wiec ominales problem ... ale C++
>> juz
>> sobie dobrze radzi z liczbami zespolonymi ?
>> Bo Fortran raczej nie ma z tym klopotu, ale dawniej kod z C++
>> daleki byl
>> od doskonalosci.
>Podejrzewam (bo nie porównywałem), że C++ obecnie radzi sobie z
>liczbami
>zespolonymi tak samo dobrze jak Fortran. W każdym razie w bibliotece
>standardowej ma wsparcie dla tych liczb:
>http://en.cppreference.com/w/cpp/numeric/complex .

Wlasnie o to chodzi - w Fortranie napiszesz a+b, to wygeneruje kilka
instrukcji dla koprocesora dodajacy odpowiednie rejestry, a tu to
nawet nie wiem - jest inline, czy wywola funkcje ?

Funkcja w Fortranie jak ma zwrocic zespolony wynik, to zwraca w dwoch
rejestrach, a w C++ chyba to wykracza poza typy podstawowe, wiec
trzeba obiekt, pamiec na niego alokowac, potem zwalniac ... i operacja
a+b moze sie zrobic powaznym programem.


>> Takie np odwrocenie tablicy zespolonej rownie elegancko jak w
>> Fortranie
>> daje sie zapisac i rownie szybko idzie ?
>Elegancko macierze to się odwraca w Matlabie (i klonach):
>http://www.mathworks.com/help/matlab/ref/inv.html.
>A jak to się robi w Fortranie?

Elegancko sie uzywa funkcji z biblikoteki numerycznej. Ale ja o tym
jak taka funkcje samemu napisac :-)

J.

do góry

On Mon, 27 Jan 2014 21:00:00 +0100, Jaros?aw Soko?owski
<j...@l...waw.pl> wrote:

>Pan J.F napisał:
>
>> A z drugiej strony - uzyles f2c, wiec ominales problem ... ale C++ juz
>> sobie dobrze radzi z liczbami zespolonymi ?
>> Bo Fortran raczej nie ma z tym klopotu, ale dawniej kod z C++ daleki
>> byl od doskonalosci.
>> Takie np odwrocenie tablicy zespolonej rownie elegancko jak w
>> Fortranie daje sie zapisac i rownie szybko idzie ?
>
>To mnie zawsze wprawiało w pewną zadumę. Fortran od dziecka rachował
>na liczbach zespolonych jak na każdych innych. Zaś jego bezpośredni
>następcy jeśli już, to dopiero po dopisaniu do nich jakichś bibliotek.
>Edisony jakieś te wszystkie języki pisały, czy co?

Fortran wie ze a + (b + c) != (a + b) + c, a inne jezyki nie wiedza

A.L.

do góry

Hello Hebisch,

Monday, January 27, 2014, 10:44:15 PM, you wrote:

[...]

> - ma pozwalać na zwięzły i czytelny zapis programu

Oksymoron. W ogóle pisanie w kontekście C o czytelnym kodzie to kpina.

[...]

--
Best regards,
RoMan
Nowa strona: http://www.elektronika.squadack.com (w budowie!)

do góry

Użytkownik "RoMan Mandziejewicz" napisał w wiadomości
Hello Hebisch,
[...]
>> - ma pozwalać na zwięzły i czytelny zapis programu
>Oksymoron. W ogóle pisanie w kontekście C o czytelnym kodzie to
>kpina.

Alez skad. Sa konstrukcje ... ale nie musisz ich uzywac.

Nie podoba sie Sum+=*Bufptr++, to napisz

Sum=Sum+ Buf[i] ;
i=i+1 ;

J.

do góry

Użytkownik "A.L." napisał w wiadomości
On Mon, 27 Jan 2014 21:00:00 +0100, Jaros?aw Soko?owski
>>To mnie zawsze wprawiało w pewną zadumę. Fortran od dziecka rachował
>>na liczbach zespolonych jak na każdych innych. Zaś jego bezpośredni
>>następcy jeśli już, to dopiero po dopisaniu do nich jakichś
>>bibliotek.
>>Edisony jakieś te wszystkie języki pisały, czy co?

>Fortran wie ze a + (b + c) != (a + b) + c, a inne jezyki nie wiedza

My tu o liczbach zespolonych a nie zerowych :-)

W C wprowadzili "unary plus"

Piszesz a+ (+(b+c)) i liczy tak jak zapisane, a nie w dowolnej
kolejnosci.

J.

do góry