Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Funkcja _delay_us(double us); - jak działa?

dziechu 23 Sie 2010 16:40 4385 53
  • #31
    dziechu
    Poziom 27  
    No właśnie też o to chodzi - sprzęt, przecież mam np. gotowe biblioteki wyświetlaczy graficznych dla różnych procesorów, w zewnętrznych plikach. Zamiast KS0108AVR.c podstawiam KS0108PIC.c i już, no jeszcze w pliku KS0108PIC.h podstawić nazwy portów.. Jasne że trzeba ustawić inaczej timery itp. ale to jest kilkanaście linijek na początku programu. Także odwołania np. do portów procesora w programie głównym jest identyczne (typu portx &= 0x0f;) i zadziała tak samo, co najwyżej nazwy portów trzeba podstawić. Tak czy inaczej widzę że plik główny da się w 15min. dostosować - ustawienia timerów, ADC itp. mam na początku, funkcje obsługi przerwań na końcu, nie muszę biegać po całym pliku i szukać, nie wspominając że w C sam listing jest 4x krótszy.
  • #32
    mirekk36
    Poziom 42  
    Dokładnie jak piszesz - a jak już człowiek się uprze i musi raz z tego a raz z innego procka korzystać i często takie zmiany zachodzą - to można w celu "przeportowania" kodu nawet jakieś od razu #define'y wymyśleć i poustawiać tak aby jeszcze więcej rzeczy się automatycznie działo jeśli chodzi nawet o sam sprzęt ;)
  • #33
    Użytkownik usunął konto
    Użytkownik usunął konto  
  • #34
    mirekk36
    Poziom 42  
    albertb --> nikt nie pojeździł a przynajmniej ja nie miałem takiego zamiaru, tylko chciałem zwrócić uwagę na oczywiste różnice. Podyskutować chyba zawsze można?

    A ten przykład , który kolega podał jest bardzo nieszczęśliwy i wręcz wg mnie kolega sam przeczy sobie i strzelił trochę jak kulą w płot niestety. Nie chodzi przecież o jakieś czasem nawet specyficzne funkcje biblioteczne danego kompilatora dla danego procka. Tu chodzi o podstawowe zawsze UNIWERSALNE konstrukcje języka C jak chociażby wszelkiej maści pętle, ale także podstawowe działania na stringach, obliczenia, typy danych itp - w tym drzemie potęga a nie w tym, że na jednym procku będzie _delay_ms() a na innym delay_ms(). A nawet gdyby to hyhyhy tylko dodanie podkreślnika.

    Tymczasem co ma wspólnego z przeportowaniem makrodefinicja w asemblerze - tu chyba się coś wręcz koledze pomyliło! To makrodefinicja makrodefinicją - ale na każdy procek musisz jej ciało całkiem inaczej napisać w asemblerze - więc co ty tu porównujesz w ogóle ???

    Nawet jak będziesz miał pod ręką makrodefinicje już takie przygotowane pod AVR i PIC to gdy będziesz chciał odpalić to na ARM czy innym - to będziesz musiał zbudować ją CAŁKOWICIE OD NOWA - czyż nie??? nie zgodzisz się z tym? tymczasem zajrzysz do kompilatora jakiegoś kompilatora C na ARM i okaże się, że będzie dostępna np __delay__ms() no i co ??? dodanie dodatkowych podkreślników równa się pisaniu jej kodu od nowa ???? szoczek

    Dodano po 3 [minuty]:

    Proszę bardzo powiedz mi jak będą wyglądały twoje makrodefinicje w asemblerze dla jakichś obliczeń ciut bardziej skomplikowanych - matematycznych w asemblrze na różnych prockach . Np logarytmy itp .... jesteś w stanie w kilka sekund napisać program wykorzytujący takie obliczenia na różne procki w asm ??? myślę że nie - a znając C - TAK!

    Nie wspomnę już o kurczę z pozoru głupich pętlach, warunkach , obsłudze stosu i wielu innych tego typu. Człowieku jak ty to w prosty i szybki sposób poprzenosisz z jednego asm na inny asm, którego dopiero pierwszy raz na oczy zobaczysz ??????

    A w C - proszę bardzo przenosisz BEZ ŻADNYCH NAJMNIEJSZYCH czasem przeróbek

    więc o czym my mówimy?
  • #35
    dziechu
    Poziom 27  
    :) Dyskusja jakby poszła w różnych dziwnych kierunkach. Moje pytanie było proste - czy można jako wartość argumentu funkcji delay podać np. 11.25. Można, o to mi chodziło i właściwie temat do zamknięcia. Tymczasem można tu przeczytać że delay jest wogule do d... i stosować tylko sprzętowe timery, albo że ktoś tam potrafi szybciej konwertować programy w ASM na różne procesory niż w C (???) itd. Niepotrzebnie! Poza tym napisałem program w C w tydzień, a ten sam program w asm pisałem miesiąc, bo po prostu jest mniej pisania i liczenia i temu nie można zaprzeczyć. Piszę a = b - c; a jeżeli chcę z duża precyzją to abc deklaruję jako float albo double i nie przejmuję się że mam do odjecia liczby które mieszczą się w ośmiu bajtach, że każdy muszę załadować, odjąć, sprawdzić przepełnienie itd... No po prostu nie rozumiem dyskusji:) Delay w 99% używa się z wartościami int, a jeżeli w jednym miejscu programu jest to 11.25, to nie jest to aż tak duży problem przy przenoszeniu oprogramowania. Jestem przekonany że mogę swój program w C przenieść na PIC w ciągu jednego dnia. W ASM posiedziałbym przynajmniej tydzień i to raczej nie z braku umiejętności;)
  • #36
    mirekk36
    Poziom 42  
    dziechu --> no ale zrozum człowieka. Sam pisałeś, że ileś tam lat pisałeś tylko w asm i ciężko ci było się zabrać za C. Zawsze to odkładałeś - czy to po części nie z tych samych powodów? obaw? itp

    Myślę, że ta dyskusja wcale nie jest taka niepotrzebna bo może pokazać i innym, że jednak warto się zainteresować C szczególnie że przekonuje się tu o tym ktoś kto już od wielu lat pisał tylko w asemblerze ;)

    ale nie martw się, ze mną było dokładnie tak samo kilka lat temu. Też chyba z 7 razy podchodziłem u rzucałem naukę C. Udało się chyba za 8 razem i jak zassałem to aż wir powstał. Co wcale nie oznacza, że pożegnałem się z asemblerem przecież bo to byłoby bez sensu. Jako wstawki - asembler - jak najbardziej się przydaje.

    Więc może i kolega albertb - w końcu za którymś razem da się namówić na C ? ;)
  • #37
    dziechu
    Poziom 27  
    Dodam jeszcze tak - najpierw nie chciałem pisać tego programu w C, ale uzupełnić ten w asm o możliwość wyliczenia między innymi log10(a/b) z dokładnością lepszą niż 2 miejsca po przecinku, bo w jednostkach logarytmicznych moje urządzenie wyświetla wyniki. Nie znalazłem gotowych bibliotek zmiennoprzecinkowych w asm (może masz???). Kompilator C takie oblliczenia robi używając 1.6kB kodu, więc jak widać to dość skomplikowane obliczenia i napisanie takich funkcji od zera kosztuje sporo czasu. Obsługę wyświetlacza na KS0108 pisałem w asm od zera. Na PIC w asm też musiałbym pisać od zera (nie znalazłem gotowców), a w C? Proszę bardzo, 10min. w Googlach i mam biblioteki w C dla KS0108 dla AVR, dla PIC, dla '51 i kilku innych.... razem z zestawami różnej wielkości czcionek itp... no po prostu nie ma o czym mówić. Ja też broniłem asm i bronię tylko w jednym aspekcie - pełna kontrola nad sprzętem, w 100%, do jednego cyklu zagarowego i każdego pinu procesora. Tu w C coś piszę i nie bardzo wiem co mi z tego robi kompilator (choż jak widzę bardziej doświadczeni też to kontrolują:) No ale jeżeli program działa, piszę go 4x szybciej, mam dostęp do rozmaitych bibliotek, przykładów, to mogę poświęcić tą żądzę pełnej kontroli:)

    Dodano po 5 [minuty]:

    Mirek, masz 100% racji, podchodziłem kilka razy do C już kilka lat temu, bo jednak filozofia jest zupełnie inna i jakoś nic nie kumałem. Jednak tym razem sie nie poddałem, zawsze przychodzi taki przełom - nagle załapuje sie nie jakiś pojedyńczy rozkaz, ale właśnie filozofie, strukturę, w pewnym momencie widzi się jakby całość i wtedy natsępuje zaskok, a od tego momentu to już nauka idzie piorunem i z przyjemnością:)
  • #38
    mirekk36
    Poziom 42  
    dziechu napisał:
    Tu w C coś piszę i nie bardzo wiem co mi z tego robi kompilator (choż jak widzę bardziej doświadczeni też to kontrolują:) No ale jeżeli program działa, piszę go 4x szybciej, mam dostęp do rozmaitych bibliotek, przykładów, to mogę poświęcić tą żądzę pełnej kontroli:)


    Grzeszysz bo nie wiesz co mówisz ;) Takie teorie o tym, że w C nie masz pełnej kontroli bo kompilator coś tam sobie robi - to zwykle właśnie opowiadają początkujący adepci C. Sam zresztą zauważasz że bardziej doświadczeni jakoś to kontrolują. Otóż można i to w pełni a jak trzeba to choćby w krytycznych sytuacjach za pomocą wstawek asm - ale szybko sam zobaczysz, że rzadko oooj rzadko będziesz po nie sięgał. A że nie masz takiego podejścia jak wielu początkujących w programowaniu, że jak coś im nie wychodzi to od razu procek do d..., albo kompilator do d.... albo w ogóle wszystko inne tylko nie ja - to szybko przejdziesz w C ten okres bolączek. Trzeba tylko poczytać co i jak robi kompilator to wtedy będziesz wiedział co w trawie piszczy. Nie mówiąc już że masz od razu po każdorazowej kompilacji podglą tego co zrobił z pięknymi opisami w asemblrze !!! Więc dla osoby, która już zna asm to samo miodzio. Myślę że też się złapiesz przy takim podglądaniu kodu tego co robi kompilator - w asm sam nieraz robiłeś pewne rzeczy na tzw "okrętkę" podczas gdy można o wiele prościej. Przecież myśleli nad tym m.inn twórcy sławnego czy niesławnego w tym temacie delay'a ;)
  • #40
    mirekk36
    Poziom 42  
    dziechu napisał:
    ...., podchodziłem kilka razy do C już kilka lat temu, bo jednak filozofia jest zupełnie inna i jakoś nic nie kumałem. Jednak tym razem sie nie poddałem, zawsze przychodzi taki przełom - nagle załapuje sie nie jakiś pojedyńczy rozkaz, ale właśnie filozofie, strukturę, w pewnym momencie widzi się jakby całość i wtedy natsępuje zaskok, a od tego momentu to już nauka idzie piorunem i z przyjemnością:)


    oooo to chodzi, ja pomimo że już od kilku lat robię tylko w C to coraz bardziej żałuję że ten zaskok nie nastąpił u mnie dużo wcześniej Kurdę tyle czasu by człowiek zaoszczędził a przy okazji i kaski więcej zarobił ;)
  • #41
    dziechu
    Poziom 27  
    Mirek, to prawda. Trochę od drugiej strony zaczynałem bo musiałem - zamiast pisać małe fragmenty i je analizować itd... od razu musiałem napisać dość spory program, który pewnie będę jeszcze 100x poprawiał i optymalizował poznając lepiej C. To i tak dziwne, że łącząc naukę, pisząc pierwszy w życiu program w C od razu powstał dobrze działający i przetestowany odpowiednik tego co mam w ASM (ale z zaawansowaną matematyką:). Myślałem że uda mi się to za jakieś pół roku:)
  • #42
    mirekk36
    Poziom 42  
    hyhyhy sam pamiętam, gdy akurat kiedyś poznawałem nowy dla mnie asembler właśnie procków AVR (bo wcześniej to głównie dawno temu tylko asemblery 8051 czy Z80) i jak robiłem jakiś tam hobbystyczny projekcik:

    https://www.elektroda.pl/rtvforum/topic678948.html

    kurka wodna , chyba z miesiąc się (sorki za wyrażenie) pierniczyłem z tym w asemblerze. Tymaczasem teraz projekty tego prokroju skomplikowania to hmm w 2-3 godziny się trzaśnie w C i po zawodach. Ale właśnie nawet ucząc się na początku C - też byłem zdziwiony od razu bardzo szybkim efektem jeśli chodzi o czas napisania kodu w jakiejś tam nawet wstępnej wersji. A testowanie, uruchomienie i wypuszczenie do ew sprzedaży w porównaniu do asemblera skraca się w postępie chyba geometrycznym ;)
  • #43
    dziechu
    Poziom 27  
    Tak czy inaczej dziękuję wszystkim za pomoc, bo dzięki tutejszej pomocy wiele problemów rozwiązałem, a bez tej pomocy może znowu bym się poddał.
    Z80 to też był mój pierwszy, potem krótko '48 no i długo nowsze '51 (asm w zasadzie ten sam). Najbardziej wkurzały mnie PICe, AVR to już była sama przyjemność, jeżeli chodzi o asm.

    P.S. Ten projekt ładnie zrobiony:)
  • #44
    Użytkownik usunął konto
    Użytkownik usunął konto  
  • #45
    dziechu
    Poziom 27  
    Albertb, może w takim razie odnieś się do moich wypowiedzi - chciałem wstawić funkcje matematyczne do gotowego programu w asm. Funkcje która by liczyła log10(a/b) z np. trzema miejscami po przecinku, ok? I moje pytanie - masz gotowe biblioteki asm zmiennego przecinka? Bo ja nie znalazłem. Potrafiłbyś ewentualnie mi to napisać? Bo dałem ogłoszenie że zlecę napisanie takich procedur w asm na AVR - dwóch się zgłosiło i po wstępnych próbach zrezygnowało. Przyznam się, że pewnie zrobiłbym to sam, ale wysiłkiem i czasem duuuużo większym niż napisanie w C całego programu. Jeżeli kompilator C potrzebuje na takie obliczenia 1.6 kB kodu, to nawet choćby to robił bardzo nieoptymalnie, widać że nie są to procedurki na godzinę roboty, tak?

    No i jeszcze jedno - proszę, wyjaśnij jak to robisz, to portowanie asm avr na asm pic - bardzo mnie to ciekawi. Bo ja jedyną metodę jaką znam to na piechotę przepisywanie rozkazu po rozkazie z duuuuzymi zmianami dotyczacymi całkowicie innych architektur, sposobów działania rozkazów itd... Jeżeli program ma kilka tysięcy linii, to dla mnie jest po prostu masaaaaaaaakra! Mówiąc inaczej - nie znam takiego pojęcia jak portowanie asm avr na pic - po prostu pisze się program od nowa, czy nie? Jak Ty to robisz???
  • #46
    mirekk36
    Poziom 42  
    Panie alberb -> no wydawało mi się, że mówiąc o przenośności kodu to podstawowe znaczenie ma przenoszenie uniwersalnego kodu pomiędzy różnymi prockami różnych rodzin i nawet dla procków z którymi się pierwszy raz spotykamy.

    No nie będziemy teraz stawiali warunków granicznych kto szybciej co przeportuje i w jakim języku byle by to było na procki, które się zna od podszewki bo to bez sensu.

    I co z tego, że skorzystam z gotowych funkcji bibliotecznych??? skoro pewne funckje w C są już po prostu standardowe? Czy ty uważasz, że ja miałem na myśli, że będę w C sam pisał od początku i wyważał głową drzwi funkcje do obliczeń matematycznych, żeby się ścigać z kimś kto pisze w asm czy innym języku?

    Jeśli się nie zrozumieliśmy na początku to może ustalmy co leży u podstaw bardzo ogólnego pojęcia "przeportowania" programu jakiegokolwiek na inny - nawet nowy procesor dla którego masz kompilator C z jakimiś podstawowymi właśnie funkcjami bibliotecznymi. A nawet bez nich jeszcze raz powiem o pętlach, warunkach i obsłudze stosu i wiem co mówię.

    Nie chodzi mi wcale o przeportowywanie nawet jakichś cudzych programów. Mówię o tym co chociażby samemu się pisze.

    A jeśli ty będziesz się dalej upierał że w nowo poznanawanym asemblerze szybciej napiszesz jakiś tam nawet średni (kurdę wiem że bardzo ogólne pojęcie) program w asemblerze niż w C to chyba sam sie okłamujesz. Nie wspomnę już o dużych projektach.

    I nie mówię, że asembler jest do kitu itp, nie mam zamiaru rozpoczynać dziecinnej wojny n/t wyższości jednego języka nad drugim. Ci którzy wolą się męczyć w asemblerze to bedą się męczyć do końca życia. Chyba że kiedyś zaczną w C

    A jesli piszesz także w C - to na prawdę ta dyskusja staje się w ogóle bezprzedmiotowa bo nie wiadomo o co się sprzeczamy.
  • #47
    Użytkownik usunął konto
    Użytkownik usunął konto  
  • #48
    mirekk36
    Poziom 42  
    albertb napisał:
    I jeśli nie muszę to innych języków nie używam. Ale to nie powód, aby je gloryfikować na fałszywych przesłankach.


    Matko Boska, a myślałem że ty wiesz o czym mówisz? Sam się napierw uczepiłeś _delay'ów jak wiadomo kto i czego , makrodefinicji, których rzekomo nie trzeba przepisywać na inny asm (tak wynikia z twoich dziwnych pokrętnych już wypowiedzi) ... a teraz z jakąś fałszywą gloryfikacją wyjeżdżasz. Nie wspominając już o dziecinnych wręcz przechwałkach jak to ty wszystko "siam" w asemblerze jesteś w stanie szybciej od innych napisać. To się dopiero nadaje na temat fałszywej gloryfikacji. Żeby na końcu napisać, że jesteś fanem C i C++. To się kolega nagadał - tyle że wygląda, że sam ze sobą i trochę jakby bez sensu.
  • #49
    dziechu
    Poziom 27  
    albertb:)
    1. Jeżeli masz na wejściu programu dane wejściowe z czujnika liniowego, a wynik musisz przedstawić w jednostkach logarytmicznych, bo takie są powszechnie stosowane, to jak to robisz unikając FP???
    2. Każdy w miarę doświadczony programista potrafi, jak wspomniałem to kwestia czasu i wysiłku, czasem nie wartego zabawy.
    3. Nie bardzo rozumiem co Ci dają w tym wypadku makrodefinicje. Przechodząc na inny procesor musisz przepisać wszystko, łącznie z makrodefinicjami, stąd kilka tysięcy linii. Co iinego gdy masz takie na różne procesory i tu właśnie zaleta C - znajdziesz w necie w kilka minut, dla asm raczej musisz sam zrobić.
    Poza tym używasz pojęć 'dobrze napisany program', źle napisany program' ??? To takie pojęcia mało ścisłe. Żle napisany program to np. program bez komentarzy, co dla kompilatora ma raczej nijakie znaczenie. Może być źle napisany, bo np. nie używa czy mało używa procedur, co spowoduje że będzie znacznie bardziej rozwlekły, większy, ale będzie działał. Może też być źle napisany i źle działać, wieszać się czy 'iść w maliny' - to takiego chyba w ogóle się nie portuje:) A makrodefinicje czy procedury... też mam gotowe na typowe LCD, klawiatury, RS itp. ale to nie wystarczy, bo dzisiaj ludzie chcą wyświetlacze graficzne itp. i okazuje się że gotowce które masz to tylko 5% a 95 musisz zrobić. No i stale dziwi mnie stwierdzenie - nie mam bibliotek FP i nigdy ich nie szukałem... ciekawe...

    Być może te różnice w poglądach biorą się z różnic tego co robimy. Ja zajmuję sie głównie urządzeniami pomiarowymi, mierzącymi różne rzeczy jak światło (w tym kolor), dźwięk, poziom różnych gazów itp. W urządzeniach pomiarowych często używa się jednostek logarytmicznych. Jeżeli czujnki daje sygnał logarytmiczny (np. fotodioda ze wzmacniaczem logarytmującym) to problem z głowy. Ale jeżeli sygnał jest liniowy, to trzeba FP. Do tej pory udawało mi się uniknąć FP, bo przy wymaganej dokładności dawałem po prostu tablicę z wartościami log (adresowaną jednym bajtem, czyli 256 wartości). Jednak kiedy trzeba było wynik wyswietlić z jednym miejsce po przecinku więcej, no to robić tablicę z ponad 2500 elementów... Stąd konieczność FP. A tak na marginesie - kilka lat temu doszedłem do wniosku - po co mam robić programy dla kogoś, kto produkuje urządzenia i je sprzedaje zarabiając 100x tyle co ja. I zacząłem sam produkować i sprzedawać, więc już nie piszę tyle co kiedyś, ale mam duuuuużo wiecej czasu na zabawę np. z C :)
  • #50
    tymon_x
    Poziom 30  
    I tak z miłej dyskusji na temat typów do funkcji zrodziło się... przerzucanie argumentów "to ja mam rację, a to jest be...". mirekk36 i dziechu mają rację. Ja bym dodał, że obie rzeczy (assembler, C) mają rację bytu, powinno się znać. Chcesz wycisnąć z małej niewinnej Attiny całą moc jaką fabryka dała, daj asm. Potrzebujesz skomplikowanych funkcji matematycznych, przenośności, szybko i przyjemnie coś napisać, fajne jest C. Interesują Cię RTOS'y, mutexy/semafory, może C++? O tym można zapełnić cały internet, ale filozofia pisania w assemblerze powinna być znana. Dajmy na to rynek procesorów sygnałów (DSP), największy udział w rynku mają kody napisane w asm niż w C, mimo że więcej osób zaczyna i zna ten drugi. Chcesz się pobawić soft-procesory w FPGA? Zostaje tylko asm z np. darmowym Picoblazem. Też nie wyobrażam Sobie łatwej przenośności w asm. Przykład: ktoś operuje na zestawie instrukcji Thumb-2, i do podmiany bitów korzysta z BFI, weźmie to ktoś inny na wcześniejszy rdzeń ARM'a i kleks, nie ma. Trzeba zastosować kilka instrukcji. I zwyczajne ctrl+F, Find&Replace nie pomoże(; A w C można zmieścić to w jednej linijce, i w dodatku odpalić gdzie się chce. A jak to kompilator interpretuje, jego sprawa, ważne żeby tego nie robił przez 20 instrukcji asm (;
  • #51
    dziechu
    Poziom 27  
    No i właśnie tak cały czas piszemy:) Ostatnio robiąc ładowarkę aku na Tiny13 pisałem normalnie w asm, bo jednak 'czuję' go lepiej, a roboty na 20min. Ale kiedy były problemy z ATMEGA 8, 16, 32... i okazało się że być może cały program urządzenia (zajmujący prawie całe 32 kB) będę musiał napisać od początku na PIC, to sie załamałem. A na PIC nie miałem nic gotowego, ani procedur obsługi KS0108.

    Tak na marginesie - jedna z funkcji z menu oblicza coś takiego:

    Funkcja _delay_us(double us); - jak działa?

    A Dmax, Dśr i wsp to wartości zawierające jedną cyfrę całkowitą i dwie po przecinku, kto się będzie z tym męczył w ASM???
  • #52
    mirekk36
    Poziom 42  
    tymon_x napisał:
    ... Ja bym dodał, że obie rzeczy (assembler, C) mają rację bytu, powinno się znać. Chcesz wycisnąć z małej niewinnej Attiny całą moc jaką fabryka dała, daj asm. Potrzebujesz skomplikowanych funkcji matematycznych, przenośności, szybko i przyjemnie coś napisać, fajne jest C. Interesują Cię RTOS'y, mutexy/semafory, może C++?


    No właśnie o tym cały czas mowa, ale albertb niczym guru z jakiejś sekty wymyślił argumenty o "gloryfikacji na fałszywych przesłankach" - chore.

    Ja nawet korzystając z ATtiny spokojnie używam C, chociaż czasem kodu w C jest tylko co kot napłakał a reszta to wstawki w asm. No ale jak pisałeś - jeśli trzeba to można i całość machnąć w asm dla Tiny - cóż to za problem? Tylko bardzo często gdy już zacznie się nawet na Tiny pisać w C zamiast asm to okazuje się, że po co się męczyć z samym asm od początku. Zresztą jak kto woli, przecież nikt tu nikogo nie przekonuje żeby nie pisał sobie kodu tylko w asm!!! Każdy zrobi jak mu wygodnie.
  • #53
    Użytkownik usunął konto
    Użytkownik usunął konto  
  • #54
    dziechu
    Poziom 27  
    Zależało mi głównie na log10(a/b) z dokładnością 3 miejsca po przecinku, dla zakresu wyniku 0 - 3.000 (z rozdzielczością oczywiście 0.001). Okazuje się, że żeby otrzymać taką dokładność log10, to w początkowym zakresie np. 0 - 0.300 dzielenie a/b musi mieć dokładność ok. 5 miejsc po przecinku, choć można to uprościć do log10(a) - log10(b). Tak czy inaczej proste to nie jest. Co do portowania programu na inne platformy - nigdy nie piszę programu z taką myślą, bo jeżeli opracowuje się urządzenie, to na konkretny schemat i raczej nie ma konieczności zmiany procesora. No chyba że nagle procesory znikają z rynku... Ogólnie koszty są zbyt wielkie takiej zmiany, bo trzeba przerobić część schematu, opracować nowe płytki itd...
    Co do Bascomu - nie znam. Pewnie jest nieco pogardzany jako 'amatorski'. Dla mnie to nie ma znaczenia, jeżeli mogę na nim stworzyć dobrze działający program mniejszym wysiłkiem. Najchętniej używałbym języka, gdzie wystarczyłoby jedno polecenie - "napisz program który robi to..." i wcale nie wstydziłbym się tego:) A przeciez wielkich aplikacji na PC nikt nie pisze w asm, nawet przeważnie nie ma tam żadnych wstawek asm, ze szkodą dla tych aplikacji, bo w porównaniu z np. latami 80' dzisiaj mamy komputery 1000x szybsze a programy robią tylko 10x wiecej. Coraz większa moc komputerów idzie w coraz bardziej niechlujne pisanie programów, które pochłania tą moc.

    Dodano po 8 [minuty]:

    A czy dostęp do bibliotek w internecie nie jest zaletą??? OCZYWISCIE ŻE JEST!!! Może to nie jest właściwość jezyka, ale popularność, dostęp do bibliotek, dokumentacji, przykładów i wszelkiego rodzaju pomocy to olbrzymia zaleta dla nawet najzawodowszego zawodowca;) Tego mi brakowało, kiedy np. przeglądam sposób sterowania następnego wyświetlacza graficznego z setką rozkazów, nową magistralą, timingami... czasami sie już nie chce. Chyba że się jest hobbistą i robi to wszystko dla czystej przyjemności:)

    No i na koniec odnośnie procesorów 8 bitowych. Wielu uważa i pisze tu, że procedury zmniennoprzecinkowe to nie dla 8śmio bitowców, itp. itd. a chyba zapomnieli (lub ci młodsi po prostu nie wiedzą), że były kiedyś takie komputery jak Spectrum, który miał procesor 8bit Z80, pamięci programu 16kB (!), a takie wypasione modele miały 32 czy max 64kB, RAMu 1 kB, a taktowane 4Mhz, czyli raczej słabsze niż np. ATMEGA32:) I były to wtedy prawdziwe komputery na których robiło się cuda, a obliczenia log, sin, cos etc. z dokładnością 8 czy wiecej cyfr po przecinku to była pestka:) Ale wtedy pisało się programy licząc każdy bajt i robiło różne sztuczki, żeby zaoszczędzić 10 czy 20 bajtów. A kto dzisiaj tak pisze?