Ji°φ Peterka

╪φkat poΦφtaΦi, co p°esn∞ mß d∞lat, lze vφce r∙zn²mi zp∙soby a na r∙zn²ch ·rovnφch: lze jej nap°φklad programovat v n∞kterΘm vyÜÜφm programovacφm jazyku procedurßlnφho Φi neprocedurßlnφho charakteru nebo na vyÜÜφ ·rovni pou₧φvat vhodn² generßtor aplikacφ apod.

PoΦφtaΦ lze ovÜem programovat i na nejni₧Üφ mo₧nΘ ·rovni, kterou je ·rove≥ jeho strojovΘho k≤du - na tΘto ·rovni mu programßtor sestavuje program p°φmo z jeho strojov²ch instrukcφ. Tφm samoz°ejm∞ odpadß pot°eba p°ekladu neboli nahrazovßnφ obecn∞jÜφch a abstraktn∞jÜφch p°φkaz∙ vyÜÜφho programovacφho jazyka cel²mi skupinami strojov²ch instrukcφ - to mß na starosti program zvan² p°ekladaΦ.

OvÜem sestavit program p°φmo ze strojov²ch instrukcφ a p°edat jej poΦφtaΦi v takovΘ form∞, jakΘ rozumφ a v jakΘ je schopen p°φsluÜn² program skuteΦn∞ vykonat, znamenß vyjßd°it jej i se vÜemi jeho instrukcemi a jejich operandy, (i s p°φpadn²mi daty) v ΦφselnΘ (p°esn∞ji binßrnφ) podob∞. To je samoz°ejm∞ mo₧nΘ ud∞lat "ruΦn∞", ale kdo to n∞kdy zkouÜel, jist∞ mi dß za pravdu, ₧e tudy cesta nevede. ProblΘm je toti₧ v tom, ₧e tato Φinnost je sice rutinnφ povahy, ale pro Φlov∞ka je znaΦn∞ nßroΦnß. Tak nßroΦnß , ₧e p°i nφ v∞tÜinou zapomφnß na to podstatnΘ (na vlastnφ programovßnφ) a ₧e se doslova utßpφ ve zcela mechanick²ch Φinnostech, jako jsou p°evody z desφtkovΘho do binßrnφho tvaru Φi zjiÜ¥ovßnφ v tabulce, jak² Φφseln² k≤d mß ta kterß instrukce, jak² mß p°esn² formßt apod. JeÜt∞ nßroΦn∞jÜφ jsou pak v²poΦty Φφseln²ch adres, kterΘ je nutnΘ pou₧φvat jako operandy skokov²ch instrukcφ Φi instrukcφ volßnφ, ale kterΘ si p°i takovΘmto zp∙sobu programovßnφ p°φmo ve strojovΘm k≤du vypoΦφtßvß programßtor sßm a "ruΦn∞".

O chybßch, kter²ch se p°itom obvykle dopoustφ, rad∞ji ani nemluvφme.

P°itom je ale v zßsad∞ mo₧nΘ programovat "kulturn∞" i na ·rovni strojovΘho k≤du, tzn. takov²m zp∙sobem, p°i kterΘm je programßtor v maximßlnφ mo₧nΘ mφ°e zbaven vÜech rutinnφch Φinnostφ a m∙₧e se pln∞ soust°edit na vlastnφ programovßnφ. Programßtorovi lze ulehΦit mo₧nostφ zapisovat jednotlivΘ strojovΘ instrukce i s jejich operandy nikoli v ΦφselnΘm tvaru, ale ve tvaru symbolickΘm a stejn∞ tak mo₧nostφ oznaΦovat v²znaΦnΘ adresy v programu symbolick²mi nßv∞Ütφmi a ty pak pou₧φvat vÜude tam, kde je pot°eb a se na p°φsluÜnΘ adresy odkßzat (nap°φklad pro vyjßd°enφ cφlovΘ adresy skokovΘ instrukce apod.). ╚eÜtina si pro prßv∞ naznaΦenou mo₧nost zavedla dokonce i v²sti₧nΘ pojmenovßnφ: p°φsluÜn² jazyk oznaΦuje jako jazyk symbolick²ch instrukcφ nebo tΘ₧: jazyk symbolick²ch adres.

Prßv∞ naznaΦenß mo₧nost programovßnφ v jazyku symbolick²ch instrukcφ (resp. v jazyku symbolick²ch adres) vÜak vy₧aduje, aby existoval n∞kdo, kdo p°evede symbolick² program do p°φsluÜnΘho ΦφselnΘho tvaru. Takov²to p°evod p°itom nebude p°ekladem - alespo≥ ne v tom smyslu, jak je pou₧φvßn v souvislosti s vyÜÜφmi programovacφmi jazyky, kde p°i p°ekladu dochßzφ k nahrazovßnφ jednotliv²ch obecn∞jÜφch p°φkaz∙ vyÜÜφho programovacφho jazyka cel²mi sekvencemi strojov²ch instrukcφ. V naÜem p°φpad∞ naopak dochßzφ k transformaci stylem 1 ku 1, kdy jedna strojovß instrukce, vyjßd°enß v symbolickΘm tvaru, je nahrazena sv²m ekvivalentem, vyjßd°en²m v ΦφselnΘm tvaru. V angliΦtin∞ se takov²to postup oznaΦuje jako assembly, co₧ v doslovnΘm p°ekladu znamenß "sestavenφ". Programu, kter² toto sestavenφ zajiÜ¥uje, se pak °φkß assembler (a v ΦeskΘm kontextu obvykle s jednφm "s").

╪ekne-li se tedy v angliΦtin∞ "assembler", je tφm v u₧Üφm slova smyslu mφn∞n pouze program, kter² zajiÜ¥uje prßv∞ naznaΦenΘ sestavenφ. V ÜirÜφm slova smyslu je ale stejn²m termφnem oznaΦovßn i jazyk, kter² tento program p°ijφmß a p°evßdφ do ΦφselnΘho tvaru - tedy to, pro co si ΦeÜtina (na rozdφl od angliΦtiny) naÜla v²sti₧nΘ oznaΦenφ "jazyk symbolick²ch instrukcφ" (resp. jazyk symbolick²ch adres). I v ΦeÜtin∞ se ale dnes pou₧φvß termφn "asembler" jak pro samotn² sestavovacφ program, tak i pro p°φsluÜn ² jazyk - jinak bychom vlastn∞ ani nemohli mφt ₧ßdnΘ uΦebnice programovßnφ v asembleru, ₧ßdnΘ programy (Φi alespo≥ Φßsti program∙) psanΘ v asembleru apod.

Kdy₧ u₧ jsme se ale dostali k otßzce programovßnφ v asembleru: Mß n∞co takovΘho v dneÜnφ dob∞ jeÜt∞ v∙bec smysl - jsou-li k dispozici vÜechny ty p°ekladaΦe vyÜÜφch programovacφch jazyk∙, kterΘ navφc dokß₧φ dosti efektivn∞ optimalizovat k≤d, kter² generujφ? Odpov∞∩ je kladnß: I v dneÜnφ dob∞ se mnohdy vyplatφ napsat v asembleru n∞kterΘ kritickΘ Φßsti aplikacφ Φi operaΦnφho systΘmu - kritickΘ co do rychlosti Φi nßrok∙ na pam∞¥ apod. Programovßnφ v asembleru toti₧ stßle jeÜt∞ dßvß programßtor∙m nejlepÜφ mo₧nosti "Üφt programy na mφru" konkrΘtnφm poΦφtaΦ∙m a specifick²m pot°ebßm, co₧ se m∙₧e s v²hodou uplatnit nap°φklad u nejr∙zn∞jÜφch ovladaΦ∙, obslu₧n²ch rutin p°eruÜenφ apod. Z°ejm∞ se ale ji₧ nesetkßme s tφm, ₧e by se v asembleru psaly celΘ aplikace - asembler jako nßstroj programovßnφ je toti₧ mnohem mΘn∞ efektivnφ ne₧ kter²koli programovacφ jazyk vyÜÜφ ·rovn∞.