sterowanie urządzeniami el. przez PC?

Użytkownik "Mario" napisał

jądra systemów operacyjnych (czyli to co najważniejsze) pisze sie w asemblerze, całą resztę bajerów w C:O)

opis to jest tylko wyglądu czarngo puidełeczka a do tego co w środku opisów nie ma, często nawet nie masz mozliwosci zajrzeć do tego co jest w środku, bo są to funkcje skompilowane, kiedyś pamiętam napisałem bardzo prostą unkcyjkę (kilka lini kodu) a potem znalazłem funkcję w kompilatorze o opisie dokładnie odpowiadającemu działąniu mojej funkcji i jak zajrzałem do jej kodu źródłowego (nie pamiętam skąd go wziąłem, może było dostępne żródło w C) to zobaczyłem dosłownie setki lini kodu, nawet nie byłem w stanie tego przeanalizować,

co tu czytać? to zależy wyłącznie od architektury procka

Użytkownik "T.M.F." napisał:

ja pie### literatura? poczytaj podręcznik do C i do asemblera, acha samo przeczytanie nic ci nie da, niestety jeszcze nie wymyślono literetury która jeszcze myśli za czytelnika, głową musisz ruszyć sam, może zaboleć:O)

Użytkownik "zbyszek" napisał:

dałeś bardzo dobry przykład, wiekszość funkcji jest właśnie tak pisana zeby była debiloodporna, sprawdza wszystko i jest na wszystko odporna, zajmuje setki lini kodu i nadmiernie obciąża procesor:O( widzisz, nie zawsze takich funkcji potrzebujesz, często wystarczy ci funkcja które niczego nie sprawdza i wykonuje to samo w paru liniach kodu, a błędów nie będzie bo funkcja pracuje tylko na jednym typie danych i już sprawdzonych:O)

ok, wpożo, jak wydajność i niezawodność nie jest wymagana to sie pisze w C:O)

ok, bo prawdopodobnie była ona pisana w asemblerze:O)

Użytkownik "Mario" napisał:

fakt, ale powiedz mi ile komend asemblera wygeneruje kompilator włąśnie dla takiej prostej pętli napisanej w C?:O)

może, ale akurat osoba co mi program zademonstrowałą, pokazała mi też identyczny program napisany w C (jeden i drógi pisane przez zawosowe zespoły porogramistów) i porównanie było też takie jak pisałem:O)

Dobry kompilator potrafi petle calkowicie usunac, jesli wyda mu sie niepotrzebna.

Ba - mi kiedys caly program usunal. Nic nie drukowal, interesowal mnie tylko czas wykonania, a kompilator wykazal sie inteligencja i zoptymalizowal do zera :-)

J.

gargamel pisze:

Eeee, ale niby od kiedy? W asemblerze są zwykle 2-3 pliki (część wspólna przerwań, część schedulera związana z przełączaniem kontekstu, startup) i już. Cała reszta jądra, włączając scheduler, kolejki, powiadomienia, starzenie zadań - to wszystko prawie zawsze pisze się w C. Wtedy jest duużo mniej roboty z portowaniem na kolejny procek. Zobacz przykładowo, na ilu platformach pójdzie FreeRTOS. A to tylko mały pikuś w porównaniu z większymi systemami.

he he a ty cišgle uparty....wspomagania sprzętowego operacji dsp nie zastšpi nawet najlepszy asembelr :)

zbyszek

Zamiast filozofować naucz się pan w końcu języka polskiego a później ANSI C.

Użytkownik "zbyszek" napisał:

ojej, oczywiste ze sprzętowo jest najwydajniej, potem asembler, następnie języki wysokopoziomowe:O) a co do FFT to procesory sygnałowe wykonują to sprzętowo, programuje sie je też w asemblerze:O)

gargamel napisal(a):

No ale jesli w procesorze sa jakies pajlajningi, jednostki rownogle, itd to programowanie w asm chyba nie musi byc najszybsze?

gargamel denied rebel lies:

Chcesz się ścigać z optymalizacjami kompilatora? To dobry musisz być. Ja nie mam zamiaru - piszę w C a kompilator załatwia resztę.

MoonWolf pisze:

Chyba nic nigdy nie pisałeś na DSP'ki. Kompilator C wygeneruje zwykle kod asemblerowy kilka razy !!! gorszy, niż mógłbyś sam ręcznie wycyzelować (mając pod ręką listę instrukcji z zależnościami pipeline itp). ARM to inna sprawa i tutaj przeciętny kompilator C z włączoną optymalizacją zadziała podobnie do optymalizacji ręcznej. Natomiast pecety (x86) to ekstremum w drugą stronę - przy kompilacji kodu dla wyższych architektur (np. Pentium) i włączonej optymalizacji mała jest szansa wygrać ręcznie z kompilatorem. Chyba że korzystasz z dodatkowych instrukcji a'la DSP czyli SSE/SSE2/SSE3/SSE4 itp.

In the darkest hour on Mon, 16 Feb 2009 20:06:38 +0100, gargamel snipped-for-privacy@dolina.eu screamed:

Aha. Czyli widzimisię. Syndrom związany z byciem ajatollahem asemblera.

In the darkest hour on Sun, 15 Feb 2009 22:01:59 +0100, gargamel snipped-for-privacy@dolina.eu screamed:

Tu przede wszystkim chodzi o krótszy kod źródłowy i krótszy czas, który trzeba zużyć na napisanie programu.

Jakieś potwierdzenie tych Twoich widzimiśnych faktów?

Początkujący zazwyczaj generują PEBKAC-e. A to jest niezależne od języka.

In the darkest hour on Mon, 16 Feb 2009 20:03:42 +0100, gargamel snipped-for-privacy@dolina.eu screamed:

Rozumiem. Sprawdźmy kolejne fakty...

# tar tvjf linux-source-2.6.26.tar.bz2 |grep -c '\.c$'

Gdyby pisać wszystko w assemblerze, to samo zdebugowanie zajęłoby dużo czasu, nie mówiąc o konieczności wynajdowania koła w postaci backtrace.

Artur M. Piwko pisze:

BTW: Zauważ, że pliki w asemblerze są najczęściej odrębne dla n różnych procesorów, natomiast większość z kodu pisanego w C da się odpalić na różnych platformach. Dlatego sensowniejsze byłoby obliczenie, ile plików w asm i ile w C jest używanych do konkretnej kompilacji jądra Linuxa, np. dla x86 ze standardowym zestawem sterowników. Wyjdzie pewnie 20-30x więcej plików w C, niż w asm. Przelicz to na liczbę linii kodu...