Computer_Architecture_Week_4

명령어 집합

• 파이썬이나 C언어는 사람이 이해할 수 있는 high level의 language. 하드웨어가 움직이려면 컴퓨터(CPU)가 이해할 수 있는 명령어들이 필요함.

명령어 집합 구조(ISA, instruction set architecture)

• 좁은 의미에서 컴퓨터구조 == 명령어집합구조(ISA)
• 어떤 프로그램과 그 프로그램을 수행할 컴퓨터 하드웨어 사이의 인터페이스에 대한 완전한 정의 혹은 명세
  -> 명령어는 CPU 등 컴퓨터 하드웨어에서 인식되거나 실행될 수 있는 기계 명령어(8bit =1byte)
• 명령어 집합 구조는 "특정 CPU를 위해 정의된 명령어들의 모음"
• assembly 코드는 machine 코드를 연산기호로 만든 것.(컴퓨터 HW가 이해할 수 있는 기계어를 사람이 기억하고 사용할 수 있도록)
• 명령어 집합 구조는 "특정 CPU를 위해 정의된 명령어들의 모음". 각 회사마다 자기네 CPU에 맞는 명령어가 있음.
• microarchitecture: 실제 구현까지 포함한 것.
• C언어는 applcation level에서 사용. C언어에서 함수를 사용하게 되면 complier(assembler)를 통해 ISA로 바뀌게 됨. 그러면 그 때 CPU가 하나씩 하나씩 수행함.

C 프로그램의 변환과정

• C program -> Asm program -> Object program -> Executable program
• Assmebly 는 훨씬 간단하기 때문에 코드의 줄은 더 긺.

ADT(Abstract data type)

• data value들의 집합이 측정 Object를 가리키는 state가 됨.
• 정확히는 잘 모르겠음

명령어의 특성: 형태를 결정하는 요인

• [비유] CPU라는 기계는 주메모리에서 작업지시서(명령어)를 받아와서 그 지시서를 실행한다.
  -> 다양한 종류의 명령어들을 "기계"는 어떻게 인식할 수 있을까?
  -> 일단, 형태적 요소를 갖고 1차원적 분류를 해보자.
• 따라서, 명령어 특성에 맞는 형태(서식) 정의가 먼저 필요
  -> 명령어의 형태에 영향을 미치는 요인들 고려

명령어의 특성: 피연산자 수

• (산술연산 기반의) 명령어 기본 형식
  -> z = f(x,y)
  -> f: 명령어, x,y,z: 피연산자(operand)로서, 데이터 위치(레지스터/메모리 주소)나 값 자체를 포함하여, 주소 필드라고도 부름

피연산자 수에 따른 명령어 종류

• 피 연산자가 없는 경우
  -> halt: 프로그램 정지
  -> add: 피연산자가 있어야 할 것 같지만, 하드웨어적으로 stack based machine으로 구축되어 있는 경우가 많아서, 피연산자가 있다고 가정하고, stack에서 맨 위에 있는거 2개를 꺼내와서 다시 stack에 집어 넣는다. 장점: 명령어가 짧음
• 단항 피연산자
  -> not r1: boolean 느낌임
  -> add r1: Accumulate=> r1 + Acc 값을 다시 Acc에 저장
• 이항 피연산자
  -> add r1, r2 : r1 <- r1 + r2
• 삼항 피연산자(가장 많이 쓰임)
  -> add r1, r2, r3: r1 <- r2 + r3
• 다항 피연산자
  -> madd r1, r2, r3, r4: multiadd로 수행 명령어 수는 감소되지만, 명령어 종류의 수는 증가한다.

명령어의 특성: 명령어 길이

• 고정길이 명령어: 명령어의 종류나 명령어에 포함된 구성요소에 관계없이 명령어의 길이가 모두 일정
  -> 장점: 명령어 해독의 용이성 등으로 프로세서 하드웨어 디자인이 쉬워짐.
  -> 단점: 짧은 길이의 명령어도 긴 명령어와 동일한 길이여서, 프로그램의 크기 증가. add도 madd처럼 길이가 긴 명령어 취급을 받기 때문에, garbage 메모리를 낭비한다.

• 가변길이 명령어: 명령어의 종류나 명령어에 포함된 구선요소에 따라 다양한 길이의 명령어 사용
  -> 장점: 명령어의 길이 최적화로 프로그램의 크기가 감소, 컴퓨터/연산 특성을 사용하는 명령어 사용 가능
  -> 단점: 프로세서 하드웨어 디자인이 어려움. CPU가 힘듦. 어떤 놈은 길고, 어떤 놈은 짧기 때문에 CPU입장에서는 골때림

• [비유] 동일한 택배상자들 vs 내용물에 딱 맞는 크기의 택배상자들
  -> 공간 측면에서 동일한 택배상자가 비효율적이지만, 모양이 일정하기 때문에

명령어의 특성: 각 필드 길이

• 연산 코드 필드 길이: 연산의 개수를 결정
  -> 필드가 길면, 여러가지 연산을 할 수 있으니 좋긴 하다. 4bit -> 2^4가지의 연산 정의 가능하다.
  -> 만약 연산코드 필드를 4bit에서 5bit으로 늘리면 32개의 연산 정의가 가능하나, 다른 필드의 길이가 감소한다.

• 오퍼랜드 필드 길이: 오퍼랜드의 범위 결정
  -> 오퍼랜드의 종류에 따라 범위가 달라짐
  -> 데이터: 표현 가능한 수의 범위 결정
  -> 기억장치 주소: 메모리 entry 개수 결정
  -> 레지스터 번호: 레지스터의 개수 결정
  -> 위 3개를 따질 수 있어야함. 그래야 가장 최적화를 잘 할 수 있음.

• [예] 연산부호bit는 8 bit(1B), 메모리주소 bit는 16 bit(2B), 데이터 bit는 32bit(4B)라면?
  -> 정의 가능한 연산 갯수는?
  -> 표현 가능한 수의 갯수는?
  -> 명령어 길이는?
  -> 메모리 용량은?

명령어 집합 설계시 고려사항

• 하드웨어 기술이나 컴퓨터 구성, 프로그래밍 언어, 컴파일러 기술, 플랫폼이 될 운영체제 등을 다 고려해야 함.
• 명령어 형식(연산코드, 연산종류에 따른 피연산자 수와 길이, 종류 등)
• 연산의 종류(전송, 처리, 제어, 입출력 연상 등)
• 피연산자 형식(피연산자 데이터에 대한 정보, 데이터들의 형태, 데이터 값을 저장하는 방식 등)
• 피연산자를 위한 주소지정방식(피연산자가 레지스터, 메모리 등 다양한 위치에 있을 수 있으므로, 주소 정보를 나타내는 방식에 대한 정보 명시 필요)