Средства и методы разработки

ответы  > инструкции (из одного параграфа) раскладываются по узлам статичкески и тупо - то есть в 1-ый узел попадают инструкции 1,5,9,13... во второй 2,6,10... и т.д.? да, распределение команд по клеткам пока статическое > "адреса" операндов тоже вычисляются статически, то есть если мы злонамерено сдвинем поток инструкций и в 1-ый узел попадет инструкция 6, то операнды будут взяты не оттуда, откуда надо? адреса операндов вычисляются всегда относительно текущей инструкции, т.е. 0-невалидно, 1-предыдущая инструкция, 2 инструкция перед предыдущей и т.д. Если вставить инструкцию где-то в середине, то адреса "поплывут" и будет неправильно, к счастью последняя версия ассемблера поддерживает метки и проблема не особо актуальна: ld adr1 ld adr2 add @1, @2 st addr3, @1 можно заменить на l_adr1: ld adr1 l_adr2: ld adr2 l_summ: add @l_adr2, @l_adr1 st addr3, @l_summ > как вычисляется метрика (та что не дальше 63) - как разность между номерами узлов или хитрее, как нумеруются узлы? поскольку адресация идёт не от начала параграфа, а от текущей инструкции, то метрика 63 - это всего лишь самая старая инструкция, значение которой можно получить > так сразу непонятно - зачем ждать декодирования инструкций приемников результата? потому что коммутатор не имеет буферизации, и результаты попадают сразу в поля операндов декодированных инструкций; вновь декодированным инструкциям просто неоткуда взять операнды, если зависимые инструкции уже исполнены; это тупость, но это так именно у них и работает > я подозреваю, что параграфы разделяются по старшим битам адреса? нет, у каждой инструкции есть один бит, установка которого сигнализирует, что это последняя команда параграфа, в ассемблере есть специальная псевдокоманда > ну то есть существует ограничение на кол-во инструкций в параграфе и короткие параграфы нужно набивать "ноп-ами"? нет, ограничений на длину параграфов никаких нет, наоборот, чем он длиннее, тем выше производительность, но не нужно забывать, что переходы внутри параграфа невозможны, это строго всегда линейный участок кода > мультипортовый регистровый файл посложнее сделать, чем write buffer мультипортовость здесь ни при чём, не нужно забывать, что процессор OoOE, поэтому запись в регистр может исполниться раньше чтения, что-бы это не вызывало проблем читается всегда только состояние регистров на момент входа в параграф, а записанные значения будут доступны только в следующем параграфе. Это не проблема, поскольку все эти значения можно получить из коммутатора (откуда они и записываются в регистры), поэтому читать новое значение регистра нет смысла - можно прямо получить значение из той инструкции, которая его вычислила. А вот в следующем параграфе получить значения можно только из регистров - результаты инструкций предыдущего параграфа недоступны - этот геморрой приводит к значительному оверхеду.