Форум РадиоКот

Вот Gudd-Head вставил картинку из первого поста этой темы...
А там lost in translation, однако!
"Рисунок 1.21 Последовательность выполнения команд в конвейере"
А теперь из спецификации, например, на мегу48 (2545R–AVR–07/09)

"Figure 6-4. The Parallel Instruction Fetches and Instruction Executions"
Перевести можно как "Параллельное извлечение и исполнение инструкций".
Ни слова о конвейере. В атмеле, таки, разделяют выборку команды и её исполнение...

Текст, как и даташит, надо читать полностью... а не как больше нравится...

Figure 6 shows the parallel instruction fetches and instruction executions enabled by the Harvard
architecture and the fast-access Register File concept. This is the basic pipelining concept to obtain up to 1 MIPS per MHz with the corresponding unique results for functions per cost,
functions per clocks, and functions per power-unit.

In order to maximize performance and parallelism, the AVR uses a Harvard architecture – with
separate memories and buses for program and data. Instructions in the program memory are
executed with a single level pipelining. While one instruction is being executed, the next instruction
is pre-fetched from the program memory. This concept enables instructions to be executed
in every clock cycle.

Я указал на несоответствие русской подписи к картинке и текста в спецификации одного из контроллеров.
Да, в тексте есть упоминание конвейера.
Ты сам же выделил - (из второй цитаты) инструкция выполняется на одноуровневом конвейере, в то время как другая извлекается из памяти. (из первой цитаты) Это основная идея конвейера.
Тогда что есть "single level pipelining" - это сколько тактов? single - один?!

Kavka писал(а):Тогда что есть "single level pipelining" - это сколько тактов? single - один?!

А где здесь про такты? По-моему это переводится как: "одно конвейерном уровне".
Т.е. конвейер есть, но самый простой - одноуровневый. В то время как одна команда выполняется, следующая инструкция
предварительно извлекается из памяти программы.

Kavka писал(а):"Figure 6-4. The Parallel Instruction Fetches and Instruction Executions"
Перевести можно как "Параллельное извлечение и исполнение инструкций".
Ни слова о конвейере

Перевод почти точный, а вот его интерпретация неверна. Имеется в виду, что параллельно производится выполнение одной инструкции и выборка следующей. Обратите внимание на другие надписи на рисунке: "1st Instruction Fetch" и т.д.

SII писал(а):а вот его интерпретация неверна. Имеется в виду, что параллельно производится выполнение одной инструкции и выборка следующей. Обратите внимание на другие надписи на рисунке: "1st Instruction Fetch" и т.д.

Интерпретирую я правильно.

Вопрос был (первое сообщение темы)

feodorsumkin писал(а):АЛУ в AVR-микроконтроллерах прямо к РОНам подсоединено (судя по документации). Это как? Отдельная шина от АЛУ к РОНам что ли? Или всё же через общую шину данных обмен идёт, просто без промежуточных регистров-защёлок на входах АЛУ (тогда в принципе можно сказать, что АЛУ напрямую к РОНам подсоединено).

Но в любом случае это дело не меняет. Как можно извлекать информацию из регистра и тут же в него же что-то записывать ?

Т.е. как происходит, например, суммирование за один такт (выборка команды не рассматривается!)?

Выше, тут и тут принцип был описан.
Очень упрощённая схема. Только идея, без деталей.

По картинке: inst3 является и источником и приёмником одновременно и работает все по одному фронту.
На pin-ы не обращайте внимания - нарисовал, чтобы квартус не ругался.

Только сейчас увидел вашу дискуссию вокруг конвееров, и чего так ругаться
Тактируется только начало выполнения команды(выборка регистров), затем по завершению выборки происходит выполнение операции а сразу вслед за ней запись результата(т.е. выполнение операции и запись регистра выполняются без синхронизации)
по фронту следующего такта уже выполняется следующая инструкция(несмотря на то что запись результата может быть еще не завершена)

И никаких PLL

естественно если в следующей команде требуется излечь содержимое этого регистра(в который происходит запись) - возможен конфликт конвеера, в таком случае нужно либо уменьшить тактовую частоту чтоб запись результата происходила раньше чем начнется следующий такт, либо переделать программу чтоб такие команды не шли одна за другой

unalex писал(а):(т.е. выполнение операции и запись регистра выполняются без синхронизации)
по фронту следующего такта уже выполняется следующая инструкция(несмотря на то что запись результата может быть еще не завершена)

Проиллюстрируйте это на примере команды инкремента регистра с записью результата в тот же регистр.
Разве запрещено писать последовательно несколько инкрементов?
Фронт один, его хватит только на счетчик команд...
Пускай дешифратор команд и адресные селекторы РОНов не тактируются, пускай АЛУ так же выдаст результат на выход только с задержкой распространения, а далее как? Кто защелкнет результат в тот же РОН, не отключая всю предыдущую байду? Какой фронт? Чем он будет сформирован?

Фронт следующего цикла.

КРАМ писал(а):Кто защелкнет результат в тот же РОН, не отключая всю предыдущую байду? Какой фронт? Чем он будет сформирован?

чисто эмпирически возможно после выполнения операции АЛУ сам формирует такт для защелкивания РОНА, или же все выполнено по синхронной схеме

фронт - выборка, спад - рассчет, фронт следующего тактового сигнала - запись и одновременно выборка для новой команды

проверьте, такая последовательность команд работает корректно?

ADD R16, R17
ADD R16, R17

выполнится ли сложение дважды или возникнет конфликт?

SII писал(а):Фронт следующего цикла.

То есть система построена на "гонках" фронтов...
Время распространения больше, чем время переключения счетчика команд...
А как же конвейер?
ЗЫ. Только мне не понятно, а зачем все это? Если схемотехника и топология столь быстры, что способны за время одного периода частоты тактирования перенести сигнал на выход, то что мешает его тактировать с необходимой частотой? Есть архитектуры, где за два периода тактирования исполняется машцикл. Т.е. тактовая вдвое выше. Ну и что?
В чем правда, брат? (с)

КРАМ писал(а):То есть система построена на "гонках" фронтов...
Время распространения больше, чем время переключения счетчика команд...
А как же конвейер?

Ниччего не понимаю Какие гонки, время распространения чего?

ЗЫ. Только мне не понятно, а зачем все это? Если схемотехника и топология столь быстры, что способны за время одного периода частоты тактирования перенести сигнал на выход, то что мешает его тактировать с необходимой частотой? Есть архитектуры, где за два периода тактирования исполняется машцикл. Т.е. тактовая вдвое выше. Ну и что?

Без конвейера работа получается строго последовательная:

1. Прочитать очередную команду из памяти и сохранить её во внутреннем регистре команд.
2. Выполнить прочитанную команду.
3. При необходимости проанализировать её результаты, определить адрес следующей выполняемой команды и соответствующим образом модифицировать счётчик команд (из-за наличия условных переходов это не обязательно команда, следующая за только что исполненной). Выполнить эти действия до завершения шага 2 нельзя из-за условных переходов.

Эти действия могут быть выполнены за один длинный такт, при этом потребуются внутренние сигналы синхронизации (формируемые, например, линиями задержек). Можно их выполнить и за несколько тактов -- именно так, собственно, и работали простые процессоры типа 8080, 8086 и т.д. Более того, при достаточно сложной системе команд число тактов, необходимых для выполнения команды, может сильно различаться -- в том же 8086 самые быстрые, если память не изменяет, выполнялись за два такта, а самые медленные (деление) могли выполняться несколько десятков тактов.

Конвейер позволяет совместить стадии выборки и выполнения команды в предположении, что следующая выполняемая команда располагается прямо за текущей. Для простого процессора (вроде AVR8) каждый такт одновременно выполняются такие действия:

1. Выборка команды по адресу, находящемуся на начало такта в счётчике команд, и запоминание её в регистре кода команды для исполнения во время следующего такта.
2. Увеличение адреса в счётчике команд, чтобы он указывал на команду, следующую за выбираемой в п. 1.
3. Исполнение команды, код которой был загружен в предыдущем такте. Если ей окажется команда успешно выполняемого перехода (т.е. безусловного перехода либо условного, условие для которого выполнено), то модификация поведения процессора для пп. 1 и 2: 1) в регистр кода команды будет загружен код команды "нет операции", благодаря которому в следующем АЛУ процессора никакой полезной работы выполнять не будет; 2) в счётчик команд будет занесён адрес не следующей команды, а той, что указана в команде перехода.

Таким образом, физически каждая команда выполняется два такта: на первом -- её выборка, на втором -- собственно исполнение. Однако логически при отсутствии переходов команды выполняются по одной за такт, поскольку АЛУ выполняет операции на каждом такте. Именно поэтому для сложения указывается длительность 1 такт, а вот для условного перехода -- 1 или 2 такта: второй такт для случая, когда переход произошёл.

Если несколько модифицировать эту схему, становится возможным обслуживать прерывания: при их возникновении опять-таки модифицируются пп. 1 и 2: в регистр кода команды помещается код "нет операции", а в счётчик команд -- адрес точки входа в обработчик прерывания. На следующем такте АЛУ ничего не делает, а блок выборки команд считает из памяти эту команду, и дальше начнётся выполнение обработчика.

P.S. Естественно, эта схема организации конвейера является простейшей и применима к процессорам типа AVR8, но не к более сложным. Там конвейеры бывают посложнее и позапутаннее. Например, у большинства процессорных ядер ARMов конвейер трёхступенчатый (хотя есть и пятиступенчатые ядра, а может, и другие -- я этот вопрос специально не изучал). Первый конвейер, с которым я столкнулся на практике, в ЕС-1130, был тоже трёхступенчатым (меня тогда поразило, как просто и элегантно удалось резко поднять производительность процессора по сравнению с, например, ЕС-1035, используя, в общем-то, ту же самую элементную базу -- ЭСЛ-"рассыпуху" 500-й серии). А вот в MIPS, чтобы не тормозить конвейер из-за условных переходов, сделали так, что для анализа на переход берутся результаты не команды, непосредственно предшествующей команде перехода, а более ранней -- только не помню, второй или третьей. Ну а во всяких современных Core и прочих архитектуры IA-32 конвейер намного сложней (собственно, их там даже несколько на разных уровнях).
P.S. В некоторых архитектурах, чтобы исключ

на разных этапах(выборка, исполнение, сохранение результата) работают разные блоки - АЛУ, регистры, счетчик команд и т.д.и т.п.

При строго последовательной системе получается что во время исполнения одной из операций, некоторые блоки простаивают, а в конвейерной реализации удается их использовать более эффективно

Аналогично как с простым конвейером на производстве, когда каждый методично выполняет свою работу. В противном случае время тратилось бы на различные подготовительные операции(смена инструмента, рабочего места и т.п.) и при той же скорости выполнения тех.процессов общее затраченное время на полный цикл было бы больше

Что-то вы все стараетесь сделать систему посложнее, помудрее.
Нет чтобы подумать, как получить более простое и надежное решение, и что гораздо все проще решается умножителем частоты внутреннего тактирования. Это ведь стандартное решение для процессоров уже пару десятков лет. Тем более, что частоты здесь мизерные.

Думаю вполне реально сложить два регистра за один такт на простой логике без умножения частоты, если например, по переднему фронту сигнала тактирования взять данные, а по заднему фронту выдать результат.

И напрягаться на борьбе с гвоздями?

Тактирование контроллера без ПЛЛ имеет конечно одно существенное достоинство. Джиттер кварца (фазовый шум) на два-три порядка ниже, чем после ПЛЛ. Однако, применение ПЛЛ позволяет получить сетку возможных частот, которую можно к тому же переключать программно на лету.
В связи с последним, выкрутасы с кучей параллельных шин в топологии с целью нетактируемого исполнения команды выглядят сомнительными.
На это же наводит нынешняя ситуация с архитектурами. Если конечно я не заблуждаюсь по убогости.

Муркиз писал(а):И напрягаться на борьбе с гвоздями?

выше уже было написано самое основное достоинство конвейера - а именно максимальное использование ресурсов и отсутствие ненужных простоев
при той же таковой частоте производительность будет выше

а гвозди они не так уж и часто возникают, тем более есть способы их избежать - в новой операции выбрать другой регистр, в который не производится запись, измененить последовательность операций и т.п.
см.
Вычислительный конвейер
Конфликт конвейера(англ)