Image36 (5)

190

M1

Mikroprocesorowa Ośla łączka ■

i definiowania:    nych zmiennych”?

FUNCTION Funkcyjka (ZmWewnl AS Byte, ZmWewn2 AS Word) AS Integer . . . tu instrukcje funkcji . . .

END FUNCTION

Do tej funkcji zostaną przekazane dane typu By te i Word. a funkcja zwróci dane typu Integer. W przypadku funkcji nie wykorzystuje się oczywiście rozkazu CALL, ponieważ funkcja zwróci wartość, którą trzeba umieścić w jakiejś zmiennej. Sposób korzystania z funkcji jest więc oczywisty:

Skoncentruj się! Może nie dostrzegasz wagi problemu, ale właśnie doszliśmy do bardzo ważnego szczegółu, który może zadecydować o klęsce lub sukcesie Twoich przyszłych działali.

Oto wariant 1: Te „zmienne wewnętrzne.” to najprawdziwsze zmienne utworzone w pa

ZmiennaTypulnteger = Funkcyjka (JakasZmByte, JakasZmWord)

Znów mamy identyczną sytuację, jak w przypadku wiciu poleceń, a ściślej funkcji BAS-COM-a. I oto poznałeś sposób, by dodać do BASCOM-a własne rozkazy w postaci funkcji.

BYREF/BYVAL

Oto okazało się, że SUB i FUNCTION korzystają z „wewnętrznych zmiennych”. Jest oczywiste, że mając te „wewnętrzne zmienne”, mamy szereg możliwości. Pojawia się. też istotna kwestia. Cóż mianowicie oznacza ogólne określenie, że: program główny przekazuje dane do proce dury-pndprng ramu (SUR) lub dn funkcji (FUNCTION)?

W przypadku korzystania z GOSUB i etykiet sprawa jest oczywista: „procedura /ii etykietą” po prostu operuje na „żywych” zmiennych zadeklarowanych wcześniej poleceniem DIM.

Zwróć uwagę, że to, co robią SUB i FUNCTION, można byłoby zrealizować za pomocą przygotowanych wcześniej podprogramów „za etykietą” i poleceń GOSIJR. RETURN. Oczywiście w takim wypadku musielibyśmy starannie pilnować nazw zmiennych, ponieważ te podprogramy operowałyby na tych zmiennych, które zostały zadeklarowane w programie głównym. W przypadku SUB i FUNCTION nie musimy pilnować ich „wewnętrznych” zmiennych, które nie są deklarowane poleceniem DIM jako niezależne zmienne programu, tylko deklarowane są poleceniami DECLARE SUB DECLARE FUNCTION

Obecność „wewnętrznych zmiennych” w standardowych, przygotowanych wcześniej procedurach i funkcjach zwalnia od konieczności pilnowania i deklarowania zmiennych programu głównego. Przekazujemy dane zc zmiennych programu głównego do ..zmiennych wewnętrznych i po kłopocie. .

Nie do końca. Rodzi się wątpliwość. co dzieje się ze zmiennymi programu głównego, jeśli procedura lub funkcja operują na zawartości „wewnętrz-

mięci RAM. Oznacza to dodatkowe zużycie pamięci R AM Program główny przekazuje dane

w rzeczywistości przekazaniem adresów, inaczej mówiąc, przekazaniem przez adres. Działania na zmiennych są na bieżąco „widoczne na zewnątrz" podczas działania procedury (funkcji). Jeśli operacje procedury (funkcji) /mienią zawartość zmiennych, lu stan zmiennych ńę* dzie inny nii przed wywołaniem SUB luh FUNCTION

Ico?

To jak to jest w rzeczy wistości?

Dobrze się zastanów, bo to ważny szczegół.

A odpowiedź może Cię bardzo zaskoczyć: otóż mniesz sobie dowolnie wybrać jeden z opisanych wariantów

Możesz wybrać, ale w RASCOM-ie domyślnie stosowany jest wariant 2. W opisanych wcześniej pr/ykładach:

H

m

n

x

z

DECLARE SUB Zrobcos (Zmiennax AS Byte, Zmiennay AS Integer)

SUB Zrobcos (Zmiennax AS Byte, Zmiennay AS Integer)

.    .    . tu tresc podprogramu

End SUB

do tych realnych „zmiennych wewnętrznych” procedury i wobec tego jakiekolwiek dalsze operacje prowadzenie są na tych niezależnych

a [xilL*m

Zrobcos ZmiennaW, ZmiennaZ oraz

DECLARE FUNCTION Funkcyjka (ZmWewnl AS Byte, ZmWewnŹ AS Word ) AS Integer FUNCTION Funkcyjka (ZmWewnl AS Byte, ZmWewn2 AS Word ) AS Integer .    .    . tu instrukcje funkcji .    .    .

END FUNCTION

kopiach zmiennych. Nawet jeśli operacje a potem

ZmiennaTypulnteger = Funkcyjka (JakasZmByte, JakasZmWord)

procedury (funkcji) /mienią zawartość, to tylko zawartość tych kopii. Działania na zmiennych nic są „widoczne na zewnątrz” procedury (funkcji). Po operacji stan zmiennych programu głównego pozostanie taki, jak przed wywołaniem SUB lub FUNCTION

A oto wariant 2: Chodzi tylko o to. żeby pozbyć się konieczności pilnowania nazw zmiennych. „Zmienne wewnętrzne” nie są realnymi zmiennymi - nic zużywamy dodatkowo pamięci RAM. Sytuacja wygląda tak samo jak w^r przypadku GOSUB i „procedur za etykietą”. Mówimy o „wewnętrznych zmien-nych*\ a wcale nic są to zmienne, tylko po prostu kompilator utożsami z nimi zmienne główne programu. Inaczej mówiąc, kompilator realizując program dla procesora w miejscu. gdzie napotka „wewnętrzne zmienne”.

nic zostaną utworzone żadne dodatkowe „zmienne wewnętrzne”.

Gdy kompilator natrafi w programie na zmienne „wewnętrzne”, po prostu odpowiednio podstawi odpowiednie adresy wcześniej zadeklarowanych zmiennych programu głównego. Przekazanie danych do procedury/ funkcji nastąpi przez, adres, inaczej mówiąc, przez referencję, czyli odniesienie. To angielsku byłoby to by reference. stąd skrót BYREF.

Jeśli natomiast chcemy zrealizować wariant l. to muszą zostać utworzone realne kopie zmiennych i ma nastąpić skopiowanie do nich wartości zmiennych programu głównego. Przekazanie nastąpi przez wartość, po angielsku by valtie. w skrócie BYVA1„ I właśnie taką klauzulę wykorzystamy:

DECLARE SUB Zrobcos (BYVAL Zmienna* AS Byte, BYVAL Zmiennay AS Integer)

SUB Zrobcos (BYYAL Zmiennax AS Byte, BYVAL Zmiennay A3 Integer)

... tu tresc podprogramu . . .

End SUB

użyje adresów zmiennych głównych programu. „Przekazywanie danych” okaże się więc

a potem

Zrobcos ZmiennaW, ZmiennaZ

X

>

H

3J

n

x

z

X

>

mm

>

ITJ

n

x

z

X

>

>

H

PI

n

s

z

X

>

>

H

n

Z

z

mm

X

>

r

>

Elektronika dla Wszystkich Kwiecień 2005 45