C i mikroprocesory

No właśnie, gdyby puścić te moje programiki na 486 lub niższym to wyniki mogłyby być wręcz przeciwne. :-)

Nigdy nie uważałem się za "miszcza" asm-a i386. Ale dlaczego od razu sp*? Przecież program działał. ;-) Tzn. dawał poprawne wyniki. :-)

BTW. Tak z 10 lat temu, w czasach 486 i Turbo C, napisałem taki programik do przeliczania macierzy int-ów 20x20. Wersja w asm była AFAIR jakieś

15 razy szybsza od wersji w C. No cóż, ale czasy się zmieniają. Obecnie pisanie w asm na nowoczesne procesory ma w sobie coś z czarnej magii. A i kompilatory C są lepsze.

No jest inna, bo w sam raz ta implementacja ma rozwiniętą pętlę już w kodzie C co trochę pomaga kompilatorowi.

Chociaż z drugiej strony, jak twierdzi Donald Knuth, "premature optimization is the root of all evil". IMO to dobra myśl, również dla tych, którzy na siłę chcą coś kombinować w assemblerze.

Regards, /J.D.

Dzięki, dzięki. ;-)

Regards, /J.D.

On Sat, 15 May 2004 19:40:12 +0200, "Piotr Wyderski" snipped-for-privacy@wp.pl wrote: [.....]

Właśnie. Tym bardziej że w znanym i lubianym gcc to bardzo ładnie działa.

Regards, /J.D.

Stabilnosc tez :-)

Za C przemawia przenosnosc. Jak program jest duzy, i przewidujemy zmiane procka na inna rodzine - assembler bedzie klopotem.

J.

Tak. Ale mysle ze to nie tylko jego problem :-)

Krotka ta lista. W dodatku np na stronach bmw google nie znajduje slowa Ada. U Alcatela moze ze dwa. Eurotunnel - zero. Taka to i lista.

Boeing - 130, Honeywell 65.

Malo cos tych zastosowan :-)

J.

Jasne, szczegolnie gdy w linii nr 5878 zamiast r31 uzyjesz r13. :-)

Dyskusyjna. Poza tym po co komu przenosnosc w zastosowaniach embedded? :-)

Pozdrawiam Piotr Wyderski

wystarczy za dużo poziomów wywołań funkcji, za dużo zmiennych lokalnych, za dużo zmiennych globalnych (zwłaszcza w takich procesorach, które mają po 128 bajtów RAMu) i już mamy problem.

tyle, że z tą kontrolą wszystkiego w asemblerze to też przesada. wystarczy znać zasadę działania kompilatora C i wiadomo, ile stosu zabiera dana funkcja. wszystko pod kontrolą.

w.

[.....]

No mało, ale jednak są. I *na pewno* ci którzy przy tym pracują nie narzekają specjalnie na swoje zarobki. :-) To tak jak z S/390 (obecnie zSeries) - maszynka ze średniej półki to około 2M$ + jakieś 10% rocznie za support, ale firmy to *nadal* kupują i AFAIK dobrze płacą sysadminom i programistom. A w szkołach przecież też tego nie uczą. :-) Bo to takie stare, nieintuicyjne i ładnych okienek nie ma. :-)

Regards, /J.D.

No nie wiem - ostanio jak optymalizowalem to bylo tylko 3 razy ..

Owszem. Ale wygrywa w innych miejscach.

Bo unix to taki system ktory jest napisany w C. A C to taki jezyk ktory sluzy do napisania unixa :-)

J.

^^^^^^^^^^^^

To wogóle można lubić C?! ;-) Mnie to odrzuca na samą myśl że muszę napisać coś w tym języku. A niestety wdziera się to paskudztwo coraz mocniej do elektroniki i automatyki nawet. Zresztą wogóle współczesna elektronika się coraz bardziej w wysokopoziomowe programowanie :-(

pozdrawiam Piotr

^^^^^^^^^^^^

To wogóle można lubić C?! ;-) Mnie to odrzuca na samą myśl że muszę napisać coś w tym języku. A niestety wdziera się to paskudztwo coraz mocniej do elektroniki i automatyki nawet. Zresztą wogóle współczesna elektronika zmienia się coraz bardziej w wysokopoziomowe programowanie :-(

pozdrawiam Piotr

Pluć na C to tak jakby twierdzić ze jezyk angielski jest nieprzydatny do komunikacji miedzynarodowej. RTOFL.

Mozesz sobie strzelic do dupy. To jest kompilator wylacznie na Intela i pod system DOS.

Przeczytaj watek od początku. Gosc dopiero chce sie uczyc C. BCC jest do tego najlepszy. Na razie nie przyklada sie tego do zadnego konkretnego sprzetu.

Ostatnio, czyli kiedy, co i pod co optymalizowales? :-)

Gdzie? OK, wielokrotne wykorzystywanie tego samego obszaru pamieci do przechowywania roznych rzeczy slabo wychodzi kompilatorom, ale poza tym?

Unix to taki dodatek do EMACSa. :-)

Pozdrawiam Piotr Wyderski

C niekoniecznie trzeba lubić, ale znać należy. Dla własnego dobra. :-)

Coraz więcej procesorow jest wykorzystywanych w różnych aplikacjach to i więcej programować trzeba.

Regards, /J.D.