KR101529846B1 - 원자 영역에서 조건부 커미트를 위한 결정 메카니즘 제공 장치, 방법, 및 시스템 - Google Patents
원자 영역에서 조건부 커미트를 위한 결정 메카니즘 제공 장치, 방법, 및 시스템 Download PDFInfo
- Publication number
- KR101529846B1 KR101529846B1 KR1020147018278A KR20147018278A KR101529846B1 KR 101529846 B1 KR101529846 B1 KR 101529846B1 KR 1020147018278 A KR1020147018278 A KR 1020147018278A KR 20147018278 A KR20147018278 A KR 20147018278A KR 101529846 B1 KR101529846 B1 KR 101529846B1
- Authority
- KR
- South Korea
- Prior art keywords
- code
- speculative
- transaction
- section
- checkpoint
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 50
- 230000007246 mechanism Effects 0.000 title description 8
- 238000005457 optimization Methods 0.000 claims abstract description 80
- 230000004044 response Effects 0.000 claims abstract description 44
- 239000012536 storage buffer Substances 0.000 claims description 64
- 230000008439 repair process Effects 0.000 claims description 25
- 230000036961 partial effect Effects 0.000 claims description 7
- 230000008030 elimination Effects 0.000 claims description 5
- 238000003379 elimination reaction Methods 0.000 claims description 5
- 238000011084 recovery Methods 0.000 abstract description 2
- 239000000872 buffer Substances 0.000 description 44
- 238000003860 storage Methods 0.000 description 39
- 238000012545 processing Methods 0.000 description 22
- 230000006870 function Effects 0.000 description 8
- 238000011156 evaluation Methods 0.000 description 7
- 238000003780 insertion Methods 0.000 description 7
- 230000037431 insertion Effects 0.000 description 7
- 230000009471 action Effects 0.000 description 6
- 230000003068 static effect Effects 0.000 description 6
- 230000008901 benefit Effects 0.000 description 5
- 238000010586 diagram Methods 0.000 description 5
- 230000008569 process Effects 0.000 description 5
- 238000004458 analytical method Methods 0.000 description 4
- 238000006243 chemical reaction Methods 0.000 description 4
- 239000003795 chemical substances by application Substances 0.000 description 4
- 238000012544 monitoring process Methods 0.000 description 4
- 238000013519 translation Methods 0.000 description 4
- 230000003139 buffering effect Effects 0.000 description 3
- 230000007423 decrease Effects 0.000 description 3
- 238000001514 detection method Methods 0.000 description 3
- 238000005259 measurement Methods 0.000 description 3
- 230000002028 premature Effects 0.000 description 3
- 230000002829 reductive effect Effects 0.000 description 3
- 238000005096 rolling process Methods 0.000 description 3
- 230000003466 anti-cipated effect Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 230000003247 decreasing effect Effects 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000000737 periodic effect Effects 0.000 description 2
- 238000004513 sizing Methods 0.000 description 2
- 238000000638 solvent extraction Methods 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 238000010200 validation analysis Methods 0.000 description 2
- 239000002699 waste material Substances 0.000 description 2
- 238000003491 array Methods 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 210000004027 cell Anatomy 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000000670 limiting effect Effects 0.000 description 1
- 230000000116 mitigating effect Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 238000007781 pre-processing Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 238000012163 sequencing technique Methods 0.000 description 1
- 210000000352 storage cell Anatomy 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
- 230000001052 transient effect Effects 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
- G06F8/44—Encoding
- G06F8/443—Optimisation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/76—Architectures of general purpose stored program computers
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/52—Binary to binary
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30003—Arrangements for executing specific machine instructions
- G06F9/3004—Arrangements for executing specific machine instructions to perform operations on memory
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30003—Arrangements for executing specific machine instructions
- G06F9/30072—Arrangements for executing specific machine instructions to perform conditional operations, e.g. using predicates or guards
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30003—Arrangements for executing specific machine instructions
- G06F9/30076—Arrangements for executing specific machine instructions to perform miscellaneous control operations, e.g. NOP
- G06F9/30087—Synchronisation or serialisation instructions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30098—Register arrangements
- G06F9/30105—Register structure
- G06F9/30116—Shadow registers, e.g. coupled registers, not forming part of the register space
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
- G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
- G06F9/3842—Speculative instruction execution
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
- G06F9/3854—Instruction completion, e.g. retiring, committing or graduating
- G06F9/3858—Result writeback, i.e. updating the architectural state or memory
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/466—Transaction processing
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Memory System Of A Hierarchy Structure (AREA)
- Executing Machine-Instructions (AREA)
- Advance Control (AREA)
- Retry When Errors Occur (AREA)
- Devices For Executing Special Programs (AREA)
Abstract
추론적 체크포인팅 트랜잭션을 조건부로 커미트하여, 잠재적으로 트랜잭션을 동적으로 리사이즈하는 장치 및 방법이 본 명세서에 기술된다. 이진 코드의 동적 최적화 동안, 메모리 순서화 보호책을 제공하는 트랜잭션을 삽입하여, 동적 최적화기가 코드를 더 공격적으로 최적화할 수 있게 한다. 그리고 조건부 커미트는 트랜잭션의 하드웨어 자원이 부족하지 않도록 하면서, 동적 최적화 코드의 효율적인 실행을 가능하게 한다. 추론적 체크포인트는 트랜잭션의 중단시 빠르고 효율적인 복구를 가능하게 한다. 프로세서 하드웨어는 조건부 커미트 명령어, 추론적 체크포인트 명령어, 또는 둘 다를 인식하는 디코더를 포함하는 것과 같이 트랜잭션의 동적 리사이징을 지원하도록 구성된다. 그리고 프로세서 하드웨어는 그러한 명령어를 디코드함에 응답하여 조건부 커미트 또는 추론적 체크포인팅을 지원하는 동작을 수행하도록 추가로 구성된다.
Description
본 발명은 프로세서 분야, 특히, 프로세서 상의 코드 최적화 및 실행에 관한 것이다.
반도체 처리 및 논리 설계의 발전으로 집적 회로 디바이스 상에 존재할 수 있는 논리의 양이 증가되었다. 이전에, 단일 스레드(thread) 프로세서에서 이진 코드(binary code)와 같은 코드의 최적화는 다른 실행 스레드(threads)에 의한 간섭 염려가 없기 때문에 지나치게 공격적이었다. 그러나, 컴퓨터 시스템 구성은 시스템 내 단일 또는 다수의 집적 회로에서 개별의 집적 회로 상에 존재하는 다중 코어, 다중 하드웨어 스레드, 및 다중 논리 프로세서로 진화되었다. 프로세서 또는 집적 회로는 전형적으로 단일의 물리적 프로세서 다이(die)를 포함하며, 여기서 프로세서 다이는 코어, 하드웨어 스레드, 또는 논리 프로세서를 몇 개라도 포함할 수 있다. 집적 회로 상에 처리 소자, 즉 코어, 하드웨어 스레드, 및 논리 프로세서의 수를 계속 증가시키면 더 많은 작업을 병렬로 성취하는 것이 가능하다. 이와 같이 단일 스레드(threaded) 프로세서에서 더 많은 병렬의 다중 스레드 실행으로의 진화는 코드 최적화를 제한시키는 결과를 초래하였다.
의사(Pseudo) 코드 A: 단일 스레드 코드 최적화의 일 실시예
예를 들면, 의사 코드 A는 [r2] 및 [r2+4]에서 메모리로부터의 로드(loads)가 부분 중복 로드 제거(Partial Redundancy Load Elimination: PRLE) 최적화에 의해 루프를 벗어나 헤더 블록(B3)으로 올라가는(hoisted) 이진 코드의 최적화를 예시한다. 그리고 [r2+4]에서 메모리에의 저장(store)은 부분 데드 저장 제거(Partial Dead Store Elimination: PDSE) 최적화에 의해 루프를 벗어나 테일(tail) 블록(B4)으로 내려간다(sunk). 이러한 최적화는 단일 스레드 환경에서 동작할 수 있다. 그러나, 다중 스레드 애플리케이션에서 다른 스레드가 루프 실행 동안 [r2] 또는 [r2+4]에서 메모리에 기록/메모리로부터 판독할 수 있어, 잠재적으로 메모리 동작의 실행 순서의 변화로 인해 실행을 무효로 한다.
본 발명은 예를 들어 예시되고 첨부의 도면에 의해 제한되는 것은 아니다.
도 1은 원자(atomic) 영역의 원자 실행 및 동적 리사이징(resizing)을 지원하도록 구성된 다중처리 소자 프로세서의 논리 표현의 일 실시예를 예시한다.
도 2a는 하드웨어 자원 제한사항에 따라 트랜잭션의 동적 리사이징을 제공하는 것을 포함하는 코드 최적화 방법의 흐름도의 일 실시예를 예시한다.
도 2b는 조건부 커미트 코드(conditional commit code)를 삽입하는 도 2a의 흐름도의 일 실시예를 예시한다.
도 3a는 실행 동안 트랜잭션을 동적으로 리사이징하는 방법의 흐름도의 일 실시예를 예시한다.
도 3b는 조건부 커미트 지점에 실행을 지속하기에 충분한 하드웨어 자원이 존재하는지를 판단하는 도 3a의 흐름도의 일 실시예를 예시한다.
도 4는 트랜잭션의 동적 리사이징을 지원하도록 구성된 하드웨어의 논리 표현의 일 실시예를 예시한다.
도 5는 트랜잭션의 동적 리사이징을 지원하도록 구성된 하드웨어의 논리 표현의 다른 실시예를 예시한다.
도 6은 트랜잭션의 동적 리사이징을 지원하도록 구성된 하드웨어의 논리 표현의 또 다른 실시예를 예시한다.
도 7a는 트랜잭션 내에서 추론적 체크포인트(speculative checkpoints)를 제공하는 것을 포함하는 코드 최적화 방법의 흐름도의 일 실시예를 예시한다.
도 7b는 추론적 체코포인트 코드를 삽입하는 도 7a의 흐름도의 일 실시예를 예시한다.
도 8은 트랜잭션 실행 동안 메모리를 추론적으로 체크포인팅하는 방법의 흐름도의 일 실시예를 예시한다.
도 9는 메모리의 추론적 체크포인팅을 지원하도록 구성된 하드웨어의 논리 표현의 일 실시예를 예시한다.
도 10은 레지스터 파일의 추론적 체크포인팅을 지원하도록 구성된 하드웨어의 논리 표현의 다른 실시예를 예시한다.
도 11은 캐시(cache) 메모리의 추론적 체크포인팅을 지원하도록 구성된 하드웨어의 논리 표현의 또 다른 실시예를 예시한다.
도 1은 원자(atomic) 영역의 원자 실행 및 동적 리사이징(resizing)을 지원하도록 구성된 다중처리 소자 프로세서의 논리 표현의 일 실시예를 예시한다.
도 2a는 하드웨어 자원 제한사항에 따라 트랜잭션의 동적 리사이징을 제공하는 것을 포함하는 코드 최적화 방법의 흐름도의 일 실시예를 예시한다.
도 2b는 조건부 커미트 코드(conditional commit code)를 삽입하는 도 2a의 흐름도의 일 실시예를 예시한다.
도 3a는 실행 동안 트랜잭션을 동적으로 리사이징하는 방법의 흐름도의 일 실시예를 예시한다.
도 3b는 조건부 커미트 지점에 실행을 지속하기에 충분한 하드웨어 자원이 존재하는지를 판단하는 도 3a의 흐름도의 일 실시예를 예시한다.
도 4는 트랜잭션의 동적 리사이징을 지원하도록 구성된 하드웨어의 논리 표현의 일 실시예를 예시한다.
도 5는 트랜잭션의 동적 리사이징을 지원하도록 구성된 하드웨어의 논리 표현의 다른 실시예를 예시한다.
도 6은 트랜잭션의 동적 리사이징을 지원하도록 구성된 하드웨어의 논리 표현의 또 다른 실시예를 예시한다.
도 7a는 트랜잭션 내에서 추론적 체크포인트(speculative checkpoints)를 제공하는 것을 포함하는 코드 최적화 방법의 흐름도의 일 실시예를 예시한다.
도 7b는 추론적 체코포인트 코드를 삽입하는 도 7a의 흐름도의 일 실시예를 예시한다.
도 8은 트랜잭션 실행 동안 메모리를 추론적으로 체크포인팅하는 방법의 흐름도의 일 실시예를 예시한다.
도 9는 메모리의 추론적 체크포인팅을 지원하도록 구성된 하드웨어의 논리 표현의 일 실시예를 예시한다.
도 10은 레지스터 파일의 추론적 체크포인팅을 지원하도록 구성된 하드웨어의 논리 표현의 다른 실시예를 예시한다.
도 11은 캐시(cache) 메모리의 추론적 체크포인팅을 지원하도록 구성된 하드웨어의 논리 표현의 또 다른 실시예를 예시한다.
다음의 설명에서는, 본 발명의 철저한 이해를 제공하기 위해, 특정 타입의 프로세서 코어, 특정 프로세서 구성, 특정 명령어 타입, 특정 하드웨어 구조, 특정 코드 최적화 기술 등의 예와 같은 많은 구체적인 세부사항이 기술된다. 그러나, 당업자에게는 본 발명을 실시하기 위해 이러한 구체적인 세부사항을 이용하지 않아도 된다는 것이 자명할 것이다. 다른 경우에, 특정 및 대안의 프로세서 구조, 기술된 알고리즘에 특정한 논리 회로/코드, 특정 코드 구현, 특정 컴파일러 세부사항, 및 마이크로프로세서의 다른 특정한 동작 세부사항과 같은 잘 알려진 구성요소 또는 방법은 본 발명을 불필요하게 모호하게 하지 않도록 하기 위해 상세히 기술되지 않았다.
본 명세서에서 기술된 방법 및 장치는 하드웨어 제약조건에 따라 동적 크기의 트랜잭션을 이용하여 코드를 최적화하는 것이다. 구체적으로, 코드 최적화는 하드웨어 제약조건을 이용하여 트랜잭션의 추론적 체크포인팅 및/또는 조건부 커미트와 관련하여 기술된다. 그러나, 본 명세서에서 기술된 장치 및 방법은 어떠한 동적 크기의 트랜잭션 형태로도 구현될 수 있으므로 그것으로 한정되지 않는다. 예를 들면, 코드 최적화는 하드웨어, 소프트웨어, 또는 이들의 조합 내에서뿐만 아니라, 정적으로 또는 동적으로 수행될 수 있다.
도 1을 참조하면, 다중 코어를 포함하는 프로세서의 일 실시예가 예시되어 있다. 프로세서(100)는 마이크로프로세서, 임베디드 프로세서, 디지털 신호 프로세서(DSP), 네트워크 프로세서, 또는 코드를 실행하는 다른 디바이스와 같은 어떤 프로세서라도 포함할 수 있다. 일 실시예에서, 프로세서(100)는 적어도 두 개의 코어, 즉 비대칭 코어 또는 대칭 코어(예시된 실시예)를 포함할 수 있는 코어(101 및 102)를 포함한다. 그러나, 프로세서(100)는 대칭 또는 비대칭일 수 있는 처리 소자를 몇 개라도 포함할 수 있다.
일 실시예에서, 처리 소자는 스레드 유닛, 스레드 슬롯, 프로세스 유닛, 콘텍스트(context), 논리 프로세서, 하드웨어 스레드, 코어, 및/또는 실행 상태 또는 구조적(architectural) 상태와 같이 프로세서의 상태를 유지할 수 있는 어떤 다른 소자를 지칭한다. 다시 말하면, 일 실시예에서, 처리 소자는 소프트웨어 스레드, 오퍼레이팅 시스템, 애플리케이션, 또는 다른 코드와 같은 코드와 독립적으로 연관될 수 있는 모든 하드웨어를 지칭한다. 물리적 프로세서는 전형적으로 잠재적으로 코어 또는 하드웨어 스레드와 같은 다른 처리 소자를 몇 개라도 포함하는 집적 회로를 지칭한다.
코어는 대개 독립적인 구조적 상태를 유지할 수 있는 집적 회로 상에 배치된 논리를 지칭하며, 여기서 독립적으로 유지되는 각각의 구조적 상태는 적어도 몇몇 전용 실행 자원과 연관된다. 코어와는 대조적으로, 하드웨어 스레드는 전형적으로 독립적인 구조적 상태를 유지할 수 있는 집적 회로 상에 배치된 모든 논리를 지칭하며, 여기서 독립적으로 유지되는 구조적 상태들은 실행 자원에의 액세스를 공유한다. 알 수 있는 바와 같이, 소정 자원이 공유되고 다른 자원이 구조적 상태에 전용된 경우, 하드웨어 스레드와 코어의 명명법 간의 라인이 겹친다. 그러나 종종, 코어 및 하드웨어 스레드는 오퍼레이팅 시스템에 의해 개별의 논리 프로세서로 간주되며, 이 경우 오퍼레이팅 시스템은 각각의 논리 프로세서에서 동작을 개별적으로 스케줄링(schedule)할 수 있다.
도 1에 예시된 바와 같이, 물리적 프로세서(100)는 두 개의 코어, 즉 코어(101 및 102)를 포함한다. 여기서, 코어(101 및 102)는 대칭적 코어, 즉 구성, 기능 유닛, 및/또는 논리가 동일한 코어로 간주된다. 다른 실시예에서, 코어(101)는 비순차적(out-of-order) 프로세서 코어를 포함하고, 반면에 코어(102)는 순차적(in-order) 프로세서 코어를 포함한다. 그러나, 코어(101 및 102)는 각각 원시(native) 코어, 소프트웨어 관리(managed) 코어, 원시 명령어 집합 구조(ISA)를 실행하도록 구성된 코어, 변환(translated) 명령어 집합 구조(ISA)를 실행하도록 구성된 코어, 공동 설계된(co-designed) 코어, 또는 다른 공지의 코어와 같은 임의의 타입의 코어로부터 선택될 수 있다. 그러나 더 설명하면, 코어(101)에 예시된 기능 유닛에 대해 아래에서 더욱 상세히 기술되며, 코어(102) 내의 유닛이 유사한 방식으로 동작한다.
도시된 바와 같이, 코어(101)는 하드웨어 스레드 슬롯(101a 및 101b)이라고도 지칭될 수 있는 두 개의 하드웨어 스레드(101a 및 101b)를 포함한다. 따라서, 일 실시예에서, 오퍼레이팅 시스템과 같은 소프트웨어 엔티티(entities)는 잠재적으로 프로세서(100)를 네 개의 개별의 프로세서, 즉 네 개의 소프트웨어 스레드를 동시에 실행할 수 있는 네 개의 논리 프로세서 또는 처리 소자로 간주한다. 부연하면, 제1 스레드는 구조적 상태 레지스터(101a)와 연관되고, 제2 스레드는 구조적 상태 레지스터(101b)와 연관되고, 제3 스레드는 구조적 상태 레지스터(102a)와 연관될 수 있으며, 그리고 제4 스레드는 구조적 상태 레지스터(102b)와 연관될 수 있다. 예시된 바와 같이, 구조적 상태 레지스터(101a)는 구조적 상태 레지스터(101b)에 복제(replicated)되므로, 논리 프로세서(101a) 및 논리 프로세서(101b)에 대한 개별의 구조적 상태/문맥(context)이 저장될 수 있다. 코어(101)에서, 스레드(101a 및 101b)에 대해 재명명(rename) 할당기 논리(130) 내의 명령어 포인터 및 재명명 논리와 같은 다른 소규모 자원도 또한 복제될 수 있다. 재순서(reorder)/폐기(retirement) 유닛(135) 내의 재순서 버퍼, ILTB(120), 로드(load)/저장(store) 버퍼, 및 큐(queues)와 같은 일부 자원은 분할(partitioning)을 통해 공유될 수 있다. 범용 내부 레지스터, 페이지-테이블 기반 레지스터, 하위레벨 데이터 캐시 및 데이터-TLB(115), 실행 유닛(들)(140), 및 비순차적 유닛(135)의 일부와 같은 다른 자원은 잠재적으로 완전히 공유된다.
프로세서(100)는 종종 처리 소자에 의해/처리 소자에 완전히 공유되거나, 분할을 통해 공유되거나, 또는 전용될 수 있는 다른 자원을 포함한다. 도 1에는, 프로세서의 예시적인 논리 유닛/자원을 갖는 단순히 예시적인 프로세서의 일 실시예가 예시되어 있다. 프로세서가 이러한 기능 유닛 중 어떤 것을 포함하거나, 생략할 뿐만 아니라, 도시되지 않은 어떤 다른 공지의 기능 유닛, 논리, 또는 펌웨어를 포함할 수 있음을 주목하자. 예시된 바와 같이, 코어(101)는 간략화된, 대표적인 비순차적(out-of-order: OOO) 프로세서 코어를 포함한다. OOO 코어는 실행되고/취해질 분기(branches)를 예측하는 분기 타겟 버퍼(120) 및 명령어에 대한 어드레스 변환 엔트리를 저장하는 명령어-변환 버퍼(I-TLB)(120)를 포함한다.
코어(101)는 패치 유닛(120)에 연결되어 패치된 요소를 디코드하는 디코드 모듈(125)을 더 포함한다. 일 실시예에서, 패치 논리는 각각 스레드 슬롯(101a, 101b)과 연관된 개별의 시퀀서를 포함한다. 일반적으로, 코어(101)는 프로세서(100)에서 실행가능한 명령어를 정의하고/지정하는 제1 명령어 집합 구조(ISA)와 연관된다. 여기서, 종종 제1 ISA의 일부인 기계 코드 명령어는 수행되는 명령어 또는 동작을 참조하고/지정하는 명령어(연산코드(opcode)라고 지칭됨)의 일부를 포함한다. 디코드 논리(125)는 이들 연산코드로부터의 이러한 명령어를 인식하고 디코드된 명령어를 제1 ISA에 의해 정의된 바와 같은 처리를 위한 파이프라인(pipeline)으로 전달하는 회로를 포함한다. 예를 들면, 아래에서 더욱 상세히 설명된 바와 같이, 일 실시예에서, 디코더(125)는 조건부 커미트(conditional commit) 명령어 및/또는 추론적 체크포인트(speculative checkpoint) 명령어와 같은 특정한 새로운 명령어를 인식하도록 설계되거나 구성된 논리를 포함한다. 결과로서 또는 디코더(125)에 의한 인식으로서, 구조 또는 코어(101)는 적절한 명령어와 연관된 작업을 수행하기에 특정한 사전 정의된 액션을 취한다.
일예에서, 할당기 및 재명명기(renamer) 블록(130)은 명령어 처리 결과를 저장하는 레지스터 파일과 같은 자원을 예약(reserve)하는 할당기를 포함한다. 그러나, 스레드(101a 및 101b)는 잠재적으로 비순차적 실행이 가능하며, 이 경우 할당기 및 재명명기 블록(130)은 명령어 결과를 추적하는 재순서 버퍼와 같은 다른 자원도 또한 예약한다. 유닛(130)은 또한 프로그램/명령어 참조(reference) 레지스터를 프로세서(100) 내부의 다른 레지스터로 재명명하는 레지스터 재명명기를 포함할 수 있다. 재순서화/폐기 유닛(135)은 비순차적 실행 및 비순차적으로 실행되는 명령어에 대한 나중의 순차적 폐기를 지원하는 전술한 재순서 버퍼, 로드 버퍼, 및 저장 버퍼와 같은 컴포넌트를 포함한다.
일 실시예에서, 스케줄러 및 실행 유닛(들) 블록(140)은 실행 유닛에서 명령어/동작을 스케줄링하는 스케줄러 유닛을 포함한다. 예를 들면, 이용가능한 부동 소수점(floating point) 실행 유닛을 갖는 실행 유닛의 포트에서 부동 소수점 명령어가 스케줄링된다. 또한, 실행 유닛과 연관된 레지스터 파일이 정보 명령어 처리 결과를 저장하기 위해 포함된다. 예시적인 실행 유닛은 부동 소수점 실행 유닛, 정수 실행 유닛, 점프 실행 유닛, 로드 실행 유닛, 저장 실행 유닛, 및 다른 공지의 실행 유닛을 포함한다.
하위레벨 데이터 캐시 및 데이터 변환 버퍼(D-TLB)(150)는 실행 유닛(들)(140)에 연결된다. 데이터 캐시는 잠재적으로 메모리 일관성(coherency) 상태로 유지되는 데이터 오퍼랜드(operands)와 같은 최근에 사용된/동작된 요소를 저장하는 것이다. D-TLB는 최근의 가상/선형 물리적 어드레스 변환을 저장하는 것이다. 특정 예로서, 프로세서는 물리적 메모리를 다수의 가상 페이지로 분할하는 페이지 테이블 구조를 포함할 수 있다.
여기서, 코어(101 및 102)는 최근에 패치된 요소를 캐시하는 것인 상위레벨 또는 더 먼(further-out) 캐시(110)에의 액세스를 공유한다. 상위레벨 또는 더 먼이라는 것은 실행 유닛(들)에서 점점 멀리 떨어지거나 멀리 떨어진 캐시 레벨을 말한다. 일 실시예에서, 상위레벨 캐시(110)는 마지막 레벨의 데이터 캐시, 즉 제2 또는 제3 레벨의 데이터 캐시와 같이 프로세서(100)의 메모리 계층에서 마지막 캐시이다. 그러나, 상위레벨 캐시(110)는 명령어 캐시와 연관되거나 명령어 캐시를 포함할 수 있기 때문에 그것으로 한정되지 않는다. 명령어 캐시의 한 타입인 추적(trace) 캐시는 그 대신 디코더(125) 다음에 연결되어 최근에 디코드된 추적을 저장할 수 있다.
도시된 구성에서, 프로세서(100)는 또한 프로세서(100) 외부의 디바이스들, 이를 테면, 시스템 메모리(175), 칩셋, 노스브리지, 또는 다른 집적 회로와 통신하는 버스 인터페이스 모듈(105)을 포함한다. 메모리(175)는 프로세서(100) 전용이거나 또는 시스템 내 다른 디바이스와 공유될 수 있다. 일반적인 타입의 메모리(175)의 예는 동적 랜덤 액세스 메모리(DRAM), 정적 RAM(SRAM), 비휘발성 메모리(NV 메모리), 및 다른 공지의 저장 디바이스를 포함한다.
일 실시예에서, 프로세서(100)는 하드웨어 트랜잭션 실행, 소프트웨어 트랜잭션 실행, 또는 이들의 조합 또는 하이브리드가 가능하다. 코드의 임계(critical) 또는 원자(atomic) 섹션/영역이라고도 지칭될 수 있는 트랜잭션은 원자 그룹으로서 실행되는 명령어, 동작, 또는 미세 동작을 그룹화한 것을 포함한다. 예를 들면, 명령어 또는 동작은 트랜잭션 또는 임계 섹션의 경계를 정하는데 사용될 수 있다. 아래에서 더욱 상세히 설명된 일 실시예에서, 이러한 명령어는 전술한 디코더와 같은 프로세서(100)의 하드웨어에 의해 인식가능한 명령어 집합 구조(ISA)와 같은 명령어 집합의 일부이다. 종종, 일단 상위레벨 언어에서 하드웨어가 인식가능한 어셈블리 언어로 컴파일되면, 이러한 명령어는 연산 코드(opcodes), 또는 디코드 단계 동안 디코더가 인식하는 명령어의 다른 부분을 포함한다.
전형적으로, 트랜잭션 실행 동안, 메모리 업데이트는 트랜잭션이 커미트(committed)될 때까지 전역적으로 가시화(globally visible)되지 않는다. 일예로서, 어떤 위치에의 트랜잭션 기록은 잠재적으로 로컬 스레드에 가시적이지만, 다른 스레드로부터의 판독에 응답하여, 기록 데이터는 트랜잭션 기록을 포함하는 트랜잭션이 커미트될 때까지 전달되지 않는다. 트랜잭션이 여전히 계류 중(pending)이면, 메모리로부터 로드된 그리고 메모리 내에 기록된 데이터 항목/요소는 아래에서 더욱 상세히 설명된 바와 같이 추적된다. 일단 트랜잭션이 커미트 지점(commit point)에 도달하면, 트랜잭션에 대한 충돌(conflicts)이 검출되지 않았다면, 트랜잭션은 커미트되고 트랜잭션 동안 이루어진 업데이트는 전역적으로 가시화된다. 그러나, 만일 트랜잭션이 그의 계류 중에 유효하지 않으면, 트랜잭션은 중단되고 업데이트가 전역적으로 가시화되지 않고 잠재적으로 재시작된다. 결과적으로, 본 명세서에서 사용된 바와 같이, 트랜잭션의 계류라는 것은 실행을 시작하였고 커미트되거나 중단되지 않은, 즉 계류 중인 트랜잭션을 말한다.
소프트웨어 트랜잭션 메모리(STM) 시스템은 종종 액세스 추적, 충돌 해결(conflict resolution), 또는 소프트웨어 코드의 실행 내에서 또는 적어도 주로 그러한 실행을 통해 다른 트랜잭션 메모리 작업을 수행하는 것을 말한다. 일 실시예에서, 프로세서(100)는 하드웨어/논리를 이용하여, 즉 하드웨어 트랜잭션 메모리(HTM) 시스템 내에서 트랜잭션을 실행할 수 있다. HTM을 구현할 때 구조 및 미세 구조 둘 다의 관점에서 많은 특정한 구현의 세부사항이 존재하며, 그 대부분은 본 발명을 불필요하게 모호하게 하지 않도록 하기 위해 본 명세서에서 설명되지 않는다. 그러나, 일부 구조, 자원, 및 구현예는 예시 목적으로 개시된다. 그러나, 이러한 구조 및 구현예는 반드시 필요하지 않고 구현의 세부사항을 다르게 한 다른 구조로 강화되고 및/또는 대체될 수 있음을 주목하여야 한다.
한가지 조합으로서, 프로세서(100)는 STM 및 HTM 시스템 양자의 이익을 이용하려는 무한 트랜잭션 메모리(UTM) 시스템 내에서 트랜잭션을 실행할 수 있다. 예를 들어, HTM은 대개 액세스 추적, 충돌 검출, 유효성(validation), 및 트랜잭션 커미트를 모두 수행하는 소프트웨어에 의존하지 않기 때문에 고속이고 소규모 트랜잭션을 실행하는데 효율적이다. 그러나, HTM은 보통 소규모 트랜잭션만을 다룰 수 있고, 반면에 STM은 무한 크기의 트랜잭션을 다룰 수 있다. 따라서, 일 실시예에서, UTM 시스템은 소규모 트랜잭션을 실행하는 하드웨어 및 그 하드웨어를 위해 너무 큰 트랜잭션을 실행하는 소프트웨어를 이용한다. 아래의 설명으로부터 알 수 있는 바와 같이, 소프트웨어가 트랜잭션을 다루는 경우에도, 하드웨어는 소프트웨어를 지원하고 가속화하는데 이용될 수 있다. 더욱이, 동일한 하드웨어가 순(pure) STM 시스템을 지원하고 가속화하는데에도 이용될 수 있다는 점을 주목하는 것이 중요하다.
전술한 바와 같이, 트랜잭션은 프로세서(100) 내의 로컬 처리 소자에 의해서뿐만 아니라, 잠재적으로 다른 처리 소자에 의해서도 데이터 항목에의 트랜잭션 메모리 액세스를 포함한다. 트랜잭션 메모리 시스템 내에 안전 메카니즘 없이도, 이러한 액세스의 일부가 잠재적으로 데이터 및 실행을 무효로 할 것이며, 즉 데이터 기록은 판독, 또는 무효 데이터의 판독을 무효로 한다. 결과적으로, 프로세서(100)는 아래에서 설명된 바와 같이 잠재적으로 판독 모니터 및 기록 모니터와 같이 잠재적인 충돌의 식별을 위해 데이터 항목에의 및 데이터 항목으로부터 메모리 액세스를 추적하거나 모니터하는 논리를 포함한다.
데이터 항목 및 데이터 요소는 하드웨어, 소프트웨어 또는 이들의 조합에 의해 정의된 바와 같이 어떤 입도(granularity) 레벨의 데이터를 포함할 수 있다. 불완전한(non-exhaustive) 목록의 데이터, 데이터 요소, 데이터 항목, 또는 그에 대한 참조의 예는 메모리 어드레스, 데이터 객체(object), 클래스, 한 타입의 동적 언어 코드의 필드, 한 타입의 동적 언어 코드, 변수(variable), 오퍼랜드(operand), 데이터 구조, 및 메모리 어드레스에 대한 간접 참조를 포함한다. 그러나, 어떤 공지의 데이터 그룹화는 데이터 요소 또는 데이터 항목이라고 지칭될 수 있다. 한 타입의 동적 언어 코드의 필드 및 한 타입의 동적 언어 코드와 같은 전술한 예들 중 몇몇은 동적 언어 코드의 데이터 구조를 지칭한다. 예시를 위해, 선 마이크로 시스템즈 사(Sun Microsystems, Inc)의 JavaTM과 같은 동적 언어 코드는 강형 언어(strongly typed language)이다. 각 변수는 컴파일 시간에 알려진 타입이다. 그 타입은 두 가지 부류, 즉 기본 타입(불린 및 수치, 예컨대, 정수(int), 플로트(float)) 및 참조 타입(클래스, 인터페이스 및 어레이)으로 나뉜다. 참조 타입의 값은 객체에 대한 참조이다. JavaTM에서, 필드로 구성된 객체는 클래스 인스턴스 또는 어레이일 수 있다. 클래스 A의 객체가 주어지면, 타입 A의 필드 x를 지칭하는 표기법 A::x 및 클래스 A의 객체 a의 필드 x를 지칭하는 a.x를 이용하는 것이 관례적이다. 예를 들면, 표현식은 a.x = a.y + a.z로 표현될 수 있다. 여기서, 필드 y 및 필드 z가 로드되어 더해지고 그 결과는 필드 x에 기록될 것이다.
따라서, 데이터 항목에의 메모리 액세스를 모니터링하고/버퍼링하는 것은 어떠한 데이터 레벨 입도로도 수행될 수 있다. 예를 들면, 일 실시예에서, 데이터의 메모리 액세스는 타입 레벨로 모니터된다. 여기서, 필드 A::x에의 트랜잭션 기록 및 필드 A::y의 비트랜잭션(non-transactional) 로드는 동일한 데이터 항목, 즉 타입 A에의 액세스로 모니터될 수 있다. 다른 실시예에서, 메모리 액세스 모니터링/버퍼링은 필드 레벨 입도로 수행된다. 여기서, A::x에의 트랜잭션 기록 및 A::y의 비트랜잭션 로드는 이들이 개별의 필드에 대한 참조이기 때문에 동일한 데이터 항목에의 액세스로 모니터되지 않는다. 주목할 것은, 데이터 항목에의 메모리 액세스를 추적할 때 다른 데이터 구조 또는 프로그래밍 기술이 고려될 수 있다. 일예로서, 클래스 A의 객체의 필드 x 및 y, 즉 클래스 B의 객체를 가리키는 A::x 및 A::y가 새로 할당된 객체로 초기화되고, 초기화 후에 결코 기록되지 않는다고 가정한다. 일 실시예에서, A::x가 가리키는 객체의 필드 B::z에의 트랜잭션 기록은 A::y가 가리키는 객체의 필드 B::z에의 비트랜잭션 로드와 관련하여 동일한 데이터 항목에의 메모리 액세스로 모니터되지 않는다. 이러한 예로부터 추정해 보면, 모니터가 어떠한 데이터 입도 레벨에서도 모니터링/버퍼링을 수행할 수 있다고 판단할 수 있다.
일 실시예에서, 프로세서(100)는 데이터 항목과 연관된 액세스, 및 잠재적인 나중의 충돌을 검출 또는 추적하는 모니터를 포함한다. 일예로서, 프로세서(100)의 하드웨어는 적절히 모니터될 것으로 판단되는 로드 및 저장을 추적하는 판독 모니터 및 기록 모니터를 포함한다. 일예로서, 하드웨어 판독 모니터 및 기록 모니터는 기본적인 저장 구조의 입도이지만 데이터 항목을 그 데이터 항목의 입도로 모니터하는 것이다. 일 실시예에서, 데이터 항목은 저장 구조의 입도로 연관된 메카니즘을 추적하여 확실하게 적어도 그 데이터 항목 전체를 적절히 모니터함으로써 제한된다.
특정한 예시적인 예로서, 판독 및 기록 모니터는 (추론적 캐시를 포함할 수 있는) 하위레벨 데이터 캐시(150) 내의 위치와 같은 캐시 위치와 연관된 특성을 포함하여, 그러한 위치와 연관된 어드레스로부터의 로드 및 그 어드레스에의 저장을 모니터한다. 여기서, 데이터 캐시(150)의 캐시 위치의 판독 특성은 판독 이벤트시 동일한 어드레스에의 잠재적인 충돌 기록을 모니터하는 캐시 위치와 연관된 어드레스로 설정된다. 이 경우, 기록 특성은 기록 이벤트가 동일한 어드레스에의 잠재적인 충돌 판독들 및 기록들을 모니터하도록 유사한 방식으로 동작한다. 이 예를 더 설명하면, 하드웨어는 캐시 위치가 적절히 모니터된 것을 표시하도록 판독 및/또는 기록 특성이 설정된 캐시 위치에의 판독 및 기록에 대한 스누프(snoops)에 기초하여 충돌을 검출할 수 있다. 반대로, 일 실시예에서, 판독 및 기록 모니터를 설정하거나, 또는 캐시 위치를 버퍼(buffered) 상태로 업데이트하면 판독 요청 또는 소유자(ownership)에 대한 판독 요청과 같은 스누프가 다른 캐시에서 어드레스를 모니터하는 충돌을 검출할 수 있다.
따라서, 이러한 설계에 기초하여, 캐시 일관성 요청 및 캐시 라인의 모니터된 일관성 상태를 다르게 결합하면 캐시 라인이 공유된 판독 모니터 상태에서 데이터 항목을 유지하는 것과 스누프가 데이터 항목에의 기록 요청을 지시하는 것과 같은 잠재적인 충돌을 초래한다. 반대로, 캐시 라인이 버퍼 기록 상태에 있는 데이터 항목을 유지하는 것과 외부 스누프가 데이터 항목에의 판독 요청을 지시하는 것은 잠재적으로 충돌하는 것으로 간주될 수 있다. 일 실시예에서, 그와 같은 액세스 요청과 특성 상태의 조합을 검출하기 위해, 스누프 논리는 그러한 충돌을 보고(report)하는 상태 레지스터뿐만 아니라, 모니터 및/또는 충돌 검출/보고용 논리와 같은 충돌 검출/보고 논리에 연결된다.
그러나, 조건 및 시나리오의 어떤 결합은 트랜잭션에 대해 무효한 것으로 간주될 수 있다. 트랜잭션의 비커미트(non-commit)에 대해 고려될 수 있는 요인의 예는 트랜잭션적으로(transactionally) 액세스된 메모리 위치의 충돌을 검출하고, 모니터 정보를 손실하고, 버퍼 데이터를 손실하고, 트랜잭션적으로 액세스된 데이터 항목과 연관된 메타데이터를 손실하고, 인터럽트, 링 전이(ring transition), 또는 명시적 사용자 명령어와 같은 다른 무효화 이벤트를 검출하는 것을 포함한다.
일 실시예에서, 프로세서(100)의 하드웨어는 트랜잭션 업데이트를 버퍼 방식으로 유지하는 것이다. 전술한 바와 같이, 트랜잭션 기록은 트랜잭션 커미트까지 전역적으로 가시화되지 않는다. 그러나, 트랜잭션 기록과 연관된 로컬 소프트웨어 스레드는 후속 트랜잭션 액세스에 대한 트랜잭션 업데이트에 액세스할 수 있다. 제1 예로서, 프로세서(100)에는 로컬 스레드에 대한 업데이트를 제공할 수 있지만 다른 외부 스레드에 대해서는 업데이트를 제공하지 않는 버퍼 업데이트를 유지하는 개별의 버퍼 구조가 제공된다.
대조적으로, 다른 예로서, 데이터 캐시(150)와 같은 캐시 메모리는 동일한 트랜잭션 기능을 제공하면서 업데이트를 버퍼하는데 이용된다. 여기서, 캐시(150)는 데이터 항목을 버퍼 일관성 상태로 유지할 수 있고, 하나의 경우에, MESIB 프로토콜을 구성하는 MESI(Modified Exclusive Shared Invalid) 프로토콜과 같은 캐시 일관성 프로토콜에 새로운 버퍼 일관성 상태가 추가된다. 데이터 항목이 버퍼 일관성 상태로 유지되는 버퍼 데이터 항목에 대한 로컬 요청에 따라, 캐시(150)는 내부 트랜잭션 순차적 순서화를 보장하기 위해 데이터 항목을 로컬 처리 소자에 제공한다. 그러나, 외부 액세스 요청에 응답하여, 트랜잭션적으로 업데이트된 데이터 항목이 커미트까지 전역적으로 가시화되지 않도록 보장하기 위해 누락(miss) 응답이 제공된다. 더욱이, 캐시(150)의 라인이 버퍼 일관성 상태로 유지되고 제거를 위해 선택되면, 버퍼 업데이트는 상위레벨의 캐시 메모리에 다시 기록되지 않고, 즉 버퍼 업데이트는 메모리 시스템을 통해 확산되지 않고, 즉 커미트 이후까지 전역적으로 가시화되지 않는다. 그 대신, 트랜잭션은 중단할 수 있거나 또는 제거된 라인은 데이터 캐시와 희생 캐시와 같은 상위레벨 캐시 메모리 사이의 추론적 구조에 저장될 수 있다. 커미트시, 버퍼 라인은 변경된 상태로 전이되어 데이터 항목이 전역적으로 가시화되게 한다.
내부 및 외부라는 용어는 대개 캐시를 공유하는 트랜잭션 또는 처리 소자의 실행과 연관된 스레드의 관점에 대한 것임을 주목하자. 예를 들면, 트랜잭션의 실행과 연관된 소프트웨어 스레드를 실행하는 제1 처리 소자는 로컬 스레드로 지칭된다. 따라서, 전술한 설명에서, 만일 제1 스레드에 의해 이전에 기록된 어드레스에의 저장 또는 그 어드레스로부터의 로드(이에 의해, 그 어드레스에 대한 캐시 라인을 버퍼 일관성 상태로 유지함)가 수신되는 경우, 캐시 라인의 버퍼 버전은 로컬 스레드이기 때문에 그 버퍼 버전은 제1 스레드에 제공된다. 대조적으로, 제2 스레드는 동일한 프로세서 내에서 다른 처리 소자에서 실행할 수 있지만, 버퍼 상태로 유지되는 캐시 라인을 담당하는 트랜잭션의 실행과 연관되지 않는 것으로, 즉 외부 스레드이며, 따라서, 제2 스레드로부터 그 어드레스로의 로드 또는 저장으로 캐시 라인의 버퍼 버전을 누락시키고, 캐시 라인의 비버퍼(unbuffered) 버전을 상위레벨 메모리로부터 검색하기 위해 일반적인 캐시 교체가 이용된다.
일 실시예에서, 프로세서(100)는 트랜잭션 실행을 지원할 뿐만 아니라, 잠재적으로 애플리케이션 코드(176)를 최적화하는 애플리케이션 코드(176)를 컴파일하는 컴파일러/최적화 코드(177)를 실행할 수 있다. 여기서, 컴파일러는 동작, 호출(calls), 기능, 및 트랜잭션의 실행을 가능하게 하는 다른 코드를 삽입할 수 있다.
컴파일러는 대개 소스 텍스트/코드를 타겟 텍스트/코드로 변환하는 프로그램 또는 프로그램 집합을 포함한다. 일반적으로, 컴파일러를 이용한 프로그램/애플리케이션 코드의 컴파일레이션(compilation)은 여러 단계 및 과정에서 상위레벨 프로그래밍 언어 코드를 하위레벨 기계 또는 어셈블리 언어 코드로 변환하도록 수행된다. 그러나, 간단한 컴파일레이션에는 단일 패스 컴파일러가 여전히 이용될 수 있다. 컴파일러는 어떤 공지의 컴파일레이션 기술이라도 이용하며 어휘(lexical) 분석, 전처리(preprocessing), 파싱(parsing), 시멘틱(semantic) 분석, 코드 생성, 코드 변환, 및 코드 최적화와 같은 모든 공지의 컴파일러 동작을 수행할 수 있다. 본 명세서에서 기술된 바와 같이, 트랜잭션 실행과 동적 코드 컴파일레이션을 결합하면 잠재적으로 필요한 메모리 순서화 보호책(safeguards)를 유지하면서 더 공격적인 최적화가 가능하게 된다.
대형 컴파일러는 대개 여러 단계를 포함하지만, 대개 이러한 단계 대부분은 다음과 같은 두 가지 일반적인 단계 내에 포함된다. 즉 (1) 프론트-엔드(front-end), 즉 일반적으로 구문(syntactic) 처리, 시멘틱 처리, 및 어떤 변환/최적화가 일어날 수 있는 경우, 및 (2) 백-엔드(back-end), 즉 일반적으로 분석, 변환, 최적화, 및 코드 생성이 일어나는 경우. 일부 컴파일러는 컴파일러의 프론트-엔드와 백 엔드 사이에서 도해(delineation)의 블러링(blurring)을 예시하는 미들 엔드(middle end)를 참조한다. 결과적으로, 삽입, 연관, 생성, 또는 컴파일러의 다른 동작은 전술한 단계 또는 과정뿐만 아니라, 컴파일러의 어떤 다른 공지의 단계 또는 과정에서도 언급될 수 있다. 예시적인 예로서, 컴파일러는 잠재적으로 컴파일레이션의 프론트-엔드 단계에서 호출/동작의 삽입과 그런 다음에 트랜잭션 메모리 변환 단계 동안 호출/동작의 하위레벨 코드로의 변환과 같이 하나 이상의 컴파일레이션 단계에서 트랜잭션 동작, 호출, 기능 등을 삽입한다. 동적 컴파일레이션 동안, 컴파일러 코드 또는 동적 최적화 코드는 그러한 동작/호출을 삽입할 뿐만 아니라, 런타임(runtime) 동안 실행 코드를 최적화할 수 있음을 주목하자. 특정한 예시적인 예로서, 이진 코드(이미 컴파일된 코드)는 런타임 동안 동적으로 최적화될 수 있다. 여기서, 프로그램 코드는 동적 최적화 코드, 이진 코드, 또는 이들의 조합을 포함할 수 있다.
그럼에도 불구하고, 컴파일러의 실행 환경 및 동적 또는 정적 특성에도 불구하고, 일 실시예에서, 컴파일러는 트랜잭션 실행을 가능하게 하고 및/또는 프로그램 코드 섹션을 최적화하는 프로그램 코드를 컴파일한다. 따라서, 일 실시예에서, 프로그램 코드의 실행에 대한 언급은 (1) 주 프로그램 코드를 컴파일하고, 트랜잭션 구조를 유지하고, 다른 트랜잭션 관련 동작을 수행하고, 또는 코드를 최적화하는 컴파일러 프로그램(들) 또는 최적화 코드 최적화기의 동적 또는 정적 실행, (2) 최적화된/컴파일된 애플리케이션 코드와 같은 트랜잭션 동작/호출을 포함하는 주 프로그램 코드의 실행, (3) 주 프로그램 코드와 연관된 라이브러리(libraries)와 같은 다른 프로그램 코드의 실행, 또는 (4) 이들의 조합을 말한다.
종종 소프트웨어 트랜잭션 메모리(STM) 시스템 내에서, 컴파일러는 어떤 동작, 호출, 및 컴파일되는 애플리케이션 코드와 긴밀히 연결된 다른 코드를 삽입하는데 이용될 것이며, 반면에 다른 동작, 호출, 기능, 및 코드는 라이브러리 내에 별도로 제공된다. 이는 잠재적으로 애플리케이션 코드를 다시 컴파일하지 않고도 라이브러리 분배기가 라이브러리를 최적화하고 업데이트하는 능력을 제공한다. 특정 예로서, 커미트 기능의 호출은 트랜잭션의 커미트 지점에서 애플리케이션 코드 내에 일렬로 삽입될 수 있으며, 반면에 커미트 기능은 업데이트가능한 라이브러리에 별도로 제공된다. 추가로, 특정 동작 및 호출을 놓을 위치의 선택은 잠재적으로 애플리케이션 코드의 효율에 영향을 미친다.
배경 섹션에서 전술한 바와 같이, 다중 스레드 시스템에서 코드의 공격적인 최적화는 잠재적으로 메모리 순서화 문제와 관련하여 위험하다. 그러나, 일 실시예에서, 메모리 순서화 보호책을 유지하면서 공격적인 최적화를 가능하게 하기 위해 코드 최적화는 트랜잭션 메모리 보호책과 결합된다. 여기서, 프로그램 코드에 최적화된 코드를 포함하는 원자 영역(atomic region)이 삽입되어, 최적화된 코드의 실행시 트랜잭션 보호책이 어떤 메모리 순서화 위반도 보장하지 않도록 할 수 있다. 결과적으로, 최적화된 코드는 공격적으로 최적화될 수 있고, 원자 영역은 그 영역을 커미트하지 않도록 하기 위해 확실하게 메모리 순서화 위반이 검출되도록 한다.
그러나, 원자 영역과 코드 최적화의 결합은 다른 변형으로도 이익을 얻을 수 있다. 따라서, 일 실시예에서, 프로세서(100)는 프로세서(100) 내에서의 하드웨어 자원의 유효성(availability)에 기초하여 프로그램 코드(176) 내의 트랜잭션을 동적으로 리사이징(resizing)할 수 있다. 전통적으로, 어느 원자 영역이든 완전히 커미트되거나 중단된다. 그러나, 이 예에서, 트랜잭션은 트랜잭션의 종료점(endpoint) 전에 커미트될 수 있다, 즉 트랜잭션(또는 트랜잭션 내 코드의 일부)의 실행을 완료하기에 적거나 불충분한 자원이 존재하는 경우 소규모 트랜잭션으로 동적으로 리사이즈될 수 있다. 예시적인 예로서, 캐시 메모리(150)가 시험적(tentative), 트랜잭션 정보를 연관된 트랜잭션 추적 정보와 함께 유지하는데 이용된다고 가정한다. 이러한 시나리오에서, 캐시(150)가 이용가능한 캐시 엔트리가 부족하거나 오버플로우(overflows)(제거를 위해 트랜잭션적으로 액세스된 라인을 선택하고 희생 캐시가 충만 상태임)하면, 실행중인 트랜잭션은 시험 정보가 전역적으로 가시화되도록 그 시점에서 커미트될 수 있다. 다음에, 커미트 지점부터 원래 트랜잭션의 종료점까지 새로운 트랜잭션이 재시작할 수 있다. 그 결과, 트랜잭션 하드웨어 자원, 즉 이 예에서 캐시 메모리(150)는 자유롭다. 그리고 트랜잭션은 트랜잭션 전체를 롤백(rolling back)하거나 트랜잭션을 UTM 시스템에서와 같은 소프트웨어로 확장하는 대신에 두 개의 소규모 하드웨어 트랜잭션을 완료할 수 있다.
따라서, 일 실시예에서, 프로세서(100)는 HTM, STM, 또는 UTM이든, 디코더, 캐시 메모리, 추론적 저장 구조, 추적 메카니즘, 저장 버퍼, 레지스터 파일, 체크포인트 저장 메카니즘, 및 트랜잭션의 실행을 지원하는 어떤 다른 공지의 하드웨어의 어떤 조합과 같은 트랜잭션 메모리 시스템을 지원하는 하드웨어를 포함한다. 더욱이, 프로세서(100)는 또한 그러한 하드웨어가 트랜잭션 실행을 지원하기 위해 이들의 유효성, 사용량(usage), 또는 표현을 추적하고, 제공하고, 또는 표시하도록 구성된 하드웨어/논리를 포함한다. 제1 예로서, 사용량 메트릭(metric)(하드웨어 사용량의 표현)은 캐시 메모리, 희생 캐시, 저장 버퍼, 또는 로드 버퍼와 같은 저장 구조에서 이용가능하거나, 또는 반대로 점유된 다수의 엔트리를 포함한다. 다른 예로서, 사용량 메트릭은 메모리의 오버플로우, 인터럽트 이벤트, 또는 엔트리의 제거와 같은 이벤트의 발생을 포함할 수 있다. 그러나, 실제적이든 추상적이든 어떠한 사용량 메트릭이라도 이용될 수 있다.
더 추상적인 사용량 메트릭의 일예로서, 카운터가 코드 내에서의 루프 반복(iterations) 횟수를 카운트한다고 가정하고, 카운터가 임계치(threshold)에 도달하면, 트랜잭션은 커미트된다. 여기서, 임계치는 불충분한 하드웨어 자원으로 인해 트랜잭션의 중단이 발생한 경우 임계치를 줄이는 것과 같이, 시간의 경과에 따른 코드 프로파일링(profiling)에 기초하여 동적으로 조정될 수 있다. 그 경우, 하드웨어 자원 또는 특정 이벤트의 정확한, 실제 사용량은 제공되지 않는다. 그러나, 카운터 임계치의 동적 조정을 통해, 하드웨어는 본질적으로 하드웨어 자원이 소진되기 전에, 즉 많은 자원 사용량으로 인해 중단, 또는 롤백이 수행되기 전에 루프 횟수를 추정한다. 결과적으로, 일 실시예에서, 그러한 하드웨어 추정은 코드 실행에 대한 자원 유효성을 추정하기 때문에 하드웨어 자원의 사용량 또는 그 사용량의 표현으로 언급된다.
일 실시예에서, 프로세서(100)의 하드웨어는 트랜잭션이 동적으로 리사이즈되는 때를 비동기적으로 결정할 수 있다. 예를 들면, 하드웨어 자원의 사용량이 많으면, 프로세서(100)는 트랜잭션을 커미트하고 프로세서(100)에서 실행하는 프로그램 코드(176)의 관점에서 다른 트랜잭션을 투명하게 재시작할 수 있다. 여기서, 트랜잭션을 포함하는 프로그램 코드(176)는 실행 논리(140)에 의해 실행된다. 그리고 프로그램 코드의 관점에서 트랜잭션은 끊김없이(seamlessly) 실행된다. 그러나, 하드웨어 관점에서, 저장 버퍼와 같은 자원은 사용량이 많았고(오버플로가 있었고), 그래서 하드웨어는 트랜잭션의 종료점 전에 트랜잭션을 커미트하였고, 그 커미트 지점에 제2 트랜잭션을 재시작하였고, 그런 다음에 트랜잭션의 원래 종료점에서 제2 트랜잭션을 커미트하였다.
또 다른 실시예에서, 트랜잭션의 동적 리사이징은 하드웨어 및 펌웨어/소프트웨어의 조합으로 수행된다. 여기서, 프로세서(100)는 트랜잭션 실행을 지원하고 그러한 자원의 사용량/유효성을 추적하는 하드웨어 자원을 포함한다. 그리고 프로그램 코드(176)로부터의 조건부 코드(conditional code)는 실행될 때 그러한 하드웨어 자원의 사용량/유효성에 기초하여 실행 논리(140)가 동적으로 리사이즈(종료점 전에 트랜잭션을 커미트)하도록 하는 것이다. 본질적으로, 자원 사용량 및 잠재적인 조건부 커미트의 체크는 즉 하드웨어에 의한 특정 명령의 실행과 독립적으로(비동기적으로) 하지 않고, 소프트웨어 명령어의 결과로서 동시에 수행된다.
예를 들면, 동적 컴파일러 코드의 일부일 수 있는 동적 최적화 코드(177)는 프로세서(100)의 런타임 동안 프로그램 코드(176)를 동적으로 컴파일하고/최적화하는 실행 논리(140/141)에 의해 실행된다. 그러한 컴파일레이션/최적화 동안, 원자 영역은 그 원자 영역 내에 조건부 커미트 코드와 함께 프로그램 코드(176)의 섹션에 삽입된다. 다음에, 실행 논리(140/141)는 코드(176)를 동적으로 최적화하고 런타임 동안 동적으로 최적화된 코드(176)를 실행한다. 구체적으로, 실행 논리(140/141)는 원자 영역 및 그 내부의 최적화된 코드를 실행한다. 디코드 단계(125)에서 조건부 커미트 코드를 인카운터(encountering)하고/디코드함에 응답하여, 하드웨어 자원의 사용량이 결정된다. 사용량/유효성이 이미 이전에 추적되었을 수 있지만, 조건부 커미트 코드에 응답하여 사용량이 보고되고/평가된다는 점을 주목하자. 하드웨어 자원의 유효성/사용량에 기초하여 원자 영역을 커미트할지가 판단될 수 있다.
일 실시예에서, 자원 사용량에 기초하여 커미트할지의 판단은 하드웨어에 의해 조건부 코드에 응답하여 수행된다. 다시 말하면, 하드웨어는 하드웨어 사용량을 독립적으로 평가하고 사용량이 조기(early) 커미트를 유발하기에 충분히 많은지를 판단할 수 있다. 일예로서, 조건부 커미트 코드는 디코더(125)에 의해 인식가능한 조건부 커미트 명령어를 포함한다. 조건부 커미트 명령어, 또는 영역 체크 명령어는 분기 타겟(branch target) 어드레스를 포함한다. 그리고 하드웨어는 디코드 논리(125)를 이용하여 조건부 커미트 명령어를 디코드함에 응답하여 하드웨어 자원 사용량이 너무 많은지, 또는 다르게 자원이 불충분하게 존재하는지를 판단한다. 만일 사용량이 충분히 많거나 또는 자원이 불충분하게 존재하는 경우, 실행 논리(140)는 실행을 분기 타겟 어드레스로 점프한다.
일 실시예에서, 하드웨어는 기설정된 알고리즘에 기초하여 사용량이 너무 많은지 또는 불충분한 자원이 존재하는지를 판단한다. 예를 들면, 하드웨어 자원이 저장 버퍼를 포함하는 경우, 사용량이 너무 많으면 사용되거나 오버플로우(어떤 저장 버퍼 엔트리도 이용가능하지 않음)가 발생하는 기설정된 수의 저장 버퍼 엔트리를 포함한다. 하드웨어는 또한 이전의 실행(코드 프로파일링)에 기초하여 코드의 예상 사용량을 추정하고, 그 추정치를 현재의 하드웨어 사용량과 함께 이용하여 조건부 커미트없이 실행을 지속하기에 충분한 자원이 존재하는지를 판단할 수 있다.
대안으로, 조건부 커미트 명령어는 또한 예상 사용량을 포함할 수 있다. 그리고 하드웨어는 예상 사용량과 하드웨어 사용량을 비교하여 불충분한 자원이 존재하는지를 판단한다. 예를 들면, 조건부 코드(176)가 프로그램 코드(176)의 원자 영역 내 루프에 삽입된다고 가정한다. 결과적으로, 조건부 코드는 루프의 매 반복시 실행된다. 여기서, 조건부 커미트 명령어는 루프의 반복 동안 이용되는 저장 버퍼 엔트리의 예상 수를 참조하며, 이는 코드에 의해 또는 코드의 동적 프로파일링에 의해 추정되는 바와 같이 접촉되는 고유 저장 버퍼 엔트리의 수에 기초할 수 있다. 디코드 논리(125)가 조건부 커미트 명령어를 디코드함에 응답하여, 엔트리의 예상 수는 프로세서(100)의 하드웨어에 의해 결정된 바와 같은 저장 버퍼 내에 이용가능한 엔트리의 수와 비교된다. 만일 예상 엔트리의 수가 이용가능한 엔트리의 수보다 큰 경우, 실행은 조건부 커미트 명령어에 의해 참조된 분기 타겟 어드레스로 점프한다. 분기 타겟 어드레스는 원자 영역의 조기 커미트를 수행하고 제2 원자 영역을 재시작하기 위해 프로그램 코드(176) 또는 라이브러리 코드와 같은 다른 코드 내에 어드레스 참조 코드를 포함할 수 있다.
또 다른 실시예에서, 소프트웨어는 하드웨어 사용량이 너무 많은 때, 또는 하드웨어 유효성이 너무 낮은 때를 결정한다. 이 예에서, 프로세서(100)는 레지스터와 같은 하드웨어 사용량의 표현(하드웨어 사용량 메트릭)을 유지하는 것인 저장 소자를 포함한다. 여기서, 조건부 코드는 사용량 메트릭을 로드/판독하고, 이를 평가하고, 조기 커미트가 수행될 것인지를 판단하는 동작을 포함한다. 만일 조기 커미트가 수행될 것이면, 조건부 코드는 실행 논리(140)에 의해 실행될 때 현재 트랜잭션을 커미트하고 다른 원자 영역을 시작할 수 있는 분기 타겟 어드레스로 실행을 점프하는 점프 동작을 포함한다.
하드웨어 및 소프트웨어는 유사한 평가를 수행할 수 있다는 점을 주목하자. 그러나, 하드웨어 해결책은 잠재적으로 하드웨어가 조기 커미트를 완벽하게 다루거나 또는 단지 조건부 커미트 명령어만을 수신하게 하는 것을 통해 코드 조밀도(compactness)를 가능하게 한다. 그러나, 소프트웨어가 평가를 수행하게 하면 조기 커미트를 수행할 때를 결정할 때 더 많은 융통성을 제공한다. 결과적으로, 하드웨어 및 소프트웨어 간의 조합의 어떤 변화도(gradient)는 하드웨어 사용량/유효성이 언제 너무 많거나 적은지를 구현예 및 원하는 이점에 기초하여 결정하는데 이용될 수 있다.
도 1은 다른 모듈, 유닛, 및/또는 논리를 표현한 예시적인 프로세서의 추상적인 논리도를 예시한다. 그러나, 본 명세서에서 기술된 방법 및 장치를 이용하는 프로세서가 예시된 유닛을 포함하지 않아도 된다는 것을 주목하자. 그리고, 프로세서는 도시된 유닛들 중 일부 또는 모두를 생략할 수 있다. 추가로, 도 1은 단지 두 개의 코어만을 도시하지만, 프로세서는 동일한 타입의 다중 코어와 같은 임의 수의 코어뿐만 아니라, 각각 타입이 다른 둘 초과의 코어를 포함할 수 있다.
도 1은 외부 메모리 제어기(제어기 허브(170))와의 인터페이스와 점대점 방식으로 연결된 프로세서의 일 실시예를 예시한다. 그러나, 많은 현재의 프로세서는 다중 코어뿐만 아니라, 공유 캐시 및 다른 인터페이스를 상호 연결하는 링 구성을 갖는 온 프로세서 메모리 인터페이스 모듈, 즉 온 칩 모듈을 포함하기 시작했다. 비록 예시되지는 않았지만, 일 실시예에서, 프로세서(100)는 링 상호 연결부 연결 코어, 캐시, 및 메모리 제어기 컴포넌트를 포함한다.
여기서, 물리적으로 분산된 캐시의 슬라이스를 관리하기 위해 캐싱 에이전트가 이용된다. 일예로서, 각 캐시 컴포넌트는 공동 배치된 코어, 즉 캐시 에이전트가 캐시의 분산형 슬라이스를 관리할 목적으로 연관된 코어의 캐시의 슬라이스를 관리하는 것이다. 많은 유사 캐시 에이전트는 링 상호 연결부에서 트래픽을 다루고 캐시 슬라이스와 인터페이스하고, 코어 에이전트/컴포넌트는 트래픽을 다루고 코어와 인터페이스하는 것이다. 추가로, 링 상호 연결부는 메모리 제어기 인터페이스 논리(MCIL) 및/또는 다른 제어기를 연결하여 다른 모듈, 그러한 메모리 및/또는 그래픽 프로세서와 인터페이스할 수 있다.
도 2a를 참조하면, 원자 영역을 이용하여 코드를 최적화하는 방법의 흐름도의 일 실시예가 도시되어 있다. 비록 도 2a에서 흐름의 블록들이 실질적으로 연속적으로 예시되어 있지만, 예시된 방법의 흐름은 부분적으로 또는 완전히 병렬로 수행될 뿐만 아니라, 어떠한 순서로도 수행될 수 있다. 예를 들면, 조건부 커미트 코드는 원자 영역의 시작 및 끝 명령어를 삽입하기 전에 삽입될 수 있다. 더욱이, 도시된 블록들은 반드시 수행되지 않아도 된다. 그리고 예시되지 않은 다른 블록들도 도시된 블록들과 함께 또는 그 블록들을 대신하여 수행될 수 있다.
블록(205)에서, 최적화 대상 프로그램 코드의 섹션을 식별한다. 전술한 바와 같이, 프로그램 코드는 컴파일러 코드, 최적화 코드, 애플리케이션 코드, 라이브러리 코드, 또는 어떤 다른 공지의 코드 공식 표시(formulation)를 지칭할 수 있다. 특정한 예시적인 예로서, 프로그램 코드는 프로세서(100)에서 실행될 코드, 이를 테면, 실행을 위해 준비된, 프로세서(100)에서 실행을 위해 동적으로 컴파일된, 및/또는 프로세서(100)에서 실행하도록 동적으로 최적화된 이진 코드를 포함한다. 또한, 코드(동작, 기능 호출 등)의 삽입 및 코드의 최적화는 컴파일러 및/또는 최적화 코드와 같은 프로그램 코드의 실행을 통해 수행된다. 일예로서, 최적화 코드는 프로세서(100)에서 프로그램 코드의 실행 직전에 프로그램 코드를 최적화하기 위해 런타임에서 프로세서(100) 상에서 동적으로 실행된다.
의사 코드 B: 최적화 대상 의사 코드 영역
일 실시예에서, 의사 코드 B로부터의 영역과 같은 최적화 대상 프로그램 코드의 섹션을 식별하는 것은 그 코드가 최적화 대상 프로그램 코드의 섹션/영역을 표시하는 것을 포함한다. 예를 들면, 특정 명령어 또는 경계설정(demarcation)은 최적화 대상 코드의 섹션을 표시하는데 이용되거나 또는 최적화로부터 이익을 얻을 것이다. 다른 옵션으로서, 프로그래머는 프로그램 코드의 섹션에 관한 힌트(hints)를 제공하며, 이러한 힌트는 최적화 코드에 의해 최적화 대상 섹션을 식별하는데 이용된다. 다른 실시예에서, 영역은 프로파일링 정보에 기초하여 식별/선택된다. 예를 들면, 프로그램 코드는 하드웨어, 프로세서에서 실행하는 소프트웨어, 펌웨어, 또는 이들의 조합에 의해 실행 동안 프로파일링된다. 여기서, 코드의 프로파일링은 힌트를 생성하거나 또는 원래의 소프트웨어 힌트를 수정할 뿐만 아니라, 최적화 대상 영역을 직접 식별한다. 또한, 코드의 섹션은 잠재적으로 특정 타입, 포맷, 또는 코드의 순서와 같은 특정 특성에 의해 식별된다. 특정한 예시적인 예로서, 코드 포함 루프는 잠재적인 최적화를 목표로 한다. 그리고 실행 동안 루프의 프로파일링은 루프 중 어느 것이 최적화되어야 할지를 결정한다. 또한, 만일 루프가 로드 및 저장과 같이 최적화될 특정 코드를 포함하는 경우, 그러한 코드를 포함하는 영역이 최적화를 위해 식별된다. 의사 코드 B로부터 알 수 있는 바와 같이, 영역은 루프 실행을 최적화하기 위해 루프를 벗어나 올라가고 내려갈 수 있는 로드 및 저장을 포함한다.
의사 코드 C: 시작 및 커미트 원자 영역 명령어가 삽입된 코드 영역
일 실시예에서, 최적화를 위해 식별된 코드의 섹션은 원자 영역으로 변환된다. 또는 코드의 섹션 중 적어도 일부가 원자 영역으로 변환된다. 여기서, 코드의 일부는 블록(210-215)에 도시된 바와 같이 시작 및 종료(커미트) 트랜잭션(원자 영역) 명령어에 의해 경계가 설정된다. 의사 코드 C로부터 알 수 있는 바와 같이, 영역 시작 및 영역 커미트 명령어는 각각 코드의 영역 전후에 삽입된다. 일 실시예에서, 코드는 다수의 진입(entries) 및 다수의 출구(exits)를 포함한다. 결과적으로, 시작 원자 영역 및 끝 원자 영역 명령어는 각각 각 진입점 및 각 출구점에서 삽입될 수 있다. 그러나, 영역이 원자임을 표시하는 어떠한 공지의 방법이라도 이용될 수 있다.
의사 코드 D: 조건부 커미트 코드가 삽입된 코드 영역
블록(220)에서, 조건부 커미트 지점을 결정한다. 다수의 조건부 커미트 지점이 최적화 대상 코드의 영역 내에 결정되고/할당될 수 있지만, 용이한 설명을 위해 단지 하나의 커미트 지점만이 아래에서 더욱 상세히 설명된다는 점을 주목하자. 조건부 커미트 지점을 결정하는 것은 조건부 커미트 지점들 사이에서 하드웨어 자원의 부족을 방지하기 위한 어떤 공지의 할당/결정 알고리즘에 기반할 수 있다. 제1 예로서, 조건부 커미트 지점이 루프 내에 삽입되어, 조건부 커미트 지점이 매 반복시 인카운터되도록 한다. 여기서, 조건부 커미트 지점은 루프의 처음에 오도록 결정된다. 다른 예로서, 코드의 동적 프로파일링은 종종 하드웨어 자원의 부족을 초래하는 실행 경로를 표시한다. 그러므로, 그러한 실행 경로에 조건부 커미트 지점이 할당되어 그러한 경로의 실행 동안 자원의 부족을 방지한다. 유사하게, 자원을 독점하거나 자원의 소비가 많은 것으로 알려진 실행 경로에 조건부 커미트 지점이 할당될 수 있다.
블록(225)에서, 조건부 커미트 코드는 적어도 조건부 커미트 지점에 삽입된다. 조건부 커미트 코드는 다음 커미트 지점까지를 통한 실행을 지원하기에 불충분한 하드웨어 자원이 존재한다고 판단된 경우 트랜잭션의 리사이즈, 즉 조기 커미트를 유발하기 위한 것이다. 도 2b를 간략히 참조하면, 조건부 커미트 코드를 삽입하는 흐름도의 일 실시예가 예시되어 있다. 흐름(226)에서, 조건부 커미트 명령어를 조건부 커미트 지점에 삽입한다. 의사 코드 D에서 알 수 있는 바와 같이, 일 실시예에서, 조건부 커미트 명령어는 원자 영역 내의 커미트 지점(L1)에 삽입된 영역 체크 명령어를 포함한다.
제1 예로서, 영역 체크 명령어 또는 조건부 분기 명령어와 같은 조건부 커미트 명령어는 분기 타겟 어드레스에 대한 참조를 포함한다. 그리고 다음 커미트 지점까지를 통한 실행을 지원하기에 불충분한 자원이 존재한다고 결정한 결과로서, 실행은 조건부 커미트 명령어에 응답하여 분기 타겟 어드레스로 점프한다. 여기서, 조건부 커미트 코드는 또한 분기 타겟 어드레스에서 커미트 코드를 포함할 수 있다. 본질적으로, 이 예에서, 조건부 커미트 명령어는 테스트/쿼리를 시작하여 충분한 자원이 존재하는지를 판단하기 위한 것이다. 그리고 분기 타겟 어드레스에서의 코드는 불충분한 자원이 존재할 경우 조기에 트랜잭션을 커미트하기 위한 것이다. 따라서, 블록(227)에서, 커미트 명령어를 분기 타겟 어드레스에 삽입한다.
의사 코드 D에서, (B4)에서 원자 영역의 출구(exit)/종료점(end point)에 제1 region_commit 명령어가 삽입되고, 반면에 블록(B6)에서 분기 타겟 어드레스 시점(L2)에 제2 region_commit가 삽입된다. 여기서, 만일 (L1)에서 region_check 명령어에 응답하여 불충분한 자원이 결정되면, 실행은 region_check 명령어에 의해 참조된 분기 타겟 어드레스(B6)로 점프한다. 트랜잭션 라이브러리 또는 구조적으로 인식된 커미트 명령어 내의 커미트 기능의 호출과 같은 region_commit 명령어는 원자 영역을 조기에(종료점(B4) 전에) 커미트하도록 실행된다. 또한 더욱이, 블록(228)(의사 코드 D로부터 (B7))에서, 제2 시작 원자 영역 명령어(region_start)를 region_commit 명령어 다음에 삽입한다. 결과적으로, 원자 영역의 실행은 (B3)(region_start)에서 시작한다. 그리고 (L1)에서 region_check 명령어에 의해 불충분한 자원이 결정되거나 또는 종료점(B4)이 인카운터될 때까지 지속한다. 그러나, 만일 (L1)에서 불충분한 하드웨어 자원이 결정되면, 원래 트랜잭션은 리사이즈된다, 즉 커미트 지점(L2, B6)에서 커미트된다. 다음에, (B7)에서 제2 원자 영역이 시작되고, 영역 실행은 (L1)에서 커미트 지점(B4) 또는 자원이 다시 한번 제한될 때까지 제2 트랜잭션으로서 지속된다. 따라서, 단일 원자 영역은 소규모 트랜잭션으로 동적으로 리사이즈되어 사전에 중단 또는 소프트웨어 트랜잭션 실행으로의 확장을 초래하는 하드웨어 자원의 부족을 방지할 수 있다.
조건부 커미트 명령어가 어떤 정보를 포함할 수 있다는 것을 주목하자. 예를 들면, 전술한 바와 같이, 일 실시예에서, 조건부 커미트 명령어는 의사 코드 D에서 코드 B2를 통한 루프 동안 이용되는 엔트리의 예상 수와 같은, 다음 커미트 지점까지의 예상 하드웨어 자원 사용량을 포함한다. 여기서, 이와 같은 예상 사용량은 루프 B2의 또 다른 반복 동안 실행을 지원하기에 불충한 자원이 존재하는지를 판단할 때 이용된다. 특정한 예시적인 예로서, 예상 사용량은 다음 커미트 지점까지 코드 영역의 실행에 응답하여 고유하게 접촉될 것으로 예상되는 저장 구조에서 다수의 엔트리를 포함한다.
추가로, 조건부 코드는 조건부 커미트 명령어로 제한되지 않는다. 예를 들면, 하드웨어가 사용량을 결정하고 그 사용량을 레지스터에 보관하는(도 5를 참조하여 더욱 상세히 설명됨) 실시예에서, 조건부 코드는 레지스터로부터 사용량을 판독/로드하고, 그 사용량을 평가하고, 다음에 의사 코드 D로부터의 B6 및 B7과 유사한 커미트 및 재시작 코드로 분기하는 점프 또는 분기 동작을 발행하는 동작을 포함할 수 있다. 다른 실시예에서, 소프트웨어는 하드웨어와 통신하거나 또는 하드웨어에 질의하는 대신, 하드웨어 사용량을 추정할 수 있다. 그러한 시나리오에서, 조건부 코드는 그러한 추정을 수행하는 코드를 포함한다. 예를 들면, 도 6을 참조하여 더욱 상세히 설명되는 카운트는 조건부 커미트를 수행하기 전에 루프의 반복 횟수를 제한하기 위해 소프트웨어의 실행을 통해 유지된다. 이 예에서, 카운트 유지를 위해 실행되는 코드는 조건부 커미트 코드로 간주될 수 있다.
블록(230)에서, 프로그램 코드의 섹션을 최적화한다. 의사 코드 E는 최적화 후의 코드의 일예를 도시한다.
의사 코드 E: 최적화 후의 코드 영역
비록 일부 실시예에서 원자 영역의 경계설정 및 조건부 커미트 코드의 삽입이 프로그램 코드를 최적화하는 것으로 간주되지만, 다른 실시예에서 트랜잭션 실행의 메모리 순서화 보호책에 의존하면서 실행 이익을 얻기 위해 프로그램 코드의 섹션이 추가로 최적화된다. 특정 예로서, 로드 및 저장은 부분 중복 로드 제거(PRLE) 및 부분 데드 저장 제거(PDSE)를 이용하여 루프를 벗어나 올라가고 내려간다. 의사 코드 E는 PRLE가 [r2] 및 [r2+4] 로드 올라가고 PDSE는 [r2+4] 저장 내려간 후의 원자 영역을 도시한다. 일 실시예에서, 추가의 메모리 순서화 규칙이 적용된다는 것을 주목하자. 여기서, 메모리 순서화 교차 영역을 위반하는 어떤 메모리 최적화도 시작하고 커미트하지 않도록 보장하는 것이 유리할 수 있다. 이에 대한 일예는 의사 코드 E에서 볼 수 있으며, 여기서 [r2+4] 저장은 (B6)에서 region_commit 전에 삽입되고 [r2] 및 [r2+4] 로드는 (B7)에서 region_start 명령어 후에 다시 삽입된다. 결과적으로, 만일 영역이 조기에 커미트되면(조건부 커미트 지점으로 리사이즈되면), [r2+4] 저장은 영역이 B6에서 커미트되기 전에 수행된다. 그리고 [r2] 및 [r2+4] 로드는 (B7)에서 새로운 트랜잭션의 재시작 후에 수행된다.
비록 위에서는 로드 및 저장 최적화가 검토되었지만, 어떤 공지의 코드 최적화 기술이라도 이용될 수 있다. 불완전 목록 및 단순히 예시적인 몇 가지 추가의 코드 최적화의 예는 루프 최적화, 소프트웨어 파이프라이닝, 데이터 흐름 최적화, 코드 생성 최적화, 바운드(bounds) 체킹 제거, 분기 오프셋 최적화, 데드(dead) 코드 제거, 및 점프 스레딩을 포함한다.
도 3a를 참조하면, 원자 코드를 동적으로 리사이징하는 흐름도의 일 실시예가 도시되어 있다. 블록(305)에서, 최적화된 프로그램 코드를 포함하는 트랜잭션(원자 영역)을 실행한다. 일 실시예에서, 최적화된 프로그램 코드는 런타임 동안 동적으로 최적화되며, 즉 동적 최적화 코드는 런타임에서 실행 시간에 딱 맞춰 "즉시(on the fly)" 프로그램 코드를 최적화하기 위해 실행된다. 종종 이러한 타입의 동적 최적화 또는 컴파일레이션은 정적 컴파일레이션 중과 같이 프로그램 전체를 알지 못하지만, 코드의 일부를 섹션 단위로 컴파일/최적화할 수 있다.
블록(310)에서, 영역 체크 명령어를 인카운터한다. 일 실시예에서, 영역 체크 명령어를 인카운터하는 것은 디코드 논리가 그 명령어를 디코드하는 것을 포함한다. 그러나, 인카운터하는 것은 그러한 명령어(또는 명령어의 동작)를 수신하거나 제공하는 파이프라인의 어떤 단계를 지칭할 수 있다. 예를 들면, 영역 체크 명령을 인카운터하는 것은 그 대신에 그 명령어와 연관된 동작을 위해 버퍼 내에 엔트리 할당, 그 동작의 디스패치, 그 명령어의 동작 또는 미세 동작을 수행하는 실행 유닛을 이용하는 명령어의 실제 실행, 또는 어떤 다른 공지의 파이프라인 단계를 지칭할 수 있다. 전술한 바와 같이, 일 실시예에서, 영역 체크 명령어는 하드웨어에 질의하는 프로세서의 디코더에 의해 인식가능한 ISA의 일부이다. 이러한 질의는 단순히 하드웨어에 사용량을 질의하는 로드일 수 있다. 그리고나서 소프트웨어는 하드웨어가 더 이상 관여하지 않고 충분한 자원이 이용가능한지를 판단한다. 대조적으로, 질의는 원자 영역의 실행을 지속하기에 충분한 자원이 존재하는지를 판단하게 하는 하드웨어 요청을 포함할 수 있다. 여기서, 질의는 하드웨어가 불충분한 자원이 존재하는지에 대한 조건문으로 분기하는 타겟 어드레스를 제공한다. 그러나, 질의는 하드웨어가 충분한 자원이 이용가능한지를 판단할 때 이용하는 예상 사용량을 영역 체크 명령어가 제공하는 경우 더 관여할 수 있다.
영역 체크 명령어에 응답하여, 블록(315)에서, 영역 체크 지점에서 하드웨어 유닛(들)이 다음 조건부 커미트 지점까지와 같은 트랜잭션의 영역을 완료하기에 충분한 자원을 갖는지를 판단한다. 충분한 하드웨어 자원이 존재하는지를 판단하는 것은 실제로 어떤 방식으로든 측정되거나 근사화될 수 있다. 제1 예로서, 하드웨어 자체가 사용량 레벨을 추적하고 및/또는 판단한다. 그리고 하드웨어, 펌웨어, 소프트웨어, 또는 이들의 조합은 그 사용량 레벨/메트릭이 트랜잭션의 영역을 완료하기에 충분한 유효성을 포함하는지를 판단한다. 그러나, 사용량 레벨이 순전히 소프트웨어의 지시로도 근사화되고/측정될 수 있음을 주목하자. 이 경우, 이러한 측정은 하드웨어 자신이 추적을 수행하는 전술한 예만큼 정확하지 않을 수 있지만, 측정을 지원하기 위해 추가적인 하드웨어 훅(hooks)이 추가되지 않아도 된다.
도 3b를 잠시 참조하면, 트랜잭션 영역의 실행을 완료하기에 충분한 자원이 존재하는지를 판단하는 흐름도의 일 실시예가 예시되어 있다. 흐름(350)에서, 하드웨어 유닛, 또는 다수의 하드웨어 유닛의 예상 사용량을 결정한다. 예상 사용량을 결정하기 위해 하드웨어, 펌웨어, 소프트웨어, 또는 이들의 조합이 이용될 수 있다.
하나의 시나리오에서, 트랜잭션을 포함하는 프로그램 코드의 실행이 프로파일링된다. 프로파일링 동안, 제한된 자원으로 인한 많은 중단, 중단없는 커미트, 및/또는 하드웨어 사용량이 추적된다. 그리고나서, 컴파일러와 같은 코드는 과거의 실행 프로파일에 기초하여 예상 사용량에 대한 힌트 또는 암시를 제공한다. 다른 시나리오에서, 예상 사용량은 추정치를 포함할 수 있다. 예를 들면, 만일 하드웨어 유닛이 저장 버퍼이면, 예상 사용량은 이러한 상황에서 코드 영역 내에 많은 고유 저장(새로운 저장 버퍼 엔트리에 할당할 가능성이 있는 저장 동작)을 포함한다. 본질적으로, 코드 내에서 저장 수는 코드 영역의 실행 동안 이용될 저장 버퍼 엔트리의 수를 추정한다. 그러나, 예상 사용량을 결정하는 것은 소프트웨어 프로파일링 또는 추정으로 한정되지 않는다. 그 대신, 하드웨어는 유사한 프로파일링 또는 추정을 수행할 뿐만 아니라, 예상 사용량을 결정하는 코드와 함께 동작할 수 있다.
유사하게, 흐름(355)에서, 하드웨어 유닛의 이용가능한 사용량을 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 조합으로 결정한다. 전술한 예를 계속 설명하면, 조건부 커미트 명령어가 32개의 엔트리 저장 버퍼의 예상 사용량이 추정 또는 과거의 프로파일링에 기초하여 10개의 저장 버퍼 엔트리를 포함한다는 것을 하드웨어에게 알려준다고 가정한다. 그러면, 저장 버퍼는 그의 헤드(head) 및 테일(tail) 포인터를 이용하여 20개의 엔트리가 현재 할당(12개의 엔트리가 이용가능)되어 있다고 판단할 수 있다. 이러한 판단으로부터, 흐름(360)에서 비교를 수행할 수 있다. 그리고 이용가능한 엔트리의 수가 예상 사용량보다 크기 때문에, 흐름(360)에서 실행을 지속하기에 충분한 자원이 존재한다고 판단한다. 대안으로, 만일 단지 9개의 엔트리만 이용가능하다면, 흐름(370)에서 충분한 자원이 존재하지 않는다고 판단한다.
그러나, 이러한 비교는 하드웨어 자원에서 정확하게 충분한 공간이 이용가능하다는 것을 보장하는 것으로 한정되지 않는다. 그 대신, 임계치를 이용하여 버퍼구역(buffer zone)이 제공될 수 있다. 예를 들면, 만일 사용량이 (임계치 초과로) 많거나 유효성이 (임계치 미만으로) 낮으면, 흐름(365, 370)에서 유사한 판단이 내려질 수 있다고 가정하자. 특정한 예시적인 예로서, 유효성을 위해 6개 엔트리의 버퍼 구역이 이용된다. 이 경우, 만일 이용될 예상 엔트리의 수가 10개이고 32개의 엔트리 버퍼에 20개가 이용된다면, 12개의 엔트리만 이용가능하다. 그러므로 만일 10개의 엔트리의 예상 사용량이 할당된다면, 단지 2개의 엔트리만 이용가능하게 될 것이다. 이용가능한 6개의 엔트리의 버퍼 구역이 이용되기 때문에, 흐름(370)에서 자원이 불충분하다고 판단된다. 그 대신, 만일 20개의 엔트리가 이용가능하다면(단지 12개의 엔트리만 이용된다면), 코드 영역에 대해 10개의 엔트리를 할당하면 여전히 10개의 엔트리가 이용가능할 것이기 때문에 (흐름(365)에서처럼) 충분한 자원이 존재한다.
추가로, 사용량 및 유효성은 스레드 우선순위(priority) 및 사용량을 고려할 수 있다. 여기서, 만일 다수의 스레드가 하드웨어 자원에의 액세스를 공유한다면, 자원은 분할되거나 완전히 공유될 수 있다. 결과적으로, 사용량 및 유효성은 예상 사용량과 비교하여 이러한 공유를 고려할 수 있으므로, 하나의 스레드는 하드웨어 자원을 독점하지 않는다(다른 스레드를 위한 충분한 유효성이 남겨지지 않음). 예를 들면, 만일 두 개의 스레드가 분할을 통해 캐시에의 액세스를 공유한다면, 하나의 스레드로부터의 트랜잭션은 캐시의 엔트리의 절반으로 제한될 수 있다. 그러므로, 사용량 및 유효성은 캐시 전체 대신 캐시의 절반과 관련된다.
전술한 설명은 저장 버퍼와 관련하여 그리고 간략히 캐시와 관련하여 이루어졌지만, 사용량/유효성은 저장 버퍼, 로드 버퍼, 캐시 메모리, 희생 캐시, 레지스터 파일, 큐, 실행 유닛, 또는 다른 공지의 프로세서 하드웨어와 같은 어떤 단일 또는 하드웨어 자원(들)의 조합과 관련하여 이루어질 수 있다. 예를 들면, 만일 하드웨어 자원이 캐시 메모리를 포함한다면, 예상 사용량은 접촉되는/이용되는 많은 캐시 라인을 포함할 수 있고, 사용량은 데이터를 유지하는 많은 캐시 라인 또는 공유되고, 배타적이고, 또는 변형된 많은 캐시 라인과 같은 일관성 상태에 있는/없는 많은 캐시 라인을 포함할 수 있으며, 유효성은 무효 일관성 상태와 같은 특정 일관성 상태에 있는/없는 많은 이용가능한 엔트리 또는 라인을 포함할 수 있다. 또한, 유효성/사용량은 유효성/사용량을 측정하는 하드웨어와 관련하여 추가로 설명되었다. 그러나, 전술한 바와 같이, 사용량/유효성은 소프트웨어, 하드웨어, 또는 이들의 조합에 의해 추정될 수 있을 뿐만 아니라, 직간접적으로 측정될 수 있다.
도 3a로 되돌아가면, 만일 영역을 완료하기에 충분한 자원이 존재한다고 판단되면, 실행 흐름은 흐름(305)으로 되돌아간다. 다시 말하면, 실행은 다음 조건부 커미트 지점까지 지속되며, 그 지점에서 하드웨어 자원의 평가가 다시 수행될 수 있다. 그러나, 만일 충분한 자원이 존재하지 않는 것으로 판단되면, 흐름(320)에서 트랜잭션의 종료 전에 트랜잭션을 커미트한다(동적으로 리사이즈한다). 그리고 일 실시예에서, 끊김없는(seamless) 실행을 제공하기 위해, 흐름(325)에서 원자 실행을 지속하기 위해 새로운 트랜잭션을 시작한다. 여기서, 단일의 대규모 트랜잭션은 본질적으로 실행 공간을 더 많이 제공하기 위해 가상 또는 시스템 메모리로 확장되지 않고 하드웨어에 의해 처리될 수 있는 소규모 트랜잭션들로 동적으로 갈라진다.
도 4를 참조하면, 트랜잭션의 실행을 지원하는 논리 블록의 일 실시예가 예시되어 있다. 도시된 메모리(405)는 오퍼레이팅 시스템(OS) 코드, 하이퍼바이저(hypervisor) 코드, 애플리케이션 코드, 동적 컴파일러 코드 등과 같은 프로그램 코드(410)를 보유하도록 구성된다. 일예로서, 프로그램 코드(410)는 도 2a 및 도 2b에 따라 (런타임 또는 부분적 프로그램 컴파일레이션에서) 동적으로 최적화되는 애플리케이션 코드의 적어도 일부를 포함한다. 런타임 동안, 트랜잭션이 동적 리사이징을 지원하는 코드를 갖는 최적화된 코드를 포함하는 코드(410)가 실행된다. 일 실시예에서, 프로그램 코드(410)는 전술한 바와 같이 영역 체크 명령어와 같은 조건부 커미트 명령어(415)를 포함한다.
여기서, 디코더(425)(프로세서의 디코드 논리)는 조건부 커미트 명령어(415)를 인식하도록 구성된다. 예를 들면, 디코드 논리(425)는 연산코드(opcode)(418)를 명령어 집합 구조(Instruction Set Architecture)의 일부로 식별하도록 설계되고 상호 연결된다. 결과적으로, 디코더(425)가 연산 코드(op code)(418)를 포함하는 조건부 명령어(415)를 디코드함에 응답하여 특정(사전 정의된) 동작/미세 동작이 논리(430), 하드웨어(435), 및 실행 논리(440)에 의해 수행될 것이다. 도시된 바와 같이, 조건부 명령어(415)는 예상 하드웨어 사용량(하드웨어 사용량 메트릭)(416) 및 분기 어드레스(420)에 대한 참조(기본 어드레스 및 코드 내에서 다른 타겟 어드레스와의 오프셋과 같은 어드레스 위치)를 포함한다.
디코더(425)가 조건부 명령어(415)를 디코드/인카운터하면, 일 실시예에서, 하드웨어는 조건부 커미트 명령어(415)에 의해 표시된 실행되는 하드웨어 사용량을 수용하기에 충분한 하드웨어 자원이 이용가능한지를 판단한다. 하드웨어 자원 사용량 및 하드웨어 자원의 예상 사용량을 수용하기에 충분한 자원이 이용가능한지를 판단하기 위해 어떤 공지의 방법 및 장치라도 이용될 수 있다. 그러나, 그러한 판단을 구현하는 일 실시예를 예시하는 특정 예가 아래에서 설명된다.
여기서, 디코더(425)가 조건부 명령어(415)를 수신하면, 프로세서 파이프라인 내의 디코더(425) 및 논리(430)에 의해 다른 동작/미세 동작이 수행된다. 예를 들면, 디코더(425)는 조건부 커미트 명령어(415)를 수행되는 동작의 추적과 같은 다수의 동작(미세 동작)으로 디코드할 수 있다. 전술한 설명으로부터 그러한 추적은 디코딩 후에 추적 캐시에 저장/내장될 수 있음을 주목하자. 그리고 예를 들면, 만일 동작 중 하나가 하드웨어 자원의 사용량 레벨을 표시하는 레지스터의 판독 또는 하드웨어(435)로부터의 로드를 포함하는 경우, 논리(430)는 로드 버퍼 내에 엔트를 할당하고 실행 논리(440)에서 로드의 실행을 스케줄링할 수 있다.
또한, 하드웨어(435)는 조건부 명령어(415)에 응답하여 제공되고, 결정되고, 또는 로드되는 그러한 사용량 레벨(435)을 결정하도록 구성된다. 전술한 바로부터, 사용량 레벨을 결정할 수 있는 트랜잭션 실행을 지원하는 하드웨어의 많은 예는 캐시 메모리, 추론적 캐시 메모리, 저장 버퍼, 로드 버퍼, 레지스터 파일, 추론적 레지스터 파일, 체크포인트 레지스터 파일 등을 포함한다. 결과적으로, 명령어(415)는 하나 이상의 하드웨어 자원에 대해 하나 이상의 예상 사용량 메트릭을 포함할 수 있다. 그리고 개별의 하드웨어 또는 자원 자신은 자신의 사용량 레벨을 추적하도록 구성된다. 예를 들면, 일 실시예에서, 캐시 메모리의 캐시 제어 논리는 캐시 메모리에 보유된 많은 무효 캐시 라인 또는 캐시 메모리 내에 있는 많은 이용가능한 라인과 같은 캐시 메모리의 사용량 레벨을 추적하도록 구성된다.
다음에, 예상 사용량 레벨을 결정된 하드웨어 사용량 레벨과 비교함에 기초하여, 조기 커미트(동적 리사이징)없이 트랜잭션의 실행을 지속하기에 충분한 자원이 존재하는지가 판단된다. 그리고 만일 조기 커미트가 수행된다면, 도시된 예에서 실행 논리(440)는 조건부 커미트 명령어(415)에 의해 제공된 바와 같이 분기 타겟 어드레스(420)로 점프한다. 전술한 바와 같이, 분기 타겟 어드레스는 실행될 때 트랜잭션을 조기에 커미트하고 다른 트랜잭션을 재시작하여 원자 실행을 지속하는 코드를 포함할 수 있다.
특정한 예시적인 예로서, 조건부 커미트 명령어(415)가 디코더(425)에 의해 수신된다고 가정한다. 그리고 조건부 명령어(415)는 10개의 저장 버퍼 엔트리 및 10개의 캐시 라인의 예상 사용량 메트릭(416)을 포함한다. 하드웨어(435)(트랜잭션 캐시 메모리 및 저장 버퍼)는 자신의 사용량 레벨을 결정한다. 이러한 하드웨어 엔티티(entities)가 사용량을 지속적으로 추적할 수 있고, 이들이 조건부 커미트 명령어(415)에 의한 질의/요청시 그러한 사용량을 제공한다는 것을 주목하자. 또는, 그러한 논리는 실제로 조건부 커미트 명령어(415)로부터 요청이 수신될 때 사용량을 결정할 수 있다. 어떤 식으로든, 하드웨어 사용량 레벨/메트릭(436)은 실행 논리(440)에 의한 동작을 위한 정보를 보유한 레지스터와 같은 저장 소자로 제공된다. 다음에, 하드웨어 사용량 레벨(436) 및 예상 하드웨어 메트릭(416)을 비교하여 조기 커미트없이 실행을 지속하기에 충분한 자원이 이용가능한지를 판단한다. 전술한 바로부터, 이러한 비교는 버퍼 구역, 임계치, 또는 직접적인 비교를 이용하여 설계자의 어떤 알고리즘 선호도에 기초하여 충분한 자원이 이용가능한지를 판단할 수 있다.
여기서, 저장 버퍼가 32개의 저장 버퍼 엔트리 중 16개(16개의 엔트리가 이용가능함)를 이용하고 트랜잭션 캐시가 트랜잭션적으로 액세스된 것으로 표시된 64개의 엔트리 중 60개를 갖고 있다고 가정한다(트랜잭션은 이미 이러한 라인을 액세스하였고 그러한 라인을 교체하면 정보의 손실을 초래하여 중단 또는 소프트웨어 트랜잭션 실행, 즉 4개의 이용가능한 엔트리로의 확장을 유발할 것이다). 그리고 설계자의 알고리즘이 예상 엔트리 수를 고려한 후 4개의 엔트리가 이용가능해야 한다고 명시한다고 가정한다. 그 경우, 예상 저장 버퍼 엔트리가 10개이고 이용가능한 엔트리가 16개이면, 저장 버퍼에는 다음 조건부 커미트 지점까지 원자 실행을 수용하기에 충분한 이용가능한 공간이 존재한다. 그러나, 트랜잭션적으로 액세스된 것으로 표시되지 않은 캐시 엔트리는 단지 4개뿐이고, 그래서 트랜잭션 캐시 공간은 충분하지 않다. 결과적으로, 점프 실행 유닛과 같은 실행 논리(440)는 분기 타겟 어드레스(420)로 점프하여 트랜잭션을 조기에 커미트(트랜잭션을 동적으로 축소)하고 다른 트랜잭션을 재시작하는 코드를 패치하고, 디코드하고, 실행한다.
전술한 예들은 예상 하드웨어 사용량 메트릭 및 분기 타겟 어드레스를 포함하는 조건부 커미트 명령어와 관련하여 설명되었음을 주목하자. 그러나, 조건부 커미트 명령어는 하드웨어가 코드의 실행을 지원하기에 하드웨어 유효성이 충분한지를 평가하거나 추정하도록 하는 어떤 명령어라도 포함할 수 있다. 예를 들면, 조건부 커미트 명령어는 단지 조건부 점프 명령어일 수 있으며, 이 경우 하드웨어는 트랜잭션이 커미트되어야 할지를 판단하는 코드의 과거 하드웨어 프로파일링에 대한 현재의 사용량 레벨을 평가한다. 그리고 그러한 평가를 내린 후 하드웨어는 조건부 커미트 명령어에 의해 제공된 분기 어드레스로 점프할 수 있다.
또 다른 실시예에서, 하드웨어는 비동기적으로(특정한 조건부 커미트 명령어에 맞춰지거나 또는 그러한 명령어에 응답하지 않고) 트랜잭션이 커미트되어야 한다고 판단할 수 있음을 주목하자. 여기서, 프로세서가 트랜잭션 코드를 실행하고 오버플로 이벤트(이미 트랜잭션적으로 표시된 엔트리의 제거와 같이 하드웨어 자원에 공간이 남아 있지 않음을 표시하는 이벤트)가 발생하면, 하드웨어는 코드가 더 잘 알지 못해도 하드웨어 트랜잭션을 커미트하고 새로운 트랜잭션을 재시작할 수 있다.
다음에 도 5를 참조하면, 트랜잭션의 동적 리사이징을 지원하는 하드웨어의 또 다른 실시예가 예시되어 있다. (도 4와 관련하여) 앞에서, 결정된 하드웨어 사용량 레벨/메트릭은 실행 논리(440)에 의한 동작에 이용되는 레지스터와 같은 저장 소자에 보관될 수 있다고 설명하였다. 그러한 예와 유사하게, 결정된 하드웨어 사용량 레벨/메트릭은 레지스터(550)와 같은 저장 소자에 유사하게 로드될 수 있다. 그러나, 일 실시예에서, 모델 특정 레지스터(MSR)를 포함할 수 있는 레지스터(550)는 사용자 레벨 애플리케이션 코드와 같이 하드웨어 자원 유효성의 평가를 수행하는 프로그램 코드에 의해 액세스가능하게(그 코드에 노출되도록) 구성된다. 앞의 예에서, 하드웨어는 소프트웨어로부터 예상된 사용량에 기초하여 평가를 수행하였다. 그러나 여기서, 소프트웨어는 하드웨어(MSR(550))에 질의하여 하나 이상의 하드웨어 자원의 사용량 레벨을 수신할 수 있다. 다음에, 소프트웨어는 자신의 지침에 기초하여 다음 커미트 지점까지 원자 실행을 지속하기에 충분한 자원이 존재하는지를 판단할 수 있다. 이러한 처리는 사용자가 하드웨어를 얼마나 사용할 수 있는지를 판단하게 해주기 때문에 사용자에게 더 많은 융통성을 제공할 수 있다. 결과적으로, 프로세서 설계자는 프로세서가 더 많은 제어를 유지해야 하는지 또는 사용자가 그러한 판단을 할 수 있는지를 선택할 수 있다.
특정한 예시적인 예로서, 프로세서가 잠재적으로 동적 리사이징을 위해 삽입된/최적화된 트랜잭션을 포함하는 프로그램 코드(510)를 최적화하고 실행하는 동적 컴파일러 코드를 실행한다고 가정한다. 여기서, 프로세서의 스레드(미도시)의 명령어 포인터에 기반한 프로세서의 패치 논리(역시 미도시)는 로드 동작(515)을 패치한다. 로드 버퍼 엔트리는 로드 버퍼 내 논리(530)/하드웨어(535)에 할당된다. 이러한 로드는 논리(530)에 의해 스케줄링되고 디스패치될 뿐만 아니라, 실행 논리(540)에 의해 실행되어 하드웨어(535)로부터 결정된 사용량 레벨(536)(캐시, 버퍼, 또는 레지스터 파일과 같은 트랜잭션 실행을 지원하는 자원)을 로드한다. 로드 또는 선행(preceding) 명령어는 동기적으로 하드웨어(535)가 사용량을 판단하고 및/또는 그 사용량을 MSR(550)에 보관하도록 할 수 있음을 주목하자. 대안으로, 하드웨어(535)는 (이벤트에 기초하여 또는 주기적 특성으로) 그 사용량 레벨을 MSR(550)에 비동기적으로 보관할 수 있다. 어떤 식으로든, 사용량 레벨은 동작(516)에 의해 판독되고 평가된다.
예를 들면, 동작(516)은 소프트웨어에 의해 정의된 예상 사용량 레벨 또는 다른 임계치 레벨에 따라 로드된, 하드웨어 사용량 레벨을 평가하는 불린(Boolean) 표현식을 포함할 수 있다. 실제로, 불린 표현식은 바로 아래에서 더욱 상세히 설명되는 조건문(conditional statement) 및/또는 점프 명령어(517)의 일부일 수 있다. 여기서, 만일 하드웨어 사용량 레벨의 평가가 트랜잭션이 조기에 커미트되어야 한다고 나타내면, 디코더(525)에 의해 연산코드(opcode)(517o)를 통해 인식된 바와 같은 점프 명령어(517)는 전술한 바와 같이 목적지 어드레스(520)로 분기하도록 실행되어, 트랜잭션을 커미트하고 다른 트랜잭션을 재시작한다.
이제 도 6을 참조하면, 트랜잭션의 동적 리사이징을 지원하는 하드웨어의 또 다른 실시예가 예시되어 있다. 일 실시예에서, 카운터(650)는 루프(615)의 실행을 통한 반복 횟수를 카운트하도록 구성된다. 카운터(650)는 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 조합으로 구현될 수 있음을 주목하자. 예를 들면, 카운터(650)는 어떤 값을 보유하는 레지스터일 수 있다. 그리고 소프트웨어 코드는 루프를 통한 매 반복시 현재 값을 판독하고, 현재 값을 새로운 값으로 변경(증가/감소)하며, 새로운 값을 레지스터에 저장한다. 본질적으로, 소프트웨어는 카운터를 유지한다. 그러나, 하드웨어 카운터는 루프의 매 반복의 처음 또는 끝에서도 역시 증가/감소할 수 있다.
일 실시예에서, 카운터(650)의 카운터 값은 트랜잭션의 조기 커미트가 발생하는 때를 결정하는데 사용된다. 예를 들면, 카운터(650)는 루프의 반복 횟수가 임계치에 도달할 때까지 이를 카운트한다. 임계치에 도달할 때, 카운터는 만기가 되거나 오버플로우하여 조기 커미트를 유발한다. 카운터가 0에서 시작하여 임계치에 도달(오버플로잉)할 때까지 카운트 업하거나 또는 어떤 값에서 시작하여 0으로 카운트 다운(만기가 되거나 언더플로잉)할 수 있다.
임계치 값(또는 0으로 감소하는 카운터의 시작값)은 어떠한 방식으로든 결정될 수 있다. 임계치 값은 하드웨어에 포함되거나 소프트웨어에 의해 설정된 정적의 사전 정의된 값일 수 있다. 여기서, 정적의 사전 정의된 값은 프로세서에 포함된 하드웨어의 타입 또는 크기뿐만 아니라, 실행되는 코드의 타입 또는 크기와 같은 어떤 알려진 특성에 기초하여 하드웨어 또는 소프트웨어에 의해 지능적으로 선택될 수 있다. 또는 정적의 사전 정의된 값은 루프의 반복 횟수를 롤백을 상당히 감소시키기에 충분히 작은 수로 제한하는 보수적인(conservative) 값과 같이 여유있게 선택된다.
대안의 실시예에서, 임계치(시작값)는 동적으로 선택되고 변경이 가능하다. 여기서, 하드웨어, 소프트웨어, 또는 이들의 조합은 어떤 특성(들)에 기초하여 초기 시작값(임계치)을 선택할 수 있다. 예를 들면, 다수의 이용가능한 캐시 라인 또는 저장 버퍼 엔트리(예컨대, 32개)는 코드의 단일 루프 반복에서 저장의 총수(예컨대, 8)로 나누어 임계치(예컨대, 4)를 결정한다. 일 실시예에서, 다수의 저장의 추정치는 다수의 저장이 단지 단일 캐시 라인만을 접촉할 수 있기 때문에 상당히 보수적이다. 그러므로, 좀 더 공격적인 초기값도 사용될 수 있다. 다른 예로서, 코드 또는 하드웨어는 코드 크기/타입, 하드웨어 유닛 크기/타입, 또는 루프의 실행을 보장하는 다른 공지의 요인도 완료하기에 충분한 자원을 갖는 것을 보장하는 공격적이거나 보수적인 값을 선택한다. 더욱이, 하드웨어 또는 소프트웨어는 코드를 프로파일하고 시작/임계치 값을 제공할 수 있다. 여기서, 임계치 수를 포함하는 소프트웨어 힌트는 루프의 실행이 개시하기 전에 제공되고, 카운터는 그 임계치 수에 기초하여 설정된다. 또는 하드웨어는 코드를 유사하게 프로파일할 수 있고 코드 영역의 프로파일 이력에 기초하여 카운터를 설정할 수 있다.
일 실시예에서, 카운터를 초기화한 후, 임계치(시작값)는 동적으로 수정, 이를 테면, 루프의 실행 분석(코드 프로파일링 또는 롤백 판단)에 기초하여 조정된다. 본질적으로 일 실시예에서, 카운터(650)는 제한된 하드웨어 자원으로 인해 롤백 또는 허용가능한 수의 롤백이 발생하기 전에 루프(615)의 반복이 실행할 수 있는 횟수를 추정하는데 사용된다. 따라서, 만일 허용가능한 수 초과의 롤백이 발생하면, 이전의 임계치를 감소시켜 커미트가 발생하기 전에 반복 횟수를 줄여 롤백의 수를 감소시킨다. 이러한 시나리오에서, 너무 빈번한 롤백은 실행 시간을 낭비하고 잠재적으로 지연을 초래한다. 그러나, 임계치가 너무 보수적이지(비본질적으로 여전히 이용가능한 자원이 많아 원자 실행이 비효율적인 경우 조기에 트랜잭션을 커미트 하지) 않도록 보장하기 위해, 일 실시예에서 임계치는 롤백이 발생할 때까지 증가된다. 단일, 여러 번의, 또는 지수적인 증가로 증가/감소가 일어날 수 있음을 주목하자. 일예로서, 시작값이 초기에 63으로 설정(즉, 커미트 전에 64번의 반복이 허용)된다고 가정한다. 만일 하드웨어 제약조건으로 인해 많은 중단/롤백이 검출된 경우, 임계치는 62로 감소된다. 이후의 롤백시, 실행을 효율적으로 완료하게 하는 균형된 시작값이 결정될 때까지 임계치는 2(60), 4(56), 8(48) 등으로 더 감소된다.
도 6의 설명이 조건부 커미트 명령어와 특별히 관련하지 않고 루프 반복 횟수를 카운트하는 카운트와 관련하여 이루어졌음을 주목하자. 여기서, 카운터가 임계치에 도달하면 하드웨어를 통해 비동기적으로 커미트를 시작할 수 있다. 그러나, 다른 실시에에서, 카운터(650)는 도 5 및 도 6으로부터의 조건부 커미트 코드와 함께 동작한다. 일예로서, 카운터는 이용가능한 하드웨어 자원의 양을 결정하고/추정하는 하드웨어 메카니즘일 수 있으며 조건부 커미트 명령어는 하드웨어 카운터에 기초하여 커미트 코드로의 점프를 유발한다. 예를 들면, 카운터(650)가 9(조건부 커미트가 발생해야 하기 전에 10번의 반복 허용)로 초기화된다고 가정한다. 그리고 루프(615)의 매 반복시, 조건부 점프 명령어와 같은 조건부 커미트 명령어가 실행되어 카운터가 만료된(0에 도달한) 경우 분기 타겟 어드레스로 점프한다. 10번의 반복이 완료되고 조건부 점프가 실행되면, 실행 흐름은 실행중인 원자 영역의 커미트먼트(commitment)를 위해 타겟 어드레스로 점프한다.
비록 카운터가 개별의 하드웨어 유닛의 정확한 특정 사용량 레벨을 측정하지 않더라도, 카운터는 잠재적으로 좀 더 모두를 아우러서(encompassing) 추정한다. 전술한 바와 같이, 임계치의 동적 조정을 통해, 하드웨어 제한사항에 따라 롤백을 감소시키는 최적의 반복 횟수를 구할 수 있다. 따라서, 만일 이전에 식별되지 않은 어떤 하드웨어 제한사항이 롤백을 유발하면, 동적 카운터 임계치는 이를 파악할 수 있고, 반면에 설계자 또는 프로그래머에 의한 개별의 식별은 그러한 식별되지 않은 원인을 무시할 수 있다. 더욱이, 카운터는 또한 특정 하드웨어 유닛의 사용량 측정과 함께 이용되어 두 유닛의 레벨 입도뿐만 아니라, 과성취(overreaching), 전역 입도(global granularity)를 제공할 수 있다.
앞의 설명은 주로 하드웨어 자원이 소진되기 전에 트랜잭션을 조건부로 커미트하는데 초점을 맞추었다. 또는 예상 사용량에 대해 하드웨어 사용량을 결정하는 것은 실행을 지원하기에 충분한 자원이 이용가능한지를 판단하기 위한 것이다. 그러나, 일부 실시예에서, 원자 영역을 통해 실행하는 것이 유리할 수 있다. 그리고 원자 영역을 주기적으로(사용자 명령어, 이벤트, 또는 하드웨어 정의 시간에 따라) 체크포인트(checkpoint)하는 것이 유리할 수 있다. 그러므로, 실제 하드웨어 제한사항, 예외사항(exception), 인터럽트, 또는 다른 장애(fault)를 만날 때, 원자 영역은 최근의 잠정(interim) 체크포인트로 롤백되고 자유로운 자원으로 커미트될 수 있다. 본질적으로, 전방 추정 및 트랜잭션을 앞서서 커미팅하는 대신, 일 실시예에서, 트랜잭션은 일반적으로 트랜잭션 전체의 중단 및 재시작을 요구하는 실제 자원 제한사항을 만날 때에만 리사이즈된다. 이러한 처리는 트랜잭션 내에서 롤백이 발생한 경우 이것이 단지 롤백되는 허용가능한 실행량이라는 것을 보장하는 다수의 체크포인트를 수행함으로써 성취된다.
도 7a를 참조하면, 트랜잭션 내에서 추론적 체크포인트를 제공하는 것을 포함하는 코드 최적화 방법의 흐름도의 일 실시예가 도시되어 있다. 블록(705)에서, 최적화 대상 프로그램 코드의 섹션을 식별한다. 도 2a의 설명과 유사하게, 코드의 섹션/영역은 섹션에 관한 사용자 식별/힌트, 프로그램 분석, 코드 프로파일링, 코드 특성(특정 형태, 형식, 순서, 또는 영역의 특성, 즉 루프 또는 저장 횟수), 또는 최적화 대상 코드 영역을 식별하는 다른 공지의 방법에 따라 식별될 수 있다. 일예에서, 코드는 이진 코드를 포함한다. 그리고 이진 코드의 실행 동안, 이진 코드는 동적으로 최적화될 것이다. 결과적으로, 최적화 실행 동안, 루프는 이진 코드에서 인카운터된다. 그러므로, 루프는 롤백이 실행 손실을 크게 하지 않도록 체크포인트 간의 간격이 확실하게 충분히 작도록 최적(추론적 체크포인트 삽입)으로 결정된다. 일예로서, 아래의 의사 코드 F는 최적화 대상 코드 영역의 일예를 예시한다.
의사 코드 F: 최적화 대상 코드 영역
또한 도 2a의 설명과 유사하게, 흐름(710, 715)에서 코드의 영역을 경계설정(섹션의 처음에 시작 원자 영역 명령어 그리고 섹션의 끝에 종료 원자 영역 명령어를 삽입)한다. 그리고 전술한 바와 같이, 코드 영역은 다수의 진입 및 다수의 출구를 포함할 수 있다. 블록(720)에서, 프로그램 코드 내의 추론적 체크포인트 위치를 결정한다. 최적화 대상 코드의 영역 내에 다수의 추론적 체크포인트가 결정되고/할당될 수 있지만, 용이한 설명을 위해, 단지 하나의 체크포인트만 아래에서 더욱 상세히 설명된다는 점을 주목하자.
추론적 체크포인트를 결정하는 것은 원자 영역 내에 롤백 효과를 최소화하는 어떤 공지의 할당/결정 알고리즘을 기반으로 할 수 있다. 제1 예로서, 추론적 체크포인트가 매 반복시 인카운터되도록 루프 내에 추론적 체크포인트가 삽입된다. 여기서, 추론적 체크포인트는 루프의 처음에 또는 루프의 에지에 존재하도록 결정될 수 있다. 다른 예로서, 코드의 동적 프로파일링은 종종 하드웨어 자원이 부족하거나 또는 명령어 카운트가 큰 실행 경로를 표시한다. 그러므로, 추론적 체크포인트가 그러한 실행 경로에 할당되어 긴 실행 경로 내에서 중단으로 인해 원자 영역 전체를 롤백하는 것을 방지한다. 유사하게, 독점하거나 소비가 많은 자원인 것으로 알려진 실행 경로에는 추론적 체크포인트가 할당될 수 있다. 본질적으로, 전체 트랜잭션 및 전체 트랜잭션의 연관된 롤백 전에 존재하는 종래 기술의 체크포인트 대신, 트랜잭션(로컬, 내부, 또는 일시적 체크포인트) 내에 체크포인트를 이용하여 (실행 낭비가 적은) 소규모 롤백이 수행된다. 그 결과, 더 큰 영역이 최적화될 수 있다. 그리고 만일 자원 제한사항이 인카운터되면, 소규모 롤백이 수행된다. 또한, 롤백 시점에, 트랜잭션은 잠재적으로 커미트되고, 궁극적인 장애가 처리되고, 다른 트랜잭션이 시작된다.
흐름(725)에서, 추론적 체크포인트 코드를 추론적 체크포인트 위치에 삽입한다. 추론적 체크포인트 코드는 메모리, 캐시 메모리, 및/또는 레지스터 파일과 같은 추론적 하드웨어 자원을 체크포인트하기 위한 것이다. 그리고 일 실시예에서, 추론적 체크포인트 코드는 또한 이후의 중단 상태에 따라 하드웨어 자원을 체크포인트로 복원하는 코드를 포함할 수 있다. 도 7b를 간략히 참조하면, 추론적 체코포인트 코드를 삽입하는 흐름도의 일 실시예가 예시되어 있다. 의사 코드 G는 또한 추론적 체크포인트 코드의 삽입 후 코드의 예시적인 예를 도시한다.
의사 코드 G: 추론적 체크포인트 코드가 삽입된 후의 코드 영역
흐름(726)에서, 추론적 체크포인트 명령어/동작((B5)에서 L1)을 추론적 체크포인트(B2, B5의 루프 백 에지)에 삽입한다. 일 실시예에서, 추론적 체크포인트 명령어는 추론적 하드웨어 자원의 체크포인트(현재 스냅샷(snapshot))를 개시하는 어떤 명령어를 포함한다. 예를 들면, 추론적 체크포인트 명령어는 프로세서의 디코더에 의해 인식가능하다. 그리고 일단 디코드되고, 스케줄링되고, 실행되면, 추론적 레지스터 파일, 저장 버퍼, 또는 둘 다를 체크포인트의 추론적 레지스터 파일 또는 추론적 캐시와 같은 체크포인트 저장 구조로 체크포인트되도록 한다.
더욱이, 일 실시예에서, 추론적 체크포인트 코드는 또한 잠재적으로 현재의 롤백을 유발시킨 동일한 롤백 상황을 방지하는 어떤 액션을 수행하기 위한 어떤 다른 코드를 포함한다. 예를 들면, 만일 제한된 하드웨어 자원으로 인해 롤백이 발생한 경우, 완화 액션이 취해지지 않으면, 그때마다 동일한 하드웨어 제한사항이 인카운터되어, 전방으로 진행하지 못할 수 있다.
일예로서, 의사 코드 H에서 좌측의 코드가 최적화된다고 가정한다.
의사 코드 H: 최적화 대상 코드 영역
여기서, 최적화된 코드 내에서 롤백을 다루는 방법에 대해 다수의 시나리오가 존재한다. 제1 예로서, 아래의 의사 코드 I에 예시된 바와 같이, 추론적 체크포인트 명령어는 정상 루프 실행 또는 추론적 체크포인트로의 롤백 후의 재실행 사이를 구별할 수 있는 조건부(분기) 명령어와 쌍을 이룬다. 분기 명령어는 실행될 때 이전에 체크포인트된 상태로 롤백하는 어떤 공지의 방식으로 롤백을 다루는 다른 실행 경로로 점프한다.
의사 코드 I: 분기 명령어와 추론적 체크포인트 명령어의 페어링(Pairing)
아래의 의사 코드 J에 도시된 또 다른 시나리오에서, 추론적 체크포인트 명령어는 일부 실시예에서 전술한 단일 체크포인트 및 분기 명령어로의 분기 명령어와 결합된다.
의사 코드 J: 분기와 추론적 체크포인트 명령어의 결합
의사 코드 G의 설명을 참조하면, 일 실시예에서, 추론적 체크포인트 코드는 또한 실행될 때 체크포인트 저장 구조로부터 최신의 체크포인트의 정확한 상태를 복원 또는 복구하는 (롤백, 복원, 재구성, 복구 등으로 지칭될 수 있는) 수리(fix-up) 코드(B5)를 포함한다. 일부 실시예에서, 전술한 다른 시나리오는 또한 추론적 체크포인트 코드 및/또는 수리 코드로 간주될 수 있다. 또한 여기서, 의사 코드 G에 도시된 바와 같이, 수리 코드는 또한 트랜잭션/원자 영역을 커미트하는 커미트 코드(B6)를 포함할 수 있다. 본질적으로, 추론적 체크포인트 코드는 추론적 하드웨어를 체크포인트한다. 그리고 추론적 하드웨어의 부족시 또는 중단을 유발하는 이벤트(인터럽트, 동적 단언(assertion), 메모리 에일리어스(alias) 체크 등)를 만날 때, 체크포인트 코드는 추론적 하드웨어의 정확한 상태를 복구한다. 추가로, 재실행 및 연속적인 실행을 위한 추론적 하드웨어를 확보하기 위해, 트랜잭션은 선택적으로 커미트된다. 이러한 설명으로부터, 수리 코드를 도출하는 것은 여러 방식으로 수행될 수 있음을 알 수 있다. 예로서, 수리 고드는 (1) 체크포인트 저장 구조가 추론적 하드웨어를 체크포인트하기에 충분한 공간을 갖지 않는 경우 추론적 체크포인트 동작의 실행, (2) 추론적 하드웨어가 수용할 수 없는 추론적 동작의 실행, (3) 추론적 실행 동안의 예외사항, 또는 (4) 트랜잭션 내에서 일시적인 내부 체크포인트로의 롤백을 유발하는 어떤 다른 이벤트로부터 입력될 수 있다.
더욱이, 추론적 체크포인트는 조건부 커미트와 결합되어 장애, 예외사항, 또는 훨씬 싸게 하는(원자 영역 전체의 시작 대신 체크포인트로 복귀시 실행이 덜 낭비됨) 예측할 수 없는 다른 원인으로 인한 그러한 롤백/중단을 체크포인팅하면서, 추론적 자원의 부족으로 인한 중단을 방지하는 것과 같은 추가 이익을 제공할 수 있다. 아래의 의사 코드 K는 그러한 결합의 일예를 도시한다.
의사 코드 K: 추론적 체크포인트와 조건부 커미트의 결합
게다가, 일 실시예에서, 조건부 커미트 명령어는 아래의 의사 코드 L에 도시된 바와 같이 추론적 체크포인트를 인식하게 된다.
의사 코드 L: 추론적 체크포인트를 인식하는 조건부 커미트
이 경우, region_check(조건부 커미트) 명령어는 시스템이 (전술한 바와 같이) 자원이 부족하려고 하거나 또는 실행이 (실행이 추론적 체크포인트로 롤백한 후) 롤백 지연이 있는 경우 L2로 점프한다.
또한, 단지 추론적 체크포인트와 조건부 커미트 명령어가 함께 사용될 수 있는 것은 아니며, 일 실시예에서 이러한 명령어 자신은 아래의 의사 코드 M에 도시된 바와 같이 결합된다.
의사 코드 M: 추론적 체크포인트 및 조건부 커미트에 대한 한가지 명령어
여기서, 결합된 명령어가 실행되면, 체크포인트가 수행되고 조건부 커미트(하드웨어 자원이 부족하거나 고갈되려 하는 경우의 커미트)가 평가된다. 여기서, 만일 시스템의 추론적 자원이 고갈되는 경우 또는 실행이 기록된 추론적 체크포인트로 롤백하는 경우, 실행은 L2로 점프하고 (이 예에서) 추론적 자원을 커미트하고 궁극적인 장애를 수리함으로써 이를 다룬다.
비록 앞의 설명이 일단 하드웨어가 고갈되면 이전의(또는 최근의 추론적) 체크포인트로의 롤백과 관련하여 이루어졌지만, 장애가 검출되고, 예외사항이 발생하고, 또는 다른 예측할 수 없는 이벤트가 인터럽션을 유발하고, 그러한 인터럽션에 따라 다른 경로가 검토될 수 있다. 실제로, 일 실시예에서, 인터럽션 발생시, 하드웨어, 소프트웨어, 또는 이들의 조합은 다음에 무엇을 해야할지를 판단한다. 예를 들면, 하드웨어에서 발생한 장애/이벤트와 같은 장애가 원자 실행 동안 발생한다고 가정한다. 원자 실행은 인터럽트된다. 그리고 일반적으로 제어는 장애의 형태를 판단하고 그 장애를 수리하는 소프트웨어로 핸드오버된다(handed over).
여기서, 처리기와 같은 소프트웨어는 장애의 형태, 가장 최근의 추론적 체크포인트로의 롤백할 때의 어려움, 가장 최근의 추론적 체크포인트 대신 마지막 커미트 지점까지 롤백함으로써 손실된 명령어의 수 또는 실행량, 또는 복귀(return) 프로그램에서 실행 시점을 선택할 때 공지된 다른 요인과 같은 임의 수의 요인에 따라 다음에 무엇을 해야할지를 판단할 수 있다. 본질적으로, 이러한 예시적인 예에서, 처리기와 같은 소프트웨어는 실행을 원자 영역의 시작, 원자 영역 내 마지막 커미트 지점, 또는 원자 영역 내 최신의 추론적 체크포인트로 롤백해야 하는지를 판단한다. 그리고 비록 이러한 예가 그러한 판단을 내리는 소프트웨어에 초점을 맞추었지만, 하드웨어도 또한 그러한 판단을 내릴 수 있다. 일 실시예에서, 그러한 판단을 내리는데 새로운 명령어(speculative_rollback)가 이용된다. 여기서, speculative_rollback 명령어는 일단 디코드되고 실행되면 프로그램 코드 내 적절한 것(추론적 체크포인트 또는 최근의 커미트 지점)으로의 복귀를 유발하는 어떤 정보를 포함한다.
본 명세서에서 기술된 코드는 동일한 블록, 영역, 프로그램, 또는 메모리 공간 내에 공동 배치되지 않아도 된다는 것을 주목하는 것이 중요하다. 실제로, 주 프로그램 코드 내 루프백 에지에 추론적 체크포인트 동작이 삽입될 수 있다. 그리고 가장 가까운 체크포인트로 롤백하고 선택적으로 트랜잭션을 커미트하는 코드를 포함하는 수리 코드는 코드의 라이브러리 또는 다른 부분에 위치할 수 있다. 여기서, 주 프로그램 코드가 실행한다. 그리고 수리 코드가 입력되면, 라이브러리 코드의 하나 이상의 기능으로의 호출을 실행하여 롤백 및 커미트를 수행한다. 또한, 하드웨어는 소프트웨어의 지시없이 유사한 체크포인트 동작을 수행할 수 있다. 여기서, 하드웨어는 추론적 하드웨어를 주기적 또는 이벤트 구동(driven) 단위와 같이 투명하게 체크포인트한다. 그리고 추론적 하드웨어의 부족에 따라, 프로세서는 최신의 체크포인트로의 실행을 롤백하고, 트랜잭션을 커미트하고, 트랜잭션을 재시작하고, 그리고 체크포인트와 롤백 시점 사이에서 명령어를 재생한다. 소프트웨어 관점에서, 실행은 정상적으로 지속하고, 반면에 하드웨어는 자원 제약조건 및 재실행을 모두 다루었다. 또한, 하드웨어와 소프트웨어 사이에서 로컬, 내부 트랜잭션 체크포인트를 성취하기 위해 어떤 레벨의 협업이라도 사용될 수 있다.
도 7a를 참조하면, 블록(730)에서, 프로그램 코드의 섹션을 최적화한다. 아래의 의사 코드 N은 최적화 후 의사 코드 M으로부터의 코드 영역의 일예를 도시한다.
의사 코드 N: 추론적 체크포인트와 조건부 커미트에 대한 단일 명령어를 포함하는 최적화된 코드
또 다른 최적화 예로서, 아래의 의사 코드 O는 또 다른 최적화(의사 코드 G로부터의 코드 영역의 최적화) 예를 예시한다.
의사 코드 O: 최적화 후의 코드 영역
전술한 바와 같이, 원자 영역 내의 코드에 대해 어떤 공지의 최적화 기술도 수행될 수 있다. 불완전한 목록 및 단순히 예시적인 코드 최적화의 몇 가지 예는 PRLE, PDSE, 루프 최적화, 데이터 흐름 최적화, 코드 생성 최적화, 바운드 체킹 제거, 분기 오프셋 최적화, 데드 코드 제거, 및 점프 스레딩을 포함한다. 의사 코드 O에서, (B6)에서 커미트한 후, (B6)에서 다른 트랜잭션이 시작하고 (B2)에서 실행이 지속된다. 다른 실시예(미예시)에서, (B3)에서 코드가 재입력될 수 있다. 일부 실시에에서 원자 영역의 경계설정 및 조건부 커미트 코드의 삽입은 또한 프로그램 코드를 최적화하는 것으로 간주될 수 있다.
다음에 도 8을 참조하면, 트랜잭션 실행 동안 메모리를 추론적으로 체크포인팅하는 방법의 흐름도의 일 실시예가 예시되어 있다. 흐름(805)에서, 트랜잭션을 실행한다. 일예로서, 트랜잭션은 런타임 동안 원자성(atomicity)을 보장하는 코드 최적화 전반에 걸쳐 트랜잭션을 삽입하도록 동적으로 최적화된 이진 코드이다.
흐름(810)에서, 트랜잭션으로부터의 추론적 체크포인트 명령어를 인카운터한다. 추론적 체크포인트 명령어는 또한 도 7a 및 도 7b와 관련하여 전술한 바와 같이 런타임 동안 최적화기에 의해 추론적 체크포인트에 삽입되었을 수 있다. 프로세서는 (전형적으로 사전 지정된/정의된 연산 코드를 검출하는 디코더에 의해) 추론적 체크포인트 명령어를 인식한다. 그리고 추론적 체크포인트 명령어에 따라, 흐름(815)에서 추론적 레지스터 파일을 체크포인트(추론적) 레지스터 파일에 체크포인트한다. 추가로, 흐름(820)에서 추론적 캐시가 저장 버퍼를 체크포인하기에 충분한 공간을 포함하는지를 판단한다. 만일 충분한 공간이 이용가능하다면, 흐름(825)에서 저장 버퍼를 추론적 캐시에 체크포인트한다. 그러나, 만일 충분한 공간이 존재하지 않다면, 수리/롤백 절차(아래에서 더욱 상세히 설명된 블록(845-855))가 수행된다.
결과적으로, 만일 트랜잭션의 실행 동안 단기(short-term) 롤백 이벤트가 인카운터되면, 현재 실행을 위해 이용되는 추론적 레지스터 파일 및 저장 버퍼는 체크포인트된 상태로 복원될 수 있다. 일예로서, 흐름(830)에서 저장 동작을 인카운터한다. 흐름(835)에서, 저장 버퍼가 저장 동작을 위해 할당될 수 있는 엔트리와 같은 이용가능한 엔트리를 포함하는지를 판단한다. 그리고 만일 쉽게 이용가능한 엔트리가 존재하거나, 또는 할당해제(deallocated)되고 재할당될 수 있는 엔트리가 존재한다면, 블록(840)에서 엔트리를 그와 같이 할당한다. 그러나, 만일 이용가능한 저장 버퍼 엔트리가 존재하지 않다면, 롤백 절차(블록(845-855))가 수행된다.
롤백/복구 절차(845-855)는 이전 체크포인트로부터 정확한 구조 상태를 복원하는 것이다. 여기서, 롤백은 커미트하지 않은(전역적으로 가시화되지 않는) 추론적 실행 동안에 이루어진다. 따라서, 전역 가시적 상태(비추론적 저장 구조)는 동일하게 유지되어야 한다. 그러나, 현재의 추론적 실행을 지원하는 추론적 하드웨어 구조는 복원된다. 추론적 캐시가 저장 버퍼로부터 가장 최근의 체크포인트까지의 추론적 업데이트를 이미 보유하기 때문에, 블록(850)에서 저장 버퍼는 플러쉬된다(flushed). 다시 말하면, 트랜잭션의 시작부터 가장 최근의 체크포인트까지의 저장은 추론적 캐시에 보유된다. 그리고 가장 최근의 체크포인트로부터 현재의 실행 시점(롤백의 개시)까지의 저장은 저장 버퍼에 보유된다. 따라서, 롤백되는 그러한 저장은 저장 버퍼로부터 간단히 폐기된다.
또한, 추론적 레지스터 파일은 체크포인트 레지스터 파일로부터 복원된다. 여기서, 추론적 레지스터 파일은 가장 최근의 체크포인트로부터의 업데이트를 포함하는 트랜잭션의 처음부터 모든 업데이트를 보유하므로, 추론적 레지스터 파일은 체크포인트 레지스터 파일로부터의 값들로 재로드된다. 만일 원래의 체크포인트가 추론적 레지스터 파일 전체의 복사본(추론적 실행 동안 변경된 단지 레지스터만의 선택적 저장만이 아님)을 포함하면, 체크포인트 레지스터 파일은 추론적 레지스터 파일로 재분류(이용)될 수 있고 이전의 추론적 레지스터 파일은 플러쉬되고 나중에 체크포인트 레지스터 파일로 이용될 수 있다는 것을 주목하자. 또는 추론적 레지스터 파일은 추론적 체크포인트 레지스터 파일에 (한 사이클 또는 몇 사이클로) 플래시 복사된다.
흐름(860)에서, 트랜잭션을 선택적으로 커미트할 수 있다. 롤백 절차는 예외사항, 추론적 캐시 내 공간 부족, 또는 저장 버퍼 내 공간 부족에 따라 이루어지기 때문에, 트랜잭션은 자유로운 그러한 자원에 커미터될 수 있다. 여기서 저장 버퍼 및 추론적 캐시 업데이트는 비추론적 캐시 메모리에 커미트되어, (흐름(875-880)에 도시된) 그러한 자원을 자유롭게 한다. 그리고 유사하게 추론적 레지스터 파일은 비추론적 레지스터 파일에 커미트되어, 이를 (흐름(875-880)에 도시된) 추가의 추론적 실행을 위해 자유롭게 한다. 더욱이, 만일 트랜잭션의 완전 중단이 수행되면(865), 블록(870)에서 저장 버퍼 및 추론적 캐시를 플러쉬하여 이들을 이전 트랜잭션(비추론적) 상태로 복원한다.
도 9를 참조하면, 추론적 체크포인팅을 지원하도록 구성된 하드웨어의 논리 표현의 일 실시예가 예시되어 있다. 디코더(디코드 논리)(910)는 추론적 체크포인트 명령어(SCPI)(905)를 인식하도록 구성되거나 상호 연결된다. 예를 들면, 도 9의 하드웨어를 포함하는 프로세서의 사전 정의된 명령어 형식은 특정되고 하드웨어로 설계될 수 있다. 그리고 특정한 비트 패턴을 갖는 명령어의 일부는 특정 명령어들에 해당하고, 그 중 하나는 SCPI(905)이다.
다음에, SCPI에 따라, 추론적 저장 구조에 보유된 추론적인 값(935)은 추론적 체크포인트 저장 구조 내에 추론적 체크포인트 값(940)으로 체크포인트된다. 실행 논리(920)가 SCPI(920)를 실행하는 디코더에 연결된 것으로 예시됨을 주목하자. 또한 명백하게, 종종 디코딩과 실행 사이에는 많은 파이프라인 단계가 존재한다. 예를 들면, SCPI는 추적 캐시 내에서의 약간의 동작으로 디코드될 수 있고, 그러한 동작은 버퍼에 큐되고, 스케줄링되고, 디스패치되고, 실행되어 본 명세서에서 기술된 동작/방법을 수행할 수 있다.
앞에서 개략적으로 설명된 바와 같이, 체크포인트는 어떤 시점에서 값들의 상태에 대한 스냅샷, 또는 적어도 그 시점에서 그러한 값들의 상태를 복구하기에 충분한 정보를 포함한다. 따라서, 일 실시예에서, 체크포인트는 추론적인 값(935)의 전체 복사본을 추론적 체크포인트 값(940)으로서 포함한다. 여기서, 추론적인 값(935)은 추론적 레지스터 파일로부터의 추론적 레지스터 파일 값을 포함할 수 있고, 추론적 체크포인트 값(940)은 가장 최근의 체크포인트에 시간을 맞춘 추론적 레지스터 파일의 복사본을 포함한다. 다른 예로서, 추론적 체크포인트 값은 마지막 체크포인트 이후에 변경된 추론적인 값(935)만을 포함한다. 여기서, 추론적인 값(935)은 추론적 레지스터 파일로부터의 추론적 레지스터 파일 값을 포함할 수 있고, 추론적 체크포인트 값(940)은 추론적 레지스터 파일 내에서 마지막 체크포인트 이후에 변경된 레지스터만으로부터의 마지막 체크포인트로부터의 추론적 레지스터 파일 값을 포함한다. 또 다른 예로서, 추론적 체크포인트 값(940)은 원자 영역의 처음부터 체크포인트까지 시간에 맞춘 모든 값을 포함하고, 반면에 추론적인 값(935)은 그 체크포인트로부터 현재의 실행 시점까지의 모든 추론적인 값을 포함한다. 여기서, 저장 버퍼는 추론적 캐시에 보유된 (시작부터 마지막 체크포인트까지) 오래된 값에 추가된 추론적인 값(935)을 보유할 수 있다.
도 10을 참조하면, 레지스터 파일의 추론적 체크포인팅을 지원하도록 구성된 하드웨어의 논리 표현의 또 다른 실시예가 도시되어 있다. 전술한 설명과 유사하게, 디코더(1010) 및 실행 논리(1020)는 각각 SCPI(1005)를 수신하고, 인식하고, 실행하도록 구성된다. SCPI(1005)에 따라, 추론적 레지스터 파일(1035)은 추론적 체크포인트 레지스터 파일(1040)에 체크포인트된다. 전술한 바와 같이, 체크포인트는 레지스터 파일(1035)을 체크포인트 레지스터 파일(1040)에 플래시 복사하는 것을 포함한다. 또는, 파일(1035) 내에서 레지스터가 변경되면, 오래된 값은 레지스터 파일(1040)에 체크포인트된다. 여기서, SCPI(1005)에 따라 값을 복사하는 대신, 파일(1035) 내에 있는 이들의 대응하는 것의 변경시 복사된 오래된 체크포인트 값은 파일(1040)로부터 클리어되거나 무효한 것으로 표시된다. 실행이 지속되면, 변경된 레지스터는 다시 파일(1040)에 체크포인트된다.
(도 8의 블록(820)에서처럼 추론적 캐시 내 공간 부족, 도 8의 블록(840)에서처럼 저장 버퍼 내 공간 부족, 예외사항, 또는 다른 롤백 이벤트로부터) 가장 최근의 체크포인트로의 롤백에 따라, (단지 변경된 것이든 완전 복사본이든) 체크포인트 값은 추론적 체크포인트 레지스터 파일(1040)로부터 추론적 레지스터 파일(1035)로 복원된다. 그러나, 만일 트랜잭션의 중단과 같이 트랜잭션 영역의 맨처음으로 롤백하면, 일 실시예에서, 추론적 레지스터 파일(1035)은 비추론적 레지스터 파일(1030)로부터 재로드된다. 본질적으로, 추론적 파일(1035)은 동작 중인 추론적 레지스터 파일이다. 그러므로, 트랜잭션은 추론적 레지스터 파일(1035)과 함께 동작(판독 및 기록)한다. 따라서, 만일 트랜잭션의 처음에 로드가 재실행되는 경우, 비추론적인 값이 재로드되지 않으면, 로드는 중단 전에 추론적 레지스터 파일(1035)에 보유된 나중에 변경된 추론적인 값을 부주위로 로드할 수 있다.
추가로, 트랜잭션의 커미트에 따라, 추론적 레지스터 파일(1035)은 비추론적 레지스터 파일(1030)에 커미트된다(복사된다). 여기서, 추론적 업데이트는 비추론적 결과로서 전역적으로 가시화된다. 다시, 레지스터 파일(1035) 전체가 비추론적 레지스터 파일(1030)에 복사될 수 있다. 또는 변경된 추론적 레지스터 파일(1035) 내 그러한 레지스터만 비추론적 레지스터 파일(1030)에 복사될 수 있다.
도 11을 참조하면, 캐시 메모리의 추론적 체크포인팅을 지원하도록 구성된 하드웨어의 논리 표현의 또 다른 실시예가 예시되어 있다. 도 9 및 도 10과 관련하여 전술한 바와 같이, 디코더(1110) 및 실행 논리(1120)는 SCPI(1105)를 디코드하고 실행하도록 구성된다. 여기서, 실행 논리(1120)는 원자 영역으로부터 추론적 저장을 실행할 때 저장 버퍼(1140)를 이용하여 추론적 업데이트를 보유한다. 이전의 저장으로부터 로드하는 그러한 동일 영역(로컬 스레드)으로부터의 로드는 저장 버퍼(1140)에 보유된 추론적인 값으로부터 로드하는 것임을 주목하자. 따라서, 저장 버퍼(1140)와 실행 논리(1120)의 로드 실행 유닛 사이에는 유사한 로드의 인플라이트(in-flight) 저장 기구가 이용될 수 있다. 그러나, 저장 버퍼(1140) 내 저장 어드레스로의 비추론적 또는 비로컬 로드는 저장 버퍼(1140) 내의 값이 아닌 캐시(1130)에 보유된 비추론적인 값을 수신하는 것이다. 또한, 만일 원자 영역으로부터 체크포인트되거나 추론적 캐시(1135)로 이동된 저장 어드레스로의 판독/로드가 있다면, 추론적 캐시 값은 직접 또는 저장 버퍼(1140)를 통해 로드에 제공되어야 한다.
SCPI(1105)에 따라, 버퍼(1140) 내에 있는 저장 버퍼 업데이트는 추론적 캐시(1135)로 이동된다. 그 결과, 추론적 캐시(1135)는 원자 영역의 처음부터 최신 체크포인트까지의 추론적 업데이트를 보유한다. 그리고 저장 버퍼(1140)는 그러한 최신 체크포인트로부터 현재의 실행 체크포인트까지의 추론적 업데이트를 보유한다. 따라서, 원자 영역의 커미트시, 추론적 캐시(1135) 및 저장 버퍼(1140) 내의 모든 업데이트는 비추론적 캐시(1130)에 커미트되고/이동되고/복사된다. 예시된 바와 같이, 이러한 커미트는 저장 버퍼(1140)를 추론적 캐시(1135)에 그리고 추론적 캐시(1135)를 비추론적 캐시(1130)에 커미트함으로써 수행된다. 그러나, 또 다른 실시예에서, 저장 버퍼(1140) 및 추론적 캐시(1135) 양자로부터의 업데이트는 비추론적 캐시(1130)로 직접 제공된다. 커미트한 후, 이러한 업데이트는 전역적으로 가시적이며 메모리 계층(1150)을 통해 (상위레벨 메모리 및 홈(home) 위치로) 전달될 수 있다.
더욱이, 가장 최근의 체크포인트로의 로컬 내부 롤백에 따라, 저장 버퍼(1140)는 플러쉬된다. 전술한 바와 같이, 이 실시예에서, 저장 버퍼(1140)는 본질적으로 가장 최근의 체크포인트부터 현재의 실행 시점까지의 업데이트를 보유한다. 그러므로, 롤백시, 그러한 업데이트는 폐기된다. 일예에서, 저장 버퍼(1140)가 원자 영역으로부터 새로운 저장 동작을 수용할 수 없음에 따라 로컬 롤백이 개시될 수 있다는 것을 주목하자(도 8의 블록(840)). 그리고 블록(820)에서, SCPI(1105)에 따라 캐시(1135)가 가득 차 있어서 저장 버퍼(1140)의 업데이트를 캐시할 수 없음에 따라 롤백이 또한 개시될 수 있다. 또한, 중단(원자 영역 전체의 롤백)이 발생할 때, 저장 버퍼(1140) 및 추론적 캐시(1135)(원자 영역의 처음부터 현재 실행 시점까지의 업데이트)는 모두 플러쉬된다.
본 명세서에서 사용된 바와 같은 모듈은 어떤 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 조합을 지칭한다. 종종 개별적으로 예시된 모듈 경계는 일반적으로 변화하고 잠재적으로 겹친다. 예를 들면, 제1 및 제2 모듈은 잠재적으로 어떤 독립적인 하드웨어, 소프트웨어, 또는 펌웨어를 유지하면서 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 조합을 공유할 수 있다. 일 실시예에서, 논리라는 용어의 사용은 트랜지스터, 레지스터와 같은 하드웨어, 또는 프로그램가능한 논리 디바이스와 같은 다른 하드웨어를 포함한다. 그러나, 다른 실시예에서, 논리는 또한 펌웨어, 마이크로 코드와 같은, 하드웨어에 통합된 소프트웨어 또는 코드를 포함한다.
본 명세서에서 사용된 바와 같은 어떤 값은 수치, 상태, 논리 상태, 또는 이진 논리 상태의 모든 공지의 표현을 포함한다. 종종, 논리 레벨, 논리값, 또는 논리적 값의 사용은 또한 단순히 이진 논리 상태를 나타내는 1과 0으로 지칭된다. 예를 들면, 1은 하이 논리 레벨을 나타내고 0은 로우 논리 레벨을 나타낸다. 일 실시예에서, 트랜지스터 또는 플래시 셀과 같은 저장 셀은 단일 논리값 또는 다수의 논리값을 보유할 수 있다. 그러나, 컴퓨터 시스템에서 다른 값의 표현도 사용될 수 있다. 예를 들면, 10진수 10은 1010이라는 이진값과 16진수 문자 A로도 표현될 수 있다. 따라서, 어떤 값은 컴퓨터 시스템에서 보유될 수 있는 정보의 모든 표현을 포함한다.
더욱이, 상태는 값 또는 값의 일부로 표현될 수 있다. 일예로서, 논리 1과 같은 제1 값은 디폴트 또는 초기 상태를 표현할 수 있고, 반면에 논리 0과 같은 제2 값은 디폴트가 아닌 상태를 표현할 수 있다. 또한, 일 실시예에서, 용어 리셋(reset) 및 세트(set)는 각각 디폴트 및 업데이트된 값 또는 상태를 지칭한다. 예를 들면, 디폴트값은 잠재적으로 하이 논리값, 즉 리셋을 포함하고, 반면에 업데이트된 값은 잠재적으로 로우 논리값, 즉 세트를 포함한다. 어떤 값들의 조합은 몇 개의 상태라도 표현하는데 이용될 수 있음을 주목하자.
전술한 방법, 하드웨어, 소프트웨어, 펌웨어 또는 코드의 실시예는 처리 소자에 의해 실행가능한 기계 액세스가능한 또는 기계 판독가능한 매체에 저장된 명령어 또는 코드를 통해 구현될 수 있다. 기계 액세스가능한/판독가능한 매체는 컴퓨터 또는 전자 시스템과 같은 기계에 의해 판독가능한 형태로 정보를 제공(즉, 저장 및/또는 전송)하는 어떠한 기구라도 포함한다. 예를 들면, 기계 액세스가능한 매체는 정적 RAM(SRAM) 또는 동적 RAM(DRAM)과 같은 랜덤 액세스 메모리, ROM, 자기 또는 광학 저장 매체, 플래시 메모리 디바이스, 전기 저장 디바이스, 광학 저장 디바이스, 음향 저장 디바이스, 전파 신호(예컨대, 반송파, 적외선 신호, 디지털 신호)를 보유하는 다른 형태의 저장 디바이스 등을 포함한다.
본 명세서 전체에서 "일 실시예" 또는 "하나의 실시예"라는 언급은 그러한 실시예와 관련하여 기술된 특정한 특징, 구조, 또는 특성이 본 발명의 적어도 일 실시예에 포함된다는 것을 의미한다. 따라서, 본 명세서 전체에 걸쳐 여러 곳에서 "일 실시예에서" 또는 "하나의 실시예에서"라는 문구가 나타나더라도 반드시 모두 동일한 실시예를 지칭하는 것은 아니다. 더욱이, 특정한 특징, 구조, 또는 특성은 하나 이상의 실시예에서 어떤 적절한 방식으로 구체화될 수 있다.
전술한 명세서에서, 상세한 설명은 특정한 예시적인 실시예와 관련하여 제시되었다. 그러나, 첨부의 특허청구범위에 기술된 바와 같은 본 발명의 광범위한 정신 및 범주로부터 벗어남이 없이 여러 변형 및 변경이 이루어질 수 있음이 명백할 것이다. 따라서, 본 명세서 및 도면은 제한적인 의미라기보다 예시적인 의미로 간주되어야 할 것이다. 더욱이, 전술한 실시예 및 다른 예시적인 언어의 사용은 반드시 동일한 실시예 또는 동일한 예를 지칭하지 않고, 잠재적으로 동일한 실시예 뿐만 아니라, 다른 별개의 실시예를 지칭할 수 있다.
Claims (22)
- 프로그램 코드를 최적화하기 위한 컴퓨팅 디바이스로서,
(i) 최적화될 프로그램 코드의 섹션을 식별하고, (ii) 최적화될 프로그램 코드의 상기 섹션의 식별에 응답하여 프로그램 코드의 상기 섹션의 적어도 일부분을 원자 영역으로 구분하고(demarcate), (iii) 상기 원자 영역 내에 존재하는 것으로 판정된 추론적 체크포인트(speculative checkpoint)에 추론적 체크포인트 코드를 삽입하고, (iv) 최적화될 프로그램 코드의 상기 섹션의 식별에 응답하여 프로그램 코드의 상기 섹션을 최적화하는 컴파일러 모듈; 및
상기 원자 영역 내의 상기 추론적 체크포인트를 판정하는 디코드 모듈
을 포함하는 컴퓨팅 디바이스. - 제1항에 있어서,
프로그램 코드의 상기 섹션의 적어도 일부분을 원자 영역으로 구분하는 것은, (i) 코드의 상기 섹션의 상기 일부분의 개시 시에 시작 트랜잭션 명령어를 삽입하고, (ii) 코드의 상기 섹션의 상기 일부분의 종료 시에 종료 트랜잭션 명령어를 삽입하는 것을 포함하는 컴퓨팅 디바이스. - 제1항에 있어서,
상기 추론적 체크포인트 코드는, (i) 추론적 체크포인트 레지스터 파일 내의 추론적 레지스터 파일을 체크포인트하고, (ii) 추론적 캐시 내의 저장 버퍼를 체크포인트하는 추론적 체크포인트 동작을 포함하고,
상기 컴파일러 모듈은, 또한, 코드의 상기 섹션의 상기 일부분의 실행 중에 상기 추론적 캐시 또는 상기 저장 버퍼의 자원 고갈에 응답하여 수리(fix-up) 코드를 삽입하여 상기 추론적 체크포인트 레지스터 파일에 유지된 상기 추론적 레지스터 파일의 상기 체크포인트로 롤백(roll-back)하는 컴퓨팅 디바이스. - 제3항에 있어서,
코드의 상기 섹션의 상기 일부분의 실행 중에 상기 저장 버퍼의 자원 고갈에 응답하여 수리 코드를 삽입하는 것은, 상기 저장 버퍼가 코드의 상기 섹션의 상기 일부분의 실행 중에 임의의 이용가능한 엔트리들을 포함하지 않는 것에 응답하여 수리 코드를 삽입하는 것을 포함하고,
코드의 상기 섹션의 상기 일부분의 실행 중에 상기 추론적 캐시의 자원 고갈에 응답하여 수리 코드를 삽입하는 것은, 상기 추론적 캐시가 상기 컴퓨팅 디바이스에 의한 상기 추론적 체크포인트 동작의 실행 시에 상기 저장 버퍼로부터의 엔트리들을 유지하는데 충분한 이용가능한 엔트리들을 포함하지 않는 것에 응답하여 수리 코드를 삽입하는 것을 포함하는 컴퓨팅 디바이스. - 제1항에 있어서,
프로그램 코드의 상기 섹션을 최적화하는 것은, PRLE(Partial Redundancy Load Elimination), PDSE(Partial Dead Store Elimination), 루프 최적화, 데이터 흐름 최적화, 코드 생성 최적화, 바운드(bounds) 체킹 제거, 분기 오프셋 최적화, 데드(dead) 코드 제거 및 점프 스레딩을 포함하는 그룹으로부터 선택된 최적화 기술을 통해 코드의 상기 섹션을 최적화하는 것을 포함하는 컴퓨팅 디바이스. - 복수의 명령어를 포함하는 머신 판독가능한 매체로서, 상기 복수의 명령어는 컴퓨팅 디바이스에 의해 실행될 때 상기 컴퓨팅 디바이스로 하여금,
최적화될 프로그램 코드의 섹션을 식별하고,
최적화될 프로그램 코드의 상기 섹션의 식별에 응답하여 프로그램 코드의 상기 섹션의 적어도 일부분을 원자 영역으로 구분하고,
상기 원자 영역 내의 추론적 체크포인트를 판정하고,
상기 추론적 체크포인트의 판정에 응답하여 상기 추론적 체크포인트에 추론적 체크포인트 코드를 삽입하고,
최적화될 프로그램 코드의 상기 섹션의 식별에 응답하여 프로그램 코드의 상기 섹션을 최적화하게 하는 머신 판독가능한 매체. - 제6항에 있어서,
프로그램 코드의 상기 섹션의 적어도 일부분을 원자 영역으로 구분하는 것은, (i) 코드의 상기 섹션의 상기 일부분의 개시 시에 시작 트랜잭션 명령어를 삽입하고, (ii) 코드의 상기 섹션의 상기 일부분의 종료 시에 종료 트랜잭션 명령어를 삽입하는 것을 포함하는 머신 판독가능한 매체. - 제6항에 있어서,
상기 추론적 체크포인트 코드는, 실행될 때 상기 컴퓨팅 디바이스로 하여금 (i) 추론적 체크포인트 레지스터 파일 내의 추론적 레지스터 파일을 체크포인트하고, (ii) 추론적 캐시 내의 저장 버퍼를 체크포인트하는 추론적 체크포인트 동작을 포함하고,
상기 복수의 명령어는, 또한, 상기 컴퓨팅 디바이스로 하여금 코드의 상기 섹션의 상기 일부분의 실행 중에 상기 추론적 캐시 또는 상기 저장 버퍼의 자원 고갈에 응답하여 수리 코드를 삽입하여 상기 추론적 체크포인트 레지스터 파일에 유지된 상기 추론적 레지스터 파일의 상기 체크포인트로 롤백하게 하는 머신 판독가능한 매체. - 제8항에 있어서,
코드의 상기 섹션의 상기 일부분의 실행 중에 상기 저장 버퍼의 자원 고갈에 응답하여 수리 코드를 삽입하는 것은, 상기 저장 버퍼가 코드의 상기 섹션의 상기 일부분의 실행 중에 임의의 이용가능한 엔트리들을 포함하지 않는 것에 응답하여 수리 코드를 삽입하는 것을 포함하고,
코드의 상기 섹션의 상기 일부분의 실행 중에 상기 추론적 캐시의 자원 고갈에 응답하여 수리 코드를 삽입하는 것은, 상기 추론적 캐시가 상기 컴퓨팅 디바이스에 의한 상기 추론적 체크포인트 동작의 실행 시에 상기 저장 버퍼로부터의 엔트리들을 유지하는데 충분한 이용가능한 엔트리들을 포함하지 않는 것에 응답하여 수리 코드를 삽입하는 것을 포함하는 머신 판독가능한 매체. - 제8항에 있어서,
프로그램 코드의 상기 섹션을 최적화하는 것은, PRLE, PDSE, 루프 최적화, 데이터 흐름 최적화, 코드 생성 최적화, 바운드 체킹 제거, 분기 오프셋 최적화, 데드 코드 제거 및 점프 스레딩을 포함하는 그룹으로부터 선택된 최적화 기술을 통해 코드의 상기 섹션을 최적화하는 것을 포함하는 머신 판독가능한 매체. - 프로그램 코드를 최적화하기 위한 방법으로서,
최적화될 프로그램 코드의 섹션을 식별하는 단계;
최적화될 프로그램 코드의 상기 섹션의 식별에 응답하여 프로그램 코드의 상기 섹션의 적어도 일부분을 원자 영역으로 구분하는 단계;
상기 원자 영역 내의 추론적 체크포인트를 판정하는 단계;
상기 추론적 체크포인트를 판정하는 단계에 응답하여 상기 추론적 체크포인트에 추론적 체크포인트 코드를 삽입하는 단계; 및
최적화될 프로그램 코드의 상기 섹션의 식별에 응답하여 프로그램 코드의 상기 섹션을 최적화하는 단계
를 포함하는 방법. - 제11항에 있어서,
프로그램 코드의 상기 섹션의 적어도 일부분을 원자 영역으로 구분하는 단계는, (i) 코드의 상기 섹션의 상기 일부분의 개시 시에 시작 트랜잭션 명령어를 삽입하는 단계, 및 (ii) 코드의 상기 섹션의 상기 일부분의 종료 시에 종료 트랜잭션 명령어를 삽입하는 단계를 포함하는 방법. - 제11항에 있어서,
상기 추론적 체크포인트 동작을 실행하는 단계;
상기 추론적 체크포인트 동작을 실행하는 단계에 응답하여 추론적 체크포인트 레지스터 파일 내의 추론적 레지스터 파일을 체크포인트하는 단계;
상기 추론적 체크포인트 동작을 실행하는 단계에 응답하여 추론적 캐시 내의 저장 버퍼를 체크포인트하는 단계; 및
코드의 상기 섹션의 상기 일부분의 실행 중에 상기 추론적 캐시 또는 상기 저장 버퍼의 자원 고갈에 응답하여 수리 코드를 삽입하여 상기 추론적 체크포인트 레지스터 파일에 유지된 상기 추론적 레지스터 파일의 상기 체크포인트로 롤백하는 단계
를 더 포함하는 방법. - 제13항에 있어서,
코드의 상기 섹션의 상기 일부분의 실행 중에 상기 저장 버퍼의 자원 고갈에 응답하여 수리 코드를 삽입하는 단계는, 상기 저장 버퍼가 코드의 상기 섹션의 상기 일부분의 실행 중에 임의의 이용가능한 엔트리들을 포함하지 않는 것에 응답하여 수리 코드를 삽입하는 단계를 포함하고,
코드의 상기 섹션의 상기 일부분의 실행 중에 상기 추론적 캐시의 자원 고갈에 응답하여 수리 코드를 삽입하는 단계는, 상기 추론적 캐시가 컴퓨팅 디바이스에 의한 상기 추론적 체크포인트 동작의 실행 시에 상기 저장 버퍼로부터의 엔트리들을 유지하는데 충분한 이용가능한 엔트리들을 포함하지 않는 것에 응답하여 수리 코드를 삽입하는 단계를 포함하는 방법. - 제11항에 있어서,
프로그램 코드의 상기 섹션을 최적화하는 단계는, PRLE, PDSE, 루프 최적화, 데이터 흐름 최적화, 코드 생성 최적화, 바운드 체킹 제거, 분기 오프셋 최적화, 데드 코드 제거 및 점프 스레딩을 포함하는 그룹으로부터 선택된 최적화 기술을 통해 코드의 상기 섹션을 최적화하는 단계를 포함하는 방법. - 복수의 명령어를 포함하는 머신 판독가능한 매체로서, 상기 복수의 명령어는 컴퓨팅 디바이스에 의해 실행될 때 상기 컴퓨팅 디바이스로 하여금,
메모리 내에 저장된 프로그램 코드를 실행하고,
상기 프로그램 코드의 트랜잭션 실행을 지원하도록 구성된 하드웨어 자원들의 유효성(availability)의 표시를 제공하고,
상기 하드웨어 자원들의 유효성의 표시에 기초하여 상기 프로그램 코드의 최적화된 부분을 포함하는 트랜잭션 영역을 동적으로 리사이즈하게 하는 머신 판독가능한 매체. - 제16항에 있어서,
상기 트랜잭션 영역을 동적으로 리사이즈하는 것은, 상기 트랜잭션 영역의 실행을 완료하는데 불충분한 자원들이 이용가능함을 나타내는 상기 하드웨어 자원들의 유효성의 표시에 응답하여 조건부 커미트 명령어를 실행하는 것을 포함하고, 상기 조건부 커미트 명령어는 상기 트랜잭션 영역의 종료 전에 상기 프로그램 코드 내에 삽입되고, 상기 트랜잭션 영역의 종료 전에 상기 트랜잭션을 커미트하도록 구성되는 머신 판독가능한 매체. - 제17항에 있어서,
상기 복수의 명령어는, 또한, 상기 컴퓨팅 디바이스로 하여금 상기 프로그램 코드의 상기 최적화된 부분을 취득하기 위해 상기 프로그램 코드의 일부분을 최적화하게 하고, 상기 프로그램 코드의 상기 일부분을 최적화하는 것은, 실행 중, 상기 트랜잭션 영역의 종료 전에 상기 조건부 커미트 명령어를 삽입하는 것을 포함하는 머신 판독가능한 매체. - 제17항에 있어서,
상기 조건부 커미트 명령어는 상기 트랜잭션 영역의 일부분의 실행 시에 이용될 하드웨어 자원들의 예상 양에 대한 기준을 포함하고,
상기 복수의 명령어는, 또한, 상기 컴퓨팅 디바이스로 하여금 상기 하드웨어 자원들의 유효성의 표시가 상기 트랜잭션 영역의 실행을 완료하는데 불충분한 자원들이 이용가능하다는 것을 나타내는지의 여부를 판정하게 하는 머신 판독가능한 매체. - 제19항에 있어서,
상기 하드웨어 자원들의 유효성의 표시가 상기 트랜잭션 영역의 실행을 완료하는데 불충분한 자원들이 이용가능하다는 것을 나타내는지의 여부를 판정하는 것은, 하드웨어 자원들의 이용가능한 양이 하드웨어 자원들의 상기 예상 양보다 작다고 판정하는 것을 포함하는 머신 판독가능한 매체. - 제16항에 있어서,
상기 트랜잭션 영역을 동적으로 리사이즈하는 것은 상기 트랜잭션 영역으로부터 트랜잭션 기입을 실행하는 것을 포함하고,
상기 복수의 명령어는, 또한, 상기 컴퓨팅 디바이스로 하여금 하드웨어 저장 버퍼를 오버플로우하는 트랜잭션 기입에 응답하여 상기 트랜잭션 영역을 최근의 체크포인트로 롤백하고 상기 트랜잭션 영역을 커미트하게 하는 머신 판독가능한 매체. - 제16항에 있어서,
상기 메모리는 온-프로세서 캐시 메모리, 프로세서에 직접 결합된 시스템 메모리, 및 프로세서에 간접 결합된 시스템 메모리를 포함하는 그룹으로부터 선택되는 머신 판독가능한 매체.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US12/890,639 | 2010-09-25 | ||
| US12/890,639 US8549504B2 (en) | 2010-09-25 | 2010-09-25 | Apparatus, method, and system for providing a decision mechanism for conditional commits in an atomic region |
| PCT/US2011/053285 WO2012040715A2 (en) | 2010-09-25 | 2011-09-26 | Apparatus, method, and system for providing a decision mechanism for conditional commits in an atomic region |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020137007981A Division KR101496063B1 (ko) | 2010-09-25 | 2011-09-26 | 원자 영역에서 조건부 커미트를 위한 결정 메카니즘 제공 장치, 방법, 및 시스템 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| KR20140091779A KR20140091779A (ko) | 2014-07-22 |
| KR101529846B1 true KR101529846B1 (ko) | 2015-06-17 |
Family
ID=45871872
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020137007981A KR101496063B1 (ko) | 2010-09-25 | 2011-09-26 | 원자 영역에서 조건부 커미트를 위한 결정 메카니즘 제공 장치, 방법, 및 시스템 |
| KR1020147018278A KR101529846B1 (ko) | 2010-09-25 | 2011-09-26 | 원자 영역에서 조건부 커미트를 위한 결정 메카니즘 제공 장치, 방법, 및 시스템 |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020137007981A KR101496063B1 (ko) | 2010-09-25 | 2011-09-26 | 원자 영역에서 조건부 커미트를 위한 결정 메카니즘 제공 장치, 방법, 및 시스템 |
Country Status (8)
| Country | Link |
|---|---|
| US (3) | US8549504B2 (ko) |
| EP (1) | EP2619654B1 (ko) |
| JP (1) | JP5661934B2 (ko) |
| KR (2) | KR101496063B1 (ko) |
| CN (1) | CN103119556B (ko) |
| SG (1) | SG188993A1 (ko) |
| TW (1) | TWI546733B (ko) |
| WO (1) | WO2012040715A2 (ko) |
Families Citing this family (78)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8898401B2 (en) * | 2008-11-07 | 2014-11-25 | Oracle America, Inc. | Methods and apparatuses for improving speculation success in processors |
| US8806145B2 (en) * | 2008-11-07 | 2014-08-12 | Oracle America, Inc. | Methods and apparatuses for improving speculation success in processors |
| EP2519876A1 (en) | 2009-12-28 | 2012-11-07 | Hyperion Core, Inc. | Optimisation of loops and data flow sections |
| GB2480285A (en) * | 2010-05-11 | 2011-11-16 | Advanced Risc Mach Ltd | Conditional compare instruction which sets a condition code when it is not executed |
| US8549504B2 (en) | 2010-09-25 | 2013-10-01 | Intel Corporation | Apparatus, method, and system for providing a decision mechanism for conditional commits in an atomic region |
| US9195501B2 (en) * | 2011-07-12 | 2015-11-24 | Qualcomm Incorporated | Instruction culling in graphics processing unit |
| WO2013095569A1 (en) * | 2011-12-22 | 2013-06-27 | Intel Corporation | Method, apparatus and system for selective execution of a commit instruction |
| US9268596B2 (en) | 2012-02-02 | 2016-02-23 | Intel Corparation | Instruction and logic to test transactional execution status |
| US10146545B2 (en) | 2012-03-13 | 2018-12-04 | Nvidia Corporation | Translation address cache for a microprocessor |
| US9880846B2 (en) | 2012-04-11 | 2018-01-30 | Nvidia Corporation | Improving hit rate of code translation redirection table with replacement strategy based on usage history table of evicted entries |
| US10241810B2 (en) | 2012-05-18 | 2019-03-26 | Nvidia Corporation | Instruction-optimizing processor with branch-count table in hardware |
| US8924927B2 (en) * | 2012-06-01 | 2014-12-30 | Google Inc. | Representation and conversion of dynamically-typed arrays |
| US9075727B2 (en) | 2012-06-14 | 2015-07-07 | International Business Machines Corporation | Reducing penalties for cache accessing operations |
| US9015423B2 (en) | 2012-06-14 | 2015-04-21 | International Business Machines Corporation | Reducing store operation busy times |
| US9740549B2 (en) | 2012-06-15 | 2017-08-22 | International Business Machines Corporation | Facilitating transaction completion subsequent to repeated aborts of the transaction |
| US9384004B2 (en) | 2012-06-15 | 2016-07-05 | International Business Machines Corporation | Randomized testing within transactional execution |
| US10437602B2 (en) | 2012-06-15 | 2019-10-08 | International Business Machines Corporation | Program interruption filtering in transactional execution |
| US8966324B2 (en) | 2012-06-15 | 2015-02-24 | International Business Machines Corporation | Transactional execution branch indications |
| US9361115B2 (en) | 2012-06-15 | 2016-06-07 | International Business Machines Corporation | Saving/restoring selected registers in transactional processing |
| US9436477B2 (en) | 2012-06-15 | 2016-09-06 | International Business Machines Corporation | Transaction abort instruction |
| US8682877B2 (en) | 2012-06-15 | 2014-03-25 | International Business Machines Corporation | Constrained transaction execution |
| US9348642B2 (en) * | 2012-06-15 | 2016-05-24 | International Business Machines Corporation | Transaction begin/end instructions |
| US20130339680A1 (en) | 2012-06-15 | 2013-12-19 | International Business Machines Corporation | Nontransactional store instruction |
| US9336046B2 (en) * | 2012-06-15 | 2016-05-10 | International Business Machines Corporation | Transaction abort processing |
| US8688661B2 (en) * | 2012-06-15 | 2014-04-01 | International Business Machines Corporation | Transactional processing |
| US8880959B2 (en) | 2012-06-15 | 2014-11-04 | International Business Machines Corporation | Transaction diagnostic block |
| US9367323B2 (en) * | 2012-06-15 | 2016-06-14 | International Business Machines Corporation | Processor assist facility |
| US9442737B2 (en) | 2012-06-15 | 2016-09-13 | International Business Machines Corporation | Restricting processing within a processor to facilitate transaction completion |
| US9772854B2 (en) * | 2012-06-15 | 2017-09-26 | International Business Machines Corporation | Selectively controlling instruction execution in transactional processing |
| US9317460B2 (en) | 2012-06-15 | 2016-04-19 | International Business Machines Corporation | Program event recording within a transactional environment |
| US9448796B2 (en) | 2012-06-15 | 2016-09-20 | International Business Machines Corporation | Restricted instructions in transactional execution |
| CN105760265B (zh) * | 2012-06-29 | 2019-11-05 | 英特尔公司 | 用于测试事务性执行状态的指令和逻辑 |
| US9262170B2 (en) * | 2012-07-26 | 2016-02-16 | International Business Machines Corporation | Out-of-order checkpoint reclamation in a checkpoint processing and recovery core microarchitecture |
| US8893080B2 (en) * | 2012-08-15 | 2014-11-18 | Telefonaktiebolaget L M Ericsson (Publ) | Parallelization of dataflow actors with local state |
| CN106170761B (zh) * | 2012-09-27 | 2019-05-10 | 英特尔公司 | 用于在二进制转换中横跨多个原子区调度存储指令的方法和装置 |
| US9317297B2 (en) * | 2012-09-27 | 2016-04-19 | Intel Corporation | Replay execution of instructions in thread chunks in the chunk order recorded during previous execution |
| US9081607B2 (en) | 2012-10-24 | 2015-07-14 | International Business Machines Corporation | Conditional transaction abort and precise abort handling |
| WO2014100698A1 (en) * | 2012-12-20 | 2014-06-26 | Massachusetts Institute Of Technology | Methods and systems for enhancing hardware transactions using hardware transactions in software slow-path |
| US20140189310A1 (en) * | 2012-12-27 | 2014-07-03 | Nvidia Corporation | Fault detection in instruction translations |
| US9448799B2 (en) | 2013-03-14 | 2016-09-20 | Samsung Electronics Co., Ltd. | Reorder-buffer-based dynamic checkpointing for rename table rebuilding |
| US10108424B2 (en) | 2013-03-14 | 2018-10-23 | Nvidia Corporation | Profiling code portions to generate translations |
| US9575722B2 (en) * | 2013-03-14 | 2017-02-21 | International Business Machines Corporation | Software interface for a specialized hardward device |
| US9473561B2 (en) * | 2013-03-15 | 2016-10-18 | International Business Machines Corporation | Data transmission for transaction processing in a networked environment |
| US9304863B2 (en) * | 2013-03-15 | 2016-04-05 | International Business Machines Corporation | Transactions for checkpointing and reverse execution |
| US9424138B2 (en) | 2013-06-14 | 2016-08-23 | Nvidia Corporation | Checkpointing a computer hardware architecture state using a stack or queue |
| US9116719B2 (en) * | 2013-06-27 | 2015-08-25 | Intel Corporation | Partial commits in dynamic binary translation based systems |
| US20150188797A1 (en) * | 2013-12-27 | 2015-07-02 | Guy Satat | Adaptive admission control for on die interconnect |
| US9965320B2 (en) | 2013-12-27 | 2018-05-08 | Intel Corporation | Processor with transactional capability and logging circuitry to report transactional operations |
| US9317379B2 (en) * | 2014-01-24 | 2016-04-19 | International Business Machines Corporation | Using transactional execution for reliability and recovery of transient failures |
| US9329946B2 (en) * | 2014-02-27 | 2016-05-03 | International Business Machines Corporation | Salvaging hardware transactions |
| US9311178B2 (en) * | 2014-02-27 | 2016-04-12 | International Business Machines Corporation | Salvaging hardware transactions with instructions |
| US20150242216A1 (en) * | 2014-02-27 | 2015-08-27 | International Business Machines Corporation | Committing hardware transactions that are about to run out of resource |
| US9336097B2 (en) * | 2014-02-27 | 2016-05-10 | International Business Machines Corporation | Salvaging hardware transactions |
| US10120681B2 (en) | 2014-03-14 | 2018-11-06 | International Business Machines Corporation | Compare and delay instructions |
| US9558032B2 (en) | 2014-03-14 | 2017-01-31 | International Business Machines Corporation | Conditional instruction end operation |
| US9454370B2 (en) | 2014-03-14 | 2016-09-27 | International Business Machines Corporation | Conditional transaction end instruction |
| US9720661B2 (en) * | 2014-03-31 | 2017-08-01 | International Businesss Machines Corporation | Selectively controlling use of extended mode features |
| US9195593B1 (en) * | 2014-09-27 | 2015-11-24 | Oracle International Corporation | Hardware assisted object memory migration |
| US10324768B2 (en) * | 2014-12-17 | 2019-06-18 | Intel Corporation | Lightweight restricted transactional memory for speculative compiler optimization |
| GB2533416A (en) * | 2014-12-19 | 2016-06-22 | Advanced Risc Mach Ltd | Monitoring utilization of transactional processing resource |
| GB2536871A (en) * | 2015-03-04 | 2016-10-05 | Advanced Risc Mach Ltd | An apparatus and method to generate trace data in response to transactional execution |
| GB2539958B (en) * | 2015-07-03 | 2019-09-25 | Advanced Risc Mach Ltd | Data processing systems |
| US9703537B2 (en) * | 2015-11-02 | 2017-07-11 | International Business Machines Corporation | Method for defining alias sets |
| US11188336B2 (en) | 2015-12-28 | 2021-11-30 | Qualcomm Incorporated | Replay of partially executed instruction blocks in a processor-based system employing a block-atomic execution model |
| GB2554096B (en) * | 2016-09-20 | 2019-03-20 | Advanced Risc Mach Ltd | Handling of inter-element address hazards for vector instructions |
| US10621090B2 (en) | 2017-01-12 | 2020-04-14 | International Business Machines Corporation | Facility for extending exclusive hold of a cache line in private cache |
| US10521351B2 (en) | 2017-01-12 | 2019-12-31 | International Business Machines Corporation | Temporarily suppressing processing of a restrained storage operand request |
| US10409815B2 (en) * | 2017-02-27 | 2019-09-10 | Sap Se | SQLScript compilation tracing system |
| US10915527B2 (en) * | 2017-06-07 | 2021-02-09 | International Business Machines Corporation | Parallel search of a partitioned data set extended (PDSE) in parallel |
| US10572387B2 (en) | 2018-01-11 | 2020-02-25 | International Business Machines Corporation | Hardware control of CPU hold of a cache line in private cache where cache invalidate bit is reset upon expiration of timer |
| FR3083343B1 (fr) * | 2018-06-29 | 2023-05-26 | Ingenico Group | Procede de determination d'une validite d'un code applicatif, dispositif et produit programme d'ordinateur correspondants. |
| US11113251B2 (en) * | 2018-09-05 | 2021-09-07 | Vast Data Ltd. | Transaction manager |
| US10929139B2 (en) * | 2018-09-27 | 2021-02-23 | Qualcomm Incorporated | Providing predictive instruction dispatch throttling to prevent resource overflows in out-of-order processor (OOP)-based devices |
| CN118012448A (zh) * | 2018-12-03 | 2024-05-10 | 纳格拉影像有限公司 | 虚拟平台系统的安全部署和操作 |
| US10838723B1 (en) | 2019-02-27 | 2020-11-17 | Apple Inc. | Speculative writes to special-purpose register |
| US11281582B2 (en) | 2020-01-14 | 2022-03-22 | International Business Machines Corporation | Completion logic performing early commitment of a store-conditional access based on a flag |
| US11361400B1 (en) | 2021-05-06 | 2022-06-14 | Arm Limited | Full tile primitives in tile-based graphics processing |
| US20230289075A1 (en) * | 2022-03-14 | 2023-09-14 | Western Digital Technologies, Inc. | Data Storage Device and Method for Host-Initiated Transactional Handling for Large Data Set Atomicity Across Multiple Memory Commands |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20000076584A (ko) * | 1999-02-03 | 2000-12-26 | 포만 제프리 엘 | 컴퓨터 프로세싱 시스템에서의 로드 연산을 재순서화하기위한 방법 및 장치 |
| KR20050013544A (ko) * | 2002-04-30 | 2005-02-04 | 어드밴스드 마이크로 디바이시즈, 인코포레이티드 | 로드 동작들의 추론적 결과들을 레지스터 값들에링크시키는 시스템 및 방법 |
Family Cites Families (31)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2610926B2 (ja) * | 1988-02-20 | 1997-05-14 | 日本電気株式会社 | トランザクション制御方式 |
| JP3097873B2 (ja) * | 1991-11-18 | 2000-10-10 | 日本電気株式会社 | トランザクション制御方式 |
| US6112019A (en) * | 1995-06-12 | 2000-08-29 | Georgia Tech Research Corp. | Distributed instruction queue |
| GB9526717D0 (en) | 1995-12-29 | 1996-02-28 | Shine Thomas A | Digital frequency generator |
| US7257780B2 (en) * | 2000-08-07 | 2007-08-14 | Altera Corporation | Software-to-hardware compiler |
| US6658656B1 (en) | 2000-10-31 | 2003-12-02 | Hewlett-Packard Development Company, L.P. | Method and apparatus for creating alternative versions of code segments and dynamically substituting execution of the alternative code versions |
| US7131119B2 (en) | 2001-05-30 | 2006-10-31 | International Business Machines Corporation | Code optimization |
| US20020194244A1 (en) * | 2001-06-01 | 2002-12-19 | Joan Raventos | System and method for enabling transaction-based service utilizing non-transactional resources |
| US20050071438A1 (en) | 2003-09-30 | 2005-03-31 | Shih-Wei Liao | Methods and apparatuses for compiler-creating helper threads for multi-threading |
| US7383290B2 (en) | 2004-03-09 | 2008-06-03 | Hewlett-Packard Development Company, L.P. | Transaction processing systems and methods utilizing non-disk persistent memory |
| US7496735B2 (en) | 2004-11-22 | 2009-02-24 | Strandera Corporation | Method and apparatus for incremental commitment to architectural state in a microprocessor |
| US7984248B2 (en) | 2004-12-29 | 2011-07-19 | Intel Corporation | Transaction based shared data operations in a multiprocessor environment |
| US8799882B2 (en) | 2005-12-07 | 2014-08-05 | Microsoft Corporation | Compiler support for optimizing decomposed software transactional memory operations |
| US20080005332A1 (en) | 2006-06-08 | 2008-01-03 | Georgia Tech Research Corporation | Method for Opportunistic Computing |
| US7496707B2 (en) * | 2006-08-22 | 2009-02-24 | International Business Machines Corporation | Dynamically scalable queues for performance driven PCI express memory traffic |
| US8060728B2 (en) | 2007-05-14 | 2011-11-15 | Apple Inc. | Generating stop indicators during vector processing |
| US7516365B2 (en) * | 2007-07-27 | 2009-04-07 | Sun Microsystems, Inc. | System and method for split hardware transactions |
| US7966459B2 (en) | 2007-12-31 | 2011-06-21 | Oracle America, Inc. | System and method for supporting phased transactional memory modes |
| WO2009098739A1 (ja) | 2008-02-05 | 2009-08-13 | Panasonic Corporation | プログラム最適化装置およびプログラム最適化方法 |
| WO2009114645A1 (en) * | 2008-03-11 | 2009-09-17 | University Of Washington | Efficient deterministic multiprocessing |
| JP2011529603A (ja) | 2008-07-28 | 2011-12-08 | アドバンスト・マイクロ・ディバイシズ・インコーポレイテッド | バーチャル化可能な高度な同期機構 |
| US9189233B2 (en) * | 2008-11-24 | 2015-11-17 | Intel Corporation | Systems, apparatuses, and methods for a hardware and software system to automatically decompose a program to multiple parallel threads |
| US8612929B2 (en) * | 2008-12-10 | 2013-12-17 | Oracle America, Inc. | Compiler implementation of lock/unlock using hardware transactional memory |
| US20110208921A1 (en) | 2010-02-19 | 2011-08-25 | Pohlack Martin T | Inverted default semantics for in-speculative-region memory accesses |
| US8688963B2 (en) | 2010-04-22 | 2014-04-01 | Oracle International Corporation | Checkpoint allocation in a speculative processor |
| US9880848B2 (en) | 2010-06-11 | 2018-01-30 | Advanced Micro Devices, Inc. | Processor support for hardware transactional memory |
| US8560816B2 (en) | 2010-06-30 | 2013-10-15 | Oracle International Corporation | System and method for performing incremental register checkpointing in transactional memory |
| US8549504B2 (en) | 2010-09-25 | 2013-10-01 | Intel Corporation | Apparatus, method, and system for providing a decision mechanism for conditional commits in an atomic region |
| US20120079245A1 (en) * | 2010-09-25 | 2012-03-29 | Cheng Wang | Dynamic optimization for conditional commit |
| US9424015B2 (en) * | 2011-02-08 | 2016-08-23 | Oracle International Corporation | System and method for optimizing software transactional memory operations using static caching of memory objects |
| US9146950B1 (en) * | 2012-12-14 | 2015-09-29 | Symantec Corporation | Systems and methods for determining file identities |
-
2010
- 2010-09-25 US US12/890,639 patent/US8549504B2/en active Active
-
2011
- 2011-09-26 TW TW100134554A patent/TWI546733B/zh not_active IP Right Cessation
- 2011-09-26 SG SG2013018742A patent/SG188993A1/en unknown
- 2011-09-26 EP EP11827728.4A patent/EP2619654B1/en not_active Not-in-force
- 2011-09-26 KR KR1020137007981A patent/KR101496063B1/ko not_active IP Right Cessation
- 2011-09-26 JP JP2013529453A patent/JP5661934B2/ja not_active Expired - Fee Related
- 2011-09-26 WO PCT/US2011/053285 patent/WO2012040715A2/en active Application Filing
- 2011-09-26 KR KR1020147018278A patent/KR101529846B1/ko active IP Right Grant
- 2011-09-26 CN CN201180046077.7A patent/CN103119556B/zh not_active Expired - Fee Related
-
2013
- 2013-05-13 US US13/893,238 patent/US9146844B2/en not_active Expired - Fee Related
-
2015
- 2015-09-28 US US14/867,950 patent/US9817644B2/en not_active Expired - Fee Related
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20000076584A (ko) * | 1999-02-03 | 2000-12-26 | 포만 제프리 엘 | 컴퓨터 프로세싱 시스템에서의 로드 연산을 재순서화하기위한 방법 및 장치 |
| KR20050013544A (ko) * | 2002-04-30 | 2005-02-04 | 어드밴스드 마이크로 디바이시즈, 인코포레이티드 | 로드 동작들의 추론적 결과들을 레지스터 값들에링크시키는 시스템 및 방법 |
Also Published As
| Publication number | Publication date |
|---|---|
| KR20140091779A (ko) | 2014-07-22 |
| TW201220183A (en) | 2012-05-16 |
| US9817644B2 (en) | 2017-11-14 |
| EP2619654B1 (en) | 2018-08-01 |
| JP5661934B2 (ja) | 2015-01-28 |
| US9146844B2 (en) | 2015-09-29 |
| US20130318507A1 (en) | 2013-11-28 |
| JP2013541094A (ja) | 2013-11-07 |
| EP2619654A2 (en) | 2013-07-31 |
| CN103119556A (zh) | 2013-05-22 |
| KR101496063B1 (ko) | 2015-02-25 |
| WO2012040715A3 (en) | 2012-06-21 |
| US8549504B2 (en) | 2013-10-01 |
| EP2619654A4 (en) | 2016-11-16 |
| CN103119556B (zh) | 2016-01-20 |
| SG188993A1 (en) | 2013-05-31 |
| US20160019038A1 (en) | 2016-01-21 |
| TWI546733B (zh) | 2016-08-21 |
| WO2012040715A2 (en) | 2012-03-29 |
| KR20130064792A (ko) | 2013-06-18 |
| US20120079246A1 (en) | 2012-03-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR101529846B1 (ko) | 원자 영역에서 조건부 커미트를 위한 결정 메카니즘 제공 장치, 방법, 및 시스템 | |
| EP2619655B1 (en) | Apparatus, method, and system for dynamically optimizing code utilizing adjustable transaction sizes based on hardware limitations | |
| JP6095670B2 (ja) | コンピュータ・システム内のオペランド活性情報の維持 | |
| KR101025354B1 (ko) | 가상 트랜잭션 메모리를 위한 글로벌 오버플로우 방법 | |
| JP2013541094A5 (ko) | ||
| RU2501071C2 (ru) | Механизм запроса поздней блокировки для пропуска аппаратной блокировки (hle) | |
| US7877630B1 (en) | Trace based rollback of a speculatively updated cache | |
| US20140047219A1 (en) | Managing A Register Cache Based on an Architected Computer Instruction Set having Operand Last-User Information | |
| EP2513803A2 (en) | Performing mode switching in an unbounded transactional memory (utm) system | |
| US8051247B1 (en) | Trace based deallocation of entries in a versioning cache circuit | |
| US7779307B1 (en) | Memory ordering queue tightly coupled with a versioning cache circuit | |
| US8370576B1 (en) | Cache rollback acceleration via a bank based versioning cache ciruit |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A107 | Divisional application of patent | ||
| A201 | Request for examination | ||
| E902 | Notification of reason for refusal | ||
| E701 | Decision to grant or registration of patent right | ||
| GRNT | Written decision to grant | ||
| FPAY | Annual fee payment |
Payment date: 20180529 Year of fee payment: 4 |