Всегда ли должен изменяться счетчик программы (после указания команды)?

Question

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

Я бы хотел немного расширить этот вопрос. Допустим, у нас есть следующий простой C-код:

// gcc -g min.c -o min.exe          # generate executable
// gcc -S min.c -o min.s            # generate assembler listing from source
// objdump -S min.exe > min.sdump   # generate assembler listing from executable
int main() {
  int a;
  a = 15;
  return a;
}

Сравнивая списки ассемблера (objdump -S не всегда очень точно разбрасывает строки исходного текста), я получаю что-то вроде этого:

min.s:                     min.sdump:
---------------------      -------------------------
main:                      08048394 <main>:
    pushl   %ebp                8048394: 55                    push   %ebp
    movl    %esp, %ebp          8048395: 89 e5                 mov    %esp,%ebp
    subl    $16, %esp           8048397: 83 ec 10              sub    $0x10,%esp
    movl    $15, -4(%ebp)       804839a: c7 45 fc 0f 00 00 00  movl   $0xf,-0x4(%ebp)
    movl    -4(%ebp), %eax      80483a1: 8b 45 fc              mov    -0x4(%ebp),%eax
    leave                       80483a4: c9                    leave
    ret                         80483a5: c3                    ret
    .size   main, .-main        80483a6: 90                    nop

Я знаю, что это, скорее всего, неправильно - но давайте предположим, что однобайтовые инструкции занимают один такт, а другие - два. Затем я мог бы взять «тик инструкции» в качестве нарастающего фронта часов в момент, когда «предыдущая» команда завершилась; как показано на следующей временной диаграмме (соответствует списку разборки; латексный / тикз-код для изображения можно найти здесь ):

Итак, перефразируя исходный вопрос:

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

Answer 1

Так что эта маленькая программа будет делать то, что вы просите:

int main(){
    loop: goto loop;
}

Она будет скомпилирована в нечто вроде этого:

.L3:
    jmp .L3

В результате компьютер останется прежнимпри взгляде со стороны.Внутри кремний будет делать что-то вроде этого за один шаг :

PC = argument of JMP

ПК будет настроен, но всегда будет иметь то же значение, что и в настоящее время.

Редактировать

Непонятно, что именно вы имеете в виду под «замком». Каждый бесконечный цикл будет потреблять ресурсы процессора и будет бесперебойным, если прерывания отключены.Это не имеет никакого отношения к тому, меняется компьютер или нет.Цикл сверху - это только наименьший возможный замкнутый цикл.

Однако: в реальных системах существует ARE прерываний - в каждой ОС с этими двумя буквами планировщик будет пробужден таймером прервать и передать ЦП следующему процессу.Даже на микроконтроллере, где обычно нет «операционной системы», внутренние и внешние прерывания используются в каждом нетривиальном случае.Фактически - жесткая петля сверху не является чем-то необычным на микроконтроллерах - основная работа выполнена, ЦП переходит в тесную петлю и ожидает следующего прерывания.Прерывание каким-то образом прервет цикл.

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

Answer 2

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