KR101150003B1 - 소프트웨어 개발 툴 생성 방법 - Google Patents

Abstract

광범위한 소프트웨어 개발 툴들을 작성하기 위한 소프트웨어 개발 아키텍처가 제공된다. 소프트웨어 개발 툴은 소프트웨어 개발 시니리오 집합에 특정된 기능을 기술하는 규격을 소프트웨어 개발 시나리오 독립형 프레임워크 내에 통합시킴으로써 생성될 수 있다. 이후, 통합된 규격을 컴파일하여 소프트웨어 개발 툴을 생성할 수 있다. 또는, 통합은 소스 코드로의 액세스없이 런타임 시에 달성될 수 있다. 소프트웨어 개발 아키텍처는 소프트웨어 시나리오 독립형 중간 표현 포맷, 복수의 프로그래밍 언어 특정 예외 핸들링 모델들을 지원할 수 있는 하나 이상의 예외 핸들링 모델, 복수의 소스 언어의 타입 표현을 나타낼 수 있는 타입 시스템, 및 복수의 실행 아키텍처를 타겟으로 하는 코드를 생성할 수 있는 코드 생성기의 임의 결합을 사용할 수 있다.

소프트웨어 개발 툴, 인프라스트럭처, 아키텍처, SDA, 중간 표현

Description

소프트웨어 개발 툴 생성 방법{SOFTWARE DEVELOPMENT INFRASTRUCTURE}

도 1은 광범위의 소프트웨어 개발 툴들을 구성하기 위한 SDA의 블럭도.

도 2a는 SDA를 이용한 소프트웨어 개발 툴 작성 방법에 대한 흐름도.

도 2b는 SDA를 이용한 소프트웨어 개발 툴 작성 방법에 대한 다른 흐름도.

도 3은 SDA를 이용한 소프트웨어 개발 툴의 컴포넌트 생성 시스템에 대한 하이레벨의 블럭도.

도 4는 도 3에 도시된 바와 같은 시스템을 이용하여 생성된 3개의 타겟 실행 아키텍처 각각에 대한 컴파일러, 디버거, 및 최적화기의 블럭 뷰.

도 5는 SDA를 이용하여 작성된 컴파일러의 예시적인 컴파일 프로세스의 블럭도.

도 6a～도 6d는 소스의 판독으로부터, 하이레벨 머신 독립형 IR～로우레벨 머신 종속형 IR로의 IR 변환을 추적하여 진행한 것을 도시하는 도면.

도 7은 여러 단계의 컴파일에서 IR을 타입 검사하기 위한 컴파일러 시스템의 일 실시예의 블럭도.

도 8은 IR과 함께 사용하기 위한 타입 검사기의 블럭도.

도 9는 표준화 예외 핸들링을 IR에 구현하기 위한 시스템을 도시하는 도면.

도 10a는 예외 핸들링 생성자를 위한 중간 표현의 표준화된 셋트를 작성하기 위해 IL 리더를 이용하는 방법을 도시하는 도면.

도 11은 복수의 IL 표현의 형태로 기술된 복수의 소스 언어 내에 예외 핸들링 생성자의 단순한 표준화된 IR을 생성하기 위한 시스템의 블럭도.

도 12는 코드 생성용 시스템의 블럭도.

도 13은 코드 생성용 소프트웨어로 구현되는 방법의 일 실시예의 흐름도.

도 14a는 코어 프레임워크를 확장하여 툴을 작성하기 위한 코어 클래스 정의를 확장하는 전체적인 프로세스를 도시하는 도면.

도 14b는 SDA 코어 프레임워크를 확장하기 위한 소프트웨어 시나리오 종속형 확장자를 이용하여 소프트웨어 개발 툴을 작성하기 위한 전체적인 프로세스를 도시하는 도면.

도 15a는 코어 컴파일러 프레임워크를 확장하기 위해 코어 컴파일러 프레임워크에 확장자를 부가하는 방안을 도시하는 도면.

도 15b는 확장자로부터 코어 컴파일러 프레임워크를 개별 파일로서 컴파일하는 방안을 도시하는 도면.

도 16은 컴파일 시간 이전에 코어 프레임워크 프로그램에 관한 클래스를 정적으로 확장하는 방법을 도시하는 도면.

도 17은 도 16의 프로세스를 구현하기 위한 예시적인 시스템을 도시하는 도면.

도 18은 런타임에서 확장자를 적절한 코어 클래스에 링크시켜 확장형 코어 프레임워크 소프트웨어 프로그램의 코어 클래스 정의를 확장하는 방법을 도시하는 도면.

도 19는 도 18의 프로세스를 구현하기 위한 예시적인 시스템을 도시하는 도면.

도 20은 컴퓨터 소프트웨어 산출물의 블럭도.

도 21은 도 20에 도시된 소프트웨어 실행의 특정예를 도시하는 블럭도.

도 22는 컴퓨터 소프트웨어 산출물의 다른 실시예를 도시하는 도면.

도 23은 기존의 소프트웨어 개발 툴을 변경하기 위한 컴퓨터 소프트웨어 산출물을 도시하는 도면.

도 24는 SDA로부터의 상호 호환형 소프트웨어 툴의 생성을 도시하는 도면.

도 25는 SDA의 일 실시예의 운영 환경으로서 기능하는 컴퓨터 시스템의 일례를 도시하는 도면.

<도면의 주요 부분에 대한 부호의 설명>

100 : SDA 코어

102 : API

104 : 원시 컴파일러

106 : Pre-JIT 컴파일러

108 : JIT 컴파일러

110 : 최적화기

112 : 결함 검출 툴

114 : 분석 툴

116 : CDK

<관련 출원 정보>

본 출원은 이하에 기재된 미국특허출원들의 부분계속(continuation-in-part)출원으로서, 이하에 기재된 미국특허출원들에 기초한 우선권을 주장하며, 이하에 기재된 미국특허출원들 전부는 본 명세서에 참조로서 포함되었다 : 발명자가 마크 로날드 플레스코(Mark Ronald Plesko)와 데이비드 리드 타르디티 주니어(David Read Tarditi, Jr.)이고, 발명의 명칭이 "컴파일 처리 시의 이종 프로그램 컴포넌트들의 일관성을 표현하고 검사하기 위한 타입 시스템(TYPE SYSTEM FOR REPRESENTING AND CHECKING CONSISTENCY OF HETEROGENEOUS PROGRAM COMPONENTS DURING THE PROCESS OF COMPILATION)"이며, 2003년 6월 27일자로 제출된 출원 제10/607,591호; 발명자가 줄리안 버거(Julian Burger)이고, 발명의 명칭이 "타겟 아키텍처 규격을 이용한 소프트웨어 개발 툴 제작(GENERATING SOFTWARE DEVELOPMENT TOOLS VIA TARGET ARCHITECTURE SPECIFICATION)"이며, 대리인참조번호가 제3382-64708호이고, 2003년 6월 30일자로 제출된 출원 제10/610,692호; 발명자가 줄리안 버거와 데이비드 리드 타르디티 주니어와 찰스 엘. 미첼(Charles L. Mitchell)과 앤드류 에드워드 아이어즈(Andrew Edward Ayers)와 비노드 케이. 그로버(Vinod K. Grover)이고, 발명의 명칭이 "확장형 컴파일러 및 툴 인프라스트럭처를 위한 기술어(DESCRIPTION LANGUAGE FOR AN EXTENSIBLE COMPILER AND TOOLS INFRASTRUCTURE)"이며, 대리인참조번호가 제3382-65690호이고, 2003년 7월 23일자로 제출된 출원 제10/626,251호; 발명자가 찰스 엘. 미첼과 줄리안 버거와 비노드 케이. 그로버와 데이비드 리드 타르디티 주니어이고, 발명의 명칭이 "소프트웨어 개발 툴을 위한 소프트웨어의 범용 중간 표현(GENERAL PURPOSE INTERMEDIATE REPRESENTATION OF SOFTWARE FOR SOFTWARE DEVELOPMENT TOOLS)"이며, 대리인참조번호가 제3382-65679호이고, 2003년 7월 22일자로 제출된 출원 제10/625,892호; 및 발명자가 비노드 케이. 그로버와 아켈라 브이.에스. 사스트리(Akella V.S. Sastry)이고, 발명의 명칭이 "다중 예외 핸들링 모델을 위한 중간 표현(AN INTERMEDIATE REPRESENTATION FOR MULTIPLE EXCEPTION HANDLING MODELS)"이며, 대리인참조번호가 제3382-65591호이고, 2003년 6월 26일자로 제출된 출원 제10/609,275호.

본 발명의 기술 분야는 소프트웨어 개발에 관한 것이며, 보다 상세히는 소프트웨어 개발 툴의 제작을 용이하게 하기 위한 아키텍처에 관한 것이다.

프로그래밍 시에 프로그래머에게 각 프로그래밍 언어마다에 특정된 이점을 제공하는 많은 수의 프로그래밍 언어들이 이용 가능하다. 마찬가지로, 각 프로세서마다에 특정된 특정 태스크를 실행하기 위한 이점을 제공하는 다수의 프로세서들이 이용 가능하다. 예를 들어, 임베디드 프로세서는 전자 장치 내에서 양호하게 정의된 태스크를 처리하는 데 특히 적절한 한편, 인텔

펜티엄

프로세서 등의 범용 프로세서는 보다 유연적이며, 복잡한 태스크를 처리할 수 있다. 또한, 프로 그래머가 소프트웨어의 신뢰도, 보안성, 및 고성능에 대한 높은 요구를 처리하는 데 도움을 주기 위해 만들어진 툴 타입(tool type)이 다양하게 존재한다. 즉, 컴퓨팅 환경, 컴퓨팅 구성, 및 컴퓨팅 장치의 다양성은 점차 확대되고 있다. 따라서, 소프트웨어 개발자는 엄청난 양의 각종 소프트웨어 개발 시나리오 내에서 적응하여 작업하는 데 직면하게 된다.

이러한 다양성을 처리하고자 하는 요구는, 이미 너무나 복잡해진 소프트웨어 개발 툴 제작 분야를 난해하게 만들어 버렸다. 소프트웨어 개발 툴들은 어셈블러, 디스어셈블러, 디코더, 인코더, 인스트럭션(instruction) 선택 컴포넌트, 인스트럭션 인증(legalization) 컴포넌트 등의 각종 컴포넌트들을 포함할 수 있다. 흔히, 이러한 컴포넌트들은 요건들이 중복되어 있고, 컴포넌트들 자체가 하나 이상의 개발 툴에서(예컨대, 컴파일러와 디버거에서) 발견되기도 한다.

유사 컴포넌트 기능에 대한 필연성이 상당함에도 불구하고, 특히 프로그래밍 언어나 기타 프로그램 표현의 범위에 걸쳐 설계 및 구현을 공유하는 툴 컴포넌트의 개발은 힘들었다. 흔히, 각 툴의 각 컴포넌트는 제각기 단독으로 구현되므로, 작업이 크게 중복되고, 코드가 이중으로 되풀이되었다. 또한, 동일한 소스 기반 내에서조차, 아키텍처 간 표준화(uniformity)가 거의 되어 있지 않은 경우도 있다. 그러므로, 하나의 컴포넌트의 코드에서 이루어지는 얼마간의 개량은 특정 구현에는 도움이 되지만, 그 개량이 동일 기능을 구현하는 다른 툴 또는 아키텍처에 자동으로 전달되지는 않는다. 결국, 특정 소프트웨어 개발 시나리오를 처리하는 데 들이는 노력은 다른 시나리오를 처리하는 데에도 되풀이될 수 밖에 없는 것이 통상적이다.

광범위의 소프트웨어 개발 툴 컴포넌트들을 작성하는 데 소프트웨어 개발 아키텍처(software development architecture : SDA)가 제공된다. 이 컴포넌트들은 하나 이상의 소스 언어로 작성된 프로그램 혹은 이진 실행 파일 등의 컴퓨터 판독 가능 입력에 대하여 사용될 수 있다. 이후, 이 컴포넌트들을 결합하여, 소프트웨어 개발 툴을 제작할 수 있다. SDA는 다양한 특징들을 포함한다. 이 다양한 특징들은 개별적?독립적으로 사용될 수도 있고, 혹은 다양한 조합 및 하위 조합으로 사용될 수도 있다.

일 특징으로, SDA는, 복수의 프로그래밍 언어 및 이진 실행 파일 등의 기타 컴퓨터 판독 가능 프로그램 포맷을 나타낼 수 있는 중간 표현(intermediate representation), 복수의 프로그래밍 언어 또는 기타 컴퓨터 판독 가능 프로그램 포맷을 지원할 수 있는 하나 이상의 예외 핸들링 모델, 및 복수의 소스 언어 또는 기타 컴퓨터 판독 가능 프로그램 포맷에 대한 타입 표현(type representation)을 나타낼 수 있는 타입 시스템을 사용한다. 또한, 중간 표현은 복수의 실행 아키텍처에 대한 이진 실행형(binary executable)을 나타낼 수 있다. 즉, 이 중간 표현을 사용하여 작성된 컴포넌트는 다양한 프로그래밍 언어로 작성된 프로그램에 적용될 수 있고, 이진 실행 파일 또는 오브젝트 파일 등의 프로그램의 컴퓨터 판독 가능 표현에 적용될 수 있고, 특정 타겟 아키텍처의 프로그램에 적용될 수 있다. 이는, 컴포넌트 공유를 허용함으로써 소프트웨어 툴 개발 비용을 절감시킨다. 이종 컴포넌트들로 구성된 프로그램들에 대한 분석 및 최적화의 개선을 용이하게 한다. 이러한 컴포넌트는 데이터플로우 분석, 컨트롤플로우 분석, 프로그램 변환, 데이터 표현 최적화, 레지스터 할당기, 및 인스트럭션 스케줄러를 포함할 수 있다.

일 특징으로, 소프트웨어 개발 시나리오에 특정된 기능을 소프트웨어 개발 시나리오에 독립된 프레임워크에 구현하기 위한 규격을 통합함으로써 소프트웨어 개발 툴의 컴포넌트를 생성하는 방법이 제공된다. 소프트웨어 개발 시나리오는 프로그래밍 언어, 타겟 실행 아키텍처, 중간 표현의 레벨 등에 관한 것일 수 있다.

다른 특징으로, 확장 버전의 중간 표현 및 공유 컴포넌트를 포함하는 소프트웨어 개발 툴을 제작하기 위한 컴퓨터 실행 가능 소프트웨어가 제공된다. 이 소프트웨어는 타겟 소프트웨어 개발 툴을 기술하는 소프트웨어에 대한 복수의 구성(configuration)들 중 하나를 선택하는 것을 허용하고; 타겟 소프트웨어 개발 툴에 특정된 데이터를 중간 표현에 편입시킬 수 있으며; 구성 및 데이터가 호환되는 타겟 소프트웨어 개발 툴을 포함하는 컴포넌트를 제작할 수 있다. 이와 같이, 컴포넌트 및 중간 표현은, 기존 툴에 대한 새로운 요건, 툴의 새로운 타입, 새로운 혹은 개량된 프로그래밍 언어, 새로운 컴퓨터 아키텍처 등의 새롭고 예측하기 어려운 상황에 사용될 수 있도록 확장될 수 있다.

상기의 특징들과 그 외의 다른 특징들은 첨부된 도면을 참조하는 이하의 상세한 설명으로부터 명백하게 될 것이다.

광범위의 소프트웨어 개발 툴들을 위한 컴포넌트들을 작성하고, 이 컴포넌트들을 연결시켜 툴을 제작하기 위한 SDA가 제공된다. SDA는, 임의의 개수의 타겟 실행 아키텍처들의 입력 코드 및 출력 코드로서 임의의 개수의 프로그래밍 언어를 취할 수 있는 각종 소프트웨어 개발 툴을 제작할 수 있다.

예시적인 타겟 실행 아키텍처

본 명세서에서 언급되는 타겟 실행 아키텍처는 각종 하드웨어 머신이나 가상 머신 중 임의의 것을 포함할 수 있다. 타겟 실행 아키텍처는 코드를 실행하기 위한 임의의 환경을 포함할 수 있다. 이러한 타겟 실행 아키텍처로는, 인텔

x86, AMD, IPF, ARM, 및 MIPS 아키텍처들 뿐만 아니라, 이하에 구현된 아키텍처를 포함한 그 외 다른 아키텍처들도 포함될 수 있다.

인텔

x86 아키텍처로는, 인텔사로부터 입수할 수 있는 80x86, 80x88, 인텔186, 인텔286, 인텔386, 인텔486, 및 펜티엄 프로세서들 등의 인텔

x86 아키텍처 기반의 임의의 프로세서가 포함되지만, 이에 한정되지는 않는다. AMD 아키텍처는, AMD(Advanced Micro Devices)사로부터 입수할 수 있는 AMD64 및 AMD32 아키텍처들을 포함하지만, 이에 한정되지는 않는다. IPF(Itanium processor family) 아키텍처는 인텔사로부터 입수할 수 있는 IA64 아키텍처를 포함하지만, 이에 한정되지는 않는다. ARM 아키텍처는 ARM사로부터 입수할 수 있는 다수의 16 및 32 비트 임베디드 RISC 마이크로프로세서들을 포함한다. MIPS 아키텍처는 MIPS 테크놀로지사로부터 입수할 수 있는 MIPS64™ 및 MIPS32™ 아키텍처들을 포함하지만, 이에 한정되지는 않는다.

예시적인 소프트웨어 개발 툴

본 명세서에서 언급되는 소프트웨어 개발 툴은 소프트웨어를 개발하는 데 유용한 각종 툴들 중 임의의 것을 포함할 수 있다. 이러한 툴로는, 원시 코드 컴파일러, JIT(Just-in-Time) 컴파일러, 디버거, 시뮬레이터, 분석 툴, 결함 검출 툴, CDK(compiler development kit), 및 최적화기가 포함될 수 있다.

이 소프트웨어 개발 툴들은 프로그램 변환 컴포넌트, 프로그램 분석 컴포넌트, 어셈블러, 디스어셈블러, 디코더, 인코더, 인스트럭션 선택 컴포넌트, 인스트럭션 인증 컴포넌트 등의 컴포넌트를 포함할 수 있다. 몇몇의 경우, 컴포넌트 그 자체가 툴로서 동작할 수 있다.

예시적인 소프트웨어 개발 시나리오

수많은 소프트웨어 개발 시나리오들 중 임의의 시나리오는 SDA의 기능에 영항을 끼칠 수 있다. 예를 들어, 특정 소프트웨어 개발 툴용의 소프트웨어 개발 시나리오는, 상기 소프트웨어 개발 툴을 타겟으로 하는 각종 타겟 실행 아키텍처(예컨대, IPF, x86, AMD, ARM 등)를 포함할 수 있다. 또한, 소프트웨어 개발 시나리오들은 수행되는 컴파일의 타입(예컨대, JIT 컴파일러 또는 원시 최적화 컴파일러)에 관련될 수 있다. 또한, 소프트웨어 개발 시나리오는, 분석, 최적화, 시뮬레이션, 디버깅, 코드 생성 등과 같이 소프트웨어 개발 툴에 의해 수행되는 그 외 다른 타입의 기능에 관련될 수도 있다. 또 다른 소프트웨어 개발 시나리오는 소프트웨어 개발 툴이 특별한 방법으로 구성될 수 있는 특정 프로그래밍 언어(예컨대, JAVA, C++, C# 등)에 관련될 수 있다. 이러한 언어들은 여러 다른 예외 핸들링 모델들을 가질 수 있다. 또한, 소프트웨어 개발 시나리오는 소프트웨어 개발 툴이 관리형(managed) 실행 환경(예컨대, 마이크로소프트 .NET 프레임워크에 의해 제공되는 마이크로소프트 CLR 환경)에 사용되어야할지의 여부에 관련될 수도 있다. 그 외 다른 시나리오도 가능하다.

SDA는 하나 이상의 임의의 소프트웨어 개발 시나리오를 취급하는 툴에 대한 컴포넌트를 생성하는 데 사용될 수 있다. 예를 들어, SDA는 복수의 프로그래밍 언어 중 임의의 하나를 수용하고, 복수의 타겟 실행 아키텍처 중 임의의 하나를 위한 코드를 생성하는 등의 동작을 할 수 있는 툴의 컴포넌트들을 생성하는 데 사용될 수 있다.

소프트웨어 개발 아키텍처

도 1은 복수의 구성 중 임의의 하나로 임의의 개수의 컴포넌트를 생성하기 위해 SDA를 이용함으로써 광범위의 소프트웨어 개발 툴들을 제작하는 기반으로 사용되는 SDA의 블럭도를 도시한다. 컴포넌트들의 집합(100)은 임의의 구성에서 사용될 수 있는 모듈을 나타낸다. 이러한 모듈은 SDA에 의해 제공되는 코어 기능을 사용하여 구축된다. SDA 코어(100)는 오브젝트 파일들의 집합이나 소스 코드로서 제공될 수 있다. SDA 코어(100)는 복수의 관리 및/또는 원시 API(application program interface)(102)를 제공한다. SDA 코어(100)와 API(102) 주변의 각 블럭은, SDA를 이용하여 구축되는, 가능한 소프트웨어 개발 툴들을 나타낸다. 이러한 툴들은 원시 컴파일러(104), Pre-JIT 컴파일러(106), JIT 컴파일러(108), 최적화 툴(110), 결함 검출 툴(112), 분석 툴(114), 및 CDK(116)를 포함할 수 있다.

원시 컴파일러(104)는 복수의 타겟 실행 아키텍처와 복수의 소스 언어에 대한 하나 이상의 원시 머신 코드의 컴파일러를 나타낸다. 예를 들어, SDA를 이용하여 구축된 원시 컴파일러(104)는 C++ 프로그래밍 언어로 작성된 프로그램을 x86 타겟 실행 아키텍처에서의 실행을 위한 원시 코드로 컴파일할 수 있다.

Pre-JIT 컴파일러(106)는, 임의의 개수의 타겟 실행 아키텍처들에서 애플리케이션을 실행시키기 전에, 마이크로소프트사의 .NET 플랫폼용의 CIL(Common Intermediate Language)과 같은 아키텍처 독립형 프로그램 표현으로부터 원시 코드를 최적화 및 생성할 수 있다. Pre-JIT 컴파일러는 설치 시에 서버에서 캐쉬와 같이 동작하거나, 로드 시에(혹은 백그라운드에서) 클라이언트에서 온더플라이(on the fly)로 동작할 수 있다. 예를 들어, SDA의 Pre-JIT 사용(106)은, CIL을 x86 타겟 실행 아키텍처에서의 실행을 위한 원시 코드로 컴파일하도록 설계된 Pre-JIT 컴파일러를 생성하는 것일 수 있다.

JIT 컴파일러(108)는 타겟 실행 아키텍처에서 CIL과 같은 아키텍처 독립형 표현으로부터 런타임(즉, just-in-time)에 필요한 코드를 컴파일할 수 있다. 예를 들어, SDA로부터 인터페이스를 이용하여 구축된 JIT 컴파일러(108)는 AMD 타겟 실행 아키텍처에서 런타임에 CIL을 원시 코드로 컴파일하도록 설계될 수 있다.

결함 검출 툴(110)은 하나 이상의 언어로 작성된 코드에서 정적으로(프로그램이 실행되기 이전에) 결함을 검출할 수 있다. 결함 검출 툴들은 임의의 개수의 타겟 실행 아키텍처 상에서 실행되도록 제작될 수 있다. 예를 들어, SDA의 결함 검출 사용(110)은, C++ 프로그래밍 언어로 작성된 코드를 입력으로서 취하여, 그 코드에서 결함을 검출하도록 설계된 결함 검출 툴을 생성하는 것일 수 있다. 결함 검출 툴은, 예컨대 x86 타겟 실행 아키텍처 상에서 실행되도록 설계될 수 있다.

분석 툴(112)은 하나 이상의 언어로 작성된 코드를 분석한다. 분석 툴은 임의의 개수의 타겟 실행 아키텍처 상에서 실행되도록 제작될 수 있다. 예를 들어, SDA의 분석 툴 사용(112)은, C# 프로그래밍 언어로 작성된 코드를 취하여, 소스 코드의 어느 모듈이나 라인이 한 특정 모듈의 변경에 의해 영향을 받을 수 있는지를 판정하도록 설계된 분석 툴을 생성하는 것일 수 있다. 이를 프로그램 슬라이싱(program slicing)이라고 하고, 대규모의 시스템을 변경할 때 유리하다.

최적화기 툴(114)은 복수의 언어들로 작성된 코드를 최적화한다. 예를 들어, SDA의 최적화 툴 사용(114)은, C++ 프로그래밍 언어로 작성된 코드를 취하여, 프로파일 데이터에 기초하여 필드의 레이아웃을 최적화하도록 설계된 최적화 툴을 생성하는 데 사용될 수 있다. 대안으로, Managed C++ 등의 임의의 마이크로소프트 .NET 언어로부터 CIL을 최적화도록 설계된 최적화 툴이 생성될 수 있다.

CDK 사용(116)은 제3자가 컴파일러를 독립적으로 개발할 수 있게 한다. CDK는 SDA의 컴포넌트들 중 일부 혹은 전부의 바이너리(binary)들, SDA의 컴포넌트들 중 일부 혹은 전부의 라이브러리들, 및 제3자가 시스템의 특정 부분을 변경할 수 있게 하는 컴포넌트들 중 일부 혹은 전부에 대한 소스 코드들을 포함할 수 있다. 예를 들어, SDA를 이용하여 구축된 CDK 툴(116)은 해당 칩 벤더가 WinCE를 사용하는 디바이스용의 컴파일러를 신속하고 효과적인 비용으로 생성할 수 있게 할 수 있다.

상술한 툴들은 SDA 코어(100)의 구성 요소들을 전부 혹은 일부를 사용한다. 또한, 상술한 툴들은 SDA 코어에 나타나 있지 않은 추가의 컴포넌트들을 포함할 수 있다. 스루풋, 풋프린트, 호스트, 타겟, 및 코드 품질(quality) 요건에 기초한 구성으로부터 페이즈(phase) 및 컴포넌트가 부가 혹은 삭제될 수 있다.

예를 들어, 원시 컴파일러(104)는 컴파일 시간 및 메모리 풋프린트에 가장 높은 비용을 책정해 두고, 가장 바람직한 코드 품질을 얻는 것을 기대한다. 따라서, 이러한 구성 툴은 보다 최적화된 코드를 갖는다. 반면, JIT 컴파일러(108)는 다소 최적화된 코드를 얻는다 할지라도 보다 고속의 컴파일 시간 및 보다 적은 메모리 풋프린트 구성을 요구한다. 따라서, 이러한 툴은 비용이 많이 드는 재구축을 회피할 수 있도록 가능한 많은 플로우 그래프, 루프 그래프, 및 SSA 그래프 등의 데이터 구조를 보유한다. 또한, 중간 표현을 거치는 패스 횟수를 최소화할 수 있다.

도 2a는 SDA를 이용한 소프트웨어 개발 툴 생성 방법에 대한 흐름도이다. 블럭(200)은 SDA에서 하나 이상의 규격이 수신되는 것을 나타낸다. 블럭(202)에서는, 규격들로부터 (예컨대, 소스 코드를 생성하고 나서, 컴파일함으로써) 소프트웨어 개발 컴포넌트들이 생성된다. 블럭(204)에서는, 상기 컴포넌트들이 SDA에 링크되어, 커스터마이즈드 소프트웨어 개발 툴이 제작된다. 대안으로는, 추가의 기능을 제공하는 커스텀 코드(custom code)가 규격에 부가되어 컴포넌트에 통합될 수 있다. 그리하여, SDA 및 컴포넌트의 조합으로부터 소프트웨어 개발 툴이 생성될 수 있다.

대안으로, 도 2b는 실행 버전의 SDA를 이용한 소프트웨어 개발 툴 생성 방법에 대한 다른 흐름도를 도시한다. 블럭(206)에서는 소프트웨어 개발 컴포넌트들이 제공되고, 블럭(208)에서는 (예컨대, 소스 코드로의 액세스없이 런타임에 동적으로) 컴포넌트들이 SDA에 링크되어, 커스터마이즈드 소프트웨어 개발 툴이 생성된다.

규격들은, 하나 이상의 소프트웨어 개발 시나리오에 특정된 기능을 구현하기 위한 정보를 기술하기에 적절한 임의의 컴퓨터 판독 가능 언어나 형식(예컨대, 오브젝트나 실행 가능 코드, 소스 코드, 혹은 커스텀 언어)으로 된 것일 수 있다.

도 3은 SDA(300)를 이용한 소프트웨어 개발 툴의 컴포넌트 생성 시스템의 하이레벨 블럭도이다. 소프트웨어 개발 시나리오의 타겟 특정 세부 정보를 기술하는 하나 이상의 규격(들)(302)이 생성된다. 예를 들어, 규격(들)(302)은 타겟 툴이 Virtual Basic, C#, CIL 등의 .NET 언어, C++ 등의 프로그래밍 언어들 중 어느 것을 입력으로서 취할 수 있는지를 나타낸다. 마찬가지로, 규격(들)(302)은 x86, AMD, MIPS, IPF 아키텍처 등의 타겟 소프트웨어 개발 툴을 위한 타겟 실행 아키텍처를 나타낸다. 또한, 규격(들)은 입력 언어의 타입 검사를 위한 규칙 집합이나, SDA 코어 데이터 구조를 확장 가능하게 구성하기 위한 클래스 확장 선언 집합 등의 기타 정보를 포함할 수 있다. 이후, 규격(들)(302)은 SDA(300)에 링크될 수 있는 소프트웨어 개발 컴포넌트(들)(304)를 생성하는 데 사용된다. 링크된 컴포넌트(들)(304)와 SDA(300)는 JIT 컴파일러, Pre-JIT 컴파일러, 원시 컴파일러, 또는 기타 소프트웨어 개발 툴과 같은 임의의 개수의 툴들(306)을 제작할 수 있도록 결합되어 사용될 수 있다. 대안으로, 타겟 소프트웨어 개발 툴(304)에 추가의 기능을 구현하기 위해서 커스텀 코드가 부가될 수 있다.

이와 같이, 하나 이상의 소프트웨어 개발 시나리오에 대해 타겟 소프트웨어 개발 툴을 커스터마이징하기 위해 간단히 타겟 특정 데이터를 공급하기만 하면, 특정 구성의 SDA와 같은 단일 소스 기반으로부터 임의의 개수의 소프트웨어 개발 툴의 컴포넌트들이 생성될 수 있다. 그러므로, 소프트웨어 개발 툴은 타겟 특정 모듈 및 타겟 비특정 모듈의 양측으로 구분된다고 생각될 수 있다. 도 4는 이러한 개념을 도시하고 있다. 도 4는 도 3에 도시된 시스템과 같은 시스템을 사용하여 구축된 3개의 타겟 실행 아키텍처 각각에 대한 JIT, Pre-JIT, 및 마이크로소프트

Visual C++

의 원시 컴파일러들, 디버거, 및 최적화기의 블럭도를 도시한다. 실행 아키텍처들의 각종 툴들이 공통 SDA 및 규격(들)로부터 구축되므로, 규격(들) 또는 커스텀 코드에 의해 제공되는 소프트웨어 개발 툴의 타겟 특정 코드는 공통 SDA에 의해 제공될 수 있는 타겟 비특정 코드로부터 구분된다. 따라서, 타겟 실행 아키텍처의 컴포넌트들은 동일한 규격(들)로부터 생성되므로 다른 타입의 소프트웨어 개발 툴에서도 동일할 수 있다.

소프트웨어 개발 툴들은, 오직 타겟 특정 컴포넌트들만이 변경될 필요가 있으므로 상이한 실행 아키텍처들 간에서 용이하게 타겟 재설정될 수 있고, 타겟 특정 코드와 타겟 비특정 코드 중 어느 하나에서 발견되는 버그는 큰 스케일로 수정될 수 있다.

예를 들어, 개발자가 인텔

x86 아키텍처용의 JIT 컴파일러(400)를 AMD 또는 MIPS 아키텍처들에서 동작시킬 수 있도록 이 JIT 컴파일러에 대해 타겟을 재설정하기를 원한다고 가정한다. 개발자는 AMD 또는 MIPS 실행 아키텍처에 특정된 데이터를 포함하는 적절한 규격을 작성하기만 하면 된다. 그러면, 타겟 특정 데이터는 인텔

x86 아키텍처용의 JIT 컴파일러(400)를 생성하는 데 사용되는 동일 또는 유사한 공통 SDA로 통합된다. 다음으로, 통합된 SDA 및 규격(들)은 AMD 아키텍처용의 JIT 컴파일러(402) 또는 MIPS 아키텍처용의 JIT 컴파일러(404)를 생성하는 데 사용된다.

이번에는, 개발자가 인텔

x86 아키텍처용으로 작성된 규격(들)을 사용하여 구성된 최적화기(406)로 소프트웨어 결함을 찾아낸다고 가정한다. 소프트웨어 결함이 타겟 비특정 코드에서 발견된다면, 이 코드는 공통 SDA의 일부일 가능성이 높다. 따라서, 이 소프트웨어 결함은 도 4에 도시된 툴들 모두에 걸쳐 나타날 수 있다.

일단, 공통 SDA를 사용하여 구축된 컴포넌트 공통 SDA 자체의 개선사항이 개발되면, 도시된 15개의 툴(3개의 다른 아키텍처 각각마다의 3개의 컴파일러 및 2개의 툴)에 대한 개선사항은 하나의 소스 코드 기반(컴포넌트 또는 공통 SDA)에서 그 변경을 구현함으로써 동시에 개시될 수 있다. 간단히, 갱신된 SDA를 사용하여 각 타겟 실행 아키텍처용의 규격(들)을 재컴파일하기만 하면, 혹은 SDA와 컴포넌트의 새로운 바이너리를 배포하기만 하면, 갱신?교정 버전의 15개의 툴이 생성될 수 있다.

마찬가지로, 소프트웨어 결함이 인텔

x86 실행 아키텍처의 최적화기(406) 의 타겟 특정 코드에서 발견된 경우, 소프트웨어 결함은 인텔

x86 실행 아키텍처용으로 작성된 규격(들)에 있을 가능성이 높다. 다시, 인텔

x86 실행 아키텍처용 툴들 전반에 걸친 소프트웨어 결함을 정정하는 것은, 하나의 소스 코드(인텔

x86 규격(들))를 정정하고, 갱신된 규격(들)을 공통 SDA를 사용하여 재컴파일하기만 하면 된다.

도 4에 도시된 소프트웨어 개발 툴들은, 다른 실행 아키텍처들에 대한 타겟 재설정을 고속으로 할 수 있는 것 외에도, 또 다른 프로그래밍 언어를 입력으로서 수용할 수 있도록 재설계하는 것도 고속으로 할 수 있다. 예를 들어, 본 예를 위해서, 디버거(408)는 C++를 입력으로서 취하며 MIPS 실행 아키텍처에 대해 타겟이 되는 것을 나타내는 규격(들)으로부터 생성되었다고 가정한다. 디버거(408)가 C#을 입력으로서 취하는 한편, MIPS 아키텍처 상에 실행되는 것을 유지하는 것으로 재설계하는 것은, 다른 입력 언어를 나타내도록 규격(들)을 재작성하는 것과 같이 간단하다. 그리고, 새로운 규격(들)은 동일 또는 유사한 SDA에 통합될 수 있고, C#을 입력으로서 취하는 새로운 디버거가 생성된다.

SDA 코어 데이터 구조 및 추상화

머신 모델 - 추상화의 타겟 재설정

본 명세서에서 설명되는 SDA를 사용하여 생성된 소프트웨어 개발 툴들에 대한 타겟 고속 재설정을 지원하기 위해, SDA 코어는 타겟 비특정부와 타겟 특정부로 분할된다. 가능한 어느 위치에서든지, 공통 타겟 특정 코드는, 정보를 획득하거나 변환을 수행하기 위한 타겟 특정 코드로의 호출을 이용하여 타겟 비특정 SDA로 분해될 수 있다. 이하의 섹션들은 단지 예로서 SDA 코어의 일 실시예에 대한 구현 상세를 설명하는 것이다. 대안이 되는 SDA 코어는, 이하의 혹은 그 외 다른 특징들의 임의의 조합을 이용할 수 있다.

레지스터

복수의 레지스터 파일을 질의(예컨대, 범용, 플로우팅 포인트, 술어)하고, 어느 머신 타입을 핸들링할 수 있는지를 판정(예컨대, int32, float64, MMX)하며, 머신 레지스터를 나타내는 오브젝트를 획득(예컨대, EAX, r0, p3)하기 위한 머신 레지스터 파일은 API를 통해 액세스될 수 있다. 레지스터 오브젝트는 레이아웃 클래스로부터 파생되어, 데이터 플로우용의 내부 열거 번호 등; 텍스트 스트링으로 된 레지스터 명; 속성; 이진 인코딩; 및 확장 가능형 오브젝트 등의 정보를 부가할 수 있다.

머신 종속형 명령코드(OPCODE)

명령코드(예컨대, ADD, MOVZX)의 수를 질의하고 명령코드를 나타내는 오브젝트를 획득하기 위한 머신 명령코드 테이블은 API를 통해 액세스될 수 있다. 명령코드 오브젝트는 내부 명령코드 열거; 텍스트 스트링으로 된 명령코드 명; 속성; 및 확장 가능형 오브젝트 등의 정보를 캡슐화할 수 있다.

호출 규정(calling convention)

호출 규정은 페이즈를 감소시킴으로써 명료하게 되도록 할 수 있고, 타겟 비특정 프레임워크에서 ABI(Application Binary Interface) 특정 콜백(callback)을 통해 구현될 수 있다. 이 프레임워크는 레지스터에 파라미터를 할당하는 것, 레지스터 피연산자(operand)를 (스택 패싱(stack passing)을 위해) 메모리 피연산자로 떨어뜨리는 것 등의 공통 동작을 위한 하위루틴을 포함할 수 있다.

복수의 호출 규정은, 호출에 사용되는 호출 규정의 타입을 기술하는 타겟 특정 속성을 가진 호출 명령어 각각에 주석(annotation)을 부가함으로써 지원될 수 있다. 이러한 속성은 하이레벨의 머신 독립형 최적화 페이즈에 의해 유지 및 전파될 수 있다.

예외 핸들링 모델

각종 EH(exception handling) 모델들은 머신 모델의 질의 및 필요한 임의의 타겟 특정 코드로의 콜백을 사용하여 타겟에 비특정되게 구현될 수 있다. 예외 핸들링은 이하의 개별 섹션에서 보다 상세히 설명될 것이다.

코드 생성

본 실시예에서, 코드 생성은 인스트럭션 선택/감축, 내장(intrinsic)/스위치(switch)/질문(question) op 확장, 및 인스트럭션 인증으로 이루어진다. 레지스터 할당 및 스케줄링은 개별 페이즈로 생각될 수 있다. 코드 생성은 이하의 개별 섹션에서 보다 상세히 설명될 것이다.

인코딩

인코딩은 컴파일러 IR을 이진 머신 코드로 번역하는 프로세스이다. 작성된 타겟 특정 코드에서 발생되는 대부분의 작업을 인코딩하기 위한 머신 비특정 프레임워크가 존재할 수 있다.

스케줄링 테이블

스케줄링 테이블은 글로벌 스케줄링 및 로컬 스케줄링에서 사용될 수 있다. 머신 스케줄링 테이블은 인스트럭션 대기 시간 및 각각의 머신 인스트럭션에 필요한 함수 유닛들을 포함할 수 있다. 이 테이블은 코드 생성에서 사용되는 타겟 재설정 툴에 의해 생성될 수 있다.

디스어셈블러

디스어셈블러는 코드 생성 파일에 의해 구동될 수 있다. 이는, 공통 인터페이스를 사용하여 링커 및 디버거에 의해 공유되는 DLL로서 구현될 수 있다.

프롤로그/에필로그

함수 프롤로그 및 에필로그는 타겟 특정 콜백을 사용하여 타겟 비특정 프레임워크에서 생성될 수 있다. 프롤로그는, 프레임 포인터 초기화; 스택 정렬; 스택 할당; 비휘발성 레지스터 내용 저장; 예외 핸들링 구조 초기화; 및 런타임 검사 및 초기화의 항목들 중 임의의 것 혹은 전부를 포함할 수 있다. 에필로그는 비휘발성 레지스터 복구; 스택 할당해제(de-allocation); 프레임 포인터 복구; 및 런타임 검사의 항목들 중 임의의 것 또는 전부를 포함할 수 있다. 함수당 2개의 프레임 포인터 즉, 로컬 포인터와 파라미터 포인터가 잠재적으로 존재할 수 있다. 이들은 머신과 함수에 종속될 수 있다.

엔디언(endian) 지원

크로스타겟팅 시나리오(cross-targeting scenario)는 SDA가 엔디안을 인식할 것을 요구한다. 규격(들)은 타겟 실행 아키텍처의 엔디안을 기술할 수 있다. 따라서, 방사(emission) 루틴은 이를 고려하여 설계될 수 있다.

스택 할당

규격(들)은 스택 정렬 및 성장 방향 정보를 포함할 수 있다. 스택 할당 패키지는 최대 요구 로컬 정렬 및 총 스택 사용 공간을 산출하는 것을 담당할 수 있다. 또한, 스택 팩킹(packing) 최적화가 사용되지 않을 경우, 스택 오프셋이 로컬로 할당될 수 있다.

타입 시스템

IR을 위한 타입 시스템은 많은 중요한 목적을 처리하며, 이하의 개별 섹션에서 보다 상세히 논의할 것이다.

함수

함수 또는 메소드 오브젝트는 단일 프로시저를 구성하는 코드를 기술할 수 있다. 이하의 속성들은 함수 오브젝트를 기술하는 데 고려될 수 있다 :

1) 함수 ID : 메소드에 대한 고유 식별자

2) 함수 명

3) 리턴 값 타입

4) 호출 규정

5) 함수 서명 또는 인수 리스트

6) 예외 정보

함수는 비연속 방식으로 레이아웃되는 규약(provision)들을 포함할 수 있다. 예외 정보, 혹은 함수의 레이아웃에 부속된 정보를 갖는 그 외 다른 임의의 데이터 구조는 그에 적절하게 변경될 수 있다.

함수가 여러 컴파일러 단계들을 통해 진행되어 감에 따라, 함수는 이후의 단계에서 중대한 대부분의 정보를 포함하는 단일 엔티티(entity)일 수 있다. 또한, 함수 오브젝트는 대부분의 변환 즉, 코드 분리, 즉시 처리(inlining), 루프 풀기(loop unrolling) 등을 지원하는 것일 수 있다. 따라서, 변환을 따라 지속적으로 움직이려는 의식적인 노력이 없다면, 각 함수에 연관된 정보는 매우 빠른 속도로 쓰이지 않게 될 수 있다.

함수 전체에 걸친 데이터플로우 분석이 성공적이기 위해서는, 전체 함수가 물리적으로는 더 이상 연속적이지 않더라도, 전체 함수를 표현할 수 있는 것이 바람직하다.

함수 및 메소드

본 실시예에서는, 함수와 메소드 간의 구별이 불필요할 수 있다. 이는 클래스 계층 구성이 도입되면 단지 용어 기술상의 차이일 뿐일 수 있다.

클래스

클래스 오브젝트는 그 클래스에 속하는 모든 함수들 또는 메소드들에 대한 컨테이너(container)일 수 있다. 아래의 속성들은 클래스 오브젝트를 기술할 수 있다 :

1) 클래스 명

2) 크기

3) 함수 리스트

4) 가상 호출 테이블을 포함하는 데이터 멤버들에 대한 타입/레이아웃 정보

본 실시예에서는 클래스 정의가 다수의 모듈들로 분리되지 않을 수 있으므로, 최적화를 위해서는 클래스 내부 표현이 재정리(reordering)될 수 있는 것이 중요하다. 이러한 클래스 재정리의 일례로는 작업 설정 감소가 함께 이루어져야 하는 것이 있는데, 이는 클래스 오브젝트에 속하는 다수의 데이터 구조가 존재한다는 것에 기인하며, 이는 클래스 내부 레이아웃에 따라야할 뿐만 아니라, 재정리될 필요가 있을 수 있다.

페이즈 제어

상술된 SDA의 구성 가능성과 확장성, 및 컴포넌트들을 결합시키기 위한 표준화된 메커니즘을 제공하려는 소망에 기인하여, 하드 코딩보다는 데이터를 통해 페이즈 제어가 제공될 수 있다. 페이즈 정리는 페이즈 오브젝트들의 리스트를 생성함으로써 구체화될 수 있다. 페이즈 리스트는 구성, 머신 타겟, 및 사용자 확장성에 의해 변경될 수 있다.

각각의 페이즈 오브젝트는 디버그 전제 조건(실행되어야 할 디버그 검사), 실행 전제 조건(페이즈의 실행을 제어하는 컴파일 플래그, 예를 들어 글로벌 최적화용 -Od 등), 프리-페이즈(pre-phase) 확장성, 페이즈 엔트리 포인트, 포스트-페이즈(post-phase) 확장성, 디버그 사후 조건(post-conditions), 텍스트로 된 페이즈 명, 및 이전 페이즈와 다음 페이즈에 대한 포인터 등을 캡슐화할 수 있다.

페이즈들 각각은, 함수가 "크다"는 것을 인식하고 적절하게 변환을 조절하는 것을 담당할 수 있다. 예를 들어, 정확성을 보증하기 위해 유지되는 함수가 n개 이상의 IR 노드를 갖는다면 간섭 패키지가 철저한 분석에 대하여 포기를 결정할 수 있다. 또는, 최적화는 전체 함수에 대하여 수행하는 것이 너무 비용이 든다고 결정하고, 그 대신에 일부만 동작하거나 또는 전부 턴 오프하는 것도 가능하다.

메인 드라이버

메인 드라이버는 SDA 및 임의의 부속된 확장성 모듈들의 초기화를 담당한다. 기동(start-up) 시, 컴파일러 구성에 따라 다양한 시스템 패키지들이 초기화될 수 있다(주로 페이즈 리스트를 셋업). 그리고, 타겟 특정 초기화가 동작될 수 있다(확장성 특성을 제공 가능). 다음에, 확장성 모듈들이 초기화될 수 있다(페이즈 리스트를 변경하여 다양한 데이터 구조에 부가 가능 등). 이 때, 커맨드 라인 프로세서가 호출될 수 있다. 마지막으로, 에러가 발생하지 않으면, 컴파일 매니저(구성에 의존할 것임)가 제어할 수 있다.

중간 표현(Intermediate Representation : IR)

본 명세서에 설명되는 툴들의 컴포넌트들을 생성하기 위한 SDA의 일 실시예에서는, 툴의 전체 실행 동안 메모리 내 사용자 프로그램을 나타내는 단일 공통 IR 포맷이 제공된다. IR 포맷은 통합된 단일 형태를 사용하여, 하이레벨의 머신 독립형 연산들로부터 로우레벨의 타겟 머신 코드까지의 코드 범위를 표현할 수 있다. 도 5는 여러 언어들을 입력으로서 취하고, 여러 언어들을 출력으로서 제공하며, 여러 실행 아키텍처들을 타겟 설정할 수 있는 SDA를 사용하여 생성된 컴파일러에서의 컴파일 프로세스 예를 나타내는 블럭도이다.

소스 코드(500～506)는 4개의 서로 다른 소스 언어로 작성되어 있다. 예를 들어, 소스 코드(500)는 C#으로 작성된 한편, 소스 코드(506)는 C++로 작성되어 있다. 또한, PE 바이너리 및 기타 실행 가능한 포맷들이 입력으로서 받아들여질 수 있다. 먼저, 소스 코드가 리더(508)에서 처리되어 시스템에 입력된다. 그리고, 소스 언어가 HIR(high-level IR)로 번역된다. 그리고, 블럭(510)에서 HIR은 선택적으로 분석 및 최적화될 수 있다. 그리고, HIR은 MIR(mid-level IR)로 번역된다. 이 표현은 HIR보다는 낮은 수준이지만, 여전히 머신 독립형이다. 이 시점에서, MIR은 블럭(512)에 도시된 바와 같이 선택적으로 분석 및 최적화될 수 있다. 그리고, 블럭(514)에서는 코드 생성에 의해 MIR이 머신 종속형의 LIR(low-level IR)로 번역된다. 그리고, LIR은 블럭(516)에서 선택적으로 분석 및 최적화될 수 있고, 블럭(518)에서 에미터(emitter)에 공급될 수 있다. 에미터는 시스템으로 입력된 본래의 소스 코드를 나타내는 여러 포맷들(520～526) 중 하나의 코드를 출력할 것이다. 이러한 프로세스를 통해, 프로세스를 완성하는 데 필요한 데이터가 소정의 형태의 영구 메모리(528)에 저장된다.

따라서, 컴파일 프로세스는 명령어들을 하나의 레벨 또는 표현으로부터 다른 레벨 또는 표현으로 변환하는 것을 포함한다. 일 실시예에서, IR을 하이레벨 연산으로부터 머신 코드로 번역하는 프로세스는 기본 형태를 전혀 변경하지 않고도 IR에 보다 많은 정보를 간단히 속성화하는 일련의 최적화 및 코드 생성 패스일 수 있다. 예를 들어, 도 6a～도 6d는 소스 판독으로부터, 하이레벨 머신 독립형 IR에서 로우레벨 머신 종속형 IR로의 IR 변환의 진행을 나타낸다. 이 도면들이 나타내듯이, IR은 레지스터들 및 실제 머신 명령코드들 등의 타겟 머신 사양에 따라 간단히 확장되고 속성화된다. 그러나, 그 형태는 실질적으로 동일하게 유지된다.

또한, IR은 다른 SDA 구성들에서 사용될 수 있도록 스케일될 수 있다. 예를 들어, JIT 컴파일러 구성은 속도 및 메모리에 제약이 있어서, SDA의 JIT 구성을 사용하여 생성되는 JIT 컴파일러에서 사용되는 IR의 형태는, 컴파일 속도를 감소시키거나 메모리 풋프린트를 증가시키는 경향이 있는 특성들을 추가하거나 또는 제거함으로써 구성될 수 있다. 이와 달리, 원시 컴파일러들을 최적화하는 하이엔드(high-end) 프로그램 전체는 리소스에 집약적이고 고품질의 코드를 요구하는 경향이 있다. 따라서, SDA의 원시 컴파일러 구성을 사용하여 생성되는 원시 컴파일러에서 사용되는 IR의 형태는, 컴파일 속도를 제한하거나 컴파일러에 이용 가능한 메모리 양을 감소시키는 경향이 있는 특성들을 추가하거나 또는 제거함으로써 구성될 수 있다.

본 실시예에서, SDA에 사용되는 IR은 연산자, 데이터플로우 소스 집합 및 데이터플로우 목적지 집합으로 표현되는 데이터플로우 연산의 선형 스트림으로서 구성되는 그래프 데이터 구조일 수 있다. 데이터플로우 정보 및 사이드 이펙트(side-effect)가 데이터플로우 집합에 명백히 포함될 수 있다. IR은 견고한 코드 생성 및 타입 검사를 가능하게 하기 위해 소스 레벨 타입 정보를 사용하여 스트롱 타이핑(strong typing)될 수 있다. 또한, IR은 프로그램을 충분히 기술하는 데 필요한 데이터플로우 및 컨트롤플로우 링크들 중 일부 또는 전부를 포함할 수 있다. 환언하면, 필요한 모든 링크가 존재하는 경우, 플로우 그래프 또는 예외 핸들링 트리/그래프 등의 다른 데이터 구조는 필요없다.

또한, 연산에서 사용되거나 정의되는 임의의 리소스는 연산 소스 또는 목적지 리스트 상에 명백히 또는 암시적으로 나타날 수 있다. 데이터플로우 분석 및 컴파일러 구성은 일반적으로 연산의 사이드 이펙트 전부를 판정하는 데 피연산자들 을 분석하기만 하면 되기 때문에 간략화될 수 있다. 따라서, 새로운 연산들은 피연산자들의 소집합을 새로운 방식으로 간단히 재결합함으로써 구현되기 때문에 추가가 용이하다.

IR은, 메모리를 명확히 하고 피연산자에 연관된 단일 "태그"를 통해 알리아스(alias) 분석을 결정하기 위한 단일 모델을 포함할 수 있다. 태그는 유지되거나, 확장 분석을 통해 보다 정확하게 될 수도 있다. 컴파일러의 모든 페이즈들은 간단히, 태그를 수용하고 연산의 사이드 이펙트에 대한 "오라클(oracle)"을 요청할 수 있다.

이하의 섹션들은 개시되는 SDA의 실시예들을 사용하기에 적절한 IR의 일 실시예에 대한 구현 상세를 설명한다.

예시적인 IR

SDA의 실시예들에 대한 예시적인 IR은 튜플(tuple)들의 타입화된(typed) 선형 스트림으로서 구현될 수 있다. 각 튜플은 입력 피연산자들의 집합(소스 리스트), 연산자, 및 출력 피연산자들의 집합(목적지 리스트)을 구비할 수 있다. 사이드 이펙트들(예컨대, 모든 사이드 이펙트들)은 실제 혹은 묵시적(implied) 레지스터 사용/정의 및 심볼 기호/정의 정보를 포함한 명령어에 대해 명백하게 될 수 있다. 인디렉션(indirection)들은 자신에 부속된 간섭 정보를 갖게 된다.

IR은 플로우 그래프와 함께 존재하거나, 플로우 그래프없이 존재할 수 있지만, 글로벌 최적화는 플로우 그래프를 필요로 할 수 있다. 또한, 예외 핸들링 영역 그래프 및 최적화 영역 그래프는 IR 정보를 증가시키는 데 사용될 수 있다. IR은 플로우 그래프와 루프 그래프를 구축하고 예외 핸들링 영역 그래프로의 맵핑을 재수립하기에 충분한 정보를 가져야 한다. 플로우 그래프(및 보다 작은 범위의 루프 및 예외 핸들링 영역 그래프들)는 거의 항상 존재할 수 있기 때문에, 이러한 설계는 이들 그래프가 코어 IR의 일부인 시스템에서와 같이 이들 그래프에 대한 용이한 액세스를 제공할 수 있다.

IR은 트리 기반의 최적화 및 SSA 기반의 최적화를 직접 지원하도록 설계될 수 있다. 이는 리프 튜플(leaf tuples)에 대해 정의 필드를 부가함으로써 행해질 수 있다. 가장 간단한 형태로는, 표현 템프(temp)들이 함께 링크되어 표현 트리를 형성할 수 있다. 이는 미리-하향된(pre-lowered) 코드에 대하여 불변일 수 있다. 이러한 표현 스레딩(expression threading)은 표현 뷰(expression view)를 사용할 필요가 없는 분석에 의해 무시될 수 있다. 변환은 이들을 올바른 상태인 채로 있게 할 수 있으며, 클린업용 표현 최적화기(expression optimizer)를 사용할 수 있다. 풀 블로운 SSA(Full blown SSA)는 동일한 정의 필드들을 사용할 수 있고, PHI 명령어 등의 특수 연산들을 포함할 수 있다. SSA 하에서, 표현 템프는 간단히 전체 SSA 그래프의 서브셋이 될 수 있다.

inline_code를 지원하기 위해, 컴파일러의 초기 페이즈들은 _asm 시퀀스의 데이터플로우 효과를 요약하는 "아웃라인(outline)" 명령어를 볼 수 있다. 실제 _asm 명령어 시퀀스는 매우 최근 단계의 하향이 시퀀스를 인라인(inline)할 때까지 사이드 리스트(side list)로서 행 오프(hang off)될 수 있다.

IR의 각종 예들은 하향 프로세스를 보여주지만, IR은 상향 프로세스에서도 사용될 수 있다. 예를 들어, 툴은 입력으로서 바이너리를 취하여, 상기 바이너리에 대한 IR을 구성할 수 있다.

피연산자

피연산자는 명령어들의 리프 노드일 수 있고, 명령어들의 소스 및 목적지 리스트 상에 나타날 수 있다. 모든 사이드 이펙트는 명령어들에 대해 명백하게 될 수 있으므로, 피연산자는 즉치(immediate), 레지스터, 메모리, 및 조건 코드(condition code)를 포함하는 일부 또는 전부의 실제 또는 잠재적인 리소스 용도들을 나타내도록 제공된다. 각 리프 노드는 그 추상 타입을 나타내는 것에 연관된 타입을 가질 수 있고, 이는 하향된 명령어들에 대한 머신 타입에 맵핑된다.

레지스터

레지스터 피연산자는 실제 물리적 레지스터 또는 가상 레지스터 중 어느 하나를 지정할 수 있다.

템프 레지스터(Temp Register)

템프 피연산자는 다음 2가지 형태 중 하나를 취할 수 있다 : 1) 표현 템포러리(temporary)(즉, temp reg)는 표현 내에서 사용되는 싱글 정의이고, 단일 사용이며, 임시적인 것일 수 있음; 또는 2) 일반 템포러리(general temporary)(즉, temp var)가 questionOps, CSEs, 스칼라 치환, 및 인덕션(induction) 변수 등에 대해 컴파일러에 의해 도입될 수 있고, 다수의 정의와 용도를 가질 수 있음.

표현 템포러리는 레지스터에만 상주할 수 있고, 기본적인 블럭 경계를 넘나들며 상주할 수는 없을 수 있다. 일반 템포러리는 레지스터 또는 메모리에 상주할 수 있고, 기본 블럭 경계를 넘나들며 상주할 수 있다. 이들 중 어느 것도 자신의 어드레스를 취하지 않는다.

물리적 레지스터

물리적 레지스터는 실제의 머신 레지스터이다. 이는 정수, 부동 소수, 멀티미디어, 벡터, 및 전용 레지스터를 포함한다.

지정 레지스터(Named Register)

지정 레지스터는 물리적 머신 레지스터에 대한 후보이거나 물리적 머신 레지스터에 할당되었던 사용자 변수일 수 있다.

메모리

메모리 피연산자는 메모리 또는 추상 메모리에 저장된 값을 나타낼 수 있다. 추상 메모리는 명백한 간섭 계산(explicit interference calculation)에 사용될 수 있다.

지정 메모리(Named Memory)

지정 메모리는 메모리에 저장되는 사용자 변수를 나타낼 수 있다.

벡터 메모리

벡터 메모리는 벡터 연산을 위한 벡터 피연산자에 사용될 수 있다.

인디렉트 메모리(Indirect Memory)

메모리 인디렉션은 임의의 타겟 머신 상에 가장 강력한 어드레스 모드를 나타낼 수 있다. 또한, 인디렉션은 간섭 정보를 포함할 수 있다.

추상 메모리

추상 메모리는 명령어에, 직접 참조가 아닌 명백한 메모리 사용/정의 사이드 이펙트(즉, 간섭 정보 등)를 주석으로 달 때 사용될 수 있다.

어드레스

어드레스 피연산자는 코드 또는 데이터의 위치를 특정할 수 있다.

유효 어드레스(Effective Address)

유효 메모리 어드레스 피연산자는 임의의 타겟 머신 상에 가장 강력한 어드레스 모드를 나타낼 수 있다.

데이터 어드레스

데이터 어드레스는 데이터를 액세스하는 데 사용되는 간단한 형태의 유효 어드레스일 수 있다.

코드 어드레스

코드 어드레스는 논로컬(non-local) 코드에 사용되는 간단한 형태의 유효 어드레스일 수 있다.

레이블(Label)

레이블은 로컬 코드에 사용되는 간단한 형태의 유효 어드레스일 수 있다.

조건 코드

IR은 조건 코드를 위한 추상 개념을 사용할 수 있다.

레지스터 집합

킬 셋트(kill set) 및 사이드 이펙트를 표현하는 데 레지스터 집합이 사용될 수 있다.

즉치

즉치 피연산자는 명령어에 나타날 수 있는 알려진 값을 특정할 수 있다. 이 값은 컴파일러에 의해 항상 알려진 것일 수 있고, 혹은 하향화, 링킹, 및 로딩 상태들을 포함하는 차후 단계에서만 결정될 수 있다.

정수형 즉치(Integer Immediate)

정수형 즉치는 가장 큰 정수 사이즈로 정규화될 수 있다.

부동형 즉치(Float Immediate)

부동형 즉치는 내부/이식(internal/poratable) 형태로 정규화될 수 있다.

심볼형 즉치(Symbolic Immediate)

심볼형 즉치는 컴파일러에 의해 계산된 또는 링커/런타임에 의해 개량될 수 있는 상수 값들을 나타내는 심볼일 수 있다.

연산(머신 독립형 명령코드)

연산은 수개의 카테고리로 나뉠 수 있다. 이들 카테고리는 아래와 같은 명백한, 가변 사이즈의, 여러 종류의 명령어들로 분류되거나 또는 분해될 수 있다:

. 산술 연산

. 오버플로우를 갖는 산술 연산

. 논리 연산

. 포인터 연산

. 구조 연산

. 오브젝트 연산

- 할당

- 호출(가상, 인스턴스)

- 필드 액세스/업데이트

. 어레이 연산

- 할당

- 판독/기입

- 바운드 검사 없는 판독/기입

- 길이 연산

. 벡터 연산

. 분기(branch) 연산

. 호출 연산

. 내장 호출 연산

. 리턴 연산

. 스위치 연산

. 예외 연산

. 타입 변환(동적/정적 캐스트)

. 타입 테스트 연산

. 보안 연산

. 스레딩 연산

. 동기 연산

. 검사 연산

- 널 포인터 검사 연산

- 바운드 검사 연산

- 타입 검사 연산

. 아웃라인 의사(pseudo) 연산

. 데이터 연산

블럭

플로우 그래프가 존재하는 경우, 특수한 블럭 의사 명령어들이 기본 블럭들의 시작 및 끝을 표시할 수 있다.

레이블

레이블은 사용자가 정의하거나 또는 컴파일러가 생성한 것일 수 있다.

프라그마(PRAGMA)

프라그마는 사용자가 정의하거나 또는 컴파일러가 생성한 것일 수 있다.

주석

주석은 사용자가 정의하거나 또는 컴파일러가 생성한 것일 수 있다. 일반적으로, 이들은 본래 컴파일러 및 JIT 컴파일러가 코드 품질을 향상시키기 위해 사용할 수 있는 추가의 의미론적(semantic) 정보를 전달할 수 있다.

리스트

리스트 IR 노드는 제어 명령어들에 의해 특정된 플로우에 링키지(linkage)를 생성하는 데 사용되는 보조 노드들일 수 있다.

분기 리스트

분기 리스트 노드가 레이블에 부속되어, 모든 도달 분기들을 나타낼 수 있다.

케이스 리스트(Case List)

케이스 리스트 노드가 스위치 연산에 부착되어 모든 케이스 값들 및 분기들을 나타낼 수 있다.

디버그 정보(라인 및 컬럼)

모든 명령어는 소스 라인 및 컬럼 정보를 나타내는 디버그 정보를 전달할 수 있다. 코드를 확장/하향시킬때 또는 최적화를 수행할 때, 이러한 정보는 디버깅 목적으로 유지될 수 있다.

타입 시스템

IR은 또한 여러 형태의 IR에서 일관성을 검사하기 위한 타입 표시를 포함할 수 있다. 특히, 타입화된 언어 및 타입화되지 않은 언어, 약하게 타입화된 언어 및 엄격하게 타입화된 언어, 및 폐기 정보 수집(garbage collection)을 갖는 언어 및 이를 갖지 않는 언어를 포함한 여러 소스의 언어들로 작성된 프로그램들을 나타내기에 적합한 타입화 중간 언어가 제공될 수 있다. 또한, 타입 검사 아키텍처가 SDA에 제공되어, 프로그램 컴포넌트 및/또는 컴파일 단계에 대한 소스 언어에 따라 서로 다른 타입 및 타입 검사 규칙들을 사용할 수 있게 한다.

예를 들어, 하이레벨 최적화기를 여러 언어들로 작성된 프로그램에 적용하는 것이 바람직할 것이다. 이 언어들은 서로 다른 원시 타입(primitive type)들 및 원시 연산(primitive operation)들을 포함할 것이다. 예를 들어, 한 언어가 복잡한 산술 타입들과 연산들을 포함하는 한편, 다른 언어는 컴퓨터 그래픽 특유의 타입들과 연산들을 포함할 수 있다. 중간 표현이 다른 타입 시스템들에 의해 파라미터화되도록 함으로써, 최적화기는 다른 원시 타입들과 연산들을 갖는 언어들에 대해 사용될 수 있다.

다른 예는, 소정의 컴포넌트들은 엄격하게 타입화된 서브셋트의 언어로 작성되고 다른 컴포넌트들은 타입 세이프(type-safe)가 아닌 풀(full) 언어로 작성된 프로그램을 포함할 수 있다. 제1 집합의 컴포넌트들에 대해 에러 검사를 보다 많이 하는 것이 바람직하다. 이는 서로 다른 컴포넌트들에 대해 서로 다른 타입 검사 규칙들을 이용함으로써 달성될 수 있다.

또 다른 예는, 컴파일 동안 타입 정보를 드롭핑(dropping)하는 것이 있다. 타입 검사기 및 컴파일러는 타입 정보가 차후 단계에 드롭핑될 수 있게 하는 한편, 정확한 정보가 보다 이전 단계들동안 유지될 수 있게 한다. 이는 컴파일의 서로 다른 단계들에 대하여 서로 다른 타입 검사와 조합하여 'unknown' 타입을 사용함으로써 달성될 수 있다.

SDA의 일 실시예에서, 복수의 타입 표현들이 타입 클래스 계층에 정의되어 여러 언어의 타입 시스템들이 타입화 IR(typed IR)에 의해 표현될 수 있다. 추상 베이스 클래스는 모든 타입들에 대해 'Phs::Type'으로서 정의될 수 있다. 베이스 클래스는 예를 들어 실제, 심볼형, 또는 미지의(또는 가변) 타입과 같은 다양한 타입들에 대한 사이즈 정보 'sizekind'를 포함할 수 있다. 베이스 클래스는 또한 타입 분류를 지정하기 위해 'typekind'를 포함할 수 있다. 또한, 타입화 IR로부터 본래 소스 코드로의 역 맵핑을 제공하기 위해 외부에서 정의되는 타입을 덮어 씌우는 추상 타입으로서 외부 타입이 제공될 수 있다.

베이스 클래스 아래에는, "Phx::PtrType'로서 정의되는 클래스가 포인터 타입들을 나타낼 수 있다. 예를 들어, 폐기 정보 수집의 관리형 포인터(폐기 수집된 오브젝트들 내의 위치를 지정함), 비 폐기 정보 수집의(non-garbage collected) 관리형 포인터(폐기 수집되지 않은 오브젝트 내의 위치를 지정함), 비관리형 포인터(예를 들어, C++로 작성된 코드에서 발견되는 것 등), 참조 포인터(폐기 수집된 오브젝트의 베이스를 지정함), 및 널 등이 있다.

계층의 동일 레벨에서, 'Phx::ContainerType'이라고 정의되는 클래스는 내부 멤버들을 포함하는 타입들 등 컨테이너 타입들을 나타낼 수 있다. 내부 멤버는 필드, 메소드, 및 기타 타입들을 포함할 수 있다. 'Phx::FuncType'이라고 정의되는 클래스는 임의의 필요한 호출 규정, 인수 리스트, 및 리턴 타입 리스트를 포함하는 함수 타입들을 나타낼 수 있다. 또한, 'Phx::UnmgdArrayType'이라고 정의되는 클래스는 비관리형 어레이 타입들을 나타낼 수 있다. 계층에서 'Phx::ContainerType' 아래에, 4개의 클래스가 더욱 정의될 수 있다. 'Phx::ClassType'이라고 정의되는 클래스는 클래스 타입들을 나타낼 수 있고, 'Phx::StructType'이라고 정의되는 클래스는 스트럭트(struct) 타입들을 나타낼 수 있고, 'Phx::InterfaceTpye'이라고 정의되는 클래스는 인터페이스 타입들을 나타낼 수 있으며, 'Phx::EnumType'이라고 정의되는 클래스는 열거 타입들을 나타낼 수 있다. 계층에서 'Phx::ClassType' 아래에, 'Phx::MgdArrayType'이라고 정의되는 추가의 클래스는 관리형 어레이 타입들을 나타낼 수 있다.

'primtype' 클래스는 스트럭트 타입의 특정한 인스턴스로서 정의될 수 있다. 'primtype'은 int, float, unknown, void, condition code, unsigned int, xint 등의 여러 타입들을 포함할 수 있다. 이 표현들은 타입화 IR의 HIR과 LIR 모두에서 사용될 수 있다.

또한, 타겟 특정 원시 타입들이 타입 표현에 포함될 수 있다. 몇몇 언어들은 타입 시스템이 알게 되면 효과적으로 핸들링될 수 있는 복잡한 산술 타입들을 가진다. 예를 들어, 'MMX' 명령어를 살펴보자. 이러한 명령어는 일부 버전의 x86 프로세서에서 구현되어 통신 데이터 타입 및 멀티미디어에 관한 단일 명령어/복수 데이터 연산을 지원하는 외부 명령어 집합 중 하나이다. 타입 시스템은 타입 표현들의 변경을 최소로 하며 이들 명령어를 인식하고 사용하도록 커스터마이즈될 수 있다.

상술된 타입 표현의 실시예는 또한 "unknown" 타입을 포함할 수 있고, 이는 임의의 타입을 나타낼 수 있으며 선택적으로 이와 연관된 사이즈를 갖는다. 사이즈는 값에 대한 머신 표현의 사이즈일 수 있다. 'unknown' 타입은 타입 정보를 특정 타입으로부터 'unknown' 타입으로 변경함으로써 제어되는 방식으로 컴파일러가 타입 정보를 드롭핑할 수 있게 한다. 이는 타입이 알려지지 않은 경우에도 조작되는 값의 사이즈에 의존하는 코드를 컴파일러가 생성할 수 있게 한다. 다른 타입들도 'unknown' 타입들을 사용할 수 있고, 'unknown' 타입은 또한 타입 정보 일부(모든 정보가 아닌 일부의 정보가 알려진 경우)의 표현을 가능하게 한다.

예를 들어, 포인터가 'int' 타입이라고 가정하자. 하향화의 어느 단계에서는, 타입 정보 'int'를 드롭핑하는 것이 바람직할 수 있다. 'unknown' 타입은 컴파일러가 'int' 타입을 'unkonwn' 타입으로 대체할 수 있게 한다. 그리고, 타입 검사기는 관심 포인터가 올바른 타입을 지적하고 있는지를 검사할 필요가 없다. 이는 본질적으로 지적된 값이 런타임 시 프로그램 기능에 역으로 영향을 주지 않는 방식으로 넘겨지는 기회를 취한다.

'unknown type'을 사용하는 다른 예는 함수에 대한 타입을 정의하기 위한 것이다. 'unknown'에 대한 타입 포인터의 인수를 갖는 함수가 호출되면, 인수가 미리 'int'에 대한 타입 포인터를 갖는 경우, 컴파일러는 올바른 타입이 전달된 것으로 신뢰할 것이다. 포인터를 참조하지 않는 것(dereferencing)의 결과는 'int'에 알려지거나 또는 알려지지 않을 수 있지만; 'int'로서 사용될 것이다. 보다 복잡한 예로는 가상 함수 호출의 하이레벨로부터 로우레벨 중간 표현으로의 변환 동안 중간 템포러리 변수를 도입하는 것이다. 객체 지향 언어들에서 가상 호출을 구현하기 위해서 가상 테이블('vtable'이라고도 함)이 널리 사용된다. 로우레벨 중간 표현에서 가상 함수 호출을 이루는 제1 단계는 메모리 오브젝트의 제1 필드를 패치하는 것이다. 제1 필드는 vtable에 대한 포인터를 포함한다. 이러한 패치의 결과는 템포러리 변수에 할당된다. 템포러리 변수의 타입(vtable에 대한 포인터를 나타내는 타입으로, vtable은 다수의 필드를 가질 수 있음)을 구성하는 것은 표현하기에 복잡하고 부담되는 일일 수 있다. 그 대신, 컴파일러는 중간 템포러리 변수를 "pointer to unknown"으로 단순히 할당할 수 있다. 따라서, 'unknown' 타입의 사용은 상세한 타입 정보를 유지하는 것이 불필요하거나 또는 컴파일러 구현자에게 상당한 부담이 되는 컴파일의 후반 단계들을 간략하게 한다.

도 7은 컴파일의 여러 단계에서 IR의 타입을 검사하고, 이에 따라, 하향화의 여러 레벨에서 타입화 IR의 타입을 검사하기 위한 컴파일러 시스템의 일 실시예를 나타낸다. 소스 코드(700)는 다양한 소스 언어들 중 임의의 하나를 나타낸다. 소스 코드(700)는 타입화 IR(702)의 HIR로 번역된다. 이렇게 함에 있어, 소스 언어의 타입 표현들은 타입화 IR 내부로의 타입 표현들로 번역된다.

HIR은 컴파일 프로세스 전반에 걸쳐 하향화된다. 이러한 것을 나타내기 위해, 하이(HIR; 702), 미드(MIR; 704) 및 로우(LIR; 706) 레벨 표현들이 도시된다. 그러나, 본 실시예는 이에 한정되지 않는다. 임의의 개수의 컴파일 단계가 타입 검사될 수 있다.

각 레벨 표현에서의 IR은 타입 검사기(708)에 의해 타입이 검사될 수 있다. 타입 검사기(708)는 하나 이상의 규칙 집합(710)을 컴파일 프로세스의 각 단계에 적용하고, 이에 따라 IR의 각 표현에 적용하기 위한 알고리즘 또는 프로시저를 구현한다. 규칙 집합(710)은 소스 언어, 컴파일 단계, 타입 강도 등 여러 특성들에 기초하여 선택된다.

예를 들어, 소스 코드(700)가 C++ 프로그래밍 언어로 작성된 코드를 포함한다고 가정하자. C++ 소스 코드(700)는 먼저 타입화 IR의 HIR(702)로 번역된다. 원한다면, 이 시점에, 임의의 개수의 특성들을 결정하기 위해 타입 검사기(708)가 HIR(702)와 상호작용할 수 있다. 이러한 특성들은 컴파일 단계(HIR), 현재 소스 코드의 타입(C++), 언어가 타입화되었는지의 여부(되었음), 느슨하게 타입화되었는지 혹은 엄격하게 타입화되었는지의 여부(느슨하게) 등을 포함할 수 있다. 이러한 특성들에 기초하여, 타입 검사기는 적절한 집합의 규칙들을 선택할 수 있다. 규칙 집합이 선택되면, 타입 검사기는 그 집합의 규칙들에 따라 HIR을 타입 검사한다. 일단 HIR이 MIR로 또는 LIR로 하향화되면, 특성들이 다시 액세스될 것이고, 동일하거나 다른 집합의 규칙들이 적절하게 될 수 있다.

일 실시예에서는, 3 집합의 타입 검사 규칙들이 타입 검사기에 공급된다. 그 중 한 집합은 C# 또는 CIL에 바람직한 "엄격한(strong)" 타입 검사에 대응할 수 있다. 다른 집합은 "엄격한" 타입 검사에 비하여 보다 느슨한 타입 검사인 "약한(weak)" 타입 검사에 대응할 수 있다. 예를 들어, "약한" 타입 검사 규칙 집합은 타입 캐스트(type cast)를 허용할 수 있다. 타입 캐스트는 일 타입의 변수가 단일 용도의 다른 것과 같이 작용하도록 한다. 예를 들어, 'int' 타입의 변수가 'char'(character)처럼 작용하도록 될 수 있다. 이하의 코드는 문자 'P'를 인쇄하기 위한 타입 캐스트를 사용한다.

int a;

a = 80;

cout << (char) a;

따라서, 'a'가 'int' 타입으로서 정의되고 그 값에 '80'이 할당되더라도, 'cout' 구문은 타입 캐스트로 인하여 'a'를 'char' 타입으로서 취급할 것이고, '80'이 아니라 'P'(ASCII값 80)를 표시할 것이다.

마지막으로, 집합은 "표현(representation)" 검사에 대응할 수 있다. "표현" 검사는 'unknown' 타입을 사용함으로써와 같이 중간 프로그램 표현의 일부에서 드롭핑된 타입 정보를 허용할 수 있으며, 이러한 타입 정보가 언제 드롭핑될 수 있는가 또는 'unknown' 타입 정보가 언제 다른 타입 정보로 대체될 수 있는가를 나타내는 규칙들을 포함할 수 있다. 예를 들어, 'Void' 타입의 값을 리턴하는 함수의 결과는 'unknown' 타입의 변수에 할당되는 것이 금지될 수 있다.

또한, 컴파일의 단일 단계에서 하나 이상 집합의 규칙들이 사용될 수 있다. 예를 들어, 소스 코드(700)가 단일 언어를 포함하지만, 엄격하게 타입화된 섹션들 및 느슨하게 타입화된 섹션들을 포함한다고 가정하자. 타입 검사기는 엄격하게 타입화된 소정의 섹션에서 일 집합의 HIR용 규칙들을 사용하고, 느슨하게 타입화된 코드 섹션에 대해서는 다른 집합의 규칙들을 사용할 수 있다.

도 8은 본 명세서에서 설명되는 IR과 함께 사용하기 위한 타입 검사기의 블럭도이다. 타입 검사기(800)는 서로 다른 소스 언어들 및/또는 서로 다른 컴파일 단계들에 대응하는 임의의 개수의 규칙 집합들을 입력으로서 받아들일 수 있다. 도 8에는, 4개의 규칙 집합들(802～808)이 타입 검사기(800)에 제공된다. 규칙 집합 802는 엄격한(strong) 타이핑을 갖는 언어들에 대한 HIR용 규칙 집합을 나타내고, 규칙 집합 804는 약한(weak) 타이핑을 갖는 언어들에 대한 HIR용 규칙 집합을 나타내고, 규칙 집합 806은 어떤 타이핑도 갖지 않는(즉, 'no') 언어들에 대한 HIR용 규칙 집합을 나타내며, 규칙 집합 808은 LIR용 규칙 집합을 나타낸다. 프로그램 모듈(810)은 엄격한 타이핑을 갖는 언어를 HIR로 나타내고, 프로그램 모듈(812)은 LIR로 하향화된 이후의 프로그램 모듈(810)을 나타낸다.

타입 검사기(800)는 타입 검사되는 프로그램 모듈의 특성들에 기초하여 적절한 규칙 집합을 선택하고, 통합 프로시저 또는 알고리즘을 사용하여 상기 선택된 규칙 집합을 프로그램 모듈에 적용한다. 예를 들어, 타입 검사기(800)는 프로그램 모듈(810)(엄격한 타이핑을 갖는 언어를 HIR로 나타냄)을 타입 검사하기 위해 규칙 집합(802)(엄격한 타이핑을 갖는 언어들에 대한 HIR용 규칙 집합을 나타냄)을 선택할 수 있다. 후속하여, 타입 검사기(800)는 프로그램 모듈(812)(엄격한 타이핑을 갖는 언어를 LIR로 나타냄)을 타입 검사하기 위해 규칙 집합(808)(LIR에 대한 규칙 집합을 나타냄)을 선택할 수 있다.

상술된 타입 검사 시스템의 규칙 집합들은 전부 새로운 언어들로, 또한 기존 언어들의 새로운 특징들로 용이하게 확장된다. 예를 들어, 새로운 언어가 도입되면, 새로운 규칙 집합이 그 새로운 언어에 대하여 간단하게 작성된다. 규칙 집합들은 타입 검사기 또는 컴파일러 시스템 자체와는 별도이고, 규칙 집합들을 별도의 엔티티들로서 받아들이도록 설계되기 때문에, 새로운 언어에 대한 새로운 규칙 집합들은 기존 타입 검사 시스템 또는 컴파일러를 재배포하거나 업데이트할 필요없이 배포될 수 있다. 이와 마찬가지로, 예를 들어 C++에 XML 지원을 부가하는 등 기존 언어에 새로운 특징이 부가된다면, 컴파일의 여러 단계에서 C++에 대응하는 규칙 집합이 용이하게 재구성되어 새로운 특징들을 동적으로 핸들링할 수 있다. 다시, 새로운 코어 시스템이 업데이트 되거나 배포될 필요가 없다.

또한, 규칙 집합들은 타입들에 관한 제약조건들을 허용한다. 예를 들어, 다른 것으로부터의 클래스 상속이 규칙에서 설명된 제약조건일 때 특정 타입에 대한 서브-타이핑(sub-typing)이 허용되는지 여부 등이 있다. 다른 제약조건은 데이터가 데이터를 포함하는 가상 테이블로 변환될 수 있다는 것을 나타내기를 원하는 등의, 박스로 처리된(boxed) 제약조건일 수 있다. 그 외에는 사이즈 제약 조건, 또는 원시 타입과 동일한 타입들이 필요함을 나타내는 원시 타입 제약조건을 포함할 것이다. 규칙 집합의 임의의 다른 부분과 같이, 새로운 제약조건들이 원하는대로 부가될 수 있다.

타입 검사기가 사용하는 규칙 집합은 규칙 집합을 작성하기 위한 애플리케이션으로의 프로그래밍 인터페이스를 통해 작성될 수 있다. 애플리케이션은 규칙 집합이 타입화 IR의 개별 명령어들에 할당되는 규칙들을 갖는 원시 타입의 계층으로 표현될 수 있도록 규칙들을 작성할 수 있다. 계층은 특정 프로그램 모듈 또는 컴파일 유닛과 관련되는 타입들의 여러 구성 요소들을 명백히 드러내는 타입 그래프의 형태로 제공될 수 있다. 심볼 및 연산 등 IR 요소들이 타입 시스템의 요소들과 연관이 있을 것이다. 타입 그래프 노드는 원시 타입과 작성된 타입을 기술할 것이고, 또한 컴포넌트, 네스트된 타입(nested types), 함수 서명, 인터페이스 타입, 계층의 구성 요소 등 그들의 관계 및 소스 명과 모듈/어셈블리 외부 타입 구성 요소에 대한 참조 등 기타 정보를 기술할 것이다.

예외 핸들링

SDA와 함께 사용될 수 있도록 본 명세서에서 설명되는 IR은 C++, 마이크로소프트 CLR, 및 마이크로소프트 윈도우의 SEH(Structured Exception Handling) 등 각종 언어 특정 예외 핸들링 모델들을 지원할 수 있다.

도 9는 컴파일러 백 엔드(940)에 의해 다수의 소스 언어들(905～908)에 대하여 IR(930)에서의 표준화 예외 핸들링을 구현하는 시스템(900)을 도시한다. 도 9에 도시된 바와 같이, 시스템(900)은 다수의 소스 코드 표현들(905～908) 각각에 대하여 IL(Intermediate Language) 표현(910～913)을 포함하고, 이는 상기 다수의 IL 표현(910～913)을 단일 IR(930)로 번역하는 IL 리더(920)에 의해 파싱되거나 판독된다. IL 표현은 IR(930)보다 하이레벨인 중간 표현이고, CIL(마이크로소프트 CLR)(C#, Visual Basic, JScript, C, 및 FORTRAN인 경우), C++ IL(C++인 경우) 등의 임의의 개수의 공지된 중간 언어들로 표현될 수 있다. 다수 언어들에 대한 표준화 예외 핸들링 프레임워크를 생성하기 위한 시스템(900)이 다수의 소스 언어들에 대하여 단일 IL 리더 프로세스를 갖는 것으로 도시되어 있지만, 리더들 각각은 IL 표현들(910～913) 중 하나 이상에 대응하는 다수의 리더를 구현할 수 있다.

도 10a는 IL 리더(920)를 사용하여 복수의 서로 다른 소스 언어들로 기술된 예외 핸들링 구성용 중간 표현들의 표준화 집합을 생성하는 일반적인 전체 방법(1000)을 나타낸다. 단계 1010에서, 소프트웨어의 중간 언어 표현(예컨대, 소스 코드 파일의 중간 언어 표현)을 리더(920)가 수신하고, 단계 1015에서, 파일이 판독되거나 파싱되어 IL 코드 스트림(1020) 내에서 예외 핸들링 구성을 식별한다. 그리고, 단계 1030에서, 리더(920)(가상 머신으로 생각될 수도 있음)는 단계 1020에서 사전에 식별된 예외 핸들링 구성의 표준화된 단일 IR을 생성한다. 이러한 예외 핸들링 프레임워크는 코드 최적화 및 코드 생성 등 컴파일러 백 엔드의 프로세스들을 간략화하도록 사용될 수 있다.

예외 핸들링 구성을 갖는 소프트웨어의 표준화 IR은 소프트웨어의 예외 핸들링 제어를 명백하게 표현할 수 있다. 도 10b는 소프트웨어의 표준화 IR로부터 실행할 수 있는 것(executable)을 생성하는 방법(1050)을 도시한다. 이 방법은 예를 들어 소프트웨어에 대한 실행 가능한 버전(예컨대, 머신 특정 코드 또는 기타 오브젝트 코드)을 생성할 때 컴파일러 또는 기타 소프트웨어 개발 툴에 의해 사용될 수 있다.

단계 1060에서, 표준화 IR이 판독된다(예를 들어, 컴파일러 또는 기타 소프트웨어 개발 툴에 의함). 예를 들어, 도 10a의 방법에 의해 생성된 표준화 IR이 사용될 수 있다. 표준화 중간 표현에 대한 기타 변환, 번역, 또는 최적화가 원하는 바에 따라 수행될 수 있다.

단계 1070에서, 소프트웨어의 컴퓨터 실행 가능 버전이 생성된다(예를 들어, 컴파일러 또는 기타 소프트웨어 개발 툴에 의함). 소프트웨어의 컴퓨터 실행 가능 버전은 표준화 IR에 기초하여 소프트웨어의 예외 핸들링 제어 흐름을 구현한다.

도 11은 다수의 IL 표현들 형태로 표현된 다수의 소스 언어들 내에서 예외 핸들링 구성의 간단한 표준화 IR을 생성하는 시스템의 다른 실시예를 나타낸다. 도 11에 도시된 바와 같이, 먼저, 마이크로소프트의 .NET 프레임워크 내에서 지원되는 소스 언어 그룹(1110)(예컨대, C#, C, Microsoft Visual Basic, Jscript, 및 FORTRAN)이 CIL 표현(1140)으로 번역된다. 그러나, 다른 소스 언어들과의 차이점으로 인해 C++은 CIL(1130)으로 알려진 다른 중간 언어로 표현된다. C++ IL 및 CIL 내에서의 컨트롤플로우 및 예외 핸들링 모델들은 기본적으로 다른 방식으로 기술되고, 따라서 C++ IL 및 CIL 표현들에 대한 별도의 IL 리더들(1135 및 1145)을 제공할 필요가 있을 수 있다.

리더들(1135 및 1145) 양자가 그들 각각의 리더 내에 구현되는 적절한 알고리즘을 사용해서 그들 각각의 중간 언어 코드 스트림들을 파싱 또는 판독하여, 백 엔드(1160)에 제공될 예외 핸들링 명령어들(1150)의 표준화 프레임워크를 사용해서 중간 언어 코드 스트림 내에서 예외 핸들링 구성들 또는 명령어들 또는 표현들을 표현한다.

코드 생성

SDA를 사용해서 임의의 개수의 실행 아키텍처들을 위한 소프트웨어 개발 툴을 생성하기 위해, SDA는 공통 IR로부터 임의의 개수의 머신 종속형 표현들을 생성할 수 있는 코드 생성기를 포함할 수 있다. 이러한 코드 생성용 시스템의 실시예가 도 12에 도시된다. 본 실시예에서, 타겟 특정 데이터를 갖는 타겟 실행 아키텍처 사양(1200)이 타겟 재설정 툴(1202)에 공급된다. 대안으로, 규격(1200) 및 타겟 비특정 데이터를 갖는 제2 규격(1204) 양자가 타겟 재설정 툴(1202)에 공급될 수 있다.

타겟 재설정 툴(1202)은 하나 이상의 코드 생성 컴포넌트들에 관련된 데이터에 대한 규격(들)(1200/1204)을 파싱한다. 규격(들)(1200/1204)의 데이터에 기초하여, 타겟 재설정 툴은 하나 이상의 컴포넌트들을 생성한다. 각 컴포넌트는 코드 생성 컴포넌트들을 생성하는 데이터를 제공한다.

예를 들어, 도 12의 실시예에서, (예컨대, lex 포맷에서의) 토큰화 문법(tokenization grammar)(1206) 및 (예컨대, yacc 포맷에서의) 파서 문법(1208), 및 일련의 C 소스와 헤더 파일들(1210)이 생성된다.

lex를 사용하는 예에서, 토큰화 문법(1206)은 소스 코드 생성용 lex 컴파일러(1212) 및 컴파일러의 어휘 분석 컴포넌트를 생성할 필요가 있는 헤더 파일들(1214)에 제공된다. lex는 컴파일러의 어휘 분석 컴포넌트를 생성하기 위해 특별히 설계된 언어이다.

yacc를 사용하는 예에서, 파서 문법(1208)은 소스 코드 생성용 yacc 컴파일러(1216) 및 컴파일러의 구문 분석 컴포넌트를 생성하기 위해 필요한 헤더 파일들(1214)에 제공된다. yacc는 소스 코드 입력의 스트럭처들을 특정하는 범용 툴을 제공하고, 이러한 각 스트럭처로서 호출될 코드가 인식된다.

소프트웨어 개발 툴 구축을 위해 필요한 컴포넌트들을 생성하는 것을 궁극적으로 담당하는 소스 코드는, 타겟 재설정 툴에 의해 생성된 일련의 C 소스 및 헤더 파일들(1210/1214)을 SDA의 구성 내에 포함되는 공통 프레임워크(1218)와 통합함으로써 생성된다. 예를 들어, 일련의 C 소스 및 헤더 파일들(1214)과 공통 프레임워크 소스 코드 및 헤더 파일들(1218)의 통합을 컴파일함으로써 어휘 및 구문 분석 컴포넌트들이 생성된다. 이와 마찬가지로, 일련의 C 소스 및 헤더 파일들(1210)과 공통 프레임워크 소스 코드 및 헤더 파일들(1218)의 통합을 컴파일함으로써 기타 소프트웨어 개발 툴 컴포넌트들이 생성될 수 있다.

따라서, C 소스 및 헤더 파일들(1210/1214)와 공통 프레임워크 소스 코드 및 헤더 파일들(1218)의 통합을 나타내는 소스 코드(1220)가 컴파일러(1222)에 제공되어, SDA 내에서 공통 프레임워크에 따르는 규격(1200)에서 설명된 타겟 실행 아키텍처를 지향하는 컴파일러(1224)를 생성한다.

상술한 바와 같이, 소프트웨어 개발 툴 컴포넌트들은 인증 테이블(legalization table)들을 포함한다. 이 테이블들은 특정 형태의 타겟 명령어를 식별하기에 충분한 정보를 포함한다. 인증 프레임워크는 명령어 선택, 명령어 인증, 인코딩, 및 컴포넌트 열거에 의해 사용되는 형식 인덱스(form index)를 제공할 수 있다.

도 13은 본 명세서에 설명되는 기술들에 사용하기 적합한 코드 생성용 소프트웨어로 구현되는 방법의 일 실시예의 순서도이다. 블럭(1302)에서는, 타겟 실행 아키텍처 규격이 처리되어, 소스 코드로 표현되는 복수의 컴포넌트들이 생성된다. 블럭(1304)에서, 소스 컴포넌트들은 소스 코드로 표현되는 프레임워크에 통합된다. 프레임워크는 SDA 코어에 의해 제공되거나 또는 SDA 코어에 포함될 수 있다. 원한다면, 블럭(1306)에서 커스텀 코드가 포함될 수 있다. 이후에, 블럭(1308)에서 통합 소스 코드가 컴파일되어 코드 생성 컴포넌트로부터 소프트웨어 개발 툴이 생성된다.

코어 데이터 구조 확장

SDA의 다른 실시예에서는, 확장자 필드가 SDA의 구성이 구축되는 소프트웨어 개발 시나리오, 또는 타겟 소프트웨어 개발 툴의 바람직한 개별 특성에 따른 임의 다른 인자에 종속될 수 있는 SDA 코어 데이터 구조를 확장 가능하게 구성하기 위한 방법 및 시스템이 제공된다. 도 14a는 코어 프레임워크를 확장하여 툴을 작성하기 위해 코어 클래스 정의를 확장하는 전체 프로세스를 나타낸다. 먼저, 확장자를 나타내는 데이터를 만나면(블럭(1402)), 소프트웨어 개발 툴의 클래스를 그 확장자에 의해 나타낸 것으로서 확장시킨다(블럭(1404)).

도 14b는 SDA 코어 프레임워크를 확장하는 소프트웨어 시나리오 종속성 확장자를 사용하여 소프트웨어 개발 툴을 생성하는 전체 프로세스를 기술한다. 블럭(1410)에서는, 단순화된 오브젝트 정의 언어(object definition language : ODL)를 사용하여 코어 클래스를 정의할 수 있다. 이어서, 블럭(1420)에서는, 소프트웨어 개발 시나리오와 같은 임의의 여러 인자에 기초하여 특정 SDA에 대한 구성을 결정할 수 있다. 소프트웨어 개발 시나리오는 작성 중인 소프트웨어 개발 툴의 타입, 타겟 실행 아키텍처, 타겟 입력 언어 등을 나타낼 수 있다. 이후, 고려되는 인자들 전부 또는 일부에 기초하여, 블럭(1430)에서 오브젝트 기술 언어를 사용하여 확장자를 정의함으로써, 코어 클래스를 확장하는 데 필요한 추가 또는 상이한 클래스 멤버들을 표현할 수 있다.

블럭(1440)에서는, 확장자를 코어 클래스에 연계시켜 코어 클래스 정의를 적절하게 확장시킬 수 있다. 오브젝트 기술 언어의 구문은 코어 클래스를 확장 가능한 것으로서, 또는 확장 가능하지 않은 것으로서 정의하고, 또한 특정의 확장자 클래스 멤버 집합들을 선택된 코어 클래스의 확장자로서 연관시키도록 제공되어야 한다. 또한, 프리-프로세서 번역 프로그램을 사용하여 데이터 또는 오브젝트 기술 언어를 프로그래밍 언어로 번역할 수 있다. 이러한 사전-처리 후에, 블럭(1450)에서, 확장된 클래스 정의가 더 컴파일되고 코어 프레임워크를 확장하여 특정 구성의 다른 소프트웨어 개발 툴을 구현하도록 이용될 수 있다.

상술된 프로세스를 사용함으로써, 서로 다른 다수의 확장자 정의를 개별적으로 제공할 수 있어, 각각의 확장자는 임의 복잡한 상속 관계들을 유지할 필요없이도 코어 또는 기본 클래스를 필요에 따라 간단히 확장시킬 수 있다. 특정의 코어 클래스 확장자를 제공하는 프로그래머들은 다른 코어 클래스의 확장자를 알 필요가 없다. 이는 확장자를 정의하는 작업을 단순화시킬 뿐 아니라, 확장된 코어 클래스를 이용하려는 사용자들도 오직 코어 클래스명만을 알고서도 확장된 코어 클래스를 이용할 수 있다. 따라서, 프로그래머들은 확장된 클래스 정의를 사용할 때 클래스 정의들 간에서의 복잡한 계층 구조적 관계를 기억하는 작업으로부터 자유로울 수 있다.

코어 프레임워크 프로그램을 확장시키기 위한 한 가지 해결 방안은, 코어 프로그램의 소스 코드 파일로의 액세스를 획득하고 오브젝트 기술 언어를 사용하여 확장자들을 정의함으로써 코어 클래스를 필요에 따라 정적으로 확장시킨 후, 그 확장자들이 코어 클래스에 자동적으로 삽입되도록 처리하여 확장된 클래스들을 생성하는 것일 수 있다. 이와는 다르게, 소스 코드에 확장자들을 소스 코드 언어로 직접 수동으로 부가하여 확장된 클래스들을 생성할 수 있다. 도 15a는 이와 같은 해결 방안을 도시한 것으로, 코어 프레임워크 파일(1510)에 확장자(1520, 1530, 및 1540)를 부가하여 코어 프레임워크 파일(1510)을 확장시킨 다음, 확장자(1520, 1530, 및 1540)를 현재 확장되어 있는 코어 프레임워크(1510)의 일부로서 컴파일한다.

그러나, 이러한 해결 방안이 모든 목적에 적합한 것은 아닐 수 있는데, 이는 확장자(예를 들어, 1520, 1530, 및 1540)의 정의를 제공하는 프로그래머들이 코어 프레임워크(1510)의 소스 코드를 액세스해야 할 필요가 있기 때문이다. 이는 코어 프레임워크(1510)의 제공자들이 코어 프레임워크 소스 코드의 보안을 유지하기를 원하는 환경에서는 바람직하지 않을 수 있다. 그런 경우, 도 15b에서 도시된 제2 해결 방안을 사용할 수 있으며, 여기서 코어 컴파일러 프레임워크(1550)는 확장자(1560, 1570, 및 1580)와는 독립된 파일로서 컴파일된다.

제2 해결 방안에서는, 확장자(1560, 1570, 및 1580) 및 코어 프레임워크(1550)를 서로에 대해 링크되도록 적응시킴으로써, 런타임 시에 확장자들이 코어 프레임워크에 링크되어 코어 프레임워크를 적절히 확장시킬 수 있다. 이와 같은 링크는 특정 코어 클래스를 확장시키기 위해 어느 확장자를 사용해야 하는가를 지정하는 단순 링크된 목록으로서 구현될 수 있다. 이는 또한 필요에 따라 코어 클래스에 확장자를 적절히 관련시키는 단순 명명 규정(simple naming convention)을 이용하여 달성될 수 있다. 제1 해결 방안과 비교해 볼 때, 제2 해결 방안은 런타임 시 링킹의 양상에 관련된 추가적인 오버헤드 처리를 필요로 할 수 있으므로, 저속으로 구현될 수 있다. 반면, 제2 해결 방안에서는 개발자들이 코어 프레임워크의 소스 코드를 액세스함이 없이 코어 클래스의 확장을 가능하게 하는 유연성을 제공한다.

도 16은 도 15a에 관련하여 도시된 컴파일 시점 전에 코어 프레임워크 프로그램에 관련된 클래스들을 정적으로 확장시키기 위한 방법을 도시한다. 코어 클래스들 및 그들의 확장자들은 오브젝트 기술 언어를 사용하여 정의될 수 있다. 코어 클래스 및 확장자의 정의가 동시에 또는 함께 생성될 필요는 없다. 그러나, 확장자를 부가시키는 것에는 코어 프로그램의 소스 코드로의 액세스를 어느 정도 필요로 할 것이다.

일단 이러한 클래스 정의가 획득되면, 블럭(1610)에서는 코어 클래스들 및 그들의 확장자들의 정의를, 오브젝트 기술 언어 표현을 소스 코드 표현으로 번역할 수 있는 ODL 프리-프로세서에 의해 함께 처리할 것이다. 블럭(1620)에서는, ODL 프로세서에 의한 사전-처리의 결과로서, 헤더 파일 및 가능하게는 코어 클래스들 및 그들의 확장자들의 정의를 C++ 등의 소스 코드 언어로 나타내는 일부 다른 코드가 생성될 것이다. 블럭(1630)에서는, 코어 클래스 멤버 및 확장자 클래스 멤버를 포함하는 확장된 클래스 정의를 갖는 헤더 파일을 현재 확장된 코어 프레임워크에 관련된 코드의 나머지와 함께 컴파일하여 커스텀으로 구성된 소프트웨어 개발 툴을 생성할 것이다.

도 17은 도 16의 프로세스를 구현하기 위한 예시적인 시스템을 도시한다. 도 17에서 도시된 바와 같이, 다수의 확장자 정의(1710) 내지 코어 클래스 정의(1720)는 오브젝트 기술 언어 파일로서 저장될 수 있다. 코어 클래스 정의 및 확장자 정의에 각각 대응하는 파일(1710) 및 파일(1720)을 수신할 수 있는 ODL 프리-프로세서(1730)가 제공될 수 있다. 이 프리-프로세서는 또한 파일(1710 및 1720)을 그들의 오브젝트 기술 언어 형식에서 소스 코드 표현(1740)으로 번역할 수 있어야 한다. 소스 코드 표현은 최종적으로 컴퓨터 프로세서에 의해 실행 가능한 형식으로 컴파일될 수 있는 임의 언어로 될 수 있다. 프리-프로세서(1730)에 의해 생성된 소스 코드(1740)는 클래스 정의가 일반적으로 저장되는 헤더 파일을 포함할 수 있다. 프리-프로세서(1730)에서 출력되는 소스 코드(1740)의 언어에 적합한 소스 코드 컴파일러(1750)를 제공하여 소스 코드 표현(1740)을 컴파일함으로써, 컴파일러 및 다른 소프트웨어 개발 툴 등의 코어 소프트웨어 프로그램(1760)의 커스터마이즈된 확장된 버전이 생성될 수 있다.

도 18은 확장 가능한 코어 프레임워크 소프트웨어 프로그램의 코어 클래스 정의를, 런타임 시에 확장자를 적당한 코어 클래스에 링크시킴으로써 확장시키는 방법을 도시한다. 코어 클래스 정의 및 확장자는 오브젝트 기술 언어를 사용하여 개별적으로 표현될 수 있다. 오브젝트 기술 언어는 코어 클래스 정의가 동적으로 확장 가능한 것을 표현하는 데 적합할 수 있다. 또한, 이러한 언어는 특정의 코어 클래스 정의 및 그들의 확장자들 간에서의 연관들을 표현하는 데 적합할 수 있다. 이하에서는, 이러한 적합한 한 언어에 대한 구문에 대해 상세히 기술하기로 한다. 일단 정의가 표현되면, ODL 프리-프로세서를 사용하여(블럭 1810), 오브젝트 기술 언어 표현의 정의를 소스 코드 표현으로 번역할 수 있다(블럭 1820). 그러나, 정적 프로세스(도 16)와는 달리, 도 18의 동적 프로세스에서는, 코어 클래스 정의가 그들의 확장자 정의와 함께 ODL 프리-프로세서에 의해 처리되지 않는다. 그 대신, 코어 클래스 정의에 대응하는 소스 코드 헤더 파일 및 클래스 확장자 정의에 대응하는 소스 코드 헤더 파일이 개별적으로 생성된다. 이들을 서로 다른 ODL 프리-프로세서에 의해 생성할 수 있지만, 그렇게 할 필요는 없다. 또한, 블럭(1830)에서, 코어 클래스 정의를 포함하는 헤더 파일 및 확장자 정의를 포함하는 헤더 파일을 개별적으로 컴파일하여 컴퓨터에 의해 실행 가능한 독립된 파일들을 생성한다. 그러나, 블럭(1840)에서는, 런타임 중에, 클래스 확장자 정의를 적당한 코어 클래스 정의에 링크시켜 코어 클래스를 정의된 바와 같이 확장시킬 수 있다.

도 19는 도 18의 프로세스를 구현하기 위한 예시적인 시스템을 도시한다. 도 19에 도시된 바와 같이, 클래스 확장자 정의가 오브젝트 기술 언어로 제공되어 파일(1910)에 저장된다. 각각의 확장자가 도시된 바와 같이 개별 파일로서 저장될 필요는 없다. 또한, 코어 클래스 정의가 오브젝트 기술 언어로 제공되어 파일(1920)에 저장된다. 도 18에 기술된 프로세스에 따르면, 코어 클래스 정의를 오브젝트 기술 언어 표현에서 헤더 파일(1935)로서 저장되는 소스 코드 언어 표현으로 번역하여 코어 클래스 정의를 처리하기 위한 ODL 프리-프로세서(1925)가 제공된다. 마찬가지로, 클래스 확장자 파일(1910)을 처리하는 다른 ODL 프리-프로세서(1930)를 제공하여, 확장자를 포함하는 소스 코드 헤더 파일(1940)을 생성할 수 있다. 클래스 확장자 헤더 파일(1940)을 컴파일하는 소스 코드 컴파일러(1945)를 제공하여, 클래스 확장자 정의를 포함하는 컴퓨터 실행 가능 파일(1960)을 생성할 수 있다. 마찬가지로, 코어 클래스 정의를 포함하는 헤더 파일(1935)을 컴파일하는 소스 컴파일러(1950)를 제공하여, 코어 클래스 정의를 포함하는 컴퓨터 실행 가능 파일(1955)을 생성할 수 있다. 그러면, 런타임 시에, 코어 클래스에 대응하는 실행 가능 파일(1955) 및 확장자 클래스에 대응하는 실행 가능 파일이 실행될 때, 코어 클래스 및 확장자 클래스 내에 제공되는 링크(1970)는 코어 클래스가 적절히 확장되도록 하게 할 수 있다.

소프트웨어 산출물(software deliverable)

도 20은 본 명세서에서 설명된 기술에 대한 컴퓨터 소프트웨어 산출물의 블럭도이다. 소프트웨어 산출물(2000)은 SDA(2002)를 포함한다. SDA(2002)는 하나 이상의 IR, 예외 핸들링 모델, 타입 시스템, 코드 생성기, 또는 본원에서 설명된 코어 데이터 구조 확장자 기술을 구현하기 위한 소스 코드 또는 오브젝트를 포함할 수 있다. SDA(2002)는 임의 개수의 소프트웨어 개발 시나리오에서 각종 소프트웨어 개발 툴 중 임의 하나를 생성하도록 구성될 수 있다. 이러한 구성은 원시 컴파일러 구성(2004), JIT 컴파일러 구성(2006), Pre-JIT 컴파일러 구성(2008), 분석 툴 구성(2010), 결함 검출 구성(2012), 최적화기 구성(2014), 또는 CDK 구성(2016)을 포함하지만, 이들에만 한정되는 것은 아니다.

소프트웨어 산출물은 적합한 컴퓨터 시스템 상에서 타겟 소프트웨어 개발 툴을 생성하도록 실행될 수 있다. 컴퓨터 시스템 상의 소프트웨어 산출물/SDA(2000/2002)에 컴포넌트(들)(2018)를 제공한다. 컴포넌트(들)(2018)는 타겟 실행 아키텍처에 관련된 데이터(2020), 클래스 확장자 선언 집합(2022), 타겟 소프트웨어 개발 툴용 입력 언어에 관련된 데이터(2024), 및 하나 이상의 타입 규칙 집합(2026) 중 하나 이상을 포함할 수 있지만, 이들에만 한정되는 것은 아니다.

소프트웨어 산출물은 선택된 구성 및 컴포넌트(들)(2018)에 기반하여 소프트웨어 개발 툴을 생성할 수 있다. 예를 들어, 도 21은 도 20에서 도시된 실행 가능한 소프트웨어의 특정 예를 나타내는 블럭도이다.

소프트웨어 산출물(2100)은 최적화기 구성의 SDA(2102)를 포함한다. 컴포넌트(들)(2104)는 x86 아키텍처에 관련된 데이터(2106), 최적화기 구성에 일치하는 클래스 확장자 선언 집합(2108), 입력 언어 C++에 관련된 데이터(2110), 및 타입 검사를 위한 세 가지 규칙 집합(예를 들어, 한 집합은 엄격한 타입 검사에 대응하며, 또 한 집합은 약한 타입 검사에 대응하며, 나머지 한 집합은 표현 타입 검사에 대응함)을 포함한다. 컴포넌트(들)(2104)는 소프트웨어 산출물/SDA(2100/2102)에 링크되어 최적화기(2114)를 생성한다. 최적화기(2114)는 입력으로서 C++ 언어로 기록된 소스 코드를 채용하고 x86 아키텍처를 대상으로 하고 있다.

도 22는 본원에서 설명된 기술에 대한 컴퓨터 소프트웨어 산출물의 다른 실시예를 도시한 것이다. 이 실시예에서는, 소프트웨어 산출물(2200)은 SDA(2210)의 이진 또는 기타 컴퓨터 실행 가능 파일 버전일 수 있다. 소프트웨어 개발 컴포넌트(2220)를 (예를 들어, 실행 시 소스 코드로의 액세스 없이) 소프트웨어 산출물(2200)에 링크(예를 들어, 동적으로)시킬 수 있다. 이들 컴포넌트와 소프트웨어 산출물을 결합시킴으로써, 소프트웨어 개발 툴(2230)을 생성할 수 있다.

이와는 다르게, 도 23에서 도시된 바와 같이, 기존 소프트웨어 개발 툴(2300)을 변형시킬 수 있다. 기존 소프트웨어 개발 툴(2300)은 본원에서 기술된 여러 방법에서와 같이 SDA(2310)를 사용하여 생성할 수 있다. 이 후, 새로운 컴포넌트(2320)를 생성하여 SDA(2310)에 링크시킴으로써 변형된 소프트웨어 개발 툴 버전(2330)을 생성할 수 있다.

또 다른 실시예에서는, SDA를 사용하여 상호 호환성 소스트웨어 툴을 생성할 수 있다. 도 24는 SDA(2410)를 사용하여 생성된 제1 소프트웨어 개발 툴(2400)의 블럭도이다. 이어서, 제2 소프트웨어 툴의 기능을 포함하는 하나 이상의 새로운 컴포넌트(2420)를 생성하여 이진 또는 기타 실행 가능 포맷(2430)의 SDA에 링크시킴으로써 제2 소프트웨어 개발 툴(2440)을 생성할 수 있다. 제1 및 제2 소프트웨어 툴(2400/2440)은 이들 툴이 SDA의 특성들(예를 들어, 공통 IR)을 공유한다는 사실로부터 상호 호환성을 갖는다.

IR 포맷의 예시적인 확장성

SDA용으로 정의된 코어 클래스를 확장시킬 수 있으므로, IR 포맷 자체를 확장시킬 수 있다. 예를 들어, 새로운 클래스 멤버들을 코어 클래스에 추가시킬 수 있으며 IR 포맷으로 표현할 수 있다. 이러한 구성은 스케일 가능성(scalability) 목적에 유익할 수 있다. 예컨대, JIT 컴파일러에 대해서는 (예로서, 성능 상의 이유로 인해) 경량(lightweight)의 데이터 구조를 사용하는 것이 바람직할 수 있다. 반면, 전체 프로그램 최적화 컴파일러의 경우에는 보다 포괄적인 데이터 구조를 사용하는 것이 적합할 수 있다.

코어 클래스는 본원에서 기술된 오브젝트 기술 언어 메카니즘을 통해 확장시킬 수 있다. 따라서, 코어 클래스는 적절한 소프트웨어 컴포넌트 또는 툴의 개발 시에 또는 실행 시에 (예를 들어, 코어 클래스의 소스 코드로의 액세스없이) 확장될 수 있다. 이와 같이 하여, 시스템은 IR 포맷의 런타임 확장성을 지원할 수 있다.

예시적인 소프트웨어 개발 시나리오 독립성

소프트웨어 개발 시나리오 독립성은 여러 방식으로 나타낼 수 있다. 예를 들면, 하나 이상의 소프트웨어 개발 시나리오에 대한 독립성이다. 예를 들어, 구현은 프로그래밍 언어(예컨대, 입력 언어), 소프트웨어 실행 아키텍처(예컨대, 프로세서 또는 가상 머신), 예외 핸들링 모델, 관리형 코드 시나리오 등, 또는 이들의 임의 결합과는 독립적일 수 있다.

예시적인 운영 환경

도 25는 SDA의 실시예를 위한 운영 환경으로서 기능하는 컴퓨터 시스템의 일례를 도시한다. 이 컴퓨터 시스템은 프로세서(2521), 시스템 메모리(2522), 및 시스템 메모리를 비롯하여 여러 시스템 컴포넌트를 프로세서(2521)에 상호접속시키는 시스템 버스(2523)를 포함하는 퍼스널 컴퓨터(2520)를 포함한다. 시스템 버스는 몇몇의 예를 들자면, PCI, VESA, 마이크로채널(MCA), ISA, 및 EISA 등의 버스 아키텍처를 이용하는 로컬 버스, 주변 버스, 및 메모리 버스 또는 메모리 제어기를 포함하는 여러 유형의 버스 구조 중 임의의 것을 포함할 수 있다. 시스템 메모리는 판독 전용 메모리(ROM)(2524) 및 랜덤 액세스 메모리(RAM)(2525)를 포함한다. ROM(2524)에는, 예를 들어, 기동 시에 퍼스널 컴퓨터(2520) 내의 구성요소들 간에서의 정보 전송을 도와 주는 기본 루틴을 포함하고 있는 기본 입/출력 시스템(BIOS; 2526)이 저장되어 있다. 또한, 퍼스널 컴퓨터(2520)는 하드 디스크 드라이브(2527), 일례로서 분리형 디스크(2529)에 대해 판독 또는 기록을 행하는 자기 디스크 드라이브(2528), 일례로서 CD-ROM 디스크(2531)를 판독하거나 다른 광 매체에 대해 판독 및 기록을 행하는 광 디스크 드라이브(2530)를 더 포함한다. 하드 디스크 드라이브(2527), 자기 디스크 드라이브(2528), 및 광 디스크 드라이브(2530)는 하드 디스크 드라이브 인터페이스(2532), 자기 디스크 드라이브 인터페이스(2533), 및 광 드라이브 인터페이스(2534) 각각을 통해 시스템 버스(2523)에 연결된다. 이들 드라이브 및 그들에 연관된 컴퓨터 판독 가능 매체는 퍼스널 컴퓨터(2520)에 데이터, 데이터 구조, 컴퓨터 실행 가능 명렁어(동적 링크 라이브러리, 및 실행 가능 파일 등의 프로그램 코드) 등의 비휘발성 저장을 제공한다. 상기에서는 비록 컴퓨터 판독 가능 매체를 하드 디스크, 이동식 자기 디스크 및 CD로 기술하였지만, 자기 카세트, 플래쉬 메모리 카드, 디지탈 비디오 디스크, 베르누이 카트리지 등, 컴퓨터에 의해 판독 가능한 다른 유형의 매체를 포함할 수 있다.

이들 드라이브 및 RAM(2525)에는 오퍼레이팅 시스템(2535), 하나 이상의 애플리케이션 프로그램(2536), 기타 프로그램 모듈(2537), 및 프로그램 데이터(2538)를 비롯하여 다수의 프로그램 모듈이 저장될 수 있다. 사용자는 퍼스널 컴퓨터(2520)에 키보드(2540)와, 마우스(2542) 등의 포인팅 장치를 통해 커맨드 및 정보를 입력할 수 있다. 기타 입력 장치(도시 안됨)로서, 마이크로폰, 조이스틱, 게임 패드, 위성 안테나, 스캐너 등을 포함할 수 있다. 이들 및 기타 입력 장치는 종종 시스템 버스에 결합되는 직렬 포트 인터페이스(2546)를 통해 프로세서(2521)에 연결되지만, 병렬 포트, 게임 포트 또는 USB 등의 다른 인터페이스를 통해 연결될 수 있다. 또한, 모니터(2547) 또는 다른 유형의 표시 장치가 디스플레이 제어기 또는 비디오 어댑터(2548) 등의 인터페이스를 통해 시스템 버스(2523)에 연결된다. 퍼스널 컴퓨터(2520)는 모니터 외에도, 스피커 및 프린터 등의 기타 주변 출력 장치(도시 안됨)를 포함하는 것이 일반적이다.

퍼스널 컴퓨터(2520)는 원격 컴퓨터(2549) 등의 하나 이상의 원격 컴퓨터와의 논리적 접속을 이용하여 네트워킹 환경에서 동작할 수 있다. 원격 컴퓨터(2549)는 서버, 라우터, 피어 장치 또는 기타 일반 네트워크 노드일 수 있으 며, 퍼스널 컴퓨터(2520)에 관련되어 기술된 구성 요소의 전부 또는 다수를 포함하는 것이 일반적이지만, 도 25에서는 단지 메모리 기억 장치(2550)만을 도시하였다. 도 25에서 도시된 논리적 접속에는 근거리 통신망(LAN)(2551) 및 광역 통신망(WAN)(2552)을 포함한다. 이러한 네트워킹 환경은 사무실, 전사적 컴퓨터 네트워크, 인트라넷 및 인터넷에서는 일반적이다.

퍼스널 컴퓨터(2520)가 LAN 네트워킹 환경에서 사용될 경우에는, 퍼스널 컴퓨터(2520)는 네트워크 인터페이스 즉, 어댑터(2553)를 통해 근거리 통신망(2551)에 연결된다. 퍼스널 컴퓨터(2520)가 WAN 네트워킹 환경에서 사용될 경우에는, 퍼스널 컴퓨터(2520)는 일반적으로 인터넷 등의 광역 통신망(2552)을 통해 통신을 구축하기 위해 모뎀(2554) 또는 다른 수단을 포함한다. 내장형이나 외장형일 수 있는 모뎀(2554)은 시리얼 포트 인터페이스(2546)를 통해 시스템 버스(2523)에 연결된다. 네트워킹 환경에서, 퍼스널 컴퓨터(2520)에 관련하여 도시된 프로그램 모듈, 또는 그 일부는 원격 메모리 기억 장치에 저장될 수 있다. 도시된 네트워크 접속은 단지 일례에 불과한 것으로, 컴퓨터들 간에서의 통신 링크를 구축하기 위한 다른 수단을 사용할 수 있다.

대체예

상기에서는 예시된 실시예의 원리에 대해서만 기술 및 도시하였지만, 본 기술 분야의 숙련자라면 이러힌 원리를 벗어나지 않는 한 상기 예시된 실시예에 대한 변형 및 수정 실시예가 가능하다는 것을 인식할 수 있을 것이다.

실시 가능한 다양한 실시예들에 비추어 보면, 예시된 실시예들은 단지 예에 불과한 것으로, 본 발명을 한정하려고 기술한 것은 아니다. 그 보다는, 본 발명은 오히려 첨부된 특허청구범위에 기재된 사항에 의해서 광의적으로 해석되어야 한다. 따라서, 본 발명은 특허청구범위의 사상 내에서 이루어지는 모든 실시예들을 포함할 수 있다.

본 발명에 따르면, 광범위의 소프트웨어 개발 툴들을 위한 컴포넌트들을 작성하고, 이 컴포넌트들을 연결시켜 툴을 제작하는 데 SDA가 제공된다. 이 SDA는, 임의의 개수의 타겟 실행 아키텍처들의 입력 코드 및 출력 코드로서 임의의 개수의 프로그래밍 언어를 취할 수 있는 각종 소프트웨어 개발 툴을 제작하는 것이 가능하다.

Claims (43)

1. 소프트웨어 개발 아키텍처를 구현하기 위한 컴퓨터 실행 가능 명령어들을 기록한 하나 이상의 컴퓨터 판독 가능 기록 매체에 있어서, 상기 소프트웨어 개발 아키텍처는,

   프로그래밍 언어로 작성된 프로그램 모듈을 소스 언어로부터 소프트웨어 개발 시나리오 독립형 중간 표현으로 변환하는 변환기 - 상기 소프트웨어 개발 시나리오 독립형 중간 표현은 하이레벨 중간 표현(high-level intermediate presentation), 미드레벨 중간 표현(mid-level intermediate presentation) 및 로우레벨 중간 표현(low-level intermediate presentation) 중 하나임 -;

   복수의 상이한 소스 언어에 대한 복수의 프로그래밍 언어 특정 예외 핸들링을 지원하도록 동작 가능한 하나 이상의 예외 핸들링 모듈;

   상기 복수의 상이한 소스 언어의 타입 표현들을 나타내도록 동작 가능한 타입 시스템 모듈; 및

   복수의 실행 아키텍처들을 타겟으로 하는 코드를 생성하도록 동작 가능한 코드 생성기 - 상기 코드는 상기 복수의 상이한 소스 언어에 대한 복수의 프로그래밍 언어 특정 예외 핸들링을 지원 가능함 -

   를 포함하고,

   상기 타입 시스템 모듈은,

   상기 소프트웨어 개발 시나리오 독립형 중간 표현을 타입 검사하기 위한 복수의 규칙 세트; 및

   상기 프로그램 모듈이 상기 변환기에 의하여 상기 소스 언어로부터 상기 하이레벨 중간 표현으로 변환될 때, 상기 복수의 규칙 세트에 따라 상기 하이레벨 중간 표현을 타입 검사하고,

   상기 프로그램 모듈이 상기 변환기에 의하여 상기 하이레벨 중간 표현으로부터 상기 미드레벨 중간 표현으로 변환될 때, 상기 복수의 규칙 세트에 따라 상기 미드레벨 중간 표현을 타입 검사하고,

   상기 프로그램 모듈이 상기 변환기에 의하여 상기 미드레벨 중간 표현으로부터 상기 로우레벨 중간 표현으로 변환될 때, 상기 복수의 규칙 세트에 따라 상기 로우레벨 중간 표현을 타입 검사 - 상기 복수의 규칙 세트는 상기 소스 언어, 상기 소프트웨어 개발 독립형 중간 표현의 레벨 및 타입 강도(strength of typing)에 기초하여 선택됨 - 하는 타입 검사기를 포함하고,

   상기 코드 생성기는, 상기 변환기, 상기 복수의 상이한 소스 언어에 대한 복수의 프로그래밍 언어 특정 예외 핸들링을 지원하도록 동작 가능한 상기 하나 이상의 예외 핸들링 모듈 및 상기 복수의 상이한 소스 언어의 타입 표현들을 나타내도록 동작 가능한 상기 타입 시스템 모듈을 사용하여, 복수의 상이한 소프트웨어 개발 툴의 하나 이상의 소프트웨어 개발 컴포넌트를 구축하며,

   상기 코드 생성기는 상기 복수의 상이한 소프트웨어 개발 툴의 상기 하나 이상의 소프트웨어 개발 컴포넌트를, 소프트웨어 개발 시나리오 독립형 프레임워크 내에 통합하고,

   상기 코드 생성기는 상기 하나 이상의 소프트웨어 개발 컴포넌트 및 소프트웨어 개발 시나리오 독립형 프레임워크를 컴파일함으로써 상기 복수의 상이한 소프트웨어 개발 툴을 작성하는,

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

   상기 아키텍처는 경량(lightweight) JIT 컴파일러들로부터 모든 프로그램 최적화 컴파일러들에 이르는 타겟 소프트웨어 개발 툴들을 생성하도록 스케일 가능한, 컴퓨터 판독 가능 기록 매체.
3. 제1항에 있어서,

   상기 아키텍처는 메모리 풋프린트, 컴파일 속도, 및 최적화의 범위를 변경하여 타겟 소프트웨어 개발 툴을 생성하도록 구성될 수 있는, 컴퓨터 판독 가능 기록 매체.
4. 제1항에 있어서,

   상기 소프트웨어 개발 아키텍처는 상기 소프트웨어 개발 시나리오 독립형 프레임워크에 변형 컴포넌트를 결합시켜 변형 가능한 소프트웨어 개발 툴을 생성하도록 동작 가능한, 컴퓨터 판독 가능 기록 매체.
5. 제1항에 있어서,

   상기 소프트웨어 개발 아키텍처는 상기 소프트웨어 개발 시나리오 독립형 프레임워크의 이진 버전을 변형 컴포넌트에 동적으로 링크시켜 소프트웨어 개발 툴을 생성하도록 동작 가능한, 컴퓨터 판독 가능 기록 매체.
6. 제1항에 있어서,

   상기 중간 표현은 상기 중간 표현을 채용하는 소프트웨어 툴의 런타임 시에 확장 가능한, 컴퓨터 판독 가능 기록 매체.
7. 제1항에 있어서,

   상기 아키텍처는 상기 하나 이상의 소프트웨어 개발 컴포넌트에 결합 가능한, 컴퓨터 판독 가능 기록 매체.
8. 제7항에 있어서,

   상기 하나 이상의 소프트웨어 개발 컴포넌트는 타겟 소프트웨어 개발 툴을 기술하는 데이터를 포함하는, 컴퓨터 판독 가능 기록 매체.
9. 제7항에 있어서,

   상기 하나 이상의 소프트웨어 개발 컴포넌트는 상기 코드 생성기에 타겟 실행 아키텍처 데이터를 제공하는, 컴퓨터 판독 가능 기록 매체.
10. 제7항에 있어서,

    상기 하나 이상의 소프트웨어 개발 컴포넌트는 하나 이상의 타입 검사 규칙을 상기 타입 시스템 모듈에 제공하는, 컴퓨터 판독 가능 기록 매체.
11. 제7항에 있어서,

    상기 하나 이상의 소프트웨어 개발 컴포넌트는 클래스 확장자 선언들의 집합을 상기 아키텍처에 제공하는, 컴퓨터 판독 가능 기록 매체.
12. 삭제
13. 제7항에 있어서,

    상기 복수의 상이한 소프트웨어 개발 툴은 원시 컴파일러(native compiler)를 포함하는, 컴퓨터 판독 가능 기록 매체.
14. 제7항에 있어서,

    상기 복수의 상이한 소프트웨어 개발 툴은 JIT 컴퍼일러를 포함하는, 컴퓨터 판독 가능 기록 매체.
15. 복수의 상이한 타겟 소프트웨어 개발 툴을 생성하는 방법에 있어서,

    하나 이상의 소프트웨어 개발 시나리오에 특정된 기능을 규정하는 적어도 하나의 컴퓨터 판독 가능 규격을 수신하는 단계 - 상기 적어도 하나의 컴퓨터 판독 가능 규격은, 상기 복수의 상이한 타겟 소프트웨어 개발 툴의 소프트웨어 개발 시나리오 기능을 규정하며, 상기 소프트웨어 개발 시나리오 기능은,

    타겟 프로세서 실행 아키텍처;

    타입 검사 규칙 세트;

    관리형(managed) 실행 환경;

    입력 프로그래밍 언어 또는 입력 이진 포맷; 및

    컴파일 타입(compilation type)

    을 포함함 -;

    프로그래밍 언어로 작성된 프로그램 모듈을 중간 표현으로 변환함으로써, 상기 적어도 하나의 규격으로부터, 상기 복수의 상이한 소프트웨어 개발 툴에 대한 적어도 하나의 소프트웨어 개발 컴포넌트를 생성하는 단계 - 상기 중간 표현은 하이레벨 중간 표현, 미드레벨 중간 표현 및 로우레벨 중간 표현 중 하나임 - ;

    상기 복수의 상이한 소프트웨어 개발 툴에 대한 상기 적어도 하나의 소프트웨어 개발 컴포넌트를 소프트웨어 개발 시나리오 독립형 프레임워크 내에 통합시키는 단계; 및　

    상기 복수의 상이한 타겟 소프트웨어 개발 툴을 생성하도록 상기 적어도 하나의 소프트웨어 개발 컴포넌트 및 프레임워크를 적어도 일부 컴파일하는 단계

    를 포함하고,

    상기 컴퓨터 판독 가능 규격은, 복수의 상이한 프로그래밍 언어를 나타낼 수 있는 상기 중간 표현을 처리하는 기능을 포함하며,

    상기 중간 표현은, 상기 복수의 상이한 프로그래밍 언어에 대한 복수의 프로그래밍 언어 특정 예외 핸들링을 지원할 수 있는 하나 이상의 예외 핸들링 모델을 포함하고

    상기 적어도 하나의 소프트웨어 개발 컴포넌트를 생성하는 단계는,

    상기 프로그램 모듈이 소스 언어로부터 상기 하이레벨 중간 표현으로 변환될 때, 상기 타입 검사 규칙 세트에 따라 상기 하이레벨 중간 표현을 타입 검사하는 단계;

    상기 프로그램 모듈이 상기 하이레벨 중간 표현으로부터 상기 미드레벨 중간 표현으로 변환될 때, 상기 타입 검사 규칙 세트에 따라 상기 미드레벨 중간 표현을 타입 검사하는 단계; 및

    상기 프로그램 모듈이 상기 미드레벨 중간 표현으로부터 상기 로우레벨 중간 표현으로 변환될 때, 상기 타입 검사 규칙 세트에 따라 상기 로우레벨 중간 표현을 타입 검사하는 단계 - 상기 타입 검사 규칙 세트는 상기 소스 언어, 상기 중간 표현의 레벨 및 타입 강도(strength of typing)에 기초하여 선택됨 - 를 포함하는, 방법.
16. 삭제
17. 제15항에 있어서,

    복수의 소프트웨어 개발 시나리오들 각각에 대한 복수의 컴퓨터 판독 가능 규격들로부터 생성된 소프트웨어 개발 컴포넌트들이 상기 프레임워크 내에 통합되는, 방법.
18. 삭제
19. 삭제
20. 삭제
21. 삭제
22. 제15항에 있어서,

    상기 컴퓨터 판독 가능 규격은 하나 이상의 언어에 대해 타입 검사를 행하기 위한 하나 이상의 규칙 집합을 포함하는, 방법.
23. 제15항에 있어서,

    상기 컴퓨터 판독 가능 규격은 상기 소프트웨어 개발 시나리오 중 하나 이상에 특정된 클래스 확장자 선언들의 집합을 포함하는, 방법.
24. 삭제
25. 삭제
26. 제15항에 있어서,

    상기 중간 표현은 상기 복수의 상이한 프로그래밍 언어들의 타입 표현들을 나타낼 수 있는 타입 표현들을 포함하는, 방법.
27. 제15항에 있어서,

    상기 소프트웨어 개발 시나리오 중 하나에 특정된 커스텀 코드를 통합시키는 단계

    를 더 포함하는 방법.
28. 제15항에 있어서,

    상기 복수의 상이한 소프트웨어 개발 툴은 원시 컴파일러, JIT 컴파일러, 분석 툴, 및 CDK로 이루어진 그룹 중에서 적어도 두 개를 포함하는, 방법.
29. 제15항에 있어서,

    상기 컴퓨터 판독 가능 규격은 Pre-JIT 컴파일러 기능, 최적화기 기능, 및 결함 검출 툴 기능으로 이루어진 그룹 중의 하나의 기능을 특정하는, 방법.
30. 제15항에 따른 방법을 수행하기 위한 하나 이상의 컴퓨터 실행 가능 명령어를 포함하는 하나 이상의 컴퓨터 판독 가능 기록 매체.
31. 삭제
32. 삭제
33. 삭제
34. 삭제
35. 삭제
36. 삭제
37. 삭제
38. 삭제
39. 삭제
40. 삭제
41. 삭제
42. 삭제
43. 삭제

Images