Да, внешние кэши (почти?) Всегда PIPT, а самой памяти явно нужен физический адрес. Поэтому вам нужен физический адрес строки, когда вы отправляете ее в иерархию памяти.
В процессорах Intel кэши VIP1 L1 имеют все биты индекса из части адреса со смещением внутри страницы, поэтому virt = phys, что позволяет избежать проблем с наложением имен. В основном это PIPT, но он по-прежнему может извлекать данные / теги из набора параллельно с поиском TLB битов pagenumber для создания входных данных для компаратора тегов.
Полный физический адрес известен только из индекса + тега L1d, опять же, потому что он ведет себя как PIPT для всего, кроме задержки загрузки.
В общем случае с практически индексированными кэшами, где некоторые биты индекса берутся из номера страницы, это хороший вопрос . Такие системы существуют, и ОС часто использует раскраску страниц, чтобы избежать псевдонимов. (Поэтому им не нужно очищать кэш при переключении контекста.)
Фактически индексируемый физически помеченный кэш Синоним имеет диаграмму для одного такого VIPT L1d: физический тег расширяется на несколько бит, чтобы полностью доходить до смещения страницы, перекрывая верхний индекс бит .
Хорошее наблюдение, что кэш с обратной записью должен иметь возможность удалять грязные строки задолго после того, как проверка TLB для хранилища была выполнена. В отличие от загрузки, вы все равно не получите результат TLB, если только вы не сохранили его где-то.
Наличие в теге всех битов физического адреса выше смещения страницы (даже если оно перекрывает некоторые биты индекса) решает эту проблему.
Другим решением может быть сквозной кэш, поэтому у do всегда есть физический адрес из TLB для отправки с данными, даже если он не восстанавливаемый из тега + индекса кеша. Или для кэшей только для чтения, например кэши инструкций, виртуальность не проблема.
Но я не думаю, что проверка TLB при выселении может решить проблему для случая неперекрывающегося тега: у вас нет полного виртуального адреса больше , только младшие биты вашего номера страницы являются виртуальными (из индекса), остальные - физическими (из тега). Так что это неверный ввод в TLB.
Итак, помимо неэффективности, есть также не менее важная проблема, что она вообще не будет работать. : P Может быть, есть какой-то трюк, которого я не знаю, или что-то, чего я пропускаю, но я не думаю, что даже специальный TLB, индексированный обоими способами (phys-> virt и virt-> phys), мог бы работать, потому что множественные отображения разрешена одна и та же физическая страница.
Я думаю, что реальные процессоры, которые использовали кэши VIVT, обычно использовали их для сквозной записи. Я недостаточно хорошо знаю историю, чтобы сказать наверняка или привести какие-либо примеры. Я не понимаю, как они могут выполнять обратную запись, если они не хранят два тега (физических и виртуальных) для каждой строки.
Я думаю, что в ранних процессорах RISC часто было 8 тыс. Кешей с прямым отображением.
Но у классического 5-каскадного первого поколения MIPS R2000 (с использованием внешнего SRAM для его L1), по-видимому, был кэш обратной записи PIPT, если диаграмма на этих слайдах помечена как MIPS R2000 верно, показывая 14-битный индекс кэша, берущий несколько бит из номера физической страницы результата TLB. Но он по-прежнему работает с задержкой в 2 цикла для нагрузки (1 для генерации адреса на этапе EX, 1 для доступа к кэшу на этапе MEM).
В те дни тактовые частоты были намного ниже, а кэши + TLB стали больше. Я думаю, тогда 32-разрядный двоичный сумматор в ALU имел сравнимую задержку с доступом к кэш-памяти TLB +, возможно, не использовал в качестве агрессивных конструкций для переноса или переноса.
Таблица данных MIPS 4300i (вариант MIPS 4200, используемый в Nintendo 64) показывает, что происходит где / когда в 5-ступенчатом конвейере, а некоторые вещи происходят на восходящем или падающем фронте тактовой частоты.позволяя ему делить некоторые вещи на полчаса на сцене.(например, переадресация может работать с первой половины одной стадии до второй половины другой, например, для цели перехода -> выборка инструкций, все еще без необходимости дополнительной фиксации между полуэтапами.)
В любом случае, это показываетРасчет DVA (виртуальный адрес данных) происходит в EX: это регистр + imm16 из lw $t0, 1234($t1).Затем DTLB и DCR (чтение из кэша данных) происходят параллельно в первой половине этапа Data Cache.(Так что это VIPT).DTC (проверка тегов данных) и LA (выравнивание нагрузки, например, сдвиг для LWL / LWR или для LBU для извлечения байта из извлеченного слова) происходят параллельно во 2-й половине этапа.
Так что я до сих порне нашли подтверждения одноцикловой (после расчета адреса) PIPT MIPS.Но это определенное подтверждение того, что VIP-цикл с одним циклом был чем-то особенным.Из Википедии мы знаем, что ее D-кэш имел обратную запись с прямым отображением 8 КБ .