특정 컴퓨터 시스템이 주어지면 어셈블리 코드의 실제 정확한 런타임을 추정 할 수 있습니다

이것은 어셈블리 코드입니다

section .text
    global _start       ;must be declared for using gcc
_start:                     ;tell linker entry point
    mov edx, len    ;message length
    mov ecx, msg    ;message to write
    mov ebx, 1      ;file descriptor (stdout)
    mov eax, 4      ;system call number (sys_write)
    int 0x80        ;call kernel
    mov eax, 1      ;system call number (sys_exit)
    int 0x80        ;call kernel

section .data

msg db  'Hello, world!',0xa ;our dear string
len equ $ - msg         ;length of our dear string

특정 컴퓨터 시스템이 주어지면 어셈블리 코드의 실제 런타임을 정확하게 예측할 수 있습니다.

1986 년경의 68020 프로세서 인 다소 원시적 인 CPU 매뉴얼에서 인용 할 수있다. "프로세서 구현에 대한 정확한 지식이 있더라도 명령 시퀀스의 정확한 런타임 계산은 어렵다". 우리는 가지고 있지 않습니다. 그리고 최신 프로세서와 비교할 때 그 CPU는 원시적 이었습니다 .

해당 코드의 런타임을 예측할 수 없으며 둘 다 예측할 수 없습니다. 그러나 프로세서에 대량의 캐시가 있고 대량의 비 순차적 기능이있는 코드의 "런타임"을 정의 할 수도 없습니다 . 일반적인 최신 프로세서는 "실행 중", 즉 다양한 실행 단계에있는 200 개의 명령어를 가질 수 있습니다. 따라서 첫 번째 명령어 바이트를 읽으려고 시도한 후 마지막 명령어를 폐기하는 데 걸리는 시간은 상당히 길 수 있습니다. 그러나 프로세서가 필요로하는 다른 모든 작업에 대한 실제 지연은 훨씬 적을 수 있습니다.

물론 운영 체제를 두 번 호출하면이를 완전히 예측할 수 없습니다. "stdout에 쓰기"가 실제로 무엇을하는지 모르므로 시간을 예측할 수 없습니다.

코드를 실행하는 정확한 순간에 컴퓨터의 클럭 속도를 알 수 없습니다. 일부 절전 모드에있을 수 있습니다. 컴퓨터가 뜨거워 져서 클럭 속도가 느려질 수 있으므로 동일한 클럭주기 횟수에도 다른 시간이 걸릴 수 있습니다.

전체적으로 : 완전히 예측할 수 없습니다.

일반적으로이 작업을 수행 할 수는 없지만 어떤 의미에서는 많은 작업을 수행 할 수 있으며 실제로 몇 가지 역사적인 경우가 있었습니다 .

아타리 2600 (또는 아타리 비디오 컴퓨터 시스템), 아타리은 CPU가 가진 의미, 장치를 프레임 버퍼를 제공하기 위해 감당할 수있는 최초의 가정용 비디오 게임 시스템 중 하나 먼저 시대 이후 시스템과는 달리 1978 년에 출시 된 생성 할 항목을 결정하기 위해 모든 스캔 라인에서 코드 실행-이 코드를 실행하는 데 17.08 마이크로 초 (HBlank 간격) 이상 걸리면 스캔 라인이 그리기 전에 그래픽이 올바르게 설정되지 않습니다. 더 나쁜 것은 프로그래머가 Atari가 일반적으로 허용하는 것보다 더 복잡한 내용을 그리기를 원한다면, 명령에 대한 정확한 시간을 측정하고 빔이 그려 질 때 그래픽 레지스터를 전체 스캔 라인에 대해 57.29 마이크로 초의 범위로 변경해야했습니다.

그러나 Atari 2600은 6502 기반의 다른 많은 시스템과 마찬가지로이 시나리오에 필요한 시간 관리를 신중하게 수행 할 수있는 매우 중요한 기능을 가지고 있습니다. CPU, RAM 및 TV 신호는 모두 동일한 마스터를 기반으로 클럭을 모두 소모했습니다. 시계. TV 신호는 3.98 MHz 클럭에서 흘러 나와 TV 신호를 관리하는 정수 "컬러 클럭"으로 시간을 분할했으며 CPU 및 RAM 클럭의주기는 정확히 3 개의 컬러 클럭이므로 CPU의 클럭은 현재 진행 TV 신호에 대한 정확한 시간 측정. (이에 대한 자세한 내용 은 Stella Atari 2600 에뮬레이터 용으로 작성된 Stella Programmer 's Guide를 확인하십시오 ).

또한이 운영 환경은 모든 CPU 명령어가 모든 경우에 정의 된주기의주기를 가짐을 의미했으며 많은 6502 개발자가이 정보를 참조 표에 게시했습니다. 예를 들어, 다음 표CMP 에서 가져온 (메모리와 누산기 비교) 명령에 대한이 항목을 고려 하십시오 .

CMP  Compare Memory with Accumulator

     A - M                            N Z C I D V
                                    + + + - - -

     addressing    assembler    opc  bytes  cycles
     --------------------------------------------
     immediate     CMP #oper     C9    2     2
     zeropage      CMP oper      C5    2     3
     zeropage,X    CMP oper,X    D5    2     4
     absolute      CMP oper      CD    3     4
     absolute,X    CMP oper,X    DD    3     4*
     absolute,Y    CMP oper,Y    D9    3     4*
     (indirect,X)  CMP (oper,X)  C1    2     6
     (indirect),Y  CMP (oper),Y  D1    2     5*

*  add 1 to cycles if page boundary is crossed

이 모든 정보를 사용하여 Atari 2600 (및 기타 6502 개발자)은 코드를 실행하는 데 걸리는 시간을 정확히 파악하고 필요한 작업을 수행하고 Atari의 TV 신호 타이밍 요구 사항을 준수하는 루틴을 구성 할 수있었습니다. 또한이 타이밍이 매우 정확하기 때문에 (특히 NOP와 같은 시간 낭비적인 지침에 대해) 그래픽을 그릴 때이를 사용하여 그래픽을 수정할 수도있었습니다.

물론, Atari의 6502는 매우 구체적인 경우이며,이 모든 것은 시스템에 다음이 모두 있기 때문에 가능합니다.

• RAM을 포함한 모든 것을 실행 한 마스터 시계. 최신 시스템은 CPU와 RAM에 대해 독립적 인 클럭을 가지고 있으며, RAM 클럭은 종종 느리고 두 개가 반드시 동기화되지는 않습니다.
• 어떤 종류의 캐싱도 없습니다. 6502는 항상 DRAM에 직접 액세스합니다. 최신 시스템에는 상태를 예측하기 어렵게하는 SRAM 캐시가 있습니다. 캐시가있는 시스템의 동작을 여전히 예측할 수는 있지만 확실히 더 어렵습니다.
• 동시에 실행되는 다른 프로그램이 없습니다. 카트리지의 프로그램이 시스템을 완전히 제어했습니다. 최신 시스템은 비 결정적 스케줄링 알고리즘을 사용하여 여러 프로그램을 한 번에 실행합니다.
• 신호가 제 시간에 시스템을 가로 질러 이동할 수있을 정도로 클럭 속도가 느립니다. 예를 들어 4GHz의 클럭 속도를 가진 최신 시스템 에서는 절반 미터 마더 보드의 길이를 이동하는 데 6.67 클럭 사이클 의 광자가 필요합니다. 보드의 신호가 장치에 도달하는 데에도 두 번 이상의주기가 걸리기 때문에 단 한 번의 주기로
• 잘 변하지 않는 잘 정의 된 클럭 속도 (아타리의 경우 1.19MHz)-최신 시스템의 CPU 속도는 항상 변경되는 반면, 아타리는 TV 신호에 영향을주지 않고는이를 수행 할 수 없습니다.
• 게시 된 사이클 타이밍-x86은 명령에 걸리는 시간을 정의하지 않습니다.

이 모든 것들이 합쳐져서 정확한 시간이 걸리는 명령 세트를 만들 수있는 시스템을 만들었습니다.이 응용 프로그램에서는 이것이 정확히 요구되었습니다. 대부분의 시스템은 단순히 필요하지 않기 때문에 이러한 정도의 정밀도를 갖지 않습니다. 계산이 완료 될 때 수행되거나 정확한 시간이 필요한 경우 독립적 인 클럭을 쿼리 할 수 ​​있습니다. 그러나 일부 임베디드 시스템에서와 같이 요구가 옳다면 여전히 나타날 수 있으며 이러한 환경에서 코드를 실행하는 데 걸리는 시간을 정확하게 결정할 수 있습니다.

또한이 모든 것이 정확한 시간이 걸리는 일련의 조립 지침 을 구성 하는 데만 적용된다는 큰 면책 조항을 추가해야합니다 . 싶은 것은 심지어 이러한 환경에서, 조립의 어떤 임의의 조각을, 그리고 "? 얼마나 오래이 걸릴 실행할 않는다"요청하는 경우, 당신은 절대적으로 할 수 없어 -입니다 앞뒤가 맞지 문제 해결이 불가능 입증되었습니다.

편집 1 : 이 답변의 이전 버전에서 Atari 2600은 프로세서가 TV 신호의 위치를 ​​프로세서에 알리는 방법이 없다고 말하면서 전체 프로그램을 계산하고 처음부터 동기화하도록 강요했습니다. 의견에서 나에게 지적한 것처럼 이것은 ZX 스펙트럼과 같은 일부 시스템에서는 사실이지만 Atari 2600에서는 그렇지 않습니다. 다음 수평 블랭킹 간격이 발생할 때까지 CPU를 정지시키는 하드웨어 레지스터와 수직 블랭킹 간격을 마음대로 시작하는 기능. 따라서 카운팅주기 문제는 각 스캔 라인으로 제한되며, 개발자가 스캔 라인을 그릴 때 내용을 변경하려는 경우에만 정확합니다.

여기에는 두 가지 측면이 있습니다.

@ gnasher729가 지적했듯이 실행해야 할 정확한 명령을 알고 있으면 캐싱, 분기 예측, 스케일링 등으로 인해 정확한 런타임을 추정하기가 여전히 어렵습니다.

그러나 상황은 더욱 악화됩니다. 어셈블리 덩어리가 주어지면 어떤 명령이 실행 될지 알 수 없으며 심지어 얼마나 많은 명령이 실행 될지 알 수 없습니다. 이것은 쌀의 정리 때문입니다. 만약 우리가 정확하게 결정할 수 있다면, 그 정보를 사용하여 정지 문제를 해결할 수 있습니다. 그것은 불가능합니다.

어셈블리 코드는 점프와 분기를 포함 할 수 있으며 프로그램의 전체 추적을 무한대로 만들 수 있습니다. 비용 의미론 또는 주석이 달린 유형 시스템과 같은 것들을 통해 실행에 대한 상한선을 제공 하는 보수적 인 실행 시간 근사치에 대한 연구가있었습니다. 나는 구체적으로 어셈블리에 대해 익숙하지 않지만 그런 것이 존재하더라도 놀라지 않을 것입니다.

"컴퓨터 시스템"선택에 마이크로 컨트롤러가 포함됩니까? 일부 마이크로 컨트롤러는 매우 예측 가능한 실행 시간을 가지고 있습니다. 예를 들어 8 비트 PIC 시리즈는 명령이 다른 주소로 분기되거나 플래시에서 읽거나 특수한 2 워드 명령이 아닌 한 명령 당 4 개의 클록주기를 갖습니다.

인터럽트는 이러한 종류의 timimg를 분명히 방해하지만 "베어 메탈"구성에서 인터럽트 처리기없이 많은 작업을 수행 할 수 있습니다.

어셈블리와 특수 코딩 스타일을 사용하면 항상 같은 시간이 걸리는 코드를 작성할 수 있습니다. 대부분의 PIC 변형에 여러 개의 타이머가있는 것은 흔하지 않지만 가능합니다.

8 비트 컴퓨터 시대로 돌아가서 일부 게임은 그와 같은 일을했습니다. 프로그래머는 비디오 및 오디오 하드웨어의 정확한 타이밍과 동기화하기 위해 소요 된 시간과 CPU의 알려진 클럭 속도에 따라 명령을 실행하는 데 걸리는 정확한 시간을 사용합니다. 당시에는 디스플레이가 각 라인의 화면을 일정한 속도로 순환하고 음극선을 켜고 꺼서 형광체를 활성화 또는 비활성화하여 해당 행의 픽셀을 페인트하는 음극선 관 모니터였습니다. 프로그래머는 빔이 스크린의 해당 부분에 도달하기 직전에 비디오 하드웨어에 표시 할 내용을 알려주고 남은 시간에 나머지 코드를 맞추기 위해“빔 레이싱”이라고 불렀습니다.

그것은 현대 컴퓨터 나 예제와 같은 코드에서는 절대로 작동하지 않을 것입니다.

왜 안돼? 간단하고 예측 가능한 타이밍을 망칠 몇 가지 사항은 다음과 같습니다.

CPU 속도와 메모리 가져 오기는 모두 실행 시간에 병목 현상이 발생합니다. 실행 명령을 가져 오거나 CPU가 수용 할 수있는 것보다 더 빠르게 바이트를 전달할 수있는 메모리를 설치하는 것보다 CPU를 더 빨리 실행하는 것은 비용 낭비입니다. 이 때문에 오래된 컴퓨터는 모두 같은 시계에서 실행되었습니다. 최신 CPU는 기본 메모리보다 훨씬 빠르게 실행됩니다. 그들은 명령 및 데이터 캐시를 통해이를 관리합니다. 캐시에없는 바이트를 기다려야하는 경우에도 CPU는 여전히 정지합니다. 따라서 동일한 명령이 캐시에없는 경우보다 명령이 훨씬 더 빠르게 실행됩니다.

또한 최신 CPU에는 파이프 라인이 길다. 그들은 칩의 다른 부분이 파이프 라인의 다음 몇 가지 명령에 대해 예비 작업을하도록하여 높은 처리량을 유지합니다. CPU가 다음 명령어가 무엇인지 모르는 경우 실패합니다. 분기가 있으면 발생할 수 있습니다. 따라서 CPU는 조건부 점프를 예측하려고합니다. (이 코드 스 니펫에는 없지만 파이프 라인을 막은 조건부 점프가 잘못되었을 수 있습니다. 게다가 전설적인 답변을 연결하는 좋은 변명도 있습니다.) int 80실제로 커널 모드로 트랩 하도록 호출하는 시스템 복잡한 CPU 기능인 인터럽트 게이트를 사용하여 예측할 수없는 지연이 발생합니다.

OS가 선점 형 멀티 태스킹을 사용하는 경우이 코드를 실행하는 스레드는 언제든지 타임 슬라이스를 잃을 수 있습니다.

프로그램이 베어 메탈에서 실행되고 하드웨어에서 직접 작동하기 때문에 빔을 경주하는 것 또한 효과가있었습니다. int 80시스템 호출 을 위해 전화 를 거는 중입니다. 이는 운영 체제로 제어권을 넘겨 주므로 타이밍을 보장 할 수 없습니다. 그런 다음 임의의 스트림에서 I / O를 수행하면 모든 장치로 리디렉션 될 수 있습니다. I / O에 걸리는 시간을 말하기에는 너무 추상적이지만 명령을 실행하는 데 걸린 시간을 확실히 지배 할 것입니다.

최신 시스템에서 정확한 타이밍을 원하면 지연 루프를 도입해야합니다. 더 빠른 반복을 가장 느린 속도로 실행해야하며 그 반대는 불가능합니다. 사람들이 현실에서 그렇게하는 한 가지 이유는 요청이 다른 것보다 시간이 오래 걸리는 공격자에게 암호화 정보가 유출되는 것을 방지하기위한 것입니다.

이것은 다소 접선이지만, 우주 왕복선에는 정확히 동기화, 즉 런타임 일치와 정확히 일치하는 4 대의 중복 컴퓨터가 있습니다.

BFS (Backup Flight Software) 컴퓨터가 4 개의 1 차 Avionics 소프트웨어 시스템 (PASS) 컴퓨터와의 동기화를 거부했을 때 최초 우주 왕복선 발사 시도가 제거되었습니다. "The Bug Heard Round the World"에 대한 자세한 내용은 여기를 참조하십시오 . 사이클주기에 맞게 소프트웨어를 개발 한 방법에 대한 흥미로운 내용을 읽고 흥미로운 배경 지식을 얻을 수 있습니다.

우리는 여기서 두 가지 다른 문제를 혼합하고 있다고 생각합니다. (그렇습니다, 나는 이것이 다른 사람들에 의해 언급되었다는 것을 알고 있지만 더 명확하게 표현할 수 있기를 바랍니다.)

먼저 소스 코드에서 실제로 실행되는 명령어 시퀀스 (입력 데이터와 코드에 대한 지식이 필요함-루프를 몇 번 반복해야합니까?) 테스트 후 분기를 가져와야합니다. ). 정지 문제로 인해 명령어 순서가 무한 할 수 있으며 (종료되지 않음) 입력 데이터에 대한 지식이 있어도이를 정적으로 결정할 수는 없습니다.

실행할 명령 순서를 설정 한 후 실행 시간을 결정하려고합니다. 그것은 시스템 아키텍처에 대한 지식으로 확실히 추정 할 수 있습니다. 그러나 문제는 많은 최신 머신에서 실행 시간이 메모리 페치 캐싱에 크게 의존한다는 것입니다. 즉, 실행 된 명령과 마찬가지로 입력 데이터에 많이 의존합니다. 또한 조건부 분기 대상의 올바른 추측에 달려 있으며 이는 다시 데이터에 의존합니다. 따라서 추정치 일뿐 정확한 것은 아닙니다.