Programowanie uC - Pascal, czy C ?

Wstawi asemblerowe to sie robilo 30 lat temu. Dzisiaj praktyka mowi aby napisac procedure w asemblezre i wolac jja z C

A.L.

C? Wstawka asm w funkcji C jest chyba bezpieczniejsza bo kompilator wm zadba prolog i epilog funkcji...

Na uC w C da się zrobić wszystko a w Pascalu nic. Głównie dlatego że wybór języka programowania przez rynek dawno został zrobiony i nie ma tu żadnego sensownego argumentu. Po prostu *NIE* ma kompilatorów Pascala na uC poza jakimś żałosnym hobbystycznym szumem, więc rozmowa na ten temat jest czysto akademicka i nie ma praktycznego zastosowania jak również wykazuje ukryte skłonności samobójcze kierownika potencjalnego projektu.

W dniu poniedziałek, 27 stycznia 2014 17:45:17 UTC-5 użytkownik J.F napisał:

C i Pascal to duze uproszczenie w porównaniu z wcześnieszymi PL/I czy Algolem 68. Ale nawet Pascal Wirtha zawiera parę "ciekawych" konstrukcji:

- zwracanie wartosci przez przypizanie do nazwy funkcji (trzeba rozróżniać zwracanie wwartości od wywołania rekursywnego)

- parametry przekazywane przez wartość i przez zmienną, trzeba je rozróżniać, a przekazywanie przez zmienną wymaga w praktyce żeby kompilator w środu miał operator adresu

- rekordy z wariantami, mają część stałą i zmienną, przy tym pozwalają na dowolne zagnieżdżanie (co daje podobny efekt jak anonimowe unie wprowadzone w latach 90 do niektórych kompilatorów C)

- rekordy spakowane, użyteczność podobna do pół bitowych, ale można napisać całą masę bezużytecznych deklaracji które kompilator ma poprawnie obsłużyć.

- funkcje lokalne (mają dostęp do zmiennych otaczającej je funkcji)

- skoki nielokalne (trzeba zwinąć stos wywołań)

- tablice konforemne, mają specjalną regułę przekazywania jako parameter i wymagają wsparcia dla tablic zmiennej wielkości

Wiele implementacji Pascala pomijało ważne własności ale pełna implementacja byłaby bar

Nietrywialne użycia "with" zastępuje operator adresu i wskaźniki. Tak źe w sumie zysk dla Pascala raczej niewielki. Ja pisałem sporo w Pascalu, a nie pamiętam czy kiedyś uzyłem "with".

Pascal pozwala na wydajny kod jak masz optymalizator. Ale bez optymalizatora kod wynikowy będzie gorszy niż z C,

ma tu

na

temat

ektu.

Obrazek nie jest tak zero-jedynkowy jak go przedstawiasz. Jest GNU Pascal

L.

No nie, spodziewam sie ze pierwsze byly kiepskie. Ale sie udoskonalily ... jak piszesz - na dlugo przed pecetami.

No nie - to tylko jedna z mozliwosci, dla tych co chca szybko pascala posadzic na nowej maszynie. Byly i normalne kompilatory.

Zalezy. Programista mowi ze C jest dwa razy szybsze i Pascal przestaje byc uzywany.

Ale niespecjalnie krytycznie :-)

Spojrz na produkty Borlanda ... i nie masz racji. Pare rozszerzen do standardu i oba jezyki sa prawie identyczne.

A potem zrobili C++

No ale C tez moze je usunac.

Mowisz ze tak to bylo ? Czy to juz jednak czasy wciec ?

J.

Historia jezyka C

Byly. Ale te ktore znam (Na Odre na prztklad, czy Turbo Pascal) benerowaly kod maszynowy "on the fly" zamiast generacji p-codu. Ale bazujaca na kompilatorze Ammana. Struktura kompilatora byla taka sama i narzucona pzrez strukture jezyjk poniekad

A.L.

sztuczki optymalizacyjne.

bibliotek.

sgetri, dgetri cgetri, zgetri

:-)

pzdr bartekltg

W dniu 27.01.2014 14:47, Jarosław Sokołowski pisze:

Ostatnio słabo mi się sprawdził fpc pod względem szybkosci. Ale możliwe, że są szybkie, szczególnie komercyjne. Tu się spierał nie będę.

Pan Cezary Grądys napisał:

Też nie chodzi mi o to, by sie spierać, tylko o ustalenie faktu. Sytuacja z Mizarem i zmianą kompilatora z Borlanda na FPC miała miejsce na przełomie wieków (przypomnę, że skutkowało to sporym przyspieszeniem). Ale pamiętam też, jak ktoś tak z dziesięć lat wcześniej pokazywał mi swoje analizy kodu wynikowego Borlanda -- był tak dobry, że trudno było coś poprawić. W dodatku Pascal miewał ten kod lepszy od C w analogicznym programie testowym. Może to stąd, że te analizowane programy były stosunkowo proste, a Mizar, to kawał kodu. Możliwe, że ta utrata szybkości następuje przy jakichś konkretnych rzeczach, które słabo zostały dopracowane w kompilatorze (nie wyrabia się na zakrętach, czy cóś).

Popatrz sobie jak dziala kompilator Pascala. Zagniezdzone procedury powoduja ze dostep do miennych musi sie odbywac pzrez tworzony na biegowo, w czasie wykonywanai programu, ciag aktywacji (dynamic activation link). C czegos takiego nie potzrebuje z definicji. Wiec dostep do zmiennyc hzajmuje w Pascalu wiecej czasu niz w C

A.L.

Hm, musialbym przypomniec sobie ... ale jest to chyba a) do zrobienia - kompilator wiedzac ze to procedura wywolana z nadrzednej moze policzyc gdzie na stosie jest zmienna nadrzednej. gorzej jesli jest rekurencja. A C przeciez tez ma bloki w funkcji, w ktorych moga byc wlasne zmienne. A C++ to juz w ogole.

b) do obejscia - jesli procedura dostanie dodatkowe parametry z uzywanymi zniennymi z nadrzednych.

c) a przeciez wystarczy napisac - kto uzywa zmiennych z nadrzednych procedur obniza wydajnosc.

J.

kiego : a >

zamiast

dowolnej zmiennej "byle gdzie", to zaproszenie do burdelu. Ot, taki jest j

calu.

r++ i

w PHP

L !! Itd., itp...

cz teraz o nich. Jeszcze

rnighan

le jego tekst pokazuje w

Pascalem.

rawa ale nie dorabiaj

nia na

dukacyjne a nie

naczenia, w

?.

ista w jedynie

e C jest

?czesne

?niejszy szlag

gramistycznym.

bardziej czytelno/nieczytelny. To tylko operatory logiczne.

for(;;;) - co to QRVA jest?!

a+=b; a-=b;

menty zapisane w C, to jest po prostu BURDEL jak tralala!!

a1b+; a1b-;

W dniu 01.02.2014 00:43, snipped-for-privacy@gmail.com pisze:

Aha..

-- butek Safety note: Don't put all your enriched uranium hexafluoride in one bucket. Use at least two or three buckets and keep them in separate corners of the room. This will prevent the premature build-up of a critical mass.