Ennek EP-n általában kevés jelentősége van, legfeljebb a rendszerbővítőknél fontos, amik áthelyezhető formátumba is fordíthatók.
PC-n is csak a .dll (Windows) és .so (Unix) file-ok áthelyezhetők - illetve ezek közül is csak az utóbbi valódi pozíció független kód 32 bites x86 rendszeren, a programok fix címre fordítódnak (de ez nem probléma, mert az operációs rendszer mindnek külön virtuális címterületet biztosít).
Csak akkor, ha a relatív ugrás nem történik meg. Az utasítások futásideje (memória várakozás nélkül):
- JP (mindig): 10 ciklus
- JR (nem teljesül a feltétel): 7 ciklus
- JR (az ugrás megtörténik): 12 ciklus
A windows DLL az valojaban amugy a UNIX-okbol ismert COFF formatum, megfejelve egy EXE fejleccel
![Smiley :)](/Smileys/phpbb/smiley.gif)
Vagy hasonlo. Amugy erre irtam, hogy meg egy "modernnek mondott" 32 bites x86-on is merheto telejsitmenycsokkenest okoz az, hogy egy regisztert "elpazarolsz" mert PIC kodot forditasz (lasd pl gcc -fPIC kapcsolojat, es errol valo ertekezest benchmark-okban a kulonbozo ISA-k kapcsan).
De amugy igazad van, neha ettol ez meg fontos, es "be kell vallalni" a regiszter "elpazarlasat" (elpazarlas: masra hasznalhato lenne, igy kevesebb "szabad" regisztered van, tobb dolgot kell memoriaba lepakolni: ergo, valamivel lassabb lesz. Egy modern valodi "RISC" procin ez nem olyan nagy gond, mivel van regiszter dogivel).
Nem erzem ugy, hogy egy EP specifikus programnal ez annyira lenyeh, ha "szabalyosan" EXOS-al mux stb, azzal toltodik be,miegymas, akkor kb adott hova lehet tenni. Viszont azonnal igazad van, ha ennel tobbet akarsz, mondjuk Z80 peldat nem tudok sajat munkaimbol hozni, de 6502 (es compatible) eseten en csinaltam olyat hogy a kod maga legyen teljesen platform fuggetlen (ha I/O, kepernyore iras, barmi van, azt kvazi syscall-kent hasznalt BRK csinalja): ekkor ugyanaz a binaris kod futhat barmilyen 6502 (v compatible) alapu gepen, ha ott kesz van hozza a "syscall interface" (OS-nek nem hivnam, mert ahhoz nem eleg fejlett meg), nyilvan itt relokacio is van (nem lehet tudni h a target gep memoriaszervezese milyen: hol van RAM, stb). Amde en ezt pl nem PIC koddal oldottam meg, hanem az o65 nevu formatummal, amiben relokacios tablak vannak, hogy kb milyen cimen kell pl egy byte-ot modositani. Ja, es o65-nek van symbol tablaja is stb, az mas kerdes h en nem hasznalom jelenleg, lasd BRK-s trukk.
Lehet ilyet is, de nem hiszem hogy megeri annyira, ha egy adott hw "gyari" OS-e ala akarsz tolni dolgokat.
A kulon virtualis cimterulet egy modern OS eseten igaz, amde nem vonatkozik lib-ekre: hiszen annak linkelodnie kell ugye a programodhoz pl. Szoval itt kellhet a PIC. Nyilvan ha irsz egy programot ami kiirja "hello world" az pl Linux alatt nem PIC kod, tekintve hogy a process sajat virtualis cimteruletet lat, es ugyanaz a "memoriakiosztas" a process szemszogebol legalabb. Viszont van eset, amikor ez nem eleg, lasd pl lib-ek esete.