Az assembly programokban a memória-címekre azok sorszámával lehetett hivatkozni. Egy 128Mb memóriával szerelt számítógépben 128*1024*1024 db sorszámot lehet használni, mivel a memória ennyi db byte-ot tartalmaz. A példában ezek a sorszámok a [0 .. 134.217.727] intervallumból kerülnek ki^[1].

Az assembly programok sokszor tényleges memóriacímeket (sorszámokat) tartalmaztak számkonstansok formájában. Ez sok szempontból nem volt elég rugalmas:

A helyzet javítása érdekében a programozók elkezdtek konstansokat használni a programjaikban. Ezeket a programok elejére összefoglaló jelleggel, táblázat-szerű módon írták le:

FIZETES= 1034

ELETKOR= 1038

NYUGDIJAS= 1040

Ezek után az assembly programokban az ADD EAX,[1034] helyett (ami azt jelentette, hogy add hozzá az [1034] memóriacímen található értéket az EAX regiszterben éppen benne levő értékhez) azt írhatták, hogy ADD EAX,[FIZETES]. Ez sokkal olvashatóbb forma, másrészt amennyiben a fizetés értékét mégsem az 1034-es memóriacímen kellett tárolni (változás), akkor egyetlen helyen kellett csak átírni – a program eleji táblázatban.

Ez az egyszerű és logikus meggondolás indította el a ’változó’ fogalmának fejlődését. A fenti esetben a FIZETES volt az azonosító, melyhez a programozó konstans formájában rendelt hozzá memóriacímet – helyet a memóriában.

Még fejlettebb assembler fordítók esetén a fenti táblázat az alábbi formában is felírható volt:

FIZETES= 1034

ELETKOR= FIZETES+4

NYUGDIJAS= ELETKOR+2

Ebben az esetben már kiolvasható volt a táblázatból, hogy a FIZETES névvel jelölt memóriaterület 4 byte-os tároló hely volt, hiszen ekkora memória-szakasz fenntartása után a következő memóriaterület (’ELETKOR’ elnevezéssel) 4 byte-tal távolabbi ponton kezdődik.

Ez a változat azért is jobb, mert segíti, hogy elkerüljük két tárolóterület átfedését a memóriában (átlapolás). Megakadályozni nem tudja, hiszen amennyiben a fizetés tárolási igénye 8 byte lenne, akkor a fenti esetben az életkor még átlógna a fizetés tárlóhelyének utolsó 4 byte-jára. Ennek persze a programozó az oka, aki rosszul írta fel a táblázatot. Ha azonban a fizetés tárolására 2 byte is elég lenne, akkor 2 byte-nyi felhasználatlan terület keletkezne a memóriában (ami szintén nem szerencsés).

A fenti problémákon túl az assembler azt sem tudta ellenőrizni, hogy a tárlórekeszt megfelelően kezeli-e a programozó a későbbiekben:

MOV EAX, [FIZETES]// EAX 32 bites regiszter, 4 byte

MOV AX, [FIZETES]// AX 16 bites regiszter, 2 byte

MOV AL, [FIZETES]// AL 8 bites regiszter, 1 byte

A fenti utasítások mindegyike elfogadható az assembly nyelv szintaktikai szabályai szerint. Az első esetben a megadott memóriacímről 4 byte-nyi adat kerül be az EAX nevű regiszterbe. Második esetben csak 2 byte, harmadik esetben csak 1 byte. A memória-beolvasást ugyanis a fogadó regiszter mérete befolyásolja. Amennyiben a fizetés 4 byte-on kerül tárolásra, úgy a második és harmadik utasítás nagy valószínűséggel hibás, hiszen miért olvasnánk be a fizetést tartalmazó számsorozat-nak csak az egyik felét?

Az ilyen jellegű hibákra azonban az assembler nem tudott figyelmeztetni, mivel számára a FIZETES csak egy memóriacím volt. A helyes kezelésre a programozónak kellett ügyelnie. Az assembler nem is tudta volna ellenőrizni a kódot ebből a szempontból, hiszen nem volt információja arról, hogy mit is ért a programozó fizetés alatt.

Ezt a plusz információt hívják a programozási nyelvben típusnak.

A típus sok mindent meghatároz. Többek között meghatározza az adott érték tárolási méretét a memóriában. A típus ismeretében a fenti táblázat felírható az alábbi formában:

DWORD FIZETES

WORDELETKOR

BYTENYUGDIJAS

A fenti táblázat szerint a FIZETES egy dupla-szó (DWORD), aminek helyigénye 4 byte. Az ELETKOR egy szimpla szó (WORD), 2 byte helyigényű. A NYUGDIJAS egy byte, aminek helyigénye (mint a neve is mutatja) 1 byte.

Amikor az ASSEMBLER-ek már a fenti táblázatot is kezelték, akkor már képesek voltak a tárterület-címeket automatikusan kiosztani. Az első azonosító címéhez képest a primitív típusnevek (dword, word, byte, …) tárolási igényét ismervén automatikusan növelték a memóriacímeket, és adtak értéket az azonosítóknak. Ezek az értékek továbbra is memóriacímek voltak, de az automatikus kiosztás miatt a memóriaterületek átlapolásának esélye még kisebbre zsugorodott.

A fenti primitív típusnevek még nem jelölték az azonosítók tényleges típusát. A fordító mindössze a tárigény-szükséglet kiszámítására használta fel. A hibás kezelés lehetőségét még mindig megengedte, vagyis egy 4 byte-os helyigényű értéknek még mindig szabad volt az egyik felét beolvasni, és dolgozni vele.

Nem voltak ’finom’ típusnevek. Nem volt ’char’, ’bool’, ’short int’, ’unsigned short int’ típusok. Ezek mindegyike 1 byte tárolási igényű, csak ezen 1 byte-on hordozott információ jelentésében térnek el. Mivel a jelentést a fordító még nem kezelte, csak egy olyan típusnév volt, amelynek 1 byte volt a tárolási igénye.

Ennek megfelelően ezt még nem tekinthetjük tényleges típusnévnek, mindössze tárolási-igény névnek.

A változó más komponenseinek (élettartam, hatáskör) kezelése is hiányzott az assembly nyelvből, és az assembler programokból.