Programowanie uC - Pascal, czy C ?

W dniu 27.01.2014 21:55, Grzegorz Niemirowski pisze:

Pozdrawiam Grzegorz

amistycznym.

bardzo

logiczne.

sztuczki

powolnego niejawnego kodu

zapis

wykonania np. 1.5 a badziewiaty kompilator Frotranu np. 4 i

rne

w zadanym zakresie. Kompilator Pascala wie kiedy ma do czynienia

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

tora

w dokumentacji procesora...). W Pascalu podobna rzecz

i bibliotek.

dyskusyjnych: snipped-for-privacy@googlegroups.com...

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.

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

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

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

Pare rozszerzen made in Borland i oba dawaly taka sama.

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.

No, na tej arytmetyce mozna lekko osiwiec :-)

Akurat tego bym nie gloryfikowal, malo uzyteczne.

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.

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.

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.

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

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.

Biblioteki C w zasadzie mozna by i w Pascalu wykorzystac.

J.

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.

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.

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

J.

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

A.L.

[...]

Hello Hebisch, [...]

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

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

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

J.

On Mon, 27 Jan 2014 21:00:00 +0100, Jaros?aw Soko?owski

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.

Jasne. Tylko czasem analizowa? dzia?anie cudzego programu trzeba. I zaczynaj? si? wytryski fantazji programistycznej...

od fizycznej struktury danych w pami?ci. O ile w przypadku drobnych

by? kul? u nogi.

Nie byly badziewne. Pierwsze kompilatory C byly doskonale, na dlugo zanim pojawily sie pecety. W C byl i jest pisany UNIX. Gdy Pecety sie pojawily, kompilatory C bazowaly na technice kompilacji kompilatorow Unixowych i byly naprawde doskonale. Zas kompilatory Pascala bazowaly na p-kodzie i maszynie wirtualnej

Jak idzie o optymalizacje, to optymalizacja nei jest specjalnie krytyczna

No i wlasnei dlatego program w Pascalu jest wolniejszy niz w C

Nei nalezy porownywac pomarancz z jablkami. Pascal to silnie typowany jezyk wysokiego poziomu, C to "strukturalizowany asembler" dla zastosowan gdzie neisbedny jest bliski kontakt z "metalem"

NA dodatek, Pascal ma pewne cechy ktore powoduja ze musi wykonywac sie wolniej niz C. Oprocz indeksow tablic (patzr wyzej) sa "zanurzone procedury" (nested procedures) ktore wymahaja aby dostep do pewnych elementow byl okreslany w czasie wykonania programu.

Dodatkowe problemy sa historyczne. Pascal zrobil sie populatny gdy pojawil sie kompilator Ammana bazuajcy na p-kodzie, ktory umozliwial latwe przenoszenie na inne maszyny. Kopmilatory Pascala albo poprzestawaly na p-kodzie i jego interpretacji, albo kompilowaly p-kod do kodu maszyny. Niektore (kompilator dla ICL1900, czylo Odry 1305) generowaly nierelokowalny kod maszynowy zamiast generacji p-kodu. Oczywiscie, to wszystko plus prostota rekursywnych parserow LL(1) powodowala ze generowany kod nei byl piorunujacej jakosci.

Optymalizacja zas nei zawsze jest pozadana. Wiadomo ze a + (b+c) nei rowna sie czasami (a+b)+c, a optymalizujacy kompilator usunie nawiasy jako pierwsza czynnosc. No, chyba ze to jest kompilator Fortranu...

A.L.

P.S> A przyczyna zwiezlosci C jest prosta: gdy uzywa sie {} zamiast begion/end, krazek tasmy papierowej jest znacznie mniejszy...

Do tego wlasnei sluzy C. C jest strukturalizowanym asemblerem

A.L.

Nie jestem pewien. Link do standardu?...

A.L.

W dniu 2014-01-27 23:45, J.F pisze:

Gorzej z konstrukcjami typu:

W dniu 2014-01-28 08:42, Zbych pisze:

No właśnie, ten zapis jest przykład typowego, niechlujnie napisanego kodu w imię tzw. "zwięzłości". :-D

No pewnie. A w ramach czytelności warto też wstawić spacje po obu stronach operatora +=. Nawet pomimo tego, że to takie rozrzutne. :-D