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

Bascom instrukcja programu.

Roman Szemik 27 Cze 2005 22:33 12134 8
  • #1 27 Cze 2005 22:33
    Roman Szemik
    Poziom 14  

    Poszukuję instrukcji programu bascom.
    Przede wszystkim informacji co dane znaczą i w jakich np. granicach można je zmieniać, lub od czego są uzależnione.
    Pozdrawiam.

    0 8
  • #2 28 Cze 2005 00:11
    LordBlick
    VIP Zasłużony dla elektroda

    A tutaj jest tego wiecej KLIK

    0
  • #3 28 Cze 2005 18:43
    Roman Szemik
    Poziom 14  

    Dziękuję za zainteresowanie lecz poszukuję takich informacji nt. Bascom-AVR jak np:
    w ustawieniach
    compiler HWStack?SoftStack? FrameSize?
    output optimize code?size warning?
    environment IDE-Hint time?Auto Backup?

    I jeszcze jedno pytanie - czy u Was też nie można w zakładce Printer zmienić tak ustawień aby drukowało z mniejszymi marginesami i w kolorze?
    Pozdrawiam.

    -1
  • #4 28 Cze 2005 21:51
    ZbeeGin
    Poziom 38  

    Roman Szemik napisał:

    compiler HWStack?SoftStack? FrameSize?


    Ustawia się to w zależności od skomplikowania programu. Najlepiej użyć do tego polecenia DBG i dyrektywy $DBG - potem za pomocą Stack Analyzera można dokładnie określić jakie wartości są potrzebne.
    Generalnie SoftStack przechowuje odwołania do procedur i funkcji (SUB i FUNCTION). HWStack to stos główny, tam odkładają się wszystkie adresy powrotne skoków wewnętrznych, przerwań i tych wywołanych przez GOSUB. FrameSize to stos/obszar na którym odkładane są wartości zmiennych tymczasowych (np. wynik funkcji) i tych definiowanych przez LOCAL w SUB-ach.

    Roman Szemik napisał:

    output optimize code?size warning?

    Pierwsza opcja włącza optymalizację kodu - nie za dużą więc nie oczekuj zbyt wiele. Druga opcja włącza ostrzeżenie, że długość kodu przekroczyła pojemność pamięci danego układu.

    Roman Szemik napisał:

    environment IDE-Hint time?Auto Backup?

    Pierwsza opcja ustala czas pojawiania się "dymków" (takie żółte prostokątne :) ) po najechaniu kursorem myszy na dane plecenie w menu, dialogach itd.
    AutoBackup ustala interwał czasu co jaki czas programy poddawane edycji będa zapisywane bez ingerencji piszącego. Zatem nagły "zwis windy" po 30 minutach może nie być tak tragiczny w skutkach.

    0
  • #5 29 Cze 2005 16:17
    Roman Szemik
    Poziom 14  

    Dziękuję za informacje lecz mam pytania:

    Cytuję:
    Ustawia się to w zależności od skomplikowania programu. Najlepiej użyć do tego polecenia DBG i dyrektywy $DBG - potem za pomocą Stack Analyzera można dokładnie określić jakie wartości są potrzebne.

    O co tutaj chodzi i o jakie wartości tutaj chodzi?

    Jaka jest informacja że deklarowany stos jest zbyt mały.

    Jeśli chodzi o dymki to co bym nie wpisał to nie widzę różnicy w zmianie czasu czy to wyświetlania czy to opóźnienia wyświetlania.
    Również zastanawiam się jak wcześniej pisałem czy problem z drukowaniem w kolorze a dokładniej jego brak i niemożność ustawienia marginesów jest czymś normalnym?
    Pozdrawiam.

    0
  • #6 30 Cze 2005 20:46
    ZbeeGin
    Poziom 38  

    Roman Szemik napisał:

    Cytuję:
    "Ustawia się to w zależności od skomplikowania programu. (...)"

    O co tutaj chodzi i o jakie wartości tutaj chodzi?

    Dokładnie chodzi o ilość bajtów jaką początkowo zajmie każdy ze stosów. Stos jest elementem rozrastającym i kurczącym się dynamicznie. Może dojść do sytuacji gdzie jeden zajdzie na drugi - stack overleap - i kłopot gotowy. Dlatego na początku określa się rozmiary domyślne, które powinny być zgrubsza obliczone przez projektojącego program.
    Wartości wpisywane przez BASCOM automatycznie, wystarczają dla większości prostych programów nie korzystających prawie wcale z procedur (SUB) i funkcji (FUNCTION).

    W kwestii wspomnianych obliczeń to metoda nie jest prosta i rzeczywiście wyniki zależą od treści programu. Przedstawie je tutaj ale to może być dość długi wywód.

    ------------------------------
    HWStack to nic innego jak stos systemowy, tutaj odkładane są adresy powrotne skoków do podprogramów (GOSUB), przerwań (On Interrupt) oraz inne wartości, które program musi wymczasowo przechować - np. wartości wszystkich rejestrów po wywołaniu przerwania (jeśli nie użyto NoSave).
    Zagnieżdżanie podprogramów, zapętlenie przerwań powoduje gwałtowny wzrost zapotrzebowania na HWStack.

    Inaczej wygląda sprawa stosów SoftStack i Frame Space. Każda struktura SUB/FUNCTION to jakby osobny podprogram, z tą różnica, że w prosty i czytelny sosób można przekazywać mu parametry i ewntualnie otrzymywać wynik (FUNCTION). Najprostszy sposób przekazywania parametrów to umieszczenie ich na stosie i wywołanie procedury/funkcji, która sama sobie te wartośći będzie pobierać. Do tego służy właśnie SoftStack, którego aktualny wierzchołek określa rejestr Y procesora.
    Każdy parametr procedury/funkcji to dwa bajty (adres zmiennej) odłożone na SoftStack. Przykładowo:

    Sub (Param1 As Byte, Param2 As Byte)

    to 4 bajty odłożone na stosie. Po wyjściu z procedury/funkcji zostają one zwolnione ale jak łatwo sobie wyobrazić, wywołanie procedury z innej procedury to pozostawienie bieżących bajtów i odłożenie kolejnych bajtów na stos!!

    Sytuacja nieco się komplikuje jeśli w deklaracji procedury skorzystano z argumentu BYVAL:

    Sub (Param1 As Byte, Byval Param2 As Byte)

    Wtedy kompilator musi utworzyć tymczasową zmienną, a robi to... w obszarze ramki (Frame Space). Zatem tutaj sytuacja wyglądać będzie podobnie. Z puli ramki zostanie wykorzystany 1, 2 lub 4 i więcej bajtów w zależności od typu zmiennej (Byte, Integer/Word, Long/Single, String), A po wyjściu z procedury bajty te zostaną zwolnione.

    Tak samo z puli ramki bajty zostaną przeznaczone na zmienne lokalne, definiowne wewnątrz procedur/funkcji przez LOCAL. Podobnie jest w przypadku FUNCTION gdyż zwracana wartość też musi być gdzieś tymczasowo umieszczona.





    Ramka to także obszar tymczasowy dla operacji konwersji liczb na ich postać znakową i vice versa, przykładowo podczas PRINT, LCD, INPUT. Wtedy to z puli ramki wykorzystywane jest 16 bajtów.

    Podsumowując:
    - każda funkcja to minimum dwa bajty z SoftStack plus 1 do kilku bajtów zajętych w Frame Space,
    - każdy zwykły parametr to 2 bajty z SoftStack,
    - każdy parametr ByVal to 2 bajty z SoftStack plus 1 do kilku bajtów w Frame Space,
    - każda zmienna lokalna to 1 do kilku bajtów w Frame Space,
    - każda konwersja liczby<->znaki to 16 bajtów w Frame Space.

    Dokładniejsze informacje znajdziesz w helpie (np. w polskim Mojego autorstwa) w tematach: $DBG, BYVAL, BYREF, Wstawki assemblerowe.
    ------------------------------

    Roman Szemik napisał:

    Jaka jest informacja że deklarowany stos jest zbyt mały.

    Generalnie podczas kompilacji tak informacja się nie ukaże. Informacja taką znajdziesz tylko podczas symulacji programu.
    Jeśli włączysz w symulatorze u góry zakładkę uP to znajdziesz tam dwa checkbox-y: Frame Overflow oraz Stack Overflow. Jeśli któryś zostanie zaznaczony podczas symulacji programu, to znak, że ten stos jest zbyt mały. Należy zwiększyć wartość w odpowiednim polu - najlepiej dwukrotnie - i ponownie uruchomić symulację.
    Tuż poniżej znajdziesz także pola Soft Stack, Soft Stack Min itd. Tam pokazywane są bieżące wartości adresów początków stosów i ich końców. Śledząc te wartości można obliczyć (wystarczy odjąć odpowiednią parę pól) ile bajtów z każdego stosu użył program.

    Roman Szemik napisał:

    Również zastanawiam się jak wcześniej pisałem czy problem z drukowaniem w kolorze a dokładniej jego brak i niemożność ustawienia marginesów jest czymś normalnym?

    Problem z wydrukami w kolorze jest. Został on wspomniany w pliku HISTORY.TXT, który dodawany jest w pełnej wersji BASCOM-a.
    Najlepszym rozwiązaniem Twojej sytuacji jest użycie narzędzia Export to RFT z menu Tools, który pozwala na przeniesienie tekstu wraz z formatowaniem (kolory, pogrubienia) do OpenOffice.org Writera, M$ Worda itp; i tam ustalenie marginesów, rozmiaru czcionki...

    Plik RTF znajdzie się tam gdzie oryginalnie został zapisany program BAS, oraz będzie miał taką samą nazwę.

    2
  • #7 01 Lip 2005 16:43
    Roman Szemik
    Poziom 14  

    Kolego Zbigniewie. Dziękuję za informacje.
    Czytając zastanawiałem się gdzie widziałem podobny styl wymowy i nie musiałem długo szukać gdyż będąc w piaskownicy jako że piękna pogoda u nos na południu czytałem helpa jako że człowiek z różnych źródeł czerpie wiedze i hylę czoła udeżając czubkiem nosa w spację osobie która wskazuje drogę debiutantom na śćieżce zwaną Bascomem.
    Miałem już kończyć lecz przyszło mi do głowy jeszcze jedno pytanko.
    Optimize code. Piszę program na ATmega16 i jest on wypełniony w 95%.
    Włączając ww. funkcję schodzę do 86%. Zastanawiam się jednak czy optymalizacja kodu jest bezbłędna jeżeli chodzi o działanie programu ewentualnie jakie ma wady. Bardzo ważne ze względu na projekt. Ja porównuję to do kompresji JPG i stąd moje obawy.
    Pozdrawiam Roman.

    0
  • #8 01 Lip 2005 19:45
    elektryk
    Poziom 42  

    Roman Szemik napisał:
    Zastanawiam się jednak czy optymalizacja kodu jest bezbłędna jeżeli chodzi o działanie programu ewentualnie jakie ma wady.
    Coś za coś, samo określenie "optymalizacja" nic nie mówi, ale może być optymalizacja prędkości wykonywania programu, optymalizacja ilości zajętej pamięci RAM, czy optymalizacja ilości zajętej pamięci programu. Za każdym razem otrzymujemy ten sam funkcjonalnie działający program, ale coś tracimy.

    0
  • #9 03 Lip 2005 12:29
    ZbeeGin
    Poziom 38  

    W Bascomie optymalizacja stara się skrócić program, rozpisując inaczej pewne operacje. Dowodzi temu załączony przykład. Oczywiście przekłada się to na zmniejszenie rozmiaru kodu, a co za tym idzie - także przyśpieszenie jego wykonywania.

    Niestety kompilator jest tak zbudowany, że tam gdzie tylko można używa gotowych fragmentów - pobranych z bibliotek, lub z tzw. templates, czyli kodu zaszytago w kompilatorze, któremu można dobrać niektóre parametry; np.: wartości stałych, adresy zmiennych, nr-y bitów, nr-y rejestrów - na podstawie instrukcji CONFIG lub parametrów poszczególnych instrukcji.
    Dlatego tyle jest masowych przypisań do rejestrów i skoków.

    Pomyłka w załączonym tekście, źle obliczyłem skok więc wyszły błędne wnioski. Załącznik został zauktualizowany.

    1