plik

Spis rzeczy

Programowanie w j ˛ezyku asembler

1.1

Podstawowe wła´sciwo´sci asemblera . . . . . . . . . . . . . . . . . . . . . . .

1.1.1

Proces powstawania i tłumaczenia programu

. . . . . . . . . . . . . .

1.1.2

Składnia instrukcji asemblera

. . . . . . . . . . . . . . . . . . . . . .

1.1.3

Komentowanie programu . . . . . . . . . . . . . . . . . . . . . . . . .

1.1.4

Elementarne obiekty j˛ezyka . . . . . . . . . . . . . . . . . . . . . . .

1.1.5

Tworzenie nazw i operacje na słowniku . . . . . . . . . . . . . . . . .

1.1.6

Dyrektywy rezerwacji pami˛eci . . . . . . . . . . . . . . . . . . . . . .

1.1.7

Dyrektywa ko ´ncz ˛

aca program . . . . . . . . . . . . . . . . . . . . . .

1.2

Makroasembler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2.1

Ogólne wła´sciwo´sci makroasemblera . . . . . . . . . . . . . . . . . .

1.2.2

Asemblacja warunkowa

. . . . . . . . . . . . . . . . . . . . . . . . .

1.2.3

Makrodefinicje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3

Tworzenie programów w postaci modułowej

. . . . . . . . . . . . . . . . . .

1.3.1

Moduły programowe . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3.2

Absolutne i wzgl˛edne tłumaczenie modułów programowych . . . . . .

1.3.3

Atrybuty nazw w programach modułowych . . . . . . . . . . . . . . .

1.3.4

Relokowalo´s´c modułów . . . . . . . . . . . . . . . . . . . . . . . . .

1.3.5

Współu˙zywanie nazw w modułach . . . . . . . . . . . . . . . . . . . .

1.3.6

Doł ˛

aczanie modułu zawieraj ˛

acego kod ´zródłowy programu . . . . . . .

1.4

Sekcje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4.1

Typy sekcji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4.2

Składnia dyrektywy .SECTION . . . . . . . . . . . . . . . . . . . . .

1.4.3

Sekcje rejestrowe i sekcje bitowe

. . . . . . . . . . . . . . . . . . . .

1.5

Lokowanie sekcji w pami˛eci . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.1

Sposoby lokowania sekcji . . . . . . . . . . . . . . . . . . . . . . . .

1.5.2

Zwi ˛

azki mi˛edzy sekcjami

. . . . . . . . . . . . . . . . . . . . . . . .

1.5.3

Sterowanie lokowaniem sekcji . . . . . . . . . . . . . . . . . . . . . .

1.5.4

Konsolidacja programu o strukturze sekcyjnej . . . . . . . . . . . . . .

Programowanie w C

K rodziny Intel 8051

2.1

Proces uzyskiwania programu wynikowego dla programów w C . . . . . . . .

2.2

Program rozruchowy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.1

Rodzaje programu rozruchowego

. . . . . . . . . . . . . . . . . . . .

2.2.2

Definiowanie rodzaju mikrokontrolera . . . . . . . . . . . . . . . . . .

Spis rzeczy

2.2.3

Deklaracja rejestrów roboczych . . . . . . . . . . . . . . . . . . . . .

2.2.4

Przesuwanie danych . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.5

Przygotowanie stosu . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.6

Wywołanie programu w C . . . . . . . . . . . . . . . . . . . . . . . .

2.3

Organizacja danych w C . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3.1

Typy danych i ich modyfikatory . . . . . . . . . . . . . . . . . . . . .

2.3.2

Organizacja ramki stosu . . . . . . . . . . . . . . . . . . . . . . . . .

2.3.3

Przekazywanie argumentów do funkcji

. . . . . . . . . . . . . . . . .

2.3.4

Rozmieszczenie zmiennych lokalnych w ramce stosu . . . . . . . . . .

2.3.5

Przechowywanie warto´sci zwracanych przez funkcj˛e . . . . . . . . . .

2.4

Przekazywanie danych mi˛edzy funkcjami a instrukcjami asemblera . . . . . . .

2.4.1

Wprowadzanie instrukcji asemblera do programu w C . . . . . . . . .

2.4.2

Dost˛ep do zmiennych lokalnych . . . . . . . . . . . . . . . . . . . . .

2.4.3

Dost˛ep do argumentów funkcji j˛ezyka C . . . . . . . . . . . . . . . . .

2.4.4

Adresowanie bezpo´srednie i po´srednie w programach w C . . . . . . .

Indeks

Spis rysunków

1.1

Proces tworzenia programu . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2

Proces tworzenia programów w postaci modułowej . . . . . . . . . . . . . . .

1.3

Zwi ˛

azki mi˛edzy sekcjami . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1

Proces uzyskiwania programu wynikowego dla programów w C . . . . . . . .

2.2

Struktura wewn˛etrznej pami˛eci RAM po zainicjowaniu stosu . . . . . . . . . .

2.3

Ramka stosu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.4

Kolejno´s´c argumentów funkcji w ramce stosu . . . . . . . . . . . . . . . . . .

2.5

Ramka stosu dla przykładu ze strony 33 . . . . . . . . . . . . . . . . . . . . .

2.6

Mapa pami˛eci zmiennych lokalnych . . . . . . . . . . . . . . . . . . . . . . .

2.7

Mapa ramki stosu funkcji z przykłady ze strony 33

. . . . . . . . . . . . . . .

iii

1 Programowanie w j ˛ezyku asembler

1.1

Podstawowe wła ´sciwo ´sci asemblera

1.1.1

Proces powstawania i tłumaczenia programu

Program z´ródłowy

Program wynikowy

Tłumaczenie

Rysunek 1.1: Proces tworzenia programu

Proces tworzenia programu u˙zytkowego, niezale˙znie od zastosowanego j˛ezyka programo-

wania, przebiega w sposób przedstawiony ogólnie na rysunku 1.1. Proces ten mo˙zna okre ´sli´c
jako zespół działa ´n słu˙z ˛

acych przetworzeniu programu, tworzonego w sposób dogodny dla pro-

gramisty i specyficzny dla rodzaju oprogramowywanego zadania, na posta ´c dostosowan ˛

a do

potrzeb procesora realizuj ˛

acego program. Ta pierwotna posta ´c programu, nazywana programem

´zródłowym, ma zawsze posta´c symboliczn ˛

a i powstaje przy u˙zyciu edytora tekstu

. Program

wynikowy ma posta´c binarn ˛

a wyra˙zon ˛

a j˛ezykiem wewn˛etrznym (maszynowym) procesora. Pro-

ces tłumaczenia polega na nadawaniu warto´sci liczbowych nazwom symbolicznym. Elementem
składowym tego procesu jest równie˙z organizacja i zapis pami˛eci danych. Program ´zródłowy
stanowi ci ˛

ag instrukcji uszeregowanych w sposób wła´sciwy dla celów realizacji okre´slonego za-

dania. Posta´c instrukcji narzuca sposób tłumaczenia programu, okre´slaj ˛

ac zarazem podstawowy

podział j˛ezyków programowania. Wyró˙znia si˛e dwa podstawowe rodzaje j˛ezyków:

j˛ezyki maszynowo (sprz˛etowo) zorientowane nazywane asemblerami a w rozwini˛etej wer-
sji makroasemblerami,

j˛ezyki proceduralnie zorientowane, czyli tzw. j˛ezyki wy˙zszego rz˛edu.

Budowa asemblera dostosowana jest do wła´sciwo´sci sprz˛etowych procesora i urz ˛

adze ´n z nim

współpracuj ˛

acych. Wyst˛epuje wi˛ec ´scisły zwi ˛

azek mi˛edzy budow ˛

a mikrokomputera a postaci ˛

instrukcji j˛ezyka typu asembler. Zewn˛etrznie ten zwi ˛

azek przejawia si˛e w taki sposób, ˙ze jedna

instrukcja w j˛ezyku asemblerowym koduje jeden rozkaz maszynowy (jest to tzw. własno´s´c jeden
na jeden). Symbolika j˛ezyka sprowadza si˛e do u˙zywania:

Czyli MS Word odpada, na szcz˛e´scie . . . ;-)

Programowanie w j˛ezyku asembler

symbolicznych (mnemonicznych) kodów rozkazów,

symbolicznych adresów i danych.

Reasumuj ˛

ac mo˙zna powiedzie´c, ˙ze j˛ezyk typu asembler jest j˛ezykiem symbolicznym sprz˛etowo

zorientowanym.

Podstawow ˛

a cech ˛

a j˛ezyka wy˙zszego poziomu jest orientacja proceduralna, tzn. ˙ze j˛ezyki te

s ˛

a budowane pod k ˛

atem optymalizacji okre´slonego rodzaju zada ´n. Dzieli si˛e je na:

j˛ezyki algorytmiczne,

j˛ezyki symulacyjne,

j˛ezyki do tworzenia baz danych, itp. itd.

Programy pisane w tych j˛ezykach maj ˛

a praktycznie tak ˛

a sam ˛

a posta ´c dla ró˙znych typów kom-

puterów. Ró˙zni ˛

a si˛e natomiast programy tłumacz ˛

ace, które musz ˛

a by ´c inne dla ka˙zdego typu

komputera (procesora). Istotn ˛

a zewn˛etrzn ˛

a cech ˛

a j˛ezyków wy˙zszego rz˛edu jest zast˛epowanie

ka˙zdej ich instrukcji wieloma rozkazami maszynowymi.

1.1.2

Składnia instrukcji asemblera

Instrukcja jest elementarnym poleceniem dla programu tłumacz ˛

acego. Inaczej mo˙zna po-

wiedzie´c, ˙ze instrukcja jest podstawowym elementem j˛ezyka. Instrukcja mo˙ze:

kodowa´c rozkaz,

zawiera´c dyrektyw˛e,

by´c pusta (komentarz).

Dyrektywa jest to taki rodzaj instrukcji, która słu˙zy do organizowania programu. Na ogół

dyrektywy nie generuj ˛

a kodu, za wyj ˛

atkiem takich, które wprowadzaj ˛

a liczby do pami˛eci da-

nych.

Instrukcja jest zapisana w oddzielnej linii programu ´zródłowego, zatem linia programu jest

jednostk ˛

a organizacji programu ´zródłowego. W linii programu wyró˙znia si˛e cztery pola (zawar-

to´s´c ka˙zdego z nich mo˙ze by´c pusta):

pole_etykiety: pole_operacji pole_argumentów ;pole komentarza

Dwukropek jest wyró˙znikiem pola etykiety, przed komentarzem zawsze musi wyst˛epowa ´c ´sred-
nik. W polu etykiety umieszczana jest nazwa wprowadzana przez programist˛e. U˙zycie nazwy
w polu etykiety nadaje jej warto´s´c w procesie tłumaczenia programu według okre´slonych reguł.
Nazwa w polu etykiety musi by´c zako ´nczona dwukropkiem. Długo´s´c nazwy w polu etykiety
zale˙zy od dopuszczalnej długo´sci nazw danej wersji asemblera. W przypadku pakietu 2500AD
wynosi ona 32 znaki, przy czym zalecane jest u˙zywanie nie wi˛ecej ni˙z 10 znaków. Zawarto ´s´c

1.1

Podstawowe wła´sciwo´sci asemblera

pola operacji okre´sla rozkaz maszynowy lub dyrektyw˛e. Natomiast pole argumentówpodaje
dodatkowe argumenty, których liczba i rodzaj zale˙z ˛

a od zawarto´sci pola operacji. Pole komen-

tarza, poprzedzone ´srednikiem, mo˙ze zawiera´c dowolny ci ˛

ag znaków. Komentarz w procesie

tłumaczenia jest przez asembler pomijany. Przykład:

int0:

ACALL przeslij ;prze´

slij komunikat na P1

RETI

komunikat_1: .db ’komunikat 1’,0Dh,0Ah,0

1.1.3

Komentowanie programu

Standardowo komentarz realizuje si˛e przy u˙zyciu ´srednika. Przykład:

;To jest komentarz

;************************

;* Data: xx-xx-xxxx

;* Nazwisko programisty *

;* Wersja programu

;************************

U˙zycie dyrektywy

.COMMENT

pozwala na swobodne operowanie komentarzem. Cały tekst mi˛e-

dzy znakami przyj˛etymi przez programist˛e jako ograniczniki stanowi komentarz. Przykład:

.comment #

To jest przykład u˙

zycia dyrektywy .comment

Cały tekst zawarty mi˛

edzy hash-ami jest komentarzem

Taki komentarz mo˙

ze mie´

c wiele linii, ale te 3 chyba wystarcz ˛

a...

1.1.4

Elementarne obiekty j ˛ezyka

Elementarnymi obiektami j˛ezyka typu asembler, czyli wielko´sciami, na których j˛ezyk wy-

konuje działania, s ˛

stałe,

nazwy,

wyra˙zenia arytmetyczne.

Stałe mog ˛

a by´c zapisane jako:

1. dziesi˛etne: D

2. dwójkowe: B

3. ósemkowe: O, Q

Programowanie w j˛ezyku asembler

4. szesnastkowe: H

5. znakowe

Stałe liczbowe opatrzone s ˛

a odpowiednim symbolem literowym. Pomini˛ecie symbolu oznacza

liczb˛e dziesi˛etn ˛

a. U˙zycie dyrektywy

.RADIX

powoduje zmian˛e standardowej podstawy liczb

u˙zywanych w programie. Argumentem tej dyrektywy jest jeden z wymienionych symboli lub
liczba b˛ed ˛

aca podstaw ˛

a danego kodu

. Stałe znakowe ograniczone s ˛

a znakami pojedynczego

lub podwójnego cudzysłowu. Przykład:

127

;stała dziesi˛

etna

101101101b

;stała binarna

0A3h

;stała szestnastkowa. Je˙

zeli pierwsza cyfra stałej

;jest liter ˛

a to nale˙

zy j ˛

a poprzedzi´

c zerem

’napis’

;pi˛

ecio bajtowa stała znakowa

.radix 16

;ustaw standard liczb szesnastkowy

Nazwa jest ci ˛

agiem liter i cyfr zaczynaj ˛

acym si˛e od litery. Liczba znaków w nazwie zale˙zy

od standardu asemblera. W ró˙znych asemblerach zmienia si˛e tak˙ze zbiór dozwolonych znaków
alfanumerycznych, z których mog ˛

a by´c budowane nazwy i inne obiekty j˛ezyka.

Ostatni ˛

a konstrukcj ˛

a składniow ˛

a jest wyra˙zenie arytmetyczne b˛ed ˛

ace ci ˛

agiem nazw i stałych

przedzielonych dwuargumentowymi operatorami arytmetycznymi. Ka˙zda nazwa lub stała mo˙ze
by´c poprzedzona operatorem jednoargumentowym. Dopuszcza si˛e stosowanie nawiasów w celu
ł ˛

aczenia argumentów. Operatory wyra˙ze ´n arytmetycznych:

1. Operatory jednoargumentowe

‘

.NOT.

’, ‘

’,

‘!

’ – zaprzeczenie logiczne,

‘

’ – opcjonalne oznacza argument dodatni,

‘

’ – negacja arytmetyczna (uzupełnienie dwójkowe),

‘

’, ‘

.HIGH.

’ – starszy bajt szesnastobitowego słowa,

‘

’, ‘

.LOW.

’ – młodszy bajt szesnastobitowego słowa.

2. Operatory dwuargumentowe

‘

’ – pot˛egowanie całkowite,

‘

’ – mno˙zenie całkowite,

‘

’ – dzielenie całkowite,

‘

.SHR.

’ – przesuw w prawo,

‘

.SHL.

’ – przesuw w lewo,

‘

’ – suma arytmetyczna,

2, 8, 10 lub 16

1.1

Podstawowe wła´sciwo´sci asemblera

‘

’ – ró˙znica arytmetyczna,

‘

.AND.

’, ‘

’ – iloczyn logiczny,

‘

.OR.

’, ‘

’ – suma logiczna,

‘

.XOR.

’ – suma modulo 2 (ró˙znica symetryczna)

Warto´sci wyra˙ze ´n arytmetycznych zapisywane s ˛

a w słowie o´smio lub szesnastobitowym w za-

le˙zno´sci od kontekstu wyra˙zenia. Nale˙zy podkre´sli´c, ˙ze w asemblerze wyra˙zenia arytmetyczne
słu˙z ˛

a do obliczania warto´sci nazw, a nie do realizacji oblicze ´n przez program wynikowy. War-

to´sci wyra˙ze ´n arytmetycznych s ˛

a obliczane podczas procesu tłumaczenia, a nie w trakcie jego

realizacji.

W trakcie asemblacji mo˙zliwe jest stosowanie porówna ´n, których wynikiem jest

gdy wa-

runek jest spełniony lub

gdy nie jest. Operatory porówna ´n:

‘

’, ‘

.EQ.

’ – równo´s´c,

‘

’, ‘

.GT.

’ – wi˛eksze ni˙z,

‘

’, ‘

.LT.

’ – mniejsze ni˙z,

‘

.UGT.

’ – wi˛eksze ni˙z dla liczb bez znaku (ang. unsigned),

‘

.ULT.

’ – mniejsze ni˙z dla liczb bez znaku.

1.1.5

Tworzenie nazw i operacje na słowniku

Asembler w chwili rozpocz˛ecia tłumaczenia zawiera pewien wst˛epnie zdefiniowany słownik

Umieszczone s ˛

a w nim nazwy rozkazów procesora, nazwy dyrektyw, nazwy innych obiektów

j˛ezyka (np. nazwy rejestrów). Nazwy te mog ˛

a by ´c u˙zywane w programie wg. okre´slonych reguł,

zgodnie ze sposobem budowy rozkazów mikroprocesora i konstrukcji asemblera. Podstawowym
sposobem dopisania nowej nazwy do słownika jest umieszczenie jej w polu etykiety. W procesie
tłumaczenia nazwa b˛ed ˛

aca etykiet ˛

a uzyskuje warto´s´c równ ˛

a bie˙z ˛

acemu wska´znikowi umiesz-

czenia

. Bie˙z ˛

acy wska´znik umieszczenia jest zmienn ˛

a procesu tłumaczenia przybieraj ˛

ac ˛

a war-

to´sci równe adresom, pod którymi lokowany jest kod wynikowy. Programista powinien ustawi ´c
warto´s´c wska´znika przed napisaniem pierwszej linii programu zawieraj ˛

acej rozkaz. Do tego celu

słu˙zy dyrektywa

.ORG

, której argumentem jest warto´s´c adresu nadawana, przy ka˙zdym u˙zyciu

dyrektywy, bie˙z ˛

acemu wska´znikowi umieszczenia. W pakiecie 2500AD pomini˛ecie pocz ˛

atko-

wej dyrektywy

.ORG

powoduje przyj˛ecie domy´slnej warto´sci wska´znika umieszczenia

$=0000

Przykład:

;program przykładowy

.org 0

;$=0000h

ajmp start

.org 3

;obsługa przerwania INT0

Oznaczanym ‘

’

ORIGIN

Programowanie w j˛ezyku asembler

int0:

acall 100h ;prze´

slij komunikat na port P1

reti

.org 30h

start:

acall 40h

;inicjacja mikrokontrolera

czekaj: nop

ajmp czekaj

;czekaj na przerwanie

Innym sposobem dopisania nazwy do słownika, czyli nadania jej warto ´sci, jest u˙zycie jednej
z dyrektyw

.SET

lub

.EQU

, których argumentem jest wyra˙zenie arytmetyczne. Ró˙znica pomi˛e-

dzy

.SET

.EQU

sprowadza si˛e do tego, ˙ze nazwa zdefiniowana przez

.SET

mo˙ze by ´c w tym

samym programie okre´slana wielokrotnie w ró˙znych miejscach – nazwa redefiniowalna. Nato-
miast zdefiniowanie nazwy dyrektyw ˛

.EQU

wyklucza jej powtórne okre´slenie. Nazwa taka jest

nieredefiniowajna i nazywana jest cz˛esto absolutn ˛

Program tłumacz ˛

acy musi jednoznacznie przypisa ´c ka˙zdej nowej nazwie odpowiedni ˛

a war-

to´s´c. Proces tłumaczenia przebiega sekwencyjnie linia po linii od pocz ˛

atku programu. Ist-

nieje mo˙zliwo´s´c wielokrotnego definiowania tych samych nazw, a ponadto mo˙ze si˛e zdarzy ´c, ˙ze
w procesie tłumaczenia danej linii nazwa w niej u˙zyta nie została jeszcze zdefiniowana. Z po-
wy˙zszych powodów ka˙zdej tworzonej przez programist˛e nazwie musz ˛

a by ´c przyporz ˛

adkowane

atrybuty maj ˛

ace posta´c jednobitowej informacji towarzysz ˛

acej nazwie. Podstawowe atrybuty to:

1. warto´s´c (

– brak warto´sci,

– jest warto´s´c) ,

2. logiczne – redefiniowalno´s´c

Atrybut okre´slono´sci mówi o tym, czy w chwili tłumaczenia danej linii nazwa ma ju˙z warto ´s´c.
Warunkiem koniecznym poprawno´sci programu jest to, aby po przetłumaczeniu ostatniej linii
programu wszystkiem nazwy w słowniku były okre´slone.

1.1.6

Dyrektywy rezerwacji pami ˛eci

Słu˙z ˛

a do rezerwowania pami˛eci operacyjnej na pola robocze programu (s ˛

a to elementy pa-

mi˛eci danych) oraz do ustalania pocz ˛

atkowych warto´sci tych pól.

Dyrektywa

.DB

.DB lista_argumentów

Po przetworzeniu tej dyrektywy w kolejnych bajtach kodu wynikowego s ˛

a umieszczane warto ´sci

odpowiednich wyra˙ze ´n arytmetycznych lub warto´sci kodów ASCII znaków tworz ˛

acych stałe

znakowe.

Dyrektywa

.DW

Dyrektywa ta ma analogiczn ˛

a składni˛e jak

.DB

, z tym ˙ze jej argumenty słu˙z ˛

a do okre ´slania

warto´sci szesnastobitowych.

1.2

Makroasembler

Dyrektywa

.DS

Słu˙zy do rezerwacji liczby komórek okre´slonej przez parametr b˛ed ˛

acy jej argumentem.

W rezerwowany obszar nie jest wpisywana ˙zadna informacja lub jest on zerowany (na ogół
na ˙z ˛

adanie programisty).

1.1.7

Dyrektywa ko ´

ncz ˛

aca program

Dyrektyw ˛

a ko ´ncz ˛

ac ˛

a program jest dyrektywa

.END

1.2

Makroasembler

1.2.1

Ogólne wła ´sciwo ´sci makroasemblera

Makroasembler jest asemblerem rozsze˙zonym o dodatkowe dyrektywy i konstrukcje, któ-

rych u˙zycie pozwala programi´scie na wykonanie pewnych operacji na tek´scie programu ´zródło-
wego. W wyniku tych operacji mo˙zna:

kre´sli´c warunek uwzgl˛ednienia lub zignorowania fragmentu programu ´zródłowego,

zdefiniowa´c pewn ˛

a instrukcj˛e, której u˙zycie jest równoznaczne wstawieniu ci ˛

agu linii pro-

gramu,

spowodowa´c wstawienie w program ´zródłowy ci ˛

agu linii skojarzonych z wcze´sniej okre-

´slon ˛

a instrukcj ˛

W przypadku makroasemblera proces tłumaczenia ró˙zni si˛e w pewnym stopniu od tłumaczenia
w prostym asemblerze. Ka˙zda wczytana linia podlega wst˛epnej analizie i ew. przetworzeniu.
W wyniku tego linia mo˙ze:

zosta´c zignorowana,

by´c przekazana do dalszej asemblacji bez zmian,

doprowadzi´c do wytworzenia ci˛egu linii z jednej linii wczytanej.

Operacje te zawsze poprzedzaj ˛

a wła´sciwe tłumaczenie w sensie prostego asemblera.

1.2.2

Asemblacja warunkowa

Podstawowa konstrukcja programowa słu˙z ˛

aca do warunkowego tłumaczenia programu ma

nast˛epuj ˛

ac ˛

a posta´c:

.if [warunek]

;program tłumaczony je´

sli warunek spełniony (1)

Programowanie w j˛ezyku asembler

.else

;program tłumaczony je´

sli warunek nie jest spełniony (0)

.endif

Dyrektywa

.ELSE

nie jest obligatoryjna. Jej brak oznacza, ˙ze dany fragment programu jest tłu-

maczony, lub nie, bez ˙zadnej alternatywy. Argument dyrektywy

.IF

okre ´sla warto´s´c logiczn ˛

w ten sposób, ˙ze warto´s´c wyra˙zenia arytmetycznego u˙zytego jako argument ró˙znej od zera od-
powiada prawda, warto´sci równej zero odpowiada fałsz.

1.2.3

Makrodefinicje

Makrodefinicje definuje si˛e przez umieszczenie fragmentu programu ´zródłowego mi˛edzy

dyrektywami

.MACRO

.ENDM

w nast˛epuj ˛

acy sposób:

nazwa: .macro lista,parametrów,formalnych

;tre´

s´

c makrodefinicji

.endm

Przykład:

wstaw:

.macro rozkaz, warto´

s´

rozkaz

etykieta: .db warto´

s´

.endm

Tre´s´c makrodefinicji mo˙ze stanowi´c dowolny ci ˛

ag znaków, który nie musi miec składni popraw-

nej instrukcji i mo˙ze si˛e składa´c z praktycznie dowolnej liczby linii. Ogólnie definicja makroin-
strukcji słu˙zy do tego, aby za pomoc ˛

a jednej linii programu wstawi ´c ci ˛

ag linii okre´slony w tej

definicji. Lini˛e zawieraj ˛

ac ˛

a nazw˛e makrodefinicji nazywa si˛e wywołaniem makroinstrukcji. Za-

wiera ona w polu parametrów ci ˛

ag wyra˙ze ´n arytmetycznych w liczbie odpowiadaj ˛

acej liczbie

parametrów formalnych. Argumenty te nazywa si˛e parametrami aktualnymi. Makroasembler
przetwarzaj ˛

ac wywołanie makroinstrukcji (rozwijaj ˛

ac makroinstrukcj˛e) zast˛epuje odpowiednie

parametry formalne ich aktualnymi warto´sciami. Wywołanie mo˙ze by´c powtarzane dowoln ˛

ilo´s´c razy.

1.3

Tworzenie programów w postaci modułowej

1.3.1

Moduły programowe

Ko´ncowa posta´c programu wynikowego powstaje z reguły jako wynik scalania wielu jego

ró˙znych fragmentów. Przyczyny tego maj ˛

a ró˙zny charakter. Wynikaj ˛

a one przede wszystkim

1.3

Tworzenie programów w postaci modułowej

z konieczno´sci tworzenia programu przez zespół programistów, a zatem podziału na fragmenty
tworzone równolegle. Bardzo cz˛esto korzysta si˛e przy tym z bibliotek programów standar-
dowych (np. mno˙zenia i dzielenia zmiennoprzecinkowego, konwersji liczb. . . ) tworzonych
i przechowywanych w postaci odr˛ebnych modułów. Równie˙z wła´sciwo´sci fizyczne oprogra-
mowywanego procesora zmuszaj ˛

a do wyodr˛ebnienia fragmentów programu. Na przykład dla

mikrokontrolerów z rozdzielon ˛

a pami˛eci ˛

a programu i danych kod wynikowy trzeba rozdzieli ´c

zgodnie z przeznaczeniem do odpowiednich rodzajów pami˛eci. Podział logiczny dokonywany
jest przez programist˛e w celu wyodr˛ebnienia samodzielnych fragmentów nazywanych proce-
durami. Z reguły procedura jest podprogramem komunikuj ˛

acym si˛e z innymi procedurami za

pomoc ˛

a okre´slonych standardów przekazywania danych. Zatem procedury mog ˛

a by ´c budowane

niezale˙znie – zmiany wprowadzone w ich obr˛ebie nie maj ˛

a bezpo´sredniego wpływu na inne

procedury. Taki sposób tworzenia programu nazywany jest modularnym i stanowi jeden z pod-
stawowych standardów dobrego programowania.

Podstawow ˛

a jednostk ˛

a programow ˛

a z punktu widzenia asemblera jest moduł

. Jest to taki

ci ˛

ag linii programu, który dla asemblera stanowi jedn ˛

a cało´s´c. Oznacza to, ˙ze dla ka˙zdego

modułu asembler rozpoczyna swoje działanie od pocz ˛

atku (mówi si˛e, ˙ze ma miejsce restart

asemblera). Przede wszystkim modułem jest plik z programem ´zródłowym. Mo˙zna jednak
wyodr˛ebni´c moduły w ramach pojedynczego pliku. Słu˙z ˛

a do tego dyrektywy asemblera

.MOD

.ENDMOD

Z tego, ˙ze poszczególne moduły tłumaczone s ˛

a niezale˙zne, a nast˛epnie zestawiane w jedn ˛

cało´s´c, wynikaj ˛

a dwa istotne fakty:

kod programu uzyskany w wyniku asemblacji musi mie ´c tak ˛

a postac aby mógł by´c umiesz-

czony w dowolnym obszarze pami˛eci – posta ´c taka nazywa si˛e postaci ˛

a relokowaln ˛

(przesuwaln ˛

a),

z konieczno´sci tworzenia programów z po´srednich postaci przesuwalnej wynika potrzeba
dwustopniowej realizacji procesu tłumaczenia (rys. 1.2). W pierwszej fazie przy u˙zyciu
asemblera tworzone s ˛

a programy w postaci relokowalnej, w drugiej fazie moduły relo-

kowalne s ˛

a zespalane w procesie konsolidacji

w jedn ˛

a cało´s´c lokowan ˛

a w obszarach

pami˛eci o ´sci´sle okre´slonych adresach. T ˛

a drug ˛

a faz˛e realizuje program nazywany konso-

lidatorem lub programem ł ˛

acz ˛

acym

Techniczne aspekty procesu konsolidacji wymagaj ˛

a podziału modułów na mniejsze cz˛e ´sci, ele-

mentarne z punktu widzenia konsolidatora. Wynika to przedewszystkim z konieczno ´sci podziału
ka˙zdego modułu na cz˛e´sci zawieraj ˛

ace program i dane, a tak˙ze na inne fragmenty zwi ˛

azane ze

specyfik ˛

a konstrukcji procesera. Dla INTEL 8051 wyodr˛ebnianie fragmentów programu zwi ˛

zane jest z podziałem pami˛eci RAM na wewn˛etrzn ˛

a i zewn˛etrzn ˛

a, wydzieleniem rejestrów ro-

boczych i specjalnych oraz pami˛eci adresowanej bitowo.

Definiuje si˛e poj˛ecie sekcji

lub segmentu jako takiego, spójnego logicznie, fragmentu pro-

gramu, który jest traktowany przez konsolidator jako jedna elementarna cało ´s´c. Oznacza to, ˙ze

ang. module

ł ˛

aczenia, linkowania

ang. linker

ang. section

Programowanie w j˛ezyku asembler

Asembler

Moduł 1

Moduł n

Asembler

Konsolidator

Program

wynikowy

*.obj

*.asm

*.obj

*.exe

Rysunek 1.2: Proces tworzenia programów w postaci modułowej

mo˙zna wskaza´c konsolidatorowi adres, pod którym nale˙zy umie´sci´c dan ˛

a sekcj˛e oraz dodatkowe

parametry okre´slaj ˛

ace typ sekcji (np. sekcja z programem, danymi, sekcja rejestrowa. . . ).

Bior ˛

ac pod uwag˛e, ˙ze w procesie konsolidacji zespalane mo˙ze by ´c wiele modułów w ka˙z-

dym z nich mo˙zna na ogół wyró˙zni´c sekcje tego samego typu. Sekcje takie powinny by ´c ł ˛

aczone

ze sob ˛

a i umieszczane w zwartym obszrze pami˛eci. Zatem cz˛esto wygodzniej jest operowa ´c na

wi˛ekszych cało´sciach nazywanych grupami sekcji lub grupami. Grupa jest to zespół sekcji o ta-
kich samych nazwach w ró˙znych modułach traktowanych przez konsolidator tak jak pojedyncza
sekcja.

1.3.2

Absolutne i wzgl ˛edne tłumaczenie modułów programowych

Budowanie programu w postaci modułowej wymaga uzyskiwania po asemblacji kodu w po-

staci przesuwalnej umo˙zliwiaj ˛

acej ulokowanie modułu w dowolnym obszarze pami˛eci. Powo-

duje to z kolei konieczno´s´c przyporz ˛

adkowania ka˙zdemu modułowi adresu bazowego, który

stanowi adres odniesienia, wzgl˛edem którego okre´slane s ˛

a warto´sci wszystkich przesuwalnych

(relokowalnych) nazw w danym module. Ilustruje to poni˙zszy przykład

;program wyprowadzania komunikatu przez port P1

;adres pocz ˛

atku komunikatu w DPTR

.org

BAZA

pisz_kom1:

mov

dptr,#komunikat_1 ;ładuj rejestr bazowy

mov

r0,#0

;licznik znaków

dalej:

mov

a,r0

movc

a,@a+dptr

;pobierz znak

cjne

a,#0,nie_koniec ;czy koniec ła´

ncuch znaków?

ret

;tak

nie_koniec:

mov

p1,a

;nie

inc

ajmp

dalej

;komunikat nr 1

kom_end:

.equ 0

;znak ko´

nca

komunikat_1: .db ’komunikat 1’,0ah,0dh,kom_end

U˙zyta w nim nazwa

BAZA

symbolizuje jedynie adres bazowy i słu˙zy do uwidocznienia relacji mi˛edzy tym adresem

a warto´sci ˛

a nazw relokowalnych.

1.3

Tworzenie programów w postaci modułowej

Program ´zródłowy

Program wynikowy

aders (hex)

kod (hex)

.org BAZA

BAZA

pisz_kom1:

mov

dptr,#komunikat

BAZA

90 00 10

mov

r0,#0

BAZA+0003

78 00

dalej:

mov

a,r0

BAZA+0005

movc a,@a+dptr

BAZA+0006

cjne a,#0,nie_koniec

BAZA+0007

b4 00 01

ret

BAZA+000a

nie_koniec:

mov

p1,a

BAZA+000b

f5 90

inc

BAZA+000d

ajmp dalej

BAZA+000e

01 05

kom_end:

.equ 0

BAZA+0010

komunikat_1:

.db ’komunikat 1’,0ah,0dh,kom_end

BAZA+0010

6b 6f 6d

75 6e 69

itd. . .

Analizuj ˛

ac uzyskany program wynikowy mo˙zna stwierdzi ´c, ˙ze adres ka˙zdej komórki pami˛eci

daje si˛e wyrazi´c w postaci sumy dwóch składników: adresu bazowego (który tutaj symbolizuje
ogólnie nazwa

BAZA

) oraz cz˛e´sci stałej. Adres bazowy jest jednakowy dla wszystkich komórek

przechowuj ˛

acych kod wynikowy danego modułu programowego, przy czym ulega on zmianie

wraz ze zmian ˛

a poło˙zenia modułu w pami˛eci. Cz˛e´s´c stała adresu komórki nie zmienia si˛e nie-

zale˙znie od lokalizacji modułu bowiem wskazuje ona odległo´s´c od pocz ˛

atku modułu. Z powy˙z-

szego wynika, ˙ze operacje zwi ˛

azane z działaniem na adresach komórek przy zmianie poło˙zenia

modułu w pami˛eci s ˛

a proste – polegaj ˛

a na dodaniu do ka˙zdej warto ´sci stałej, zwi ˛

azanej nie-

rozł ˛

acznie z ka˙zdym kodem rozkazu uzyskanym po asemblacji, adresu bazowego okre ´slaj ˛

acego

aktualne poło˙zenie modułu w pami˛eci. Programista ma do dyspozycji szereg mo˙zliwo ´sci od-
działywania na adres bazowy modułu – zarówno przy u˙zyciu asemblera jak i w trakcie procesu
konsolidacji.

1.3.3

Atrybuty nazw w programach modułowych

W ka˙zdym programie wyst˛epuj ˛

a etykiety, czyli nazwy symblolizuj ˛

ace adresy okre ´slonych

miejsc w pami˛eci. W trakcie zmiany poło˙zenia modułu w pami˛eci musz ˛

a one podlega ´c takim

samym regułom przemieszczania jak inne adresy. Ponadto mo˙zna równie˙z definiowa ´c nazwy,
które zachowuj ˛

a stał ˛

a warto´s´c niezale˙znie od poło˙zenia modułu. Dla powy˙zszego przykładu

mo˙zna zestawi´c nast˛epuj ˛

ac ˛

a tablic˛e nazw:

Nazwa

Warto´s´c

Atrybyt absolutno´sci

pisz_kom1

BAZA+0000

dalej

BAZA+0005

nie_koniec

BAZA+000b

komunikat_1

BAZA+0010

kom_end

Programowanie w j˛ezyku asembler

Nazwy, których warto´s´c zale˙zy od poło˙zenia modułu w pami˛eci nazywane s ˛

a przesuwalnymi

(relokowalnymi), natomiast nazwy o stałych warto´sciach – absolutnymi. Ka˙zdej nazwie mo˙zna
przypisa´c atrybut absolutno´sci, który stanowi dla programu tłumacz ˛

acego wska´znik czy nale˙zy,

lub nie, modyfikowa´c nazw˛e przy zmianie poło˙zenia modułu.

1.3.4

Relokowalo ´s ´c modułów

Mo˙zna nakaza´c tłumaczenie fragmentów programu w sposób absolutny umieszczaj ˛

ac je

mi˛edzy dyrektywami:

.ABSOLUTE

.RELATIVE

Dyrektywa

.ABSOLUTE

powoduje przej´scie asemblera w tryb tłumaczenia absolutnego, co ozna-

cza, ˙ze wszystkie nazwy w tym trybie maj ˛

a atrybut absolutno´sci równy 1. Dyrektywa

.RELATIVE

przywraca tryb wzgl˛edny działania asemblera. Tryb ten jest zazwyczaj trybem domy ´slnym
asemblera o ile programista nie naka˙ze inaczej.

Tryb absolutny powinien by´c stosowany tylko w szczególnych przypadkach, poniewa˙z po-

ł ˛

aczenie modułów absolutnych z relokowalnymi mo˙ze prowadzi ´c do utworzenia niepoprawnych

sekwencji programowych. Poniewa˙z cz˛esto przyjmuje si˛e zasad˛e, ˙ze nie wyró˙znia si˛e w spe-
cjalny sposób modułów absolutnych, w zwi ˛

azku z czym s ˛

a one ł ˛

aczone z innymi modułami na

takich samych zasadach. Oznacza to, ˙ze w module absolutnym mog ˛

a ulega ´c przesuni˛eciu adresy

komórek pami˛eci natomiast nazwy definiowane w tym module pozostaj ˛

a stałe. Przykład:

adres

kod

.absolute

.org 20

petla:

nop

0020

ajmp petla

0021

01 20

Nazwa

PETLA

w tym przykładzie uzyskuje warto´s´c absolutn ˛

0020h

. Załó˙zmy, ˙ze ł ˛

aczy si˛e po-

wy˙zszy program z innymi, w efekcie czego program ten zostaje umieszczony od adresu

1000h

adres

kod

petla:

nop

1020

ajmp petla

1021

01 20

Zatem posta´c ko ´ncowa (wynikowa) tego fragmentu programu jest niepoprawna. Wynika st ˛

wniosek, ˙ze za wyj ˛

atkiem szczególnych przypadków moduły programowe nale˙zy tłumaczy ´c

w sposób wzgl˛edny, a ich wła´sciw ˛

a lokalizacj˛e w pami˛eci okre´sla´c dopiero w trakcie konsolida-

cji.

Przykład ten ilustruje równie˙z specyfik˛e stosowania dyrektywy

.ORG

w modułach przesu-

walnych – wskazuje ona odległo´s´c miejsca w module programowym od pocz ˛

atku modułu wska-

zywanego przez adres bazowy. Standardowo przyjmuje si˛e w procesie asemblacji, ˙ze adres
bazowy ka˙zdego z modułów równa si˛e zera. W trakcie konsolidacji do tego adresu dodawany

1.3

Tworzenie programów w postaci modułowej

jest adres przesuni˛ecia modułu (ang. offset), który jest dodawany do wszystkich adresów wska-
zywanych przez dyrektyw˛e

.ORG

. Powoduje to, ˙ze argument tej dyrektywy i przesuni˛ecie dodaj ˛

si˛e.

1.3.5

Współu˙zywanie nazw w modułach

Budowanie programu w postaci modułowej, a nast˛epnie ł ˛

aczenie modułów w jeden wspólny

program wymaga definiowania nazw wspólnych dla wielu modułów. Równie˙z w przypadku
doł ˛

aczania modułów bibliotecznych niezb˛edne jest u˙zycie nazw definiowanych przez moduły.

To wszystko powoduje, ˙ze w trakcie asemblacji w pewnych modułach pojawiaj ˛

a si˛e nazwy,

których warto´sci nie s ˛

a okre´slone w danym module.

Nazwa, która jest definowana w danym module i jest udost˛epniana równie˙z na zewn ˛

atrz

modułu, co oznacza ˙ze jest wa˙zna w całym programie, nazywana jest nazw ˛

a globaln ˛

a. Wskazy-

wanie nazw globalnych odbywa si˛e przy u˙zyciu dyrektywy:

.GLOBAL ci ˛

ag,nazw

Dyrektywa ta nadaje nazw ˛

a atrybut globalno´sci.

Nazwy, które s ˛

a u˙zywane w danym module, przy zało˙zeniu, ˙ze s ˛

a definiowane w innym, na-

zywane s ˛

a zewn˛etrznymi z punktu widzenia tego modułu. Nazwy takie wskazuje si˛e dyrektyw ˛

.EXTERNAL ci ˛

ag,nazw

U˙zycie tej dyrektywy powoduje nadanie wskazanym nazw ˛

a atrybutu zewn˛etrzno´sci.

Z powy˙zszych uwag wynika, ˙ze modułowe tworzenie programów wymaga wyposa˙zenia

nazw w trzy dodatkowe atrybuty: absolutno´sci, globalno´sci i zewn˛etrzno´sci. Atrybuty te s ˛

niezb˛edne w procesie konsolidacji do uzyskania kodu programu wynikowego i stwierdzenia
poprawno´sci wszystkich działa ´n składaj ˛

acych si˛e na ten proces.

Przykład ilustruj ˛

acy sposób posługiwania si˛e nazwami współu˙zywanymi w ró˙znych mody-

łach:

.module ;moduł 1

.global start

.external init

start: acall init

.endmod

.module ;moduł 2

.global init

init:

mov a,#10h

ret

.endmod

Programowanie w j˛ezyku asembler

1.3.6

Doł ˛

aczanie modułu zawieraj ˛

acego kod ´zródłowy programu

Podstawowy moduł programowy ma posta´c pliku. Wyró˙znikiem pliku jest jego nazwa

(w przykadku modułów asemblerowych wymagane jest rozszerzenie

*.asm

). Ka˙zdy moduł jest

tłumaczony oddzielnie, w wyniku czego uzyskiwany jest plik z kodem przesuwalnym (

*.obj

)

nosz ˛

acy na ogół tak ˛

a sam ˛

a nazw˛e jak plik ´zródłowy. Pliki z kodem przesuwalnym poddawane s ˛

konsolidacji polegaj ˛

acej na zespoleniu odpowiednich fragmentów programu (sekcji) z ró˙znych

modułów i lokowanie ich w wybranych obszarach pami˛eci.

Istnieje sposób bardzo prosty cho´c znacznie mniej elestyczny od wy˙zej wymienionego słu-

˙z ˛

acy do ł ˛

aczenia modułów. Jest ono wówczas wykonywane na poziomie tekstu programu ´zró-

dłowego za pomoc ˛

a dyrektywy:

.INCLUDE nazwa_pliku.asm

1.4

Sekcje

1.4.1

Typy sekcji

Sekcja – wyró˙zniony fragment programu stanowi ˛

acy elementarn ˛

a cało ´s´c z punktu widze-

nia konsolidatora. Nadaje on sekcji jedno stałe przesuni˛ecie (ang. offset). Cz˛esto takie same
konstrukcje programowe jak sekcje nazywane s ˛

a w innych asemblerach segmantami, przy czym

na ogół sposób definiowania segmentów nie pozwala na tak du˙z ˛

a eleastyczno ´s´c struktury pro-

gramu jak to ma miejsce w przypadku sekcji. Opisany sposób definiowania sekcji zwi ˛

azany jest

ze specyficznymi cechami budowy mikrokontrolerów rodziny INTEL 8051. Mo˙zna wskaza ´c
dwa sposoby definiowania sekcji: przy u˙zyciu standardowych dyrektyw tybów sekcji oraz jako
sekcji u˙zytkowanika.

U˙zycie standardowych typów sekcji powoduje, ˙ze w trakcie konsolidacji s ˛

a one traktowane

priorytetowo w stosunku do sekcji definiowanych przez u˙zytkownika. Oznacza to, ˙ze s ˛

a one lo-

kowane jako pierwsze, przy czym priorytet lokowania samych sekcji standardowych jest zgodny
z zestawieniem.

.CODE

– sekcja z programem,

.DATA

– sekcja z danymi,

.RSECT

– sekcja rejestrowa,

.BSECT

– sekcja w pami˛eci bitowej.

Typ

.CODE

ma najwy˙zszy priorytet, a ponadto jest standardowym (domy´slnym) typem sekcji

– ka˙zdemu fragmentowi programu ´zródłowego o nieokre´slonym typie sekcji nadawany jest ten
typ.

1.4

Sekcje

1.4.2

Składnia dyrektywy .SECTION

U˙zytkownik definiuje sekcje za pomoc ˛

a dyrektywy:

nazwa_sekcji: .SECTION argumenty_opcjonalne

Argumenty dyrektywy wskazuj ˛

a sposób lokowania sekcji w pami˛eci. Nazwa zdefiniowana przy

u˙zyciu dyrektywy

.SECTION

sama mo˙ze by´c u˙zywana jak dyrektywa, a konkretnie jako prze-

ł ˛

acznik sekcji. Przykład:

nop

;sekcja CODE

.DATA

;przeł ˛

acz na sekcj˛

e DATA

.ds 1

;bajt w sekcji DATA

SEKCJA_1 .SECTION

;definiuje i aktywizuje sekcj˛

e u˙

zytkownika

nop

;rozkaz w sekcji SEKCJA_1

.CODE

nop

;a ten w sekcji CODE

.SEKCJA_1 ;przeł ˛

acza na sekcje u˙

zytkownika

nop

;sekcja u˙

zytkownika mo˙

ze zawiera´

c rozkazy

.ds 1

;i dane

Powy˙zszy przykład pokazuje, ˙ze poszczególne fragmenty programu mo˙zna zestawia ´c w sekcje
w sposób praktycznie dowolny. Bior ˛

ac pod uwag˛e, ˙ze sekcje tego samego typu (w przypadku

sekcji u˙zytkownika oznacza to sekcje o tej samej nazwie) z ró˙znych modułów s ˛

a zespalane

w jedn ˛

a cało´s´c przez konsolidator daje to programi´scie elastyczne narz˛edzie tworzenia struk-

tur programowych dostasowanych zarówno do specyfiki budowy pami˛eci mikrokontrolera jak
i konstrukcji programu.

1.4.3

Sekcje rejestrowe i sekcje bitowe

Sekcje rejestrowe – konstrukcje obejmuj ˛

ace pojedyncze rejestry lub ich grupy. Definiowane

s ˛

a za pomoc ˛

a dyrektywy

.RSECT

lub przy u˙zyciu modyfikatora

REG

po dyrektywie

.SECTION

Jedyn ˛

a dyrektyw ˛

a, która mo˙ze wyst˛epowa ´c wewn ˛

atrz sekcji rejestrowej jest dyrektywa

.DS

Sposób tworzenia sekcji ilustruje przykład:

.RSECT

;przeł ˛

acza na sekcj˛

e rejestrow ˛

reg1:

.ds 1

sekcja_rej: .section reg ;definiuje rejestrow ˛

a sekcj˛

e u˙

zytkownika

reg2:

.ds 1

reg3:

.ds 1

Sekcje bitowe – umo˙zliwiaj ˛

a indywidualne adresowanie bitów. Mo˙zna utworzy ´c j ˛

a za po-

moc ˛

a standardowej dyrektywy

.BSECT

lub za pomoc ˛

a modyfikatora

BIT

. Wewn ˛

atrz sekcji bito-

wej mo˙zna u˙zywa´c jedynie dyrektywy

.DS

Programowanie w j˛ezyku asembler

1.5

Lokowanie sekcji w pami ˛eci

1.5.1

Sposoby lokowania sekcji

Umieszczenie sekcji w okre´slonym miejscu pami˛eci polega na podaniu adresu sekcji, tj.

adresu pierwszej komórki pami˛eci zadeklarowanej jako pocz˛etek sekcji oraz ew. adresu ko ´nca
sekcji (chocia˙zby w celu unikni˛ecia braku pamieci – przepełnienia). Adres sekcji mo˙ze by ´c
wskazany w programie ´zródłowym jako argument dyrektywy

.SECTION

lub w trakcie konsoli-

dacji. Zalecany jest drugi sposób bo zapewnia znacznie wi˛eksz ˛

a elastyczno ´s´c procesu lokowa-

nia.

Mo˙zna wyró˙zni´c kilka rodzajów sekcji ze wzgl˛edu na ich sposób lokowania w pami˛eci.

Bior ˛

ac pod uwag˛e sposób wykorzystania celowe jest wyodr˛ebnienie trzech rodzajów sekcji:

sekcje bezpo´srednio lokowane w pami˛eci (ang. direct),

sekcje po´srednio lokowane w pami˛eci (ang. indirect),

sekcje referencyjne (ang. reference only).

Sekcja bezpo´srednia charakteryzuje si˛e tym, ˙ze jest u˙zywana w tym obszarze pami˛eci, w którym
została ulokowana w trakcie konsolidacji. Oznacza to, ˙ze kod wynikowy i wszystkie nazwy
zdefiniowane dla danej sekcji nie podlegaj ˛

a ˙zadnym zmianom w trakcie realizacji programu

u˙zytkowego.

Po´srednie lokowanie sekcji polega na tym, ˙ze sekcja po konsolidacji jest umieszczona w jed-

nym miejscu, a nast˛epnie po rozpocz˛eciu pracy programu zostaje przeniesiona w inne niejsce
gdzie jest u˙zytkowana. Oznacza to, ˙ze warto´sci wszystkich nazw definiowanych w danej sek-
cji s ˛

a wyznaczane nie dla miejsca umieszczenia jej po konsolidacji lecz zgodnie z lokalizacj ˛

sekcji w trakcie jej u˙zytkowania przez program (np. dla sekcji z danymi przemieszczenie jej
z pami˛eci programu ROM do pami˛eci danych RAM mo˙ze mie ´c na celu umo˙zliwienie jej aktu-
alizacji w trakcie realizacji programu).

Sekcja refernecyjna jest sekcj ˛

a pust ˛

a tzn. w trakcie konsolidacji nie jest w niej lokowany

˙zaden kod wynikowy. Jest kreowana jedynie dla celów wyznaczania warto ´sci adresów niezb˛ed-

nych dla programu u˙zytkowego. (np. mo˙ze to by ´c tablica w pami˛eci danych, której adresy
s ˛

a wyznaczane w trakcie kosolidacji i przekazywane pod postaci ˛

a odpowiednich nazw do pro-

gramu u˙zytkowego w celu umo˙zliwienia działania na elementach tej tablicy.)

1.5.2

Zwi ˛

azki mi ˛edzy sekcjami

Sekcje po przeprowadzeniu konsolidacji mog ˛

a by ´c:

odseparowane tzn. lokowane w oddzielnych obszarach pami˛eci np. jako sekcje z danymi
i programem,

sklejone (ang. stacked),

nało˙zone na siebie (ang. common).

1.5

Lokowanie sekcji w pami˛eci

Pamie˛c´

Sekcja 1

Sekcja 2

Pamie˛c´

Adres kon´ca sekcji 2

Adres pocz. sekcji 1

Sekcja 1

Sekcja 2

Adres kon´ca sekcji1 =
Adres pocz. sekcji 2

Pamie˛c´

Sekcja 1

Sekcja 2

Adres kon´ca sekcji 1

Adres kon´ca sekcji 2

Adres pocz. sekcji 1 =
Adres pocz. sekcji 2

odseparowane

sklejone

nało˙zone na siebie

Rysunek 1.3: Zwi ˛

azki mi˛edzy sekcjami

1.5.3

Sterowanie lokowaniem sekcji

Rozmieszczenie sekcji w pami˛eci mo˙ze by ´c sterowane z poziomu asemblera za pomoc ˛

argumentów dyretywy

.SECTION

OFFSET

Argument

OFFSET adres

powoduje bezpo´srednie umieszczenie sekcji pod wskaza-

nym adresem przy zało˙zeniu, ˙ze adres pocz ˛

atku sekcji wynosi zero. U˙zycie dyrek-

tywy:

sekcja1:

.section offset 100h

powoduje utworzenie sekcji o nazwie “

sekcja1

” i nakazuje ulokowanie jej w pa-

mi˛eci programu z przesuni˛eciem

100h

w stosunku do pocz ˛

atku sekcji okre ´slonego

dyrektyw ˛

.ORG

INDIRECT

Po´srednie lokowanie sekcji umo˙zliwia argument

INDIRECT addres

, gdzie

adres

wskazuje miejsce, do którego sekcja zostanie przeniesiona po rozpocz˛eciu pracy
programu. U˙zycie dyrektywy:

sekcja1:

.section offset 100h, indirect 200h

spowoduje fizyczne umieszcznie sekcji w pami˛eci programu ROM pocz ˛

awszy od

adresu

100h

, przy czym etykiety definiowane w tej sekcji uzyskuj ˛

a warto ´sci, jak

gdyby sekcja była lokowana od adresu

200h

. Po inicjacji program u˙zytkowy w pierw-

szej fazie działania przemieszcza sekcje z pami˛eci ROM do pami˛eci RAM pod adres

200h

i dysponuj ˛

ac warto´sciami adresów wła´sciwymi dla tego obszaru mo˙ze od tego

momentu u˙zywa´c przemieszczonej sekcji.

STACKED

Argument

STACKED

powoduje lokoawnie sekcji tu˙z nad sekcj ˛

a poprzedni ˛

a. Nazywa

si˛e to sklejaniem sekcji. Sekcja poprzednia musi by ´c zdefiniowana jako bezpo´sred-
nia. Np. zdefiniowanie sekcji w sposób jak ni˙zej:

sekcja1:

.section offset 100h

;sekcja bezpo´

srednia

a nast˛epnie:

sekcja2:

.section stacked

powoduje, ˙ze

sekcja2

jest lokowana tu˙z nad

sekcja1

Programowanie w j˛ezyku asembler

AUTO_STACK

W praktyce cz˛esto jest stosowana technika polegaj ˛

aca na sklejaniu sekcji z frag-

mentów umieszczonych w ró˙znych plikach (modułach). Sklejanie takich fragmen-
tów umo˙zliwia argument

AUTO_STACK

. Nazwy sklejanych fragmentów definiowa-

nych równie˙z jako sekcje musz ˛

a by´c we wszystkich plikach jednakowe.

REF_ONLY

Wskazanie sekcji referencyjnej nast˛epuje za pomoc ˛

a argumentu

REF_ONLY

. U˙zycie

dyrektywy:

sekcja1:

section offset 100h, ref_only

spowoduje jedynie takie wyznaczenie adresów i nazw zwi ˛

azanych z

sekcja1

ja-

kie s ˛

a wła´sciwe w przypadku umieszczenia jej z przesuni˛eciem

100h

. Jednak bez

fizycznego umieszczania sekcji w tym obszarze.

RANGE

Ka˙zdej sekcji mo˙zna przypisa´c obszar umieszczenia za pomoc ˛

a parametrów:

RANGE adres1 adres2

COMMON

Sekcje o tej samej nazwie w ró˙znych plikach mog ˛

a by´c nakładane na siebie przy

u˙zyciu arguemntu

COMMON

. Jednak w trakcie deklaracji sekcji tego rodzaju w pierw-

szym pliku nie mo˙zna u˙zy´c argumentu

COMMON

. Sekcja w pozostałych plikach mu-

sz ˛

a by´c natomiast deklarowane z tym argumentem oraz musz ˛

a by´c typu referencyj-

nego, gdy˙z inaczej w pliku wynikowym pojawiłoby si˛e wiele rekordów z kodem
odnosz ˛

acym si˛e do tego obszaru adresowego.

1.5.4

Konsolidacja programu o strukturze sekcyjnej

Wskazywanie miejsca, gdzie wstawi´c sekcj˛e realizowane z poziomu asemblera ma ograni-

czone zastosowanie. Nie wszystkie działania mog ˛

a by ´c wykonane (np. te z doł ˛

aczaniem modu-

łów bibliotecznych), a ponadto ich elastyczno´s´c jest znacznie mniejsza od działa ´n realizowanych
przez konsolidator. A tak˙ze ka˙zda zmiana sposobu i miejsca lokowania sekcji zmusza do zmiany
programu ´zródłowego, który tym samym musi by ´c znów tłumaczony. Wła´snie dlatego zalecane
jest, aby wszystkich manipulacji na sekcjach dokonywa ´c z poziomu konsolidatora (w trakcie
konsolidacji). Cz˛esto konsolidatory wyposa˙zone s ˛

a w ´srodki przeznaczone do tego celu.

Konsolidator pakietu 2500AD dysponuje specjalnym j˛ezykiem przeznaczonym do przekazy-

wania polece ´n konsolidacji w postaci pliku wsadowego. Nazwy polece ´n stanowi ˛

a słowa angiel-

skie dobrane tak, ˙ze ich zestawienia stanowi ˛

a pełny komentarz do działa ´n zleconych konsoli-

datorowi. Zatem analiza pliku wsadowego steruj ˛

acego procesem konsolidacji w takim trybie,

nazywanym rozszerzonym (ang. enhanced) pozwala na uzyskanie pełnego obrazu konsolidacji.
Zmiany tego procesu wymagaj ˛

a tylko poprawek w pliku wsadowym, co realizuje si˛e za pomoc ˛

prostego edytora tekstu.

Przykład 1:

Załó˙zmy, ˙ze konsolidowany jest pojedynczy plik ´zródłowy stanowi ˛

acy jedn ˛

a sek-

cj˛e. Zawiera dyrektyw˛e

ORIGIN

wskazuj ˛

ac ˛

a adres pocz ˛

atku programu. Plik wsadowy steruj ˛

acy

konsolidacj ˛

a program w trybie rozszerzonym ma posta ´c:

version v0.1.1

option: executable

1.5

Lokowanie sekcji w pami˛eci

input: nazwa_pliku_wej´

sciowego

output: nazwa_pliku_wyj´

sciowego

locate: CODE at 0h

Poszczególne linie w tym przykładzie zawieraj ˛

a polecenia konsolidacji, przy czym

‘:

’ stanowi

separator oddzielaj ˛

acy nazw˛e polecenia od jego argumentu. Znaczenie poszczególnych linii:

1. Słowo kluczowe

version

wskazuje, ˙ze dany plik zawiera polecenia w trybie rozszerzo-

nym. Jest to niezb˛edne, bo stosowany jest tak˙ze standardowy tryb wsadowy, w którym
polecenia maj ˛

a inn ˛

a posta´c.

2. Słowo

option

wskazuje rodzaj pliku wyj´sciowego:

executable

– plik z kodem binarnym,

intel hex

– plik z kodem w standardzie HEX Intela,

high level

– nakazuje utworzenie dodatkowego pliku wyj´sciowego z danymi nie-

zb˛ednymi w trakcie uruchamiania programu przy u˙zyciu symulatora,

load map

3. Argumentem polecenia

input

jest nazwa pliku wej´sciowego poddawanego konsolidacji.

4. Polecenie

output

zawiera nazw˛e pliku wyj´sciowego, którego rodzaj okre´slaj ˛

a argumenty

polecenia

option

5. Polecenie

locate

wskazuje adres umieszczenia poszczególnych sekcji. Interpretowane

jest jako dodatkowe przesuni˛ecie w stosunku do adresu pocz ˛

atku programu okre ´slonego

dyrektyw ˛

ORIGIN.

Przykład 2:

Dla zało˙ze ´n jak w poprzednim przykładzie nale˙zy zbudowa ´c plik wsadowy taki,

aby mo˙zna było przył ˛

aczy´c moduły biblioteczne, a plik wyj´sciowy był w standardzie

intel

hex

, a zarazem aby został utworzony plik uruchomieniowy za pomoc ˛

a symulatora. Plik konso-

lidacji ma wówczas posta´c:

version

option: loca map, intel hex

input: nazwa_pliku_wej´

sciowego

output: nazwa_pliku_wyj´

sciowego

library: nazwa_pliku bibliotecznego

locate: CODE at 0h

2 Programowanie w C

K rodziny Intel 8051

2.1

Proces uzyskiwania programu wynikowego dla programów w C

Pliki doła˛czene przez

uz˙ytkownika

w C

Plik z´ródłowy

Standardowe pliki nagłówkowe doła˛czane

na poziomie je˛zyka C (*.h)

Pliki doła˛czene przez

uz˙ytkownika

biblioteczne

Programy

Standardowe

programy

biblioteczne

Kompilator

asemblerowy

Plik z´ródłowy

programu rozruch.

Asembler

s´rodowisko (*.def)

Pliki definiuja˛ce

Pliki

relokowalne

rozruchowy

Konsolidator

Plik

Program

Bibliotekarz

Raport z kompilacji

(*.lst)

Pliki z kodem wynikowym

(*.hex, *.exe, *.sym, *.def)

programu (*.map)

Plik z mapa˛ pamie˛ci

Rysunek 2.1: Proces uzyskiwania programu wynikowego dla programów w C

Doprowadzenie programu napisanego w C do realizacji przez mikrokontroler (lub jego sy-

mulator) jest procesem wieloetapowym. Mo˙zna wyró˙zni ´c w nim conajmniej pi˛e´c niezb˛ednych
kroków:

napisanie w j˛ezyku asembler programu rozruchowego,

przetłumaczenie programu rozruchowego,

Programowanie w C µK rodziny Intel 8051

kompilacja programu w C do postaci asemblerowej, a nast˛epnie przetłumaczenie go do
postaci relokowalnej,

wskazanie standardowych plików bibliotecznych doł ˛

aczanych w trakcie konsolidacji,

konsolidacja programu rozruchowego, programu w C oraz programów bibliotecznych
w wymienionej kolejno´sci.

Programy w j˛ezyku C wymagaj ˛

a przygotowania ´srodowiska, w którym s ˛

a realizowane. Polega

to ogólnie na zarezerwowaniu miejsca w pami˛eci dla okre´slonego rodzaju danych, zainicjowa-
nia układów wej´scia-wyj´scia do komunikacji z otoczeniem, przygotowania stosu a nast˛epnie na
oddaniu sterowania do programu w C, który standardowo rozpoczyna si˛e od funkcji

main()

Powy˙zsze działania realizuje program rozruchowy (ang. runtime start up program), który jest
napisany w j˛ezyku asembler. Jest on zwykle dostarczany przez producenta kompilatora, mo˙ze
by´c równie˙z zbudowany przez u˙zytkownika. Jest on dostosowywany do ró˙znych typów mi-
krokontrolerów rodziny 8051 za pomoc ˛

a plików definiuj ˛

acych struktur˛e rejestrów. Maj ˛

a one

rozszerzenie

*.def

i doł ˛

aczane s ˛

a za pomoc ˛

a dyrektywy

include

. U˙zytkownik mo˙ze modyfi-

kowa´c te pliki, mo˙ze równie˙z tworzy´c własne pliki definicyjne.

Programy w C równie˙z wymagaj ˛

a doł ˛

aczenia plików definicyjnych, które maj ˛

a jednak nieco

inny charakter. S ˛

a to tzw. pliki nagłówkowe

słu˙z ˛

ace do tworzenia prototypów funkcji biblio-

tecznych. Ich brak uniemo˙zliwia działanie tych funkcji. U˙zytkownik mo˙ze doł ˛

acza ´c równie˙z

własne pliki nagłówkowe.

Tłumaczenie programu w C odbywa si˛e dwuetapowo. Najpierw program w C tłumaczony

jest na program w asemblerze, a nast˛epnie program asemblerowy tłumaczony jest do postaci
relokowalnej. U˙zywaj ˛

ac odpowiedniego przeł ˛

acznika kompilatora powy˙zsze etapy mo˙zna zre-

alizowa´c jako jedn ˛

a cało´s´c.

Postacie relokowalne programu w C i programu rozruchowego s ˛

a poddane nast˛epnie kon-

solidacji ł ˛

acznie z programami bibliotecznymi. Tego rodzaju programy s ˛

a dostarczane przez

producenta. Mo˙zna równie˙z tworzy´c własne programy biblioteczne. U˙zytkownik mo˙ze doł ˛

cza´c własne programy relokowalne do standardowej biblioteki za pomoc ˛

a programu o nazwie

librarian

. Wynikiem konsolidacji jest plik wykonywalny

*.exe

lub cz˛e´sciej jego posta´c he-

xadecymalna

*.hex

. Mo˙zna równie˙z uzyska´c pliki

*.sym

*.def

niezb˛edne gdy u˙zywa si˛e

symulatora. Ponadto programista mo˙ze za˙zyczy ´c sobie utworzenia raportu z kompilacji

*.lst

oraz pliku z map ˛

a programu

*.map

zawieraj ˛

acego dane na temat obszarów pami˛eci zajmowa-

nych przez sekcje oraz warto´sci nazw globalnych.

2.2

Program rozruchowy

2.2.1

Rodzaje programu rozruchowego

Program ten napisany jest w asemblerze i spełnia nast˛epuj ˛

ace zadania:

przygotowanie stosu i wywołanie pocz ˛

atkowej funkcji C (

main()

ang. header files

bibliotekarz

2.2

Program rozruchowy

zapewnienie komunikacji mi˛edzy fizycznym urz ˛

adzeniem wej´scia-wyj´scia (lub systemem

operacyjnym) a programem w C,

zarezerwowanie obszarów na dane,

przeniesienie danych z pami˛eci programu do pami˛eci danych.

Pakiet 2500AD dostarcza trzy rodzaje programów rozruchowych:

przeznaczonych do zastosowanie w sytuacji gdy do przechowywania danych u˙zywa si˛e
wył ˛

acznie wewn˛etrznej pami˛eci RAM. Jest to tzw. tryb wewn˛etrzny kompilatora (ang.

internal memory mode). Program rozruchowy nosi nazw˛e

c8051ir.src

. W przypadku

gdy u˙zywa si˛e symulatora nale˙zy zastosowa ´c wersj˛e

c851sir.src

przeznaczonych do u˙zytku wył ˛

acznie z zewn˛etrzn ˛

a pami˛eci ˛

a RAM jako miejsca przecho-

wywania danych programu w C, co nazywane jest trybem zewn˛etrznym (ang. external
memory mode). Stosowane s ˛

a wtedy odpowiednio programy rozruchowe:

c8051er.src

c8051ser.src

przeznaczonych do ł ˛

acznego wykorzystania obu rodzajów pami˛eci RAM. Jest to tzw. tryb

mieszany (ang. mixed memory mode):

c8051mr.src

c8051smr.src

Podj˛ecie decyzji co do rodzaju pami˛eci RAM, a wi˛ec i trybu kompilacji programu, wi ˛

a˙ze si˛e nie

tylko z wyborem rodzaju programu rozruchowego, ale równie˙z mi˛edzy innymi z wykorzysta-
niem odpowiednich programów bibliotecznych, sposobem definiowania zmiennych globalnych
itd. . . .

2.2.2

Definiowanie rodzaju mikrokontrolera

Rodzina 8051 obejmuje kilkadziesi ˛

at typów mikrokontrolerów. Program jest natomiast pi-

sany dla konkretnego typu, co oznacza, ˙ze u˙zywa on nazw rejestrów specjalnych odpowiednich
dla danego typu. Nazwy te s ˛

a u˙zywane zarówno na poziomie asemblera jak i j˛ezyka C. Nazwy

rejestrów specjalnych u˙zywane na tych poziomach s ˛

a ró˙zne. Oznacza to konieczno ´s´c realizacji

nast˛epuj ˛

acych działa ´n:

Na pocz ˛

atku programu rozruchowego nale˙zy u˙zy ´c dyrektywy

.CHIP

z argumentem okre-

´slaj ˛

acym typ mikrokontrolera (np.

.chip 8052

). Powoduje to doł ˛

aczenie do słownika

nazw asemblera całej grupy nazw rejestrów specjalnych i nazw bitów specyficznych dla
wskazanego typu mikrokontrolera. Od tego momentu nazwom tym zostaj ˛

a przypisane

warto´sci odpowiadaj ˛

ace adresom rejestrów i bitów, które nie mog ˛

a by ´c redefiniowane.

Umo˙zliwia to wskazanie tych nazw przez programist˛e bez konieczno ´sci odwoływanie si˛e
do adresów zwi ˛

azanych z tymi nazwami.

Na pocz ˛

atku sekcji

program

programu rozruchowego nale˙zy doł ˛

aczy ´c plik

c????sr.def

zawieraj ˛

acy globalne definicje nazw rejestrów specjalnych.

Programowanie w C µK rodziny Intel 8051

Tak zdefiniowane nazwy poprzedzone doln ˛

a kresk ˛

(

) mog ˛

a by´c u˙zywane we wszystkich mo-

dułach pod warunkiem zdefiniowania ich jako zewn˛etrzne dla tych modułów. Dla programu
w C realizowane jest to za pomoc ˛

a makropolecenia doł ˛

aczaj ˛

acego plik nagłówkowy:

#include "c8052sr.h"

Zawarto ´s ´c plików definicyjnych

Plik

c8052sr.def

ma posta´c:

***********************************************************

* 8052 C compiler special functions registers definitions *

***********************************************************

spec_func_regs: .section reg,offset 0,ref_only

.globals on

_P0;

.reg 80h

_PCON:

.reg 77h

_SFB:

.reg 80h

.globals off

.ends

Plik nagłówkowy programu w C o nazwie

c8052sr.h

ma posta ´c:

/************************************************************/

/* 8052 C compiler special functions registers declarations */

/************************************************************/

.asm

.chip 8052

.endasm

extern near char P0; /* port 0 */

extern near char PCON; /* power control */

extern near char IE; /* interrupt enable control */

/*******************************************************/

/* 8052 C compiler special functions bits declarations */

/*******************************************************/

near struct special_finction bits

{

/* Bit name

Bit value */

normalnie nazywn ˛

a podkre´sleniem

2.2

Program rozruchowy

/* P0 (Port 0) */

unsigned int P0_0:1 ; /* port 0, bit 0

80h*/

unsigned int P0_0:1;

/* port 0, bit 7

87h*/

/* TCON (Timer Control) */

unsigned int IT0:1; /*input INT0/transition activated 88h */

}

Doł ˛

aczenie tego pliku nagłówkowego umo˙zliwia w programach w C u˙zywanie nazw zdefinio-

wanych rejestrów i bitów jako zmiennych. Ilustruj ˛

a to przykłady:

#include “c8052sr.h”

near char c1;

main()

{

char c2;

c1=P0;

c2=P1;

P2=c2;

.local c2

.asm

mov .low. _c1,p0

mov _c2,p1

.endasm

}

Powy˙zszy program po kompilacji b˛edzie wygl ˛

adał tak:

;.asm

.chip 8052

;.endams

;char c1;

.internal_uninit_data

_c1: .ds 1

;

.program

_main: .equal $

;

?ASC0: .equal 0

?TSC0: .equal 0

?LSC0: .equal 1

inc sp

;c1=P0

mov a,.low. _P0

mov .low. _c1, a

Programowanie w C µK rodziny Intel 8051

;c1=P1

mov a,.low. _P1

xch a,r0

mov a,sp

add a,#0-?LSC0-1

xch a,r0

mov @r0,a

;P2=c2

mov .low. _P2,a

;local c2

c2: .var+0-?LSC0+1

;asm

mov .low. _c1,p0

mov _c2,p1

;endasm

Komunikacje z bitami rejestrów specjalnych w programie w C. Program ten deklaruje rejestry
adresowane bitowo jako struktur˛e bitow ˛

a. Program w C:

#include “c8052sr.h”

extern struct special_functions_bits _SFB;

char c1;

main()

{

_SFB.EA=1;

}

po kompilacji:

;_SFB.EA=1

setb .low. __SFB+47

;

2.2.3

Deklaracja rejestrów roboczych

Kompilator C wykorzystuje wszystkie rejestry robocze r0 . . . r7 mikrokontrolera, niezb˛edne

jest wi˛ec ich zdefiniowanie w programie rozruchowym w sposób wła´sciwy dla kompilatora.
Najlepiej zrobi´c to w postaci sekcji rejestrowej. Jej parametry mo˙zna zadeklarowa ´c na poziomie
asemblera, bo nie ulegaj ˛

a one zmianie w trakcie konsolidacji. Realizowane to jest nast˛epuj ˛

aco:

registers:

.section reg, offset 0, ref_only

.global __reg0

.global __reg1

.global __reg7

2.2

Program rozruchowy

__reg0:

.ds 1

__reg7:

.ds 1

__oper1_lsb: .equal __reg0

__oper1_msb: .equal __reg2 ;adres operandu 1

__stack_msb: .equal __reg7

2.2.4

Przesuwanie danych

Kompilator u˙zywa czterech rodzajów sekcji wraz z trzema odpowiadaj ˛

acymi im sekcjami

bibliotecznymi. Sekcje te nosz ˛

a ró˙zne nazwy dla trybu wewn˛etrznego i zewn˛etrznego kompila-

tora.

Rodzaj sekcji

Sekcje biblioteczna

Tryb zewn˛etrzny

program

lib_program

const_data

lib_const_data

init_data

lib_init_data

uninit_data

Tryb wewn˛etrzny

program

lib_program

internal_const_data

lib_internal_const_data

internal_init_data

lib_internal_init_data

internal_uninit_data

Pierwszy rodzaj sekcji zawiera programy u˙zytkownika i programy biblioteczne. Pozostałe

trzy rodzaje sekcji u˙zywane przez kompilator słu˙z ˛

a do lokowanie danych podzielonych na 3 klasy:

dane nieinicjowane, dla których w wyniku deklaracji typu musi by ´c zarezerwowane miej-
sce w pami˛eci, jednak w rezerwowany obszar nie s ˛

a wpisywane ˙zadne warto ´sci

dane inicjowane, którym prócz zadeklarowania typu przypisywana jest warto ´s´c. Obydwa
powy˙zsze typy zwi ˛

azane s ˛

a z deklaracjami zmiennych.

trzeci typ danych zwi ˛

azany jest ze stałymi u˙zywanymi w programie. Stałe nie zmieniaj ˛

warto´sci przez cały czas działania programu. Okre´slony symbol mo˙zna zadeklarowa´c jako
stał ˛

a u˙zywaj ˛

ac do tego celu słowa kluczowego

const

Przykład:

char c1;

char c2=0;

const char c3=3;

main(){}

Programowanie w C µK rodziny Intel 8051

po kompilacji:

;char c1

.internal_uninit_data

_c1: ds 1

;char c2=0;

.internal_init_data

_c2: .byte 0

;const char c3=3;

.internal_const_data

_c3: .byte 3

Utworzenie w/w klas sekcji pozwala na umieszczenie modułów bibliotecznych w okre ´slonych
obszarach pami˛eci. S ˛

a one lokowane zgodnie z parametrami podanymi w pliku konsolidacji

(

*.lnk

). Program rozruchowy musi zdefiniowa´c wszystkie niezb˛edne sekcje, nawet je´sli s ˛

puste. Przyj˛ecie okre´slonego porz ˛

adku pozwala konsolidatorowi na wyznaczanie rozmiarów

sekcji, co jest niezb˛edne do przemieszczania odpowiednich sekcji przez program rozruchowy
oraz ewentualne zerowanie odpowiednich sekcji.

W funkcjach j˛ezyka C mog ˛

a wyst˛epowa´c dane tymczasowe, które spełniaj ˛

a wewn ˛

atrz funk-

cji zadania pomocnicze. Moduły biblioteczne przechowuj ˛

a ich warto ´sci na stosie. Lokalizacja

ka˙zdej zmiennej wskazywana jest jako przesuni˛ecie w stosunku do zawarto ´sci wska´znika chwi-
lowych zmiennych bibliotecznych:

__ilib_temp_ptr

(dla trybu wewn˛etrznego). Wyznaczanie

lokalizacji dokonywane jest w trakcie kompilacji i wymaga zdefiniowania odpowiednich sek-
cji. Te sekcje nie mog ˛

a by przemieszczane wi˛ec ich parametry s ˛

a definiowane na poziomie

asemblera.

2.2.5

Przygotowanie stosu

Stos wewn˛etrzny umieszczany jest ponad obszarem wewn˛etrznych danych nieinicjowanych.

Niezb˛ednym elementem zwi ˛

azanym z tym obszarem jest wska´znik

__ilib_temp_ptr

słu˙z ˛

acy

do poruszania si˛e po zarezerwowanym obszarze pami˛eci, który programy biblioteczne u˙zywaj ˛

do przechowywania wyników. Mo˙zliwe jest wielokrotne wywoływanie podprogramów biblio-
tecznych realizowane w trzech krokach:

1. Lokalizacja kolejnego bloku danych w obszarze stosu o rozmiarze

__lib_temp_constants_size

2. Przechowanie warto´sci bie˙z ˛

acego wska´znika w

__ilib_temp_ptr

3. Wprowadzenie nowej warto´sci wska´znika i wywołanie programu bibliotecznego.

2.2.6

Wywołanie programu w C

Wywołanie programu w C z poziomu programu rozruchowego realizowane jest rozkazem

LCALL_MAIN

. Mo˙zna te˙z stosowa´c rozkaz skoku gdy nie przewiduje si˛e powrotu po zrealizo-

waniu programu w C. Gdy taki powrót ma miejsce (np. gdy wywołanie nast ˛

apiło z programu

2.3

Organizacja danych w C

internal_init_data

internal_lib_init_data

__ilib_temp_ptr

internal_uninit_data

internal_lib_temp_constants

Bank 3

Bank 2

Bank 1

Bank 0

Bity stanu

30h

7Fh

00h

Rysunek 2.2: Struktura wewn˛etrznej pami˛eci RAM po zainicjowaniu stosu

monitora lub systemu operacyjnego) nale˙zy zapewni ´c przywrócenie warto´sci wska´znika stosu
jaka była przed wywołaniem programu w C.

2.3

Organizacja danych w C

2.3.1

Typy danych i ich modyfikatory

Kompilator 2500AD operuje na nast˛epuj ˛

acych typach danych:

Nazwa

Typ

Rozmiar

znakowy

char

8 bitów

całkowity

int

16 bitów

całkowity krótki

short

8 bitów

całkowity długi

long

32 bity

zmiennoprzecinkowy

float

32 bity (IEEE)

zmiennoprzecinkowy podwójnej precyzji

double

64 bity (IEEE)

Stosowane s ˛

a nast˛epuj ˛

ace kwalifikatory:

Kwalifikator

Stosowany do typu

unsigned

char, int, long

const

do wszystkich wł ˛

aczaj ˛

ac struktury

volatile

do wszystkich wł ˛

aczaj ˛

ac struktury

Znaczenie kwalifikatorów:

unsigned

liczba całkowita nieujemna. W stosunku do takich liczb obowi ˛

azuj ˛

a reguły arytme-

Programowanie w C µK rodziny Intel 8051

tyki binarnej.

const

słu˙zy do wskazywania stałych, które nie podlegaj ˛

a zmianom w czasie realizacji

całego programu. Kompilator generuje kod pozwalaj ˛

acy na przekazywanie tych

danych do procesora. Zmienne wska´znikowe o warto´sciach b˛ed ˛

acych adresami do

tych stałych maj ˛

a długo´s´c 16 bitów.

volatile

wskazuje, ˙ze okre´slone dane musz ˛

a by´c ponownie ładowane przy ka˙zdym ich u˙zy-

ciu poniewa˙z s ˛

a modyfikowane w trakcie realizacji programu. Tego typu kwalifika-

tor jest u˙zyteczny przy obsłudze układów I/O adresowanych jednolicie z pami˛eci ˛

Uwaga:

Standard j˛ezyka C wymaga oby argumenty operacji 2-argumentowej typy char były

najpierw przetworzone na posta´c int. Opisywany kompilator nie przestrzega tego wychodz ˛

z zało˙zenia, ˙ze mikrokontorlery rodziny 8051 znacznie cz˛e´sciej wykonuj ˛

a operacje na liczbach

8-bitowych typu char ni˙z na 16bitowych typu int. Dlatego trzeba kontrolowa ´c efekty stosowa-
nych operacji. Ilustruje to przykład:

char c1,c2;

int i;

i=c1<<8; /* przesu´

n w lewo 8 pozycji */

Rezultat tej operacji wynosi 0 poniewa˙z wszystkie bity zostały przesuni˛ete przed przechowa-
niem wyniku w postaci zmiennej

. Aby uzyska ´c poprawny wynik przed przesuni˛eciem nale˙zy

dokona´c konwersji zmiennej

na typ int:

i=(int)c1<<8;

2.3.2

Organizacja ramki stosu

Ka˙zdej funkcji kompilowanej w trybie wewn˛etrznym przydzielany jest fragment pami˛eci

zorganizowany w stos nazywany ramk ˛

a (rys. 2.3). Składa si˛e ona z trzech obszarów:

1. pami˛eci argumentów funkcji,

2. pami˛eci danych tymczasowych,

3. pami˛eci zmiennych lokalnych.

Kompilator dla ka˙zdej funkcji generuje trzy stałe procesu kompilacji, które stanowi ˛

a rozmiary

danych w ramce stosu:

?LSC

rozmiar danych lokalnych

?TSC

rozmiar danych tymczasowych

?ASC

rozmiar argumentów przekazywanych bezpo´srednio na stos

2.3

Organizacja danych w C

Dane tymczasowe

Argumenty

Zmienne lokalne

SP po wywołaniu

funkcji

SP przed wywołaniem

funkcji

?ASC - rozmiar obszaru argumentow przekazy-

wanych bezpos´rednio przez stos

SP-?LSC

SP-?LSC+1-TSC

Argumenty przekazywane przez rejestry

?TSC - rozmiar danych tymczasowych

?LSC - rozmiar zmiennych lokalnych

Adres powrotu z funkcji (2 bajty)

Rysunek 2.3: Ramka stosu

Rozmiary te maj ˛

a warto´sci równe liczbie bajtów zarezerwowanych w ramce na dany rodzaj wiel-

ko´sci. Słu˙z ˛

a one do okre´slania wzgl˛ednych adresów bazowych obszarów ramki, które z kolei

stanowi ˛

a podstaw˛e wyznaczania poło˙zenia danych w ramce. Okre´slone s ˛

a nast˛epuj ˛

ace adresy

bazowe:

adres wzgl˛edny pocz ˛

atku obszaru zmiennych lokalnych (

-?LSC+1

) wskazuj ˛

acy poło˙zenie

najstarszego bajtu pierwszej zmiennej lokalnej wzgl˛edem aktualnej zawarto ´sci wska´znika
stosu

adres wzgl˛edny pocz ˛

atku obszaru danych tymczasowych (

-?LSC

)

adres wzgl˛edny ko ´nca obszaru danych tymczasowych (

-?LSC-?TSC

), który słu˙zy jako

adres bazowy obszaru argumentów funkcji

Powy˙zsze adresy bazowe umo˙zliwiaj ˛

a lokalizacj˛e danych w ramce na podstawie ich adresów

wzgl˛ednych b˛ed ˛

acych liczbami wskazuj ˛

acymi odległo´s´c w bajtach najstarszego bajtu danych

od adresu bazowego.

2.3.3

Przekazywanie argumentów do funkcji

Tłumacz ˛

ac funkcj˛e j˛ezyka C kompilator standardowo lokuje ich argumenty typu char i int

w rejestrach roboczych. W momencie gdy kompilator przetłumaczy wywołanie funkcji rozpo-
czyna poszukiwanie miejsca dla przechowania pierwszego argumentu. Je ´sli jest on typu char/int
i jest miejsce w rejestrach to jest on tam umieszczany. W przeciwnym przypadku argument jest
lokowany na stosie. Czynno´s´c ta powtarzana jest do wyczerpania listy argumentów. Kompilator

Programowanie w C µK rodziny Intel 8051

u˙zywa rejestrów A, R1, R2, R3

do przechowywania argumentów typu char, oraz par R2+R0,

R3+R1 dla typu int. Przykłady:

funkcja1(char arg1, char arg2)

– pierwszy argument umieszczony jest w A, drugi w R2

funkcja2(char arg1, int arg2)

– pierwszy argument w A, drugi w R3+R1

funkcja3(int arg1, char arg2)

– pierwszy argument w parze R2+R0, drugi w R1

funkcja4(int arg1, int arg2)

– pierwszy w R2+R0, drugi R3+R1

Po przej´sciu do realizacji funkcji w pierwszym kroku wysyłane s ˛

a na stos argumenty przekazy-

wane w rejestrach. Po ich wysłaniu obszar ramki stosu przeznaczony na argumenty zawiera je
w kolejno´sci odwrotnej do kolejno´sci ich deklaracji. Pokazano to na rys. 2.4 dla przykładowej
funkcji:

f_przykl_1 (char, int, float)

Pamie˛c´ danych
tymczasowych

char

int

float

bity 0..7

bity 8..15

bity 0..7

bity 8..15

bity 16..23

bity 24..31

Ostatni argument

Pierwszy argument

Rysunek 2.4: Kolejno´s´c argumentów funkcji w ramce stosu

Przekazanie argumentów na stos odbywa si˛e dwuetapowo:

1. Przed wywołaniem funkcji – pocz ˛

atkowe argumenty s ˛

a ładowane do rejestrów roboczych,

reszta na stos.

2. Po wywołaniu funkcji – argumenty z rejestrów przenoszone s ˛

a na stos.

Mi˛edzy tymi działaniami ma miejsce operacja zwi ˛

azana z wywołaniem podprogramu realizuj ˛

cego dan ˛

a funkcj˛e. Dlatego obszar stosu wewn˛etrznego przeznaczonego na argumenty zostaje

przedzielony na dwie cz˛e´sci dwubajtowym adresem powrotu z podprogramu.

W tej kolejco´sci.

2.3

Organizacja danych w C

Przykład:

main()

{

f_przykl_2(1,2,3);

}

f_przykl_2(int x, int y, int z)

{

int a,b,s;

a=4;

b=5;

s=0;

s=s+z;

s=s+y;

return(s);

}

Odwołanie si˛e do funkcji

f_przykl_2

wymaga przekazania do niej trzech argumentów. Argu-

menty pierwszy i drugi lokowane s ˛

a w parach rejestrów R2 i R0 oraz R3 i R1, trzeci argument

lokowany jest na stosie. Po kompilacji odpowiednie instrukcje asemblera maj ˛

a posta ´c:

;f_przykl_2(1,2,3)

mov

r0,#.low. 3

mov

r2,#.high. 3

push

_oper1_msb

push

_oper2_lsb

mov

r1,#.low. 2

mov

r3,#.high. 2

mov

r0,#.low. 1

mov

r0,#.high. 1

lcall _f_przykl_2

dec

?BOF0:

.equal $

ret

_f_przykl_2: .equal $

push

_oper2_msb

push

_oper2_lsb

push

_oper1_msb

push

_oper1_lsb

Po wywołaniu podprogramu funkcji argumenty z rejestrów przenoszone s ˛

a na stos. Po zako ´n-

czeniu tej operacji ramka stosu ma posta´c przedstawian ˛

a na rys. 2.5.

2.3.4

Rozmieszczenie zmiennych lokalnych w ramce stosu

Zmienne lokalne umieszczane s ˛

a na stosie w kolejno´sci ich definiowania zaczynaj ˛

ac od naj-

starszego bajtu. Dla funkcji z przykładu ze strony 33 map˛e pami˛eci zmiennych lokalnych przed-
stawia rysunek 2.6.

2.3

Organizacja danych w C

Rozmieszczenie zmiennych lokalnych musi by ´c poprzedzone zarezerwowaniem obszaru

stosu na dane tymczasowe i zmienne lokale. Odpowiedni fragment programu po kompilacji
ma posta´c:

?ASC1: .equal 2

?TSC1: .equal 0

?LSC1: .equal 6

mov a,sp

add a,#?TSC1+?LSC1

mov sp,a

;po tej operacji wska´

znik stosu wskazuje koniec ramki stosu

Mechanizm lokowanie zmiennych ilustruje poni˙zszy kod:

;a=4

mov a,sp

add a#0-?LSC1+1

mov r0,a

mov @r0,#.high. 4

inc r0

mov @r0,#.low. 4

;b=5

mov a,sp

add a,#2-?LSC1+1

mov r0,a

;s=0

Po zako ´nczeniu lokowania zmiennych lokalnych ramka stosu dla przykładu ze strony 33 przed-
stawion ˛

a na rysunku 2.7. W tej formie jest ona wykorzystywana przez cały czas realizacji pod-

programu funkcji.

Obszar zmiennych tymczasowych jest wykorzystywany w taki sam sposób jak obszar zmien-

nych lokalnych w miar˛e pojawiania si˛e danych wykorzystywanych chwilowo dla celów przecho-
wania wyników po´srednich.

Powrót z podprogramu funkcji wymaga ustawienia wska´znika stosu SP. Realizuj ˛

a to instruk-

cje:

;return(s)

?BOF1: .equal $

mov a,sp

add a,#-?LSC1-?TSC1-4

mov sp,a

ret

Programowanie w C µK rodziny Intel 8051

.low. 0

Pamie˛c´ danych

tymczasowych

.high. 4

.high. 5

.low. 4

.low. 5

.high. 0

.low. 1

.high. 1

.low. 2

.high. 2

adres

powrotu

.low. 3

.high. 3

Rysunek 2.7: Mapa ramki stosu funkcji z przykłady ze strony 33

2.3.5

Przechowywanie warto ´sci zwracanych przez funkcj ˛e

Zmienna zwracana przez funkcj˛e okre´slona jest jako argument instrukcji

return

. Typ zwra-

canej warto´sci musi by´c wskazany przez podanie typu funkcji przed jej nazw ˛

a. Pomini˛ecie tej

deklaracji oznacza funkcj˛e etapu int (czyli zwracaj ˛

ac ˛

a warto´s´c całkowit ˛

a). Sposób zwracania

warto´sci funkcji okre´sla tablica:

Typ zwracanej warto´sci

Zwracana w:

wszystkie funkcje:

char

int

R2,R0

funkcje zewn˛etrzne (korzystaj ˛

ace z zewn˛etrznej pami˛eci RAM):

long, float, double

lokacja w pami˛eci tymczasowej:

__FUNCTION_RET_ADDR

wska´znik do lokacji w R2 i R0

funkcje wewn˛etrzne:

long, float, double

lokacja w pami˛eci tymczasowej:

__IFUNCTION_RET_ADDR

wska´znik do lokacji w A

Sposób zwracania warto´sci przez funkcj˛e z przykładu ze strony 33 pokazuje fragment pro-

gramu:

mov a,sp

mov a,#4-?LSC1+1

mov r1,a

mov @r1,__oper1_msb

inc r1

mov @r1,__oper1_lsb

2.4

Przekazywanie danych mi˛edzy funkcjami a instrukcjami asemblera

;return(s)

Modyfikacja funkcji z tego przykładu powoduje, ˙ze zwracana jest warto ´s´c 4-bajtowa. Program
w C ma wówczas posta´c:

main()

{

long f_przykl_3(1,2,3);

}

long f_przykl_3(int x, int y, int z)

{

int a,b;

long s;

a=4;

b=5;

s=(long)z;

return(s);

}

Po przetłumaczeniu funkcji return:

;return(s)

mov r1,a

mov a,__ilib_temp_ptr

add a,#-__IFUNCTION_RET_ADDR

lcall __istore_long

2.4

Przekazywanie danych mi ˛edzy funkcjami a instrukcjami

asemblera

2.4.1

Wprowadzanie instrukcji asemblera do programu w C

Współprac˛e fragmentów programów w C i w asemblerze umo˙zliwiaj ˛

a odpowiednie dyrek-

tywy kompilatora. Podstawow ˛

a konstrukcj ˛

a składniow ˛

a umo˙zliwiaj ˛

ac ˛

a wprowadzenie instrukcji

asemblera jest para dyrektyw:

.asm

;program w asemblerze

.endasm

Tekst mi˛edzy nimi jest przenoszony przez kompilator bezpo´srednio do tłumaczenia przez asem-
bler.

Programowanie w C µK rodziny Intel 8051

Uwaga:

Kompilator dzieli etykiety na lokalne i globalne:

nazwy lokalne generowane s ˛

a przez kompilator wewn ˛

atrz funkcji i s ˛

a wa˙zne tylko w ob-

r˛ebie danej funkcji,

nazwy globalne musz ˛

a by´c definiowane na zewn ˛

atrz funkcji.

Nazwy lokalne definiowane wewn ˛

atrz funkcji wyró˙zniane s ˛

a przez kompilator znakiem

pocz ˛

atku lub ko ´ncu nazwy. Poniewa˙z stosowana jest zasada, ˙ze u˙zycie nazwy globalnej ko ´nczy

blok nazw lokalnych we wstawkach asemblerowych nale˙zy u˙zywa ´c nazw z

‘?’

na pocz ˛

atku lub

na ko ´ncu.

2.4.2

Dost ˛ep do zmiennych lokalnych

Zmienne lokalne umieszczane s ˛

a na stosie wewn˛etrznym lub zewn˛etrznym w zale˙zno ´sci od

trybu pracy kompilatora. Kompilator lokalizuje je w sposób wzgl˛edny w odniesieniu do war-
to´sci wska´znika ramki. Dyrektywa

.local

powoduje wygenerowanie na poziomie asemblera

dyrektywy

.var

przyporz ˛

adkowuj ˛

acej zmiennej warto´s´c b˛ed ˛

acej przesuni˛eciem w stosunku do

aktualnej zawarto´sci wska´znika ramki. W trybie wewn˛etrznym rol˛e wska´znika ramki spełnia
SP. Poni˙zszy przykład ilustruje wykorzystanie dyrektywy

.local

do wskazywania z poziomu

asemblera zmiennej lokalnej przez nazw˛e:

main()

{

char c2;

int int2;

.local c2; /* tworzy przesuni˛

ecie w stosunku do zawarto´

sci SP */

.local int2;

/* teraz asembler mo˙

ze odwoływa´

c si˛

e do obu zmiennych przez nazw˛

e */

.asm

;wstawka asmeblerowa

mov a,sp

add a,#c2

mov r0,a

mov @r0,#0

;wyzeruj zmienn ˛

a c2

mov a,sp

add a,#int2

mov r0,a

mov @r0,#.high. 0

;wyzeruj zmienn ˛

a int2

inc r0

mov @r1,#.low. 0

.endasm

}

2.4.3

Dost ˛ep do argumentów funkcji j ˛ezyka C

Dost˛ep do argumentów funkcji j˛ezyka C z poziomu asemblera umo˙zliwia dyrektywa kom-

pilatora

.arg

. Działa ona tak samo jak dyrektywa

.local

z tym, ˙ze argumentem generowanej

2.4

Przekazywanie danych mi˛edzy funkcjami a instrukcjami asemblera

dyrektywy asemblera

.var

jest przesuni˛ecie wskazuj ˛

ace zmienn ˛

a w obszarze argumentów funk-

cji. Przykład:

main(char c1, int int1)

{

.arg c1;

.arg int1;

/* dalej ja w przykładzie powy˙

zej */

}

2.4.4

Adresowanie bezpo ´srednie i po ´srednie w programach w C

Adresowanie bezpo´srednie – za nazw ˛

a u˙zywan ˛

a w programie kryje si˛e adres, tzn. u˙zycie

danej nazwy powoduje odwołanie si˛e do komórki pami˛eci (lub rejestru) opatrzonej nazw ˛

a. Do-

tyczy to wszystkich nazw globalnych takich jak:

nazwy zmiennych globalnych

nazwy funkcji

nazwy rejestrów specjalnych (s ˛

a definiowane z zasady jako nazwy globalne)

a tak˙ze (z zało˙zenia) struktur zło˙zony takich jak:

tablice

unie

Przykład:

const char tab[]=”komunikat 1”;

main ()

{

extern const char tab[];

char c1;

c1=tab[0];

}

fragment odpowiedniego programu asemblerowego:

.internal_const_data

_tab:

.byte

”komunikat 1”

.program

_main:

.equal $

?ASC0:

.equal 0

?TSC0:

.equal 0

?LSC0:

.equal 1

Programowanie w C µK rodziny Intel 8051

;c1=tab[0]

mov

dptr,#_tab+0

clr

movc a,@a+dprt

xch

a,r0

mov

a,sp

add

a,#0-?LSC0+1

xch

a,r0

mov

@r0,a

?BOFO:

.equal $

dec

ret

.global _tab

.global _main

.extern _tab

.end

U˙zywaj ˛

ac nazw operuje si˛e na zawarto´sciach komórek lub rejestrów traktowanych jako argu-

menty o danej nazwie. Mo˙zliwe jest te˙z uzyskanie adresu danej nazwy i odwołanie si˛e do
argumentu po´sredniego przez ten adres. Mo˙zliwe s ˛

a równie˙z stosowne operacje na adresach

jako zmiennych całkowitych. Przykład:

char c1=1;

main()

{

extern char c1;

int adr_main;

adr_main=&main;

c1++;

}

po kompilacji:

;char c1=1

.internal_init_data

_c1:

.byte 1

.program

_main: .equal $

?ASC0:

.equal 0

?TSC0:

.equal 0

?LSC0:

.equal 4

mov a,sp

mov a,#?TSC0+?LSC0

mov sp,a

2.4

Przekazywanie danych mi˛edzy funkcjami a instrukcjami asemblera

;adr_main=&main

mov r0,#.low. _main

mov r2,#.high. _main

mov a,sp

add a,#2-?LSC0+1

mov r1,a

mov @r1,__oper1_msb

inc r1

mov @r1,__oper1_lsb

;c1++

inc .low. _c1

Adresowanie po´srednie – polega na operowaniu adresem zmiennej zamiast jej nazw ˛

a. Tego ro-

dzaju działanie jest niezb˛edne je´sli chce si˛e mie´c dost˛ep do zmiennej jednej funkcji z poziomu
innej funkcji. Przekazywanie argumentu z pierwszej funkcji do drugiej odbywa si˛e poprzez war-
to´s´c, tzn. przy u˙zyciu stosu przekazywane s ˛

a kopie argumentów funkcji wywołuj ˛

acej. Funkcja

wywołana operuje tylko na tych kopiach. Aby mo˙zna było zmieni ´c oryginały argumentów funk-
cja wywołuj ˛

aca musi przekaza´c ich adresy. Umo˙zliwia to operator

, który u˙zyty dla zmiennej

o nazwie ”

” w sposób ”

” nakazuje pobranie adresu zmiennej

. Chc ˛

ac teraz operowa ´c na

tym adresie mo˙zna utworzy´c now ˛

a zmienn ˛

a, np. ”

prt=&a;

” nazywan ˛

a wska´znikiem (zmienn ˛

wska´znikow ˛

a), której warto´s´c stanowi adres zmiennej

. Chc ˛

ac zmieni´c warto´s´c zmiennej

mo˙zna zastosowa´c ten wska´znik z operatorem ”

” nakazuj ˛

acym traktowa ´c swój argument jako

adres, np. ”

*ptr=5;

” powoduje, ˙ze zmienna

przyjmuje warto´s´c 5.

Indeks

adres bazowy, 10
asembler, 1

biblioteki, 9
bie˙z ˛

acy wska´znik umieszczenia, 5

dyrektywa, 2

.ABSOLUTE, 12
.BSECT, 14
.CODE, 14
.COMMENT, 3
.DATA, 14
.DB, 6
.DS, 7
.DW, 6
.ELSE, 8
.END, 7
.ENDIF, 8
.ENDM, 8
.ENDMOD, 9
.EQU, 6
.EXTERNAL, 13
.GLOBAL, 13
.IF, 8
.INCLUDE, 14
.MACRO, 8
.MOD, 9
.ORG, 5, 12
.RADIX, 4
.RELATIVE, 12
.RSECT, 14
.SECTION, 15
.SET, 6

grupy sekcji, 10

instrukcja, 2

kompilacja, 22

makroasembler, 7
makrodefinicja, 8

parametry

aktualne, 8
formalne, 8

wywołanie, 8

moduł, 9

konsolidacja, 9
posta´c relokowalna, 9

nazwy, 3, 4

absolutna, 12
absolutne, 6
atrybuty, 6, 13

absolutno´sci, 12
globalno´sci, 13
okre´slono´sci, 6
zewn˛etrzno´sci, 13

globalne, 13
relokowalna, 12
wspólne, 13
zewn˛etrzne, 13

pole

argumentów, 3
etykiety, 2
komentarza, 3
operacji, 3

procedura, 9
program

´zródłowy, 1

wynikowy, 1

program rozruchowy, 22
przeł ˛

acznik sekcji, 15

słownik, 5

dopisywanie nazw, 5

segment, 9, 14