KR101292476B1 - 동적 확장가능 프로세서들에 대한 소프트웨어 지원을 위한컴퓨터 운영 체제, 재작성기 도구, 및 애플리케이션 효율성개선 방법 - Google Patents

Abstract

포스트-컴파일(a post-compilation) 도구가 컴파일러에 의해 생성된 실행가능 파일 이미지들을 다시쓸 수 있다. 이 도구는 확장자 정의를 추가하고, 확장자-트리거 명령어들을 삽입하고, 보안 서명을 추가할 수 있다. 운영 체제 소프트웨어는 실행가능 파일 이미지를 로딩할 때에 확장 기능을 통보받을 수 있어서, 적합한 프로세서 확장자를 로드하도록 진행할 수 있다. 운영 체제 소프트웨어는 애플리케이션 대신하여 프로세서 확장자의 이용가능성을 관리할 수 있다.

재작성기 도구(rewriter tool), 실행가능 파일 이미지, 확장자 정의, 확장자-트리거 명령어, 보안 서명

Description

동적 확장가능 프로세서들에 대한 소프트웨어 지원을 위한 컴퓨터 운영 체제, 재작성기 도구, 및 애플리케이션 효율성 개선 방법{SOFTWARE SUPPORT FOR DYNAMICALLY EXTENSIBLE PROCESSORS}

CPU 설계자들이 보편성을 위해 분투하는 반면에, 지금껏 제작된 모든 애플리케이션 프로그램은 그것의 대부분의 시간을 자신의 실행가능 파일 이미지를 포함하는 코드의 매우 작은 일부분에 할애한다. 이는 퍼스널 컴퓨터 사용을 위한 일반적인 프로그램들, 내장형 컴퓨터를 위한 프로그램들, 및 심지어는 미국 워싱톤 레드몬드의 MICROSOFT?사의 XBOX?와 같은 게임용 플랫폼에도 적용된다. 실행가능 파일 이미지 내의 최상위 두 개 또는 세 개의 기초 블록들이 일반적으로 총 실행 카운트의 80％를 훨씬 넘게 차지한다고 분석된다.

프로그램의 보다 효과적인 실행을 위한 매력적인 전망은 범용 소프트웨어 명령어들의 원래 시퀀스와 의미는 동일하지만 보다 효과적인 구현을 갖는 특화된 프로세서 명령어들에 의해 최상위의-실행 기초 블록들을 최적화하는 것이다. 문헌에 보고된 스피드-업은 두 배에서 여섯 배까지, 그리고 몇몇 경우에는 심지어는 수십 배 이상까지 큰 범위를 갖는다. 우리의 경험으로는 기대되는 스피드-업의 어림치로서 세 배를 고려한다.

당대 프로세서의 CPU는 문서화(well-documented)되어 있는, 프로세서 명령어 들의 고정된 집합을 구현한다. 프로세서 명령어들은, 가능한 가장 컴팩트한 형태로, 애플리케이션 요건의 가장 큰 가능한 집합을 캡처하도록 선택된다. CPU는 통상적으로, 칩이 일단 제작되면 임의의 새로운 프로세서 명령어를 추가하는 것은 불가능한 방식의 고정된 논리로 실현된다. 한편, FPGA(Field-Programmable Gate Arrays)는, 칩이 필드에 배치된 후에라도, 추후의 확장 및 변경을 허용하는 CPU를 구현하기 위한 대안적인 방법이다.

CPU의 내부 컴포넌트들을 서로 연결하기 위해서는 동적으로 변화가능한 방식으로, 고정된 논리를 이용해 CPU를 구현하는 것이 또한 가능하다. 이 접근법은 우리가 "동적 확장가능 프로세서( dynamically extensible processors )"라고 부르는 새로운 타입의 프로세서들을 만들어 낼 수 있다. 이들 프로세서들은 고정된 논리의 장점(줄어든 크기, 높아진 클록률)에 기본 프로세서 명령어 집합에 프로세서 확장자를 추가할 수 있는 기능을 결합시킨다.

확장가능 프로세서의 실용적인 사용은 애플리케이션 프로그램 내의 확장된 명령어를 이상적으로 사용할 것이다. 일반적으로, 프로그래머는 애플리케이션 프로그램을 작성하기(write) 위해 어셈블러 또는 보다 고급 언어 컴파일러를 사용한다. 이런 방침(path)은 각각의 새로운 프로세서 명령어마다 새로운 어셈블러 및 새로운 컴파일러를 다시 생성시킬(re-generating) 것을 요구할 수 있다. 확실하게 가능한 반면에, 이는 대신에 시간-소모적인 동작이다. 이는 또한 제한 및 위험이 따른다. 프로그램이 사실상 어셈블러로 작성된(written) 경우에는, 다시 작성해야만 한다. 새로운 명령어들에 의해 컴파일러가 변경되면, 고급 언어 프로그램들만 이 새로운 명령어들을 자동으로 이용할 수 있다. 또한, 컴파일러를 위한 소스를 갖지 않은 경우에는, 컴파일러는 변경하지 못할 수 있다. 컴파일러들은 크고 복잡한 프로그램들이므로, 미묘한 오류(subtle errors)가 도입될 가능성은 매우 크다. 마지막으로, 우리는 애플리케이션 프로그램에 대한, 또는 일부 중요한 라이브러리를 위한 소스를 갖지 않을 수 있어, 사용하기 어렵게 한다.

현존하는 도구들 및 운영 체제들은 고정된 프로세서 명령어 집합을 위해 설계되어서 동적 확장가능 프로세서의 필요에 대처할 수 없다. 예를 들면, 미국 캘리포니아주 산타 클라라의 TENSILICA?사에 의해 제작된 XTENSA? 프로세서 계열은 표준 도구모음(toolset)에 의해 다음과 같은 방식으로 지원된다 - 시스템 설계자들이 특수 도구들을 사용하여 제조자들이 제공한 기본 프로세서 설계에서 시작하여 새로운 프로세서를 위한 하나 이상의 프로세서 명령어들을 정의함 - . 이 도구의 주된 목적은 새로운 확장된 프로세서를 위한 베릴로그(Verilog) 코드를 생성하도록 돕는 것이다. 도구는 새로운 프로세서 명령어의 수동적 정의에 기초하여 새로운 컴파일러 및 링커(linker)를 자동적으로 생성한다. 이 절차는 정적( static )이어서, 애플리케이션 프로그램이 컴파일되어 그것에 대해 최적화될 수 있기 전에 새로운 칩뿐만 아니라 새로운 도구모음의 생성을 요구한다는 것에 유념해야 한다.

아래의 참조문헌은 미국 특허청에 그 사본이 제출되어 있는데, 사용자 지정된 확장가능 프로세서들의 설계에 추가적인 배경을 제공한다: Clark, Blome, Chu, Mahlke, Biles, and Flautner의, "An Architecture Framework for Transparent Instruction Set Customization in Embedded Processors ." 참고 문헌 섹션은 본원 에 설명된 작업에 또한 일반적으로 관련된 동일한 및 다른 저자들의 각종 기타 논문들을 제시한다.

본 발명은 동적 확장가능 프로세서들의 소프트웨어 지원을 위한 시스템 및 방법들을 제공한다. 도구는 컴파일러에 의해 제작된 실행가능 파일 이미지를 재작성할(rewrite) 수 있다. 도구는 확장자 정의를 추가하고, 확장자-트리거 명령어들을 삽입하고, 보안 서명을 추가할 수 있다. 운영 체제 소프트웨어는 실행가능 파일 이미지를 로딩할 때에 확장자 기능(capability)을 통보받을 수 있어서, 적합한 프로세서 확장자를 로드하도록 진행할 수 있다. 운영 체제 소프트웨어는 애플리케이션을 대신하여 프로세서 확장자들의 이용가능성을 관리할 수 있다. 본 발명의 다른 장점 및 특징들은 이하에 설명된다.

본 발명에 따른 동적 확장가능 프로세서들에 소프트웨어 지원을 위한 본 시스템 및 방법들이 첨부된 도면을 참조하여 더 상세히 설명된다.

도 1은 컴파일러에 의해 제작된 실행가능 파일 이미지(100)를 도구(110)가 재작성될(rewrite) 수 있는 발명의 각종 양태들의 상호운용의 개요를 도시하는 도면이다. 운영 체제 소프트웨어(130)는 실행가능 파일 이미지(100)를 로딩할 때 확장자 기능을 통보받을 수 있다. 운영 체제 소프트웨어(130)는 애플리케이션을 대신하여 요청된 프로세서 확장자의 이용가능성을 관리할 수 있다.

도 2는 예시적인 재작성기 도구(205)의 입력들(202, 203), 및 출력(207)의 개략도.

도 3은 동적 확장가능 프로세서들을 이용하는, 실행가능 파일 이미지들에 대한 예시적으로 확장된 파일 포맷을 도시하는 도면.

도 4는 이미지가, 재작성기 도구에 의해 보충되기 전의 원본 기초 블록을 도시하는 도면.

도 5는 도구가 확장자-트리거 명령어를 이용하여 기초 블록 내의 제1 명령어를 덮어 쓰는 실시예를 도시하는 도면.

도 6은 도구가 확장자-트리거 명령어를 이용하여 기초 블록 내의 제1 명령어를 덮어 쓰고 블록 내의 모든 후속 명령어들을 삭제하는 실시예를 도시하는 도면.

도 7은 도구가 확장자-트리거 명령어를 기초 블록에 삽입하고 이미지 내의 나머지 명령어들을 모두 이동(move up)시키는 실시예를 도시하는 도면.

도 8은 도구가 이미지 내 곳곳으로 이동된 의사-브랜치(pseudo-branch) 명령어를, 기초 블록에 추가하는 실시예를 도시하는 도면.

도 9는 소프트웨어 가시 확장자 상태인 확장가능 프로세서를 도시하는 도면.

도 10은 도 9에 따라 구성된 멀티프로세서 시스템 내의 확장가능 프로세서를 위한 프로세스 별 상태(per-process state) 및 프로세서 별 상태(per-processor state)를 도시하는 도면.

본 발명의 각종 실시예들의 철저한 이해를 제공하기 위해 소정의 특정한 상세들이 다음의 설명 및 도면들에 개시된다. 컴퓨팅 및 소프트웨어 기술과 주로 연 관되는 소정의 공지된 세부사항들은, 본 발명의 각종 실시예들을 불필요하게 애매하게 만드는 것을 방지하기 위해 이하의 개시에 기재되지는 않는다. 또한, 당해 기술의 당업자는 이하에 설명되는 하나 이상의 상세한 기재가 없이도 본 발명의 다른 실시예들을 수행할 수 있음을 이해할 것이다. 마지막으로, 각종 방법들이 이하에 개시된 단계들 및 순서들에 관련하여 설명되었지만, 본 명세서 자체는 본 발명의 실시예들의 명확한 구현예를 제공하기 위한 것이며, 단계들 및 단계들의 순서는 본 발명을 수행하는데 요구되는 것으로 간주되어서는 안된다.

도 1은 본원에서 재작성기 도구(rewriter tool)로도 지칭되는 도구(110)가 컴파일러에 의해 제작된 실행가능 파일 이미지(100)를 재작성할 수 있는 본 발명의 각종 양태들의 상호운용의 개요를 도시한다. 실행가능 파일 이미지는 애플리케이션 또는 컴퓨터 프로그램, 즉, 몇몇 유용한 함수(function) 또는 함수들의 집합을 수행하도록 설계된 일련의 기계 판독가능 명령어들이다. 일반적으로, 애플리케이션은 우선 인간 판독가능 소스 코드로 작성된(written) 후에, 소스 코드는 다수의 자동화된 프로세스(이 중 하나는 컴파일러임)에 의해 기계 언어로 변환된다.

일 실시예에서 도구(110)는, 특정한 애플리케이션을 우선 컴파일하는 컴파일러와는 별개이다. 도구는 컴파일된 실행가능 파일 이미지를 주시하고(look at), 이미지에서 기초 블록들을 식별하고, 확장자-트리거 명령어(121, 122)를 삽입하고 보안 서명(125)을 추가함으로써 이미지를 변경한다. 기초 블록에 의해 수행되었을 수 있는 것과 동일한 기능적 단계들을 프로세서 확장자가 효과적으로 수행하게끔 하는 확장자-트리거 명령어들을 이미지에 보충하는 것은, 이미지를 실행하는 데 있 어 효율성을 증진시킨다.

다른 실시예에서는, 기초 블록들을 식별하여 실행가능 파일 이미지에 확장자-트리거 명령어들(121, 122) 및 컴파일된 채로 보안 서명(125)을 적절히 부가하는 것이 가능한 컴파일러에 도구(110)가 통합될 수 있다.

확장자 정의(123, 124)는 "기초 블록들(basic blocks)" 또는, 확장자 트리거 명령어들이 보충될 이진 명령어들을 제공하거나 그것들을 참조한다. 따라서 확장자 정의(123, 124)는 실행가능 파일 이미지를 통틀어 검색하여, 패턴(123, 124)에 매치되는 임의의 기초 블록들(101, 102)을 찾고, 이러한 영역들(101, 102)에 확장자-트리거 명령어들(121, 122)을 보충하는 데 사용될 수 있는 이진 명령어들의 패턴을 제공한다.

확장자-트리거 명령어들(121, 122)은 프로세서 확장자가 실행되게끔 하는 명령어들이다. 따라서, 도구(110)에 의해 변경된 실행가능 파일 이미지(100)는 대응하는 프로세서 확장자가 실행되게 하는 확장자-트리거 명령어들(121, 122)을 포함할 수 있다. 이는 원한다면 확장자 정의들(123, 124)을 더 포함할 수 있고, 확장가능 프로세서를 확장하는 데 사용되는 임의의 확장자 데이터(126, 127)를 더 포함할 수 있다. 확장자 데이터(126, 127)의 특성들은 프로세서-특정적이므로(processor-specific) 본원에서 논의되지 않는다.

보안 서명(125)은 일반적으로 실행가능 파일 이미지(100)에 행한 변경이 신뢰할 만한 기관에 의한 것이며, 또한 이러한 변경 후에는 이미지가 변화되지 않았음을 체크하는 수단을 제공한다.

운영 체제 소프트웨어(130)가 적합한 확장자(예를 들면 참조부호 123 및/또는 124)를 로드하여 다수의 애플리케이션을 대신하여 요청된 확장자의 이용가능성을 관리한다. 당해 기술분야에서 이해되는 용어로서, 운영 체제는, 부팅 프로그램에 의해 컴퓨터에 초기에 로딩된 후에 컴퓨터 내의 다른 모든 프로그램들을 관리하는 소프트웨어 프로그램이다. 다른 프로그램들에는 각종 애플리케이션 프로그램들이 있다. 애플리케이션 프로그램들은 정의된 애플리케이션 프로그램 인터페이스(API)를 통해 서비스를 요청함으로써 운영 체제를 사용한다. 또한, 사용자들은 통상적으로 커맨드 언어 또는 그래픽적 사용자 인터페이스(GUI)와 같은 사용자 인터페이스를 통해 운영 체제와 직접 대화할 수 있다.

프로세서의 동적 확장자를 지원하기 위해, 운영 체제 소프트웨어(130)는 애플리케이션 로딩 시에, 몇몇 API를 호출하는 애플리케이션에 의해 명시적으로 또는 실행가능 파일 이미지(100)에 포함된 정보에 의해 암시적으로, 실행가능 파일 이미지(100)의 확장성 기능을 통보받을 수 있다. 보안 서명(125)은 요청된 확장자(들)(126, 127)이 정확함을 증명할 수 있다. 도 1에서 확장자들(126, 127)이 이미지(100) 내부에 도시되어 있지만, 운영 체제(130)에 의해 또는 몇몇 기타 모듈 또는 네트워크화된 컴퓨팅 장치를 통해 공급될 수 있음에 유념하자. 보안 서명(125)을 체크한 후에, 운영 체제(130)는 프로세서 확장자(126, 127)를 프로세서 확장자 슬롯(예를 들면 참조부호 141)에 로드(load)할 수 있다.

운영 체제(130)는 프로세스의 보호된 상태의 일부분으로서 프로세스 별 단위(per-process basis)로 확장자 정보를 계속 추적(track)함으로써 복수의 애플리 케이션들 중에서 이용가능한 프로세서 확장자들을 관리할 수 있다. 확장자 정보는 또한 보다 복잡한 멀티프로세서 환경(setting)에서도 추적될 수 있다. 운영 체제는 상이한 애플리케이션 프로그램들 사이에서 문맥(context)-전환할 시에 요청된 확장자들이 존재하고 로딩된다는 것을 보장할 수 있다.

변경된 실행가능 파일 이미지는 전체 원본 기초 블록들뿐만 아니라 확장자-트리거 명령어들을 포함할 수 있다. 그럼에도 이는 확장불가능한 프로세서들로 하여금, 확장자-트리거 명령어들을 단순히 무시하고 코드의 원본 기초 블록들에 "폴링쓰루(falling-through)"하여, 변경된 실행가능 파일 이미지들을 실행하게 한다. 한편, 확장가능 프로세서는, 확장자-트리거 명령어들을 실행하고, 코드의 대응하는 원본 블록들을 "점프-오버(jumps-over)"한다.

확장가능 프로세서(140)는 현재 로딩되는 확장자(currently-loaded extensions)들을 위해 제한된 개수의 슬롯들(141, 142, 143)만을 갖는다. 운영 체제(130)는 이들 제한된 리소스들을 관리하여 이용가능한 슬롯들(141, 142, 143)의 개수를 요청된 확장자들이 초과하는 경우에 최적화되지 않은 경우(the non-optimized cases)로 되돌아 갈 수 있다.

도 2는 예시적인 재작성기(rewriter) 도구(205)의 입력들(202, 203) 및 출력(207)의 개략적인 모습을 도시한다. 재작성기 도구(205)는 관심있는 코드를 연결된 명령어의 시퀀스 보다는 개별적 명령어들로서 주목하지는 말아야 한다는 현실감(realization)을 활용한다. 다시 말해, 명령어들의 집합이 아니라 기초 블록들( basic blocks)의 집합으로서 코드를 주목해야 한다. 예외 및 인터럽트를 제외 하고는, 마지막 명령어가 다른 곳으로 브랜치하기 전에 기초 블록이 전체적으로 실행되므로, 이는 명확하게 정의된 프로세서들 모두에서, 자동으로 전부 실행되거나 전혀 실행되지 않는 프로세서 명령어와 매우 유사하다. 기초 블록의 경우에는, 운영 체제는 인터럽트 및 가상 메모리 결함을 숨겨서(hide away) 무언가 오류적인 것이 일어날 때 단지 예외를 트리거한다.

이 논의를 위해, "기초 블록"은 브랜치 명령어에서 종료하는 기계 명령어의 선형 시퀀스로 정의된다. 브랜치(branch)는 조건부이거나 아닐 수 있는데 서브루틴 호출 및 반환이 브랜치이다. 기초 블록 중간으로의 점프는 있을 수 없어서, 가장 최초의 명령어에 입력되는 것만이 가능하다. 블록으로의 점프의 경우에 우리는 두 개의 블록들을 고려할 것인데 대신에, 각각의 블록은 두 엔트리 포인트에 해당하고, 양쪽 블록은 동일한 브랜치 명령어에서 종료한다.

여기서는 코드 생성을 위해 보다 고급의 언어 및 컴파일러를 주로 사용하여 기초 블록들이 실제 코드에서 반복될 가능성도 보다 커지게 된다. 우리의 분석에서는 우리가 애플리케이션 프로그램들의 큰 집합을 고려하고 반복되는 기초 블록 패턴들을 찾는 경우에 평균적으로, 각각의 패턴들이 적어도 10회는 반복됨을 발견할 것으로 나타났다. 일부 패턴들은 수천번 반복한다.

일 실시예에서, 도구(205)는 컴파일러(201) 및 링커에 의해 제작된 실행가능 파일 이미지(202)를 재작성한다(rewrites). 도구(205) 동작(operation)을 수행하도록 보통의 컴파일러의 링커를 변경함으로써 도구(201)가 실현될 수 있어서, 중복된 작업을 제거할 수 있다. 도 2에 도시된 대로, 도구(205)로의 입력은 원본 실행 가능 파일 이미지(202) 및 프로세서 확장자 정의 파일(203)이다. 대안적인 실시예에서, 프로세서 확장자 정의 파일(203)은 데이터베이스로서 구현될 수 있다. 프로세서 확장자 정의 파일(203)은, 도구(205)가 실행가능 파일 이미지(202)에서 검색할 수 있는 기초 블록들을 식별한다. 파일(203)은 또한 기초 블록들이 내부에서 식별되는 경우에 이미지(202)를 보충하는 데 사용될 수 있는 확장자-트리거 명령어들의 정의 및 기계 판독가능 코딩을 제공한다.

마지막으로, 파일(203)은 프로세서를 확장하는 데 운영 체제에 의해 사용되기 위해 이미지(202)에 또한 삽입될 수 있는 확장자 정의를 공급할 수 있다. 도구(205)는 정의 파일(203) 내에 정의된 기초 블록 패턴들에 매치되는 이미지(202)에서 기초 블록들을 찾고 그것들에 새로운 확장자-트리거 명령어들을 보충한다. 논리적 레벨에서, 우리는 기초 블록(또는 기초 블록들의 세트)에 확장자-트리거 명령어들을 부가하는 행위로서 재작성기 동작을 생각할 수 있다. 기초 블록을 "보충하는(supplementing)" 것은 기초 블록을 교체하는 것, 기초 블록의 일부를 교체하는 것, 또는 기초 블록에 추가를 하는 것을 포함한 행위로서 이해되어야 하겠다.

다음은 예시적인 명령어 확장자 정의 파일(203)이다:

/* file: patts.bbw */

[bbname return]

MIPSBE

[encoding]

[v1=v0+8]b26.6:c011111;b21.5:r1;b16.5:r2;b0.16:v1;

[code 12]

1000228c

8004000

18002124

[disasm]

lw r2,10(r1)

jr r2

addiu r1,r1,18

[registers 3]

0,29,31

[values 2]

{0,6,10}

{8,6,18}

[bbname __ull_div]

MIPSBE

[encoding]

[r1=r2+1;r3=r0+11;r5=r4+1;r6=r5+1]b26.6:c011110;b21.5:r4;b16.5:r2;b0.16:v0;

[code 48]

40080100

c21f0200

25082300

40100200

c21f0400

25104300

40200400

c21f0500

25208300

2b182600

5000310

40280500

[disasm]

sll r1,r1,1

srl r3,r2,31

or r1,r1,r3

sll r2,r2,1

srl r3,r4,31

or r2,r2,r3

sll r4,r4,1

srl r3,r5,31

or r4,r4,r3

sltu r3,r1,r6

beq r0,r3,40

sll r5,r5,1

[registers 7]

0,9,8,11,4,5,6

[valuess 1]

{40,11,5}

[bbname R_DrawColumnLoop_c]

MIPSBE

[encoding]

[r7=r0+4;r4=r0+5;r3=r0+6;r1=r0+7]b26.6:c011101;b21.5:r5;b16.5:r6;b11.5:r8;b6.5:r9;b0.6:c000000;

[code 44]

3140100

7f004230

21106200

4290

21108200

4290

21082500

ffffc624

e2a0

f6ffc814

2138e900

[disasm]

sra r2,r1,16

andi r2,r2,7f

addu r2,r3,r2

lbu r2,0(r2)

addu r2,r4,r2

lbu r2,0(r2)

addu r1,r1,r5

addiu r6,r6,-1

sb r2,0(r7)

bne r6,r8,0

addu r7,r7,r9

[registers 10]

0,7,2,6,5,10,3,4,8,9

위의 예시적인 파일은 세 개의 명령어 패턴을 식별하는데, 각각은 정규형의 기초 블록에 몇몇 잉여 정보를 더한 것이다. "bbname" 오프닝 태그에 의해 "return"으로 명명된 제1 패턴은, 도 4 내지 도 8에 실행 예로서 사용된 기초 블록에 직접적으로 대응한다. "＿ull_div" 및 "R＿DrawColumnLoop＿c"라고 불리는 기타 블록들은 실제 애플리케이션 시스템을 최적화하는 데 유용한 것으로 현재 고려된다.

관찰될 수 있는 바와 같이, 각각의 패턴은 패턴을 명명하는 "bbname" 절(clause)로 시작한다. 이 제1 섹션에서는 어떤 유형의 프로세서에 패턴들이 속해 있을지가 또한 명시된다 - 이 경우에는 MIPS(Microprocessor without Interlocked Pipeline Stages) BigEndian 확장가능 프로세서임 - . 구현에 따르면, 하나의 파일에서 여러 프로세서들을 위한 패턴을 수집하는 것이 바람직하다.

"encoding" 절은 패턴의 특정 기초 블록 인스턴스에 대한 실제 인수(argument)를 확장자-트리거 명령어로 인코딩하는 방법을 재작성기 도구에게 설명하는 스트링이다. 스트링은 두 개의 부분인, 각괄호(angle brackets)들 내에 도시된 선택적인 전제조건 부분과 강제 치환 부분(a mandatory substitution part)으로 나뉜다.

전제조건은 세미콜론들로 분리된 다수의 절들을 포함할 수 있다. 각각의 절은 패턴의 파라미터인 값 또는 레지스터로 불린다. 예를 들면, 블록 "return"에서 절은 값 파라미터 수 1 "v1"이 값 파라미터 0 "v0" 더하기 8과 동일해야만 하는 조 건을 명시한다. 패턴을 기초 블록 인스턴스에 적용하기 전에 재작성기에 의해 전제조건으로서 빠르게 검증되는 매우 단순한 산술식을 사용할 수 있다. 전제조건이 충족되지 못한 경우에는 패턴이 적용되지 않는다. 레지스터 파라미터의 전제조건들은 "r<n>" 형태로 되어 있고 그것들은 레지스터 넘버 자체를 참조한다. 일부 레지스터 할당이 일부 다른 레지스터 할당으로부터 추론될 수 있는 경우에 우리는 확장된 명령어 내의 귀중한 공간을 사용하지 않을 수 있다.

인코딩의 치환 부분(substitution part)은 세미콜론으로 분리된 다수의 절들을 포함한다. 절들 각각은 비트 필드 사양(bit field specification)을 포함하는데, 그 다음에는 콜론이 이어지고, 다시 인수(argument) 선택자가 이어진다. 비트 필드는 문자 "b"로 시작하고, 그 다음에 필드의 제1 비트의 비트 넘버가 포함된다. 도트(a dot)는 비트를 포함한 비트들의 비트 필드의 크기를 분리한다(separate the bit field size, in bit, inclusive). 인수 선택자는 레지스터 파라미터 "r<n>" 또는 값 파라 미터 "r<n>", 또는 이진 상수 "c<bits>"일 수 있다.

"code" 섹션은 프로세서를 위한 기초 블록 패턴의 이진 표현이다. 키워드 "code" 뒤에는, 후속되는 이진 코드의 바이트 크기가 바로 이어진다. 예시적인 실시예에서는, 각각의 MIPS 명령어는 4 바이트를 요구한다. 따라서 "code" 섹션은 확장자로 대체된 이진 명령어들을 제공한다.

"disasm" 섹션은 기초 블록의 의미가 무엇인지를 상기시키는 것으로서, 사용자 이익만을 위한 것이다. 여기서 코드는, 모든 레지스터들이 1에서 시작하는 리넘버링된 "정규(canonical)" 형임을 유념하자.

"registers" 섹션은 이 패턴으로 추상화된 실제 기초 블록에서 발견된 실제 레지스터 넘버들의 할당을 보여준다. 제1 블록("return")에서 지시된 레지스터 치환은 도 4의 코드로 직접 유도될 것이다. 이 절은 패턴에 의해 명시된 레지스터들의 개수뿐 아니라 레지스터 넘버 0을 사용할 수 없는 MIPS 프로세서에 대한 특별한 경우를 가리키는데, 이는 와이어드(wired) 값 0을 갖는 특별한 레지스터가 된다.

"values" 섹션은 한 인스턴스화에서 다른 인스턴스화로 변할 수 있는 패턴에서 상수를 나타내는 데 사용된다. 이때, 각각의 값은 괄호로 묶인 3 요소들의 튜플(tuple)이다. 제1 요소는 값을 포함하는 명령어의 바이트 오프셋이다. 제2 요소는 값이 인코딩되는 방법을 가리키는 프로세서-특정적 코드이다. 일반적으로, 여기서 값은 명령어가 이미지 파일 내에서 돌아다닐 때에 명령어를 변경하기 위해 링커/로더에 의해 사용된 재배치 코드(relocation code)에 대응한다. 제3 요소는 원본 기초 블록에서 발견된 실제 값 그 자체이다. 이 전체의 예시적 파일("encoding" 섹션은 제외)은 별도의 도구에 의해 자동으로 생성될 수 있는데, 이는 당업자에 의해 이해될 것이므로 본원에서 더 설명하지는 않겠다.

상술한 예시적인 정의 파일에서 설명되지 않았지만, 이러한 파일은 또한 몇몇 실시예에서, 새로운 프로세서 확장자 명령어를 갖는 하나 이상의 프로세서들을 확장하는 데 사용되는 확장자 데이터를 포함할 수 있다. 다른 실시예에서는, 이러한 확장자 데이터가 소위 "bitfile"의 형태일 수 있는데, 이는 구성되기 위해 FPGA 프로세서로 로딩되는 판매자-소유권자 파일 포맷이다. 예를 들면, 이는 상기 논의된 Clark, Blome, Chu, Mahlke, Biles, 및 Flautner의 논문에 제시된 그래프를 인 코딩하는 고정된 크기의 비트 스트링일 수 있다.

도구(205)는 바람직하게는 주어진 명령어 패턴에 매치되는 명령어들의 모든 시퀀스를 발견할 수 있다. 이 패턴 매칭을 달성하기 위한 한가지 방법은 다음과 같지만, 보다 정교한 알고리즘들이 또한 가능하며 그러한 변화들은 당업자에 의해 이해될 것이다.

명령어 패턴 및 후보 블록의 길이가 우선 체크될 수 있고, 그 후 세 개의 프로세서-특정적 분석 단계들이 수행될 수 있다. 제1 단계에서는, 연산코드(opcode) 호환성을 위해 두 개의 블록들이 체크된다. 단순한 구현은 두 개의 블록에서 명령어 연산코드 및 연산코드 한정자(qualifiers) 들이 블록 내의 대응하는 위치에서 동일한지를 체크할 수 있다.

두 번째 단계는 레지스터 할당들이 호환가능한지를 체크한다. 명령어 패턴이 정규(canonical) 레지스터 할당을 포함하는 경우에는, 호환성 체크는 다음과 같이 진행된다: 우선, 후보 블록에 대한 모든 레지스터 할당들이 "미사용(unesed)"으로 마크된다. 각각의 레지스터를 만나게 되면, 정규 패턴으로 지정된 레지스터("레지스터 N(resister N)")를 식별한다. 후보자로 지정된 레지스터는 "레지스터 M(resister M)"으로 불릴 수 있다. 다음으로, 후보 블록에 대한 레지스터 지정에서 레지스터 N의 위치를 식별한다. 위치가 "미사용(unused)"인 경우에는, 그것에 레지스터 M의 값이 할당될 수 있다. 만일 미사용이 아니고 이미 할당된 경우에는, 값이 여전히 M임을 체크한다. 아닌 경우에는, 두 개의 블록들이 호환가능하지 않아 체크는 실패한다.

세 번째 단계는 명령어 블록들에 내포된 임의의 상수 값들이 호환가능한지 체크한다. 주어진 필드에 대한 "값(value)" 파라미터를 명령어 패턴이 나타내는 경우에는, 후보자는 인코딩된 임의의 실제 값을 자유롭게 가질 수 있거나, 아니면 두 개의 필드들은 동일한 값들을 포함해야만 한다. 값 파라미터의 일례로는, 두 개의 블록들이 그것들의 마지막 브랜치 목적지에서만 상이한, 흔한 경우에는, 브랜치 오프셋 필드일 수 있다. 매치되어야만 하는 상수의 일례로는 시프트 양이 가능한데, 매우 드물게는 그러한 필드를 단순히 변경함으로써 명령어의 두 시퀀스가 매치될 수 있다.

바람직한 실시예에서는, 도구(205)는 이전에 존재하던(pre-existing) 컴파일러(201) 도구들에 대한 대체가 아니다. 도구(205)는 컴파일러(201)의 도구들이 적용되고 이미지(202)가 가장 널리 공지된 최적화 기술들 모두에 따라 완전히 최적화된 후에 동작(works)한다. 몇몇 실시예들에서는, 도구(205)가 자신의 임무를 끝낸 후에 컴파일러(201)의 도구를 다시 적용함으로써 추가의 효율을 얻는 것이 가능할 수 있다.

서명된, 최적화된 실행가능 파일 이진 이미지(207)가 도 3에 도시된 확장된 파일 포맷의 형태를 취할 수 있다. 설명된대로, 확장된 파일 포맷은 섹션 카운트 및 오프셋을 갖는 이미지 파일 헤더(301), 보안 다이제스트 및 서명 섹션(302), 명령어 확장자 테이블(303)(두 개의 확장자들이 도시되어 있지만, 임의 개수의 확장자들도 물론 가능함), 및 임의의 코드 섹션(들)(304)을 포함할 수 있다.

도 2로 잠시 돌아가면, 도구(205)가 이미지(202)에 확장자-트리거 명령어를 보충할 수 있는 방법이 적어도 네 가지 존재한다. 이들 각종 대안적인 실시예들은 도 4 내지 도 8에 도시되어 있다. 도 4는 도구에 의해 이미지에 보충이 있기 전의 원본 기초 블록을 도시한다. 도 5 내지 도 8은 확장자-트리거 명령어가 보충된 기초 블록을 도시한다. 도 5는 도구가, 확장자-트리거 명령어로 기초 블록 내의 제1 명령어를 덮어쓰는(overwrites) 실시예를 도시한다. 도 6은 도구가, 확장자-트리거 명령어로 기초 블록 내의 제1 명령어를 덮어쓰고 블록 내의 후속하는 명령어들을 모두 삭제하는 실시예를 도시한다. 도 7은 도구가 기초 블록에 대해 확장자-트리거 명령어를 삽입하고 이미지 내의 남아있는 명령어들을 모두 이동시키는(move up) 실시예를 도시한다. 도 8은 도구가, 기초 블록에 이미지 내 곳곳으로 이동된 의사-브랜치 명령어를 추가하는 실시예를 도시한다.

모든 경우에서, 확장자-트리거 명령어를 실행하는 것은 원본 기초 블록과 동일한 의미론적 액션을 수행하고, 실행은, 기초 블록이 유도했던 곳에서 정확하게 계속될 것이다. 예를 들면, 도 7에서, 기초 블록을 존재한 채로 남기지만 이는 확장자-트리거 명령어가 실행되는 경우에는 실행되지 않는다. 도 5에서, 남아있는 블록의 명령어는 확장자-트리거 명령어가 실행되는 경우에 유사하게 실행되지 않는다.

도 8은 적어도 기초 블록 움직임(motion) 및 이미지 조작의 관점에서 도 7의 특수-경우로서 몇 가지 방법으로 고려될 수 있다. 브랜치 명령어를 사용하는 것은 어떤 액션이 바람직한지에 관하여 임의의 정보를 확장가능 프로세서에 전달하도록 허용하지 않음을 유념해야 한다. 몇몇 실시예에서는, 확장가능 프로세서는 그것의 자동-확장자 알고리즘의 "(학습)learning" 구문을 시작하기 위한 트리거로서 이 명령어를 처음부터 사용할 것이다. 이 어드레스에서의 학습-단계 트리거 명령어(learning-phase trigger instruction)의 후속 실행은 그 후 학습된 실행으로 하여금 원본 기초 블록 대신에 실행하게 할 수 있다.

도 7의 확장된 명령어는 세 인수(arguments), 두 레지스터 및 하나의 스택 오프셋을 인코딩한다. 우리가 도 8을 사용하면 우리는 이 정보를 전달할 수 없을 것이므로, 이 유형의 함수 에필로그(function epilogue)에 매치하는 모든 블록은 개별적으로 인코딩되어야 할 것이다. 다시 말해, 도 8은 도 7처럼 도 6으로 축소될 수는 없다.

각각의 해법은 장점과 단점을 갖는다. 도 5는 구현하기에 효과적이고 쉽지만, 비 확장가능(non-extensible) 프로세서들에 대해 이전 버전과는 호환(backward campatible)되지 않는다. 도 6 내지 도 8은 이미지의 완전한 재-링킹(re-linking), 재배치 정보의 변경, 심볼 테이블 등을 효과적으로 요구한다. 원본 링커를 변경하는 것은 이들 해법을 구현하는 한 가지 방법이다. 도 6은 평균적으로 하나의 확장자-트리거 명령어가 적어도 두(일반적으로는 훨씬 더 많은) 명령어들의 완전한 기초 블록을 대신하기 때문에, 실행가능 파일 이미지의 크기를 줄일 수 있다. 도 5와 마찬가지로, 이는 이전 버전과 호환불가능하다. 도 7은 기능적으로 풍부하고, 이전 버전과 호환가능하지만, 이는 약간 더 큰 이미지들을 또한 생성해서 구현하기에 더 어렵다.

몇몇 상황에서, 도 7 및 도 8은 단지 수용할 수 있는 실시예들일 수 있다. 다수의 로드 및 저장 명령어를 포함하는 기초 블록의 경우를 고려하자. 필요한 원자성(atomicity)을 제공하기 위해서는, 확장된 명령어를 대체하는 데 있어서 로드 및 저장들이 모두 성공하거나 모두 실패하는 것 중 반드시 어느 한쪽이어야 한다. 이는 하드웨어에서 실현하기에 쉽지 않고, 확장된 명령어의 구현자(implementer)가 로드들/저장들 중 하나의 동등한 어드레스에서 실행을 인터럽트할 수 있도록 하기에 유리할 수 있다. 완전히 호환가능해지기 위해, 이는 몇몇 경우, 예를 들면 로드 동작이 예외를 일으키는 경우에 요구되는 구현예일 수 있다.

애플리케이션 이미지들에 확장자-트리거 명령어들을 삽입하는 것은 다수의 추가 고려사항을 제기한다. 비록 프로세서가 확장가능해도, 우리는 확장자가 실제로 실행 시에 이용가능하다고 가정할 수는 없다. 확실히 이용가능한 프로세서 명령어들만이 기초 집합 내의 명령어들이다. 다음으로 우리는 이하의 두 가지 문제를 고려하려 한다: (1) 확장자들이 로딩되지 않고 우리가 확장된 명령어를 실행하도록 시도한다면 무슨 일이 일어날 것인가? (2) 확장자들이 적절하게 로드 및 관리된다는 것을 어떻게 보장할 수 있는가?

첫 번째 문제는 우리가 일반적으로 "이전 버전과의 호환가능성(backward compatibility)"이라고 지칭하는 고려사항들을 제기한다. 프로세서가 로드된 확장자를 갖지 않던지 또는 확장가능 프로세서가 아니든지 간에, 실행 시스템은 반드시, 이미지를 실패시키거나 또는 원본의, 최적화되지 않은 이미지와 동일한 방식으로 이미지를 실행시켜야 한다. 이미지를 실패시키는 것은 실현하기에 쉽고, 확장된-명령어들은 불법적인 명령어로 고려될 수 있어 시도될 경우 트랩이 생성될 수 있다. 이는 어쨌든 비-확장된 프로세서에서의 가장 가능성이 큰 결과이다. 그러나 요구되는 사전조건들이 모두 부합하지는 않는다는 사실에도 불구하고, 이미지를 실패시키는 것은 실제로, 그 이미지의 실행을 요청한 사용자(또는 시스템)가 그것이 원래 의도된대로 동작하기를 기대하는 경우에는, 가장 바람직한 결과가 아니다.

도구가 도 7 또는 도 8의 접근법을 사용한 경우에, 이는 쉽게 달성될 수 있다. 확장된 명령어들은 널(null) 명령어들(no-op)로서 고려될 수 있고 실행은 원본 기초 블록을 폴쓰루(fall-through)(또는 그것으로 브랜치)할 것이다. 비-확장된 프로세서는 트랩을 생성시킬 것이고, 성능 패널티를 피하기 위해서는 운영 체제에게 어떤 일이 일어날지를 알아채고, 성가신 확장된 명령어를 명료하게 재작성해서 이를 진짜의, 트랩핑되지 않은 널 명령어로 대체하는 것이 합당하다. 일 실시예에서는, 프로세서 확장자 명령어를 실행하기 위해 호출하는 애플리케이션의 일부를 무효로(nullifying) 하는 것은 하나 이상의 프로세서 확장자 제어 레지스터들의 값을 바꿈으로써 달성될 수 있다. 확장가능 프로세서가 이 옵션을 가질 뿐만 아니라, 운영 체제는 확장자를 로딩하는 요건을 느리게-평가하는 것일 수 있어서 이 트랩을 자신의 확장자-관리 알고리즘의 일부로서 사용할 것이다. 그러나 프로세서가 비-트랩핑의 옵션을 갖고 모든 불법적 명령어들을 널 명령어로서 고려하는 것이 또한 합당하다. 이를 달성하기 위한 한 방법은 확장자 명령어들의 존재시에 프로세서 행동을 정의하기 위해 소프트웨어가 사용할 수 있는 제어 레지스터를 하드웨어에 제공하는 것이다. 다시 말해, 소프트웨어는 트랩할지 하지 않을지를 결정해야한다.

상기 제시된 두 번째 문제에 대해 고려하면, 프로세서 확장자들을 다루기 위한 수많은 가능한 관리 스킴들이 존재한다. 몇몇 예에서 이 문제는 단순히 무시될 수 있다. 내장형 시스템의 경우, 또는 게임 콘솔의 경우를 고려하자. 이들 경우에서 애플리케이션 프로그램의 집합은 사전에 공지되어 있거나 엄격히 제한된다. 예를 들면, 게임 콘솔의 제조자는 안전장치(safeguards)를 제자리에 놓아서 인증된 게임들만이 콘솔에서 실행될 수 있다. 이러한 경우에서 운영 체제는 파워-업 시에 확장자를 로드할 것이고 애플리케이션 프로그램들이 확장자들을 적절히 사용한다고 단지 가정할 것이다.

이러한 시나리오에서, 혹자는 왜 이들 확장자들이 기본 프로세서 명령어 집합의 일부가 아닌지를 물을 수 있다. 많은 가능한 이유들이 존재하는데, 게임 콘솔에서 확장자(들)이 실제로 전개될 수 있고 시간이 지남에 따라 새로운 프로세서 명령어들이 추가되지만 이전의 프로세서를 보존하기 위해 주의(attention)를 항상 기울인다. 다른 이유로는 제작의 절약이 있다. 단일한 프로세서 칩은 많은 양이 제작되지만 그러면 그것은 자신의 용도에 따라 상이한 방식으로 맞춤화(customized)된다. 이는 동일한 프로세서가 상이한 시스템을 위해 상이한 방식으로 최적화되어서 내장형 시스템들에게 다소 매력적일 수 있다. 이것이, 사용된 관리 스킴인 경우에는 상술된 재작성기 도구면 충분할 것이다.

실행가능 파일 이미지에서 임의의 잉여 정보를 요구하지 않는 또 다른 접근법은 각각의 확장된 명령어를 고유하게 인코딩하는 것이어서, 명령어가 처음 실행되는 경우에 요구되는 확장자를 운영 체제가 자동으로 식별하게 할 수 있게 하는 것인데, 이때 운영 체제는 불법적 명령어 트랩을 트리거한다. 확장자 자체는 다른 수단에 의해 운영 체제에 제공될 것이다. 이 접근법은 한정사항 - 중앙의 클리어링하우스(clearinghouse)가 없는 각종 소프트웨어 개발자들과 같은 관련되지 않은 상대들 중에 고유성을 보장하는 것이 어렵고, 확장된 명령어들을 인코딩하는 데 이용가능한 잉여 운영코드들의 수가 상당히 제한될 수 있음 - 을 갖는다. 임의의 기타 관리 해결법은 재작성기 도구가 몇몇 잉여 정보를 실행가능 파일 이미지에 추가할 것을 요구한다.

도 9는 소프트웨어 가시 확장 상태를 갖는 예시적인 확장가능 프로세서를 도시한다. 확장가능 프로세서는 확장 상태(901), 명령어 캐시(903), 명령어 디코딩 로직(905), 현재 라우팅 로직(907), 및 확장자 유닛(909)을 포함한다. 상술된 바와 같이, 확장자 데이터가 무엇이며 그것이 하는 것이 정확하게 무엇인지는 프로세서-특정적이다. 본 발명은 이 정보(예시 목적으로 도시됨)에만 의존하는 것은 아니다. 많은 상이한 프로세서 확장자 스킴들이 가능함이 명백할 것이다. 예를 들면, 도 9의 프로세서는 내부의 실행 유닛들 사이에서 데이터의 라우팅을 정의하기 위한 비트들의 스트링을 사용한다. 이 정보는 도 9 및 도 10에서 "라우트-데이터(route-data)"로 지칭된다.

적절하게 구현된다면, 라우팅 데이터는 프로세서의 보안에 영향을 미칠 수 없으므로 이미지가 보안 유효성을 통과했음을 확인하기 위해 보안 인증서를 실행가능 파일 이미지들에 적용하는 것은 불필요하다. 라우팅 정보를 이미지에 국부적으로 이용하는 특정의 확장된 연산코드에 라우팅 정보를 연관시키는 테이블을 이미지 에 삽입하는 것으로 충분하다. 도 3에서는, 명령어 확장자들 섹션(303)이 두 개의 그러한 확장자를 갖는 테이블을 보유하고, 동일한 라우팅 데이터는 일반적으로 도 3에서 "데이터(Date)"로서 지시된다. 하나의 이러한 이미지는 자체 포함형으로, 임의의 다른 이미지들에는 독립적이다 - 다른 수단으로 확장자 데이터를 제공할 필요가 없어서 비록 동일한 명령어 연산코드가 상이한 이미지들에서 상이한 의미를 갖는다 해도, 운영 체제는 다수의 이미지들을 동시적으로 다룰 수 있을 만큼 충분한 정보를 가짐 - 라는 것에 주목하자.

또 다른 확장가능 프로세서 실시예는 FPGA에 확장자 데이터로서 로드되는 이진 파일을 사용할 수 있다. 파일은 많은 명령어들 사이에서 공통적이다. 이 유형의 프로세서 설계가 있어서 확장자는 프로세서 상태에 대해 임의 동작을 수행할 수 있고, 이에 따라 확실하게 보장될 것이다. 이러한 프로세서를 보장하기 위해, 확장자를 사용하기 원하는 이미지는 아마도 어쩌면 보안 인증서를 갖고 확장자를 고유하게 식별하도록 요구될 수 있다. 확장자 자체는 암호화된, 그리고 서명된 데이터로서 이미지에 포함될 수 있다.

또 다른 확장가능 프로세서 실시예에서는, 예를 들면, 운영 체제의 일부로서 확장자가 전달되어(shipped) 개별적으로 설치된다. 이 접근법의 한가지 장점은 런타임 북키핑 오버헤드(runtime bookkeeping overhead)를 최소화한다는 점이다. 도 9 및 도 10을 참조하면, 이러한 실시예에서 라우트-데이터 구성요소들은 주어진 확장자에 대해 작은 식별자를 포함한다.

최종 확장가능 프로세서 실시예에서는, 본원에 개시된 제1 실시예에서처럼, 확장자들이 보안 처리를 생성할 수 없는 방식으로 확장가능 프로세서가 설계될 수 있지만, 확장자들은 하나의 확장자에서 여전히 많은 명령어 구현들을 제공할 수 있다. 이 실시예에 대하여 확장자가 이미지에 포함되지 않았다면 확장자를 식별하는 것이 바람직하다. 재작성기 도구는 도 3에 도시된 보안 다이제스트 및 서명 섹션(302)을 실행가능 파일 이미지에 추가해야 한다.

요약하면, 재작성기 도구는 확장자 트리거 명령어들을 실행가능 파일 이미지의 코드 섹션에 삽입하고, 또한 확장자 정의 및/또는 확장자 식별을 추가할 수 있고, 보안 서명 및 다이제스트를 실행가능 파일 이미지에 더 추가할 수 있다.

동적 확장가능 프로세서를 포함하는 시스템에서 로드되고, 그러한 프로세서를 이용하기 위해 상술된 바와 같이 재작성된 애플리케이션을 위한 소프트웨어 서포트에 대해 이제 자세히 설명될 것이다. 소프트웨어 서포트는 다른 운영 체제 기능을 포함하는 운영 체제에 통합될 수 있다.

예시적인 실시예에서, 운영 체제는 애플리케이션 로딩 시에 프로세서 확장성을 이용하기 위해 애플리케이션의 능력을 통보받는다. 이러한 통보는 일부 애플리케이션 프로그래밍 인터페이스(API) 호출의 명백한 호출에 의할 수 있거나, 또는 이전의 섹션에서 정의된 대로 실행가능 파일 이미지에 포함된 정보에 기초한 운영 체제에 의해 행해진 추론에 기초할 수 있다. 확장성의 통지에 따라, 운영 체제는 임의의 적합한 프로세서 확장자를 확장가능 프로세서 슬롯에 로드할 수 있다.

운영 체제는 프로세스의 보호된 상태의 일부로서 프로세스 단위로 확장성 정보를 계속 추적할 수 있다. 도 10은 도 9의 확장가능 프로세서에 요구되는 프로세 스 별 상태를 도시한다. 이는 또한 도 10에서도 도시된 대로 어떤 프로세서 확장자가 멀티-프로세서 시스템의 이용가능한 확장가능 프로세서의 어떤 슬롯에 로드되는지를 계속 추적하는 데 도움이 될 수 있다. 이 지식은 예를 들면, 확장자 데이터가 상대적으로 크고 사용중인 확장자들이 몇 개 없을 경우에 유용할 수 있다. 이 경우에서 상이한 애플리케이션 프로그램들로부터 동시에 확장자를 로드하는 것이 가능할 수 있다. 도 10은 반복되는 라우트-데이터를 도시하는데, 이는 잠재적으로 값비싼 비교를 요구한다. 라우트-데이터를 분리된 영역에서 유지하고 포인터들 또는 인덱스들을 대신 이용하는 것이 가능하다.

운영 체제 로더는 애플리케이션 시작 시에 프로세서 확장자를 운영 체제에 제공할 수 있다. 로더는 또한 애플리케이션들이 프로세서 확장자들을 공유하는 것을 도울 수 있다. 연산코드를 사용하여 재작성기 도구에 의해 생성된 애플리케이션들은 일반적으로 동일한 방식으로 모두 일부 값에서 시작하여 동일한 방식으로 진행하는 연산코드들을 가질 것이다. 이는 애플리케이션들 중에서 연산코드들 사이의 충돌을 유도한다. 이 문제를 피하기 위해서는, 새롭게 로딩된 이미지의 연산코드를 로더가 변경할 수 있어서 이전에 로드된 이미지들과의 충돌을 최소화하게 한다. 도 10은 이 최적화의 효과를 도시한다. 프로세스-1과 프로세스-2가 상이한 연산코드를 사용하기 때문에, 그것들은 양쪽 모두 임의의 관리 트랩에 빠지지 않고 프로세서-1에서 스케쥴링될 수 있고, 프로세서-2는 양쪽 프로세서에 모두에서 스케쥴링될 수 있다. 프로세서-1을 프로세서-2에서 스케쥴링하려고 시도하는 경우에는, 대신에 트랩에 빠질 것이다.

확장가능 프로세서는 현재 로드중인 확장자들을 위한 단지 제한된 개수의 슬롯들을 갖는다. 실제의 개수는 도 9에 도시된 만큼 적을 수 있거나, 또는 더 클 수 있지만, 이는 언제나 유한 개일 것이다. 운영 체제는 애플리케이션 프로그램(들)을 대신하여 이 제한된 리소스를 효과적인 방식으로 공유하여, 이를 관리하는 중재자(arbiter)일 수 있다.

이 문제는 부동-소수점 코프로세서를 다루는 문제 및 다수의 애플리케이션 프로그램들에 의해 남겨진 상태와 유사하다. 하나의 결정적 차이를 갖는 공지된 알고리즘들이 본원에서 적용될 수 있다. 부동 소수점 코프로세서 경우에서 코프로세서가 이용가능하도록 되지 않고서는 실행은 진행할 수 없는데, 그 이유는 (a) 변화할 수 있는 상태가 남아있고, (b) 코프로세서만이 부동-소수점 명령어들을 실행할 수 있기 때문이다.

우리의 경우에서 재작성기 도구가 도 7에 예시된 스킴을 사용하는 것으로 가정하면, 우리에게는 이들 제한이 없게 된다. 우선, 애플리케이션 상태는, 부동 소수점 경우와 유사한 것으로 더 고려되지 않는, 잉여 레지스터 상태를 확장자가 제공하지 않는 한, 특수 유닛이 아니라 범용 레지스터들에서 보유된다. 라우트-데이터는 변화가능하지 않아서 문맥 전환에 걸쳐 보존될 필요는 없다는 것을 인식해야 한다. 둘째로, 원본 기초 블록의 코드가 여전히 유효하므로, 운영 체제는 확장된 명령어들을 건너뛰어서 단순히 그 원본 코드로 폴링쓰루(falling-through)하는 옵션을 갖는다. 이는 우리가 확장된 명령어에 대해 트랩할지 하지 않을지를 결정하기 위해 확장가능한 프로세서를 소프트웨어에 남겨두는 것을 선호하는 이유이다.

"코프로세서 없이(without the coprocessor)" 실행을 계속하는 옵션을 갖는 것은 새로운, 보다 정교한 관리 알고리즘을 가능케 한다. 예를 들면, 운영 체제는, (1) 리소스를 애플리케이션에 배타적으로 할당하고 - (1a) 애플리케이션은 그것을 최대로 사용하기 위해 관찰되거나, (1b) 인간 사용자에 의해 선택됨 - ; 및/또는 (2) 인터럽트 서비스 루틴들이 그것들을 사용하지 않을 것이라고 가정하여, 또는 예측가능한 응답 시간을 보장하기 위해, 인터럽트에 대한 모든 확장자들을 사용할 수 없게 하고; 및/또는 (3) 이용가능한 슬롯들이 존재하는 만큼 많은 확장자들을 로드 및 그렇지않으면 최적화되지 않은 기초 블록들에 폴-백(fall-back)하고; 및/또는 (4) 최근에 가장 적게 사용된 알고리즘(a least-recently-used algorithm)을 사용하여 효과적으로 확장자 데이터의 캐시가 어떤 것인지를 다룰 수 있다.

본원에 기술된 특정한 구현예 이외에도, 다른 양태들 및 구현예들이 본원에 개시된 사항을 고려함으로써 당업자에게 이해될 것이다. 상세 및 설명된 구현예들은 다음의 청구항들의 정당한 사상 및 범위에서, 단지 예시로서 고려되기 위한 것이다.

Claims (27)

1. 컴퓨터 실행가능 명령어들을 저장하는 컴퓨터 판독가능 저장 매체로서,

   상기 컴퓨터 실행가능 명령어들은,

   애플리케이션의 로딩 중에 상기 애플리케이션의 기초 블록(basic block)을 처리하기 위한 프로세서 확장자 명령어(processor extension instruction)를 식별하는 단계;

   상기 프로세서 확장자 명령어로 프로세서를 확장하는 단계;

   상기 프로세서 확장자 명령어를 실행하기 위해 호출하는 상기 애플리케이션의 일부분을 교체하는 단계 - 상기 일부분은 비-트래핑 널 명령어(non-trapping null instructions)로 교체됨 - ;

   하나 이상의 프로세서 확장자 제어 레지스터들의 값을 변경함으로써 상기 프로세서 확장자 명령어를 실행하기 위해 호출하는 애플리케이션의 일부분을 무효로 하는(nullifying) 단계; 및

   둘 이상의 애플리케이션들 중 어느 애플리케이션이 상기 프로세서 확장자 명령어를 가장 많이 사용하는지 판정하고 상기 둘 이상의 애플리케이션들 중 상기 프로세서 확장자 명령어를 가장 많이 사용하는 것으로 관찰된 하나의 애플리케이션에 상기 프로세서 확장자 명령어를 배타적으로 할당함으로써, 상기 둘 이상의 애플리케이션들 사이에서 상기 프로세서 확장자 명령어를 공유하는 단계를 실행하는

   컴퓨터 판독가능 저장 매체.
2. 제1항에 있어서,

   상기 컴퓨터 실행가능 명령어들은 상기 애플리케이션과 상기 프로세서 확장자 명령어 사이의 연관(association)을 추적하는(tracking) 단계를 추가로 실행하는

   컴퓨터 판독가능 저장 매체.
3. 제2항에 있어서,

   상기 컴퓨터 실행가능 명령어들은 문맥 전환(context switch)이 수행되는 경우에 상기 프로세서가 상기 프로세서 확장자 명령어로 확장되는 것을 보장하는 단계를 추가로 실행하는

   컴퓨터 판독가능 저장 매체.
4. 제1항에 있어서,

   상기 컴퓨터 실행가능 명령어들은, 상기 프로세서를 확장하기 전에 보안 서명을 체크하는 단계를 추가로 실행하는

   컴퓨터 판독가능 저장 매체.
5. 제1항에 있어서,

   상기 컴퓨터 실행가능 명령어들은, 멀티프로세서 시스템에서 복수의 프로세서들의 확장자 슬롯들(extention slots)을 추적하는 단계 - 상기 슬롯들은 상기 프로세서 확장자 명령어와 연관됨 - 를 추가로 실행하는

   컴퓨터 판독가능 저장 매체.
6. 컴퓨터 실행가능 명령어들을 저장하는 컴퓨터 판독가능 저장 매체로서,

   상기 컴퓨터 실행가능 명령어들은,

   브랜치 명령어(branch insturction)에서 종료하는 적어도 하나의 기계 명령어들의 선형 시퀀스를 위한 실행가능 파일 이미지의 로딩 중에 상기 실행가능 파일 이미지를 검색하는 단계 - 상기 검색하는 단계는 둘 이상의 기계 명령어들의 선형 시퀀스에 대하여 포괄적 템플릿(a generic template)을 매치하는 단계를 포함하고, 상기 둘 이상의 기계 명령어들의 선형 시퀀스는 적어도 하나의 명령어 필드에서 서로 상이함 - ;

   상기 적어도 하나의 기계 명령어들의 선형 시퀀스 및 적어도 하나의 대응하는 새로운 명령어에 대한 적어도 하나의 패턴을 제공하는 정의 파일(definition file)을 판독하는 단계;

   적어도 하나의 새로운 명령어를 상기 실행가능 파일 이미지에 보충하는 단계 - 상기 적어도 하나의 새로운 명령어는 상기 적어도 하나의 기계 명령어들의 선형 시퀀스를 나타내는 프로세서 확장자 명령어가 실행되도록 함 - ; 및

   둘 이상의 애플리케이션들 중 어느 애플리케이션이 상기 프로세서 확장자 명령어를 가장 많이 사용하는지 판정하고 상기 둘 이상의 애플리케이션들 중 상기 프로세서 확장자 명령어를 가장 많이 사용하는 것으로 관찰된 하나의 애플리케이션에 상기 프로세서 확장자 명령어를 배타적으로 할당함으로써, 상기 둘 이상의 애플리케이션들 사이에서 상기 프로세서 확장자 명령어를 공유하는 단계를 실행하는

   컴퓨터 판독가능 저장 매체.
7. 제6항에 있어서,

   상기 보충하는 단계를 실행하는 명령어들은 상기 적어도 하나의 기계 명령어들의 선형 시퀀스에 제1 명령어를 덮어쓰기(overwriting)하는 단계를 실행하는

   컴퓨터 판독가능 저장 매체.
8. 제6항에 있어서,

   상기 보충하는 단계를 실행하는 명령어들은 상기 적어도 하나의 기계 명령어들의 선형 시퀀스에 제1 명령어를 덮어쓰기(overwriting)하는 단계 및 상기 적어도 하나의 기계 명령어들의 선형 시퀀스에서 적어도 하나의 후속(subsequent) 명령어를 제거하는 단계를 실행하는

   컴퓨터 판독가능 저장 매체.
9. 제6항에 있어서,

   상기 보충하는 단계를 실행하는 명령어들은 상기 적어도 하나의 기계 명령어들의 선형 시퀀스의 앞에 상기 새로운 명령어를 삽입하는 단계 및 상기 실행가능 파일 이미지에서 모든 잔여 명령어들을 앞당기는(move up) 단계를 실행하는

   컴퓨터 판독가능 저장 매체.
10. 제6항에 있어서,

    상기 보충하는 단계를 실행하는 명령어들은 상기 적어도 하나의 기계 명령어들의 선형 시퀀스에 의사-브랜치 명령어(a pseudo-branch instruction)를 추가하는 단계를 실행하는

    컴퓨터 판독가능 저장 매체.
11. 제6항에 있어서,

    상기 컴퓨터 실행가능 명령어들은 상기 적어도 하나의 기계 명령어들의 선형 시퀀스 및 적어도 하나의 대응하는 새로운 명령어를 제공하는 데이터베이스를 액세스하는 단계를 추가로 실행하는

    컴퓨터 판독가능 저장 매체.
12. 프로세서 확장자 명령어를 공유하는 방법으로서,

    애플리케이션의 로딩 중에 상기 애플리케이션의 기초 블록을 처리하기 위한 프로세서 확장자 명령어를 식별하는 단계;

    상기 프로세서 확장자 명령어로 상기 프로세서를 확장하는 단계;

    프로세서 확장자 명령어를 실행하기 위해 호출하는 애플리케이션의 일부분을 교체하는 단계 - 상기 일부분은 비-트래핑 널 명령어(non-trapping null instructions)로 교체됨 - ;

    하나 이상의 프로세서 확장자 제어 레지스터의 값을 변경함으로써 상기 프로세서 확장자 명령어를 실행하기 위해 호출하는 상기 애플리케이션의 일부분을 무효로 하는(nullifying) 단계; 및

    둘 이상의 애플리케이션들 중 어느 애플리케이션이 상기 프로세서 확장자 명령어를 가장 많이 사용하는지 판정하고 상기 프로세서 확장자 명령어를 가장 많이 사용하는 것으로 관찰된 상기 둘 이상의 애플리케이션들 중 하나에 상기 프로세서 확장자 명령어를 배타적으로 할당함으로써, 상기 둘 이상의 애플리케이션들 사이에서 상기 프로세서 확장자 명령어를 공유하는 단계를 포함하는

    프로세서 확장자 명령어 공유 방법.
13. 제12항에 있어서,

    상기 애플리케이션과 상기 프로세서 확장자 명령어 사이의 연관을 추적하는 단계를 더 포함하는

    프로세서 확장자 명령어 공유 방법.
14. 제13항에 있어서,

    문맥 전환(context switch)이 수행되는 경우에 상기 프로세서가 상기 프로세서 확장자 명령어로 확장되는 것을 보장하는(ensuring) 단계를 더 포함하는

    프로세서 확장자 명령어 공유 방법.
15. 제12항에 있어서,

    상기 프로세서를 확장하기 전에 보안 서명을 체크하는 단계를 더 포함하는

    프로세서 확장자 명령어 공유 방법.
16. 제12항에 있어서,

    멀티프로세서 시스템에서 복수의 프로세서들의 확장자 슬롯들을 추적하는 단계를 더 포함하는

    프로세서 확장자 명령어 공유 방법.
17. 삭제
18. 삭제
19. 삭제
20. 삭제
21. 삭제
22. 삭제
23. 삭제
24. 삭제
25. 삭제
26. 삭제
27. 삭제

Images