KR101442382B1

KR101442382B1 - 가상 프로세서의 멀티-펑션 명령의 명령 펑션을 차단하기 위한 펑션 가상 퍼실리티

Info

Publication number: KR101442382B1
Application number: KR1020127033571A
Authority: KR
Inventors: 단 그레이너; 데미안 리오 오시섹; 티모시 슬레겔; 리사 헬러
Original assignee: 인터내셔널 비지네스 머신즈 코포레이션
Priority date: 2010-06-24
Filing date: 2010-11-08
Publication date: 2014-09-17
Also published as: SI2430532T1; US10521231B2; AU2010355814A1; US11809870B2; ES2435634T3; WO2011160723A1; HRP20131009T1; KR20130060233A; US20110320773A1; RU2565514C2; BR112012033816B1; DK2430532T3; US20210255867A1; ZA201209646B; JP2013535063A; CA2800640C; PL2430532T3; BR112012033816A2; CN102906700A; EP2430532A1

Abstract

명령의 복수의 펑션의 실행을 지원하는 프로세서에 있어서, 명령 차단 값은 상기 복수의 펑션들 중 하나 혹은 그 이상을 차단하기 위해 세트되며, 그 결과 상기 차단된 펑션들 중 하나를 실행하려는 시도는 프로그램 예외를 초래하고, 상기 명령은 실행되지 않는다. 그러나 상기 동일 명령은 차단되지 않은 펑션들 중에는 어느 것이라도 실행할 수 있다.

Description

가상 프로세서의 멀티-펑션 명령의 명령 펑션을 차단하기 위한 펑션 가상 퍼실리티{FUNCTION VIRTUALIZATION FACILITY FOR BLOCKING INSTRUCTION FUNCTION OF A MULTI-FUNCTION INSTRUCTION OF A VIRTUAL PROCESSOR}

본 발명은 컴퓨터 시스템들에 관한 것이며, 특히 컴퓨터 시스템 프로세서 명령 기능성(instruction functionality)에 관한 것이다.

상표들: IBM®은 미국 뉴욕 아몬크 소재 인터내셔널 비지네스 머신즈 코포레이션의 등록 상표이며, S/390, Z900, z990 및 z10와 기타 제품이름들은 인터내셔널 비지네스 머신즈 코포레이션 혹은 다른 회사들의 등록상표들이거나 혹은 제품이름들일 수 있다.

IBM은 수많은 높은 수준의 재능을 가진 엔지니어들의 작업을 통해서, 1960년대 IBM® System 360으로 알려진 머신들로 시작하여 오늘날까지, 컴퓨팅 시스템에 대한 본질적 성격 때문에, “메인프레임”으로 알려져 있는 특별한 아키텍처 (special architecture)를 생산하여 왔다. 메인프레임의 동작 원리들은 IBM 발명자들에 의해서 발명되어 채택되어 왔던 명령들의 메인프레임 구현 상에서 실행될 수 있는 명령들을 기술함에 의해서 머신의 아키텍처를 설명하는데(state), 그 이유는 “메인프레임”으로 표시된 컴퓨팅 머신의 상태를 개선하는데 대한 그들의 중요한 공헌 때문이며, 중요한 공헌들로서 IBM의 동작 원리들(IBM's Principles of Operation)에 포함되어 여러 해 동안 설명되었다. IBM® z/Architecture® 동작의 원리들의 제 8판은, 2009년 2월에 발간되었으며, SA22-7832-07로서 발간된 표준 참고자료가 되었으며, IBM의 z10® 메인프레임 서버들에 포함되어 있다.

도 1a를 참조하면, 종래 호스트 컴퓨터 시스템(50)의 대표적인 콤포넨트들이 도시되어 있다. 콤포넨트들의 다른 구성들도 또한 컴퓨터 시스템에 채용될 수 있는데, 이들은 공지 기술에 잘 알려져 있다. 대표적인 호스트 컴퓨터(50)은 다른 컴퓨터들 혹은 SAN 등과 통신하기 위한 스토리지(11) 및 네트웍들(10)에 대한 I/O인터페이스들 뿐만 아니라 메인 스토어(main store)(컴퓨터 메모리 2)와 통신하기 위해서 하나 혹은 그 이상의 CPU들(1)을 포함할 수 있다. CPU(1)은 아키텍처된 명령 세트(architected instruction set) 및 아키텍처된 기능성(architected functionality)을 갖는 아키텍처를 준수한다. CPU(1)은 프로그램 주소들(가상 주소들)을 메모리의 실제 주소로 변환하기 위해 동적 주소 변환부(DAT)(3)을 가질 수 있다. DAT는 통상적으로 변환 룩어사이드 버퍼(a Translation Lookaside Buffer (TLB)) (7)을 포함하는데, 이는 컴퓨터 메모리(2)의 블록에 대한 나중의 억세스들이 주소변환 지연을 필요하지 않도록 변환들을 캐싱(caching)하기 위해서이다. 통상적으로 캐시(9)가 컴퓨터 메모리(2)와 프로세서(1) 사이에 채용된다. 캐시(9)는 계층적 구조를 가질 수 있는데, 이는 하나 이상의 CPU에 대하여 이용 가능한 큰 캐시(a large cache)와 상기 큰 캐시와 각각의 CPU사이에 더 적고(smaller), 더 빠른(faster)(하위 레벨: lower level)캐시들을 가질 수 있다. 일부 구현들에서, 상기 하위 레벨 캐시들은 명령 페칭(instruction fetching)과 데이터 억세스들을 위해 별도의(separate) 하위 레벨 캐시들을 제공하도록 분리될 수 있다. 한 실시 예에서, 명령은 캐시(9)를 통해서 명령 페치 유닛(an instruction fetch unit) (4)에 의해서 메모리(2)로부터 페치된다. 상기 명령은 명령 디코드 유닛(an instruction decode unit) (6)에서 디코드 되어 명령 실행 유닛들(instruction execution units) (8)로 전송된다(일부 실시 예들에서는 다른 명령들과 함께). 통상적으로 여러 명령 실행 유닛들(8)이 채용되는데, 이들은 예를 들어, 산술연산 실행 유닛(an arithmetic execution unit), 부동 소수점 실행 유닛(a floating point execution unit) 및 브랜치 명령 실행 유닛(a branch instruction execution unit)을 포함한다. 상기 명령은 상기 실행 유닛에 의해서 실행되는데, 필요에 따라서 명령 지정된 레지스터들 혹은 메모리(2)로부터 오퍼런드들(operands)에 억세스한다. 만일 오퍼런드가 메모리 (2)로부터 억세스된다면(로드 혹은 저장된다면), 로드 스토어 유닛(a load store unit) (5)은 통상적으로 실행될 상기 명령의 제어 하에서 상기 억세스를 처리한다. 명령들은 하드웨어 회로들로 혹은 내부 마이크로코드(펌웨어) 혹은 이들의 조합에 의해서 처리될 수 있다.

도 1b에서, 호스트 아키텍처를 갖는 호스트 컴퓨터 시스템(50)을 에뮬레이트하는(emulate) 종래 기술의 에뮬레이트된 호스트 컴퓨터 시스템(21)의 예가 제공된다. 에뮬레이트된 호스트 컴퓨터 시스템(21)에서, 호스트 프로세서(CPU) (1)은 에뮬레이트된 호스트 프로세서(혹은 가상의 호스트 프로세서)이고 에뮬레이션 프로세서(27)을 포함하는데, 이는 호스트 컴퓨터 시스템(50)의 프로세서(1)의 아키텍처와는 다른 네이티브 명령세트 아키텍처(a different native instruction set architecture)를 갖는다. 에뮬레이트된 호스트 컴퓨터 시스템(21)은 에뮬레이션 프로세서(27)에 대해 억세스 가능한 메모리(22)를 갖는다. 상기 예시적 실시 예에서, 메모리(22)는 호스트 컴퓨터 메모리(2) 부분과 에뮬레이션 루틴들(23) 부분으로 파티션된다. 호스트 컴퓨터 메모리(2)는 호스트 컴퓨터 아키텍처에 따라서 에뮬레이트된 호스트 컴퓨터 시스템(21)의 프로그램들에 대해 이용 가능하다. 에뮬레이션 프로세서(27)은 에뮬레이터된 프로세서(1)의 아키텍처와 다른 아키텍처의 아키텍처된 명령 세트의 네이티브 명령들, 에뮬레이션 루틴 메모리(23)으로부터 획득된 상기 네이티브 명령들을 실행하고, 그리고 호스트 컴퓨터 메모리(2) 내의 프로그램으로부터, 실행을 위해 호스트 명령을 억세스 할 수 있는데, 이는 시퀀스 & 억세스/디코드 루틴(a Sequence & Access/Decode routine) 내에 획득된 하나 혹은 그 이상의 명령(들)을 채용함으로써 한다. 상기 루틴은 상기 억세스된 호스트 명령의 펑션을 에뮬레이트하기 위한 네이티브 명령 실행 루틴을 결정하기 위해서 상기 억세스된 호스트 명령(들)을 디코드할 수 있다. 호스트 컴퓨터 시스템(50) 아키텍처를 위해 정의된 다른 퍼실리티들(other facilities)은 아키텍처된 퍼실리티 루틴들에 의해서 에뮬레이트될 수 있으며, 그러한 퍼실리티들에는 예를 들어 일반 레지스터들, 제어 레지스터들, 동적 주소 변환부 및 I/O 서브시스템 지원부와 프로세서 캐시가 포함된다. 상기 에뮬레이션 루틴들의 성능을 개선하기 위해서 상기 에뮬레이션 루틴들은 또한 프로세서(27)의 에뮬레이션에서 이용 가능한 펑션(예를 들어 일반 레지스터들 및 가상 주소들의 동적 변환부)을 이용할 수 있다. 호스트 컴퓨터(50)의 펑션을 에뮬레이트하는데 있어서 프로세서(27)을 지원하기 위해서 특별 하드웨어 및 오프-로드 엔진들(Off-Load Engines)도 또한 제공될 수 있다.

메인프레임에서, 아키텍처된 머신 명령들은 컴파일러 어플리케이션을 위해 프로그래머들, 보통으로 오늘날 “C”프로그래머들에 의해서 자주 사용된다. 스토리지 매체에 저장된 이들 명령들은 z/Architecture IBM 서버에서 그대로(natively), 혹은 다른 아키텍처를 실행하는 머신들에서 대체적으로(alternatively) 실행될 수 있다. 이들은 기존의 그리고 미래의 IBM 메인프레임 서버들에서 그리고 IBM의 다른 머신들(예를 들어, pSeriesⓒ 서버들 및 xSeries® 서버들) 상에서 에뮬레이트 될 수 있다. 이들은 IBM®, Intel®, AMD™, Sun Microsystems 및 기타 제조사들에 의해서 제조된 하드웨어를 사용하는 아주 다양한 머신들 상의 Linux를 실행하는(running) 머신들 내에서 실행될 수 있다. Z/Architecture® 하의 그러한 하드웨어 상에서 실행되는 경우 이외도, Linux는 http://www.turbohercules.com, http://www.hercules-390.org 및 http://www. funsoft.com에 기술되어 있는 바와 같은 에뮬레이션을 사용하는 기계들에서도 또한 사용될 수 있다. 에뮬레이션 모드에서, 에뮬레이션 소프트웨어는 에뮬레이트되는 프로세서의 아키텍처를 에뮬레이트하기 위해 네이티브 프로세서에 의해서 실행된다.

네이티브 프로세서(27)은 에뮬레이트되는 프로세서의 에뮬레이션을 수행하기 위해서 통상적으로 펌웨어 혹은 네이티브 운영체제를 포함하는 에뮬레이션 소프트웨어(23)을 실행한다. 에뮬레이션 소프트웨어(23)은 상기 에뮬레이트되는 프로세서 아키텍처의 명령들을 페치하고 실행할 책임이 있다. 에뮬레이션 소프트웨어(23)은 에뮬레이트되는 프로그램 카운터를 유지하는데, 이는 명령 경계들(instruction boundaries)을 추적하기 위해서이다. 에뮬레이션 소프트웨어(23)은 하나 혹은 그 이상의 에뮬레이트되는 머신 명령들을 한번에 페치하여 네이티브 프로세서(27)에 의한 실행을 위해 상기 하나 혹은 그 이상의 에뮬레이트되는 머신 명령들을 네이티브 머신 명령들의 대응 그룹으로 변환할 수 있다. 이들 변환된 명령들은 더 빠른 변환이 달성될 수 있도록 캐시될 수 있다. 그럼에도 불구하고, 상기 에뮬레이션 소프트웨어는 상기 에뮬레이트되는 프로세서 아키텍처의 아키텍처 규칙들을 유지해야 하는데, 이는 운영 체제들과 상기 에뮬레이트되는 프로세서를 위해 작성된 어플리케이션들이 정확하게 동작하도록 하기 위함이다. 더 나아가, 상기 에뮬레이션 소프트웨어는 에뮬레이트되는 프로세서(1) 아키텍처에 의해서 식별되는 리소스들(resources)을 제공해야 하는데, 이들에는 제어 레지스터들, 일반 레지스터들, 부동 소수점 레지스터들, 예를 들어 세그멘트 테이블들 및 페이지 테이블들을 포함하는 동적 주소 변환 펑션, 인터럽트 메커니즘들, 컨텍스트 스위치 메커니즘들, 타임오브데이(TOD) 클럭들 및 I/O 서브시스템들에 대한 아키텍처된 인터페이스들이 포함되나 이에 한정되지는 않는다. 이들은 운영 체제 혹은 상기 에뮬레이트되는 프로세서상에서 실행되도록 설계된 어플리케이션 프로그램이 상기 네이티브 프로세서 상에서 실행될 수 있도록 하기 위함이다.

에뮬레이트될 특정 명령이 디코드되고, 서브루틴이 개별 명령의 펑션을 수행하기 위해 호출된다. 에뮬레이트되는 프로세서(1)의 펑션을 에뮬레이트하는 에뮬레이션 소프트웨어 펑션(23)은, 예를 들어, “C”서브루틴 혹은 드라이버, 또는 특정 하드웨어의 드라이버를 제공하는 기타 다른 방법으로, 구현되는데, 이는 본 발명의 바람직한 예를 이해하고 나면, 당업자들이 실시할 수 있을 것이다. 다양한 소프트웨어 및 하드웨어 에뮬레이션 특허들은 다음과 같으며, 이에 한정되지 않는다. 미국 특허US 5551013에 공개된 Beausoleil와 공동 발명자들의 "하드웨어 에뮬레이션을 위한 멀티프로세서(Multiprocessor for hardware emulation)"; 미국 특허 US6009261에 공개된 Scalzi와 공동 발명자들의 “타겟 프로세서 상에 양립할 수 없는 명령들을 에뮬레이트하기 위한 저장된 타겟 루틴들의 처리 (Preprocessing of stored target routines for emulating incompatible instructions on a target processor)"; 미국 특허US5574873에 공개된 Davidian과 공동 발명자들의 “게스트 명령들을 에뮬레이트하는 에뮬레이션 루틴들을 직접 억세스하기 위해 게스트 명령들을 디코드하는 방법(Decoding guest instruction to directly access emulation routines that emulate the guest instructions); 미국 특허US6308255에 공개된 Gorishek와 공동 발명자들의 “시스템에서 비-네이티브 코드가 실행하도록 코프로세서 지원을 위해 사용되는 대칭 멀티프로세싱 버스 및 칩세트 (Symmetrical multiprocessing bus and chipset used for coprocessor support allowing non-native code to run in a system)”; 미국 특허US6463582에 공개된 Lethin과 공동 발명자들의 “아키텍처 에뮬레이션과 오브젝트 코드 변환 방법을 동적으로 최적화 하기 위한 오브젝트 코드 변환기의 동적 최적화(Dynamic optimizing object code translator for architecture emulation and dynamic optimizing object code translation method)”; 그리고 미국 특허 US5790825에 공개된 Eric Traut의 “호스트 명령들의 동적 리컴파일레이션을 통해 호스트 컴퓨터 상에서 게스트 명령들을 에뮬레이트 하는 방법(Method for emulating guest instructions on a host computer through dynamic recompilation of host instructions)”. 이들 참고 자료들은 당업자들에게 이용 가능한 타겟 머신을 위해서, 뿐만 아니라 또한 그러한 참고자료들에 의해서 사용되는 상업적 소프트웨어 기술들을 위해서, 다른 머신을 위해 아키텍처된 명령 포맷의 에뮬레이션을 달성하기 위한 공지의 다양한 방법들을 보여준다.

2009년 9월 3일에 공개된 Astrand의 미국 특허 공개번호 US 2009/0222814인 "가상 머신을 위한 USB 디바이스 펑션에 대한 선택적 익스포우져(Selective Exposure to USB Device Functionality for a Virtual Machine)"에서, 가상 머신(VM) 어플리케이션은 게스트 운영체제(OS)를 실행시켜 그 게스트 OS가 컴퓨터에 연결된 USB 디바이스들에 연결되도록 할 수 있다. 상기 VM어플리케이션은 상기 USB 디바이스와 연관된 펑션들을 필터하여 상기 USB 디바이스의 일부 펑션들이 상기 게스트 OS에 익스포우즈되게(exposed) 할 수 있다.

한 실시 예에서, 특정 명령들이 프로세서에 의해서 실행되는 것이 차단된다. 하나의 명령 차단 값(instruction blocking value)이 세트 된다(set). 하나의 명령이 페치되어 상기 프로세서에 의해서 실행되며, 상기 명령은 오피코드(opcode)를 포함하며, 상기 명령은 상기 프로세서에 의해서 지원되고: 상기 명령 차단 값이 상기 명령의 실행을 허가하는 것에 응답하여, 상기 프로세서에 의해 상기 페치된 명령을 실행하며: 상기 명령 차단 값이 상기 명령의 실행을 허가하지 않는 것에 응답하여, 상기 페치된 명령의 실행을 차단하고 그리고 프로그램 예외 이벤트(program exception event)(예를 들어 프로그램 예외)를 일으킨다.

한 실시 예에서, 프로세서는 가상 머신의 논리적 프로세서이며, 페칭은 상기 논리적 프로세서에 의해서 수행된다. 상기 가상 머신의 상기 명령 차단 값에 관한 결정이 내려지고, 상기 명령 차단 값이 하나 혹은 그 이상의 물리적 프로세서들을 갖는 상기 논리적 프로세서 내에서 세트 되며, 상기 명령은 하나 혹은 그 이상의 물리적 프로세서들에 의해서 지원되고, 상기 명령 차단 값이 상기 명령의 실행을 허가하는 것에 응답하여, 상기 실행이 상기 논리적 프로세서에 의해서 수행된다.

한 실시 예에서, 프로세서는 가상 머신의 논리적 프로세서의 하나 혹은 그 이상의 물리적 프로세서들이고, 명령 차단 값은 상기 하나 혹은 그 이상의 물리적 프로세서들 내에서 세트 되며, 페칭은 상기 하나 혹은 그 이상의 물리적 프로세서들에 의해서 수행된다.

한 실시 예에서, 명령 차단 값은 명령의 실행을 차단하기 위해서 가상 머신을 위해 정의되며, 상기 명령 차단 값을 세트 하는 것은 물리적 프로세서를 사용하도록 상기 가상머신을 인에이블 하는 것에 응답하여 하고: 다른 명령 차단 값(another instruction blocking value)이 세트 되며, 상기 다른 명령 차단 값은 다른 논리적 프로세서를 갖는 다른 가상 머신을 위해 정의되고, 상기 다른 명령 차단 값을 세트 하는 것은 물리적 프로세서를 사용하도록 상기 다른 가상 머신을 인에이블 하는 것에 응답하여 하며; 그리고 상기 다른 명령 차단 값이 상기 명령의 실행을 허가하는 것에 응답하여, 상기 다른 논리적 프로세서에 의한 명령의 실행을 허가하고; 그리고 상기 다른 명령 차단 값이 상기 명령의 실행을 허가하지 않는 것에 응답하여, 상기 다른 논리적 프로세서에 의한 명령의 실행을 허가하지 않는다.

한 실시 예에서, 명령 차단 값은 상기 명령의 실행을 차단하기 위해서 가상 머신을 위해 정의되며, 상기 명령 차단 값을 세트 하는 것은 상기 물리적 프로세서를 사용하도록 상기 가상 머신을 인에이블 하는 것에 응답하여 하고: 다른 명령 차단 값이 세트 되며, 상기 다른 명령 차단 값은 다른 논리적 프로세서를 갖는 상기 다른 가상 머신을 위해 정의되고, 상기 다른 명령 차단 값을 세트 하는 것은 물리적 프로세서를 사용하도록 상기 다른 가상 머신을 인에이블 하는 것에 응답하여 하며; 그리고 상기 다른 명령 차단 값이 상기 명령의 실행을 허가하는 것에 응답하여, 상기 다른 가상 머신이 물리적 프로세서를 사용하도록 인에이블 되는 동안 상기 물리적 프로세서에 의한 명령의 실행을 허가하고; 그리고 상기 다른 명령 차단 값이 상기 명령의 실행을 허가하지 않는 것에 응답하여, 상기 다른 가상 머신이 물리적 프로세서를 사용하도록 인에이블 되는 동안 상기 다른 물리적 프로세서에 의한 명령의 실행을 허가하지 않는다.

한 실시 예에서, 명령이 허가된 펑션 코드를 채용하는 것에 응답하여 상기 명령은 허가된 명령이 되며, 명령이 허가되지 않은 펑션 코드를 채용하는 것에 응답하여 상기 명령은 허가되지 않은 명령이 된다.

한 실시 예에서, 명령의 오피코드를 명령 차단 값에 연관 시킴으로써 상기 명령이 허가된 명령인지에 관한 결정이 내려진다.

한 실시 예에서, 페치된 명령은 수행될 펑션을 명시하며(specify), 상기 명령의 오피코드는 명령 차단 값을 찾아내기 위해 테이블 내에 인덱스하기 위해 사용되고, 상기 명령 차단 값은 허가 필드(a permission field)를 포함하며, 상기 허가 필드는 허가된 펑션들을 결정하기 위해 사용된다. 펑션이 허가된 펑션이라는 것에 응답하여, 명령의 실행을 허가하고, 펑션이 허가되지 않은 펑션이라는 것에 응답하여, 명령의 실행을 허가하지 않는다.

전술한 내용은 추가의 목적들, 특징들, 및 장점들과 함께 아래의 상세한 설명에서 자세히 설명될 것이다.

본 발명의 실시 예들은 아래에 첨부된 도면들을 참조하여 설명하는데, 이 설명은 어디까지나 예로서만 제공되는 것이다.
도 1a는 하나의 예시적인 호스트 컴퓨터를 도시한다:
도 1b는 하나의 예시적인 에뮬레이션 호스트 컴퓨터를 도시한다:
도 1c는 하나의 예시적인 컴퓨터 시스템을 도시한다.
도 2는 하나의 예시적인 컴퓨터 네트웍을 도시한다.
도 3은 컴퓨터 시스템의 하나의 예시적인 엘리멘트들을 도시한다.
도 4a는 하나의 예시적인 실행 유닛을 도시한다.
도 4b는 하나의 예시적인 브랜치 유닛을 도시한다.
도 4c는 하나의 예시적인 로드/스토어 유닛을 도시한다.
도 5는 하나의 예시적인 논리적 파티션닝을 도시한다.
도 6은 예시적인 논리적 파티션닝 엘리멘트들을 도시한다.
도 7은 예시적인 논리적 파티션닝 엘리멘트들을 도시한다.
도 8은 하나의 예시적인 오피코드 테이블을 도시하는 흐름도(a flow)이다.
도 9은 하나의 예시적인 차단 기술(blocking technique)을 도시하는 흐름도이다.
도 10은 하나의 예시적인 차단 기술(blocking technique)을 도시하는 흐름도이다.
도 11은 하나의 예시적인 차단 기술(blocking technique)을 도시하는 흐름도이다: 그리고
도 12-15는 명령 차단 기술들(instruction blocking techniques)의 흐름도들을 도시한다.

실시 예는 소프트웨어(때때로 라이선스된 내부코드, 펌웨어, 마이크로-코드, 밀리-코드, 픽코-코드 등으로 일컬어 진다)에 의해서 실시될 수 있다. 도 1a를 참조하면, 소프트웨어 프로그램 코드 실시 예는 통상적으로 CPU(중앙 처리 유닛)로 알려진 시스템 (50)의 프로세서 (1)에 의해서 롱-텀 스토리지 매체(11), 예를 들어, CD-ROM드라이브, 테이프 드라이브 혹은 하드 드라이브로부터 억세스된다. 상기 소프트웨어 프로그램 코드는 디스켓, 하드 드라이브, 혹은 CD-ROM 같은 데이터 처리 시스템에 사용되는 모든 공지의 매체들 상에 구현될 수 있다. 상기 코드는 그러한 매체 상에서 배포될 수 있고, 또는 네트웍(10)을 통해서 컴퓨터 메모리(2) 혹은 한 컴퓨터 시스템의 스토리지로부터 다른 컴퓨터 시스템들에 그러한 다른 컴퓨터 시스템들의 유저들에 의한 사용을 위해 유저들에게 배포될 수 있다.

이와 달리, 상기 프로그램 코드는 메모리(2)에 구현되어, 프로세서 버스를 사용하여 프로세서(1)에 의해서 억세스 될 수 있다. 그러한 프로그램 코드는 운영체제를 포함하는데, 이는 다양한 컴퓨터 콤포넨트들 및 하나 혹은 그 이상의 어플리케이션 프로그램들의 펑션과 상호 작용을 제어한다. 프로그램 코드는 일반적으로 대용량 스토리지 매체(1)로부터 고속 메모리(2)로 페이지 되어서(paged) 상기 프로세서에 의한 처리를 위해 이용 가능하게 된다. 소프트웨어 프로그램 코드를 메모리에, 물리적 매체에 구현하기 위한 기술 및 방법들, 및/또는 네트웍들을 통해서 소프트웨어 코드를 배포하는 기술 및 방법들은 잘 알려져 있으므로 여기서 더 상세하게 논의하지 않는다. 프로그램 코드는, 유형의 매체(전자 메모리 모듈들(RAM), 플래시 메모리, 컴팩트 디스크들(CD들), DVD들, 자기 테이프 등을 포함하나 이에 한정되지 않음)상에서 생성되어 저장되었을 때, “컴퓨터 프로그램 제품”이라 한다. 컴퓨터 프로그램 제품 매체는 통상적으로 처리 회로에 의해서, 바람직하기는 상기 처리회로에 의한 실행을 위한 컴퓨터 시스템 내에서 판독가능하다.

도 1c는 본 발명의 실시 예들이 실시될 수 있는 대표적인 워크 스테이션 혹은 서버 하드웨어 시스템을 도시한다. 도 1c의 시스템(100)은 대표적인 컴퓨터 시스템(101)을 포함하는데, 이는 개인용 컴퓨터, 워크스테이션 혹은 서버를 포함하며, 선택적으로 주변장치들도 포함한다. 워크스테이션(101)은 하나 혹은 그 이상의 프로세서들(106) 및 버스를 포함하며, 버스는 공지의 기술에 따라 프로세서들(106)과 시스템(101)의 다른 콤포넨트들 사이에 통신을 연결하고 인에이블 하기 위해 채용된다. 상기 버스는 프로세서(106)을 메모리(105) 및 롱-텀 스토리지(107) 연결하며, 롱텀 스토리지는 예를 들어 하드 드라이브(예를 들어, 모든 자기 매체, CD, DVD 및 플래시 메모리를 포함하는) 혹은 테이프 드라이브를 포함할 수 있다. 시스템(101)은 또한 유저 인터페이스 어댑터를 포함할 수 있는데, 이는 버스를 통해서 마이크로프로세서(106)을 하나 혹은 그 이상의 인터페이스 디바이스들, 예를 들어 키보드(104), 마우스(103), 프린터/스캐너(110) 및/또는 기타 인터페이스 디바이스들 - 이들은 터치 센시티브 스크린(a touch sensitive screen), 디지타이즈드 엔트리 패드(digitized entry pad) 등과 같은 모든 유저 인터페이스 디바이스를 포함할 수 있다-에 연결시킨다. 상기 버스는 또한 디스플레이 디바이스(102), 예를 들어 LCD스크린, 혹은 모니터를 디스플레이 어댑터를 통해서 마이크로프로세서(106)에 연결시킬 수 있다.

시스템(101)은 다른 컴퓨터들 혹은 다른 컴퓨터들의 네트웍들과 통신할 수 있는데, 다른 컴퓨터들의 네트웍들과의 통신은 네트웍(109)와 통신할 수 있는(108) 네트웍 어댑터들을 통해서 할 수 있다. 네트웍 어댑터들의 예에는 커뮤니케이션 채널들(communications channels), 토큰 링(token ring), 이더넷(Ethernet) 혹은 모뎀들(modems)이 있다. 이와 달리, 워크스테이션(101)은 CDPD(셀룰러 디지털 패킷 데이터)카드와 같은 무선 인터페이스를 사용하여 통신할 수 있다. 워크스테이션(101)은 근거리 네트웍(LAN) 혹은 광역 네트웍(WAN)으로 다른 컴퓨터들과 연결될 수 있거나 혹은 워크스테이션(101)은 다른 컴퓨터 등과 클라이언트/서버 구성에서 클라이언트가 될 수도 있다. 모든 이러한 구성들은, 적절한 통신 하드웨어 및 소프트웨어와 함께, 이 분야에 알려져 있다.

도 2는 본 발명의 실시 예가 실시될 수 있는 데이터 처리 네트웍(200)을 도시한다. 데이터 처리 네트웍(200)은 복수의 개별 네트웍들, 예를 들어 무선 네트웍 및 유선 네트웍을 포함할 수 있는데, 이들 각각은 복수의 워크스테이션들(101, 201, 202, 203, 204)를 포함할 수 있다. 이외에도, 당업자들이 알수 있듯이, 하나 혹은 그 이상의 LAN들이 포함될 수 있으며, 여기서 LAN은 호스트 컴퓨터에 결합된 복수의 지능 워크스테이션들을 포함할 수 있다.

도 2를 다시 참조하면, 네트웍들은 또한 메인프레임 컴퓨터들 혹은 서버들, 예를 들어 게이트웨이 컴퓨터(클라이언트 서버 206) 혹은 어플리케이션 서버(원격 서버 208, 이는 데이터 저장소를 억세스할 수 있고 또한 워크스테이션 205로부터 직접 억세스될 수 있다)를 포함할 수 있다. 게이트웨이 컴퓨터(206)은 각각의 네트웍(207)로 들어오는 엔트리 포인트로서 기능을 한다. 하나의 네트워킹 프로토콜을 다른 네트워킹 프로토콜에 연결할 때 게이트웨이(gateway)가 필요하다. 게이트웨이(206)은 통신 링크를 통해서 바람직하게도 다른 네트웍(예를 들어 인터넷)에 결합될 수 있다. 게이트웨이(206)은 또한 통신 링크를 사용하여 직접적으로 하나 혹은 그 이상의 워크스테이션들(101, 201, 202, 203, 204)에 결합될 수 있다. 상기 게이트웨이 컴퓨터는 IBM Corp으로부터 구입 가능한 IBM eServer™ zSeries® z9® Server 를 이용하여 구현될 수 있다.

소프트웨어 프로그래밍 코드는 통상적으로 시스템(101)의 프로세서(106)에 의해서 롱-텀 스토리지 매체(107), 예를 들어 CD-ROM드라이브 혹은 하드 드라이브로부터 억세스 된다. 상기 소프트웨어 프로그래밍 코드는 데이터 처리 시스템에 사용하기 위한 모든 종류의 알려진 매체, 예를 들어 디스켓, 하드 드라이브, 혹은 CD-ROM 상에 구현될 수 있다. 상기 코드는 그러한 매체 상에서 배포될 수도 있고, 혹은 네트웍을 통해서 한 컴퓨터의 메모리 혹은 스토리지로부터 다른 컴퓨터 시스템들에 그러한 다른 시스템들의 유저들에 의해서 사용하기 위해 유저들(210, 211)에게 배포될 수 있다.

이와 달리, 상기 프로그램 코드 (111)은 메모리(105)에 구현되어, 프로세서 버스를 사용하여 프로세서(106)에 의해서 억세스 될 수 있다. 그러한 프로그램 코드는 운영체제를 포함하는데, 이는 다양한 컴퓨터 콤포넨트들 및 하나 혹은 그 이상의 어플리케이션 프로그램들(112)의 펑션과 상호 작용을 제어한다. 프로그램 코드는 일반적으로 대용량 스토리지 매체(107)로부터 고속 메모리(105)로 페이지 되어서(paged) 상기 프로세서(106)에 의한 처리를 위해 이용 가능하게 된다. 소프트웨어 프로그램 코드를 메모리에, 물리적 매체에 구현하기 위한 기술 및 방법들, 및/또는 네트웍들을 통해서 소프트웨어 코드를 배포하는 기술 및 방법들은 잘 알려져 있으므로 여기서 더 상세하게 논의하지 않는다. 프로그램 코드는, 유형의 매체(전자 메모리 모듈들(RAM), 플래시 메모리, 컴팩트 디스크들(CD들), DVD들, 자기 테이프 등을 포함하나 이에 한정되지 않음)상에서 생성되어 저장되었을 때, “컴퓨터 프로그램 제품”이라 한다. 컴퓨터 프로그램 제품 매체는 통상적으로 처리 회로에 의해서, 바람직하기는 상기 처리회로에 의한 실행을 위한 컴퓨터 시스템 내에서 판독 가능하다.

상기 프로세서에 대하여 가장 빠르게 이용 가능한 캐시(보통으로 상기 프로세서의 다른 캐시들보다 더 바르고 더 적음)는 가장 낮은 레벨의 캐시(L1 혹은 레벨 1)이고, 메인 스토어(메인 메모리)는 가장 높은 레벨의 캐시(3 레벨이 있다면 L3)이다. 가장 낮은 레벨의 캐시는 종종 실행될 머신 명령들을 보유하는 명령 캐시(I-Cache)와 데이터 오퍼런드들(data operands)을 보유하는 데이터 캐시(D-Cache)로 나누어진다.

도 3을 참조하면, 한 예시적 프로세서 실시 예가 프로세서(106)으로 도시되어 있다. 통상적으로 하나 혹은 그 이상의 레벨들의 캐시(303)이 메모리 블록들을 버퍼하기(buffer) 위해 채용되는데 이는 프로세서 성능을 향상시키기 위함이다. 캐시(303)은 고속 버퍼이며, 사용 가능성이 높은 메모리 데이터의 캐시 라인들을 저장한다. 통상적인 캐시 라인들은 64, 128, 혹은 256바이트들의 메모리 데이터이다. 명령들을 캐싱하기 위해서 데이터를 캐싱하는 캐시와 분리된 캐시들이 종종 채용된다. 캐시 일관성(cache coherence) (메모리와 캐시들의 복사본 라인들의 동기)은 종종 공지 기술에서 잘 알려진 다양한 “스누프” 알고리즘들에 의해서 제공된다. 프로세서 시스템의 메인 스토리지(105)는 종종 캐시라고 일컬어진다. 4 레벨의 캐시(303)을 갖는 프로세서 시스템에서, 메인 스토리지(105)는 때때로 레벨 5(L5) 캐시로 일컬어지는데 이는 통상적으로 더 빠르고 컴퓨터 시스템에 이용 가능한 비휘발성 스토리지(DASD, 테이프 등)의 부분만을 저장하기 때문이다. 메인 스토리지(105)는 운영체제에 의해서 메인 스토리지(105)에 페이지 인되고(page in) 페이지 아웃되는(page out) 데이터 페이지들을 “캐시”한다.

프로그램 카운터(명령 카운터) (311)은 실행될 현재의 명령의 주소를 추적한다. z/Architecture 프로세서에서, 프로그램 카운터는 64비트 이고 사전 어드레싱 한계들(prior addressing limits)을 지원하기 위해서 31 혹은 24비트로 트런케이트될 수 있다(truncated). 프로그램 카운터는 컨텍스트 스위칭(context switching) 동안 유지될 수 있도록 통상적으로 컴퓨터의 PSW(프로그램 상태 워드) 내에 구현될 수 있다. 따라서, 프로그램 카운터 값을 갖고 있는, 진행중인 프로그램은, 예를 들어, 운영체제에 의해서 인터럽트될 수 있다(interrupted) (상기 프로그램 환경에서 운영체제 환경으로 컨텍스트 스위치 될 수 있다). 상기 프로그램의 PSW는 상기 프로그램이 동작하지 않고 있는(not active) 동안 프로그램 카운터 값을 유지하고, 운영체제가 실행하는 동안은 운영 체제의 프로그램 카운터가 사용된다. 통상적으로, 프로그램 카운터는 현재 명령의 바이트 수에 해당하는 양만큼 증가된다. RISC(축소 명령 세트 컴퓨팅) 명령들은 통상적으로 고정된 길이를 가지며 한편 CISC(복합 명령 세트 컴퓨팅) 명령들은 통상적으로 가변 길이를 갖는다. IBM z/Architecture의 명령들은 CISC 명령들이며 2, 4 혹은 6바이트의 길이를 갖는다. 프로그램 카운터(311)은 예를 들어 컨텍스트 스위치 동작(context switch operation) 혹은 브랜치 명령의 브랜치 테이큰 동작(Branch taken operation)에 의해서 수정된다(modified). 컨텍스트 스위치 동작으로, 현재 프로그램 카운터 값은 현재 실행중인 프로그램에 관한 기타 상태 정보(예를 들어 컨디션 코드들)와 함께 프로그램 상태 워드(PSW)에 저장되고, 새로운 프로그램 카운터 값이 로드 되어 실행될 새로운 프로그램 모듈의 명령을 가리킨다(pointing). 브랜치 명령의 결과를 프로그램 카운터(311)에 로드함으로써 프로그램이 결정들을 내리거나 혹은 프로그램 내에서 루프동작을 하도록 하기 위해서 브랜치 테이컨 동작(branch taken operation)이 수행된다.

통상적으로 명령 페치 유닛(instruction fetch unit)(305)가 채용되어 프로세서(106)을 대신하여 명령들을 페치한다. 상기 페치 유닛은 다음 순차 명령들, 브랜치 테이컨 명령들의 타겟 명령들 혹은 컨텍스트 스위치 다음에 오는 프로그램의 첫 번째 명령을 페치한다. 현대의 명령 페치 유닛들은 종종 프리페치 기술(prefetch techniques)을 채용해서 프리페치된 명령들이 사용될 가능성에 기초하여 추측하여 명령들을 미리 페치한다. 예를 들어, 페치 유닛이 16바이트의 명령을 페치할 수 있는데, 이 명령은 다음 순차 명령과 그 다음 순차 명령들에 관하여 추가의 바이트들을 포함할 수 있다.

상기 페치된 명령들은 그 다음에 프로세서(106)에 의해서 실행된다. 한 실시 예에서, 상기 페치된 명령(들)은 상기 페치 유닛의 디스패치 유닛(dispatch unit)(306)으로 전송된다. 상기 디스패치 유닛은 상기 명령들을 디코드 하여 상기 디코드된 명령(들)에 관한 정보를 적절한 유닛들(307,308,310)으로 포워드한다(forward). 실행 유닛(307)은 통상적으로 명령 페치 유닛(305)로부터 디코드된 산술연산 명령들에 관한 정보를 수신하여 상기 명령의 오피코드(opcode)에 따라 오퍼런드들(operands)에 관하여 산술연산 동작들(arithmetic operations)을 수행한다. 오퍼런드들은 상기 실행 유닛(307)에 제공되는데 바람직하기는 메모리(105), 아키텍처된 레지스터들(309)로부터 혹은 실행되는 명령의 직접 필드(immediate field)로부터 제공된다. 실행 결과들이 저장될 때, 메모리(105), 레지스터들(309) 혹은 기타 머신 하드웨어(예를 들어, 제어 레지스터들, PSW레지스터들 등)에 저장된다.

도 5를 참조하면, 예시적 가상 머신(VM) 환경이 도시되어 있다. 하이퍼바이저 프로그램(hypervisor program) (이는 IBM의 zVM과 같은 운영체제(OS)일 수 있다)이 복수의 물리적 프로세서들, 물리적 메인 메모리 그리고 물리적 어댑터들을 포함하는 멀티-프로세서”하드웨어” 컴퓨터 시스템 상에서 실행되고 있을 수 있으며, 물리적 어댑터들은 스토리지, 네트웍들, 디스플레이들 등을 포함하는 I/O 주변장치들과 통신을 하기 위한 것이다. 상기 하이퍼바이저는 VM 이미지들(예를 들어 VM1, VM2 및 VM3)를 생성하는데, 이들은 OS 및 어플리케이션 프로그램들을 포함하는 소프트웨어가 가상의 리소스들을 이용하는 가상 머신 내에서 실행될 수 있게 한다. VM 내에서 실행되는 소프트웨어는 자신이 VM 내에서 실행되고 있다는 사실을 알지 못하고 가상의 리소스들을 마치 물리적 리소스들인 것처럼 사용하면서 동작한다. IBM의 zVM 운영체제는 “게스트”이미지들을 생성할 수 있는데, 각각의 게스트 이미지는 실제로 가상 머신이 된다. 더 나아가, 모든 zVM 게스트는 스스로 zVM OS를 실행하여 “제 2 레벨의 게스트들”을 생성할 수 있다. 따라서, 가상 머신(게스트 이미지)는 가상 머신들의 계층적 구조 내에 네스트될 수 있는데 (nested), 이 계층 구조에서 각각의 zVM은 자신의 게스트 이미지들을 위한 하이퍼바이저 역할을 한다. 한편, 멀티-프로세서 플랫폼(multi-processor platform)은 “물리적으로 파티션될” 수 있는데, 각각의 물리적 파티션에는 리소스들(프로세서들, 메모리, I/O)이 할당될 수 있다. 각각의 물리적 파티션은 VM이 되는데, 그 이유는 그 파티션 내에서 실행되는 소프트웨어는 그 파티션에 할당되지 않은 머신의 리소스들은 알지 못하기 때문이다. 따라서, 머신의 리소스들은 “가상화” 된다. 다른 실시 예에서 논리적 파티션들이 VM들이 된다.

게스트들(Guests), 가상 머신들(VM들) 및 논리적 파티션들(Logical partitions)의 용어들은 여기서 서로교환 가능하게 사용될 수 있으며, 또한 컴퓨터 시스템 이미지를 가상화하는 많은 방법들은 공지 기술에 알려져 있다.

가상화는 예를 들어 VMware®의 백서에 기술되어 있는데, 그 명칭은 VMware® 의 “가상화 개요” 및” VMware VMotion 및 CPU 양립성” VMware® Infrastructure 3 이다. 더 나아가, 공개 번호 2009/0070760 로 알려진 2007년 9월 6일 Khatri및 공동 발명자들에 의해서 출원된 "프로세서 아키텍처들 사이에서의 가상 머신(VM) 마이그레이션(VIRTUAL MACHINE (VM) MIGRATION BETWEEN PROCESSOR ARCHITECTURES)" 이라는 제목의 미국 특허출원은 CPUID 레지스터의 선택된 비트들을 마스킹함으로써 머신들의 유사한 풀들 가운데 VM 마이그레이션을 가능케 하기 위해 특정의 피처 세트(certain feature set)를 에뮬레이트하는 것을 기술한다.

도 6을 참조하면, 각각의 VM은 다른 OS와 다른 어플리케이션들을 가질 수 있다. 예를 들어, OS1은 IBM의 z/OS이고 OS2는 IBM의 zLinux이거나 혹은 모든 OS들이 동일 OS들, 즉 z/OS들이 될 수 있다.

상기 하이퍼바이저는 물리적 피처들(physical features), 리소스들(resources) 및 능력들(capabilities)에 기초하여 각각의 VM을 위해 논리적 피처들, 자원들 및 능력들을 생성한다. 한 예시적 시스템에서, 물리적 메모리 부분들은 동적 주소 변환부를 통해서 각각의 VM에 할당되고, 물리적 프로세서들은 I/O 능력(capability)과 마찬가지로 VM들 사이에서 시간-공유(time-shared)될 수 있다.

도 7을 참조하면, 각각의 논리적 프로세서는 하이퍼바이저 관리된 논리적 피처 마스크(Hypervisor managed Logical Feature Mask)를 통해 물리적 피처 레지스터들(physical feature registers)을 억세스 할 수 있다. 따라서, 논리적 프로세서들 상에서 실행되는 소프트웨어는, 실제 프로세서들이 다른 아키텍처 레벨들에 있더라도, 공동 프로세서 아키텍처 레벨(common processor Architecture level) 상에서 동작하는 것처럼 보일 수 있다. 한 예에서, 상기 물리적 피처 레지스터는 Intel CPUID레지스터일 수 있는데, 이는 Intel 프로세서의 아키텍처 레벨을 표시하고 또한 프로그래머에게 이용 가능한 특정 피처들(specific features)를 표시한다. 상기 논리적 피처 마스크는 VM이 대응 논리적 프로세서의 CPU ID를 조사(query)할 때 가상 머신(VM) 내의 소프트웨어에 대하여 물리적 프로세서들 CPUID의 전부 혹은 서브세트를 제공하도록 프로그램된다.

Intel® x86 프로세서 아키텍처, "Intel® Itanium® 아키텍처 소프트웨어 개발자 매뉴얼(Volume 2, Revision 2.2, 2006년 1월)"은 CPUID 레지스터들을 제공하는데, 이는 프로세서에 의해서 지원되는 피처들을 식별하기 위해서이다. CPUID 레지스터들은 특권이 없고(unprivileged) 인디렉트 무브 명령(the indirect move (from) instruction)을 사용하여 억세스된다. 레지스터 CPUID 수를 초과하는 모든 레지스터들은 유보되어 있으며(reserved) 만일 억세스되면 유보된 레지스터/필드 폴트(Reserved Register/Field fault)를 발령한다(raise). 라이트들(writes)은 허가되지 않고 그러한 동작을 위한 아무런 명령도 존재하지 않는다. 벤더 정보는 CPUID레지스터들 0 및 1에 위치하며, 프로세서 구현을 위해, ASCII로, 벤더 이름을 명시한다. 스트링의 끝 이후 16번째 바이트까지(after the end of the string up to the 16th byte) 모든 바이트들이 제로(0)이다. 이전의 ASCII 문자들(earlier ASCII characters)은 하위 번호 레지스터들(lower number registers)과 하위 번호 매겨진 바이트 포지션들(lower numbered byte positions) 에 위치한다. CPUID 레지스터 4는 프로세서 피처들에 관한 일반 어플리케이션-레벨 정보를 제공한다. 이것은 한 세트의 플래그 비트들(a set of flag bits)을 포함하는데, 이 플래그 비트들은 주어진 피처가 그 프로세서 모델에서 지원되는지 여부를 표시하기 위해 사용된다. 예들 들어, 하나의 비트가 1(one)이면 그 피처는 지원된다는 것이고; 0(zero)이면 그 피처는 지원되지 않는다는 것을 의미한다. 미래의 프로세서 모델들에서 새로운 피처들이 추가되면(제거되면), 그러한 새로운 피처들의 추가(혹은 제거)는 새로운 피처 비트들에 의해서 표시된다. CPUID레지스터 4는 논리적으로 2개의 반쪽부분들(two halves)로 나누어지는데, 이들 둘은 모두 일반 피처(general feature)와 능력 정보(capability information)를 포함하지만, 다른 사용 모델들(different usage models) 및 억세스 능력들(access capabilities)를 가질 수 있으며; 이 정보는 모든 인에이블된 혹은 디스에이블된 피처들의 상태를 반영한다. CPUID 레지스터 4의 상위 및 하위 반쪽 부분들 모두 무브 인디렉트 레지스터 명령(the move indirect register instruction)을 통해서 억세스 가능하다; 구현에 따라서, 이 억세스를 위한 대기시간(latency)은 길어질 수도 있으며 이 억세스 방법은 셀프-실렉션(self-selection)을 사용하는 낮은-대기시간 코드 버저닝(low-latency code versioning)에 대해서는 적합하지 않을 수 있다. 이외에도, CPUID 레지스터 4의 상위 반쪽부분도 또한 테스트 피처 명령(the test feature instruction)을 사용하여 억세스가 가능하다; 이 억세스에 대한 대기시간은 테스트 비트 명령의 그 것과 비교할만하며 이 억세스 방법은 셀프-실렉션을 사용하는 낮은-대기시간 코드 버저닝을 가능하게 한다.

z/Architecture의 동작 원리들(The z/Architecture Principles of Operation)은 스토어 퍼실리티 목록 확장(STFLE) 명령(Store Facility List Extended (STFLE) instruction)을 제공하는데, 이는 Intel CPUID레지스터처럼 소프트웨어에 하부의(underlying) 중앙 처리 유닛들(CPU들) 혹은 프로세서들의 피처들(혹은 아키텍처 레벨들)에 관한 지식을 제공한다. 상기 STFLE 명령은 아래의 테이블 1에 도시한 포맷을 갖는다.

표 1

STFLE 명령(테이블 1)은 오피코드 필드 비트들(0-15), 레지스터 필드 B2(16-19) 및 변위(displacement)(직접: immediate) 필드 D2 (20-31)를 포함한다. 머신에 의한 STFLE 명령의 실행은 프로그램 내의 퍼실리티들에 관한 정보를 제공하는 비트들의 목록을 메모리 로케이션에 저장하는데, 이 메모리 로케이션은 상기 명령의 B2 필드에 의해서 지정된 레지스터의 컨텐츠를 12비트 D2 직접 필드에 추가함으로써 결정되며, 상기 메모리 로케이션은 제 2 오퍼런드 주소((B2)+D2)에 의해서 지정된 더블워드(8바이트, 한 워드는 4바이트이다)에서 시작한다. z/Architecture에서 상기 프로그램 메모리 로케이션의 주소는 동적 주소 변환부(DAT)에 의해서 결정된다.

유보된 비트들(reserved bits)은 퍼실리티를 표시하도록 현재 할당되지 않은 비트들이다. 퍼실리티 비트들(facility bits)이 할당되는 최좌측 더블워드들(the leftmost doublewords)을 위해서, 상기 유보된 비트들은 제로들로 저장된다. 최 상위 번호매겨진 퍼실리티 비트(the highest-numbered facility bit)가 하나의 모델을 위해 할당되는 더블워드 우측 편의 더블워드들(Doublewords to the right of the doubleword)은 저장될 수도 안될 수도 있다. 억세스 예외들(access exceptions) 및 PER 이벤트들은 저장되지 않은 더블워드들을 위해 인정되지 않는다. 더블워드들에서, 제 2 오퍼런드의 크기는 일반 레지스터 0의 비트들 56-63에 지정된 값보다 하나 더 크다. 일반 레지스터 0의 나머지 비트들은 할당되지 않고 제로들을 포함한다; 그렇지 않으면, 프로그램은 나중에 양립하여(compatibly) 동작하지 못할 수 있다.

제 2 오퍼런드의 크기가 하나의 모델을 위해 할당된 모든 퍼실리티 비트들을 포함할 수 있을 만큼 큰 경우에는, 완전한 퍼실리티 목록이 제 2 오퍼런드 로케이션에 저장되고, 일반 레지스터 0의 비트들 56-63은 상기 모델을 위해 할당된 모든 퍼실리티 비트들을 포함하기 위해 필요한 더블워드들의 수보다 하나 적은 수를 포함하도록 업데이트 되며, 그리고 컨디션 코드 0은 세트된다.

제 2 오퍼런드의 크기가 하나의 모델을 위해 할당된 모든 퍼실리티 비트들을 포함할 수 있을 만큼 크지 않은 경우에는, 제 2 오퍼런드 크기에 의해서 지정된 더블워드들의 수만 저장되고, 일반 레지스터 0의 비트들 56-63은 상기 모델을 위해 할당된 모든 퍼실리티 비트들을 포함하기 위해 필요한 더블워드들의 수보다 하나 적은 수를 포함하도록 업데이트 되며, 그리고 컨디션 코드 3은 세트된다.

명령의 실행은 컨디션 코드 값의 세팅을 초래하며, 상기 컨디션 코드 값은 컨텍스트 스위칭 동안 프로그램 상태 워드(PSW)에 저장된다.

특별 컨디션들(Special Conditions):

상기 제 2 오퍼런드는 더블워드 경계 상에(on doubleword boundary) 지정되어야 하며; 그렇지 않으면, 사양 예외(a specification exception)가 인정된다.

컨디션 코드의 결과(Resulting Condition Code):

0 완전한 퍼실리티 목록이 저장됨

1 -

2 -

3 불완전한 퍼실리티 목록이 저장됨

프로그램 예외들(Program Exceptions):

억세스(스토어, 제 2 오퍼런드)

동작(Operation) (만일 스토어-퍼실리티-목록-확장 퍼실리티가 설치되지 않았다면)

사양(Specification)

프로그래밍 노트들(Programming Notes):

스토어 퍼실리티 목록 확장(STORE FACILITY LIST EXTENDED)의 성능은 스토리지 내의 한 바이트를 단순히 테스트하는 것보다 대단히 느릴 수 있다(slower). 퍼실리티의 존재에 대한 테스트를 빈번하게 수행할 필요가 있는 프로그램들, 예를 들어, 퍼실리티가 하나의 경로에서는 사용되고 다른 경로에서는 사용되지 않는 듀얼-패스 코드(dual-path code)는 확장 스토어 퍼실리티 목록 명령을, 초기화 동안 한번은, 실행해야 한다. 그 다음에, 그 프로그램은 마스크 하의 테스트(TEST UNDER MASK)라는 명령을 사용하여, 저장된 결과를 조사함으로써 퍼실리티 존재에 관하여 테스트할 수 있다.

컨디션 코드 0이 세트된 경우, 일반 레지스터 0의 비트들 56-63은 저장된 더블워드들의 수를 표시하기 위해 업데이트된다. 만일 상기 프로그램이 일반 레지스터 0 내의 결과들을 무시하기로 선택한다면, 스토리지 내의 전체 제 2 오퍼런드가 스토어 퍼실리티 목록 확장(STORE FACILITY LIST EXTENDED)을 수행하기 전에 제로로 세트됨을 보장해야 한다.

테이블 2는 STFLE 비트들과 그들의 의미를 부여한 종래 기술의 z/Architecture를 보여준다. 만일 그 의미(its meaning)가 참(true)이면 현재 아키텍처 모드에 상관없이 하나의 비트가 1(one)로 세트된다. 어떤 의미가 특정 아키텍처 모드에 적용된다고 하는 경우가 아닌 한 그 의미는 현재 아키텍처 모드에 대하여 적용된다.

할당되지 않은 비트들은 새로운 퍼실리티들의 표시를 위해 유보된다; 이들 비트들은 나중에 1들로서 저장될 수 있다.

종래의 z/Architecture 퍼실리티 목록은 아래의 테이블 2에서 보여주는 것처럼 정의된다.

표 2

비트가 1(one)일 때 비트의 의미(Bit Meaning-When-Bit-Is-One):

0 z/Architecture의 제 7 및 10장의 명령 요약 피겨들(the instruction summary figures)에서 “N3”으로 표시된 명령들이 설치된다(installed).

1 z/Architecture 아키텍처 모드가 설치된다.

2 z/Architecture 아키텍처 모드가 액티브이다(active). 이 비트가 제로인 경우, ESA/390 아키텍처 모드가 액티브이다.

3 DAT-향상 퍼실리티(DAT-enhancement facility)가 z/Architecture 아키텍처 모드 내에 설치된다. DAT 향상 퍼실리티는 INVALIDATE DAT TABLE ENTRY(IDTE) 및 COMPLETE AND SWAP AND PURGE(CSPG)명령들을 포함한다.

4 INVALIDATE DAT TABLE ENTRY(IDTE)는 세그멘트-테이블 엔트리 혹은 엔트리들이 무효되었을 때 결합된 리전-및-세그멘트 엔트리들(combined region-and-segment table entries)을 선택적으로 클리어함으로써 무효화-및-클리어링 오퍼레이션(the invalidation-and-clearing operation)을 수행한다. IDTE는 또한 클리어링-바이-ASCE 오퍼레이션(clearing-by-ASCE operation)을 수행한다. 비트 4가 1인 한, IDTE는 단순히 모든 TLB들을 퍼지(purge)한다. 비트 4가 1이면, 비트 3도 1이다.

5 INVALIDATE DAT TABLE ENTRY(IDTE)는 리전-테이블 엔트리 혹은 엔트리들(region-table entry or entries)이 무효 되었을 때 결합된 리전-및-세그멘트 엔트리들(combined region-and-segment table entries)을 선택적으로 클리어함으로써 무효-및-클리어링 오퍼레이션(the invalidation-and-clearing operation)을 수행한다. 비트 5가 1이면, 비트들 3 및 4도 1이다.

6 ASN-및-LX 재사용 퍼실리티(ASN-and-LX reuse facility)가 z/Architecture 아키텍처 모드에 설치된다.

7 스토어-퍼실리티-목록-확장 퍼실리티(store-facility-list-extended facility)가 설치된다.

8 향상된-DAT 퍼실리티(enhanced-DAT facility)가 z/Architecture 아키텍처 모드에 설치된다.

9 센스-실행-상태 퍼실리티(sense-running-status facility)가 z/Architecture 아키텍처 모드에 설치된다.

10 컨디셔널-SSKE 퍼실리티(conditional-SSKE facility)가 z/Architecture 아키텍처 모드에 설치된다.

11 구성-토폴러지 퍼실리티(configuration-topology facility)가 z/Architecture 아키텍처 모드에 설치된다.

16 확장-변환 퍼실리티 2(extended-translation facility 2)가 설치된다.

17 메시지-보안 지원(message security assist)이 설치된다.

18 긴-변위 퍼실리티(long-displacement facility)가 z/Architecture 아키텍처 모드에 설치된다.

19 긴-변위 퍼실리티(long-displacement facility)는 고성능(high performance)을 갖는다. 비트19가 1이면 비트 18도 1이다.

20 HFP-곱셈-및-덧셈/뺄셈 퍼실리티(HFP-multiply-and-add/subtract facility)가 설치된다.

21 확장-직접 퍼실리티(extended-immediate facility)가 z/Architecture 아키텍처 모드에 설치된다.

22 확장-변환 퍼실리티 3(extended-translation facility 3)이 z/Architecture 아키텍처 모드에 설치된다.

23 HFP-비정규화-확장 퍼실리티(HFP-unnormalized-extension facility)가 z/Architecture 아키텍처 모드에 설치된다.

24 ETF2-향상 퍼실리티(ETF2-enhancement facility)가 설치된다.

25 스토어-클럭-패스트 퍼실리티(store-clock-fast facility)가 z/Architecture 아키텍처 모드에 설치된다.

26 파싱-향상 퍼실리티(parsing-enhancement facility)가 z/Architecture 아키텍처 모드에 설치된다.

27 선택-사양들을-갖는-무브 퍼실리티(move-with-optional-specifications facility)가 z/Architecture 아키텍처 모드에 설치된다.

28 TOD-클럭-운영 퍼실리티(TOD-clock-steering facility)가 z/Architecture 아키텍처 모드에 설치된다.

30 ETF3-향상 퍼실리티(ETF3-enhancement facility)가 z/Architecture 아키텍처 모드에 설치된다.

31 익스트랙트-CPU-타임 퍼실리티(extract-CPU-time facility)가 z/Architecture 아키텍처 모드에 설치된다.

32 비교-및-교환-및-스토어 퍼실리티(compare-and-swap-and-store facility)가 z/Architecture 아키텍처 모드에 설치된다.

33 비교-및-교환-및-스토어 퍼실리티 2(compare-and-swap-and-store facility 2)가 z/Architecture 아키텍처 모드에 설치된다.

34 일반-명령들-확장 퍼실리티(general-instructions-extension facility)가 z/Architecture 아키텍처 모드에 설치된다.

35 실행-확장들 퍼실리티(execute-extensions facility)가 z/Architecture 아키텍처 모드에 설치된다.

39 IBM 내부 사용에 할당됨(assigned to IBM internal use)

41 부동-소수점-지원-향상 퍼실리티들(floating-point-support-enhancement facilities)(FPR-GR-transfer, FPS-sign-handling, and DFP rounding)이 z/Architecture 아키텍처 모드에 설치된다.

42 DFP(십진-부동-소수점) 퍼실리티가 z/Architecture 아키텍처 모드에 설치된다.

43 DFP(십진-부동-소수점) 퍼실리티는 고성능을 갖는다. 비트 43이 1이면 비트 42도 1이다.

44 PFPO명령이 z/Architecture 아키텍처 모드에 설치된다.

어떤 명령은 하나의 아키텍처 내에서 단일의 펑션을, 혹은 일부의 경우들에서는 복수의 선택 가능한 펑션들 중 어떠한 것이라도, 수행할 수 있다. 명령을 위해 정의되는 선택 가능한 펑션들은 머신 마다 다를 수 있다. 예를 들어, 멀티-펑션 명령은, 아키텍처된 명령 세트 내에 처음으로 도입되었을 때, 단지 몇 가지 선택 가능한 펑션들만 가질 수 있다. 나중에 아키텍처된 명령 세트는 더 많은 선택 가능한 펑션들을 이전에 도입된 멀티-펑션 명령에 도입할 수 있다. 한 실시 예에서, VM에는 물리적 프로세서의 선택 가능한 펑션의 서브세트가 할당될 수 있는데, 이에 의해서, 상기 VM의 논리적 프로세서 상에서 실행되는, 명령이 상기 논리적 프로세서의 이용 가능한 펑션들의 목록을 조사할 수 있고(query), 비록 상기 물리적 프로세서가 더 많은 선택 가능한 펑션들을 수행할 수 있을 지라도 상기 VM에 할당된 펑션들만 리턴된다. 한 실시 예에서, 이것은 펑션-표시-명령 인터셉션 퍼실리티(Function-Indicating-Instruction Interception Facility) (FIIIF)를 통해서 달성되며, FIIIF는 하이퍼바이저가 게스트(가상 머신)에 의한 이 조사 펑션의 실행을 트랩(trap) 혹은 인터셉트(intercept) 할 수 있도록 하는데, 이는 이용 가능한 펑션들의 축소 목록(reduced list)을 제공하기 위함이다. 다른 실시 예에서, 상기 하이퍼바이저는, 예를 들어, 비트 마스크(a bit mask)를 통해서, 상기 게스트에 보고될 펑션들의 세트를 명시하며, 상기 멀티-펑션 명령의 상기 조사 펑션은 이 목록을 보고한다. 더 나아가, 한 실시 예에서, 논리적 프로세서 상에서 실행되는, 명령은. 선택된 선택가능 펑션을 수행하려고 시도하는 경우 프로그램 예외(program exception)를 경험하게 될 것이다.

선택 가능 펑션들을 갖는 명령의 한 예가 z/Architecture의 사이퍼 메시지(CIPHER MESSAGE)이다.

사이퍼 메시지 (KM) 명령은 복수의 사이퍼 메시지 펑션들 중 어떠한 것도 수행할 수 있다. 사이퍼 메시지 명령에 의해서 제공되는 펑션들 중 하나는 상기 프로세서에 의해서 지원되는 사이퍼 메시지 펑션들의 비트 시그니피컨트 리스트(a bit significant list)를 위해 상기 프로세서를 조사하는 것이다(query).

사이퍼 메시지 명령의 포맷(테이블 3)은 아래와 같다. 여기서 R1은 제 1 일반 레지스터를 지정하고, R2는 제2 일반 레지스터를 지정한다.

표 3

사이퍼 메시지 명령(테이블 3)의 실행은 다음과 같다:

임플라이드(implied) 일반 레지스터 0에서 상기 펑션 코드에 의해 지정된 펑션이 수행된다.

상기 명령의 비트들 16-23은 무시된다.

일반 레지스터 0의 비트 포지션들 57-63은 펑션 코드를 포함한다.

사이퍼 메시지와 체이닝(CHAINING)을 갖는 사이퍼 메시지를 위해 현재 할당된 펑션 코드들이, 각각(0-3 및 18-20) 테이블 4에 보여진다. 모든 다른 펑션 코드들은 할당되지 않는다. 사이퍼 펑션들을 위해서, 비트 56은 수정자 비트(the modifier bit)이며, 이는 암호화 혹은 복호화 동작이 수행될 것인지를 명시한다. 상기 수정자 비트는 모든 다른 펑션들을 위해 무시된다. 일반 레지스터 0의 모든 다른 비트들도 무시된다.

임플라이드 일반 레지스터 1은 스토리지 내의 파라미터 블록의 최좌측 바이트의 논리적 주소를 포함한다. 24비트 어드레싱 모드에서, 일반 레지스터 1의 비트 포지션들 40-63의 컨텐츠는 주소를 구성하고, 비트 포지션들 0-39의 컨텐츠는 무시된다. 31비트 어드레싱 모드에서, 일반 레지스터 1의 비트 포지션들 33-63의 컨텐츠는 주소를 구성하고, 비트 포지션들 0-32의 컨텐츠는 무시된다. 64비트 어드레싱 모드에서, 일반 레지스터 1의 비트 포지션들 0-63의 컨텐츠는 주소를 구성한다.

상기 조사 펑션(query function)은 다른 펑션들의 이용 가능성을 표시하는 수단을 제공한다. 명령(R1,R2), 및 R2+1의 필드들에 의해서 지정된 일반 레지스터들의 컨텐츠는 상기 조사 펑션을 위해 무시된다.

모든 다른 펑션들을 위해서, 제 2 오퍼런드(R2에 의해서 지정됨)은 파라미터 블록에 암호 키(a cryptographic key)를 사용하여 상기 펑션 코드에 의해서 명시된 바와 같이 암호화 되며, 그리고 그 결과는 제 1 오퍼런드 로케이션에 저장된다.

체이닝을 갖는 사이퍼 메시지(CIPHER MESSAGE WITH CHAINING)를 위해서, 암호화(ciphering)는 또한 상기 파라미터 블록 내 초기 체이닝 값(initial chaining value)을 사용하며, 상기 체이닝 값은 동작의 일부로서 업데이트된다. 24 비트 어드레싱을 위한 레지스터 사용은 테이블 5에서 보여진다.

R1필드는 일반 레지스터를 지정하고 짝수 번호매겨진 레지스터(even-numbered register)를 지정해야 한다; 그렇지 않으면, 사양 예외가 인정된다.

R2필드는 일반 레지스터들의 짝수-홀수 한 쌍(an even-odd pair)을 지정하는데 짝수-번호 매겨진 레지스터(an even-numbered register)는 반드시 지정해야 한다: 그렇지 않으면, 사양 예외가 인정된다.

제 1 및 제 2 오퍼런드들의 최좌측 바이트의 로케이션은 R1 및 R2 일반 레지스터들의 컨텐츠에 의해서, 각각, 지정된다. 제 2-오퍼런드 로케이션에서 바이트들의 수는 일반 레지스터 R2 + 1에 명시된다. 제 1 오퍼런드는 제 2 오퍼런드와 동일의 길이를 갖는다.

동작의 일부로서, 일반 레지스터들 R1 및 R2 내의 주소들은 처리된 바이트들의 수만큼 증가되고, 일반 레지스터 R2 + 1의 길이는 동일의 수만큼 감소된다. 주소들 및 길이의 형성 및 업데이팅은 어드레싱 모드에 따라 달라진다(dependent).

24-비트 어드레싱 모드에서, 일반 레지스터들 R1 및 R2의 비트 포지션들 40-63의 컨텐츠는 제 1 및 제 2 오퍼런드들의 주소들을, 각각, 구성하고, 비트 포지션들 0 -39의 컨텐츠는 무시된다; 업데이트된 주소들의 비트들 40-63은 일반 레지스터들 R1 및 R2 내의 대응 비트들을 대체하고(replace), 업데이트된 주소의 비트 포지션 40으로부터의 캐리들(carries)은 무시된다. 그리고 일반 레지스터들 R1 및 R2의 비트 포지션들의 컨텐츠는 제로들(zeros)로 세트된다. 31-비트 어드레싱 모드에서, 일반 레지스터들 R1 및 R2의 비트 포지션들 33-66의 컨텐츠는 제 1 및 제 2 오퍼런드들의 주소들을, 각각, 구성하고, 비트 포지션들 0-32의 컨텐츠는 무시된다; 업데이트된 주소들의 비트들 33-63은 일반 레지스터들 R1 및 R2 내의 대응 비트들을 대체하고(replace), 업데이트된 주소의 비트 포지션 33으로부터의 캐리들(carries)은 무시된다. 그리고 일반 레지스터들 R1 및 R2의 비트 포지션 32의 컨텐트는 제로(zero)로 세트된다. 64-비트 어드레싱 모드에서, 일반 레지스터들 R1 및 R2의 비트 포지션들 0-63의 컨텐츠는 제 1 및 제 2 오퍼런드들의 주소들을, 각각, 구성하고; 업데이트된 주소들의 비트들 0-63은 일반 레지스터들 R1 및 R2 의 컨텐츠를 대체하고(replace), 비트 포지션 0으로부터의 캐리들(carries)은 무시된다.

24-비트 및 31-비트 어드레싱 모드들 모두에서, 일반 레지스터 R2+1의 비트 포지션들 32-63의 컨텐츠는 32-비트 부호없는 이진 정수 (32-bit unsigned binary integer)를 형성하는데, 이는 제 1 및 제 2 오퍼런드들 내의 바이트들의 수를 명시하며 그리고 비트 포지션들 0-31의 컨텐츠는 무시된다; 업데이트된 값의 비트들 32-63은 일반 레지스터 R2+1 내의 대응 비트들을 대체한다. 64-비트 어드레싱 모드에서, 일반 레지스터 R2+1의 비트 포지션들 0-63의 컨텐츠는 64-비트 부호없는 이진 정수 (32-bit unsigned binary integer)를 형성하는데, 이는 제 1 및 제 2 오퍼런드들 내의 바이트들의 수를 명시하며; 그리고 업데이트된 값은 일반 레지스터 R2+1의 컨텐츠를 대체한다.

24 비트 혹은 31 비트 어드레싱 모드에서, 일반 레지스터들 R1, R2, 및 R2+1의 비트 포지션들 0-31의 컨텐츠는 항상 변경되지 않고 남아 있다. 테이블 5는 방금 설명한 상기 일반 레지스터들의 컨텐츠를 보여준다.

억세스-레지스터 모드에서, 억세스 레지스터들 1, R1, 및 R2는 파라미터 블록, 제 1 및 제 2 오퍼런드들을, 각각 포함하는 주소 공간들을 명시한다.

마치 처리가 제 1 및 제 2 오퍼런드들 모두의 좌측 단부(the left end)에서 시작하여 우측으로 블록 바이 블록으로(block by block) 진행하는 듯이 하여서 결과가 얻어진다. 일반 레지스터 R2+1에 명시된 제 2 오퍼런드 내의 바이트들의 수가 처리되어 그 결과가 제 1-오퍼런드 로게이션에 저장되었을 때(이를 정상 완료라 한다) 혹은 제 2오퍼런드의 길이보다 적은 CPU 결정된 블록들의 수(a CPU-determined number of blocks)가 처리되었을 때(이를 부분 완료라 한다) 동작은 종료된다. CPU-결정된 블록들의 수는 모델에 따라 다르며, 명령이 실행될 때마다 매번 다른 수(a different number)가 될 수 있다. CPU-결정된 블록들의 수는 보통 제로가 아니다(nonzero). 특정의 일상적이 아닌 상황들(certain unusual situations)에서, 이 수는 제로가 될 수 있고, 컨디션 코드 3은 아무런 진보 없이도(with no progress) 세트 될 수 있다. 그러나, CPU는 이러한 진보 없는 상황(no-progress case)의 끝없는 재발생에 대하여 보호한다.

아래 상황들 중 하나라도 일어나면, 제 1-오퍼런드 로케이션 및 체이닝-값 필드 내의 결과들은 예측할 수 없다:

크립토그래픽-키 필드(the cryptographic-key field)가 제 1 오퍼런드의 일부를 오버랩한다(overlap).

체이닝-값 필드가 제 1 오퍼런드 혹은 제 2 오퍼런드의 일부를 오버랩한다. 제 1 및 제 2 오퍼런드들이 파괴적으로 오버랩한다(overlap destructively). 데이터 처리가 좌측으로부터 우측으로 한번에 한 바이트식 수행되다고 가정할 때, 데이터가 제 1-오퍼런드 로케이션으로 전송된 이후에 제 1-오퍼런드 로케이션이 소스로서 사용되는 경우, 오퍼런드들이 파괴적으로 오버랩한다고 한다.

오퍼런드가 정상 완료 때문에 종료될 때, 컨디션 코드 0은 세트되고 R2+1 내의 결과 값은 제로이다(zero). 오퍼런드가 부분 완료 때문에 종료될 때, 컨디션 코드 3은 세트되고 R2+1 내의 결과 값은 제로가 아니다(nonzero).

스토리지-변경 PER 이벤트가 인정될 때, 4K 추가 바이트들보다 더 적은 바이트들이 상기 이벤트가 보고되기 전에 제 1-오퍼런드 로케이션들 내에 저장된다.

제 2-오퍼런드 길이가 초기에 제로일 때, 파라미터 블록, 제1 및 제2 오퍼런드들은 억세스되지 않고, 일반 레지스터들 R1, R2, 및 R2+1은 변경되지 않으며, 컨디션 코드 0은 세트 된다.

R1 및 R2 필드들의 컨텐츠가 동일한 경우, 지정된 레지스터들의 컨텐츠는 처리된 바이트들의 수만큼만 증가하고, 처리된 바이트들의 수의 두 배만큼은 증가하지 않는다.

다른 CPU들 및 채널 프로그램들에 의해서 관찰되듯이, 파라미터 블록 및 스토리지 오퍼런드들에 대한 참조는 멀티플-억세스 참조들(multiple-access references)일 수 있고, 이들 스토리지 로케이션들에 대한 억세스들은 반드시 블록-컨커런트(block-concurrent)일 필요는 없으며, 이들 억세스들 혹은 참조들의 시퀀스는 정의되지 않는다.

특정의 일상적이지 않은 상황들에서, 명령 실행은 처리된 제 1 및 제 2 오퍼런드들의 최종 유닛(the last unit)을 반영하기 위해 레지스터들 및 체이닝 값을 업데이트함이 없이 컨디션 코드 3을 세팅 함으로써 완료될 수 있다. 이 경우에 처리된 유닛의 크기는 상황과 모델에 따라 다르지만, 처리되었으나 보고되지 않은 제 1 및 제 2 오퍼런드들의 부분이 스토리지 에서 오버랩되지 않도록 제한된다. 모든 경우들에서, 체인지 비트들(change bits)은 세트되고 그리고, 적용 가능한 경우, 처리된 모든 제 1-오퍼런드 로케이션들을 위해서, PER-변경 이벤트들(PER storage-alteration events)은 보고된다.

억세스 예외들(access exceptions)은 명령의 단일 실행에서 처리된 것보다 오퍼런드의 더 큰 부분을 위해 보고될 수 있다; 그러나 억세스 예외들은 오퍼런드의 길이를 넘는(beyond) 로케이션들을 위해서는 인정되지 않으며 처리중인 현재 로케이션을 넘는 4K 바이트들보다 더 큰 로케이션들을 위해서도 인정되지 않는다.

사이퍼 메시지(CIPHER MESSAGE)를 위한 펑션 코드는 다음과 같다.

표 4

표 5

사이퍼 메시지 명령을 예로서 사용하여, 예시적 머신이 사이퍼 메시지 펑션을 구현할 수 있다. 예시적 구현에서, 호스트 프로세서는 도시된 모든 펑션들(펑션 코드 0-3 및 18-20)을 구현할 수 있다. 호스트 운영체제(OS)(혹은 하이퍼바이저)는 게스트 OS들을 위해 하나 혹은 그 이상의 가상 머신들을 생성할 수 있다. 하나의 가상 머신은, 사이퍼 메시지 명령들을 갖지 않는, 이전의 레벨 아키텍처(a previous level architecture)를 위해서 정의될 수 있다.

한 실시 예에 따르면, 만일 명령 차단 퍼실리티(an Instruction Blocking Facility)가 설치되고 사이퍼 메시지 명령들이 한 VM을 위해 차단된 명령들(Blocked instructions)로서 지정된다면, 하부의 호스트 머신이 사이퍼 메시지 명령들을 지원했다 할 지라도, 그 가상 머신에서 실행되는 프로그램들에 의해서 사이퍼 메시지 명령 실행하는 것을 상기 가상 머신은 허가하지 않을 것이다. 상기 VM에서 사이퍼 메시지 명령을 실행하려는 시도는 프로그램 체크(프로그램 예외)를 초래할 것이다.

다른 실시 예에 따르면, 만일 펑션 차단 퍼실리티(a Function Blocking Facility)가 설치되고 사이퍼 메시지 펑션들의 서브세트(예를 들어 펑션 코드들 0-3)만이 한 VM에서 허가된다면, 상기 가상 머신은 사이퍼 메시지를 실행하는 것은 허가할 것이지만, 하부의 호스트 머신이 그 펑션 코드들(0-3및 18-20)을 지원하는 사이퍼 메시지 명령들을 지원했다 할 지라도, 그 가상 머신에서 실행되는 프로그램들에 의해서 0-3이 아닌 펑션 코드를 갖는 사이퍼 메시지 명령들의 사이퍼 메시지 명령 실행을 허가하지 않을 것이다. 18-20 중 어느 하나와 같이 0-3이 아닌 펑션 코드들을 갖는 사이퍼 메시지 명령을 실행하려는 시도는 프로그램 체크(프로그램 예외)를 초래할 것이다.

다른 실시 예에서, 만일 펑션 테스트/조사 퍼리실티(a Function test/query facility)가 설치되고 사이퍼 메시지 펑션들의 서브세트(예를 들어 펑션 코드들 0-3)만이 한 VM에 허가된다면, 하부의 호스트 머신이 펑션코드들 0-3 및 18-20을 지원했다 하더라도, 사이퍼 메시지 펑션들 중 사이퍼 메시지 조사의 실행은 오직 펑션 코드들 0-3만을 리턴할 것이다.

명령 차단 퍼실리티(INSTRUCTION BLOCKING FACILITY):

도 8을 참조하면, VM에서의 가상 아키텍처 레벨(VAL) 명령 차단 퍼실리티(a Virtual Architecture Level (VAL) Instruction Blocking facility)가 도시되어 있다. 상기 VM에서 실행될 각 명령(스토리지 칼럼 내의 명령들에 도시된 바와 같은)은 하나의 오피코드(an opcode)를 포함한다. 일부 구현 예들에서, 상기 오피코드는 명령(901, 902, 903, 904) 내의 단일 필드(a single field)이다. 다른 구현들에서, 오피코드는 명령(905 (OpCode∥OpCode), 906 (OpCode∥OpCode))의 하나의 필드 이상에 분산되어 있을 수 있다. 바람직하게도, 회로들, 마이크로코드 혹은 이들의 조합이, 오피코드에 기초하여, 실행될 명령이 현재 가상 머신에 의해서 지원되는지 아닌지를 결정할 것이다. 만일 지원이 되지 않는다면, 프로그램 인터럽션(program interruption), 예를 들어, 프로그램 예외가 표시될 것이고 그 명령은 중지될 것이다(suppressed).

한 구현에서, 실행될 명령의 오피코드는 그 오피코드와 연관된 엔트리를 찾기 위해 오피코드 테이블(907)로 인덱스하기 위해서 사용된다. 찾아낸 엔트리는 그 오피코드에 의해서 지원되는 머신 레벨(ML)을 표시하는 코드를 포함할 것이다. 다른 구현에서, 각각의 가상 머신은 오피코드 테이블을 가지며 그 테이블의 엔트리는 그 오피코드가 상기 가상 머신에 의해서 지원되는지를 표시한다.

도 9를 참조하면, 테이블(907)로부터 획득된 코드(머신 레벨(ML)) (1002)는 가상 머신의 상태 묘사 테이블(state description table)(1004)의 상태 묘사 엔트리(IBC) (1005)에 대하여 비교되고, 만일 머신 레벨 코드(1002)가 IBC 상태 묘사 엔트리(1005)보다 크다면, 그 명령은 정상으로 실행될 것이고, 그렇지 않으면, 그 실행 시도는 프로그램 예외(1006)을 초래할 것이다. 다른 실시 예에서, 그 오피코드 필드에 더하여 혹은 그 오피코드 필드와 다른 명령의 필드들이 오피코드 테이블(907)로 인덱스하기 위해 사용될 수 있다. 예를 들어, 하나의 오피코드는 종래의 머신 아키텍처에서 필드들을 유보할 수 있는데 (0이 되게 하거나 혹은 무시할 수 있다), 이는 새로운 펑션을 제공하기 위해 더 새로운 아키텍처 레벨들에서 채용된다. 어떤 실시 예는 오피코드 테이블(907)로 인덱스하기 위해 그 오피코드를 갖는 이들 비트들을 포함할 수 있다. 다른 실시 예에서, 오피코드 테이블(907)은 연관된 명령에서 유보된 비트들의 허가된 사용을 표시하기 위해 사용된 ML 필드 이외의 필드들을 가질 수 있다. 예를 들어, 상기 명령이 4개의 유보된 비트들을 갖는 경우, 상기 ML 테이블은 만일 모든 비트들이 0 이 되어야 한다면 0000을 포함할 수 있고, 혹은 선택된 비트들에서 1을 포함할 수 있다(여기서 1은 그 필드의 대응하는 이전에 유보된 비트들이 0 혹은 1이 될 수 있음을 표시한다)(이는 VM을 위한 명령의 새롭게 도입된 펑션을 허가한다).

명령 테스트/조사 퍼실리티(INSTRUCTION TEST/QUERY FACILITY):

만일 명령 테스트/조사 퍼실리티의 펑션 차단 퍼실리티(a FUNCTION BLOCKING FACILITY)가 설치되면 (도 10), 오피코드 테이블 엔트리(1001)은, 한 실시 예에서, 추가적으로 펑션 코드 필드(FCx) (1003) (혹은 펑션 코드 테이블(1108)에 대한 포인터)를 포함할 수 있다. 펑션 코드 필드(1003) (혹은 펑션 코드 테이블 (1108) 엔트리(1107))은 실행될 펑션 코드(1102)와 비교된다(1103). 만일 펑션 코드가 비교된다면, 상기 명령은 그 펑션 코드를 사용하도록 허가될 것이고(1103), 만일 펑션 코드가 비교되지 않는다면, 상기 명령의 실행은 프로그램 인터럽션, 예를 들어, 프로그램 예외 혹은 사양 예외(프로그램 체크) (1104)를 초래한다.

도 11을 참조하면, 만일 상기 명령 테스트/조사 퍼실리티의 펑션 테스트/조사 차단 퍼실리티(a FUNCTION TEST/QUERY BLOCKING FACILITY)가 설치되고, 임의의 조사 명령(any query instruction)(1201)이 상기 명령의 설치된 펑션을 결정하기 위해 실행된다면, 가상 머신에 의해서 허가된 펑션 코드들 만이 리턴된다(1105). 한 실시 예에서, 비트 시그니피컨트 테이블(a bit significant table) (1108)이 가상 머신을 위해 제공되는데, 이는 그러한 조사들에 응답하기 위해 가상 머신에 의해서 사용된다. 다른 실시 예에서, 하나의 마스크(a mask)가 가상 머신에 제공되는데(도시되지 않음), 이는 VM에서 명령의 허가된 펑션코드들(1107)의 결과를 생성하기 위해 상기 호스트 머신의 설치된 펑션들과 논리곱이 된다(ANDed).

도 8을 참조하면, z/Architecture 명령 포맷들의 예들이 도시된다. 포맷(901)은 2 바이트 포맷을 도시하는데, 여기서 오피코드(Op)는 상위 바이트(high order byte)를 차지하고, 일반 레지스터 필드들 R1 및 R2는 각각 나머지 바이트의 4비트들을 차지한다. 포맷(902)는 오직2 바이트 오피코드인 명령 포맷(a 2 byte OpCode only instruction format)을 도시한다. 포맷(903)은 1 바이트 오피코드(Op), 그 다음 3개의 레지스터 필드들(R1, X2 및 B2) 그리고 그 다음 변위 필드라 불리우는 직접 필드(an immediate field) (D2)를 갖는 4 바이트(워드) 명령을 도시한다. 포맷(904)는 4 바이트 오피코드(Op), 그 다음 4 비트 레지스터 필드(B2) 그리고 그 다음 12비트 직접 필드(D2)를 갖는 4 바이트 명령을 도시한다. 포맷(905)는 1 바이트 오피코드(Op), 그 다음 4 비트 마스크(M1), 4비트 오피코드 확장(Op) 및 유보된 4비트 필드, 그 다음 12비트 직접 필드(I2)를 갖는 4 바이트 명령을 도시한다. 포맷(906)은 1 바이트 오피코드(Op), 그 다음 3개의 레지스터 필드들(R1, X2, 및 B2), 그리고 그 다음 변위 필드라 불리우는 직접필드(DL2), 그 다음 8비트의 직접 필드(DH2) 및 8비트 오피코드 확장(Op)을 갖는 8 바이트 명령을 도시한다.

도 8 및 9를 참조하면, 한 실시 예에서, 하나의 명령이 가상 머신의 논리적 프로세서에 의해 실행되기 위해 페치될 때, 오피코드 테이블(907)이 검색되는데, 이 때 상기 명령의 오피코드(들)를 검색 변수(a search argument)로서 사용한다. 상기 명령을 위한 엔트리(1001) 하나를 찾으면, 상기 엔트리는 명령 허가 정보(instruction permission information)를 결정하기 위한 정보(1002, 1003)를 포함한다. 바람직한 실시 예에서, 엔트리는 상기 명령을 지원하는 아키텍처의 머신 레벨을 표시하는 코드(ML)을 명시하는 필드(1002)를 포함한다. 상태 묘사(a state description) (1004)가 각각의 VM을 위해 제공된다. 상기 상태 묘사는 필드(IBC) (1005)를 포함하는데, 이는 VM이 시뮬레이트할 아키텍처의 머신 레벨을 표시한다. 만일 명령을 지원하는 아키텍처의 머신레벨(ML)이 VM이 시뮬레이트할 아키텍처의 머신 레벨(IBC)보다 크다면, 프로그램 예외(프로그램 체크)가 발령되고(signaled), 한 실시 예에서, 명령의 실행은 중지된다. 한편, 만일 명령을 지원하는 아키텍처의 머신레벨(ML)이 VM이 시뮬레이트할 아키텍처의 머신 레벨(IBC)보다 크지 않다면, 명령의 실행은 허가된다.

일부 환경들에서, 복수의 펑션들 중 어떤 것이라도 실행할 수 있는 명령들(예를 들어, 전술한, 사이퍼 메시지 명령)이 제공된다. 명령에 의한 펑션의 선택은 그 펑션을 표시하는 펑션 코드(FC)를 지정하는 것을 통해서 할 수 있다. 펑션 코드는 예를 들어 명령에 의해서 간접적으로 지정될 수도 있고 또는 비트들 혹은 명령의 필드들에 의해서 명시적으로 지정될 수 있다. 일부 경우들에 있어서, 특정 펑션 코드들은 초기에 머신 아키텍처 레벨로 구현될 수 있으며(예를 들어 0-3), 추가의 펑션 코드들은 나중의 머신 아키텍처 레벨들에 추가될 수 있다. 올더 아키텍처 레벨(an older architecture level)에 관해서는 실행하고 뉴어 아키텍처 레벨(a newer architecture level)의 펑션들의 실행은 차단(금지)하도록만 펑션코드들을 허가하는 능력(capability)을 VM에 제공할 수 있다.

도 10을 참조하면, 이것은 오피코드 테이블 엔트리(1001) 내에 펑션 코드 필드(FCx) (1003)을 가짐으로써 달성될 수 있다. 명령이 실행될 때, FCx 필드(1003)은 호스트 프로세서에 의해서 지원되는 실제 펑션 코드들보다 오히려 리턴될 허가된 펑션 코드 목록을 명시한다. 한 실시 예에서, 오피코드 테이블 엔트리의 FCx(1003) 필드는 IBC 필드(1005)와 연결되는데(concatenated) 이는 허가된 펑션 코드들(FC들)(1107)을 포함하는 엔트리를 찾아내기 위해 FCx 테이블(1108)로 인덱스(1006)하기 위함이다. 허가된 FC들(1107)은 명령에 의해서 명시된 FC(1102)와 비교된다(사이퍼 메시지 명령에서, 일반 레지스터 0 (1101)의 비트들 (1102)는 명시된 FC(1102)를 포함한다). 만일 (1103)에서 FC 값이 허가되면(1105), FC에 의해서 표시된 펑션의 정상 실행(normal execution)이 허가된다. 만일 (1103)에서 FC 값이 허가되지 않으면(1104), 프로그램 예외, 예를 들어 사양 예외(프로그램 체크) 이벤트가 수행된다. 마찬가지로, 펑션 조사/테스트 동작(1201)(예를 들어, 사이퍼 메시지 명령 조사 동작)이 실행되면, 오피코드 테이블 엔트리(1003)의 FCx 비트들은 IBC 비트들(1005)와 연결되는데(1106), 이는 오피코드가 오피코드 테이블 엔트리(1001)을 찾아내는 명령을 위해 허가된 FC들(1107)을 찾아내기 위해서 FCx 테이블(1008)로 인덱스하기 위함이다. 그 다음 허가된 FC들은 상기 펑션 조사/테스트 동작에 의해서 명시된 로케이션에 리턴한다(1105).

한 실시 예에서, FCx 비트들이 0이면, FCx 테이블(1108)에 대한 억세스는 수행되지 않으며, 대응 명령에 의해서 표시된 모든 펑션 코드는 변환없이 사용된다.

한 실시 예에서, 명령들에 대한 기타 아키텍처 수정들은 펑션 코드들을 위해 설명한 것과 동일한 메커니즘을 사용할 수 있다. 이 경우에 있어서, 예를 들어, 한 아키텍처 레벨에서 명령(905)는 오피코드 확장 필드 및, 유보된(0000), 12 필드 사이에 비트들을 가질 수 있다. 바람직하게도, 상기 유보된 비트들은 0에 대해서 테스트되는데, 이는 그 명령이 영이 아닌(non-zero) 비트들이 지원하는 환경에서 아직 지원되지 않은 펑션을 적절이 수행할 수 있도록 보장하기 위해서이다. 뉴어 아키텍처는 새로운 펑션을 식별하기 위해 유보된 비트들 중 하나 혹은 그 이상을 사용하여 새로운 펑션을 구현한다. 한 예에서, 이들 4개의 유보된 비트들(Res)은 도 10에서의 FC 비트들(1102)에 대해서 도시된 바와 같이 지원되는 지를 결정하기 위해서 FCx 테이블(1108)로 인덱스 할 수 있다. 이 경우에 있어서, 연결(concatenation)은 펑션 코드들을 위해서는 0∥IBC∥FCx가 될 것이고, 새로운 펑션 허가 테스트(1103)을 위해서는 1∥IBC∥FCx가 될 것이다. FC(1102)가 허가된 FC비트들(1107)과 비교되는 대신에, 명령(905)의 Res 필드가 허가된 FC 비트들(1107)에 대해서 체크될 것인데, 이는 상기 펑션이 허가되었는지를 결정하기 위함이다.

다른 실시 예에서, 명령(905)의 Res필드는 마치 그 것이 명령(905) 오피코드들의 제 3 오피코드 확장(a third OpCode extension)인 것처럼 연결될 수 있는데, 이는 상기 필드에 도입된 펑션이 허가되었는지를 결정하기 위해서 오피코드 테이블(907)로 인덱스 하기 위함이다.

명령의 페칭의 일부로서, 혹은 후속으로, CPU는 명령의 특정 속성들(certain attributes)을 결정할 수 있는데, 이러한 속성들은, 예를 들어, 오퍼런드들의 수, 오퍼런드들의 종류(스토리지 혹은 레지스터), 오퍼런드 배열 요건들(operand alignment requirements), 및 승인 요건들(authorization requirements)을 포함한다. 에뮬레이션 환경에 있어서, 이러한 결정은 인덱스로서 오퍼레이션 코드를 사용하는 단순한 테이블 룩-업(a simple table look-up)의 결과일 수 있다; 고성능 CPU 하드웨어 구현에서, 그러한 결정은 프로세서의 명령-디코드 회로 내에 구축될 수 있다(built). 따라서, 명령이 디코드 되면, 그 명령을 위한 머신 레벨이 허가된 머신 레벨을 표시하는 프로그램 가능 값과 비교될 수 있다. 디코드된 명령이 허가된 값보다 더 높은 머신 레벨을 갖는 경우 그 명령은 구현에 따라서 전송(dispatched), 실행(executed) 혹은 완료(completed)되는 것이 차단되고(blocked) 무효 오피코드(invalid opcode)를 위한 머신 종속 예외(the machine dependent exception)가 생성될 수 있다.

가상-아키텍처-레벨 퍼실리티(virtual-architecture-level facility)는 각각의 명령과 연관된 추가의 속성을 도입할 수 있는데; 이 속성은 명령이 처음 아키텍처에 도입된 머신 레벨이다. 이 머신 레벨은 연속체(continuum) 상의 인코드된 뉴메릭 포인트(an encoded numeric point) (예를 들어, 10.2, 이는 두 번째 펌웨어 레벨에서 10번째 제너레이션 머신(the 10th-generation machine at the second firmware level)을 의미한다) 일 수 있으며, 또는 단순히 가장-최근 머신 레벨과 관련한 값(예를 들어, 2[혹은 -2], 이것은 명령에 현재 머신 이전에 둘의 머신 제너레이션이 도입되었음을 의미한다)이 될 수도 있다.

도 12를 참조하면, 한 실시 예에서, 특정 명령들(1258)이 프로세서에 의해 실행되는 것이 차단된다(blocked). 명령 차단 값이 세트된다(1251). 프로세서에 의해서 실행되기 위해 명령이 페치되며(1252), 이 명령은 오피코드를 포함하고, 이 명령은 프로세서에 의해서 지원된다. 상기 명령이 실행될 때, 상기 명령 차단 값은 상기 명령(혹은 상기 명령의 오피코드)과 비교되는데(1253), 이는 상기 실행이 허가되었는지를 결정하기 위해서이다. 상기 명령 차단 값이 상기 명령의 실행을 허가하는 것에 응답하여(1254), 프로세서에 의해서 상기 페치된 명령을 실행하고(1255); 상기 명령 차단 값이 상기 명령의 실행을 허가하지 않는 것에 응답하여(1254), 상기 페치된 명령의 실행을 차단하고 프로그램 예외 이벤트를 일으킨다(1256).

도 13을 참조하면, 한 실시 예에서, 프로세서는 가상 머신의 논리적 프로세서이며, 페칭은 논리적 프로세서에 의해서 수행된다. 상기 가상 머신의 명령 차단 값에 관한 결정이 내려진다(1254), 여기서 상기 명령 차단 값은 하나 혹은 그 이상의 물리적 프로세서들을 갖는 논리적 프로세서 내에 세트 되며, 상기 명령은 상기 하나 혹은 그 이상의 프로세서들에 의해서 지원되며, 상기 명령 차단 값이 상기 명령의 실행을 허가하는 것에 응답하여 상기 실행이 상기 논리적 프로세서에 의해서 수행된다(1352). 만일 상기 명령이 차단되면(1256), 프로그램 예외 이벤트가 보고된다.

도 14를 참조하면, 한 실시 예에서, 프로세서는 가상 머신의 논리적 프로세서의 하나 혹은 그 이상의 물리적 프로세서이다. 여기서 상기 명령 차단 값은 하나 혹은 그 이상의 물리적 프로세서들 내에 세트 되며(1451), 상기 페칭은 상기 하나 혹은 그 이상의 물리적 프로세서들에 의해서 수행된다. 상기 물리적 프로세서는 상기 명령 차단 값을 실행될 상기 명령과 비교하는데(1452), 이는 상기 명령이 차단될 것인지를 결정하기 위해서이며, 그 결과에 따라 상기 물리적 프로세서는 상기 명령을 수행하거나 (1454) 혹은 프로그램 예외 이벤트를 일으킨다(1455).

도 15를 참조하면, 한 실시 예에서, 명령 차단 값은 명령의 실행을 차단하기 위해서 가상 머신을 위해 정의되며, 명령 차단 값을 세트 하는 것은 물리적 프로세서를 사용하도록(1553) 가상 머신을 인에이블 하는 것에 응답하여 하고 (1551); 다른 명령 차단 값이 세트 되며(1552), 다른 명령 차단 값은 다른 논리적 프로세서를 갖는 다른 가상 머신을 위해 정의되고, 다른 명령 차단 값을 세트하는 것은 물리적 프로세서를 사용하도록(1553) 다른 가상 머신을 인에이블하는 것에 응답하여 하며; 다른 명령 차단 값이 명령의 실행을 허가하는 것에 응답하여(1254), 다른 논리적 프로세서에 의한 명령의 실행을 허가하고(1255); 그리고 다른 명령 차단 값이 명령의 실행을 허가하지 않는 것에 응답하여(1254), 다른 논리적 프로세서에 의한 명령의 실행을 허가하지 않는다(1255).

한 실시 예에서, 명령 차단 값은 명령의 실행을 차단하기 위해서 가상 머신을 위해 정의되며, 명령 차단 값을 세트 하는 것은 물리적 프로세서를 사용하도록 가상 머신을 인에이블 하는 것에 응답하여 하고, 다른 명령 차단 값이 세트 되며, 다른 명령 차단 값은 다른 논리적 프로세서를 갖는 다른 가상 머신을 위해 정의되고, 다른 명령 차단 값을 세트하는 것은 물리적 프로세서를 사용하도록 다른 가상 머신을 인에이블하는 것에 응답하여 하며; 그리고 다른 명령 차단 값이 명령의 실행을 허가하는 것에 응답하여, 물리적 프로세서를 사용하도록 다른 가상 머신이 인에이블되는 동안 물리적 프로세서에 의한 명령의 실행을 허가하고; 그리고 다른 명령 차단 값이 명령의 실행을 허가하지 않는 것에 응답하여, 물리적 프로세서를 사용하도록 다른 가상 머신이 인에이블되는 동안 물리적 프로세서에 의한 명령의 실행을 허가하지 않는다.

도 12를 참조하면, 한 실시 예에서, 복수의 선택 가능한 펑션들의 선택된 펑션(1259)과 연관된 허가된 펑션 코드를 명령(1258)이 채용하는 것에 응답하는 명령(1258)은 허가된 명령이며, 허가되지 않은 펑션 코드를 명령(1258)이 채용하는 것에 응답하는 명령은 허가되지 않은 명령이고, 펑션 코드들은 명령에 의해서 명시된다.

한 실시 예에서, 명령의 오피코드를 명령 차단 값에 연관시킴으로써 명령이 허가된 명령인지에 관한 결정이 내려진다.

한 실시 예에서, 페치된 명령은 수행될 펑션을 명시하며, 명령의 오피코드는 명령 차단 값을 찾아내기 위해 테이블로 인덱스하기 위해 사용되고, 명령 차단 값은 허가 필드를 포함하며, 허가 필드는 허가된 펑션들을 결정하기 위해 사용된다. 펑션이 허가된 펑션임에 응답하여, 명령의 실행이 허가되고 그리고 펑션이 허가되지 않은 펑션임에 응답하여, 명령의 실행은 허가되지 않는다.

전술한 설명은 하나의 컴퓨터 시스템, 실시 예의 용어들 및 구조를 이해하는데 도움이 될 수 있다. 실시 예들은 z/ Architecture 혹은 이에 관하여 제공된 설명에 한정되는 것은 아니다. 다른 컴퓨터 제조업체들의 다른 컴퓨터 아키텍처에 여기서 소개한 내용을 적용하는 실시 예들도 장점을 가질 수 있다.

여기서는 바람직한 실시 예들이 도시되고 설명되었지만, 실시 예들은 여기서 소개된 정확한 구성에 대해서만 한정되는 것이 아니라는 점과, 아래에 첨부한 청구항들에 정의된 본 발명의 범위 내에 있는 모든 변경들 및 수정들에게도 권리가 유보되어 있음을 이해할 수 있을 것이다.

Claims

특정 명령들이 프로세서에 의해서 실행되는 것을 차단하기 위한 컴퓨터 구현 방법에 있어서, 상기 방법은:
명령 차단 값(an instruction blocking value)을 세트하는 단계(setting);
상기 프로세서에 의해서 실행될 명령을 페치하는 단계(fetching) - 상기 명령은 오피코드(opcode)를 포함하고, 상기 명령은 상기 프로세서에 의해서 지원됨 -;
상기 명령 차단 값이 상기 명령의 실행을 허가하는 것에 응답하여, 상기 페치된 명령을 상기 프로세서에 의해서 실행하는 단계(executing); 및
상기 명령 차단 값이 상기 명령의 실행을 허가하지 않는 응답하여, 상기 페치된 명령의 실행을 차단하고(blocking) 프로그램 예외 이벤트(a program exception event)를 일으키는 단계(causing)를 포함하는
방법.
제 1항에 있어서, 상기 프로세서는 가상 머신(a virtual machine)의 논리적 프로세서(a logical processor)이며, 상기 페칭은 상기 논리적 프로세서에 의해서 수행되고, 상기 방법은:
상기 가상 머신의 명령 차단 값을 결정하는 단계(determining) - 상기 명령 차단 값은 하나 혹은 그 이상의 물리적 프로세서들을 갖는 상기 논리적 프로세서 내에 세트되며, 상기 명령은 상기 하나 혹은 그 이상의 물리적 프로세서들에 의해서 지원되고, 상기 명령 차단 값이 상기 명령의 실행을 허가하는 것에 응답하여 상기 실행이 상기 논리적 프로세서에 의해서 수행됨 - 를 더 포함하는
방법.
제 1항에 있어서, 상기 프로세서는 가상 머신의 논리적 프로세서의 하나 혹은 그 이상의 물리적 프로세서들이며, 상기 명령 차단 값은 상기 하나 혹은 그 이상의 물리적 프로세서들 내에 세트되고, 상기 페칭은 상기 하나 혹은 그 이상의 물리적 프로세서들에 의해서 수행되는
방법.
제 2항에 있어서, 상기 방법은:
상기 명령 차단 값은 상기 명령의 실행을 차단하기 위해서 상기 가상 머신을 위해 정의되며, 상기 명령 차단 값을 세트하는 것은 상기 물리적 프로세서를 사용하도록 상기 가상 머신을 인에이블 하는 것에 응답하여 하고,
다른 논리적 프로세서(another logical processor)를 갖는 다른 가상 머신을 위해 정의된 다른 명령 차단 값(another instruction blocking value)을 세트하는 단계(setting) - 상기 다른 명령 차단 값을 세트하는 단계는 상기 물리적 프로세서를 사용하도록 상기 다른 가상 머신을 인에이블하는 것에 응답하여 함 -; 및
상기 다른 명령 차단 값이 상기 명령의 실행을 허가하는 것에 응답하여, 상기 다른 논리적 프로세서에 의한 상기 명령의 실행을 허가하는 단계(permitting); 및
상기 다른 명령 차단 값이 상기 명령의 실행을 허가하지 않는 것에 응답하여, 상기 다른 논리적 프로세서에 의한 상기 명령의 실행을 허가하지 않는 단계를 더 포함하는
방법.
제 3항에 있어서, 상기 방법은:
상기 명령 차단 값은 상기 명령의 실행을 차단하기 위해서 상기 가상 머신을 위해 정의되며, 상기 명령 차단 값을 세트하는 것은 상기 물리적 프로세서를 사용하도록 상기 가상 머신을 인에이블 하는 것에 응답하여 하고,
다른 논리적 프로세서를 갖는 다른 가상 머신을 위해 정의된 다른 명령 차단 값을 세트하는 단계(setting) - 상기 다른 명령 차단 값을 세트하는 단계는 상기 물리적 프로세서를 사용하도록 상기 다른 가상 머신을 인에이블 하는 것에 응답하여 함 -; 및
상기 다른 명령 차단 값이 상기 명령의 실행을 허가하는 것에 응답하여, 상기 다른 가상 머신이 상기 물리적 프로세서를 사용하도록 인에이블 되는 동안 상기 물리적 프로세서에 의한 상기 명령의 실행을 허가하는 단계(permitting); 및
상기 다른 명령 차단 값이 상기 명령의 실행을 허가하지 않는 것에 응답하여, 상기 다른 가상 머신이 상기 물리적 프로세서를 사용하도록 인에이블 되는 동안 상기 물리적 프로세서에 의한 상기 명령의 실행을 허가하지 않는 단계를 더 포함하는
방법.
제 1항에 있어서, 상기 명령이 허가된 펑션 코드를 채용하는 것에 응답하여, 상기 명령은 허가된 명령이 되며, 상기 명령이 허가되지 않은 펑션 코드를 채용하는 것에 응답하여, 상기 명령은 허가되지 않은 명령이 되는
방법.
제 2항에 있어서, 상기 방법은:
상기 명령의 오피코드를 상기 명령 차단 값으로 연관시킴으로써 상기 명령이 허가된 명령인지를 결정하는 단계를 더 포함하는
방법.
제 6항에 있어서, 상기 페치된 명령은 수행될 펑션을 명시하며, 상기 방법은:
상기 명령 차단 값을 찾아내기 위해서 테이블로 인덱스하기 위해(index) into a table) 오피코드를 사용하는 단계 - 상기 명령 차단 값은 허가 필드(a permission field)를 포함함 -;
허가된 펑션들을 결정하기 위해 상기 허가 필드를 사용하는 단계;
상기 펑션이 허가된 펑션임에 응답하여, 상기 명령의 실행이 허가됨을 결정하는 단계; 및
상기 펑션이 허가되지 않은 펑션임에 응답하여, 상기 명령의 실행이 허가되지 않음을 결정하는 단계를 포함하는
방법.
특정 명령들이 프로세서에 의해서 실행되는 것을 차단하기 위한 컴퓨터 시스템에서, 상기 컴퓨터시스템은:
메모리;
상기 메모리와 통신하는 프로세서 - 상기 프로세서는 메모리로부터 명령들을 페치하기 위한 명령 페칭 엘리멘트 및 페치된 명령들을 실행하기 위한 하나 혹은 그 이상의 실행 엘리멘트들을 포함함 - 를 포함하되,
상기 컴퓨터 시스템은 청구항 1 내지 8항 중 어느 한 항에 청구된 방법을 수행하도록 구성된
컴퓨터 시스템.
컴퓨터 판독가능 매체에 있어서,
상기 컴퓨터 판독가능 매체는 특정 명령들이 프로세서에 의해서 실행되는 것을 차단하기 위한 컴퓨터 프로그램을 포함하고,
상기 컴퓨터 프로그램은 처리 회로에 의해서 판독될 수 있고, 청구항 1 내지 8항 중 어느 한 항에 청구된 방법을 수행하기 위해 상기 처리 회로에 의한 실행을 위한 명령들을 포함하는
컴퓨터 판독가능 매체.