KR20130132674A

KR20130132674A - 명령어의 추상화를 이용한 명령어 집합 아키텍처 자동 맵핑 기법

Info

Publication number: KR20130132674A
Application number: KR1020120055078A
Authority: KR
Inventors: 김현수
Original assignee: 김현수
Priority date: 2012-05-23
Filing date: 2012-05-23
Publication date: 2013-12-05
Also published as: KR101940265B1

Abstract

바이너리 변환은 특정 장치에서 동작할 수 있도록 구성된 프로그램을 다른 장치에서 동작할 수 있도록 변환하는 과정을 의미한다. 그러나 바이너리 변환은 원본 장치와 타겟 장치에 대한 높은 의존성을 가지고 있어, 새로운 장치에 적용하기 위해서는 새로운 바이너리 변환을 수행하여야 하는 문제가 있다. 이러한 문제를 해결하기 위한 방법으로 컴파일러에서 사용하고 있는 중간 코드를 응용하여 이 문제를 해결하고 있다. 그러나 이런 방법은 추가적인 변환 과정을 거처야 하기 때문에 기존의 직접 변환 방법보다 많은 시간과 자원을 소모하게 된다. 임베디드 환경이나 실시간 환경에서 이를 적용하고자 할 때는 문제가 될 수 있다. 따라서 본 발명에서는 기존의 바이너리 변환처럼 직접적인 변환을 수행하되, 장치에 대한 의존성을 줄이기 위하여 명령어에 대한 추상화 모델을 제시하고, 추상화 모델로 표현된 명령어를 기반으로 변환 규칙을 자동으로 생성하는 방법을 제안한다.

Description

명령어의 추상화를 이용한 명령어 집합 아키텍처 자동 맵핑 기법 {Automatic Mapping Method between Instruction Set Architectures using Abstraction of Instructions}

특정장치에서 동작할 수 있도록 구성된 프로그램을 다른 장치에서 동작할 수 있도록 변환하는 바이너리 변환 기술에 관한 것이다.

.

바이너리 변환은 원본 장치와 타겟 장치에 대한 높은 의존성으로 인해 새로운 장치에 적용하기 위해서는 매번 새로운 바이너리 변환을 수행해야 한다. 이런 문제점을 해결하기 위한 방법으로 제시된 방법은 중간 코드를 이용하여 원본 코드를 중간 코드로 변환하고 중간 코드를 다시 타겟 코드로 변환하는 방법을 사용한다. 그렇지만 이 방법은 추가적인 변환 과정을 거쳐야 하기 때문에 기존의 직접 변환 방법보다 많은 시간과 자원을 소모하게 된다. 따라서 이런 문제를 모두 해결할 수 있는 방법이 필요하다.

본 특허에서는 바이너리 변환에서 발생할 수 있는 문제를 해결하기 위해 다음과 같은 방법을 사용한다.

1. 실시간/임베디드 환경에서 사용할 수 있도록 중간 표현을 사용하는 방법보다는 직접적인 변환을 수행한다.

2. 직접적인 변환을 수행함에 있어 문제가 되었던 장치에 대한 의존성을 해결하기 위해서 추상화 모델을 기반으로 변환 규칙을 자동으로 구성할 수 있도록 한다.

이를 위하여 명령어를 동일한 형태로 표현할 수 있는 추상화 모델을 정의하고, 정의된 추상화 모델을 이용하여 명령어 사이의 존재하는 변환 규칙을 자동으로 도출하는 방법을 제시한다.

.

도 1은 기능 블록
도 2는 기술 언어에서 사용되는 키워드
도 3은 기술 언어에서 사용하는 자료 유형
도 4는 SPARC v7 명세서 중 ADD 명령어의 일예
도 5는 기술 언어를 이용한 바이너리 포맷 기술
도 6은 기술 언어를 이용한 명령어 기술의 일예
도 7은 명령어 집합 아키텍처 간의 맵핑 방법의 구성도
도 8은 SPARC v7 ADD 명령어의 동작 트리의 일예

1. 명령어 추상화 모델

바이너리 변환의 목적은 기존에 존재하던 바이너리 코드를 다른 장치에서 동작시키기 위한 것이다. 따라서 바이너리 변환에서 가장 중요한 것은 변환되기 전의 바이너리 코드와 변환된 바이너리 코드의 동작이 동일하여야 한다는 것이다. 이러한 속성을 행위 보존(behavior preserving)이라 한다. 바이너리 코드는 기본적으로 명령어를 순차적으로 나열한 것으로, 바이너리 코드의 기본 단위를 명령어라고 정의할 수 있다. 여기서 명령어란 프로세서에 장착된 FPU와 ALU를 통해서 수행할 수 있는 단위 기능이 명시된 기계어이다. 따라서 바이너리 코드의 동작은 각 명령어의 단위 기능이 연동되는 것이라고 볼 수 있다. 그러므로 바이너리 코드를 구성하는 명령어에 대해서 동일한 단위 기능을 수행할 수 있는 또 다른 명령어로 변환할 수 있다면 바이너리 코드의 행위 보존을 만족시킬 수 있을 것이다. 다시 말하면, 원본 장치의 명령어와 동일한 단위 기능을 수행하는 타겟 장치의 명령어를 찾아냄으로써 바이너리 코드의 행위 보존을 만족시킬 수 있는 것이다.

이것이 가능하기 위해서는 원본 장치와 타겟 장치가 가지고 있는 명령어들을 서로 비교할 수 있어야 한다. 그러나 장치마다 명령어의 구성이 다르기 때문에, 일정한 기준을 가지고 비교하는 것이 불가능하다. 명령어 간의 비교가 가능하기 위해서는 모든 명령어를 동일한 형태로 표현할 수 있어야 한다. 따라서 명령어에 대한 추상화 모델을 정의한다.

1.1 기능 블록 : 명령어 추상화 모델

앞서 설명한 것과 같이 명령어는 프로세서에서 수행할 수 있는 단위 기능이 명시된 기계어이다. 각 명령어는 자신이 수행하여야 하는 기능과 함께 기능을 수행함에 있어서 필요로 하는 값을 부여받는다.

명령어는 자신에게 부여된 기능과 값을 통해서 식별될 수 있다. 예를 들어, SPARC 계열의 프로세서 중 ERC32는 덧셈 연산을 수행하는 다양한 명령어를 가지고 있다. 그 중에서 ADD 명령어는 두 개의 32 비트 정수 값을 더하여 32 비트 정수 값을 도출하는 기능을 수행한다. 또한 FADDs 명령어는 두 개의 32 비트 실수 값을 더하여 32 비트 실수 값을 도출하는 기능을 수행한다. ADD와 FADDs는 둘 다 덧셈이라는 기능을 수행하고 있으나, 서로 다루는 값이 정수와 실수라는 차이를 가지고 있다. 따라서 명령어는 자신이 수행하여야 하는 기능과 기능을 수행하는 과정에서 다루는 값의 유형을 통하여 식별된다고 볼 수 있다.

이처럼 명령어는 자신만의 고유한 단위 기능을 수행하고 있음을 알 수 있다. 마치 단일 함수처럼 항상 동일한 유형의 값을 입력받아 동일한 유형의 값을 출력으로 내놓는 방식으로 동작하고 있다. 이와 같은 명령어의 특성을 통해서 다음과 같은 형태의 추상화 모델을 정의한다.

[도 1]과 같은 명령어의 추상화 모델을 “기능 블록”이라고 한다. 기능 블록은 입력과 출력, 그리고 동작 기능으로 구성된다. 입력은 명령어의 입력 값의 자료 유형을 의미하며, 출력은 명령어의 출력 값의 자료 유형을 의미한다. 동작 기능은 명령어가 기능을 수행하는 과정을 의미한다.

1.2 기능 블록을 기술하기 위한 언어 정의

명령어를 기능 블록으로 표현하기 위해서는 명령어의 기능과 다루는 값의 자료 유형을 알 수 있어야 한다. 이러한 정보는 명령어 집합 아키텍처의 명세서에 기술되어 있다. 그러나 각 장치마다 기술되어 있는 방법이 다르며, 더군다나 이는 개발자를 위해 제공되는 것이기 때문에 컴퓨터가 분석하기가 불가능하다. 따라서 명령어를 기능 블록으로 표현하기 위해 필요로 하는 정보를 기술할 수 있는 방법이 필요하다.

먼저, 기존에 정의된 언어 중에서 기능 블록을 기술하기에 적합한 언어가 있는지 확인하였다[4,5,6]. 기존의 바이너리 변환과 관련된 연구에서도 명령어 집합 아키텍처 혹은 프로세서 자체를 기술하기 위한 언어를 정의하거나 사용하였다. 그러나 기존의 기술 언어들을 이용하면 명령어의 기능 혹은 동작 방식에 대해서는 기술할 수 있으나, 명령어가 기능을 수행하는 과정에서 다루는 자료 유형에 대한 정보는 기술할 수 없다. 따라서 기능 블록을 기술하기 위한 언어를 정의한다.

기능 블록을 기술하기 위한 언어를 정의하기에 앞서서 해당 기술 언어가 표현하여야 하는 정보를 나열한다. 기술 언어를 정의하는 목적이 기존에 존재하는 기술 언어에서 필요로 하는 정보를 표현할 수 없기 때문이며, 기술 언어가 표현하여야 하는 정보 자체가 기술 언어를 정의함에 있어서 기준으로 사용될 수 있기 때문이다. 기능 블록을 기술하기 위한 언어는 다음과 같은 정보를 표현할 수 있어야 한다.

- 명령어가 가지는 바이너리 포맷

- 명령어의 식별자

- 명령어가 수행하는 기능 혹은 동작 방식

- 명령어가 기능을 수행하는 과정에서 다루는 자료 유형

명령어의 바이너리 포맷과 식별자에 대한 정보는 원본 장치의 바이너리 코드를 분석하여 어떤 명령어로 구성되어 있는지 파악하기 위하여 사용된다. 즉, 바이너리 코드의 디코딩을 위하여 사용된다. 명령어의 기능과 다루는 자료 유형에 대한 정보는 앞서 설명한 것처럼 명령어로부터 기능 블록을 도출하기 위하여 사용된다.

기술 언어에서 표현하여야 하는 정보를 바탕으로 기술 언어에서 사용될 키워드와 자료 유형을 [도 2],[도 3]과 같이 정의하였다.

[도 2]는 기술 언어에서 사용될 키워드를 정리한 것이며, [도 3]은 기술 언어 내에서의 자료 유형을 정리한 것이다. “@format" 키워드는 명령어의 바이너리 포맷을 정의하기 위하여 사용되며, "@instruction" 키워드는 명령어의 기능과 명령어가 다루는 자료 유형을 정의하기 위하여 사용된다. "@type"과 "@identifier" 키워드는 하나의 명령어가 다양한 바이너리 포맷을 사용할 수 있기 때문에, 이러한 상황을 고려하여 정의한 키워드이다. 마지막으로 ”@behavior“ 키워드는 명령어의 기능을 정의하기 위하여 사용한다. 명령어 내에서 사용되는 자료 유형을 정수 레지스터, 실수 레지스터, 상수, 메모리로 정의하였다. 또한 메모리를 제외한 나머지 자료 유형은 상황에 따라서 그 크기가 유동적이기 때문에 [도 3]에 보이는 것처럼 자료의 크기를 입력할 수 있도록 하였다.

다음은 실제로 정의된 기술 언어를 이용하여 명령어를 기술하는 방법에 대한 예이다. [도 4]의 명령어는 SPARC v7의 명세서 중 ADD 명령어에 대한 부분이다. ADD 명령어는 두 개의 바이너리 포맷을 가지고 있으며, 정수 레지스터인 rs1과 rs2의 값을 더하여 정수 레지스터인 rd에 저장하는 기능을 수행한다.

먼저 표기된 바이너리 포맷에 대해서 [도 5]와 같이 기술할 수 있으며, 기술된 바이너리 포맷을 이용하여 ADD 명령어에 대해서 [도 6]과 같이 기술할 수 있다. [도 4]의 ADD 명령어를 보면 바이너리 포맷을 두 가지를 가지고 있기 때문에 @type 키워드를 이용하여 두 가지의 바이너리 포맷에 대해서 모두 표현한 것을 볼 수 있다.

2. 명령어 집합 아키텍처 간의 맵핑 전략

이번 절에서는 정의된 기능 블록을 통해서 두 장치의 명령어 집합 아키텍처를 자동으로 맵핑할 수 있는 방법에 대해서 제시한다. 제시하는 기본적인 맵핑 전략은 [도 7]과 같다. 이와 방법을 통하여 두 장치의 명령어 간의 변환 규칙을 도출할 수 있다. 이 때, 명령어 간의 변환 규칙을 도출하는 것을 명령어 맵핑이라고 하며, 각 장치가 갖는 모든 명령어들에 대해서 변환 규칙을 도출하는 것을 명령어 집합 아키텍처 맵핑이라고 한다.

명령어 집합 아키텍처 맵핑을 수행하기 위해서는 세 단계를 거쳐야 한다. 첫 번째 단계는 명령어 기술 단계로, 2.2절에서 설명한 기술 언어를 통하여 명령어 집합 아키텍처 내부의 명령어들을 기술하는 작업을 수행한다. 이는 수동으로 진행된다.

두 번째 단계는 기능 블록 도출 단계이다. 기술 언어를 통해 기술된 명령어를 통해서 기능 블록을 도출하며, @bahavior 키워드 내부에 기술된 표현식을 통하여 태그와 기능 트리 정보를 추출하게 된다. 태그와 기능 트리는 기능 블록 간의 비교를 위하여 사용되는 것으로, 자세한 내용은 뒤에 다룬다. 마지막 단계는 변환 규칙 생성 단계이다. 태그와 기능 트리를 이용하여 기능 블록 간의 비교를 수행하며, 태그와 기능 트리가 모두 일치하였을 경우에 두 기능 블록 간의 맵핑 관계가 발생하며, 그 자체가 하나의 변환 규칙으로 사용된다. 이렇게 원본 장치의 모든 기능 블록에 대한 변환 규칙을 생성한 이후에는 명령어에 대한 변환 규칙을 생성한다. 기능 블록과 명령어는 기술 문서를 통하여 맵핑 관계가 기술되어 있으므로, 이를 통해서 기능 블록과 관계있는 명령어로 변환함으로써 명령어에 대한 변환 규칙을 생성할 수 있다. 기능 블록 도출 단계와 변환 규칙 생성 단계는 자동으로 이루어진다.

위와 같은 명령어 맵핑이 이루어지기 위해서는 기본적으로 기능 블록의 비교가 가능하여야 한다. 기능 블록의 비교는 해당 기능 블록이 수행하는 기능과 다루는 자료 유형을 기준으로 수행된다. 기능 블록이 다루는 자료 유형의 경우에는 단순한 비교만으로도 수행할 수 있으나, 기능 블록이 수행하는 기능의 경우에는 그 형태가 비교하기 애매하기 때문에 단순한 비교를 통해서 수행하기 어렵다. 기능 블록의 비교를 수행하기 위하여 태그와 동작 트리를 비교 기준으로 제안한다.

2.1 태그

태그는 일반적으로 특정 객체를 보충 설명할 수 있는 단어를 의미한다. 태그는 굳이 객체에 대해서 전부를 살펴보지 않아도 간략하게 객체를 이해할 수 있도록 도와주며, 경우에 따라서 객체에 대한 색인으로 사용될 수도 있다. 이러한 태그의 특성을 활용하여 기능 블록의 비교를 수행할 때, 태그를 색인으로써 사용하고자 한다. 태그를 사용함으로써 가질 수 있는 장점으로는 비교 대상을 줄일 수 있다는 점이다. 기능 블록의 비교를 수행함에 있어서 원본 장치의 기능 블록에 대해서 타겟 장치의 모든 기능 블록과 비교하여야 하는 상황이 발생된다. 그러나 예를 들어 덧셈 연산을 수행하는 기능 블록과 분기 연산을 수행하는 기능 블록과의 비교는 전혀 무의미할 수 있다. 따라서 이러한 불필요한 비교를 피하기 위하여 태그를 사용한다. 기능 블록의 태그는 입력 값의 자료 유형, 출력 값의 자료 유형, 수행되는 기능으로 세 가지의 정보로 이루어진다.

2.2 동작 트리

동작 트리란 기능 블록이 수행하는 기능에 대한 추상 구문 트리(AST)를 말한다. [도 6]에 기술된 ADD 명령어를 보면 @behavior 내부에 ADD 명령어가 수행하는 기능에 대해서 기술되어 있는 것을 볼 수 있다. 이를 보면 알 수 있듯이 명령어에 대한 기능은 C 언어에서 사용하는 표현식으로 형태를 가지고 있다. 따라서 표현식을 비교하기 위해서는 일반적인 방법으로는 수행할 수 없기 때문에, 표현식을 추상 구문 트리로 표현하고 도출된 트리를 비교함으로써 기능을 비교할 수 있도록 한다. [도 6]의 ADD 명령어의 동작 트리는 [도 8]과 같이 표현할 수 있다.

.

Claims

.