gargamel wrote:
> Użytkownik "T.M.F." napisał:
>> A po co ci to wiedziec?
>
> no właśnie w tym stwierdzeniu jest całą prawda o językach
> wysokopoziomowych, nie wiedzieć jest łatwo,

Jak 'nie wiesz' to i w C/C++/C#/VB nie napiszesz.

> wygodnie, łatwiej nauczyć
> się języka C raz na całę życie niż architektury i asemblera kolejnych
> uP-uf, ale ceną tej łatwości jest to że potem taki windows, czy linux
> sie zawiesza, programy sie zawieszają nie wiedzieć dlaczego,

Mam kilka kompow windzianych i z linuxem - musza byc zepsute bo sie nie
chca wieszac (uptime po pol roku jest).

> a nawet
> telefony komurkowe się zawieszają (i reset nie pomaga)

Jak masz miesiac na soft to nic dziwnego. Z asm w ogole nie byloby
telefonu, bo soft by sie pisal 2 lata.

> dawniej gdy
> sprzęt był programowany w asemblerach coś takiego się w głowie nie
> mieściło żeby telefon mógł się zawiesić, a mam w domu taką starą
> dwóekranową gierkę (donkey kong) i w życiu sie nie zawiesiła, cuda
> jakeiś czy co?:O)

Roboczogodzina 20 lat temu miala inna wartosc niz teraz.

> kompilatopr może nie mieć błędów, chodzi o brak kontroli) a własnie
> niewiedza jest przyczyną błędów, dodatkowo oprogreamowując sprzęt
> urzywasz sterowników producenta i też używasz funkcji wysokopoziomowych,
> czyli też nie masz pojęcia jak dana instrukcja jest wykonywana, znowu
> nie masz kontroli i dupa blada

Ja tam mam kontrole.

>
>
>> Podaj nazwe. I nie twierdze, ze nie mozna, to po prostu jest bez sensu.
>
>
> nazwy nie pamiętam, zresztą jak programu na oczy nie widziałeś to i
> nazwa nic ci nie powie

Po opisie kilku mega w asm to ja juz bym znalazl ten program - zeby go
zobaczyc.

>, a sens ma to ogromny, bo program który pisany
> wysokopoziomowo nie ma szans na działąnie w czasie rzeczywistym na nowym
> super sprzęcie, napisany w asemblerze tylko śmiga na starych piernikach,
> wiec sens jest, jest nim wydajnosć i niezawodność,
> p.s. do tego programu 3D to pamiętam jak sam pisałem w C takie funkcje i
> wiem że jedna klatka takiego obrazu zajmowała nowemu PC 10 minut a bryła
> 3D skąłdała się z kilkuset takich klatek, więc taka obróbka trwała setki
> godzin, dlatego byłem ogromnie zdziwiony gdy program napisany w
> asemblerze działąjacy na starym peirniku robi to samo w czasie
> rzeczywistym i jeszcze w czasie rzeczywistym obraca taką bryłę i ją kroi
> w dowolnej płaszczyźnie, więc różnica w wydajnosci między językami
> niskopoziomowymi a wysokopoziomowymi jest OGROMNA i im język jest
> wyższego poziomu to jego wydajność drastycznie spada!

Tutaj to juz bzdury piszesz. Dobrze napisany program w C nie rozni sie
niczym od asemblera. No, oczywiscie trzeba wiedziec jak kompilator
ustawic, jakie konstrukcje w C uzyc itp. Ja np: nie pisze juz czasowo
krytycznych przerwan w asemblerze (dla prockow w ktorych znam
kompilator). Bardzo czesto napisanie w C wystarcza - jeden rzut oka na
wynik w asm i stwierdzam ze nie da sie szybciej.

A co do Twojego 3D - wiesz, algorytmy przyspieszaja dzialanie wielu
programow duzo bardziej niz rozne kompilatory.

>
>> masz szanse napisac cos szybciej w assemblerze... masz niezle ego :)
>
> jakie ego? to oczywisty fakt że pisząc w asemblerze na tym samym
> sprzęcie program będzie o niebo szybszy od pisanego wysokopoziomowo, ale
> ja tego nie będę pisał bo mi za to nie płącą:O)

Jak programista dupa to oczywisty fakt. Jak wie co robi, to mozesz sie
zdziwic.

--
Jerry1111

do góry

>> Nie wiem po co uczyć się historii. Lepiej nauczyć się jak udostępniać
>> sterowanie/pomiar przez Apache/PHP, Tomcat czy Ajax. A to już wymaga
>> współczesnego systemu operacyjnego.
>
> Nie o to chodzi, by uczyć się historii... Ale jeżeli człowiek sam jest
> historią, to łatwiej mu zaprogramować stary PC aniżeli przesiadać się na
> siakieś mikrocuda i/lub uczyć Ajax'a tudzież PHP. Mówię oczywiście
> spoglądając na sprawę z mojej własnej perspektywy. :-P

Zapewne tak jest. Ale za $100 mozesz kupic plytke np. ANGW100 z
32-prockiem, Linuxem na pokladzie, USB, 2xeth itd. ktora jest mala,
zuzywa pare watow, a programujesz to sobie wygodnie chociazby na PC, po
czym tylko rekompilujesz program na cross-kompilatorze i wrzucasz do
tego sterownika. Jesli umiesz programowac, rozumiem, ze znasz cos w
stylu C/C++ to to czy to bedzie DOS, czy Linux nie robi roznicy.
Kompatybilnosc zapewniaja biblioteki systemowe.

>
> Dawno temu nauczyłem się programować w DOS, i nie będąc zawodowym
> programistą/eletronikiem nie mam wcale ochoty próbować/uczyć się czegoś
> nowego w tym zakresie. To, czega nauczyłem się kilkanaście lat temu w
> zupełności mi wystarcza.
>
> Jeżeli ktoś dopiero uczy się i szuka rozwiązań, rzeczywiście równie dobrze
> mógłby próbować tych obecnych nowości (AVR, Tomcat, itd, itp...).

Zapewne, niechec do nauki to jest argument:) Ale nie zmienia to faktu,
ze sterowanie paroma przekaznikami za pomooca PC to strzelanie z armaty
do muchy.

do góry

gargamel pisze:
> Użytkownik "T.M.F." napisał:
>> Zawiesza sie bo jest napisany w jezyku wysokiego poziomu? Masz jakas
>> literature na poparcie tej tezy?
>
> oj zaraz byś chciał literaturę kjtóra by zaciebie pomyślała, naprawdę
> nie 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

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. Nawet jeśli kod wynikowy jest troszkę dłuższy to jest
wygenerowany automatycznie i małe są szanse żeby zawierał błąd. Zdarza
się, że kompilatory zawierają błędy ale dość szybko są wykrywane łatane.
Zakładam, że bardziej niezawodna jest zbiorowa praca programistów od
avr-gcc niż rzeźbienie rozbudowanego projektu przez programistę
asemblerowego. Sam od dawna pisałem w asemblerze ale przy okazji
przejścia na nowe procki przerzuciłem się na C. Nigdy więcej pisania w
asemblerze obliczeń zmiennoprzecinkowych na logarytmach :) Będzie
konieczność przyspieszenia jakiejś obsługi przerwania to najwyżej
przepiszę kawałek kodu w asemblerze ale jeszcze nie miałem takiej potrzeby.

>
>> 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(

A skąd wniosek że jeśli go nie obchodzi jak funkcja działa to znaczy że
go nie obchodzi stabilność kodu wynikowego. Przecież ty pisząc w
asemblerze też nie interesujesz się jak to jest realizowane na poziomie
mikrokodu. Skoro tego nie wiesz to może twoje instrukcje są zamieniane
na błędne mikroinstrukcje?
>



--
Pozdrawiam
MD

do góry

>> Zawiesza sie bo jest napisany w jezyku wysokiego poziomu? Masz jakas
>> literature na poparcie tej tezy?
>
> oj zaraz byś chciał literaturę kjtóra by zaciebie pomyślała, naprawdę
> nie rozumiesz aktu że im język jest wyższego poziomu tym programista ma
> mniejszą kontrolę nad kodem?:O)

Nad swoim kodem ma taka sama. Nie ma kontroli nad kodem bibliotek,
ktorych uzywa i o to chodzi. Dowolna biblioteka systemowa jest lepiej
przetestowana niz to co sam napiszesz. Ergo - mniej bedzie bledow jesli
korzystasz z kodu bibliotek niz piszesz samemu. Jesli uwazasz inaczej to
znaczy, ze jestes lepszym programista niz setki osob, ktore zawodowo te
biblioteki pisaly i wylapujesz bledy lepiej niz pewnie setki tysiecy
testerow/programistow, ktorzy je wykorzystywali.
Gdyby bylo tak jak piszesz to w kazdej ksiazce na poczatku byloby
ostrzezenie, zeby nie uzywac jezykow wysokiego poziomu. A jest dokladnie
odwrotnie, w kazdej ksiazce znajdziesz stwierdzenie, ze lepiej pisac np
w .NET niz assemblerze.

> 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

No wiem. Tak sie sklada, ze np. gcc robi petle tak optymalnie jak w
assemblerze.

>> 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(

Pokasz jakies zrodla na potwierdzenie tej tezy.

>> Pisales procedury do takiego programu 3D i nie pamietasz jego nazwy?
>> Wez nie sciemniaj.
>
> 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

Gratuluje, napisac program o funkcjonalnosci kilku MB w assemblerze i
nie pamietac jak sie nazywal... Moze czas zaczac brac Nootropil.

>> Wez sie nie osmieszaj. Masz np. funcje realizujaca np. pomniejszenie
>> fragmentu obrazu z antyaliasingiem. Realizowana jest ona sprzetowo
>> przez GPU, jaka bedzie roznica czasu wykonania jesli wywolam ja
>> programujac bezposrednio GPU, albo wywolujac przez funkcje GDI?
>> Podpowiem, zadna.
>
> jeśli coś można zrobić sprzętowo to lepiej to będzie działąć sprzętowo,

Tak, bo w sprzecie nie ma bledow. Czy ty wiesz, ze np. w takim Pentium
instrukcje sa tlumaczone na mikrokod, a nie sa realizowane sprzetowo?

> 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

Nie? A widziales np. C.U.D.A. dla NVidii? Widze, ze zahibernowales
jakies 20 lat temu i sie jeszcze nie obudziles. GPU to juz od lat nie
jest po prostu bufor ramki, tylko zestaw rownoleglych procesorow
realizujacych obliczenia matematyczne tysiace razy czybciej niz CPU.
BTW, NVidia masowo produkuje sprzet.

do góry

Dnia Wed, 11 Feb 2009 14:11:31 +0100, gargamel napisał(a):

> Użytkownik "Madz" napisał:
>> Dlaczego?
>
> bo on chce sterować centralką wentylacyjną a wiec wymaganba jest
> niezawodnosć, nice chcesz chyba żeby chłop w nocy sie zadusił bo linux się
> zawiesił, albo spuchły kondensatorki na płycie głównej:O)
>
>
Kolega pisal, ze szuka jakiejs przystawki - wiec uP + iles przekaznikow +
podpiecie tego przez RS232 do komputera. Dodatkowo, jesli zastosuje RS485
to moze miec iles takich ukladow.
Testuje obecnie PC na mini-ITX - chodzi nieprzerwanie na windowsie xp od
polowy listopada. W tym czasie mial jeden restart (nie bylo pradu), a nie
ma jeszcze upsa . Docelowo mozna zoptymalizowac windowsa wykorzystujac jego
wersje embedded - zabezpieczyc glowna czesc przed zapisem (sa takie
mozliwosci, nawet m$ je udostepnia). Mozna tez sie bawic na linuxie jak kto
woli. Jesli sterujemy czyms niekrytycznym, to na pewno przez zawieszenie PC
tragedia sie nie stanie. A jak plyte sz.. trafi, to tak samo moze mi w
mikroprocesorowym sterowniku poleciec procek.


> stanowczo przesadziłeś, stabilność PC jest praktycznie żadna, bo tam nie
> masz żadnej kontroli nad oprogramowaniem i sprzętem i nawet restart nie
> zawsze pomoże
>

praktycznie zadna stabilnosc PC - to gruba przesada z Twojej strony.
Zreszta wiele kwestii poruszyl juz w oddzielnej galezi tego watku kolega
T.M.F.

> sterowniki na mikrokontrolerach programujesz w asemblerze (całkowita
> kontrola nad kodem), masz rozdzielenie pamięci programu i danych i takei tam
> (całkowita odpornosć na wirusy i błędy)

calkowita z dokladnoscia do bledu programisty. Jak mamy juz np komunikacje
po TCP, to sie zaczynaja schody - w jezykach wyzszego poziomu jest mnostwo
gotowego, przetestowanego kodu.


>
> uP ma licznik wachdog który kontroluje awarie, a restart trwa pojedyńcze
> sekundy, a nie minuty jak w PC, no i żre pojedyńcze waty energii (a nie
> setki W jak PC) i kosztuje pojedyńcze setki złotych (a nie tysiace jak PC)

Poczytaj o zuzyciu energii przez konstrukcje na ITX. Oprocz mini-itx, jest
jeszcze chocby pico-itx. Zuzycie pradu jest i tak wieksze od uP, ale nie
mowimy tutaj o systemach zasilanych z baterii i jesli taki uklad steruje
szeregiem stycznikow/przekaznikow/elektrozaworow - to pobor pradu przez nie
bedzie o rzad wielkosci wiekszy anizeli komputera ITX (u mnie sredni pobor
to ok 9 wat, a korzystam z dysku 2.5 cala) - jesli skorzystac z pamieci
flash - to zyskamy kolejne 3waty.
Jak wspomnialem wczesniej, jedynym problemem jest brak watchdoga - mozliwe
ze producenci ITX o tym wkrotce pomysla. Tymczasem trzeba sobie cos
wlasnego wymyslic.


m.

do góry

Dnia Fri, 13 Feb 2009 18:09:09 +0100, gargamel napisał(a):

> ... ale ceną tej łatwości
> jest to że potem taki windows, czy linux sie zawiesza, programy sie
> zawieszają nie wiedzieć dlaczego, a nawet telefony komurkowe się zawieszają
> (i reset nie pomaga) dawniej gdy sprzęt był programowany w asemblerach coś
> takiego się w głowie nie mieściło żeby telefon mógł się zawiesić, a mam w
> domu taką starą dwóekranową gierkę (donkey kong) i w życiu sie nie
> zawiesiła, cuda jakeiś czy co?:O)
>

Zawieszaja sie nie dlatego, ze sa pisane w jezyksach wysokiego problemu,
ale dlatego ze producenci sie spiesza - kiedys nowy model komorki wychodzil
raz na rok, dzisiaj w miesiacu mamy parenascie nowych modeli albo i wiecej
- a testy tego co napisali programisci sa przeprowadzane na uzytkownikach.
Liczy sie kasa - zeby cos szybko sprzedac, a nie stabilnosc. Gdyby jezyki
wysokopoziomowe byly takie zle jak mowisz, to przy zlozonosci dzisiejszych
systemow z jakich dzis korzystamy mielibysmy restart co minute.


m.

do góry

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


> 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)

do góry

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


> 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 (i dokłądnie wiesz na jaki a jak znasz
arhitekturę to i wiesz jak te instrukcje są wykonywane)


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)

do góry

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)


> 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(

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, to są
> fakty a nie moje widzimisie, acha a co do błędów w kompilatoraach to

Skoro to sa fakty to z latwoscia podasz przyklady w literaturze, ktore
je potwierdzaja.

> każdy kto sie świeżo uczy jakiegoś języka to takie błędy znajduje w
> ilościach huirtowych na porządku dziennym:O(

Jasne. Bredzisz.

> przecież instrukcje w asemblerze to jest wąłśnie mikrokod (jedna
> instrukcja jest zamieniana na ciąg zer i jedynek (i dokłądnie wiesz na
> jaki a jak znasz arhitekturę to i wiesz jak te instrukcje są wykonywane)

Znowu palnales. Poczytaj czym jest mikrokod.

do góry