Jak przygotować procedury w assemblerze do użycia z include?

Witam.
Pisze w assemblerze i chciałbym wykorzystać gotowe procedurki poprzez "include".
W jaki sposób je przygotować aby nie było komunikatu typu niezdeklarowana zmienna lub zdeklarowana podwójnie?

A kolega to na jaki procesor pisze? nie laska sie pochwalic, jakiego kompilatora uzywa... widze ze to raczej poczatki pisania, bo ktos kto PISZE w assemblerze to chyba by nie zadawal takiego pytania.
Hm... w assemblerze to chyba po prostu musisz sam o to zadbac , to znaczy zadeklarowac to co niezadeklarowane i nie uzywac tych samych nazw do dwoch zmiennych. takie juz uroki assemblera.
Moja rada: jesli istnieje na to co piszesz kompilator C to daj sobie spokoj z asseblerem. Zanim bedziesz lepszy od kompilatora(tzn bedziesz w stanie napisac bardziej efektywny kod) mina lata... A w te bajki ktore niektorzy pisza ze maja pelna kontrole nad procesorem to nie wierz, maja dopoki nie popelnia bledu i pisanie programu zajmuje 10x dluzej. Odkad sa ogolnie dostepne procesory przygotowane pod 'C' czyli ARM AVR itp baaaaaaardzo rzadko mam potrzebe siegniecia po assembler. Od kilku lat wlsciwei tylko raz tego potrzebowalem i zmiescilo sie to na pol A4.

Cytat:

gmp...

Do Twojej wiadomości...

.IF
.ENDIF
.ELSE
.ELIF
.IFDEF
.IFNDEF
.MESSAGE
.ERROR

np.

ja gdzie widzialem i dodaje do naglowkow takie cos co caly plik pomija jak juz byl


a jesli chodzi o asm w keilu na '51 to do *.src jakos sam dodaje definy rejestrow '51 i trzeba odznaczyc w opcjach projektu.

opcja
"include" w c jest zarezerwonana dla bibliotek c, zazwyczaj piszesz

#include <cośtam.h>

Jeśli wstawki asm mają być krótkie to proponuje komendę inline();

jesli dłuższe to możesz zastosować __asm;

Jeszcze inna metoda , ale już ściśle zależna od konkretnego kompliatora to opjca linkowania plików *.obj ale nie zawsze działa tak jak chcesz

Po za tym mieszanie Asm i C wymaga wiele rozwagi
najlepiej jest przeanalizować zawartość kompilatu w C ponieważ kompliacja odbywa się krokowo, najpierw na podstawie kodu C tworzony jest kod ASM, a dopiero póżnień kod maszynowy , więc masz okazję obejrzeć "herezje" z C w listingu, zanim podłączysz swój "dopieszczony" kod w Asmie .

Niestety czasem te dwie sprawy mogą się gryźć NP. korzystanie ze zbierznych obszarów pamięci etc.

Wychodzi na to że będe musiał poprostu kopiować i wklejać określone procedurki.
Dziękuje wszystkim
Powodzenia

Niestety o C nie mam pojęcia, o jego sposobie zapisu itp.,itd.
Pozostało mi wymyślić .. koło.
Powodzenia

W programie AVRStudio pliki nagłowkowe deklaruje sie poprzez np:

.include "nazwa_pliku.inc"

Plik musi znajdowac sie w katalogu projektu.

Nie nażekaj "astony" tylko napisz konkretniej o co Ci chodzi ... bo do końca nie złapałem Twojego toku myślenia!

Chcesz dołączać tylko używane procedury czy że jak?

Mam wrażenie że chodzi mu o to, że ma jakieś procedury czy cos tam w asm, czyli drugi plik *.asm, i powiedzmy ma tam te same definicje czegoś. Choćby nawet te samą etykiete do skoku. Albo jakieś zmiennej.

No ale może sie sam wypowie precyzyjniej.

Chodzi o to, że podczas pisania programu w miarę rozwoju listing robi się strasznie długi i bieżąca analiza jest utrudniona. Wydawało mi się że jeżeli poszczególne podprogramy działające już w innym programie umieszczę w bieżacym jako odnośnik to będzie mi łatwiej analizować listing, bo po prostu będzie krótszy. Gdy uznam że program jest gotowy to dopiero kompilacja spowoduje dołączenie wcześniejszych procedur w całości. Podczas wcześniejszy prób "include *.asm" były ciągłe niepowodzenia tak że dałem spokój, jednak wciąż mnie to korci.
Niestety w tłumaczeniu problemu tez nie jestem biegly

Jednak zastosuję tylko nazwy podprogramów jako label z RTS i na koniec dołożę całą procedurę
Powodzenia

Rada ... jak coś deklarujesz w ASM to dawaj prefixy czego dotyczą i nie będą się dzięki temu powtarzać

ADC_Initiate
LCD_Initiate

itp. To samo z stałymi i zmiennymi ...

Oglądając programy innych próbowałem stosować zmianę nazwy dla tego samego rejestru w zalezności od tego w którym podprogramie występuje. Niestety łatwiej sie wtedy gubię . Dlatego pozostaje mi tylko symulacja, ale do tego potrzebna jest kompilacja. Jezeli mam błąd to mam tez -> brak kompilacji . Stąd moje próby pójścia na skróty

z asmie tez powinny byc includy i ifdef itp
przynajmniej z takimi sie zetknalem ( w jednym tylko mialem ograniczenie co do zagniezdzania ).

powinno Ci zwracac numer linijki blednej co zawsze pomoze jakos dojsc .

moze napisz w jakim asmie to jest to ktos to musial robic.

co do nazw to najplepiej dawac na poczatku etykiety skrot od nazwy pliku zeby sie nie powtarzalo tak jak ktos podal wczesniej przyklad.

Nie bardzo rozumiem o co chodzi większość asemblerów dopuszcza komendę

inc ("coś.obj") - czyli włączenie skompilowanego pliku asm , c, pas.

Więc jeśli chcesz, to co robisz zrobić dobrze to pomyśl o działaniu z bibliotekami lib. Ważne jest to żeby stosować adresowanie ideksowane i zapewnić przenośność kodu w pamięci, nie stosować sztywnych przypisań danych do miejsca w pamięci etc. etc.

Co zaś do analizy listingów hmm, wskazane byłoby stosowanie debugera, pułapek -trap etc.
Wtedy możesz analizować działanie kodu krokowo, skokowo i jeśli twój debuger pozwala możesz też ręcznie sterować danymi np. w celu testowania zabezpieczeń przekroczenia zakresów danych.

Praca z wydrukowanym listingiem jest bardzo złożona szczególnie, gdy zależności są dynamiczne podziwiam twoją cierpliwość działania .

A ostatnia sprawa to zastosowania, przecież

mov A, #10 to to samo co A=10; w C.

Korzyści wynikające z procedur czysto assemblerowych pojawiają się w procedurach zależnych czasowo od zegara lub tam, gdzie stosuje się arytmetykę złożoną wykorzystując daną architekturę rejestrów, cała reszta działań w assemblerze jest bardzo łatwa do przeniesienia do C i tu zdecydowanie łatwiejsza do kompliacji i debugowania.

Szczególnie, że C generuje głównie kod przenośny, a w asmie zazwyczaj działasz na konkretnych rejestrach i SFRze, będąc blisko sprzętu, ale daleko od algorytmu.
Zdecydowanie łatwiej jest śledzić zmienną int licznik_powtórzeń; od adres 100h gdzie ten licznik umieszczasz na sztywno:)

Więc może zamiast szaleć z łączeniem C i Asm przyjrzyj się temu czy rzeczywiście "twoje" procedury są tak dobre, że te z C będą gorsze

Potem naucz się korzystać z bibliotek C , a potem jak będzie brakować czegoś w C zaczniesz dodawać swoje wstawki również w asmie

Niestety plik .obj powstaje po kompilacji. Jezeli mam błąd wynikający właśnie z próby włączenia jakiejś procedury to nie mam tego pliku.
Piszę w asm (AVRstudio). Wygląda na to że nieprzemyślałem sprawy do końca.
Dzięki za podpowiedzi i
powodzenia

A może zadziała

$include (cośtam.inc)

Spróbuj

Tak było w asmie c51

Dodano po 30 [sekundy]:

Tylko nie zapomnij korzystać ze zmienych extern

Na chwilę obecną dałem spokój.
Mimo wszystko dzięki.
"include .inc" już było
Powodzenia

tak ale przez .include

Odkopuje wątek bo pragnę podzielić się swoimi spostrzeżeniami

Dołaczanie podprogramów odbywa się bardzo prosto, tzn:
.include "m128def.inc"
.include "czekaj_m128.inc"
.include "s65_LCD.inc"
.include "i2c.inc"
wyskakują wtedy dodatkowe zakładki z ww podprogramami. Jedyne co musimy pamiętać, to o zadeklarowaniu wcześniej na początku każdego podprogramu początku adresu, inaczej AVRstudio wyrzuci błedy typu przekroczony zakres skoku, albo zapisze kolejny podprogram na poprzednim.
Ale nie polecam tej metody, bo ko0mpilator niestety się zaczyna gubić i nie znajduje niektórych błędów (np ograniczenia przy komendzie movw). Po przerzuceniu całego kodu ze wszystkich zakładek w jeden ciągły, debuger zaczyna znajdować błedy.

Inna metoda w poruszaniu sie po kodzie to włączenie widoku projektu i tam mamy zakładkę labels. Otwiera się nam alfabetyczna lista wszystkich etykiet, jakie nadaliśmy i po doubleclicku AVRstudio od razu nam ustawia kursor na wybranej etykiecie w programie.
Może komuś przydadzą się te wskazówki

Pozdrawiam