Регистрлерді қайта аттандыру: Компьютерлік архитектурадағы тиімділік арттыру тәсілі
Register renaming
Регистрлерді қайта аттандыру – процессордағы дерек тәуелділіктерін жою техникасы. Логикалық регистрлер физикалық регистрлерге шамаландырылады, өнімділікті арттырады.
Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Компьютерлік архитектурада тіркелімді қайта атау – физикалық тіркелімдерден логикалық тіркелімдерді абстракциялайтын техника. Әрбір логикалық тіркелімге оған сәйкес физикалық тіркелімдер жиынтығы тағайындалады. Машиналық тіл нұсқауы белгілі бір логикалық тіркелімге сілтеме жасағанда, процессор осы атауды дереу нақты бір физикалық тіркелімге ауыстырады. Физикалық тіркелімдер тікелей қолжетімді емес, оларға тек канондық атаулар арқылы ғана сілтеме жасауға болады. Бұл техника бір-бірімен деректер бойынша байланысы жоқ, бірінен соң бірі орындалатын нұсқаулардың тіркелімдерді қайта пайдалануынан туындайтын жалған деректер тәуелділігін жою үшін қолданылады. Осы жалған тәуелділікті жою нұсқаулар ағынындағы нұсқаулық деңгейдегі параллелизмді ашады, оны суперскалярлық және реттіліксіз орындау сияқты әртүрлі және толықтыратын техникалар арқылы өнімділікті арттыру үшін пайдалануға болады.
In computer architecture, register renaming is a technique that abstracts logical registers from physical registers. Every logical register has a set of physical registers associated with it. When a machine language instruction refers to a particular logical register, the processor transposes this name to one specific physical register on the fly. The physical registers are opaque and cannot be referenced directly but only via the canonical names. This technique is used to eliminate false data dependencies arising from the reuse of registers by successive instructions that do not have any real data dependencies between them. The elimination of these false data dependencies reveals more instruction level parallelism in an instruction stream, which can be exploited by various and complementary techniques such as superscalar and out of order execution for better performance.
Проблемаға көзқарас
Бағдарламалар мәндермен жұмыс істейтін нұсқаулардан құралады. Нұсқаулар осы мәндерді бір-бірінен ажырату үшін атауы керек. Типик нұсқау мынадай болуы мүмкін: қосу және және нәтижені сақтау орынында. Осы нұсқауда , және сақтау орындарының атаулары болып табылады. Манипуляцияланатын мәндерді бірнеше рет қатарынан пайдалану жиі кездеседі. Регистрлік машиналар осы мәндерді сақтайтын жоғары жылдамдықты жад орындары – процессор тіркелімдерін енгізу арқылы осы мүмкіндікті пайдаланады. Регистрлерді аралық мәндер ретінде пайдаланатын нұсқаулар негізгі жадқа кіретін нұсқаулардан әлдеқайда жылдам орындалады. Бұл өнімділіктің артуы RISC процессор дизайнының маңызды элементі болып табылады, ол өзінің барлық негізгі математикалық және логикалық нұсқаулары үшін регистрлерді қолданады. Нақты дизайндегі регистрлер жиынтығы тіркелім файлы деп аталады. Файлдағы жеке регистрлер машиналық кодта нөмірмен анықталады. Машиналық кодта санды кодтау үшін бірнеше бит қажет. Мысалы, Zilog Z80-де файлда сегіз жалпы мақсаттағы регистр болған. Сегіз мәннің біреуін таңдау үшін үш бит керек, өйткені 23 = 8. Файлдағы регистрлердің саны көбейсе, өнімділік жақсарады, себебі уақытша мәндердің көбірек саны файлда сақталады, соның арқасында жадтан сақтау немесе жүктеудің қымбат операцияларынан аулақ болуға болады. Әдетте, қазіргі заманғы процессорлар және үлкен нұсқау сөздері бар процессорлар мүмкіндігінше көбірек регистрлерді пайдаланады. Мысалы, x86 нұсқаулар жиынтығы архитектурасында 8 жалпы мақсаттағы регистр бар, x86 64-те 16, көптеген RISC процессорларында 32, ал IA 64-те 128 регистр бар. Үлкен тіркелім файлының артықшылықтары регистр нөмірін кодтау үшін көбірек биттерді пайдалану қажеттілігімен теңестіріледі. Мысалы, 32 биттік нұсқауларды қолданатын жүйеде үш регистр болуы мүмкін, сондықтан = түріндегі операцияларды орындауға болады. Егер тіркелім файлында 32 жазба болса, әр сілтемеге 5 бит керек болады, ал үш регистрдің жиынтығы 15 бит алады, операцияны және басқа ақпаратты кодтау үшін 17 бит қалады. Тіркелім файлын 64 жазбаға дейін кеңейту үшін 6 бит, барлығы 18 бит қажет болады. Бұл орындалу жылдамдығын арттырса да, нұсқауды кодтау үшін азырақ биттер қалады. Осыдан келіп, файлдың мөлшерін мүмкін болатын нұсқаулар санымен теңестіруге тырысу қажеттігі туындайды.
Programs are composed of instructions which operate on values. The instructions must name these values in order to distinguish them from one another. A typical instruction might say: add and and put the result in In this instruction, , and are the names of storage locations. It is common for the values being manipulated to be used several times in succession. Register machines take advantage of this by introducing a number of processor registers, which are high speed memory locations that hold these values. Instructions that use the registers as intermediate values will run much faster than those that access main memory. This performance increase is a key design element of the RISC processor design, which uses registers for all of its primary math and logical instructions. The collection of registers in a particular design is known as its register file. Individual registers in the file are referred to by number in the machine code. Encoding a number in the machine code requires several bits. For instance, in the Zilog Z80 there were eight general purpose registers in the file. To select one of eight values requires three bits, as 23 = 8. More registers in the file will result in better performance, as more temporary values can be held in the file and thus avoid the expensive operations of saving or loading from memory. Generally, more modern processors and those with larger instruction words will use more registers when possible. For example, the x86 instruction set architecture has 8 general purpose registers, x86 64 has 16, many RISCs have 32, and IA 64 has 128. The advantages of a larger register file are offset by the need to use more bits to encode the register number. For instance, in a system using 32 bit instructions, you might wish to have three registers, such that you can perform operations of the type = If the register file contains 32 entries, each one of the references will require 5 bits, and the set of three registers thus takes up 15 bits, leaving 17 to encode the operation and other information. Expanding the register file to 64 entries would require 6 bits, a total of 18 bits. While this may result in faster performance, it also means there are fewer bits left over for encoding the instruction. This leads to an effort to balance the size of the file with the number of possible instructions.
Тегтер индекстелген тіркелім файлы
Бұл MIPS R10000, Alpha 21264 және AMD Athlon FP бөлімінде қолданылатын қайта атау стилі. Атауды өзгерту кезеңінде әрбір сәулеттік тіркелгіге сілтеме жасалғанда (оқу немесе жазу үшін), сәулеттік индексті қайта карталау файлында іздеу жүргізіледі. Бұл файл тег пен дайындық битін қайтарады. Егер оған әлі орындалмаған кезекте тұрған нұсқаулық болса, тег дайын емес деп белгіленеді. Оқу операциялары үшін бұл тег нұсқаулықтағы сәулеттік тіркелгінің орнын басады. Әрбір тіркелгіге жазу үшін, бос тегтердің FIFO кезектерінен жаңа тег алынады және жаңа карталау қайта карталау файлына жазылады, соның арқасында болашақ нұсқаулар сәулеттік тіркелгіні оқығанда осы жаңа тегке сілтеме жасайды. Нұсқаулық әлі орындалмағандықтан тег дайын емес деп белгіленеді. Бұл сәулеттік тіркелгі үшін бұрын бөлінген физикалық тіркелгі, қайта реттеу буферіндегі нұсқаулықпен бірге сақталады – бұл FIFO, кодтау және аяқтау кезеңдері арасындағы бағдарламалық тәртіпте нұсқаулықтарды сақтайды. Содан кейін нұсқаулықтар әртүрлі кезектерге орналастырылады. Нұсқаулықтар орындалғанда, олардың нәтижелеріне арналған тегтер таратылады, ал кезектер осы тегтерді олардың дайын емес кіріс операндаларының тегтерімен сәйкестендіреді. Сәйкестік операнд дайын екенін білдіреді. Қайта карталау файлы да осы тегтермен сәйкес келеді, соның арқасында тиісті физикалық тіркелгілер дайын деп белгіленеді. Кезектегі бір нұсқаулықтың барлық кіріс операндалары дайын болғанда, ол нұсқаулық орындалуға дайын болады. Кезектер әр циклда әртүрлі функционалдық бөлімдерге жіберу үшін дайын нұсқаулықтарды таңдайды. Дайын емес нұсқаулықтар кезектерде қалады. Кезектерден нұсқаулықтарды ретсіз алып тастау оларды үлкен және энергияны көп тұтынатын етеді. Орындалған нұсқаулықтар тегтермен индекстелген физикалық тіркелгілер файлынан оқылады (тек тарату операндаларын айналып өтеді), содан кейін орындалады. Орындау нәтижелері тегтермен индекстелген физикалық тіркелгілер файлына жазылады, сондай-ақ әрбір функционалдық бөлімге дейінгі айналма желісіне таратылады. Аяқтау кезеңі жазылған сәулеттік тіркелгінің бұрынғы тегін бос кезекке қояды, соның арқасында оны жаңа кодталған нұсқаулық үшін қайта пайдалануға болады. Қателік немесе тармақ болжамының қатесі, қайта карталау файлының соңғы жарамды нұсқаулықтағы қайта карталау күйіне дейін күйдің көшірмелерін біріктіру және реттелген алдын ала аяқтау кезектеріндегі бұрынғы тегтер арқылы кері қайтаруға себеп болады. Бұл механизм қажет болғандықтан және кез келген қайта карталау күйін қалпына келтіре алатындықтан (тек ағымдағы аяқталатын нұсқаулықтан бұрынғы күйін ғана емес), тармақ болжамының қатесін тармақ аяқталуына дейін өңдеуге болады, ықтимал тармақ болжамының қатесіне байланысты кідірістің уақытын жасыра отырып.
This is the renaming style used in the MIPS R10000, the Alpha 21264, and in the FP section of the AMD Athlon. In the renaming stage, every architectural register referenced (for read or write) is looked up in an architecturally indexed remap file. This file returns a tag and a ready bit. The tag is non ready if there is a queued instruction which will write to it that has not yet executed. For read operands, this tag takes the place of the architectural register in the instruction. For every register write, a new tag is pulled from a free tag FIFO, and a new mapping is written into the remap file, so that future instructions reading the architectural register will refer to this new tag. The tag is marked as unready, because the instruction has not yet executed. The previous physical register allocated for that architectural register is saved with the instruction in the reorder buffer, which is a FIFO that holds the instructions in program order between the decode and graduation stages. The instructions are then placed in various issue queues. As instructions are executed, the tags for their results are broadcast, and the issue queues match these tags against the tags of their non ready source operands. A match means that the operand is ready. The remap file also matches these tags, so that it can mark the corresponding physical registers as ready. When all the operands of an instruction in an issue queue are ready, that instruction is ready to issue. The issue queues pick ready instructions to send to the various functional units each cycle. Non ready instructions stay in the issue queues. This unordered removal of instructions from the issue queues can make them large and power consuming. Issued instructions read from a tag indexed physical register file (bypassing just broadcast operands) and then execute. Execution results are written to tag indexed physical register file, as well as broadcast to the bypass network preceding each functional unit. Graduation puts the previous tag for the written architectural register into the free queue so that it can be reused for a newly decoded instruction. An exception or branch misprediction causes the remap file to back up to the remap state at last valid instruction via combination of state snapshots and cycling through the previous tags in the in order pre graduation queue. Since this mechanism is required, and since it can recover any remap state (not just the state before the instruction currently being graduated), branch mispredictions can be handled before the branch reaches graduation, potentially hiding the branch misprediction latency.
Резервтік станциялар
Бұл AMD K7 және K8 жобаларының бүтін сандар бөлімінде қолданылатын стиль. Атын өзгерту кезеңінде, оқылатын әрбір архитектуралық регистр болашақтағы файлда да, қайта атау файлында да ізделеді. Болашақтағы файлдан оқылу, егер оған жазуға күтіліп отырған нұсқау болмаса, сол регистрдің мәнін береді (яғни, ол дайын). Нұсқау орындалу кезегіне қойылғанда, болашақтағы файлдан оқылған мәндер брондау станцияларындағы сәйкес жазбаларға жазылады. Нұсқаудағы регистр жазуы, қайта атау файлына жаңа, дайын емес белгі жазылуына себеп болады. Белгі нөмірі әдетте нұсқаулар тізбегімен беріледі – бос белгілерге арналған FIFO қажет емес. Белгілермен индекстелген схемадағыдай, орындалу кезегі дайын емес операндар үшін сәйкес белгілердің хабарламаларын күтеді. Белгілермен индекстелген схемадан айырмашылығы, сәйкес белгілер орындалу кезегі жазбасының брондау станциясына сәйкес хабарлама мәнін жазуға мәжбүрлейді. Орындалған нұсқаулар өз аргументтерін брондау станциясынан оқиды, жаңа ғана хабарланған операндарды айналып өтеді, содан кейін орындалады. Бұрын айтылғандай, брондау станциясының регистрлік файлдары көбінесе кішкентай болады, мысалы, сегіз жазбаға дейін. Орындау нәтижелері қайта реттеу буферіне, брондау станцияларына (егер орындалу кезегі жазбасында сәйкес белгі болса) және егер бұл архитектуралық регистрді нысаналайтын соңғы нұсқау болса, болашақтағы файлға жазылады (осы жағдайда регистр дайын деп белгіленеді). Бітіру кезінде мән қайта реттеу буферінен архитектуралық регистрлік файлға көшіріледі. Архитектуралық регистрлік файлдың жалғыз мақсаты – ерекше жағдайларды және тармақталу қателіктерін қалпына келтіру. Бітіру кезінде анықталған ерекше жағдайлар мен тармақталу қателіктері архитектуралық файлдың болашақтағы файлға көшірілуіне және қайта атау файлындағы барлық регистрлердің дайын деп белгіленуіне себеп болады. Декодтау мен бітіру арасында болашақтағы файлдың күйін қайта құрудың әдетте жолы болмайды, сондықтан тармақталу қателіктерінен ерте қалпына келтіру мүмкін емес.
This is the style used in the integer section of the AMD K7 and K8 designs. In the renaming stage, every architectural register referenced for reads is looked up in both the architecturally indexed future file and the rename file. The future file read gives the value of that register, if there is no outstanding instruction yet to write to it (i. e., it's ready). When the instruction is placed in an issue queue, the values read from the future file are written into the corresponding entries in the reservation stations. Register writes in the instruction cause a new, non ready tag to be written into the rename file. The tag number is usually serially allocated in instruction order—no free tag FIFO is necessary. Just as with the tag indexed scheme, the issue queues wait for non ready operands to see matching tag broadcasts. Unlike the tag indexed scheme, matching tags cause the corresponding broadcast value to be written into the issue queue entry's reservation station. Issued instructions read their arguments from the reservation station, bypass just broadcast operands, and then execute. As mentioned earlier, the reservation station register files are usually small, with perhaps eight entries. Execution results are written to the reorder buffer, to the reservation stations (if the issue queue entry has a matching tag), and to the future file if this is the last instruction to target that architectural register (in which case register is marked ready). Graduation copies the value from the reorder buffer into the architectural register file. The sole use of the architectural register file is to recover from exceptions and branch mispredictions. Exceptions and branch mispredictions, recognized at graduation, cause the architectural file to be copied to the future file, and all registers marked as ready in the rename file. There is usually no way to reconstruct the state of the future file for some instruction intermediate between decode and graduation, so there is usually no way to do early recovery from branch mispredictions.
Схемаларды салыстыру
Екі схемада да нұсқаулар кезекке ретпен енгізіледі, бірақ ретсіз алынып тасталады. Егер кезектер бос ұяларды біріктірмесе, онда олар көптеген қолданылмаған жазбаларға ие болады немесе бірнеше нұсқау бір уақытта дайын болғанда айнымалы басымдықпен кодтау қажет болады. Ұяларды біріктіретін кезектерде басымдықпен кодтау оңайырақ, бірақ нұсқауларды кезек бойынша жылжыту үшін қарапайым, бірақ үлкен тізбектер қажет. Резервтік станциялар қайта аттаудан орындауға дейінгі уақытты жақсырақ қысқартады, себебі қайта аттау кезеңінде физикалық регистр нөмірін іздеудің орнына тікелей регистр мәндерін табады, содан кейін мәнді табу үшін оны пайдаланады. Бұл кідіріс тармақ болжауының қатесінен туындайтын кідірістің бір бөлігі болып табылады. Резервтік станциялар нұсқауды беруден орындауға дейінгі уақытты да жақсартады, өйткені әрбір жергілікті регистрлік файл тегтермен индекстелген схеманың үлкен орталық файлынан кішірек. Тегтерді жасау және ерекше жағдайларды өңдеу резервтік станция схемасында оңайырақ, төменде талқыланғандай. Резервтік станциялар қолданатын физикалық регистрлік файлдар әдетте қызмет ететін кезекпен бірге қолданылмаған жазбаларды біріктіреді, бұл осы регистрлік файлдарды жиынтық бойынша үлкен етеді, көбірек қуатты тұтынады және тегтермен индекстелген схемада қолданылатын қарапайым регистрлік файлдарға қарағанда күрделірек жасайды. Жағдайды нашарлату үшін, әр резервтік станцияның әрбір жазбасын әрбір нәтижелік шина жаза алады, сондықтан, мысалы, функционалдық бірлікке 8 кезек жазбасы бар резервтік станция машинасы теңдестірілген тегтермен индекстелген машинаға қарағанда әдетте 9 есе көп айналма желілеріне ие болады. Осылайша, нәтижелерді жіберу тегтермен индекстелген дизайнға қарағанда әлдеқайда көп қуат пен аумаққа талап етеді. Сонымен қатар, резервтік станция схемасында нәтижелік мәнді сақтауға болатын төрт орын бар (Болашақ файлы, резервтік станция, қайта реттеу буфері және архитектуралық файл), ал тегтермен индекстелген схемада тек біреу ғана (физикалық регистрлік файл) бар. Функционалдық бірліктерден алынған нәтижелер осы сақтау орындарының барлығына жіберілгендіктен, тегтермен индекстелген схемаға қарағанда машинадағы көптеген орындарға жетуі керек, бұл функцияға көбірек қуат, аумақ және уақыт қажет етеді. Дегенмен, өте дәл тармақ болжау схемаларымен жабдықталған машиналарда және егер орындалу уақыты маңызды мәселе болса, резервтік станциялар өте жақсы жұмыс істей алады.
In both schemes, instructions are inserted in order into the issue queues, but are removed out of order. If the queues do not collapse empty slots, then they will either have many unused entries, or require some sort of variable priority encoding for when multiple instructions are simultaneously ready to go. Queues that collapse holes have simpler priority encoding, but require simple but large circuitry to advance instructions through the queue. Reservation stations have better latency from rename to execute, because the rename stage finds the register values directly, rather than finding the physical register number, and then using that to find the value. This latency shows up as a component of the branch misprediction latency. Reservation stations also have better latency from instruction issue to execution, because each local register file is smaller than the large central file of the tag indexed scheme. Tag generation and exception processing are also simpler in the reservation station scheme, as discussed below. The physical register files used by reservation stations usually collapse unused entries in parallel with the issue queue they serve, which makes these register files larger in aggregate, and consume more power, and more complicated than the simpler register files used in a tag indexed scheme. Worse yet, every entry in each reservation station can be written by every result bus, so that a reservation station machine with, e. g., 8 issue queue entries per functional unit will typically have 9 times as many bypass networks as an equivalent tag indexed machine. Consequently, result forwarding consumes much more power and area than in a tag indexed design. Furthermore, the reservation station scheme has four places (Future File, Reservation Station, Reorder Buffer and Architectural File) where a result value can be stored, whereas the tag indexed scheme has just one (the physical register file). Because the results from the functional units, broadcast to all these storage locations, must reach a much larger number of locations in the machine than in the tag indexed scheme, this function consumes more power, area, and time. Still, in machines equipped with very accurate branch prediction schemes and if execute latencies are a major concern, reservation stations can work remarkably well.