KR20180126518A

KR20180126518A - 벡터 명령 처리

Info

Publication number: KR20180126518A
Application number: KR1020187029665A
Authority: KR
Inventors: 토마스 크리스토퍼 그로커트
Original assignee: 에이알엠 리미티드
Priority date: 2016-03-23
Filing date: 2017-03-17
Publication date: 2018-11-27
Also published as: JP6882320B2; CN108834427A; IL261309B; US11269649B2; GB201604944D0; CN108834427B; IL261309A; GB2548601B; JP2019510313A; TWI756212B; EP3433724B1; KR102379886B1; WO2017163023A1; GB2548601A; TW201734769A; EP3433724A1; US20190056933A1

Abstract

처리 회로(4)는 벡터 명령에 응답하여 다수의 비트의 처리를 수행하고, 각 비트(beat)는 다수의 데이터 요소를 포함하는 벡터 값의 일부에 대응하는 처리를 포함한다. 처리 회로(4)는 2개 이상의 벡터 명령들의 그룹의 어떤 비트들(beats)이 완료했는지를 나타내는 비트 상태 정보(22)를 설정한다. 주어진 벡터 명령의 처리로의 복귀를 나타내는 이벤트로부터의 복귀 요청에 응답하여, 처리 회로(4)는 비트 상태 정보(22)에 근거하여 이미 완료된 비트들(beats)을 억제하면서 미완료된 벡터 명령들의 그룹의 처리를 재개한다.

Description

벡터 명령 처리

본 기술은 데이터 처리의 분야에 관한 것이다. 보다 상세하게는, 본 발명은 벡터 명령들의 처리에 관한 것이다.

일부 데이터 처리 시스템은 소스 피연산자 또는 명령의 결과 값이 다수의 데이터 요소를 포함하는 벡터인 벡터 명령들의 처리를 지원한다. 단일 명령에 응답하여 다수의 별개의 데이터 요소들의 처리를 지원함으로써, 코드 밀도가 향상될 수 있고 명령들의 페칭(fetching) 및 디코딩의 오버헤드(overhead)를 감소시킬 수 있다. 단일 벡터 명령을 사용하여 벡터 피연산자의 각 요소에 데이터 값을 로드하고 한 번에 데이터 값들 여러 요소를 처리함으로써, 처리할 데이터 값의 어레이를 보다 효율적으로 처리할 수 있다.

적어도 몇몇 예들은,

소스 피연산자 및 결과 값 중 적어도 하나가 복수의 데이터 요소를 포함하는 벡터 값인 벡터 명령들을 처리하는 처리 회로를 구비하는 장치를 제공하고,

주어진 벡터 명령에 응답하여, 상기 처리 회로는 복수의 비트(beats)의 처리를 수행하도록 구성되고, 각 비트(beat)는 상기 벡터 값의 일부에 대응하는 처리를 포함하며,

상기 처리 회로는 상기 주어진 벡터 명령을 포함하는 복수의 벡터 명령 중 어떤 비트(beat)가 완료했는지를 나타내는 비트 상태 정보(beat status information)를 설정하도록 구성되며,

이벤트에 응답하여, 상기 처리 회로는 상기 주어진 벡터 명령의 처리를 중단하도록 구성되고,

상기 주어진 벡터 명령의 처리로의 복귀를 나타내는 이벤트로부터의 복귀 요청에 응답하여, 상기 처리 회로는 완료한 것으로서 상기 비트 상태 정보로 나타낸 상기 복수의 벡터 명령의 비트(beats)를 억제하면서 상기 복수의 벡터 명령의 처리를 재개하도록 구성되고,

상기 벡터 값은 상기 처리 회로가 액세스 가능한 데이터 요소 크기 정보에 의해 지정된 복수의 데이터 요소 크기 중 하나를 갖는 데이터 요소들을 구비하고,

각 비트(beat)의 처리는 상기 데이터 요소 크기 정보로 나타낸 데이터 요소 크기와 관계없이, 상기 벡터 값의 고정된 크기 부분에 대응하는 처리를 포함한다.

적어도 몇몇 예들은,

소스 피연산자 및 결과 값 중 적어도 하나가 복수의 데이터 요소를 포함하는 벡터 값인 벡터 명령들을 처리하는 수단을 구비하는 장치를 제공하고,

주어진 벡터 명령에 응답하여, 상기 처리 수단은 복수의 비트(beats)의 처리를 수행하도록 구성되며, 각 비트(beat)는 상기 벡터 값의 일부에 대응하는 처리를 포함하고,

상기 처리 수단은 상기 주어진 벡터 명령을 포함하는 복수의 벡터 명령 중 어느 비트(beat)가 완료했는지를 나타내는 비트 상태 정보를 설정하도록 구성되고,

이벤트에 응답하여, 상기 처리 수단은 상기 주어진 벡터 명령의 처리를 중단하도록 구성되며,

상기 주어진 벡터 명령의 처리로의 복귀를 나타내는 이벤트로부터의 복귀 요청에 응답하여, 상기 처리 수단은 완료한 것으로서 상기 비트 상태 정보로 나타낸 상기 복수의 벡터 명령의 비트들(beats)을 억제하면서 상기 복수의 벡터 명령의 처리를 재개하도록 구성되고,

상기 벡터 값은 상기 처리 수단이 액세스 가능한 데이터 요소 크기 정보에 의해 지정된 복수의 데이터 요소 크기 중 하나를 갖는 데이터 요소들을 포함하고,

적어도 몇몇 예들은,

소스 피연산자 및 결과 값 중 적어도 하나가 복수의 데이터 요소를 포함하는 벡터 값인 벡터 명령들을 처리하는 방법을 제공하고, 상기 방법은,

주어진 벡터 명령에 응답하여, 각 비트(beat)가 상기 벡터 값의 일부에 대응하는 처리를 포함하는 복수의 비트(beats)의 처리를 수행하는 단계와,

상기 주어진 벡터 명령을 포함하는 복수의 벡터 명령 중 어떤 비트(beat)가 완료했는지를 나타내는 비트 상태 정보를 설정하는 단계와,

이벤트에 응답하여, 상기 주어진 벡터 명령의 처리를 중단하는 단계와,

상기 주어진 벡터 명령의 처리로의 복귀를 나타내는 이벤트로부터의 복귀 요청에 응답하여, 완료한 것으로서 상기 비트 상태 정보로 나타낸 상기 복수의 벡터 명령의 비트들(beats)을 억제하면서 상기 복수의 벡터 명령의 처리를 재개하는 단계를 포함하고,

상기 벡터 값은 데이터 요소 크기 정보에 의해 지정된 복수의 데이터 요소 크기 중 하나를 갖는 데이터 요소들을 포함하고,

적어도 몇몇 예들은 상술한 장치에 대응하는 명령 실행 환경을 제공하도록 호스트 데이터 처리 장치를 제어하는 프로그램 명령들을 포함하는 가상 머신 컴퓨터 프로그램을 제공한다.

가상 머신 컴퓨터 프로그램을 저장하는 컴퓨터 판독 가능한 저장 매체가 또한 제공될 수 있다. 저장 매체는 비일시적인 저장 매체일 수 있다.

본 기술의 추가적인 국면, 특징 및 이점은 첨부 도면들과 관련하여 판독될 예들에 대한 다음의 설명으로부터 명백해질 것이다.

도 1은 벡터 명령들의 처리를 지원하는 데이터 처리 장치의 일례를 개략적으로 도시한 것이다.
도 2는 벡터 명령들의 오버랩된 실행의 예를 도시한 것이다.
도 3은 명령들의 실행의 서로 다른 경우들 간의 런 타임에서 또는 상이한 프로세서 구현들 사이의 연속적인 벡터 명령들 간의 오버랩의 양을 스케일링하는 3가지 예를 도시한 것이다.
도 4는 스칼라 명령의 실행이 두 벡터 명령 간의 오버랩을 깨는 예를 도시한 것이다.
도 5는 다수의 벡터 명령들의 블록의 어느 비트(beats)가 완료되었는지를 나타내는 비트 상태 정보에 대한 예시적인 인코딩을 도시한 것이다.
도 6은 디버그 이벤트 또는 예외의 발생에 대한 비트 상태 정보를 기록하는 두 가지 예를 도시한 것이다.
도 7은 비트 상태 정보를 사용하여 디버그 이벤트 또는 예외로부터의 복귀 후 처리를 재개하는 예를 도시한 것이다.
도 8은 벡터 명령의 완료에 응답하여 상태 정보를 업데이트하는 방법을 도시한 것이다.
도 9는 예외 이벤트를 처리하는 방법을 도시한 것이다.
도 10은 예외 이벤트의 핸들링으로부터 복귀하는 방법을 도시한 것이다.
도 11 및 도 12는 혼합 스칼라 벡터 명령들의 비트들(beats)을 오버랩할 때 완화된 실행의 예를 도시한 것이다.
도 13은 상이한 클래스의 명령들을 처리하기 위한 처리 회로 내의 상이한 하드웨어 유닛들의 예를 도시한 것이다.
도 14는 동일한 클래스의 2개의 혼합 스칼라 벡터 명령들이 마주칠 때 오버랩된 실행을 방지하는 예를 도시한 것이다.
도 15는 소정 수의 중간 명령들에 의해 2개의 혼합 스칼라 벡터 명령들을 분리하는 것이 완화된 실행을 피하는 것을 돕는 방법을 나타내는 예이다.
도 16은 완화된 실행을 방지하기 위해 배리어 명령을 사용하는 예를 도시한 것이다.
도 17은 혼합 스칼라 벡터 명령들을 처리하는 방법을 도시한 것이다.
도 18은 혼합 스칼라 벡터 명령들의 오버랩된 실행의 또 다른 예를 도시한 것이다
도 19는 사용할 수 있는 가상 머신 구현을 도시한 것이다.

몇 가지 구체적인 예를 아래에서 설명한다. 본 기술은 이들 정확한 예들에 한정되지 않는다는 것을 이해할 것이다.

주어진 명령 세트 아키텍처에 따라 기록된 소프트웨어는 상이한 하드웨어 구현을 갖는 다양한 상이한 데이터 처리 장치에서 실행될 수 있다. 주어진 명령 세트가 실행될 때 아키텍처에 의해 예상되는 결과를 제공하는 한, 특정 구현은 이 아키텍처 컴플라이언스(architecture compliance)를 달성하는 방식으로 마이크로 아키텍처 디자인(micro-architectural design)을 자유롭게 변경할 수 있다. 예를 들어, 일부 애플리케이션의 경우, 에너지 효율이 성능보다 더 중요할 수 있으므로 명령 세트 아키텍처로부터 명령들을 실행하기 위해 제공된 처리 회로의 마이크로 아키텍처 디자인은 이것이 성능을 희생하더라도 가능한 적은 에너지를 소비하도록 설계될 수 있다. 다른 애플리케이션은 성능을 에너지 효율보다 더 중요한 기준으로 볼 수 있으므로 명령들의 처리량은 높일 수 있지만, 더 많은 전력을 소모할 수 있는 보다 복잡한 하드웨어 구조를 포함할 수 있다. 따라서, 다양한 서로 다른 에너지 또는 성능 포인트(performance point) 전체에 걸쳐서 스케일링을 지원하도록 명령어 세트 아키텍처를 설계하는 것이 바람직할 수 있다.

일부 명령 세트 아키텍처는 소스 피연산자 또는 결과 값(또는 둘 다)이 다수의 데이터 요소를 포함하는 벡터인 처리를 수행하는 처리 회로를 트리거하기 위한 벡터 명령들을 지원한다. 일부 마이크로 아키텍처 구현은 벡터의 모든 요소를 병렬로 처리할 수 있지만, 다른 구현은 한 번에 벡터 한 부분을 처리할 수 있다.

소정의 명령 실행 스레드(thread)를 처리하는 동안, 처리 회로가 일부 다른 유형의 처리를 수행할 수 있도록 현재 스레드의 주어진 벡터 명령의 중단(suspension)을 트리거하는 특정 이벤트가 때때로 검출될 수 있다. 예를 들어, 이벤트는, (처리 회로에 의해 실행되는 디버그 명령들(debug instructions)을 주입하여 레지스터 상태와 같은 내부 리소스(resources)를 판독함으로써, 또는 외부 디버거(debugger)로부터 처리 회로의 내부 리소스에 직접 액세스함으로써) 외부 디버거가 처리 회로의 동작을 검사할 수 있는 디버그 상태로의 스위칭을 트리거하는 디버그 이벤트, 또는 에러, 결함 또는 외부 이벤트가 발생했음을 나타내는 예외 이벤트일 수 있다. 그러한 이벤트 중 일부는 가능한 한 빨리 이벤트에 응답하는 것이 중요하다는 점에서 성능이 중대할 수 있다. 이벤트의 처리에 이어서, 이벤트로부터의 복귀 요청(return-from-event request)(예를 들어, 예외 복귀 또는 디버그 상태로부터의 복귀)은 이벤트가 발생하기 전에 수행되는 처리로의 복귀를 트리거할 수 있다.

본 원에 기술된 처리 회로는 각 비트(beat)가 벡터 값의 일부에 대응하는 처리를 포함하는 다수의 비트(beats)의 처리를 수행함으로써 벡터 명령을 처리하도록 구성된다. 처리 회로는 둘 이상의 벡터 명령들의 그룹의 어떤 비트들(beats)이 완료되었는지를 나타내는 비트 상태 정보를 설정하도록 구성된다. 주어진 벡터 명령의 처리로의 복귀를 나타내는 이벤트로부터의 복귀 요청에 응답하여, 처리 회로는 비트 상태 정보를 사용하여 어느 비트(beat)가 이미 완료되었는지를 판정하고, 이미 완료된 것으로서 비트 상태 정보에 의해 표시된 2개 이상의 명령들의 그룹의 비트(beat)를 억제한다. 주어진 벡터 명령의 주어진 비트(beat)는, 예를 들어, 그 비트(beat)와 관련된 처리 동작을 전혀 수행하지 않음으로써, 또는 그 처리 동작의 결과를 레지스터 또는 다른 저장 위치에 기록하는 것을 마스킹(masking)함으로써 억제될 수 있다.

이러한 구성은 벡터 명령들을 지원하는 프로세싱 아키텍처가 상이한 성능 및 에너지 포인트에 보다 효율적으로 스케일링할 수 있게 한다. 2개 또는 그 이상의 벡터 명령들의 완료된 비트(beats)를 추적하는 비트 상태 정보(beat status information)를 제공함으로써, 이것은 특정 마이크로 아키텍처 구현이 상이한 벡터 명령들의 실행이 오버랩되는 양을 변화시키는 자유를 주어, 각 부분적으로 실행된 명령의 진행 상황을 추적하면서 상이한 벡터 명령들의 각 비트(beat)를 서로 병렬로 수행하는 것이 가능하다. 일부 마이크로 아키텍처 구현에서는 각 벡터 명령들의 실행을 전혀 오버랩하지 않도록 선택할 수도 있기 때문에, 하나의 벡터 명령의 모든 비트(beats)가 다음 명령이 시작되기 전에 완료된다. 다른 마이크로 아키텍처는 제2 벡터 명령의 제1 서브세트의 비트(beats)가 제1 벡터 명령으로부터의 제2 서브세트의 비트(beats)와 병렬로 수행되도록 연속적인 벡터 명령들의 실행을 스태거(stagger)할 수 있다.

주어진 하드웨어 구현이 벡터 명령들의 실행을 구현하기 위해 선택하는 특정 방식과 관계없이, 비트 상태 정보를 정의함으로써, 비트 상태 정보가 이벤트의 처리 후에 완료된 명령들을 부분적으로 재개할 수 있게 하기 때문에 주어진 벡터 명령이 스레드를 중단하기 전에 모든 비트(beats)를 완료할 때까지 기다리는 것이 필요하지 않기 때문에, 명령 실행의 스레드를 중단하는 이벤트에 보다 신속하게 응답할 수 있다. 이 동작은 또한 구조적으로 명령이 그것의 실행을 완료할 수 없는 정확한 결함인 예외를 처리하는 데 중요할 수 있다. 예외 응답 레이턴시(exception response latency)는 예외 다음에 처리를 다시 시작할 때 레이턴시를 줄이는 것보다 더 중요할 수 있으므로, 이 접근법은 또한 예외 처리에 이점을 제공할 수 있다.

대조적으로, 단일 명령의 진행에 대한 정보만 기록하거나, 명령들의 그룹의 비트(beats)의 특정 조합이 실행 스레드의 중단 시에 완료되었다고 가정하는 접근법은, 마이크로 아키텍처의 하드웨어 설계자가 상이한 벡터 명령들의 오버랩의 양을 스케일링하는 더 적은 유연성을 제공할 것이다. 또 다른 대안의 접근법은. 부분적으로 실행된 명령들의 완료된 비트들(beats)의 결과를 전체 명령이 완료될 때까지 커밋(committed)되지 않은 추측 상태(speculative state)로서 저장하는 것이지만, 이것은 저전력 구현에 바람직하지 않은 부가적인 저장 및 제어 오버헤드를 요구할 것이다. 다수의 벡터 명령들의 어떤 특정 비트(beats)가 완료되었는지를 나타내는 비트 상태 정보를 제공하고, 이것을 사용하여 적절한 포인트에서 처리를 재개하면, 명령 세트 아키텍처가 훨씬 더 유연하여, 추측 상태를 관리할 필요가 없이, 다양한 상이한 마이크로 아키텍처에 있어서 성능과 에너지 효율을 향상시키는데 도움이 된다.

도 1은 벡터 명령들의 처리를 지원하는 데이터 처리 장치(2)의 예를 개략적으로 도시한 것이다. 이것은 설명의 용이함을 위해 간략화된 도면이며, 실제로 장치는 간결함을 위해도 1에 도시되지 않은 많은 요소를 가질 수 있음을 이해할 것이다. 장치(2)는 명령 디코더(6)에 의해 디코딩된 명령에 응답하여 데이터 처리를 수행하기 위한 처리 회로(4)를 포함한다. 프로그램 명령들은 메모리 시스템(8)으로부터 페치되고 명령 디코더에 의해 디코딩되어 처리 회로(4)를 제어하는 제어 신호들을 생성하여 아키텍처에 의해 정의된 방식으로 명령들을 처리한다. 예를 들어, 디코더(6)는 디코딩된 명령들의 연산코드(opcode) 및 명령들의 임의의 부가적인 제어 필드를 해석하여 처리 회로(4)가 산술 연산, 로드/저장 연산 또는 논리 연산과 같은 연산을 수행하도록 적절한 하드웨어 유닛을 활성화시키는 제어 신호들을 생성할 수 있다. 상기 장치는 처리 회로의 동작을 구성하기 위한 제어 정보 및 처리 회로(4)에 의해 처리될 데이터 값들을 저장하기 위한 레지스터들(10)의 세트를 갖는다. 산술 또는 논리 명령들에 응답하여, 처리 회로(4)는 레지스터(10)로부터 피연산자를 판독하고 명령들의 결과를 레지스터(10)에 다시 기록한다. 로드/저장(load/store) 명령들에 응답하여, 데이터 값들은 처리 회로를 통해서 레지스터(10)와 메모리 시스템(8) 사이에서 이동한다. 메모리 시스템(8)은 주 메모리뿐만 아니라 하나 이상의 레벨의 캐시를 포함할 수 있다.

레지스터(10)는 단일 데이터 요소를 포함하는 스칼라 값들을 저장하기 위한 다수의 스칼라 레지스터를 구비하는 스칼라 레지스터 파일(12)을 포함한다. 명령 디코더(6) 및 처리 회로(4)에 의해 지원되는 일부 명령들은 스칼라 레지스터(12)에 다시 기록되는 스칼라 결과를 생성하기 위해 스칼라 레지스터(12)로부터 판독된 스칼라 피연산자를 처리하는 스칼라 명령들이다.

레지스터(10)는 또한 다수의 데이터 요소를 포함하는 벡터 값을 저장하기 위한 다수의 벡터 레지스터를 포함하는 벡터 레지스터 파일(14)을 포함한다. 벡터 명령에 응답하여, 명령 디코더(6)는 처리 회로(4)를 제어하여, 벡터 레지스터(14) 중 하나로부터 판독된 벡터 피연산자의 각 요소에 대해 다수의 레인의 벡터 처리를 수행하여, 스칼라 레지스터(12)에 기록될 스칼라 결과 또는 벡터 레지스터(14)에 기록될 추가 벡터 결과를 생성한다. 일부 벡터 명령들은 하나 이상의 스칼라 피연산자로부터 벡터 결과를 생성하거나, 벡터 레지스터 파일(14)로부터 판독된 벡터 피연산자에 대한 벡터 처리의 레인뿐만 아니라 스칼라 레지스터 파일 내의 스칼라 피연산자에 대하여 부가적인 스칼라 연산을 수행할 수 있다. 따라서, 일부 명령들은 하나 이상의 소스 레지스터들 중 적어도 하나와 명령의 목적지 레지스터가 벡터 레지스터(14)이고 하나 이상의 소스 레지스터들 및 목적지 레지스터의 다른 하나가 벡터 레지스터(14)인 혼합 스칼라 벡터 명령들일 수 있다. 벡터 명령은 또한 데이터 값들이 벡터 레지스터(14)와 메모리 시스템(8) 내의 위치 사이에서 전송되게 하는 벡터 로드/저장 명령들을 포함할 수 있다. 로드/저장 명령들은 메모리 내의 위치가 어드레스들의 연속 범위에 대응하는 연속적인 벡터 로드/저장 명령들, 또는 다수의 이산 어드레스를 지정하고 이들 어드레스의 각각으로부터 벡터 레지스터의 각 요소로 데이터를 로딩하거나 벡터 레지스터의 각 요소로부터 이산 어드레스로 데이터를 저장하도록 처리 회로(4)를 제어하는 분산/수집(scatter/gather) 타입 벡터 로드/저장 명령들을 포함할 수도 있다.

처리 회로(4)는 다양한 서로 다른 데이터 요소 크기를 갖는 벡터들의 처리를 지원할 수 있다. 예를 들어, 128비트(bit) 벡터 레지스터(14)는 예를 들어 16개의 8비트(bit) 데이터 요소, 8개의 16비트(bit) 데이터 요소, 4개의 32비트(bit) 데이터 요소 또는 2개의 64비트(bit) 데이터 요소로 분할될 수 있다. 레지스터 뱅크(10) 내의 제어 레지스터는 사용되는 현재 데이터 요소 크기를 지정할 수 있거나, 또는 이것은 실행될 주어진 벡터 명령의 파라미터일 수 있다.

레지스터(10)는 또한 처리 회로(4)의 처리를 제어하기 위한 다수의 제어 레지스터를 포함한다. 예를 들어, 이들은 프로세싱되고 있는 현재 실행 포인트에 대응하는 명령의 어드레스를 나타내는 프로그램 카운터 어드레스를 저장하는 프로그램 카운터 레지스터(16), 함수 호출(function call)을 처리한 후 처리가 진행될 복귀 어드레스를 저장하는 링크 레지스터(18), 스택 데이터 구조의 메모리 시스템(8) 내의 위치를 나타내는 스택 포인터 레지스터(20), 및 비트 상태 정보를 저장하는 비트 상태 레지스터(22)를 포함할 수도 있는데, 이는 이하에서 보다 상세하게 설명될 것이다. 이들은 저장될 수 있는 제어 정보의 타입 중 일부일 뿐이고 실제로는 아키텍처의 주어진 명령 세트가 그 아키텍처에 의해 정의된 것처럼 다른 많은 제어 파라미터를 저장할 수 있음을 알 것이다. 예를 들어, 제어 레지스터는 벡터 레지스터의 전체 폭 또는 벡터 처리의 주어진 경우(instance)에 대해 사용되고 있는 현재 데이터 요소 크기를 지정할 수 있다.

처리 회로(4)는 상이한 클래스의 명령들을 처리하기 위한 다수의 별개의 하드웨어 블록들을 포함할 수 있다. 예를 들어, 도 13에 도시된 바와 같이, 메모리 시스템(8)과 상호 작용하는 로드/저장 명령들은 전용 로드/저장 유닛(200)에 의해 처리되어도 되지만, 산술 또는 논리 명령들은 산술 논리 유닛(ALU) 202, 204에 의해 처리될 수 있다. ALU 자체는 곱셈을 수반하는 연산에서 수행하기 위한 곱셈 누산 유닛(multiply-accumulate unit; MAC)(202)과, 다른 종류의 ALU 연산을 처리하기 위한 추가 유닛(204)으로 더 구분될 수도 있다. 부동 소수점 명령들을 처리하기 위해 부동 소수점 유닛(206)이 또한 제공될 수 있다. 벡터 처리를 수반하지 않는 순수 스칼라 명령들은 또한 벡터 명령들과 비교하여 별도의 하드웨어 블록으로 처리되거나 동일한 하드웨어 블록을 재사용할 수 있다.

디지털 신호 처리(DSP)와 같은 일부 애플리케이션에서는, 대략 동일한 수의 ALU 및 로드/저장 명령들이 있을 수도 있으므로 MAC과 같은 일부 대형 블록은 상당한 시간 동안 유휴 상태(idle)로 있을 수 있다. 이러한 비효율성은, 실행 리소스가 더 높은 성능을 얻기 위해 벡터 레인의 수로 스케일링되기 때문에 벡터 아키텍처상에서 악화될 수 있다. 더 작은 프로세서(예를 들어, 단일 발행, 인오더 코어(in-order core))에서 완전히 스케일 아웃된(fully scaled out) 벡터 파이프라인의 에어리어 오버헤드(area overhead)는 금지될 수 있다. 이용 가능한 실행 리소스를 더 잘 사용하면서 영역의 영향을 최소화하기 위한 한 가지 방법은, 도 2에 나타낸 것처럼, 명령들의 실행을 오버랩하는 것이다. 이 예에서, 3개의 벡터 명령은 로드 명령 VLDR, 곱셈 명령 VMUL 및 시프트 명령 VSHR을 포함하고, 이들 명령 모두는 그들 사이에 데이터 의존성이 있더라도, 동시에 실행될 수 있다. 이것은 VMUL의 요소 1이 Q1의 요소 1에만 의존되고, Q1 레지스터 전체에 의존되지 않아서, VMUL 실행이 VLDR 실행이 완료되기 전에 시작할 수 있기 때문이다. 명령들이 오버랩하도록 함으로써, 멀티플라이어(multiplier)와 같은 비싼 블록을 더 오래 활성화 상태로 유지할 수 있다.

따라서, 마이크로 아키텍처 구현이 벡터 명령들의 실행을 오버랩할 수 있게 하는 것이 바람직할 수 있다. 그러나, 아키텍처가 고정된 양의 명령 오버랩이 있다고 가정하면, 마이크로 아키텍처 구현이 아키텍처에 의해 가정된 명령 오버랩의 양과 실제로 일치하면 높은 효율성을 제공할 수 있지만, 그것은 상이한 오버랩을 사용하거나 전혀 오버랩하지 않는 상이한 마이크로 아키텍처로 스케일되면 문제를 일으킬 수 있다.

대신에, 아키텍처는 도 3의 예들에 도시된 바와 같이 다양한 서로 다른 오버랩을 지원할 수도 있다. 벡터 명령의 실행은 "비트(beats)"라고 하는 부분들로 분할되고, 각 비트(beat)는 소정의 크기의 벡터의 일부의 처리에 대응한다. 비트(beat)는 완전히 실행되거나 전혀 실행되지 않고, 부분적으로 실행될 수 없는 벡터 명령의 극소의 부분이다. 하나의 비트(beat)로 처리되는 벡터의 부분의 크기는 아키텍처에 의해 정의되며 벡터의 임의의 부분일 수 있다. 도 3의 예에서, 비트(beat)는 벡터 폭의 1/4에 해당하는 처리로서 정의되어, 벡터 명령당 4개의 비트(beat)가 있다. 분명히, 이것은 단지 하나의 예일 뿐이며 다른 아키텍처는 서로 다른 수의 비트(beats), 예를 들어 2개 또는 8개를 사용할 수도 있다. 하나의 비트(beat)에 대응하는 벡터의 부분은 처리되고 있는 벡터의 데이터 요소 크기보다 크거나 작거나 동일한 크기일 수 있다. 따라서, 요소 크기가 구현마다 또는 런 타임(run time) 시 상이한 명령들 사이에서 변할지라도, 비트(beat)는 벡터 처리의 일정한 고정된 폭이다. 하나의 비트(beat)로 처리되고 있는 벡터의 부분이 다수의 데이터 요소를 포함하면, 각 요소가 독립적으로 처리되도록 보장하기 위해 각 요소들 사이의 경계에서 캐리 신호(carry signals)를 디스에이블할 수 있다. 하나의 비트(beat)로 처리된 벡터의 부분이 요소의 일부에만 해당하고 하드웨어가 병렬로 여러 비트(beats)를 계산하기에 충분하지 않은 경우, 한 비트(beat)의 처리 중에 생성된 캐리 출력은 그 다음의 비트의 처리에 대한 캐리 입력으로서 입력되어 두 비트(beat)의 결과가 함께 데이터 요소를 형성할 수도 있다.

도 3에 도시된 바와 같이, 처리 회로(4)의 상이한 마이크로 아키텍처 구현은 추상적인 아키텍처 클록의 하나의 "틱(tick)"에서 상이한 수의 비트(beats)를 실행할 수 있다. 여기에서, "틱(tick)"은 아키텍처 상태 발전(architectural state advancement)의 유닛에 해당한다(예를 들어, 간단한 아키텍처에서 다음 틱을 가리키도록 프로그램 카운터를 업데이트하는 것을 포함하면서, 명령을 실행하는 것과 관련된 모든 아키텍처 상태를 업데이트하는 경우에 각 틱이 해당될 수 있다). 파이프라이닝(pipelining)과 같은 공지된 마이크로 아키텍처 기술은, 단일 틱이 하드웨어 레벨에서 수행하기 위해서 다수의 클럭 사이클을 필요로 할 수도 있고 대신 하드웨어 레벨에서 단일 클럭 사이클이 다수의 명령의 여러 부분을 처리할 수도 있음을 의미할 수도 있다는 것을 본 기술의 당업자는 인식할 것이다. 그러나 이러한 마이크로 아키텍처 기술은 틱이 아키텍처 레벨에서는 극소이므로 소프트웨어에서는 볼 수 없다. 간결성을 위해, 이러한 마이크로 아키텍처는 본 개시의 추가 설명 중에는 무시된다.

도 3의 하부 예에 도시된 바와 같이, 일부 구현 예들은 하나의 틱 내에서 모든 비트들(beats)을 병렬로 처리하기 위한 충분한 하드웨어 리소스를 제공함으로써, 동일한 틱에서 벡터 명령의 4개의 비트(beats) 모두를 스케줄링할 수도 있다. 이것은 고성능 구현에 적합할 수 있다. 이 경우, 전체 명령을 하나의 틱에서 완료할 수 있기 때문에 아키텍처 레벨에서의 명령들 사이에서는 어떤 오버랩도 필요하지 않다.

반면에, 더 에어리어 효율적인 구현은 틱당 2개의 비트(beats)만을 처리할 수 있는 더 좁은 처리 유닛을 제공할 수 있으며, 도 3의 중간 예에 도시된 바와 같이, 명령 실행은 제1 명령의 제3 또는 제4 비트(beat)와 병렬로 수행되는 제2 벡터 명령의 제1 및 제2 비트(beat)와 오버랩될 수 있고, 여기서 이들 명령은 처리 회로 내의 상이한 실행 유닛에서 실행된다(예컨대, 도 3에서, 제1 명령은 로드/저장 유닛(200)을 사용하여 실행되는 로드 명령이고, 제2 명령은 MAC(202)을 사용하여 실행되는 곱셈 누산 명령이다).

한층 더 에너지/에어리어 효율적인 구현은 더 좁고 한 번에 한 비트(beat)만을 처리할 수 있는 하드웨어 유닛을 제공할 수 있고, 이 경우 하나의 비트(beat)가 틱마다 처리될 수 있으며, 명령 실행은 도 3의 상부 예에 도시된 것처럼 한 비트(beat)씩 오버랩되어 스태거된다(이것은 위의 도 2에 표시된 예와 같다).

도 3에 도시된 오버랩은 단지 일부 예일 뿐이며, 다른 구현 예도 가능하다는 것을 이해할 것이다. 예를 들어, 처리 회로(4)의 일부 구현 예들은 동일한 틱에서 병렬로 다수의 명령의 이중 발행(dual issue)을 지원할 수 있으므로, 명령들의 더 큰 스루풋(throughput)이 있다. 이 경우, 하나의 사이클에서 함께 시작하는 2개 이상의 벡터 명령은 다음 사이클에서 시작하는 두 개 이상의 벡터 명령과 오버랩된 일부 비트(beats)를 가질 수도 있다.

서로 다른 성능 포인트로 스케일하도록 구현마다 오버랩되는 양을 다르게 하는 것뿐만 아니라, 벡터 명령들 간의 오버랩의 양도 프로그램 내의 벡터 명령들의 실행의 서로 다른 경우들 사이에서 런 타임 시에 변경될 수 있다. 따라서, 처리 회로(4)는 주어진 명령이 이전 명령에 대해 실행되는 타이밍을 제어하기 위해 도 1에 도시된 것처럼 비트 제어 회로(beat control circuitry)(30)를 구비할 수 있다. 이것은 명령에 이용 가능한 리소스에 의존하거나, 구현하기가 더 어려운 특정 코너 케이스에서 명령들을 오버랩하지 않도록 선택하는 자유를 마이크로 아키텍처에 준다. 예를 들어, 동일한 리소스를 필요로 하는 주어진 타입(예를 들어 곱셈 누산)의 연속적인 명령들이 있고 이용 가능한 모든 MAC 또는 ALU 리소스가 이미 다른 명령어에 의해 사용되고 있는 경우, 다음 명령 실행을 시작하기 위한 충분한 자유 리소스(free resources)가 없을 수도 있으므로 오버랩보다는, 제1 명령의 발행이 제1 명령이 완료될 때까지 대기할 수 있다.

도 4에 도시된 바와 같이, 두 개의 벡터 명령들 사이의 오버랩은 개재(intervening) 스칼라 명령이 존재하는 경우에도 방지될 수 있다. 이것은 스칼라 명령이 벡터 명령의 마지막 비트(beat)의 결과에 의존할 수 있고 제2 벡터 명령이 모든 비트(beats)에서 스칼라 결과에 의존할 수 있어서, 벡터 명령들과 스칼라 명령들이 오버랩하는 것을 회피하는 것이 더 안전할 수 있기 때문이다.

상술한 바와 같이 오버랩이 허용되는 경우, 동시에 실행되는 다수의 명령들이 있을 수도 있다. 프로그램 카운터(16)는 완료될 적어도 하나의 비트(beat)를 갖는 가장 오래된 미완료 명령의 어드레스를 추적할 수도 있다. 벡터 명령이 그것의 최종 비트(beat)를 완료하면 프로그램 카운터가 증가될 수 있다.

실행 벡터 명령의 다양한 서로 다른 오버랩을 허가하면, 다양한 성능 포인트 전체에 걸쳐서 하드웨어 리소스를 보다 효율적으로 사용할 수 있으므로, 예외 또는 디버그 이벤트나 실행의 현재 스레드의 중단(suspension)을 트리거하는 다른 이벤트를 처리하는 데 약간의 복잡성이 발생할 수 있다. 예를 들어, 도 2에 나타낸 예에서, 제4 틱에서 예외가 발생하면 레지스터 파일에 여러 개의 명령으로부터의 부분 업데이트가 포함된다. 이를 처리하는 한 가지 방법은 예외가 발생할 경우 되돌릴 수 있는 추측 상태로서 부분 업데이트를 취급하는 것이지만, 이것은 필요한 하드웨어의 양을 증가시킬 수 있는데, 왜냐하면 이들이 커밋(committed)될 때까지 메모리 시스템(8)에 데이터를 저장하기 위한 저장 요청을 버퍼링하고, 추측 상태를 추적하기 위해 하드웨어에 부가적인 레지스터를 제공해야 할 수도 있기 때문이다. 또 다른 접근법은 벡터 명령을 통해 중간에 예외를 전혀 취하지 않도록 하는 것이며, 가장 오래된 미완성된 명령이 완료될 때까지 예외를 취하지만, 예외 처리 레이턴시를 증가시키는 지연(delay)은 바람직하지 않을 수 있으며, 예외가 정확한 결함인 경우에는 이러한 동작은 결함과 관련된 아키텍처 보증을 손상시킬 수 있다.

대신에, 도 5에 도시된 바와 같이, 비트 상태 레지스터(22)는 인접한 명령들의 그룹의 어느 비트(beats)가 예외, 디버그 이벤트 또는 현재 스레드의 중단을 초래하는 다른 이벤트의 시점에서 완료되었는지를 추적하는 비트 상태 값(beat status value)을 기록하는데 사용될 수 있다. 실행의 오버랩 특성을 아키텍처에 노출시킴으로써, 이것은 마이크로 아키텍처의 복잡성을 줄이고 전력 및 면적 효율성을 높이는 데 도움이 될 수 있다.

도 5의 예에서, 비트 상태 정보는 3개의 벡터 명령 A, B, C의 그룹의 완료 비트(beat)를 추적하는 데, 여기서 명령 A는 가장 오래된 미완성 벡터 명령에 대응하고, 명령 B는 명령 A 이후의 다음 벡터 명령이고, 명령 C는 명령 B 이후의 다음 벡터 명령이다. 표기 Ax는 명령 A의 x번째 비트(beat)를 나타내며, 여기서 x는 4비트(beat) 벡터 구현 예에서 1과 4 사이에 있다. A2는 명령 A의 제2 비트(beat)이다. 도 5는 비트 상태 정보를 사용하여 3개의 명령이 추적되는 예를 도시하지만, 더 많은 수의 명령이 주어진 지점에서 부분적으로 완료될 수 있는 다른 예에서는, 비트 상태 정보는 더 많은 수의 명령을 추적할 수 있다. 예를 들어, 이중 발행(dual issue)이 지원되면, 3개 이상의 명령에 대해 비트 진행(beat progress)을 나타내는 것이 바람직할 수 있다. 비트 상태 필드(beat status field)의 각 값은 완료된 비트(beat)의 주어진 조합에 할당된다. 예를 들어, 비트 상태 값 0011은 명령 A의 제1 및 제2 비트(beat)와 명령 B의 제1 비트(beat)가 완료되었음을 나타낸다. 비트 상태 정보의 특정 인코드된 값의 명령들의 각 그룹의 비트들(beats)의 특정 세트에 대한 특정 맵핑(mapping)은 임의적이며 다양할 수 있다. 이 예에서 비트 상태 값 0000은 불완전한 명령이 없으므로, 불완전한 명령의 완료 비트(beat)가 없다는 것을 나타낸다. 이것은 예를 들어 프로세서가 스칼라 명령을 실행했을 때 발생할 수 있다.

도 6은 실행의 현재 스레드의 중단이 있는 시점에 기록된 비트 상태 정보의 몇 가지 예를 나타낸다. 도 6의 상단 예에서, 벡터 명령은 틱당 한 비트(beat)로 실행되고 제4 틱에서는 디버그 이벤트 또는 예외가 발생한다. 따라서, 이 시점에서 명령 A의 제1의 3개의 비트(beat), 명령 B의 제1의 2개의 비트(beat) 및 명령 C의 제1의 비트(beat)는 이미 완료되었지만 비트 A4, B3, C2, D1은 여전히 수행되어야 한다. 따라서, 비트 상태 정보는 도 5의 예에 따라 비트(beat) A1, A2, A3, B1, B2 및 C1이 이미 완료되었음을 나타내는 값 0111을 가질 것이다.

유사하게, 도 6의 예의 하단에서, 실행되는 명령들은 명령 B 및 C가 오버랩될 수 없도록 되어 있고(예를 들어, 그들은 동일한 하드웨어 유닛의 사용을 요구했기 때문에), 그래서 이번에는 명령 C 및 D가 디버그 이벤트 또는 예외가 발생했을 때 아직 시작되지 않았다. 이번에는 틱 4에서 발생하는 예외는 비트(beat) A1, A2, A3, B1 및 B2가 이미 완료되었지만 Cl이 아니라는 것을 나타내는 비트 상태 정보 0110의 기록을 트리거할 것이다.

유사하게, 도 3의 틱당 2비트(beat)의 예에서, 틱 2에서 예외가 발생하면 비트(beat) A1 및 A2만이 완료되었고 비트 상태 값은 0010이 될 것이다. 비트 상태 정보의 값 0001 및 0010은 예외 시에 하나의 명령 A만이 부분적으로 완료되었음을 나타내며, 비트 상태 정보는 여전히 다음 2개의 명령 B, C의 비트들(beats) 중 어느 비트(beat)도 완료되지 않았음을 식별하기 때문에 다수의 명령의 그룹의 어느 비트(beat)가 완료되었는지를 나타낸다는 점에 주의한다.

도 3의 틱당 4비트(beat) 예에서, 비트 상태 값은 각 명령이 1틱 내에서 완료하기 때문에 예외가 발행할 때 부분적으로 완료된 명령이 없으므로 예외가 발생할 때와 관계없이 0000이 된다.

디버그 이벤트 또는 예외가 발생하면, 복귀 어드레스는 가장 오래된 미완료 명령의 어드레스를 나타내는 프로그램 카운터(16)의 현재 값으로 설정된다. 따라서도 6의 예에서, 복귀 어드레스는 명령 A의 어드레스로 설정될 것이다. 복귀 어드레스는 스택 포인터 레지스터의 값에 대해 스택 위의 위치에 또는 복귀 어드레스 레지스터에 포함하는 다양한 장소에 저장될 수 있다 ,

도 7에 도시된 바와 같이, 이것은 프로세서가 이벤트로부터의 복귀 요청에 응답하여 (예를 들어, 디버그 모드 또는 예외 핸들러로부터의 복귀 시에) 비트 상태 레지스터(22)에서의 비트 상태 정보 및 복귀 어드레스에 의거하여 결정된 포인트로부터 프로세싱을 재개하는 것을 가능하게 한다. 이벤트로부터의 복귀 요청은 디버그 이벤트의 경우에 디버거에 의해, 또는 예외 이벤트의 경우에는 예외 핸들러에 의해 이루어질 수 있다. 이벤트로부터의 복귀 요청에 이어서, 처리될 명령들의 페칭은 이 경우 명령 A에 대응하는, 복귀 어드레스로 나타낸 어드레스로부터 재개된다. 명령 B, C 및 D가 이어진다(이 예는 도 6의 상단 예에 해당). 그러나, 복귀 후 처음 몇 사이클 동안, 이미 완료된 것으로서 비트 상태 정보로 나타낸 어떤 비트들(beats)은 억제된다. 프로세서는 대응하는 처리 동작이 전혀 수행되지 않게 함으로써 이러한 비트들(beats)을 억제할 수 있다(예를 들어, 데이터를 로드 또는 저장하기 위한 요청을 억제 또는 ALU 또는 MAC의 디스에이블). 대안으로, ALU 연산의 경우에도 연산을 여전히 수행할 수 있지만, 프로세서는 연산의 결과의 기록을 억제할 수 있어(즉, 목적지 벡터 레지스터의 일부의 업데이트를 억제), 레지스터 상태에 영향을 미치지 않는다. 주어진 비트(beat)를 억제하는 또 다른 방법은 주어진 비트(beat)에 대응하는 목적지 벡터 레지스터의 일부를 미리 결정된 값(예를 들어, 0)으로 설정하는 것이다. 제4 틱이 도달하면, 파이프라인은 디버그 이벤트나 예외가 이전에 발생한 지점에 도달한 다음 처리가 정상적으로 계속된다. 따라서, 예외 복귀 후 처음 몇 사이클 동안, 프로세서는 유용한 작업을 수행하지 않을 수도 있으며, 본질적으로 원래의 예외 또는 디버그 이벤트가 발생했을 때 진행(in-flight) 중이던 다수의 명령을 다시 페치하고 있다. 그러나, 예외 복귀 레이턴시는 일부 애플리케이션에서는 종종 중요하지 않으므로, 이것은 예외를 취할 때 레이턴시를 줄이기 위한 좋은 방법일 수 있고, 또한 이것은 완료되지 않은 명령들의 결과를 추측적으로 저장할 필요가 없으므로 예외 시에 저장할 필요가 있는 아키텍처 상태의 양을 줄이는데 도움이 된다. 이 접근법은 또한 벡터 명령의 비트(beat)에 의해 발생된 정확한 결함인 예외의 처리를 가능하게 한다.

몇몇의 경우에, 다수의 명령의 그룹의 완료 비트(beats)를 나타내는 비트 상태 정보는 디버그 이벤트 또는 예외 발생에 응답하여 설정될 수 있다. 그러나, 몇몇 구현 예에서, 예외가 발생했는지 여부에 관계없이, 명령이 완료될 때마다 비트 상태 레지스터를 업데이트하는 것이 더 쉬울 수 있으므로, 다음 틱에서 예외가 발생하면, 비트 상태 레지스터(22)는 명령들의 그룹의 이미 완료된 비트(beats)를 나타낸다. 따라서, 도 8은 벡터 명령이 완료될 때 상태를 업데이트하는 방법을 도시하는 흐름도이다. 스텝 50에서, 주어진 벡터 명령의 최종 비트(beat)가 완료된다. 이에 응답하여, 스텝 52에서, 프로그램 카운터(16)는 다음의 완료되지 않은 명령을 나타내는 값으로 업데이트된다. 스텝 54에서, 비트 상태 정보는 진행 중인 미완료 명령의 어느 비트(beats)가 이미 완료되었는지를 나타내도록 업데이트된다. 예를 들어, 비트 제어 회로(30)는 일련의 벡터 명령들의 실행을 스케줄링하는 타이밍들에 의거하여 비트 상태 레지스터(22)를 설정할 수 있다.

도 5는 비트 상태 정보(beat status information)의 하나의 예시적인 인코딩을 도시하지만, 또 다른 가능성은 명령 A, B, C 등의 그룹 중 하나의 1 비트(beat)에 각각 대응하는 다수의 비트(bits)를 포함하는 비트맵(bitmap)으로서 비트 상태 정보를 제공하는 것이다. 각 비트(bit)는 해당 비트(beat)가 완료되면 1로 설정되고 해당 비트(beat)가 완료되지 않았으면 0으로 설정된다(또는 그 반대). 그러나, 실제로는 이전 비트(beat)가 아직 완료되지 않은 경우 주어진 명령의 나중의 비트(beat)가 완료될 수 없으므로, 모든 비트(beat)에 대해 비트(bits)를 제공할 필요가 없으며, 더 작은 비트 필드(bit filed)의 특정 인코딩을 도 5의 예에서와 같이 완료된 비트(beatㄴ)의 특정 조합에 할당하는 것이 더 효율적일 수 있다.

도 9는 예외 이벤트에 응답하는 예를 도시하는 흐름도이다. 스텝 100에서, 예외 이벤트가 검출된다. 이에 응답하여, 스텝 102에서, 처리 회로 내의 예외 제어 회로는, 스택 포인터 레지스터(20)에 저장된 스택 포인터에 대한 오프셋에서 메모리 내의 위치에 레지스터 상태(스칼라 레지스터(12) 및 벡터 레지스터(14), 및 비트 상태 레지스터(22)의 현재 내용을 포함)를 저장(saving)하는 것을 트리거한다. 레지스터 값들을 저장하는 메모리 위치들의 그룹은 집합적으로 예외 스택 프레임이라고 칭한다. 스택 포인터는 레지스터 상태를 일시적으로 저장하기 위해 메모리에 제공된 스택 데이터 구조의 상단 또는 하단(구현 선택에 따라)을 나타내므로, 예외에 응답하여 호출된 예외 핸들러는 중단 중인 실행 스레드의 이전 상태를 잃지 않고 레지스터의 데이터를 겹쳐 쓸 수 있다. 일부 예들에서는, 모든 레지스터들 12, 14가 예외 상황에서 스택에 저장된 상태를 가질 수 있는 것은 아니다. 레지스터 파일들을, 예외가 발생하기 전에 실행중인 소프트웨어 스레드에 의해 또는 예외 처리 하드웨어에 의해 자동으로 저장된 "호출자(caller)" 상태와, 레지스터들이 예외 핸들러에 의해 겹쳐 써질 경우 스택에 이러한 레지스터들을 저장하는 것이 예외 핸들러의 책임인 "피호출자(callee)" 상태로 나눌 수 있다. 이 접근법은 레지스터들이 재사용되기 전에 일부 레지스터의 값을 보존하는 기능을 종종 필요로 하는 소프트웨어 호출 협약(software calling conventions)으로 더 나은 얼라인먼트(alignment)를 제공할 수 있다. 따라서, 하드웨어 예외 엔트리 처리의 일부로서 이들 레지스터를 저장하지 않으면 레지스터의 불필요한 이중 저장을 방지할 수 있다.

스텝 104에서, 예외 스택 프레임 내의 복귀 어드레스 위치는 가장 오래된 미완료 명령의 어드레스로 설정된다. 이것은 예외 핸들러의 완료 후에 처리가 분기할 수 있는 복귀 어드레스를 제공하여, 이전 처리를 재개한다. 선택적으로, 스텝 106에서, 스칼라 레지스터들(12) 또는 벡터 레지스터들(14) 및/또는 비트 상태 레지스터(22)의 적어도 일부의 레지스터 상태가 클리어될 수 있어, 그들의 내용이 예외 핸들러에 보이지 않도록 할 수 있다. 이것은 특정 안전한 애플리케이션이, 레지스터 내의 안전한 데이터를 보호하는 것이 바람직할 수도 있고, 또는 이전에 실행중인 스레드의 진행 상황에 예외 핸들러 가시성을 부여하는 것이 바람직하지 않은 경우 바람직할 수도 있다. 한편, 보안이 문제가 아니며 이전에 실행중인 상태에 예외 핸들러 가시성을 부여하는 것이 허용되면, 스텝 106은 생략될 수 있다.

스텝 108에서, 예외 처리 하드웨어는 발생한 예외가 결함 이벤트인지 여부를 검출한다. 예외 이벤트에는 결함 이벤트 및 비결함(non-fault) 이벤트가 포함될 수 있다. 결함 이벤트는 처리 회로(4)에 의해 실행되는 특정 명령에 의해 야기된 에러에 의해 트리거될 수도 있다. 예를 들어, 정의되지 않은 명령을 실행하려는 시도가 있으면, 또는 현재 실행중인 프로세스에 대상 어드레스에 대한 액세스 권한이 없거나 대상 어드레스에 대해 가상-물리 어드레스 변환이 아직 정의되지 않았기 때문에 로드/저장 명령이 메모리 결함을 트리거하면, 결함이 트리거될 수 있다. 반면에, 다른 타입의 비결함 예외는 특정 명령과 관련되지 않을 수도 있지만, 외부 이벤트(예를 들어, 디바이스 상의 버튼을 누르는 사용자, 또는 외부 디바이스 또는 주변 장치로부터 수신중인 신호) 또는 실행중인 프로그램(예를 들어, 알람 또는 리마인더(reminder)를 트리거하는 카운트 다운 타이머의 만료)에 의해 야기되지 않는 몇몇 다른 이벤트에 의해 트리거될 수도 있다. 현재 예외 이벤트가 결함 이벤트이면, 스텝 110에서 프로세서는 어떤 완료되지 않은 명령이 결함을 트리거했는지를 식별하는 몇몇 정보를 기록할 수도 있다. 상술한 오버랩 실행으로 인해 진행 중인 다수의 명령이 있을 수도 있기 때문에, 스텝 104에서 설정된 복귀 어드레스만으로는 어떤 특정 명령이 결함을 트리거했고 따라서 결함이 어떻게 처리될 수 있는지를 식별하기에 충분하지 않을 수도 있으므로, 결함이 있는 명령의 지시를 기록하면 특정 결함 조건을 올바르게 처리하는 데 도움이 될 수 있다(예를 들어, 진행 중인 여러 개의 로드/저장 명령이 있는 경우, 메모리 결함은 예를 들어 필요한 어드레스에 대한 변환 데이터에서 페이징(paging)함으로써 결함이 어드레싱될 수 있게 하는 특정 명령에 기인할 수 있다). 반면에, 예외가 결함 이벤트가 아니라면, 어떤 특정 명령이 예외를 트리거했는지 알지 못해서 예외가 처리될 수 있기 때문에 스텝 110은 생략된다. 예외 이벤트의 타입에 관계없이, 스텝 112에서, 프로세서는 검출된 예외 이벤트의 타입에 대응하는 예외 핸들러로의 분기(branch)를 트리거한다. 예를 들어, 프로세서는 검출된 예외 타입의 식별자에 의거하여 인덱싱되는 예외 벡터 테이블을 참조할 수 있고, 테이블은 대응하는 예외 핸들러의 어드레스를 제공할 수 있다.

도 10은 예외 처리로부터 복귀할 때 수행되는 동작을 예시하는 흐름도를 도시한 것이다. 예외 핸들러는 일반적으로 처리가 예외에 의해 중단된 이전 스레드로 돌아가야 함을 나타내는, 예외 복귀 명령으로 끝날 수 있고, 그렇지 않으면, 예외 핸들러로부터의 복귀은, 프로세서가 예외 복귀 요청으로서 검출하는 특별한 예약된 어드레스로 분기함으로써 수행될 수 있다. 따라서 복귀 명령은 이벤트로부터의 복귀 요청을 트리거할 수 있다. 이러한 예외 복귀가 스텝 120에서 검출되면, 스텝 122에서, 스택에 미리 저장된 레지스터 상태(15)와, 비트 상태 정보가 스택 포인터 레지스터(20)에 표시된 스택 위치로부터 복원되어 레지스터 파일(10)에 기록된다 스텝 124에서, 처리 회로(4)는, 어드레스가 예외 스택 프레임 내의 복귀 어드레스 위치에 의해 지정되는 명령으로 시작하는 명령들의 페칭(fetching)을 재개한다. 상술한 바와 같이, 이것은 예외가 발생한 시점에서 가장 오래된 미완료 명령의 어드레스이다. 스텝 126에서, 프로세서는 비트 상태 정보를 사용하여 이미 완료된 것으로서 비트 상태 정보에 의해 지시된 명령들의 비트들(beats)의 효과를 억제한다. 이미 완료된 비트(beat)가 반복되면 일부 명령들은 단순히 동일한 결과를 다시 생성할 수 있지만, 주어진 비트(beat)가 두 번 수행되면 다른 타입의 명령이 상이한 결과를 발생할 수 있다. 예를 들어, 주어진 메모리 위치에서 값을 극히 작게 증가시키기 위한 원자 메모리 업데이트 명령은 예외가 처리되기 전에 한 번 수행된 경우 잘못된 결과를 초래할 수 있으며 예외 다음에 처리를 다시 시작한 후에 다시 발생할 수 있다. 하나). 그러므로, 비트 상태 정보에 근거하여 명령의 이미 완료된 비트(beats)를 억제함으로써, 정확한 처리가 보장될 수 있다. 한편, 실제 하드웨어 구현이 연속 벡터 명령의 처리를 처리하는 특정 방식에 관계없이 비트 상태 정보에 유연성을 제공하여 여러 명령 그룹에 대해 완료된 비트(beats)를 사용하면 아키텍처를 서로 다른 성능 포인트로보다 효율적으로 스케일(scale)할 수 있다.

도 9 및 도 10은 비트 상태 정보를 사용하여 예외를 취하고 다시 시작하는 것을 처리하는 예를 도시하지만, 비트 상태 정보는 또한 실행의 스레드의 중단을 트리거하는 어떤 다른 이벤트에 대해 사용될 수 있다. 예를 들어 외부 디버거로부터 주입된 디버그 명령이 실행되는 디버그 모드로의 전환을 트리거하는 디버그 이벤트에서, 비트 상태 정보를 사용하면 디버그 모드 종료 후 다수의 명령의 정확한 비트(beats)로부터 처리를 다시 시작할 수 있다. 유사하게, 비트 상태 정보는 실행의 스레드의 중단을 트리거하는 다른 종류의 이벤트에 대해 유사한 방식으로 사용될 수 있다.

위에 주어진 예제에서 적어도 하나의 비트(beat)에 대한 가장 오래된 벡터 명령의 어드레스가 여전히 완료되어야 하므로 예외가 발생할 때 예외 스택 프레임에 저장된 복귀 어드레스가 설정되지만 이것은 필수적인 것은 아니다. 복귀 드레스는 처리가 재개될 포인트가 식별될 수 있게 하는 어드레스일 수 있다. 몇몇 경우에서는, 처리가 재개되는 포인트는 복귀 어드레스 및 비트 상태 정보로부터 도출될 수 있다. 예를 들어, 복귀 어드레스가 적어도 하나의 비트(beat)가 시작된 가장 최신의 벡터 명령을 나타내는 것이 가능할 수 있으며, 어떤 이전의 명령이 부분적으로만 완료했는지를 나타내는 비트 상태 정보와 함께 이들 명령이 예외 또는 다른 이벤트를 처리한 후에 그러한 명령들이 다시 패치될 수 있도록 하기에 충분할 수 있다. 그러나, 이 접근법은 부분적으로 완료된 명령들의 그룹 내에 분기가 있을 때 더 복잡할 수 있다. 가장 오래된 미완료 명령의 어드레스를 복귀 어드레스로서 사용하면 분기 전체에 걸쳐 이전에 실행된 명령들의 어드레스를 식별하려고 시도하기 위해 코드를 통해서 뒤로 물러설 필요가 없기 때문에 분기를 포함하는 명령들의 그룹의 처리가 단순화된다.

일반적으로, 상술한 비트 상태 정보는 복수의 벡터 명령에 대해 어느 비트(beats)가 완료되었는지를 나타낸다. 복수의 벡터 명령들은 적어도 하나의 비트(beat)가 여전히 완료되어야 하는 적어도 가장 오래된 벡터 명령 및 적어도 하나의 다음 벡터 명령을 포함할 수 있다. 다음 벡터 명령들은 예를 들어 개재 스칼라 명령(intervening scalar instruction)이 있을 수 있기 때문에, 가장 오래된 벡터 명령과 연속될 필요는 없다. 몇몇 경우에 있어서는, 벡터 명령이 실행될 수 있는 일부 실행 슬롯은, 실행될 명령이 충분하지 않기 때문에 비어 있을 수 있으므로, 이 경우 비트 상태 정보는 해당 비트(beats)가 완료되지 않았음을 나타낸다.

이 접근법은 다양한 하드웨어 구현 전체에 걸쳐서 스케일링(scaling)을 가능하게 한다. 몇몇 경우에, 처리 회로는 주어진 벡터 명령의 모든 비트(beats)를 병렬로 수행하기에 불충분한 하드웨어를 구비할 수도 있다. 따라서, 처리 회로는 제1 서브세트를 완료한 후에 주어진 벡터 명령의 제2 서브세트의 비트(beats)를 수행할 수 있다. 제1 및 제2 서브세트는 단일 비트(beat)를 포함할 수 있거나 프로세서 구현에 따라 다수의 비트(beats)를 포함할 수 있다.

하드웨어 유닛의 이용을 증가시키기 위해, 제2 벡터 명령에 대한 제1 서브세트의 비트들(beats)을 수행하는 것과 병행하여 제1 벡터 명령에 대한 제2 서브세트의 비트들(beats)을 수행하는 것이 가능하다. 이것은 제1 및 제2 벡터 명령이 상이한 하드웨어 유닛을 사용하여 실행될 때 특히 유용하다. 제어 회로는 하나의 벡터 명령의 얼마나 많은 비트(beats)가 이후의 벡터 명령의 제1 비트(beat)를 시작하기 전에 완료되어야 하는지를 명령마다 변경하도록 제공될 수 있다. 실행시 스케쥴링을 변경함으로써, 프로세서는 주어진 실행 명령의 경우에 이용 가능한 리소스에 응답하여 가장 적절한 스케쥴링을 선택할 수 있다.

대안적으로, 다른 구현은 주어진 벡터 명령의 모든 비트들(beats)을 병렬로 수행하는 것을 지원하는 하드웨어를 포함할 수 있다. 예외 처리 및 디버깅은 그러한 하드웨어에 대해 더 간단하지만, 예외가 취해지거나 디버그 모드로 들어간 시점에서 명령이 완전히 완료되며, 그럼에도 불구하고 그러한 하드웨어를 가진 처리 회로는 여전히 상술된 바와 같이 비트 상태 정보를 생성하여 사용할 수 있지만, 비트 상태 정보는 일반적으로 처리가 중단된 시점에서 가장 오래된 불완전한 명령에 대한 완료 비트(beats)가 없음을 나타낼 것이다(도 5에서 '비활성' 경우). 따라서, 비트 상태 정보를 정의함으로써, 아키텍처는 다양한 서로 다른 구현을 지원할 수 있다.

일부 시스템에 있어서, 비트 상태 정보는 처리를 재개하는 방법을 결정하기 위해 프로세서에 의해 사용되는 내부 상태일 수도 있지만, 사용자 또는 프로세서상에서 실행되는 소프트웨어에 액세스 가능하게 되지 않을 수도 있다.

그러나, 다른 예들에서는 비트 상태 정보는 완전히 가시적일 수 있고 처리 회로에 의해 실행되는 소프트웨어, 예외 핸들러 및 디버거 중 적어도 하나에 노출될 수 있다.

선택적으로, 처리 회로는 스택 포인터 레지스터에 의해 지시된 데이터 스토어 내의 위치에 비트 상태 정보를 저장하도록 구성될 수 있고, 필요하다면, 예외 이벤트에 응답할 때 비트 상태 정보를 클리어하여, 예외 핸들러로부터 비트 상태 정보를 숨긴다. 특히, 적어도 안전한 상태 및 덜 안전한 상태를 포함하는 다중 보안 상태를 지원하는 시스템에서, 예외 이벤트가 안전한 상태로부터 덜 안전한 상태로 천이하는 경우, 처리 회로는 예외 이벤트에 응답하여 비트 상태 정보를 클리어할 수 있다.

추가 옵션은 처리 회로가 제1 예외 이벤트에 응답하여 비트 상태 정보에 대한 액세스를 디스에이블하고, 예외 이벤트에 응답하여 액세스를 다시 인에이블하는 것이다. 예외 핸들러가 비트 상태 정보에 액세스하려고 시도하거나, 다수의 비트(beats)의 처리를 포함하는 추가 벡터 명령이 실행되면, 비트 상태 정보는 미리 결정된 위치에 느리게(lazily) 저장될 수 있다. 이 정보의 느린 저장(lazy saving)은 처리 회로에 의해 자동으로 수행되거나, 비트 상태 정보에 액세스하거나 벡터 명령을 실행하기 위한 제1 예외 핸들러의 시도에 의해 트리거된 중첩된(nested) 제2 예외 핸들러에 의해 자동으로 수행될 수 있다. 이 느린 저장 접근법은 예외가 발생했을 때 저장되는 정보의 양을 줄여서, 시간이 중요한 예외 핸들러에 진입하는 데 걸리는 시간을 줄일 수 있다.

위에서 설명된 바와 같이 벡터 명령들의 겹쳐진 실행을 지원하면 서로 다른 성능 포인트에서 다양한 하드웨어 구현 시에 아키텍처를 실행할 수 있다. 그러나, 이것은 스칼라 레지스터 파일(12) 및 벡터 레지스터 파일(14) 모두를 포함하는 혼합된 스칼라 벡터 명령들을 실행할 때 약간의 문제를 야기할 수 있다. 일반적으로 벡터 명령은 하나 이상의 소스 레지스터 및 목적지 레지스터를 지정하지만, 그 중 적어도 하나는 벡터 레지스터(14)이고, 이들 벡터 명령의 서브세트는 하나 이상의 소스 레지스터 및 목적지 레지스터 중 다른 하나가 스칼라 레지스터(12)인 혼합된 스칼라 벡터 명령이다. 도 2 및 도 3에 도시된 유형의 오버랩된 실행은 일반적으로 순수 벡터 명령에 대해 작동하는데, 왜냐하면 종속성(dependencies)은 크로스-레인(cross-lane) 종속성 없이 벡터 처리의 동일한 레인 내에 머무르는 경향이 있기 때문이다. 이것은, 종속성으로 인한 위험을 초래하지 않으면서 서로 다른 명령들의 상이한 비트들(beats)을 병렬로 실행할 수 있다는 것을 의미한다. 순열 명령(permutation instructions)과 같은, 크로스 레인 동작(cross lane operations)을 필요로 하는 벡터 명령의 일부 유형이 있을 수 있으며, 이러한 명령에 대해서는, 오버랩된 실행은 사용되지 않을 수도 있지만, 일반적으로 대부분의 벡터 명령들은 레인에 머무를 수 있고 오버랩 기술을 사용할 수 있다.

그러나, 혼합된 스칼라 벡터 명령의 경우, 스칼라 값과 벡터 처리의 각 레인 사이에 종속성이 있는 경우가 많다. 예를 들어, 스칼라 레지스터가 혼합된 스칼라 벡터 명령의 소스 레지스터인 경우, 벡터 처리의 각 레인은 스칼라 레지스터 내의 동일한 스칼라 값에 종속될 수도 있다. 이러한 유형의 혼합된 스칼라 벡터 명령의 예는 스칼라 레지스터를 사용하여 각각의 벡터 레인에서 로드/저장 동작에 사용될 목표 어드레스를 결정하기 위한 포인터를 저장하는 로드/저장 명령일 수 있다. 반면에, 스칼라 레지스터가 혼합된 스칼라 벡터 명령의 목적지 레지스터일 때, 처리 회로는 벡터 처리의 각 레인의 결과에 의존하는 스칼라 레지스터에 저장될 스칼라 결과를 생성할 수 있다. 이러한 유형의 명령의 예는 각 레인에서의 요소들의 쌍들의 곱셈을 수행하고 각각의 레인의 곱셈 결과를 스칼라 누산기 레지스터에 축적하는 곱셈 누적 명령일 수 있다. 어떤 경우에는 동일한 스칼라 레지스터가 혼합된 스칼라 벡터 명령에 의해 소스 레지스터와 목적지 레지스터로서 사용될 수 있다. 예를 들어, 로드/저장 명령은 스칼라 레지스터를 요구된 어드레스에 대한 포인터로서 사용할 수 있지만, 다음의 로드/저장 명령이 서로 다른 어드레스를 사용하도록 보장하기 위해 주어진 증분(increment)에 의거하여 포인터를 갱신할 수도 있다. 스칼라 레지스터가 소스와 목적지일 수 있는 또 다른 예는, 곱셈 누적 명령이 이전 값을 덮어쓰는 것보다 스칼라 레지스터 내의 이전 값에 더하는 경우이다. 포인터 갱신은 현재 로드 명령에 대한 어드레스가 계산되기 전 또는 후에 수행될 수 있다.

도 11 및 12는 두 개의 혼합된 스칼라 벡터 명령이 겹쳐서 실행될 때 발생할 수 있는 완화된 실행(relaxed execution)의 경우의 두 가지 예를 나타낸다. 도 11의 예에서, 벡터 로드(VLDR) 명령 다음에 VMLA(vector multiply accumulate) 명령이 온다. 이 예에서, 제1 혼합된 스칼라 벡터 명령(VLDR)은 스칼라 레지스터 RO인 소스 레지스터를 갖고, 제2 명령은 또한 스칼라 레지스터인 목적지 레지스터 RO 또는 R3을 갖는다. 정확한 처리 결과를 위해서, 제2 명령의 결과가 제1 명령의 소스 피연산자에 영향을 미치지 않아야 하고 - 더 최신의 명령은 더 오래된 명령의 입력에 영향을 주어서는 안 된다. 따라서, 특정 스칼라 레지스터가 제2 명령의 목적지 레지스터로서 사용되는 것이 제1 명령의 결과에 영향을 주지 않아야 한다고 생각할 수 있다.

그러나, 도 11에 도시된 바와 같이, 2개의 명령의 실행이 오버랩되면(이 예에서는 틱당 2비트(beats)로), VMLA 명령은 VLDR 명령의 최종 비트(beat) A4가 완료되기 전에 비트(beat) B1에서 스칼라 레지스터를 갱신하기 시작한다. VMLA 명령의 목적지 스칼라 레지스터(R3)가 도 11의 하단의 예에서와 같이 VLDR 명령의 소스 레지스터 RO과 다른 경우, VMLA 명령은 로드의 결과에 영향을 미치지 않고, 비트(beat) A4에서 수행된 로드 동작은 곱셈 누적 결과와는 관계없다. 이것은 정확한 결과이다. 그러나, VMLA 명령이 VLDR 명령과 동일한 스칼라 레지스터 RO를 지정하면, 도 11의 상단 예에서와 같이, 로드의 어드레스는 VMLA 명령의 비트(beat) B1에서 수행되는 곱셈 - 누적 동작에 의존할 것이므로, 제2 명령은 제1의 결과에 영향을 준다. 따라서, VLDR 명령의 비트(beat) A4는 다음의 VMLA 명령이 동일한 스칼라 레지스터를 지정하는지 아닌지 여부에 따라 완전히 다른 결과(상이한 어드레스로부터 로드)를 제공할 수 있다. 또한, VLDR 및 VMLA가 겹치는 양은, 처리 회로 및 런타임 시에 이용 가능한 리소스의 구현과 같은, 여러 요인에 의존할 수도 있기 때문에, VLDR의 결과가 다음의 VMLA로 인해 손상되었는지 여부는, 코드가 작성되거나 컴파일될 때 결정할 수 없다. 그러한 불확실성은 바람직하지 않고 부정확한 것으로 간주될 것이다.

한편, 도 12의 예에서, VMLA 명령은 VLDR 명령 전에 발생한다. 따라서 이번에는 제1 혼합된 스칼라 벡터 명령이 스칼라 레지스터인 목적지 레지스터를 갖고, 제2 혼합된 스칼라 벡터 명령은 스칼라 레지스터인 소스 레지스터를 갖는다. 이번에는 제2 명령이 제1 명령에 의존해야 한다고 기대하지만, 오버랩된 실행은 제2 명령의 결과가 제1 및 제2 혼합된 스칼라 벡터 명령 사이에서 얼마나 많은 개재 명령들이 실행되는지에 의존하게 할 수 있다. 예를 들어, 도 12의 상단 예에서는, 개재 명령들의 수는 0이므로, VLDR의 제1 비트(beat) B1는 (본 예는 틱당 1비트(beat)를 사용한다) VMLA의 제2 비트(beat) A2와 병렬로 수행된다. 따라서, VMLA의 제1 비트(beat) A1만이 VLDR의 비트(beat) B1 전에 완료되었으므로, VLDR의 타겟 어드레스는 VMLA 명령의 비트(beat) A에서 곱셈된 요소 Q3[1], Q4[1]의 곱(product)에 의존할 것이다. 한편, 하단 예에서는, 한 개의 개재 VORR 명령이 있으므로, VLDR은 지금 명령 C이다. 이번에는 VLDR의 제1 비트(beat) C1은 VMLA의 비트(beat) A3와 병렬로 수행되므로, 로드의 비트(beat) C1에서 산출된 타겟 어드레스는 VMLA의 제1의 2개의 비트(beat)(즉, Q3[1]*Q4[1] + Q3[2]*Q4[2])의 누적에 의존하므로, 그것은 도 12의 상단 예와 비교해 상이한 어드레스로부터 로드될 것이다.

로드의 정확한 처리 결과가 R0의 값을 곱셈 누적의 비트(beat) A1 내지 A4에서 수행된 모든 누적의 결과에 대응시키는 것이기 때문에 도 12의 예들 모두 부정확한 것으로 간주할 것이다. 그럼에도 불구하고, 주어진 명령의 결과를 갖는 것은 얼마 많은 개재 명령이 그것이 의존하는 명령으로부터 그것을 분리하는지에 의존하고 있어 바람직하지 않은 것으로 간주되어 부정확한 처리 결과를 초래한다.

이 문제를 해결하기 위한 다양한 접근법이 있다. 한 가지 접근법은 혼합된 스칼라 벡터 명령들의 실행을 절대로 오버랩하지 않는 것이다. 그러나, 일부 실제 애플리케이션(예를 들면, DSP)에 대해서, 혼합된 스칼라 벡터 명령들은 실행된 벡터 명령들의 총 수의 상당 부분을 나타낼 수 있기 때문에, 혼합된 스칼라 벡터 명령들의 오버랩된 실행을 방지하면 처음에는 벡터 명령들의 실행을 오버랩하는 많은 이점을 무효화할 수 있다. 이로 인해 곱셈 누적 유닛 또는 로드/저장 유닛과 같은 하드웨어 블록이 오랫동안 유휴 상태가 되어 프로세서의 효율성이 저하될 수 있다. 많은 경우에 연속적인 혼합된 스칼라 벡터 명령들은 동일한 스칼라 레지스터를 참조하지 않으며 이 경우 실행을 오버랩하는 것이 허용될 수 있다. 따라서 가능한 경우 이 중첩 실행을 사용하는 것이 바람직하다.

또 다른 접근법은 명령 세트 아키텍처에 제공된 혼합된 스칼라 벡터 명령들의 수를 감소시키는 것일 수도 있으므로, 대부분의 벡터 명령들은, 스칼라 결과를 생성하거나 스칼라 피연산자를 사용하더라도, 그들의 스칼라 값을 벡터 파일로부터/에 판독/기록하고, 제한된 수의 유형의 혼합된 스칼라 벡터 명령들이 스칼라 및 벡터 레지스터 파일 12, 14 사이에서 데이터를 전송하기 위해서만 제공된다. 그러나, 그러나, 벡터 레지스터 파일만을 사용하도록 벡터 명령들을 제한하는 것은 프로세서의 성능, 면적 및 전력에 영향을 미칠 수 있는 벡터 레지스터 파일(14)의 저장 용량 및 판독/기록 포트에 대한 압력을 증가시킨다. 따라서, 합리적인 수의 혼합된 스칼라 벡터 명령들을 계속해서 지원하는 것이 바람직할 수 있다.

또 다른 접근법은 각각의 혼합된 스칼라 벡터 명령들에 의해 스칼라 레지스터로서 특정된 레지스터들을 비교하고 한 쌍의 혼합된 스칼라 벡터 명령들 사이에 동일한 스칼라 레지스터에 대한 의존성이 존재할 때 오버랩된 실행을 방지하기 위해 하드웨어로 레지스터 의존성 체킹 회로를 제공하는 것이다. 그러나. 특히 상대적으로 저전력 구현에 대해서는, 이러한 의존성 체킹 회로를 제공하는 것은 비교기가 게이트 카운트(gate count)의 면에서 상대적으로 비용이 많이 들 수 있기 때문에 전체 전력 소비 및 장치의 회로 명적에 현저한 영향을 미칠 수 있다.

실제로, 벡터 명령을 사용하는 정상적인 프로그램 코드에서, 도 11 및 도 12에 도시된 것과 같은 스칼라 의존성을 가질 기회는 매우 낮다. 도 11 및 도 12는 로드에 대한 포인터로서 사용되는 레지스터에 곱셈의 합을 기록하거나, 곱셈 누적 명령에 의해 이전에 생성된 어드레스로부터 데이터를 로드하고 싶을 가능성이 매우 낮기 때문에 특히 현실적인 예가 아니다. 이 포인터 값의 혼합과 누적은 그냥 코드 관점에서 이치에 맞지 않으며, 명령들의 중복 실행으로 인해 발생할 수 있는 불확실성의 예로서 설명된다.

실제로, 발명자는 혼합된 스칼라 벡터 명령들의 특정 조합이 잠재적으로 부정확할 수 있는, 알려지지 않은 결과를 유도하는 것이 허용되는 경우에 보다 효율적인 마이크로아키텍처(microarchitecture)를 구축할 수 있음을 인식했다. 따라서, 제1 및 제2 혼합된 스칼라 벡터 명령들이 그들 사이의 미리 결정된 수의 개재 명령보다 적게 발생하면 도 11 및 12에 도시된 완화된 실행의 2가지 경우가 허용된다. 발명자는 실제로 코드가 이러한 명령들의 조합을 포함하는 경우는 드물다는 것을 알고 있으므로, 그러한 드문 경우를 방지하기 위해 값 비싼 의존성 체킹 회로를 제공하는 것은 전력 및 면적의 낭비이다. 실제로는, 몇몇 좀 더 효율적인 기술을 사용하여 의존성이 발생할 수 있는 몇 가지 상황에 대해서, 정확한 결과를 달성할 수 있도록 보장할 수 있다. 다른 의존적인 상황에서 결과가 "알려지지 않게" 하는 명령 세트 아키텍처를 제공함으로써, 전체 마이크로 아키텍처 하드웨어 구현을 보다 효율적으로 행할 수 있다. 그런 다음 알려지지 않은 결과가 발생할 수 있는 특수한 경우 코드를 기록하는 것을 피하는 것은 프로그래머의 몫이다 - 아래 설명된 대로 아키텍처는 프로그래머가 이러한 상황을 피할 수 있도록 안내하는 비교적 간단한 규칙을 정의할 수 있으므로, 처리 하드웨어 자체는 이들을 체크할 필요가 없다.

따라서, 제1 스칼라 레지스터를 지정하는 제1 혼합된 스칼라 벡터 명령과 제2 스칼라 레지스터를 지정하는 다음의 혼합된 스칼라 벡터 명령을 포함하는 일련의 명령들을, 제1 및 그 다음의 혼합된 스칼라 벡터 명령들 사이에 미리 결정된 수의 개재 명령들보다 적게, 실행하는 경우, 프로세서는 다음 방법 중 하나로 완화된 실행을 지원할 수 있다.

● 제1 스칼라 레지스터가 소스 레지스터이고 제2 스칼라 레지스터가 목적지 레지스터인 경우 처리 회로는 상기 제1 및 그 다음의 혼합 스칼라 벡터 명령들의 오버랩된 실행을 허용하여 (도 11의 예에서와 같이) 상기 제2 스칼라 레지스터가 상기 제1 스칼라 레지스터와 동일한 레지스터인지 여부에 따라 다른 상기 제1 혼합된 스칼라 벡터 명령의 결과를 생성하도록 구성된다.

● 상기 제1 스칼라 레지스터가 목적지 레지스터이고 상기 제2 스칼라 레지스터가 소스 레지스터이며 상기 제1 스칼라 레지스터 및 상기 제2 스칼라 레지스터가 동일한 레지스터(상기 제1 및 그 다음의 혼합 스칼라 벡터 명령들 사이의 미리 결정된 개수의 개재 명령 또는 더 적은 개재 명령)인 경우, 처리 회로는 상기 제1 및 그 다음의 혼합 스칼라 벡터 명령들의 상기 오버랩된 실행을 허용하여 (도 12의 예에서와 같이) 제1 및 그 다음의 혼합 스칼라 벡터 명령들 사이의 개재 명령들의 수에 따라 다른 상기 제2 혼합 스칼라 벡터 명령의 결과를 생성하도록 구성된다.

이 접근법은 주어진 명령들의 세트를 실행한 결과에서 부정확한 처리 결과와 불확실성을 초래할 것으로 예상하기 때문에 매우 직관적이지 못한데, 왜냐하면 결과는 특정 마이크로 아키텍처 구현이 명령들의 실행을 오버랩하도록 선택하는 특정 방식에 의존할 수도 있기 때문이다. 그러나, 이러한 불확실성을 허용함으로써, 마이크로 아키텍처를 더 자유롭게 변경할 수 있고 의존성 검사 비용을 피할 수 있다. 어쨌든, 이러한 유형의 혼합 스칼라 벡터 명령의 실용적인 현실 세계의 애플리케이션은 프로그래머가 완화된 실행이 발생하는 경우를 이용하기 원할 가능성이 매우 낮다.

제1 스칼라 레지스터가 소스 레지스터이고 제2 스칼라 레지스터가 목적지 레지스터인 위에 나열된 완화된 실행의 두 가지 예 중 첫 번째에서는, 제1 스칼라 레지스터는 목적지 레지스터일 수도 있다는 점에 주의한다. 마찬가지로, 제2 스칼라 레지스터는 목적지 레지스터뿐만 아니라 소스 레지스터일 수도 있다. 대안적으로, 다른 예에서는, 제1 스칼라 레지스터는 순수하게 소스 레지스터일 수 있지만, 목적지 레지스터는 아니며, 또는 제2 스칼라 레지스터는 순수하게 목적지 레지스터이지만 소스 레지스터는 아니다. 유사하게, 제1 스칼라 레지스터가 목적지 레지스터이고 제2 스칼라 레지스터가 소스 레지스터인 완화된 실행의 제2 예에서는, 제1 스칼라 레지스터는 또한 소스 레지스터일 수 있고, 제2 스칼라 레지스터는 또한 목적지 레지스터일 수 있다. 따라서, 특정 스칼라 레지스터가 소스 레지스터 또는 목적지 레지스터라는 것을 지정하면, 스칼라 레지스터가 다른 타입의 레지스터가 될 수도 있다는 것을 배제하지 않는다.

이 접근법은 제1 및 그 다음의 혼합 스칼라 벡터 명령들 중 적어도 하나가 산술 명령인 경우에 특히 유용한다.

실제로, 혼합 스칼라 벡터 명령들 간의 실제 코드에서 가장 일반적인 실제 의존성은 관련 그룹으로부터의 다수의 명령이 레지스터 의존성을 가질 때 발생한다. 예를 들어, 여러 메모리 명령들이 동일한 포인터 값을 사용할 수 있거나, 또는 여러 곱셈 누적 명령들이 도 14의 예에 도시된 바와 같이 동일한 누산기 레지스터에 누적될 수 있다. 도 13에 도시된 바와 같이, 처리 회로(4)는 상이한 클래스의 명령들에 대응하는 다수의 별개의 하드웨어 유닛들 200, 202, 204, 206을 포함할 수 있다. 예를 들어, 하드웨어 유닛은 메모리 명령들을 실행하기 위한 로드 저장 유닛(200), 곱셈을 포함하는 어떤 명령을 실행하기 위한 곱셈 누적 유닛(202), 곱셈 이외의 다른 산술 또는 논리 명령들을 실행하기 위한 ALU, 및 부동 소수점 명령들을 실행하기 위한 부동 소수점 유닛(206)을 포함할 수도 있다. 따라서, 명령들은 어떤 하드웨어 유닛이 그들을 실행하도록 설계되었는지에 따라 분류될 수 있다.

이 경우, 실행될 동일한 클래스에 여러 개의 명령이 있을 때, 두 번째 명령은 동일한 실행 리소스에 대해 경쟁하고 있기 때문에 첫 번째 명령이 완료될 때까지 시작할 수 없다. 따라서, 이 경우 자연 파이프라인 구조적 위험은, 여분의 의존성 검사 회로가 각 명령의 레지스터 지정자를 비교할 필요없이 레지스터 의존성을 해결할 수 있다. 따라서, 아키텍처는 상이한 클래스의 명령들을 정의할 수 있고, 제1 및 제2 혼합 스칼라 벡터 명령이 모두 동일한 클래스로부터 온 것이면 도 11 또는 도 12에 도시된 유형의 완화된 실행이 방지되어야 한다는 것을 요구한다. 명령의 클래스를 검사하기 위한 하드웨어는 상이한 명령들의 레지스터 지정자를 비교하기 위해 하드웨어보다 적은 추가 오버헤드를 종종 요구할 수 있으므로(하드웨어 유닛 200, 202, 204, 206 중 어느 것이 명령을 처리하는지를 제어하기 위해 명령 디코더(6)에서 연산코드(opcodes)의 디코딩이 이미 요구될 수도 있기 때문에), 이 접근법은 면적 및 전력 효율이 더 높을 수 있다.

특정한 클래스의 정의는 실시 예마다 다를 수 있다. 도 13은 메모리 액세스 명령, 곱셈 명령, 비곱셈 연산 명령 및 부동 소수점 명령에 대응하는 4개의 클래스에 맵핑될 수 있는 4개의 실행 유닛을 갖는 예를 도시하지만, 클래스는 다른 명령들을 포함하도록 확장될 수 있고, 또는 이들 클래스 중 하나 이상은 생략되거나 다른 클래스와 결합될 수 있다. 또한, 일부 벡터 명령들은 특정 클래스에 할당되지 않아, 그들의 실행은 그들의 유형에 관계없이 다른 벡터 명령들과 오버랩될 수 있다.

예를 들어, 실제 코드에서 발생할 가능성이 있는 벡터 명령들 사이의 스칼라 의존성의 가장 일반적인 경우에는, 두 개의 곱셈 명령 또는 두 개의 로드 명령이 동일한 스칼라 레지스터를 사용할 수 있으므로, 적어도 로드 명령을 포함하는 첫 번째 클래스 및 적어도 곱셈 명령(곱셈 누적 포함)을 포함하는 제2 클래스를 정의하는 것만으로 충분할 수 있다. 어떤 다른 벡터 명령은 그들의 유형에 관계없이 오버랩될 수 있는 것으로 취급될 수 있다. 몇몇 곱셈 명령이나 몇몇 로드가 오버랩하는 것을 방지하는 것은 가장 일반적인 실제 의존성을 해결하는 데 충분할 수 있다.

보다 일반적으로, 처리 회로는 상이한 클래스의 혼합 스칼라 벡터 명령을 지원할 수 있고, 처리 회로는 그들 둘 모두가 동일한 클래스로부터 오는 경우에 제1 및 그 다음의 혼합 스칼라 벡터 명령의 완화된 실행을 방지할 수 있다. 완화된 실행을 방지하는 한 가지 방법은 명령들이 오버랩되는 것을 방지하는 것이지만, 다른 접근법은 그들이 더 이상 서로 의존하지 않도록 어느 레지스터가 하나 또는 다른 명령들에 의해 지정되는지를 재매핑하는 것일 수 있다. 예를 들어, 제1 혼합 스칼라 벡터 명령이 소스 레지스터로서 스칼라 레지스터를 사용하고(스칼라 레지스터는 제1 혼합 스칼라 벡터 명령에 의해 목적지 레지스터로서 사용되지 않음), 제2 명령이 스칼라 목적지 레지스터를 사용하는 도 18에 도시된 경우에는, 명령들이 이제 다른 레지스터를 가리키도록 제1 명령에 의해 참조된 제1 스칼라 레지스터로부터, 제2 명령에 의해 참조되지 않는 다른 제3 스칼라 레지스터로 스칼라 값을 복사함으로써 완화된 실행을 방지할 수 있다. 반면에, 이 레지스터 재매핑은 또한 회로 면적의 측면에서 약간의 오버헤드를 필요로 할 수 있으며, 따라서 많은 경우에 이들 명령에 대한 오버랩된 실행을 피함으로써 완화된 실행을 단순히 방지하는 것이 더 효율적일 수 있다.

클래스들은 일반적으로 동일한 하드웨어 회로 유닛을 사용하는 명령들의 클래스들에 대응할 수 있지만, 2개 이상의 상이한 하드웨어 유닛들에 대응하는 몇몇 클래스들이 있을 수도 있다. 예를 들어, 명령들의 그룹이 스스로 클래스를 보증하기에 충분하지 않은 경우 "기타(other)"로 분류 될 수 있고 그리고 이들은 다른 수의 상이한 하드웨어 회로 유닛을 사용하여 실행될 수 있다. 주어진 구현이 상이한 하드웨어 유닛에서 다른 종류의 명령들을 실행하도록 선택하는 특별한 방법은 마이크로 아키텍처 레벨에서의 구현 선택이므로, 아키텍처는 실제로 사용되는 특정 하드웨어 유닛을 참조하지 않고 가능성 있는 구현 측면에서 클래스를 간단하게 정의할 수도 있다.

도 15 및 도 16은 2개의 혼합 스칼라 벡터 명령들 사이의 의존성이 충족되도록 보증하기 위해 프로그램 코드 레벨에서 사용될 수 있는 다른 기술을 나타낸다. 도 15에 도시된 바와 같이, 2개의 혼합 스칼라 벡터 명령들이 충분한 수의 개재 명령들에 의해 분리되면, 이들 혼합 스칼라 벡터 명령들 사이에 오버랩이 존재하지 않을 것이므로 의존성이 이미 충족될 것이다. 분리가 보장되는 소정 수의 개재 명령들은 특정 마이크로 아키텍처 구현에 의존할 것이다. 예를 들어, 틱(tick)당 하나의 비트(beat)를 처리하고 연속적인 벡터 명령들의 실행을 1비트(beat)씩 스태거(stagger)하는 구현 예에서는, 소정 수의 개재 명령들은 N-1(여기서 N은 벡터 명령당 비트(beat) 수이다)이고, 예를 들어 상기의 예의 경우에 4비트(beat) 벡터에 대해 3개의 개재 명령이다. 보다 일반적으로는, 벡터 명령이 2^J(여기서, J는 1보다 크거나 같은 정수) 비트(beats)의 처리를 이용하여 처리되는 명령들의 하나의 이슈를 가진 시스템의 경우와, 오버랩된 실행에서는, 처리 회로는 제1 벡터 명령의 (2K + 1)번째 비트(beat)와 병렬로 제2 벡터 명령의 제2 비트(beat)를 수행하고, 여기서 K는 정수이고 0≤K＜J이며, 상기 소정수의 개재 명령들은 (2^(J-K)-1)일 수 있다. 이중 이슈를 지원하는 시스템의 경우, 소정 수의 개재 명령들이 더 클 수 있다.

따라서, 일반적으로 소정 수의 명령들은 제1 혼합 스칼라 벡터 명령의 어떤 비트(beat)와 제2 혼합 스칼라 벡터 명령의 비트(beat)를 오버랩하는 것이 가능하지 않도록 보장하는 2개의 연속적인 혼합 스칼라 벡터 명령들 사이의 최소 개수의 개재 명령들이다. 프로그래머 또는 컴파일러에게 2개의 명령이 그들의 의존성을 존중할 것이라는 어떤 확실성을 제공하기 위해, 명령 세트 아키텍처는 소정 수의 개재 명령에 대해 특정의 최소값을 지정할 수도 있고, 그 아키텍처에 부합하는 마이크로 아키텍처는, 명령들이 적어도 그 명령의 수만큼 분리될 때 그 결과가 정확하고 반복 가능하다는 것을 보장하기 위한 회로를 제공해야 한다. 그럼에도 불구하고, 이것은, 프로그래머가 서로 다른 클래스의 두 개의 혼합 스칼라 벡터 명령을 소정 수의 명령보다 적게 분리하면 마이크로 아키텍처가 불확실한 결과를 허용하는 자유를 준다.

따라서, 프로그래머나 컴파일러는, 아키텍처에 의해 지정된 대로 그들 사이에 적어도 최소한의 개재 명령의 수를 포함시킴으로써 두 개의 의존적인 혼합 스칼라 벡터 명령이 그들의 의존성을 충족시킬 것이라는 것을 보장할 수 있다. 많은 경우 의존적인 혼합 스칼라 벡터 명령들은 이미 충분한 명령들에 의해 분리될 것이기 때문에 레지스터 의존성 검사 회로를 제공하여 그들이 서로 가까워지는 가끔의 경우를 방지하는 것이 정당화되지 않는 경우가 종종 있다.

다른 한편으로, 그들이 도 13 및 도 14와 관련하여 논의된 것과 동일한 클래스에 있지 않은 경우에, 그들 사이에 소정 수의 개재 명령보다 적은 수의 의존적인 혼합 스칼라 벡터 명령들을 제공하는 것이 바람직하다면, 아키텍처는 또한 하드웨어가 배리어(barrier)의 양측의 2개의 혼합 스칼라 벡터 명령들 간의 의존성을 존중하도록 강요하기 위해서 프로그램 코드에 포함될 수 있는 오버랩 배리어 명령 CSB을 제공할 수도 있다. 따라서, 오버랩 배리어 명령이 개재될 때, 처리 회로는 오버랩을 방지하거나 레지스터 지정자를 재매핑함으로써, 배리어의 양측에서 혼합 스칼라 벡터 명령의 완화된 실행을 방지할 수도 있다.

상이한 구현은, 배리어 명령을 다른 방법으로 처리할 수도 있다. 도 2의 상단 예와 같이 틱 마이크로아키텍처당 단일 비트(beat)의 경우, 첫 번째 완료 후에 두 번째 명령이 시작되도록 허용하기 위해서 배리어 명령을 검출하고 파이프 라인에 충분한 버블(bubbles)을 삽입하기 위한 몇몇 회로가 제공될 수도 있다. 도 2의 두 번째 예에 나타낸 것과 같이 듀얼 비트(dual beat) 마이크로아키텍처의 경우, 명령 절반이 양쪽 틱 모두 처리되기 때문에 하나의 버블로 충분할 수 있으므로, 배리어 명령은 no-op 연산을 실행함으로써 구현될 수 있다. 하나의 틱에서 전체 벡터 연산을 실행하기에 충분한 실행 리소스를 가진 쿼드 비트(quad beat) 마이크로아키텍처의 경우, 의존성은 스톨 또는 패딩(stalling or padding) 없이 이미 충족될 것이므로, 고성능 마이크로아키텍처는 실제로 배리어 명령에 대해 아무것도 할 필요가 없으며, 성능 향상을 위해 파이프라인의 초기 단계(예를 들면, 페치 또는 디코드 단계)에서 배리어 명령을 간단히 제거할 수 있다. 따라서, 아키텍처용으로 기록된 코드는 벡터 명령들과 오버랩하는 구현에서 실행될 경우에 배리어 명령을 포함할 수 있지만, 다른 마이크로아키텍처는 실제로 no-op를 주입할 필요가 없으며 배리어를 무시할 수 있다.

따라서, 프로그래머가 공통 스칼라 레지스터에 의존하고 소정 수의 개재 명령보다 적은 수로 분리되는 서로 다른 클래스의 혼합 스칼라 벡터 명령을 제공하기를 정말로 원할 때 매우 드물게 배리어를 사용할 수 있다. 본질적으로, 아키텍처는 프로그래머나 컴파일러가 주어진 수의 명령들보다 적은 수로 명령들을 분리하기를 원하는 경우, 그들은 배리어를 사용해야 하며 그렇지 않으면 그들은 불확실한 결과를 각오해야 한다고 규정할 수도 있다.

도 17은 혼합 스칼라 벡터 명령들을 처리하는 방법을 예시하는 흐름도를 도시한 것이다. 스텝 250에서, 명령 디코더는 처리될 명령이 혼합 스칼라 벡터 명령인지 여부를 검출한다. 그렇지 않은 경우, 명령은 해당 유형의 명령에 적합한 처리에 따라 처리된다. 명령이 혼합 스칼라 벡터 명령이면, 스텝 252에서, 비트 제어 회로(beat control circuitry)(30)는 아직 완료되지 않은 이전의 혼합 스칼라 벡터 명령이 존재하는지를 검출하고, 현재의 혼합 스칼라 벡터 명령과 동일한 클래스로부터 온 것이다. 이전의 혼합 스칼라 벡터 명령은, 명령의 검출과 같이 아직 실행을 시작하지 않았을 수도 있고, 비트(beat)의 스케줄링은 파이프라인의 초기 단계에서 발생할 수도 있다. 또는, 이전의 혼합 스칼라 벡터 명령을 부분적으로 실행할 수 있다.

동일한 클래스로부터의 완료되지 않은 혼합 스칼라 벡터 명령이 있는 경우, 스텝 254에서 비트 제어 회로(30)는 도 11 및 도 12의 예에 도시된 형태의 완화된 실행을 방지하기 위한 동작을 취한다. 이 동작은, 이전의 혼합 스칼라 벡터 명령이 완료될 때까지 실행을 위한 현재의 혼합 스칼라 벡터 명령의 스케줄링을 지연시켜, 명령이 오버랩되는 것을 방지할 수 있다. 대안으로, 현재의 혼합 스칼라 벡터 명령이 목적지 레지스터로서 제2 스칼라 레지스터를 지정하는 경우에, 이전의 혼합 스칼라 벡터 명령은 소스 레지스터로서 제1 스칼라 레지스터를 지정하고, 이전의 혼합 스칼라 벡터 명령은 아직 실행을 시작하지 않았으며, 그 동작은 상기 제1 스칼라 레지스터로부터의 값을 제2 스칼라 레지스터와 다른 제3 스칼라 레지스터에 기록하는 것과, 제1 스칼라 레지스터 대신 제3 스칼라 레지스터를 사용하여 이전의 혼합 스칼라 벡터 명령을 실행하는 것을 포함할 수도 있다. 현재의 혼합 스칼라 벡터 명령이 이전의 혼합 스칼라 벡터 명령과 동일한 클래스로부터 나온 것이라면, 이전 및 현재의 혼합 스칼라 벡터 명령에 의해 지정된 스칼라 레지스터들이, 단지 그들이 동일한 경우에, 레지스터 참조를 비교하기 위해 하드웨어에 제공된 의존성 검사 회로가 없기 때문에, 실제로 동일한 레지스터인지에 관계없이 스텝 254에서의 응답 동작이 취해진다는 점에 주의한다.

스텝 256에서 비트 제어 회로는 또한 오버랩 배리어 명령이 이전의 혼합 스칼라 벡터 명령과 현재의 혼합 스칼라 벡터 명령 사이에서 마주치게 되었는지 여부를 검사한다. 그렇게 하면, 다시 스텝 254에서 레지스터 참조를 재매핑하거나 오버랩된 실행을 방지함으로써, 완화된 실행을 피하기 위해 응답 동작이 취해진다. 도 17은 오버랩 배리어 명령을 검사하는 스텝 전에 수행된 클래스 검사 스텝 252와 함께 스텝 252 및 256이 순차적으로 수행되는 것을 나타내지만, 그들은 또한 반대 순서 또는 서로 병렬로 수행될 수 있다.

이전 및 현재의 혼합 스칼라 벡터 명령이 동일한 클래스에서 나온 것이 아니고(또는 오버랩된 실행에 제한이 부과되지 않은 '다른' 유형의 명령에서 나온 것이며) 그들 사이에 오버랩 배리어 명령이 없는 경우에는, 스텝 258에서 완화된 실행이 도 11 및 도 12에 도시된 유형들의 알려지지 않은 결과를 야기하는 경우에도 오버랩된 실행은 허용된다.

요약하면, 벡터 명령들로부터의 스칼라 레지스터 업데이트에 대한 의존성 검사를 완화시키고, 대신에 상술한 바와 같이 좀 더 경량의 아키텍처 메커니즘에 의존함으로써, 보다 효율적인 구현을 가능하게 하는 레지스터 지정자들을 비교하기 위한 하드웨어를 별도로 점검할 필요없이 실제 생활의 의존성을 충족시킬 수 있다.

도 19는 사용될 수 있는 가상 머신 구현을 나타낸다. 앞서 기술된 실시 예들은 관련된 기술들을 지원하는 특정 처리 하드웨어를 동작시키기 위한 장치 및 방법들에 관하여 본 발명을 구현하지만, 하드웨어 장치들의 소위 가상 머신 구현을 제공하는 것도 가능하다. 이들 가상 머신 구현은 가상 머신 프로그램(130)을 지원하는 호스트 오퍼레이팅 시스템(140)을 실행하는 호스트 프로세서(150)상에서 실행된다. 일반적으로, 큰 강력한 프로세서는 적절한 속도로 실행되는 가상 머신 구현을 제공해야 하지만, 호환성이나 재사용을 위해 다른 프로세서에 고유한 코드를 실행하기를 원하는 경우와 같은 특정 상황에서는 이러한 접근 방식을 정당화할 수 있다. 가상 머신 프로그램(130)은 가상 머신 프로그램(130)에 의해 모델링되는 디바이스인 실제 하드웨어에 의해 제공될 하드웨어 인터페이스와 동일한 게스트 프로그램(120)에 가상 하드웨어 인터페이스를 제공한다. 따라서, 상술한 메모리 액세스의 제어를 포함하는 프로그램 명령들은, 가상 기계 하드웨어와의 상호 작용을 모델링하기 위해 가상 머신 프로그램(130)을 사용하여 게스트 프로그램 (120) 내에서 실행될 수 있다. 게스트 프로그램(120)은 베어 메탈(bare metal) 프로그램일 수도 있거나, 또는 호스트 OS(140)가 가상 머신 애플리케이션(130)을 실행하는 방법과 유사한 방식으로 애플리케이션을 실행하는 게스트 오퍼레이팅 시스템일 수도 있다. 또한 서로 다른 유형의 가상 머신이 있고, 일부 유형에서는, 가상 머신(35)은 호스트 OS(140)를 필요로 하지 않고 호스트 하드웨어(150) 상에서 직접 실행된다는 것을 알게 될 것이다.

예시적인 구성은 이하의 조항에서 설명된다 :

(1) 소스 피연산자 및 결과 값 중 적어도 하나가 복수의 데이터 요소를 포함하는 벡터 값인 벡터 명령들을 처리하는 처리 회로를 구비하는 장치로서,

주어진 벡터 명령에 응답하여, 상기 처리 회로는 복수의 비트(beats)의 처리를 수행하도록 구성되며, 각 비트(beat)는 벡터 값의 일부분에 대응하는 처리를 포함하고;

상기 처리 회로는 상기 주어진 벡터 명령을 포함하는 복수의 벡터 명령 중 어떤 비트(beats)가 완료했는지를 나타내는 비트 상태 정보(beat status information)를 설정하도록 구성되며;

이벤트에 응답하여, 상기 처리 회로는 상기 주어진 벡터 명령의 처리를 중단하도록 구성되며;

상기 주어진 벡터 명령의 처리로의 복귀를 나타내는 이벤트 복귀 요청에 응답하여, 상기 처리 회로는 완료한 것으로서 상기 비트 상태 정보로 나타낸 상기 복수의 벡터 명령의 비트(beats)를 억제하면서 상기 복수의 벡터 명령의 처리를 재개하도록 구성되는, 장치.

(2) 상기 처리 회로는 상기 복수의 벡터 명령들 중 하나의 어드레스를 나타내는 복귀 어드레스를 설정하도록 구성되며;

상기 이벤트로부터의 복귀 요청에 응답하여, 상기 처리 회로는 상기 복귀 어드레스 및 상기 비트 상태 정보에 의거하여 처리가 재개될 포인트를 식별하도록 구성되는. 조항(1)에 따른 장치.

(3) 상기 복귀 어드레스는 적어도 하나의 비트(beat)가 여전히 완료되어야 하는 가장 오래된 벡터 명령의 어드레스를 나타내는, 조항(2)에 따른 장치.

(4) 상기 복수의 벡터 명령은 적어도 하나의 비트(beat)가 여전히 완료되어야 하는 가장 오래된 벡터 명령 및 적어도 하나의 그 다음의 벡터 명령을 포함하는, 선행의 어느 한 조항에 따른 장치.

(5) 상기 처리 회로는 주어진 벡터 명령의 복수의 비트(beats) 모두를 병렬로 수행하기에 불충분한 하드웨어를 구비하는, 선행의 어느 한 조항에 따른 장치.

(6) 상기 처리 회로는 주어진 벡터 명령의 제1 서브세트의 복수의 비트(beats)를 완료한 후에 주어진 벡터 명령의 제2 서브세트의 복수의 비트(beats)를 수행하도록 구성되는, 선행의 어느 한 조항에 따른 장치,

(7) 상기 처리 회로는 제2 벡터 명령에 대한 제1 서브세트의 비트들(beats)을 수행하는 것과 병행하여 제1 벡터 명령에 대한 제2 서브세트의 비트들(beats)을 수행하도록 구성되는, 조항(6)에 따른 장치.

(8) 하나의 벡터 명령의 얼마나 많은 비트(beats)가 그 다음의 벡터 명령의 제1 비트(beat)를 개시하기 전에 완료되어야 하는지를 명령마다 변경하는 제어 회로를 구비하는, 선행의 어느 한 조항에 따른 장치.

(9) 상기 처리 회로는 상기 주어진 벡터 명령의 복수의 비트(beats) 모두를 병렬로 수행하는 것을 지원하도록 구성된 하드웨어를 구비하는, 조항(1) 내지 (4), (6) 및 (7) 중 어느 한 조항에 따른 장치.

(10) 상기 벡터 값은 상기 처리 회로에 액세스 가능한 데이터 요소 크기 정보에 의해 지정된 복수의 데이터 요소 크기 중 하나를 갖는 데이터 요소들을 포함하며;

각 비트(beat)의 처리는 상기 데이터 요소 크기 정보로 나타낸 데이터 요소 크기에 상관없이, 벡터 값의 고정된 크기 부분에 대응하는 처리를 포함하는, 선행의 어느 한 조항에 따른 장치.

(11) 상기 처리 회로는 상기 비트 상태 정보가 상기 처리 회로에 의해 실행되는 소프트웨어, 예외 핸들러 및 디버거 중 적어도 하나에 액세스 가능하게 하도록 구성되는, 선행의 어느 한 조항에 따른 장치.

(12) 상기 이벤트는 디버그 이벤트를 포함하고, 상기 이벤트로부터의 복귀 요청은 디버그 상태로부터의 복귀를 포함하는, 선행의 어느 한 조항에 따른 장치.

(13) 상기 이벤트는 예외 이벤트를 포함하고, 상기 이벤트로부터의 복귀 요청은 예외 복귀를 포함하는, 선행의 어느 한 조항에 따른 장치.

(14) 상기 예외 이벤트는 결함 이벤트를 포함하고, 상기 결함 이벤트에 응답하여 상기 처리 회로는 상기 복수의 벡터 명령 중 어느 것이, 상기 결함 이벤트가 검출되었던 상기 주어진 벡터 명령인지를 식별하는 정보를 설정하도록 구성되는, 조항(13)에 따른 장치.

(15) 예외 이벤트에 응답하여, 상기 처리회로는 상기 비트 상태 정보에 대한 액세스를 디스에이블하도록 구성되고,

복수의 비트(beats)의 처리를 포함하는 적어도 하나의 유형의 추가 벡터 명령의 실행 또는 상기 비트 상태 정보에 액세스하려고 하는 명령에 응답하여, 상기 처리 회로는,

상기 비트 상태 정보를 미리 결정된 위치에 저장하고; 또는

제2 예외 이벤트를 발생시키도록 구성되는, 조항 (13) 및 (14) 중 어느 하나에 따른 장치.

(16) 상기 예외 이벤트에 응답하여, 상기 처리 회로는 상기 비트 상태 정보를 스택 포인터 레지스터로 나타낸 값에 관한 오프셋으로 데이터 저장부 내의 위치에 저장하도록 구성되는, 조항 (13) 및 (14) 중 어느 하나에 따른 장치.

(17) 상기 처리 회로는 적어도 안전한 상태 및 덜 안전한 상태를 포함하는 복수의 보안 상태에서 동작 가능하고, 상기 안전한 상태로부터 상기 덜 안전한 상태로의 천이를 일으키는 상기 예외 상태에 응답하여, 상기 처리 회로는 비트 상태 정보를 클리어하도록 구성되는, 조항(16)에 따른 장치.

(18) 상기 처리 회로는

주어진 비트(beat)의 처리에 대응하는 목적지 벡터 레지스터의 일부분의 업데이트를 억제하는 것과;

상기 주어진 비트(beat)의 처리와 관련된 처리 동작을 억제하는 것 중 하나에 의해 상기 주어진 비트(beat)의 처리를 억제하도록 구성되는, 선행의 어느 한 조항에 따른 장치.

(19) 소스 피연산자 및 결과 값 중 적어도 하나가 복수의 데이터 요소를 포함하는 벡터 값인 벡터 명령들을 처리하는 수단을 구비하는 장치로서,

주어진 벡터 명령에 응답하여, 상기 처리 수단은 복수의 비트(beats)의 처리를 수행하도록 구성되며, 각 비트(beat)는 벡터 값의 일부분에 대응하는 처리를 포함하고,

상기 처리 수단은 상기 주어진 벡터 명령을 포함하는 복수의 벡터 명령 중 어느 비트(beat)가 이미 완료했는지를 나타내는 비트 상태 정보를 설정하도록 구성되며;

이벤트에 응답하여, 상기 처리 수단은 상기 주어진 벡터 명령의 처리를 중단하도록 구성되며;

상기 주어진 벡터 명령의 처리로의 복귀를 나타내는 이벤트로부터의 복귀 요청에 응답하여, 상기 처리 수단은 완료한 것으로서 상기 비트 상태 정보로 나타낸 상기 복수의 벡터 명령들의 비트들(beats)을 억제하면서 상기 복수의 벡터 명령들의 처리를 재개하도록 구성되는, 장치.

(20) 소스 피연산자 및 결과 값 중 적어도 하나가 복수의 데이터 요소를 포함하는 벡터 값인 벡터 명령들을 처리하는 방법으로서,

주어진 벡터 명령에 응답하여, 각 비트(beat)가 상기 벡터 값의 일부분에 대응하는 처리를 포함하는, 복수의 비트(beats)의 처리를 수행하는 것과,

상기 주어진 벡터 명령을 포함하는 복수의 벡터 명령 중 어느 비트(beats)가 이미 완료되었는지를 나타내는 비트 상태 정보를 설정하는 것과,

이벤트에 응답하여, 상기 주어진 벡터 명령의 처리를 중단하는 것과,

상기 주어진 벡터 명령의 처리로의 복귀를 나타내는 이벤트로부터의 복귀 요청에 응답하여, 완료한 것으로서 상기 비트 상태 정보로 나타낸 상기 복수의 벡터 명령들의 비트들(beats)을 억제하면서 상기 복수의 벡터 명령들의 처리를 재개하는 것을 포함하는, 방법.

(21) 조항 (1) 내지(18) 중 어느 하나에 따른 장치에 대응하는 명령 실행 환경을 제공하도록 호스트 데이터 처리 장치를 제어하는 프로그램 명령들을 포함하는 가상 머신 컴퓨터 프로그램.

(22) 하나 이상의 소스 레지스터 및 목적지 레지스터를 지정하는 벡터 명령들을 처리하는 처리 회로를 포함하는 장치로서, 상기 목적지 레지스터 및 상기 하나 이상의 소스 레지스터 중 적어도 하나는 복수의 데이터 요소들을 구비하는 벡터 값을 저장하기 위한 벡터 레지스터이고,

상기 벡터 명령들은 상기 목적지 레지스터 및 상기 하나 이상의 소스 레지스터 중 다른 하나가 단일 데이터 요소를 포함하는 스칼라 값을 저장하기 위한 스칼라 레지스터인 적어도 하나의 유형의 혼합 스칼라 벡터 명령을 포함하고,

주어진 벡터 명령에 응답하여, 상기 처리 회로는 복수의 비트(beats)의 처리를 수행하도록 구성되며, 각 비트(beat)는 상기 벡터 값의 일부분에 대응하는 처리를 포함하고,

상기 처리 회로는, 상기 제1 벡터 명령의 적어도 하나의 비트(beat)가 상기 제2 벡터 명령의 적어도 하나의 비트(beat)와 병렬로 수행되는 제1 벡터 명령 및 제2 벡터 명령의 오버랩된 실행을 지원하도록 구성되며,

제1 스칼라 레지스터를 지정하는 제1 혼합 스칼라 벡터 명령 및 제2 스칼라 레지스터를 지정하는 그 다음의 혼합 스칼라 벡터 명령을 포함하는 명령들의 시퀀스에 응답하여, 제1 및 그 다음의 혼합 스칼라 벡터 명령들 사이의 소정 수의 개재 명령들보다 적게, 상기 처리 회로는 다음 중 적어도 하나를 포함하는 완화된 실행을 지원하도록 구성되며,

상기 제1 스칼라 레지스터가 소스 레지스터이고 상기 제2 스칼라 레지스터가 목적지 레지스터인 경우, 상기 처리 회로는 상기 제1 및 그 다음의 혼합 스칼라 벡터 명령의 상기 오버랩된 실행이 상기 제2 스칼라 레지스터가 상기 제1 스칼라 레지스터와 동일한 레지스터인지 여부에 따라 상이한 상기 제1 혼합 스칼라 벡터 명령의 결과를 생성하는 것을 허용하도록 구성되고,

상기 제1 스칼라 레지스터가 목적지 레지스터이고 상기 제2 스칼라 레지스터가 소스 레지스터이며 상기 제1 스칼라 레지스터 및 상기 제2 스칼라 레지스터가 동일한 레지스터인 경우, 상기 처리 회로는 상기 제1 및 그 다음의 혼합 스칼라 벡터 명령의 상기 오버랩된 실행이, 상기 제1 및 그 다음의 혼합 스칼라 벡터 명령들 사이의 개재 명령들의 수에 따라 상이한 상기 제2 혼합 스칼라 벡터 명령의 결과를 생성하는 것을 허용하도록 구성되는, 장치.

(23) 상기 제1 및 그 다음의 혼합 스칼라 벡터 명령들 중 적어도 하나는 산술 명령인, 항목(22)에 따른 장치.

(24) 처리 회로는 복수의 상이한 클래스의 혼합 스칼라 벡터 명령의 처리를 지원하도록 구성되고,

상기 처리 회로는 상기 제1 및 그 다음의 혼합 스칼라 벡터 명령들이 동일한 클래스의 혼합 스칼라 벡터 명령으로부터 오는 경우에 상기 제1의 다음 혼합 스칼라 벡터 명령의 상기 완화된 실행을 방지하도록 구성되는, 조항 (22) 및 (23) 중 어느 하나에 따른 장치.

(25) 상기 처리 회로는 상기 제1 및 그 다음의 혼합 스칼라 벡터 명령들의 상기 오버랩된 실행을 방지함으로써 상기 완화된 실행을 방지하도록 구성되는, 조항(24)에 따른 장치.

(26) 상기 제1 스칼라 레지스터가 소스 레지스터이고 상기 제2 스칼라 레지스터가 목적지 레지스터인 경우 상기 처리 회로는 제1 스칼라 레지스터로부터의 스칼라 값을 제3 스칼라 레지스터에 복사하고, 상기 제1 스칼라 레지스터 대신에 상기 제3 스칼라 레지스터를 상기 소스 레지스터로서 사용하여 상기 제1 혼합 스칼라 벡터 명령의 적어도 하나의 비트(beat)를 실행함으로써 상기 완화된 실행을 방지하도록 구성되는, 조항(24) 및 (25) 중의 어느 하나에 따른 장치.

(27) 상기 처리 회로는 동일한 하드웨어 회로 유닛을 사용하여 동일한 클래스로부터의 혼합 스칼라 벡터 명령들을 처리하도록 구성되는, 조항(24) 내지 (26) 중 어느 하나에 따른 장치.

(28) 상기 처리 회로는 상이한 하드웨어 회로 유닛들을 사용하여 적어도 몇몇 상이한 클래스들로부터의 혼합 스칼라 벡터 명령들을 처리하는, 조항(27)에 따른 장치.

(29) 복수의 클래스의 혼합 스칼라 벡터 명령은, 적어도

로드 명령을 적어도 포함하는 제1 클래스와,

곱셈을 수행하는 명령을 적어도 포함하는 제2 클래스를 포함하는, 상기(24) 내지 (28) 중 어느 하나에 따른 장치.

(30) 복수의 클래스의 혼합 스칼라 벡터 명령은 적어도

메모리 액세스 명령들을 적어도 포함하는 제1 클래스와,

곱셈을 수행하는 명령을 적어도 포함하는 제2 클래스와,

비곱셈 연산 명령을 적어도 포함하는 제3 클래스 및 부동 소수점 명령을 적어도 포함하는 제4 클래스 중 적어도 하나를 포함하는, 조항(24) 내지 (29) 중 어느 하나에 따른 장치.

(31) 상기 처리 회로는 상기 제1 및 그 다음의 혼합 스칼라 벡터 명령들 사이의 개재 명령이 오버랩 배리어 명령인 경우 상기 제1 및 그 다음의 혼합 스칼라 벡터 명령들의 상기 완화된 실행을 방지하도록 구성되는, 조항(22) 내지 (30) 중 어느 하나에 따른 장치.

(32) 상기 제1 스칼라 레지스터는 소스 레지스터이고 상기 제2 스칼라 레지스터는 목적지 레지스터인 경우, 상기 처리 회로는 상기 제1 스칼라 레지스터로부터의 스칼라 값을 제3 스칼라 레지스터에 복사함으로써 상기 완화된 실행을 방지하고, 상기 제1 스칼라 레지스터 대신에 상기 제3 스칼라 레지스터를 상기 소스 레지스터로서 사용하여 상기 제1 혼합 스칼라 벡터 명령의 적어도 하나의 비트(beat)를 실행하도록 구성되는, 조항(31)에 따른 장치.

(33) 상기 처리 회로는 적어도 하나의 no-op 연산으로서 상기 오버랩 배리어 명령을 실행하도록 구성되는, 조항(31) 및 (32) 중 어느 하나에 따른 장치.

(34) 상기 스칼라 레지스터가 상기 소스 레지스터들 중 하나인 혼합 스칼라 벡터 명령에 응답하여, 상기 처리 회로는 상기 스칼라 레지스터 내의 스칼라 값에 의존하는 상기 복수의 비트(beats)의 처리의 각각을 수행하도록 구성되는, 조항(22) 내지 (33) 중의 어느 하나에 따른 장치.

(35) 상기 스칼라 레지스터가 목적지 레지스터인 혼합 스칼라 벡터 명령에 응답하여, 상기 스칼라 레지스터에 기록될 스칼라 결과 값은 상기 복수의 비트(beats)의 처리의 각각의 결과에 의존하는, 조항(22) 내지 (34) 중 어느 하나에 따른 장치.

(36) 적어도 하나의 유형의 혼합 스칼라 벡터 명령에 대해, 상기 스칼라 레지스터는 소스 레지스터 및 목적지 레지스터 양자 모두인, 조항(22) 내지 (35) 중 어느 하나에 따른 장치.

(37) 처리 회로는 주어진 벡터 명령의 복수의 비트들(beats) 모두를 병렬로 수행하기에 불충분한 하드웨어를 구비하는, 조항(22) 내지(36) 중 어느 하나에 따른 장치.

(38) 상기 오버랩된 실행에서, 처리 회로는 상기 제2 벡터 명령의 제2 서브세트의 비트들(beats)을 상기 제1 벡터 명령의 제2 서브세트의 비트들(beats)과 병렬로 수행하도록 구성되는, 조항(22) 내지(37) 중 어느 하나에 따른 장치.

(39) 상기 복수의 비트(beats)의 처리는 2^J 비트(beats)의 처리를 포함하고, 여기서 J는 1보다 크거나 같은 정수이고,

상기 오버랩된 실행에서, 처리 회로는 상기 제1 벡터 명령의 (2K+1)번째 비트(beat)와 병렬로 상기 제2 벡터 명령의 제1 비트(beat)를 수행하도록 구성되고, 여기서, K는 정수이고 0≤K<J,

상기 소정 수의 개재 명령들은 (2^(J-K)-1)을 포함하는, 조항 (22) 내지 (38) 중 어느 하나에 따른 장치.

(40) 벡터 값은 처리 회로에 액세스 가능한 데이터 요소 크기 정보에 의해 지정된 복수의 데이터 요소 크기 중 하나를 갖는 데이터 요소들을 포함하고,

각 비트(beat)의 처리는 상기 데이터 요소 크기 정보로 나타낸 데이터 요소 크기와 관계없이 벡터 값의 고정된 크기 부분에 대응하는 처리를 포함하는, 조항(22) 내지 (39) 중 어느 하나에 따른 장치.

(41) 하나 이상의 소스 레지스터 및 목적지 레지스터를 지정하는 벡터 명령들을 처리하는 수단을 구비하는 장치로서, 상기 목적지 레지스터 및 상기 하나 이상의 소스 레지스터 중 적어도 하나는 복수의 데이터 요소를 포함하는 벡터 값을 저장하기 위한 벡터 레지스터이고,

상기 벡터 명령은 상기 목적지 레지스터 및 상기 하나 이상의 소스 레지스터 중 다른 하나가 단일 데이터 요소를 포함하는 스칼라 값을 저장하기 위한 스칼라 레지스터인 적어도 하나의 유형의 혼합 스칼라 벡터 명령을 포함하며,

주어진 벡터 명령에 응답하여, 상기 처리 수단은 복수의 비트(beats)의 처리를 수행하도록 구성되며, 각 비트(beat)는 상기 벡터 값의 일부분에 대응하는 처리를 포함하고,

상기 처리 수단은 제1 벡터 명령의 적어도 하나의 비트(beat)가 상기 제2 벡터 명령의 적어도 하나의 비트(beat)와 병렬로 수행되는 제1 벡터 명령 및 제2 벡터 명령의 오버랩된 실행을 지원하도록 구성되며,

제1 스칼라 레지스터를 지정하는 제1 혼합 스칼라 벡터 명령 및 제2 스칼라 레지스터를 지정하는 그 다음의 혼합 스칼라 벡터 명령을 포함하는 명령들의 시퀀스에 응답하여, 상기 제1 및 그 다음의 혼합 스칼라 벡터 명령들 사이의 소정 수의 개재 명령들보다 적게, 상기 처리 수단은 다음 중 적어도 하나를 포함하는 완화된 실행을 지원하도록 구성되며,

상기 제1 스칼라 레지스터가 소스 레지스터이고 상기 제2 스칼라 레지스터가 목적지 레지스터인 경우, 상기 처리 수단은 상기 제1 및 그 다음의 혼합 스칼라 벡터 명령의 상기 오버랩된 실행이 상기 제2 스칼라 레지스터가 상기 제1 스칼라 레지스터와 동일한 레지스터인지 여부에 따라 상이한 상기 제1 혼합 스칼라 벡터 명령의 결과를 생성하는 것을 허용하도록 구성되며,

상기 제1 스칼라 레지스터가 목적지 레지스터이고 상기 제2 스칼라 레지스터가 소스 레지스터이며 상기 제1 스칼라 레지스터와 상기 제2 스칼라 레지스터가 동일한 레지스터이면, 상기 처리 수단은 상기 제1 및 그 다음의 혼합 스칼라 벡터 명령의 상기 오버랩된 실행이 상기 제1 및 그 다음의 혼합 스칼라 벡터 명령 사이의 개재 명령의 수에 따라 상이한 상기 제2 혼합 스칼라 벡터 명령의 결과를 생성하는 것을 허용하도록 구성되는, 장치

(42) 조항(22) 내지 (40) 중 어느 하나에 따른 장치에 대응하는 명령 실행 환경을 제공하도록 호스트 데이터 처리 장치를 제어하는 프로그램 명령을 포함하는 가상 머신 컴퓨터 프로그램.

본 원에서, "... 구성됨(to configured)"라는 단어는 장치의 구성요소가 정의된 동작을 수행할 수 있는 구성을 갖는다 것을 의미하는 것으로 사용된다. 이 문맥에서, "구성"은 하드웨어 또는 소프트웨어의 상호접속의 구성 또는 방식을 의미한다. 예를 들어, 장치는 정의된 동작을 제공하는 전용 하드웨어를 가질 수 있거나 프로세서 또는 다른 처리 장치가 기능을 수행하도록 프로그래밍될 수 있다. "구성됨"은 정의된 동작을 제공하기 위해 장치 구성요소가 어떤 식으로든 변경되어야 함을 의미하지는 않는다.

본 발명의 예시적인 실시 예가 첨부된 도면을 참조하여 상세히 설명되었지만, 본 발명은 이러한 정확한 실시 예들에 한정되지 않으며, 다양한 변경 및 수정이 첨부된 청구항에 의해 한정된 본 발명의 범위 및 정신으로부터 일탈하는 일없이 본 기술분양의 당업자에 의해 이루어질 수 있다.

Claims

소스 피연산자 및 결과 값 중 적어도 하나가 복수의 데이터 요소를 포함하는 벡터 값인 벡터 명령들을 처리하는 처리 회로를 구비하고,
주어진 벡터 명령에 응답하여, 상기 처리 회로는 복수의 비트(beats)의 처리를 수행하도록 구성되고, 각 비트(beat)는 상기 벡터 값의 일부에 대응하는 처리를 포함하며,
상기 처리 회로는 상기 주어진 벡터 명령을 포함하는 복수의 벡터 명령 중 어느 비트(beats)가 완료했는지를 나타내는 비트 상태 정보를 설정하도록 구성되며,
이벤트에 응답하여, 상기 처리 회로는 상기 주어진 벡터 명령의 처리를 중단하도록 구성되고,
상기 주어진 벡터 명령의 처리로의 복귀를 나타내는 이벤트로부터의 복귀 요청에 응답하여, 상기 처리 회로는 완료한 것으로서 상기 비트 상태 정보로 나타낸 상기 복수의 벡터 명령의 비트들(beats)을 억제하면서 상기 복수의 벡터 명령의 처리를 재개하도록 구성되고,
상기 벡터 값은 상기 처리 회로가 액세스 가능한 데이터 요소 크기 정보에 의해 지정된 복수의 데이터 요소 크기 중 하나를 갖는 데이터 요소들을 포함하고,
각 비트(beat)의 처리는 상기 데이터 요소 크기 정보로 나타낸 데이터 요소 크기와 관계없이, 상기 벡터 값의 고정된 크기 부분에 대응하는 처리를 포함하는, 장치.
제 1 항에 있어서,
상기 처리 회로는 상기 복수의 벡터 명령 중 하나의 어드레스를 나타내는 복귀 어드레스를 설정하도록 구성되며,
상기 이벤트로부터의 복귀 요청에 응답하여, 상기 처리 회로는 상기 복귀 어드레스 및 상기 비트 상태 정보에 근거해서 처리가 재개되는 포인트를 식별하도록 구성되는, 장치.
제 2 항에 있어서,
상기 복귀 어드레스는 적어도 하나의 비트(beat)가 여전히 완료되어야 하는 가장 오래된 벡터 명령의 어드레스를 나타내는, 장치.
제 1 항 내지 제 3 항 중 어느 한 항에 있어서,
상기 복수의 벡터 명령은 적어도 하나의 비트(beat)가 여전히 완료되어야 하는 가장 오래된 벡터 명령 및 적어도 하나의 다음 벡터 명령을 포함하는, 장치.
제 1 항 내지 제 4 항 중 어느 한 항에 있어서,
상기 처리 회로는 상기 주어진 벡터 명령의 복수의 비트(beats)의 제1 서브세트를 완료한 후에 상기 주어진 벡터 명령의 복수의 비트(beats)의 제2 서브세트를 수행하도록 구성되는, 장치.
제 5 항에 있어서,
상기 처리 회로는, 제2 벡터 명령에 대한 제1 서브세트의 비트들(beats)을 수행하는 것과 병행하여 제1 벡터 명령에 대한 제2 서브세트의 비트들(beats)을 수행하도록 구성되는, 장치.
제 1 항 내지 제 6 항 중 어느 한 항에 있어서,
하나의 벡터 명령의 얼마나 많은 비트들(beats)이 다음 벡터 명령의 제1 비트(beats)를 시작하기 전에 완료되어야 하는지를 명령마다 변경하는 제어 회로를 구비하는, 장치.
제 1 항 내지 제 7 항 중 어느 한 항에 있어서,
상기 처리 회로는 상기 주어진 벡터 명령의 복수의 비트(beats) 모두를 병렬로 수행하기에 불충분한 하드웨어를 구비하는, 장치.
제 1 항 내지 제 4 항, 제 6 항 및 제 7 항 중 어느 한 항에 있어서,
상기 처리 회로는 상기 주어진 벡터 명령의 복수의 비트(beats) 모두를 병렬로 수행하는 것을 지원하도록 구성된 하드웨어를 구비하는, 장치.
제 1 항 내지 제 9 항 중 어느 한 항에 있어서,
상기 처리 회로는, 상기 비트 상태 정보를 상기 처리 회로에 의해 실행되는 소프트웨어, 예외 핸들러 및 디버거 중 적어도 하나가 액세스 가능하게 하도록 구성되는, 장치.
제 1 항 내지 제 10 항 중 어느 한 항에 있어서,
상기 이벤트는 디버그 이벤트를 포함하고, 상기 이벤트로부터의 복귀 요청은 디버그 상태로부터의 복귀를 포함하는, 장치.
제 1 항 내지 제 11 항 중 어느 한 항에 있어서,
상기 이벤트는 예외 이벤트를 포함하고, 상기 이벤트로부터의 복귀 요청은 예외 복귀를 포함하는, 장치.
제 12 항에 있어서,
상기 예외 이벤트는 결함 이벤트를 포함하고, 상기 결함 이벤트에 응답하여, 상기 처리 회로는 상기 복수의 벡터 명령 중 어느 것이 상기 결함 이벤트가 검출되었던 상기 주어진 벡터 명령인지를 식별하는 정보를 설정하도록 구성되는, 장치.
제 12 항 또는 제 13 항에 있어서,
상기 예외 이벤트에 응답하여, 상기 처리 회로는, 상기 비트 상태 정보에 대한 액세스를 디스에이블하도록 구성되고,
상기 비트 상태 정보에 액세스하려고 시도하는 명령 또는 복수의 비트의 처리를 포함하는 적어도 하나의 유형의 추가 벡터 명령의 실행에 응답하여, 상기 처리 회로는,
상기 비트 상태 정보를 미리 결정된 위치에 저장하거나, 또는
제2 예외 이벤트를 발생하도록 구성되는, 장치.
제 12 항 또는 제 13 항에 있어서,
상기 예외 이벤트에 응답하여, 상기 처리 회로는 스택 포인터 레지스터로 나타낸 값에 대한 오프셋에서 상기 비트 상태 정보를 데이터 저장장치 내의 위치에 저장하도록 구성되는, 장치.
제 15 항에 있어서,
상기 처리 회로는 적어도 안전한 상태 및 덜 안전한 상태를 포함하는 복수의 보안 상태에서 동작 가능하고, 상기 안전한 상태로부터 상기 덜 안전한 상태로의 천이를 일으키는 예외 이벤트에 응답하여, 상기 처리 회로는 상기 비트 상태 정보를 클리어하도록 구성되는, 장치.
제 1 항 내지 제 16 항 중 어느 한 항에 있어서,
상기 처리 회로는, 주어진 비트의 처리에 대응하는 목적지 벡터 레지스터의 일부의 갱신을 억제하는 것과,
상기 주어진 비트의 처리와 관련된 처리 동작을 억제하는 것 중 하나에 의해
상기 주어진 비트의 처리를 억제하도록 구성되는, 장치.
소스 피연산자 및 결과 값 중 적어도 하나가 복수의 데이터 요소를 포함하는 벡터 값인 벡터 명령들을 처리하는 수단을 구비하고,
주어진 벡터 명령에 응답하여, 상기 처리 수단은 복수의 비트(beats)의 처리를 수행하도록 구성되며, 각 비트(beat)는 상기 벡터 값의 일부에 대응하는 처리를 포함하고,
상기 처리 수단은 상기 주어진 벡터 명령을 포함하는 복수의 벡터 명령 중 어느 비트(beats)가 완료했는지를 나타내는 비트 상태 정보를 설정하도록 구성되고,
이벤트에 응답하여, 상기 처리 수단은 상기 주어진 벡터 명령의 처리를 중단하도록 구성되며,
상기 주어진 벡터 명령의 처리로의 복귀를 나타내는 이벤트로부터의 복귀 요청에 응답하여, 상기 처리 수단은 완료한 것으로서 상기 비트 상태 정보로 나타낸 상기 복수의 벡터 명령의 비트들(beats)을 억제하면서 상기 복수의 벡터 명령의 처리를 재개하도록 구성되고,
상기 벡터 값은 상기 처리 수단이 액세스 가능한 데이터 요소 크기 정보에 의해 지정된 복수의 데이터 요소 크기 중 하나를 갖는 데이터 요소들을 포함하고,
각 비트(beat)의 처리는 상기 데이터 요소 크기 정보로 나타낸 데이터 요소 크기와 관계없이, 상기 벡터 값의 고정된 크기 부분에 대응하는 처리를 포함하는, 장치.
소스 피연산자 및 결과 값 중 적어도 하나가 복수의 데이터 요소를 포함하는 벡터 값인 벡터 명령들을 처리하는 방법으로서,
주어진 벡터 명령에 응답하여, 각 비트(beat)가 상기 벡터 값의 일부에 대응하는 처리를 포함하는 복수의 비트(beats)의 처리를 수행하는 단계와,
상기 주어진 벡터 명령을 포함하는 복수의 벡터 명령 중 어느 비트(beats)가 완료했는지를 나타내는 비트 상태 정보를 설정하는 단계와,
이벤트에 응답하여, 상기 주어진 벡터 명령의 처리를 중단하는 단계와,
상기 주어진 벡터 명령의 처리로의 복귀를 나타내는 이벤트로부터의 복귀 요청에 응답하여, 완료한 것으로서 상기 비트 상태 정보로 나타낸 상기 복수의 벡터 명령의 비트들(beats)을 억제하면서 상기 복수의 벡터 명령의 처리를 재개하는 단계를 포함하고,
상기 벡터 값은 데이터 요소 크기 정보에 의해 지정된 복수의 데이터 요소 크기 중 하나를 갖는 데이터 요소들을 포함하고,
각 비트(beat)의 처리는 상기 데이터 요소 크기 정보로 나타낸 데이터 요소 크기와 관계없이, 상기 벡터 값의 고정된 크기 부분에 대응하는 처리를 포함하는, 처리방법.
청구항 1 내지 17 중 어느 한 항에 기재된 장치에 대응하는 명령 실행 환경을 제공하도록 호스트 데이터 처리 장치를 제어하는 프로그램 명령들을 포함하는 가상 머신 컴퓨터 프로그램.