> no więc na ile komend asemblera kompilator gcc kompiluje pętlę for?
> bo w asemblerze wystarczą dwie, trzy instrukcje

I dokladnie tyle samo w gcc.
I o czym to ma swiadczyc?

do góry

>> A jak plyte sz.. trafi, to tak samo moze mi w mikroprocesorowym
>> sterowniku poleciec procek.
>
> to teraz policz ile w tym procku PC jest milionów tranzystorów, dodaj do
> tego resztę milionów tranzystorów w płycie głównej i podzespołąch i
> porównaj to z liczbą tranzystorów w całym sterowniczku opartym na procku
> jednoukładowym, to ci popkaże skalę prawdopodobieństwa awarii sprzętu:O)

Czlowieku, na kazdy temat na ktory sie wypowiadasz pokazujesz swoja
ignorancje. Prawdopodobienstwo awarii zalezy od procesu technologicznego
a nie ilosci tranzystorow. Taki AVR32 ma zblizone prawdopodobienstwo
awarii jak malutki 8-bitowy AVR. A kazdy z tych procesorow ma
wielokrotnie nizsze prawdopodobienstwo awarii niz np. kondensator czy
dyskretny tranzystor.

>> Jak wspomnialem wczesniej, jedynym problemem jest brak watchdoga -
>> mozliwe
>> ze producenci ITX o tym wkrotce pomysla. Tymczasem trzeba sobie cos
>> wlasnego wymyslic.
>
> wątpię, bo w PC sam restart nie musi rozwiazać problemu, wiec i sensu
> stosowania brak:O(

Jasne, dlatego np. sprzedawane w setkach milonow egzemplarzy routerki/AP
z linuxem na pokladzie wg ciebie nie maja prawa dzialac.
Jak dla mnie EOT.

do góry

> rozumiesz aktu że im język jest wyższego poziomu tym programista ma
> mniejszą kontrolę nad kodem?:O)
> np: taka zwykłą pętla for w C, wiesz ile z tego kompilator robi instrukcji
> asemblera?:O) jak sprawdzisz to przynajmniej dędziesz wiedział ile tam
> jest śmiecia

Programowanie to nie tylko zadanie napisania kodu który raz zadziała,
przejdzie 2 proste testy i już. Kod często ma też sprawdzać zakresy
oczekiwanych
danych i wyników aby wyłapywać ewentualne inne mniej oczywiste błędy
przetwarzania.
Samo dodawanie czy pomnożenie to nie wszystko. Sprawdzanie zakresu wyniku,
przekroczenie tabeli
itd jest ważnym elementem prawie każdego programu. Jesli tego nie robisz w
swoich programach to
są one marne. Nawet nikt nie wie, że występują błędy i wychodzą bzdurne
wyniki.
Stąd takie proste x+y może być obudowane większym sprawdzonym kodem
kompilatora czy biblioteki.


>> Jaka niewiedza? Co mnie obchodzi jak dziala jakas funkcja. Mam funkcje
>> biblioteczna, ktora realizuje np. x+y i nie ma dla mnie znaczenia jak ona
>> to robi, byle to robila.
>
> no włąśnie, co ciebie obchhodzi, tak samo co ciebie obchodzi ze
> oprogramowanie jest niestabilne i z masą śmieci skoro jest poprawnie
> napisane:O(

Czepiasz się niesłusznie. Nie musi go obchodzić efektywność kodu
który wykonuje się sporadycznie, ważniejsza jest wtedy jego pewność
poprawności działania. A poprawność kodu na pewno jest wyższa z kompilatora
C
niż wklepanego ręcznie w asm. Ilość błędów jest związana z ilością linijek
kodu,
im prostrzy i czytelniejszy zapis tym mniej pomyłek.

Także optymalizacja kodu to inne zadanie kiedy piszesz prosty program dla
prostego 8 bitowca
i możesz to zrobic ręcznie niż kiepski C, a inne kiedy tworzysz kod dla
robudowanych
procków mających mnóstwo schematów adresowania i dla których kompilator
szuka optymalnego kodu, wykorzystania banków rejestrów , analizuje i
eliminuje martwy kod,
itd

> nic do tego programu nie pisałem, pisałem włąsny program w C o
> funkcjonalności podobnej do tamtego programu w asemblerze, dlatego wiem
> jaka byłą między nimi róznica w wydajnosci
>...
> jeśli coś można zrobić sprzętowo to lepiej to będzie działąć sprzętowo,
> ale czy ty myślisz ze grafika 3D to tylko gry PC? nie każda grafika ma
> zwiazek z przetwarzaniem obrazu, często są to czasochłonne filtracje,
> sploty, operacje na wielkich macierzach i tym poodbne, pod które nikt
> sprzętu masowo nie produkuje

Pisałem kiedyś program w C - implementując prosto dla próby własne FFT a
następnie
skorzystałem z gotowej biblioteki intela - była ona ponad 10 x szybsza od
mojego kodu,
ale to nie zasługa języka programowania tylko wykorzystania wbudowanych
zaawansowanych
instrukcji sygnałowych procka!. Jest ich teraz tak dużo i są związane
ściśle z konkretnymi
prockami, w kazdym są inne zestawy, że sami ani w asm ani w C tego nie
oprogramujemy -
biblioteki tworzy producent procków i ma popisane różne kawałki dla różnych
procków..

Takie filtry i inne o których piszesz właśnie mają piękne wsparcie sprzętowe
(SIMD) w procesorach.


zbyszek

do góry

gargamel pisze:
> Użytkownik "Mario" napisał:
>> Załóżmy, że jesteś w stanie napisać krótszą pętlę niż wygenerowana z C
>> przez kompilator. Ale musisz napisać znacznie więcej kodu, we którym
>> masz znacznie większe szanse pomylić sie. A pętla w C jest prosta jak
>> konstrukcja cepa.
>
> tak, wiem że kod w C jest piękny, te wszystki odstępy, tabulatory,
> komentarze, wszystko tak piękne że tylko podziwaić i takie proste,
> dlatego stosuje sie języki wysokopoziomowe, ale jest dróga strona,
> kosztem łątwizny jest niestabilnosć, bnłęduy io brak kontroli,

Ja widzę u ciebie błędy io :)
Kod w asemblerze też może być piękny z tabulatorami i komentarzami.
Kod w języku wysokopoziomowym jest przede wszystkim zwięzły. Fakt
pisania w C (i automatycznej generacji kodu wynikowego) nie jest
przyczyną niestabilności i błędów io. Systemy operacyjne pisze się w C i
to jest najlepszym przykładem na to że jest to najlepsze rozwiązanie.
Nie sądzę żeby napisany w asemblerze system był stabilny i dawał się
rozwijać.

to są
> fakty a nie moje widzimisie, acha a co do błędów w kompilatoraach to
> każdy kto sie świeżo uczy jakiegoś języka to takie błędy znajduje w
> ilościach huirtowych na porządku dziennym:O(

Z reguły to nie są błędy kompilatora tylko brak wiedzy programisty. Jak
się przerzucisz z jednego kompilatora asm na inny to też będzie ci się
kompilacja sypać.

> acha, no i cały brak kontroli polega na tyum że nasz funkcję jako czarne
> pudełeczka, a wiec nie masz kontroli nad tym co w środku a włąsnie te
> nieprzewidywalnme błędy biorą się gównie z niewiedzy a nie z
> nieumiejętnosciu programowania

Czytasz opis funkcji i wiesz jak ona działa. Jak masz wątpliwości to
przeglądasz kod. Jeśli chcesz w c wysłać przez UART liczbę typu int to
użyjesz np printf("%d",a) - najpierw inicjując port
rprintfInit(uartSendByte). Nie musisz znać architektury. Aby to zrobić
w asm musisz napisać sobie konwersję bin > dec > ascii potem załadować
do bufora i dopiero potem uruchomić procedurę wysyłania przez UART. W
każdej z tych procedur musisz pilnować jakie wartości odłożyć na stos
jakie rejestry użyć itp. Jednym słowem nawet do trywialnych operacji
matematycznych musisz znać dokładnie architekturę. Trudno jest ci
dołączyć kod z biblioteki - zwłaszcza pisany przez kogoś innego a w
dodatku gdy przechodzisz na inny procek to trzeba wszystko przepisywać
od nowa.
>
>> Przecież ty pisząc w asemblerze też nie interesujesz się jak to jest
>> realizowane na poziomie mikrokodu.
>
> przecież instrukcje w asemblerze to jest wąłśnie mikrokod (jedna
> instrukcja jest zamieniana na ciąg zer i jedynek

Jedna instrukcja już jest ciągiem zer i jedynek :)

(i dokłądnie wiesz na
> jaki a jak znasz arhitekturę to i wiesz jak te instrukcje są wykonywane)

Doczytaj o mikrokodzie i zastanów się czemu np. w prockach typu CISC
cykl maszynowy składa się z kilku cykli zegarowych.

>
>
> p.s. zboczyło sie trochę z tematu a wiec do sterowania wentylatorem mo
> zna kupić sobie taki mały sterowniczek mieszczący się w puszce
> eleltrycznej 9mozliwy do programowania z PC, kupujesz, programuijesz,
> podłączasz i zapominasz:O)

Można też kupić mieszczące się w puszce sterowanie światłem czy roletami
a to wszystko na pilota radiowego.


--
Pozdrawiam
MD

do góry

gargamel pisze:
> Użytkownik "T.M.F." napisał:
>> No wiem. Tak sie sklada, ze np. gcc robi petle tak optymalnie jak w
>> assemblerze.
>
> no więc na ile komend asemblera kompilator gcc kompiluje pętlę for?
> bo w asemblerze wystarczą dwie, trzy instrukcje

Pod warunkiem, że w pętli będzie inkrementacja/dekrementacja o 1 a
licznik ma wielkość równą długości słowa danych.

>
>> Gratuluje, napisac program o funkcjonalnosci kilku MB w assemblerze i
>> nie pamietac jak sie nazywal... Moze czas zaczac brac Nootropil.
>
> ojej, czytaj za zrozumieniem, nie pisałem w asemblerze, pisałem w C i
> mój program w C miałem okazję porównać z programem w asemblerze (jego
> nazwa ani kto go napisał wsale mnie nie interesowało)

Może nie potrafiłeś wydajnie pisać?

--
Pozdrawiam
MD

do góry

gargamel pisze:
> Użytkownik "Madz" napisał:
>> A jak plyte sz.. trafi, to tak samo moze mi w mikroprocesorowym
>> sterowniku poleciec procek.
>
> to teraz policz ile w tym procku PC jest milionów tranzystorów, dodaj do
> tego resztę milionów tranzystorów w płycie głównej i podzespołąch i
> porównaj to z liczbą tranzystorów w całym sterowniczku opartym na procku
> jednoukładowym, to ci popkaże skalę prawdopodobieństwa awarii sprzętu:O)


Jednoukładowiec (np ARM9) może mieć więcej tranzystorów niż stary PC. Np
XT :) Sądzę że bardziej bardziej złożony system, może być jednocześnie
bardziej bezawaryjny.

>
>> Jak wspomnialem wczesniej, jedynym problemem jest brak watchdoga -
>> mozliwe
>> ze producenci ITX o tym wkrotce pomysla. Tymczasem trzeba sobie cos
>> wlasnego wymyslic.
>
> wątpię, bo w PC sam restart nie musi rozwiazać problemu, wiec i sensu
> stosowania brak:O(

Dlaczego? Zwisy mogą być spowodowane losowym błędnym odczytem danych z
pamięci RAM lub HDD lub np wyciekiem pamięci i zajęciem wszystkich
zasobów po dużym uptime. Reset sprzętowy często ratuje sytuację.

--
Pozdrawiam
MD

do góry

Użytkownik "Mario" napisał
> Systemy operacyjne pisze się w C i to jest najlepszym przykładem
> na to że jest to najlepsze rozwiązanie. Nie sądzę żeby napisany w
> asemblerze system był stabilny i dawał się rozwijać.

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


> Czytasz opis funkcji i wiesz jak ona działa. Jak masz wątpliwości to
> przeglądasz kod.

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ć,


> Doczytaj o mikrokodzie i zastanów się czemu np. w prockach typu CISC cykl
> maszynowy składa się z kilku cykli zegarowych.

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

do góry

Użytkownik "T.M.F." napisał:
> Skoro to sa fakty to z latwoscia podasz przyklady w literaturze,
> ktore je potwierdzaja.

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)

do góry

Użytkownik "zbyszek" napisał:
> Sprawdzanie zakresu wyniku, przekroczenie tabeli itd jest ważnym
> elementem prawie każdego programu. Jesli tego nie robisz w swoich
> programach to s? one marne. Nawet nikt nie wie, że występuj? błędy i
> wychodz? bzdurne wyniki. St?d takie proste x+y może być obudowane
> większym sprawdzonym kodem kompilatora czy biblioteki.

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)


> Czepiasz się niesłusznie. Nie musi go obchodzić efektywno?ć kodu
> który wykonuje się sporadycznie, ważniejsza jest wtedy jego pewno?ć
> poprawno?ci działania.

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


> Pisałem kiedy? program w C - implementuj?c prosto dla próby własne FFT a
> następnie skorzystałem z gotowej biblioteki intela - była ona ponad 10 x
> szybsza od mojego kodu,

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

do góry

Użytkownik "Mario" napisał:
> Pod warunkiem, że w pętli będzie inkrementacja/dekrementacja o 1 a licznik
> ma wielkość równą długości słowa danych.

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


> Może nie potrafiłeś wydajnie pisać?

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)

do góry