Jak zmniejszyć zużycie pamięci w programach Bascom?

pisze proramik w bascomie i po pewnym czasie okazuje sie ze mam namalo miejsca w procku na jego zgranie. mam pytanie jak pisac poprawnie program, to znaczy czego sie wystrzegac by program optymalnie mało zajmowal pamieci w procku. nadmienie ze zmienne mam dobrane w minimalnej postaci.

może spróbuj używać komend pisanych w asemblerze

Pozdrawiam
Józef

Z optymalizacja to jest tak, ze czasem objetosc kodu wynikowego zalezy w silny sposob od stopnia zlozonosci poszczegolnych polecen i ich kolejnosci zapisu w zrodle. Parser a potem kompilator silnie reaguje na takie rzeczy. Sprobuj poprzestawiac kilka linijek w zrodle i zobacz efekty.

W moim pojeciu jest tak:

Basic - jaki jest, kazdy widzi !

C - pierwsza calkiem udana proba optymalizacji Basica ;

ASM - najoptymalniejsza wersja Basica.

Moze przelacz sie na jeden ze zoptymalizowanych Basicow to zaoszczedzisz nerwow i prob naprawienia nienaprawialnego.

zycze powodzenia, yego

najlepiej zoptymalizowac bascoma opcja odinstaluj !! tylko asm !!

Z moich doświadczeń wynika, że można zoptymalizować program w Bascomie ale wiele więcej nie osiągniesz.

Zastąp wszystkie pętle FOR pętlami WHILE, a gdzie się da IFy na SELECT... CASE. W sumie to tylko tyle znalazłem z funkcji mniej pamięciożernych. Pewnie można jeszcze coś znaleźć ale ja dałem sobie siana z Bascomem i uczę się teraz asemblera.

Witam
Olo.d, tak jak napisali przedmówcy najlepszym optymalizatorem jest rozstanie się z bascomem, ja tak zrobiłem na rzecz AnsiC i naprawde jestem zadowolony. Miałem kilka większych programów napisanych w bascomie na '51 i AVR, po przekonwertowaniu zaoszczędziłem nawet do 50% pamieci. Czas jaki mi zajął na naukę (ogarnięcie podstawowych zasad) C dla '51 i AVR od podstaw to jakieś tydzień. Nie mówie, że jestem specjalistą w tej dziedzinie, ale w większości problemów sobie poradziłem dość szybko.
Pozdrawiam.

olo.d napisał:

...mam namalo miejsca w procku na jego zgranie...

Jeśli piszesz na µC mające max 2K pamięci to może pomóc przesiadka na konkurencyjny basic - FastAVR. Ma trochę inną składnię, ale małe µC "pakuje" wyraźnie sprawniej. Napisz co to za program - może można coś przeskoczyć samym algorytmem.

nowłasnie program jest aż zapchany (for,if). Na uczelni mam C na zajęciach, ale chciałem sprubować jakiegoś nowego jezyka bo asm też już kiedyś skrobałem. No ale widze że bascom to tylko dla poczatkujących. Nawet prosty, help po polsku, troche nie dopracowany, ale ujdzie. no i chyba nie bedzie wyjścia, jak na moje potrzeby zostane narazie przy C. pozdrawiam wszystkich i dzieki za owocne RE, a jak ktoś ma jeszce jakieś uwagi co do bascomu to zapraszam z checia poczytam.

To jeszcze ja wtrące swoje 3 grosze. Co do select case to nie polecam - mniej miejsca zajmują pojedyńcze warunki IF tylko trzeba wtedy dobrze przemyśleć aby nie wyskakiwały dwa naraz albo chociarz prawidłowa wartość była wtedy kiedy oczekujemy tego. Dodatkowo zauważyłem ze w Bascomie 8051 użycie podwójnego lub potrójnego warunku IF (if cos=1 or cos=2... then) zajmuje wiecej miejsca niż umieszczenie pojedyńczego warunku w warunku - sporo więcej. W AVR tego niema - może jakiś bład w parserze. Co jeszcze. Obliczenia powinno przeprowadzać sie na podobnych typach zmiennych możliwie ograniczonych do dołu. A i jeszcze coś ciekawego: wiadomo że '51 i bascom słabo działa na przecinkach ale to też da sie obejść. Jeżeli mnożymy coś przez liczbę przecinkową(np 3,1415...) to należy sie zastanowić nad innym rozwiazaniem - najpierw liczbe pomnożyć przez całkowitą tak aby maksymalnie wykorzystać przestrzeń(np word do 65535) i dopiero dzielimy przez inną liczbe tak aby otrzymać to co powinno być. Np 180*3,14=562, i 180*300/942 - wykona sie szybciej i zajmie mniej pamięci. Generalnie do bascoma trzeba sie przyzwyczaić i da sie wtedy znim żyć. Generalnie wersja 8051 bardzo dobrze przekłada na kod maszynowy(w miare oszczednie) za to AVR to dopiero potrafi szafować pamięcią - nawet z właczoną optymalizacją kodu czasami jeden warunek zajmuje 4x tyle co powinien. Ale napewno asembler jest szybszy do krótkich procedur i w sytuacjach kiedy mamy dużo czasu na pisanie i sprawdzanie programu - popieram wstawki asemeblerowe ale natomiast c na 51 to pomyłka - na AVR jeszcze ujdzie.