KR100867564B1 - 프로그램 제어 흐름에서 변경들을 이루기 위한 장치 및 방법 - Google Patents

Abstract

데이터 프로세서는 테이블 점프들의 테스크들과 카운터 또는 타이머와 같은 실행값에 의해 제어되는 임계 또는 테스크 스위칭을 조합시키는 것에 의해 효율적인 번역기 기능을 달성하기 위해 명령(JAVASW)을 실행한다. 명령의 실행은 항상 취해지는 흐름의 변경을 필요로 한다. 한 형식에서, 명령은 명령 실행을 완성하기 위해 시그널링되는 하드웨어 가속기를 유발할 수 있다. 부가적으로, 특정 바이트코드들로 연관된 에뮬레이션 코드를 포함하는 메모리 테이블은 개별적인 저장 디바이스의 사용에 의해 식별된 다량의 바이트코드들에 대해 압축될 수 있다. 또한, 메모리 테이블의 동일한 부분의 사용은 다른 바이트코드들의 실행과 연관되어 일어날 수 있다. 자바 바이트코드들의 문맥에서 논의되었지만, 명령은 임의의 프로그래밍 언어 및 프로세서 아키텍처로 응용가능하다.

실행, 명령, 바이트코드.

Description

프로그램 제어 흐름에서 변경들을 이루기 위한 장치 및 방법{Apparatus and method for effecting changes in program control flow}

본 발명은 데이터 처리 시스템들에 관한 것으로, 특히 데이터 처리 명령들의 실행을 구현하는 소프트웨어 번역기를 구비하는 시스템들에 관한 것이다.

자바 프로그래밍 언어는 선 마이크로 시스템즈 잉크.(Sun Microsystems Inc.)에 의해 개발된 객체 지향 하이 레벨 프로그래밍 언어이며, 소형 개인 컴퓨터들에서 슈퍼 컴퓨터들까지 넓은 범위의 컴퓨터 영역에서 실행되기에 충분히 휴대될 수 있도록 설계되었다. 자바(및 다른 언어들)에 의해 기록된 컴퓨터 프로그램들은 자바 가상 머신(JVM: Java Virtual Machine)에 의한 실행을 위해 가상 머신 명령들로 컴파일될 수 있다. 일반적으로, 자바 가상 머신은 가상 머신 명령들을 디코딩하고 실행하는 번역기이다.

자바 가상 머신에 대한 가상 머신 명령들은 바이트코드들이며, 그들이 하나 이상의 바이트들을 포함한다는 것을 의미한다. 바이트코드들은 "클래스 파일(class file)"이라고 불리는 특정 파일 포맷에 저장된다. 바이트코드들 외에도, 클래스 파일은 다른 부수적인 정보뿐만 아니라 심볼 테이블을 포함한다.

하나 이상의 클래스 파일들에 있는 자바 바이트코드들로 구현된 컴퓨터 프로그램은 플랫폼에 독립이다. 컴퓨터 프로그램은 자바 가상 머신의 구현을 실행할 수 있는 임의의 컴퓨터 상에서 실행되고, 수정되지 않을 수 있다. 자바 가상 머신은 "일반적인(generic)" 컴퓨터의 소프트웨어 에뮬레이터이고, 이는 자바 가상 머신에 대한 컴퓨터 프로그램들이 플랫폼에 독립이 되도록 하는 주요 요인이다.

자바 가상 머신은 일반적으로 소프트웨어 번역기로서 구현된다. 종래의 번역기들은 실행 동안 한번에 한 명령씩 번역된 프로그램의 가상 머신 명령들을 디코딩하고 실행한다. 이에 반해, 컴파일러들은 실행 전에 가상 머신 명령들을 본래의 머신 명령들로 변환하여, 디코딩은 실행 동안 가상 머신 명령들 상에서 실행되지 않는다. 종래의 번역기들은 명령이 충돌될 때마다 실행되기 전에 각 명령을 반복적으로 디코딩하기 때문에, 번역된 프로그램들의 실행은 컴파일된 프로그램들의 본래의 머신 명령들이 본래의 머신 또는 컴퓨터 시스템 상에서 직접적으로 실행될 수 있으므로 컴파일된 프로그램들보다 통상적으로 상당히 느리다.

번역된 프로그램을 디코딩하고 실행하기 위해 소프트웨어 번역기가 실행되어야 함에 따라, 소프트웨어 번역기는 더 이상 번역된 프로그램에 사용가능하지 않는 자원들(예를 들면, 메모리)을 소비한다. 이는 본래의 머신 명령들로서 실행할 컴파일된 프로그램들과 대조적으로 그들은 타겟 컴퓨터 상에서 직접적으로 실행될 수 있고, 따라서 일반적으로 번역된 프로그램들보다 적은 자원들을 요구한다.

따라서, 번역될 컴퓨터 프로그램들의 실행 속도를 증가시키기 위한 새로운 기술들이 필요하다. 부가적으로, 그들이 원하는 자원들에 대하여 효율적인 번역기들을 제공하는 것이 필요하다.

많은 임베딩된 디바이스들이 플랫폼 독립과 자바 언어의 편재하는 특성 및 자바 가상 머신 구현들의 개발 때문에 자바 인에이블된다. 많은 저가 임베딩된 시스템들은 전용 자바 프로세서 또는 하드웨어 가속기(예를 들면, 개별 공동 프로세서(co-processor))의 하드웨어 오버헤드를 회피하기 위해 JVM으로서 자바 처리 기능을 구현하도록 요구한다. JVM을 구현하고 자바 프로그램을 실행하는 직접적인 접근은 소프트웨어 번역기의 사용을 통하는 것이다.

번역기는 번역된 명령 스트림의 명령 패치, 디코딩, 및 실행의 표준 함수들을 실행한다는 점에서 프로세서의 소프트웨어 버전을 구현한다. 번역기는 통상적으로 페치, 디코딩, 및 실행 단계들을 반복하는 프로그램 루프로서 구현된다.

자바 명령들(바이트코드들)이 페치됨에 따라, 번역기는 가상 프로그램 카운터(자바 PC)를 유지하고, 각 번역된 자바 명령의 디코딩은 바이트코드의 각 2진 인코딩에 대응하는 조항들을 갖는 큰 케이스 명령문(statement)(스위치 명령문)에 의해 실행된다. 각 조항 내의 코드는 바이트코드에 의해 정의된 실질적인 동작을 실행한다.

바이트코드가 페치되고 디코딩되어야 하기 때문에 각 바이트코드의 처리와 연관된 오버헤드가 있다. 많은 자바 명령들(바이트코드들)이 간단한 동작들을 실행하기 때문에 시퀀스의 페치 및 디코딩 부분들과 연관된 오버헤드는 모든 실행 시간의 큰 비율이 될 수 있다.

자바 환경이 실행의 많은 스레드(thread)들의 개념을 지지하기 때문에, 번역기 루프의 부가의 기능은 스레드(또는 테스크(task)) 스위치가 발생할 때의 결정에서 사용되는 카운터를 유지하는 것이다.

자바 가상 머신의 일부 구현들에서, 스레드 스위치 결정은 실행된 자바 바이트코드들의 수에 의존한다. 번역기 루프가 실행되는 각 시간에 변경되는 카운터 값을 유지하고, 이를 미리 결정된 값과 비교하는 것에 의해, 번역기는 스레드 스위치 논리도 구현한다. 스레드 스위치가 또한 심각한 오버헤드를 생성시킬 때 카운터를 유지하고 결정한다. 이러한 오버헤드는 소프트웨어 번역기의 동작 효율을 상당히 제한한다.

도 1은 데이터 처리 시스템을 도시하는 블럭도.

도 2는 자바 프로그램이 실행될 때의 실행 흐름을 도시하는 알려진 코드 시퀀스.

도 3은 도 2의 자바 프로그램 실행과 연관된 번역기 오버헤드의 알려진 다이어그램.

도 4는 본 발명에 따라 프로그램이 실행될 때의 자바 프로그램 및 대응하는 에뮬레이션 코드.

도 5는 허용된 그룹 크기보다 많은 에뮬레이션 코드를 요구하는 자바 프로그램 실행의 본 발명에 따른 예를 도시하는 도면.

도 6은 본 발명에 따른 명령 슬롯들의 한 할당을 도시하는 통상적인 에뮬레이션 코드 테이블.

도 7은 본 발명에 따라 자바 프로그램에서 명령 흐름을 스위칭하기 위한 자바 번역기 명령의 설명을 도시하는 도면.

도 8은 본 발명에 따라 프로그램 실행을 구현하기 위한 도 1의 시스템의 데이터 프로세서 부분의 블럭도.

도 9는 본 발명에 따라 명령 슬롯들의 다른 할당을 도시하는 통상적인 에뮬레이션 코드 테이블을 도시하는 도면.

본 발명은 예로써 설명되고 첨부한 도면들에 제한되지는 않으며, 동일한 참조기호들은 유사한 요소들을 나타낸다. 다음 설명에서, 다수의 특정 상세한 설명들이 본 발명의 완전한 이해를 제공하기 위해 특정 워드 또는 바이트 길이들 등으로 설명된다. 그러나, 본 발명은 이러한 특정 상세한 설명들 없이도 실행될 수 있다는 것이 당업자에게 명백할 것이다. 다른 예들에서, 회로들은 필요하지 않은 상세한 부분들로 본 발명을 불명료하게하지 않기 위하여 블록 다이어그램 형식으로 도시되었다. 대부분, 시간을 고려하는 것들에 관계된 상세한 부분들 등은 본 발명의 완전한 이해를 얻는데 불필요하고 관련 분야의 당업자의 기술들 내에 있으므로 생략되었다.

"버스(bus)"라는 용어는 데이터, 어드레스들, 제어, 또는 상태들과 같은 정보의 하나 이상의 다양한 유형들을 전송하는데 사용될 수 있는 복수의 신호들 또는 컨덕터들을 나타내는데 사용될 것이다. "주장하다(assert)" 및 "부인하다(negate)"라는 용어는 신호의 렌더링(rendering), 상태 비트, 또는 유사한 장치가 각각 그의 논리적인 참 또는 논리적인 거짓 상태로 참조될 때 사용될 것이다. 논리적 참 상태가 논리 레벨 1이면, 논리적 거짓 상태는 논리 레벨 0이 될 것이다. 또한 논리적 참 상태가 논리 레벨 0이면, 논리적 거짓 상태는 논리 레벨 1이 될 것이다. 다음 설명 및 도면들에서, '0x'를 갖는 프리팬딩에 의한 일부 값들에 대해 16진법이 사용된다. 따라서 값 0xff는 십진수값 255에 대응한다.

도 1은 데이터 처리 시스템(10)의 한 실시예를 도시하는 블럭도로, 버스(28)로 모두 양방향으로 접속되는 프로세서(12), 공동 프로세서(14), 공동 프로세서(16), 메모리(18), 다른 모듈들(20) 및 외부 버스 인터페이스(22)를 포함한다. 본 발명의 대안의 실시예들은 단지 하나의 공동 프로세서(14), 두 개의 공동 프로세서들(14 및 16) 또는 그 이상의 공동 프로세서들(도시되지 않음)을 가질 수 있다. 외부 버스 인터페이스(22)는 집적 회로 단말기들(35)에 의해 외부 버스(26)에 양방향으로 결합된다. 메모리(24)는 외부 버스(26)에 양방향으로 결합된다. 프로세서(12)는 선택적으로 집적 회로 단말기들(31)에 의해 데이터 처리 시스템(10)으로 외부로 결합될 수 있다. 공동 프로세서(14)는 선택적으로 집적 회로 단말기들(32)에 의해 데이터 처리 시스템(10)으로 외부로 결합될 수 있다. 메모리(18)는 선택적으로 집적 회로 단말기들(33)에 의해 데이터 처리 시스템(10)으로 외부로 결합될 수 있다. 다른 모듈들(20)도 선택적으로 집적 회로 단말기들(34)에 의해 데이터 처리 시스템(10)으로 외부로 결합될 수 있다. 프로세서(12)는 공동 프로세서 인터페이스(30)에 의해 공동 프로세서(14) 및 공동 프로세서(16) 모두에 양방향으로 결합된다. 데이터 처리 시스템(10) 내의 프로세서(12)의 특정 동작은 자바 코드 실행의 문맥에서 이하로 참조될 것이다.

도 2 및 3을 참조하면, 자바 프로그램에서 명령들의 종래의 실행 흐름의 예가 주어질 것이다. 알려진 번역기들에서의 중요한 실행 문제는 많은 양의 시간이 명령 흐름이 바뀔 때 및 각 에뮬레이트된 자바 바이트코드 사이에서 번역기 오버헤드 루틴을 실행할 때 소프트웨어에 의해 소비된다는 사실이다. 명령 실행 단계들 중 도 2의 도시는 이러한 점을 부각시킬 것이다. 도 2의 1 내지 7의 단계들의 식별된 모든 단계가 소프트웨어 프로그램에서 흐름의 변경을 요구한다는 것에 주의한다. 종래 기술에서, 번역기 오버헤드(54)와 같은 하나 이상의 소프트웨어 루틴들은 반복적으로 점프되어야 하고 이는 부가의 번역기 오버헤드를 생성한다. 도 3은 도 2와 동일한 소프트웨어 루틴이지만 a, f, 및 c와 같은 다양한 함수들에 대한 에뮬레이션 코드를 실행하기 위해 필요한 소프트웨어와 시간의 더 적은 양으로 비교된 번역기 오버헤드 루틴을 실행하는데 필요한 시간과 소프트웨어의 양 사이의 관계를 더 명확하게 도시한다. 번역기 오버헤드 소프트웨어는 자바 바이트코드의 페치, 디코딩, 및 디스패칭(dispatching)을 포함한다. 디스패칭은 에뮬레이트된 자바 바이트코드로 대응하는 에뮬레이션 코드로 점프하도록 실행된 단계이다. 번역기 오버헤드는 또한 스레드 스위칭이 발생될 때 결정하기 위한 카운터 함수를 실행하기 위해 소프트웨어를 포함한다는 것에 주의한다. 번역기 오버헤드(54) 소프트웨어는 또한 업데이트되어 유지되어야 하는 자바 가상 머신에 대한 가상 프로그램 카운터를 포함한다는 것을 주의한다. 도 2 및 도 3은 자바 프로그램에 의해 요구된 바이트코드들을 실질적으로 실행하기 위하여 프로세서(예를 들면, 도 1의 프로세서(12))에 의해 요구되는 자바 프로그램 바이트코드들 및 에뮬레이션 코드 테이블 모두를 도시한다는 것에 주의한다. 프로세서(12)에 의해 실행되는 각각의 자바 바이트코드에 대하여, 자바 바이트코드의 에뮬레이션을 실행하기 위해 요구되는 코드는 두개의 구성성분들을 요구한다는 것이 주의된다. 제 1 구성성분은 함수(a,f,c)를 실질적으로 실행하기 위해 코딩되고, 제 2 구성성분은 번역기 오버헤드(54) 소프트웨어로 에뮬레이션 코드의 실행을 되돌리는 소프트웨어 루틴이다. 도 3을 참조하면, 두꺼운 선에 의해 도시된 번역기 오버헤드 소프트웨어는 자바 바이트코드를 실행하기 위해 요구되는 소프트웨어의 매우 중요한 부분일 수 있다는 점이 주의된다. 결과적으로, 본원은 에뮬레이션 코드의 번역기 오버헤드 부분을 실행하기 위해 요구된 소프트웨어와 시간의 양을 효율적으로 감소시키는 시스템 및 방법을 개시한다. 각 함수(a,f,c)를 실행하기 위해 요구된 에뮬레이션 코드는 크기가 상당량 변화할 수 있고 통상적으로 변화하며, 종종 비교적 작은 코드의 양이라는 점을 도 2로부터 주지해야 한다. 대조적으로, 번역기 오버헤드(54) 소프트웨어는 특정 자바 바이트코드를 실행하기 위해 요구된 에뮬레이션 코드와 비교되는 코드의 상당한 양이다.

이제 도 4를 참조하면, 자바 프로그램(60)의 한 예와 본 발명의 한 실시예에 따라 도 1의 프로세서(12)에 의해 실행될 수 있는 그의 대응 에뮬레이션 코드 테이블(62)이 도시된다. 도 4에 도시된 본 발명의 프로그램 실행 실시예에서 각 자바 바이트코드는 에뮬레이션 코드 테이블(62)에 대응하는 그룹을 가진다는 점이 주의된다. 일반적으로, 각 그룹은 프로그램의 미리 결정된 OP 코드(OPcode)에 관련되고, 본 발명은 단지 자바 프로그램들과의 사용으로만 제한되지 않는다. 바이트코드들(a, f, c...)의 바이트코드 실행은 도시된 바와 같이 단계들 1, 2 및 3의 순서로 코드의 에뮬레이션 코드 테이블(62)에서의 검색(retrieval)으로 일어난다. 도 4에 도시된 발명의 특정 실시예에서, 0x0, 0x1, 등과 같은 자바 바이트코드 16진수 값에 의해 정의된 에뮬레이션 코드 테이블(62)의 각 코드 그룹은 16개의 프로세서(12) 명령들을 포함한다. 16이라는 숫자는, 존재하는 사용되지 않는 슬롯들을 초과하지 않도록 하고 대부분의 자바 바이트코드들을 에뮬레이트하기에 충분한 명령 슬롯들을 제공하는 값으로 선택되었다. 일부 자바 바이트코드들은 실행을 위해 16개의 프로세서(12) 명령들보다 적게 취해질 것이고, 일부는 더 많이 취해질 것이다. 결과적으로, 본 발명의 대안의 실시예들은 각 그룹에 대하여 프로세서(12)의 임의의 숫자의 명령 슬롯들을 사용할 수 있다는 것이 잘 이해되어야 한다. 또한, 그룹들의 숫자는 보다 높은 레벨의 언어에 의해 요구된 바이트코드들의 수에 따라 변화할 수 있다. 번역기 오버헤드 소프트웨어는 에뮬레이션 코드에 의해 점프되어야 하는 개별적인 루틴으로서 더이상 요구되지 않는다는 것이 또한 주의된다. 도 2에 도시된 바와 같이 종래 기술에 의해 요구된 번역기 오버헤드는 "오버헤드 플러스 JAVASW"로 라벨링되는 각 그룹에서 사용된 코드 블럭에 의해 대체되었다. 코드의 "오버헤드 플러스 JAVASW" 블럭은 이제 프로세서(12)에 의해 실행된 에뮬레이션 코드에 전체적으로 분포된다는 것이 주의된다. 도 4에 도시된 소프트웨어 플로우와 에뮬레이션 코드 테이블은 도 2에 도시된 종래 기술에 비교하여 더 적은 플로우 단계들의 변경을 갖는다는 것이 주의된다. 플로우의 변경은 점프 명령을 실행하기보다는 제어 변경의 한 형식이고, 실행될 수 있는 동작은 사용자 및 전문가 모드들 사이에서의 전환과 같은 제어의 변경이 구현되는 다른 동작일 수 있다는 것이 이해되어야 한다. 본 발명에 의해 제공된 흐름 단계들의 변경에서의 감소는 소프트웨어 오버헤드의 상당한 양을 절약한다. 도 2 및 도 4 모두에서 도시된 화살표들은 실행을 위해 부가적인 소프트웨어를 요구한다는 것을 인지하는 것이 중요하다. 각 자바 바이트코드가 도 4에 도시된 실시예에서 16개의 명령 슬롯들로 할당되었지만, 일부 특정 자바 바이트코드들은 16개의 모든 명령 슬롯들을 요구하지는 않을 것이다. 한편 일부 자바 바이트코드들은 에뮬레이션 코드에서 16개보다 많은 명령 슬롯들을 요구한다. 이러한 예가 도 5에서 논의될 것이다. 따라서, 도 4는 도 1의 프로세서(12)에 의해 실행될 수 있는 에뮬레이션 코드 테이블(62)을 도시한다. 도시된 형식에서, 코드 에뮬레이션 테이블(62)은 0x0 내지 0xFF의 16진수 어드레스들에 의해 식별되는 각 자바 바이트코드의 에뮬레이션에 대해 할당된 256과 동일한 크기의 그룹들을 갖는다. 따라서, 도 4에 도시된 에뮬레이션 코드 테이블은 자바 프로그램이 프로세서(12)에 의해 실행될 때 보다 많은 연속 흐름을 제공한다. 이러한 보다 많은 연속적인 흐름은 종래 기술에 의해 요구된 프로그램 흐름 변경들의 상당한 양에 대해 요구된 소프트웨어 오버헤드의 양을 감소시킨다(도 2 참조).

이제 도 5를 참조하면, 도 5는 본 발명이 어떻게 에뮬레이션 코드 테이블(63)에서 허용하는 그룹 크기보다 더 많은 에뮬레이션 코드를 요구하는 자바 바이트코드에 대하여 사용될 수 있는가를 도시한다. 도 5에는 에뮬레이션 코드 테이블(63)이 도시된다. 도 5에 도시된 설명을 위해 에뮬레이션 코드의 초기 부분이 단계 1로의 화살표에 의해 표시된 어드레스 0x67에서 시작한다. 단계 2는 모든 16개의 명령 슬롯들이 사용되었음과 대응 바이트코드가 부가의 에뮬레이션 코드를 요구하고 있음을 나타낸다. 따라서, 단계 2는 자바 바이트코드의 실행을 종결하기 위하여 에뮬레이션 소프트웨어 흐름이 새롭고 사용가능한 코드 블럭으로 이동해야 한다는 것을 나타낸다. 도 5에 도시된 예에서, 단계 2는 코드 블럭이 자바 바이트코드의 실행을 완성하기 위해 위치될 수 있는 원래의 에뮬레이션 코드 테이블(62)의 끝부분을 넘어선 위치로 에뮬레이션 코드의 점프의 형태로 프로그램 실행이 리다이렉션(redirection) 하는 것을 도시한다. 이러한 부가의 코드는 임의의 크기일 수 있고 단지 시스템 자원들에 의해서 제한된다. 부가의 코드는, 실행될 나머지 자바 바이트코드 에뮬레이션 코드의 저장을 허용하기 위하여 사용가능한 자원들이 존재하는 시스템의 어디에라도 저장될 수 있다. 따라서, 선택된 점프 어드레스는 데이터 처리 시스템 내의 어드레스들의 총 범위보다 작은 어드레스들의 미리 결정된 범위(0x0 내지 0xff) 내에 있거나, 또는 선택된 점프 어드레스는 사용가능한 자원들이 존재하는 어디에서라도 저장을 위한 어드레스들의 미리 결정된 범위의 외부에 있을 수 있다는 것이 이해되어야 한다. 단계 3은, 그 특정 자바 바이트코드에 대한 에뮬레이션 코드가 일단 종결되었으면, 에뮬레이션 코드는 "오버헤드 플러스 JAVASW" 소프트웨어가 시작하는 위치에서 256 그룹들 내의 임의의 그룹들 중 하나로 다시 점프할 수 있음을 나타낸다. 따라서, 자바 바이트코드 에뮬레이션을 종결하기 위해 에뮬레이션 코드 테이블(63)의 끝부분에서 요구된 엑스트라(extra) 소프트웨어는 "오버헤드 플러스 JAVASW" 소프트웨어를 포함할 필요가 없다. 이러한 동작 특성은 자바 바이트코드가 에뮬레이션 코드 테이블(63)의 단지 한 그룹만을 사용하여 에뮬레이트될 수 없는 경우에 적어도 한 그룹의 "오버헤드 플러스 JAVASW" 소프트웨어 부분의 재사용을 허용한다.

도 6을 참조하면, 각 그룹으로 할당된 명령 슬롯들의 수를 선택하는 것은 중요한 일이다. 선택은 일반적으로 에뮬레이션 코드 테이블의 총 크기와 그룹 크기를 넘어 오버플로우(overflow)하는 자바 바이트코드들의 수 간의 트레이드오프(tradeoff)를 포함한다. 도 6에서 도시된 실시예는 그룹당 16개의 명령 슬롯들을 사용하였지만, 본 발명의 대안의 실시예들은 명령 슬롯들의 다른 수로 그룹 크기를 최적화할 것이다. 각 에뮬레이트된 바이트코드에 대하여 에뮬레이션 코드로 향하도록 사용된 어드레스 계산을 매우 간단화하도록 고정되는 그룹 크기를 갖는다는 것에 주의한다. 이는 각 명령에 대한 프로세서(12)에 대한 계산 시간의 상당한 양일 수 있으며, 데이터 처리 시스템(10)의 전체적인 수행에 상당히 영향을 줄 수 있다.

여전히 도 6을 참조하면, 하나 이상의 하드웨어 가속기들이 데이터 처리 시스템(10)의 성능을 개선시키기 위하여 데이터 처리 시스템(10)(도 1을 보면, 공동 프로세서들(14,16))의 일부로서 사용될 수 있다는 것에 주의한다. 공동 프로세서는 사용될 수 있는 하드웨어 가속기의 단 하나의 유형이라는 것을 이해해야 한다. 도 6을 참조하면, 하드웨어 가속기의 존재 또는 부재에 기초하여 어떻게 에뮬레이션 코드 테이블이 변경되는지를 보여주기 위하여 IADD(정수 부가) 루틴이 두 가지 방식들로 도시되었다. 정수 부가 기능은 단지 예로써 선택된다. 도 6의 "IADD" 루틴의 좌측에는, 하드웨어 가속기가 존재하지 않을 때의 프로세서(12)에 의해 실행될 수 있는 소프트웨어 루틴(80)이 있다. 우측의 코드(82)는 하드웨어 가속기(예를 들면, 공동 프로세서(14))가 존재할 때의 프로세서(12)에 의해 실행될 수 있는 루틴을 도시한다. 하드웨어 가속기는 자바 바이트코드의 실행의 중요한 부분을 실행하기 위해 사용될 수 있다는 것이 주의된다. 도 6의 코드의 좌측 및 우측 블럭들을 비교하면, 프로세서(12)에 의해 이전에 실행되어야 했던 상당한 수의 로드 및 저장 명령들은 하드웨어 가속기가 사용될 때 더 이상 필요하지 않다는 것이 명백하다. 도 8과 연관하여 더욱 상세히 설명될 바와 같이, 사용자 결정 가능한 제어 신호는 시스템 사용자에게 미리 결정된 코드 크기 그룹핑들의 제 1 에뮬레이션 테이블 구조 또는 다른 미리 결정된 코드 크기 그룹핑들의 제 2 에뮬레이션 테이블 구조를 선택하도록 허용하는 본 발명의 한 형태로 제공된다. 하드웨어 가속기 및 프로세서는 자바 바이트코드의 실행을 통신하고 조정하기 위하여 어떤 형태의 인터페이스 또는 핸드쉐이크 메카니즘을 가져야 한다는 것이 주의된다. 도 1을 참조하면, 프로세서(12) 및 공동 프로세서들(14, 16)이 공동 프로세서 인터페이스(30)에 의해 통신한다. 프로세서(12) 및 공동 프로세서들(14,16) 간의 통신은 스레드 스위칭이 자바 프로그램에서 일어날 수 있다는 점에서 복잡해질 수 있다는 것이 주의된다. 자바 프로그램의 실행 동안 테스크들을 스위칭할 필요가 있는지와 다른 테스크가 프로세서(12)의 부분을 실행하는 시간을 갖는 것을 허용하는가를 결정하기 위하여 적어도 소프트웨어의 한 부분이 주기적으로 체크되어야 한다. 자바의 소프트웨어 테스크들 사이의 이러한 스위칭 또는 변경은 스레드 스위칭으로 불린다. 도 1을 참조하면, 프로세서(12)는 스레드 스위칭이 발생하였는지의 여부에 기초하여 정확한 자바 바이트코드가 실행되었는지 여부를 조건적으로 공동 프로세서들(14,16)로 시그널링한다. 프로세서(12)가 또한 바이트코드를 실행하지 않았으면, 공동 프로세서가 자바 바이트코드를 실행하지 않고, 스레드 스위치가 실행될 때 일반적으로 실행된 자바 바이트코드가 현재의 스레드가 재시작할 때까지 실행되지 않고 남아있기 때문에 이러한 시그널링은 JAVASW 명령 실행의 일부이며, 스레드 스위치가 실행되지 않는다는 사실을 조건으로 한다. 공동 프로세서 인터페이스(30)는 프로세서(12) 및 공동 프로세서들(14,16)이 다른 것에 의해 실행될 소프트웨어 흐름으로 시야를 갖도록 허용하기 위하여 또한 스누핑(snooping) 또는 방송 신호들을 포함할 수 있다. 본 발명에 사용될 수 있는 임의의 알려진 프로세서 내지 공동 프로세서 인터페이스들의 하나에 대한 특정 정보에 대하여, 본원에 참조로 포함되는 미국 특허 제 5,983,338호를 참조할 수 있다.

도 6의 에뮬레이션 코드 테이블(72)은 256개의 어드레스가능한 그룹들(0x0 내지 0xff)을 포함하고, 각 그룹은 대응 자바 바이트코드로 할당된다는 것이 주의된다. 에뮬레이션 코드 테이블에서 자바 스레드 스위칭을 실행하기 위해 에뮬레이션 코드를 위치시키는 것이 바람직하다. 각 그룹에 고정된 명령 슬롯들의 수 때문에, 스레드 스위칭 소프트웨어를 위해 사용할 수 있는 에뮬레이션 코드 테이블(72)에 할당되지 않은 메모리 위치는 없다. 따라서, 스레드 스위칭 코드를 위치시키기 위해 하나 이상의 그룹들 내에 사용되지 않은 명령 슬롯들을 사용할 필요가 있다. 본 발명의 한 실시예에서, 스레드 스위칭 소프트웨어 루틴은 자바 바이트코드 0으로 대응하는 제 1 그룹에 위치된다. 이러한 그룹이 필요한 동작없는(NOP) 명령, 예를 들면 4개의 명령 슬롯들만으로 할당되므로, 스레드 스위칭을 실행하기 위해 소프트웨어 루틴의 적어도 한 부분을 저장하기 위한 12개의 사용되지 않은 명령 슬롯들이 남는다. 스레드 스위칭 루틴이 할당된 슬롯들 내에 맞추어지지 않으면, 점프는 에뮬레이션 코드 테이블(63)에 대하여 도 5에 도시된 바와 같은 에뮬레이션 코드 테이블(72)의 끝부분을 넘어선 위치로 이루어질 수 있다는 것이 주의된다. 본 발명의 대안의 실시예들은 에뮬레이션 코드 테이블(72) 내의 다른 위치들의 스레드 스위칭을 실행하기 위해 소프트웨어를 위치시킬 수 있다. 스레드 스위칭 소프트웨어를 위치시키기 위해 에뮬레이션 코드 테이블(72)에 이러한 제 1 그룹을 사용하는 것은 하드웨어가 프로세서(12)의 하드웨어를 사용하는 보다 직접적인 방법에서 구현될 JAVASW 명령(이하에서 다시 설명될)을 구현하도록 한다는 것이 주의된다.

도 7은 도 4 및 5의 에뮬레이션 테이블들에서 앞서 참조된 "JAVASW" 명령의 보다 상세한 도면이다. 본 발명의 한 실시예에서, JAVASW 명령은 프로세서(12)에 의해 실행되는 명령이다(도 1을 보라). JAVASW 명령의 실행이 더 명료하기 위해, 도 1로부터의 프로세서(12)의 상세한 부분이 또한 도 8에 도시된다. 도 8에 도시된 것은 명령 레지스터(116)이다. 명령 디코딩(104)은 명령 레지스터(116)의 출력에 접속된 컨덕터들(117)과 제어 회로(105)의 입력에 연관된 출력으로 명령 레지스터(116)로부터 프로세서(12) 명령을 수신하기 위한 입력을 갖는다. 제어 회로(105)는 또한 실행될 자바 바이트코드를 입력(118)에서 수신한다. 제어 회로(105)의 출력은 컨덕터들(130)을 통해 멀티플렉서(Mux)와 조합기(106)의 제어 입력과, 프로그램 카운터(108) 및 다른 레지스터들(109)을 갖는 레지스터들(107)의 입력/출력 단말기들, 산술 논리 유닛(ALU)(110)의 입력/출력 단말기, 및 어드레스 선택 논리(111)의 입력/출력 단말기로 접속된다. 증가 회로(112)는 컨덕터들(120)을 통해 어드레스 선택 논리(111)의 제 1 입력으로 접속된 출력을 갖는다. 점프 어드레스(121)는 어드레스 선택 논리(111)의 제 2 입력으로 접속된다. 제외 어드레스(122)는 어드레스 선택 논리(111)의 제 3 입력으로 접속되고, 브랜치 어드레스(123)는 어드레스 선택 논리(111)의 제 4 입력으로 접속된다. Mux 및 조합기(106)의 출력은 JAVASW 프로그램 카운터 어드레스(124)를 제공하기 위한 어드레스 선택 논리(111)의 제 5 입력으로 접속된다. 컨덕터들(123)은 증가 회로(112)의 입력으로, 어드레스 선택 논리(111)의 출력으로, 및 제어 회로(105)와의 통신을 위한 프로그램 카운터(108)의 입력/출력 단말로 접속된다. 점프 어드레스(121), 제외 어드레스(122) 및 브랜치 어드레스(123)는 제어 회로(105)에 의해 제공된다. Mux 및 조합기(106)는 상수 0x8(100)을 수신하기 위한 입력과, R4<<1과 동일한 값을 갖는 입력(하나 좌측으로 시프트되는 레지스터들(109)의 레지스터(R4)에서의 값)(101)과, R4<<5와 동일한 값을 갖는 입력(5만큼 좌측으로 시프트되는 레지스터들(109)의 레지스터(R4)에서의 값)(102), 테이블(103) 외측의 엔트리 포인트, 및 프로그램 카운터 값 플러스 2(PC+2)를 수신하는 입력을 갖는다. 제어 회로(105)는 하나 이상의 컨덕터들(134)에 의한 스위치 스레드 임계치를 수신하기 위한 부가의 입력을 갖는다.

도 7을 참조하면, JAVASW 명령의 한 실시예의 동작이 "쿼시-C(quasi-C)" 코드의 형태로 설명된다. 한 실시예에서, JAVASW 명령은 바이트코드 에뮬레이션 시퀀스로 점프를 야기한다. 식(92)은 이러한 바이트코드 에뮬레이션 시퀀스의 어드레스가 계산되는 방법을 도시한다. 괄호들 사이에 포함된 식(92)의 부분은 JAVASW 명령의 실행 동안 레지스터들(107)의 프로그램 카운터(108)(PC)로 로드되는 점프 어드레스를 나타낸다. 이러한 값은 컨덕터들(124)에 의해 어드레스 선택 논리(111)로 도 8의 Mux와 조합기(106)에 의해 제공된다. 식(92)의 값 "PC+2"은 프로그램 카운터(108)가 증가 회로(112)에 의해 증가된 후의 프로그램 카운터 값이다. 이러한 증가는 프로세서(12)의 실행 파이프라인의 본래의 단계에 따라 발생하고, 이후 기본 어드레스 값에 따라 사용하기 위해 편리해진다. 본 발명의 다른 실시예에서, 증가하지 않는 프로그램 카운터 값(PC)이 대신 사용될 수 있다. 증가된 프로그램 값은 이후 값 0xffffe000으로 논리적으로 AND된다. 이러한 불(boolean) 연산은 0에 가해지게 될 (PC+2)의 값의 하위(low order) 13 비트에 가한 영향을 가진다. 결과적인 어드레스는 에뮬레이션 코드 테이블(72)의 제 1 바이트코드 명령 그룹의 제 1 명령 슬롯으로 향한다(도 6 참조). 본 발명의 일부 실시예들에서 논리적인 AND는 요구되지 않을 것임을 주의한다. 대신, 값 PC+2의 하위 13 비트가 잘릴 수 있다. 이러한 포인터 값이 잘리지 않으면, 레지스터들(109)의 하나인 레지스터(R4)에 저장된 자바 바이트코드 값으로 논리적으로 OR되거나, 그룹 크기에 대응하는 양에 의해 시프트될 수 있다. 이러한 설명된 동작은 새로운 프로그램 카운터 어드레스를 에뮬레이션 테이블(72) 내의 정확한 위치로 효과적으로 인덱싱하고, 따라서 프로그램 카운터 레지스터는 이제 프로세서(12)에 의해 에뮬레이트되는 자바 바이트코드에 대한 정확한 명령 그룹의 시작으로 향한다. 포인터 값을 형성하는 대안의 방법은 레지스터(R4)에 저장된 자바 바이트코드 값을 갖는 PC+2의 상위 18 비트를 간단하게 연결시키는 것이며, 이후 32비트 어드레스를 형성하기 위해 0들의 5 비트로 결과를 패딩한다. 점프 어드레스는 폭넓은 방법들로 형성될 수 있다는 것이 주의된다. 그러나, 점프 어드레스를 형성하기 위해 사용된 다양한 기술들 또는 조합들과 관계없이, 결과는 항상 현재의 자바 바이트코드에 대응하는 에뮬레이션 코드 테이블(72) 내의 정확한 명령 그룹의 시작으로 향하는 어드레스이다(도 6 참조). 식(92)이 스레드 스위칭이 발생하지 않을 때 점프 어드레스를 계산하기 위해 사용된다는 것이 다시 주의된다. 스레드 스위칭은 명령문(91)이 참일 때 발생하지 않는다. 명령문(91)은 스위치 카운트(SWCOUNT) 임계치(프로그램의 변경이 데이터 처리 시스템에 의해 구현되어야 할 때의 포인트)가 다른 자바 스레드로의 변경이 발생하였는가를 결정하기 위해서 교차되었는지의 여부를 의미한다. 따라서, 명령문(91)은 예를 들면 미리 결정된 값, 스위치 카운트 임계치를 갖는 카운트 값과 같은 값의 비교 결정을 요구한다. 명령문(91)이 참이면, 제 1 결과이고, 명령문(91)이 참이 아니면 제 2 결과이다. 그러나 명령문(91)이 참이 아니면, 이후 "다른" 명령문(93)이 프로그램 카운터(1908)에 저장되는 점프 어드레스를 계산하기 위해 사용되는 식(94)에서 결과로서 나타난다. 식(94)의 AND 동작은 식(92)과 연관하여 위에서 설명된 바와 같은 동일한 AND 동작일 수 있다는 점이 주의된다. 그러나, 식(94)의 OR 동작은 스레드 스위칭 소프트웨어를 포함하는 에뮬레이션 코드 테이블(92)의 부분으로 인덱싱하기 위해 사용된다. 다시, 자르기 동작이 식(94)의 AND 동작 대신 사용되면, 이후 그 자르기 동작의 결과는 상수 0x8인 스레드 스위칭 소프트웨어로의 오프셋으로 연관되거나 조합될 수 있다. 명령문(95)은 JAVASW 명령이 이후 스위치 카운트 값(SWCOUNT)을 감소시키는 것을 나타낸다. 본 발명의 대안의 실시예들이 다운 카운터 대신 업 카운터를 사용할 수 있거나, 스위치가 충돌되기 전에 특정 시간을 지정하는 타이머와 같은, 어떤 다른 방식으로 스레드 스위칭을 트래킹할 수 있다는 것이 쉽게 명백해질 것이다. 도 7에 도시된 실시예가 매우 특별한 방법에서 점프 어드레스들을 선택하지만, 본 발명의 대안의 실시예들은 식들(92 및 94) 및 명령문(93)을 구현하는 다른 식들을 사용할 것이다. 본 발명의 도시된 실시예가 바이트코드 에뮬레이션 시퀀스들로 점프하기 위해 식들(92 및 94)에 의해 특정된 특별한 어드레스들의 사용들을 설명하지만, 본 발명의 대안의 실시예들은 다른 원하는 어드레스들로 점프하기 위해 지정된 형식에서 식들(92 및 94)을 사용할 수 있다. 도 7에 도시된 본 발명의 실시예는 바이트코드 에뮬레이션 시퀀스로 점프하기 위해 사용된 프로세서(12) 명령을 설명하고, 본 발명의 대안의 실시예들은 다양한 다른 목적들을 위해 복수의 점프 목적지 어드레스들의 하나로 점프된 이러한 유형의 명령을 사용할 수 있다. 본 발명은 따라서 자바 바이트코드 에뮬레이션 시퀀스로 점프하기 위해 제한되지는 않으며, 점프들의 다른 유형들로 사용될 수 있다. 부가적으로, 명령문들(91 및 93)은 복수의 가능한 점프 목적지 어드레스들의 하나를 선택하는 변수 조건들의 임의의 유형일 수 있다. 또한 명령문(95)은 선택적이며 일부 실시예들에서 사용되지 않을 수 있다는 것이 명백해질 것이다.

도 7에 도시된 명령 포맷(90)은 또한 OP 코드로서 참조될 수 있다. 바람직한 형태에서, 명령 포맷(90)은 명령 레지스터(116)에 유지되고, 도 8의 명령 디코딩(104) 회로에 의해 디코딩되며, 따라서, 프로세서(12)에서 JAVASW 명령을 실행하기 위해 제어 회로(105)로 제공된다.

JAVASW 명령동안 실행되는 점프 동작이 항상 발생된다는 것을 주의한다. 점프는 선택적이거나 조건적이 아니며, 복수의 점프 목적지 어드레스들 중 하나로 항상 발생한다.

또한 R4<<5는 미리 결정된 값, 이 경우 바이트코드 값이 레지스터(R4)로 로딩되기 전에 5비트에 의해 좌측으로 시프트되는 것을 나타낸다는 것에 주의한다. 도 7에 도시된 본 발명의 실시예에서, 각 명령은 길이가 16 비트이고, 따라서, 저장 디바이스의 2 바이트를 점유한다. 5개의 비트의 좌측 시프트는 32 바이트, 또는 16개의 명령들의 곱셈과 동일하다는 것이 주의된다. 도 6을 참조하면, 바이트코드 값이 5에 의해 시프트되거나 32에 의해 곱해지는 이유는, 인덱스로의 에뮬레이션 코드 테이블(72)로의 오프셋이 에뮬레이션 코드 테이블(72) 내의 정확한 바이트코드 명령 그룹으로 허용되기 때문이다. 따라서, 값 R4<<5는 점프 목적지 어드레스 포인터를 에뮬레이션 코드 테이블(72) 내의 정확한 그룹의 시작으로 이동시키는데 사용된다.

본 발명의 대안의 실시예들은 하나보다 많은 명령을 사용하는 JAVASW 명령 기능의 구현을 포함할 수 있다는 것이 인식되어야 한다. 본 발명의 한 실시예에서 JAVASW 명령은 카운터를 제어하고 단일 명령에서 테이블 점프를 구현하기 위한 능력을 조합한다. 이것이 식들(92 또는 94)의 하나로 부가하여 실행되는 설명(95)으로서 도 7에 도시된다. JAVASW 명령에 대하여 명령 흐름의 변경이 항상 취해지고, 이는 조건적인 브랜치 명령에 대한 경우가 아니라는 것이 주의된다. JAVASW 명령에 응답하여 실행된 점프가 두 어드레스들 중 하나이고, 이들 모두는 미리 결정된 테이블 내에 있다는 것이 주의된다(도 4의 에뮬레이션 코드 테이블(62) 참조). 부가적으로, 본 발명의 한 실시예에서 JAVASW 명령은 테이블 점프의 목적지가 자바 바이트코드 값과 카운터 값 모두의 함수인 테이블 점프 동작을 실행한다. 본 발명의 한 실시예에서 카운터 값은 스레드 스위칭이 발생되어야 할 때 결정하기 위한 자바 번역기에 의해 사용된 스위치 카운터 값(도 7의 SWCOUNT)일 수 있다. 한 실시예에서, 레지스터들(109) 중 하나가 카운터로서 사용될 수 있다. 대안의 실시예들은 이러한 스위치 카운터 기능을 구현하기 위해 프로세서(12)의 하드웨어와 하드웨어 또는 소프트웨어의 조합을 사용할 수 있다. JAVASW 명령의 한 실시예에 대해, 카운터 값은 조건적으로 점프의 일반적인 엔트리 포인트가 에뮬레이션 테이블(도 7 및 8의 0x8로 예시된)로 돌아가는 미리 결정된 고정된 엔트리 포인트로 우선되도록 한다. 대안적인 실시예들은 0x8과 다른 어드레스들을 사용할 수 있다. 도 7에 도시된 바와 같이, 일반적인 테이블 엔트리 포인트는 식(92)의 실행에 의해 결정된 PC 값의 어드레스 계산으로 대응하고, 스레드 스위칭이 발생하지 않을 때 일어난다. 스레드 스위칭이 발생하면, 식(92)에 대응하는 일반적인 테이블 엔트리 포인트는 사용되지 않는다. 대신, 지금 실행되어야 하는 스레드 스위치로서, 식(94)에 의해 정의된 엔트리 포인트로 우선되고, 일반적으로 에뮬레이트된 자바 바이트코드에 대한 에뮬레이션 코드는 더이상 입력되지 않는다.

JAVASW 명령은 우선하지 않는 테이블 엔트리 포인트가 사용될 때 핸드쉐이크 신호(공동 프로세서 인터페이스(30)의 부분)를 통해 하드웨어 가속기(예를 들면, 공동 프로세서들(14,16))을 선택적으로 시그널링하는 명령을 제공한다. 이러한 핸드쉐이크 신호는 하드웨어 가속기가 프로세서(12)가 도 7의 식(92)을 실행하는지 여부(바이트코드가 프로세서(12)와 하드웨어 가속기에 의해 에뮬레이트되는 경우) 또는 프로세서(12)가 도 7의 식(94)을 실행하는 것에 의한 스레드 스위칭인지 여부(하드웨어 가속기가 현재 바이트코드의 에뮬레이션을 실행하지 않아야 하는 경우)를 결정하도록 허용한다.

부가적으로, JAVASW 명령은 바이트코드 값들의 작은 세트에 대해 우선되는 도 6에 도시된 일반적인 테이블 구조를 허용하는 디스패치 메카니즘을 제공할 것이다. 예를 들어, 16개보다 많은 명령 슬롯들을 요구하여 할당된 그룹 크기를 오버플로우하는 공통적으로 실행된 자바 바이트코드에 대하여, 자바 바이트코드에 의해 요구된 코드를 실행하기 위해 에뮬레이션 코드 테이블의 외부에 있는 위치로 JAVASW 명령을 점프하게 하는 하드웨어가 제공될 수 있다. 단지 이러한 디스패치 메카니즘을 구현하기 위해 요구된 하드웨어만이 그들의 할당된 명령 슬롯들을 오버플로우하는 자바 바이트코드들의 선택된 세트를 디코딩하기 위한 디코딩 논리의 적은 양이면, 에뮬레이션 코드 테이블의 외부의 위치로 점프하기 위해 이러한 선택된 자바 바이트코드에 대하여 에뮬레이션 코드를 허용하도록 대응하는 제어를 따라 이하에서 설명된 도 8의 Mux 및 조합기(106)로의 부가의 입력(103)이다. 이러한 디코딩 회로는 도 8과 연관하여 이하에서 설명되는 바와 같이 프로세서(12)의 제어 회로(105) 내에서 구현될 수 있다는 점을 주의한다.

앞서 주의된 바와 같이, 도 8은 도 1의 프로세서(12)의 관련 부분의 한 실시예를 도시한다. 반복을 위하여, 자바 바이트코드를 에뮬레이트하는데 사용된 명령들은 명령 레지스터(116)로부터의 명령 디코딩 회로(104)에 의해 수신된다. 명령 디코딩 회로(104)는 에뮬레이션 명령들을 디코딩하고 디코딩된 결과를 제어 회로(105)로 제공한다. 제어 회로(105)는 이러한 명령들을 실행하기 위해 제어 신호들을 프로세서(12) 내의 다른 소자들로 제공한다. 위에 지시된 바와 같이, 제어 회로(105)는 컨덕터들(130)에 의해 레지스터들(107)과 산술 논리 유닛(ALU)(110) 및 어드레스 선택 논리(111)에 양방향으로 접속된다. 제어 회로(105)는 제어 신호들을 Mux 및 조합기(106)로 제공한다. 본 발명의 대안의 실시예들은 더 많이, 더 적게, 또는 다른 입력들을 Mux 및 조합기(106)로 사용할 수 있다. Mux 및 조합기(106)로의 출력은 어드레스 선택 논리(111)로의 입력과 같이 제공되는 JAVASW 프로그램 카운터 어드레스(124)이다. 어드레스 선택 논리(111)는 입력들로서 또한 브랜치 어드레스(123), 제외 어드레스(122), 및 점프 어드레스(121)를 수신한다. 부가적으로, 어드레스 선택 논리(111)의 출력은 증가 회로(112)에 의해 증가될 수 있으며, 이후 컨덕터들(120)에 의해 어드레스 선택 논리(111)로의 입력으로서 피드백된다. 본 발명의 도시된 실시예에서, 증가 회로(112)는 2 바이트에 의해 어드레스로 증가하고, 이는 한 명령과 동일하다. 본 발명의 대안의 실시예는 다양한 양들에 의해 어드레스를 증가시키기 위해 증가 회로(112)를 사용할 수 있다. 어드레스 선택 논리(111)에 의한 어드레스 출력이 프로그램 카운터(108)로 제공되고 컨덕터들(133)에 의해 제어 회로(105)로 제공된다. 제어 회로(105)는 점프 어드레스(121), 제외 어드레스(122), 및 브랜치 어드레스(123)를 생성시키기 위해 사용된다. 제어 회로(105)는 하나 이상의 컨덕터들(134)에 의해 하나 이상의 스위치 스레드 임계치 신호들을 수신한다. 위에서 논의된 바와 같이, 레지스터들(107)은 컨덕터들(130, 131, 및 132)에 의해 산술 논리 유닛(110)으로 양방향으로 접속된다.

도시된 형태에서, Mux와 조합기(106)로의 다양한 입력들은 데이터 처리 시스템(10)으로 상당량의 유연성을 제공한다. Mux 및 조합기(106)로의 입력(113)은 Mux 및 조합기(106)로의 다른 입력들과 조합하는 다양한 JAVASW 프로그램 카운터 어드레스(124) 값들을 형성하기 위해 사용되는 프로그램 카운터(108)로부터 현재의 PC+2 값을 제공한다. 예를 들어, 상수 0x8을 제공하는 입력(100)은, 도 6의 에뮬레이션 코드 테이블(72)의 제 1 그룹에 위치되는 스레드 스위칭 소프트웨어 루틴(76)으로 JAVASW 프로그램 카운터 어드레스가 향하도록 하기 위해 입력(113)과 조합하여 사용될 수 있다. 이러한 새로운 프로그램 카운터 어드레스는 스레드 스위칭 소프트웨어가 요구될 때 사용될 것이다. Mux 및 조합기(106)로의 입력(101)은 레지스터(R4)의 컨텐트가 1 디지트 위치만큼 좌측으로 시프트되고 그 시프트는 2배 곱해진 것과 동일하다는 것을 나타낸다. 입력(101)은 에뮬레이션 코드 테이블(72)의 그룹이 대응하는 바이트코드를 구현하기 위한 에뮬레이션 코드가 위치되는 에뮬레이션 코드 테이블(72)의 끝부분을 넘어선 점프 어드레스를 저장하기 위하여 단일 명령을 포함할 때 새로운 프로그램 카운터 어드레스를 형성하기 위해 사용된다. 이러한 기능이 도 9의 이하의 설명에서 또한 설명될 것이다. Mux 및 조합기(106)로의 입력(102)은 32에 의해 곱해진 것과 동일한 레지스터(R4)의 컨텐트의 5에 의해 좌측으로 시프트된 것을 나타낸다. 좌측으로 시프트된 값R4<<5는 에뮬레이션 코드 테이블(72)의 그룹들 사이에서 선택하기 위해 입력(113)과 연관하여 사용된다. 이러한 시프트는 프로세서(12)가 이전 자바 바이트코드 실행을 끝내고 다음 자바 바이트코드의 실행을 전송할 때 새로운 프로그램 카운터 어드레스를 생성시키기 위해 실행되는 조정이다. Mux 및 조합기(106)로의 입력(103)은 일반적인 테이블 구조가 바이트코드 값들의 작은 세트에 대해 선행되도록 한다. 달리 말하면, 에뮬레이션 코드 테이블(72)의 어드레스 외측은 Mux 및 조합기(106)로의 테이블(103)의 엔트리 포인트 외측의 신호 입력으로 미리 결정된 값이 되게 할 수 있다. 본 발명의 대안의 실시예들은 데이터 처리 시스템(10)의 필요에 기초한 다른 새로운 프로그램 카운터 어드레스들을 생성시키는데 사용되는 Mux 및 조합기(106)로의 다른 입력들을 가질 것이라는 것이 주의된다. Mux 및 조합기(106)로의 입력들은 에뮬레이션 코드 테이블(72) 내의 그룹 크기를 변화시키기 위해 사용될 수 있다. 설명된 실시예가 한 표준 그룹 크기로 도시되었음에도 불구하고, 본 발명의 대안의 실시예들은 Mux 및 조합기(106)로의 입력들에 의해 정의된 다른 그룹 크기 또는 복수의 그룹 크기들을 사용할 수 있다. 이는 데이터 프로세서 시스템(10)의 사용자에게 자바와 같은 하이 레벨 언어의 다양한 바이트코드들을 에뮬레이트하기 위해 요구된 코드의 길이를 결정하는데 상당한 양의 유연성을 제공한다.

이제 도 9를 참조하면, 도 9는 바이트코드 값들의 큰 그룹을 위해 에뮬레이션 코드 테이블이 압축되도록 허용하는 디스패치 메카니즘을 도시한다. 도 5를 참조하여 상술된 바와 같이, 일부 바이트코드 값들에 대하여, 대응하는 에뮬레이션 코드는 제공하는 그룹 크기보다 많은 명령 슬롯들을 요구할 수 있다. 도 5의 단계 2 및 3에 연관된 오버헤드는 에뮬레이션 코드가 인접하는 시퀀스에 있는 경우 단순화될 수 있다. 자바 바이트코드 인코딩들을 위해, 범위 0xc0 내지 0xff의 바이트코드들의 큰 비율이 16개의 슬롯들의 그룹 크기에 제공되는 것보다 많은 명령 슬롯들을 제공하고, 도 9의 대안의 에뮬레이션 코드 테이블(83)이 바람직할 수 있다. 따라서, 도 9는 256 엔트리들(바이트코드당 1 그룹)을 포함하는 저장 디바이스로서 에뮬레이션 코드 테이블(83)을 도시하며, 여기서 첫번째 192 엔트리들(엔트리들의 3/4)은 16개의 명령 슬롯들의 그룹 크기를 갖고, (0x0 내지 0xbf의 바이트코드들에 대응하는 엔트리들), 마지막 64 엔트리들(엔트리들의 1/4)은 1개의 명령 슬롯의 그룹 크기를 갖는다. 이러한 방식으로 테이블을 구성하는 것에 의해, 0x0 내지 0xbf의 바이트코드들에 대한 엔트리들은 도 5 및 6을 참조하여 상술된 바와 같이 사용될 수 있고, 0xc0 내지 0xff의 바이트코드들에 대한 엔트리들은 대응 바이트코드에 대한 실질적인 에뮬레이션 코드로의 점프 명령을 포함한다. 이러한 구조는 테이블의 크기가 압축되게 하고, 이러한 더 복잡한 바이트코드들에 대한 에뮬레이션 코드는 도 5에서 실행된 바와 같이 초기 부분 및 최종 부분으로 분할되기보다 인접하게 남아있을 수 있다. 이러한 디스패치 메카니즘은 코드를 단순화하고 도 5의 단계들 2 및 3을 실행하는 필요를 제거하여 오버헤드를 감소시킨다. 대신, 대안의 단계 2가 0xc0 내지 0xff의 범위에서 자바 바이트코드에 대한 엔트리 에뮬레이션 루틴으로 직접적으로 점프하도록 도입된다. 다시 도 8을 참조하면, 이러한 테이블 압축은 PC+2 입력(113), 및 제어 회로(105)와 연관된 Mux 및 조합기(106)로의 입력(101)의 사용에 의해 성취된다. 스케일링 R4<<1에 의해, 테이블(83)의 바닥의 64 엔트리들로의 적절한 인덱싱이 이루어진다. Mux 및 조합기(106)로의 입력(113)에 대응하는 값 PC+2는 제어 회로(105)로의 입력(118)상의 0xc0 내지 0xff 범위의 바이트코드의 디코딩에 응답하는 제어 회로(105)에 의해 도 9의 시작 엔트리(88)로 향하도록 수정된다. 이러한 변경된 값은 이후 Mux 및 조합기(106)로의 적당한 테이블 엔트리 포인트를 선택하기 위해 R4<<1로 조합된다. 제어 회로(105)는 또한 입력(118)에서 수신된 자바 바이트코드의 사용을 통해 사용자가 결정할 수 있는 제어 신호를 구현할 수 있다. 제어 신호는 미리 결정된 그룹 크기들의 제 1 에뮬레이션 테이블 구조 또는 미리 결정된 그룹 크기들의 제 2 에뮬레이션 테이블 구조를 선택하고, 도 5와 같이 조직화된 저장 디바이스 또는 도 9와 같이 조직화된 저장 디바이스와 동작하는지 여부에 따른 사용자 유연성을 제공한다.

도 9에 도시된 실시예가 압축된 테이블 엔트리들을 갖는 바이트코드들과 같이 0xc0 내지 0xff의 바이트코드들의 특정 선택을 도시하는 동안, 대안의 바이트코 드 그룹들이 선택될 수 있고, 또는 바이트코드들의 다른 수가 본 발명에 따라 압축된 테이블 엔트리들을 위해 선택될 수 있다.

이제까지 번역기 루프와 연관된 오버헤드의 다양한 양상들을 조합하고 최소화하는 데이터 처리 명령이 제공되었다는 것이 명백해질 것이다. 한 형태에서, 명령이 집적 회로 칩 내의 또는 집적 회로 칩으로부터 독립적이고 개별적인 기억 매체에 저장될 수 있다. 명령에 대한 하드웨어 지원은 번역기 기능을 구현하는데 사용된 메모리의 최적화를 허용한다. 결과적으로, 실행 시간, 요구된 하드웨어 자원들의 양 및 요구된 번역기 소프트웨어의 양에 대한 오버헤드는 대단히 감소되었다. 본 발명은 흐름의 변경이 항상 취해지는 테이블 점프 구현 및 카운터 제어를 조합한다. JAVASW 명령은 바이트코드 값 및 카운터 값 모두에 대한 함수로서 테이블 점프의 목적지를 구현하고, 카운터 값은 조건적으로 테이블의 일반적으로 계산된 엔트리 포인트가 미리 결정된 고정된 엔트리 포인트에 선행하도록 한다. JAVASW 명령은 또한 스레드 스위치가 구현되지 않을 때 조건적으로 핸드쉐이크 신호를 통해 하드웨어 가속기를 시그널링한다. 설명된 실시예에서, 일반적인 메모리 구조가 바이트코드 값들의 작은 세트에 대하여 선행되도록 하는 디스패치 메카니즘이 제공된다. 메모리 테이블이 바이트코드 값들의 큰 그룹에 대하여 압축되도록하는 디스패치 메카니즘이 또한 제공된다. 부가적으로, 메모리 테이블은 간단하고 복잡한 바이트코드들에 대응하는 다수의 그룹 크기들(예를 들면, 2,8,18 바이트들, 등)을 지지하도록 구성될 수 있다. 이러한 분기점에서, OP 코드(바이트코드)는 디코딩되고 코드는 그룹 크기에 기초하여 선택적으로 분리된다.

앞선 설명에서, 본 발명은 특정 실시예들을 참조로 설명되었다. 그러나, 당업자는 다양한 수정들 및 변경들이 다음의 청구범위들에서 설명되는 바와 같은 본 발명의 범위로부터 벗어남이 없이 만들어질 수 있다는 것을 이해한다. 따라서, 명세서 및 도면들은 제한하는 의미보다 예시하는 것으로 간주되며, 모든 이러한 수정들은 본 발명의 범위에 포함되는 것으로 의도된다. 당업자는 도면들의 요소들이 간단함과 명료함을 위해 도시되며 크기대로 도시될 필요는 없다는 것을 이해한다. 예를 들어 도면들의 요소들의 일부의 크기들은 본 발명의 실시예들의 이해의 개선을 돕기 위하여 다른 요소들에 대해 과장될 수 있다.

이익들, 다른 장점들 및 문제들에 대한 솔루션들이 특정 실시예들에 대하여 상술되었다. 그러나, 이익들, 장점들, 문제들에 대한 솔루션들 및 임의의 이익, 장점, 또는 보다 명백하게 발생되거나 이루어질 솔루션을 야기할 수 있는 임의의 요소(들)은 임의의 또는 모든 청구범위들의 기준, 요구사항, 또는 필수 특징 또는 요소로서 분석되지 않는다. 본원에 설명된 바와 같이, "포함하다(comprises)", "포함하는(comprising)"이라는 용어 또는 이의 다른 변형은, 비배타적 포함을 커버하도록 의도되어, 프로세스, 방법, 물품, 또는 요소들의 리스트를 포함하는 장치는 단지 이러한 요소들만을 포함하지 않고, 표현적으로 나열되지 않은 다른 요소들 또는 본래의 프로세스, 방법, 물품, 또는 장치를 포함할 것이다.

Claims (9)

1. 제 1 어드레스에 위치된 제 1 명령을 페치하는 수단; 및 데이터 처리 시스템으로 상기 제 1 명령을 실행하는 수단을 포함하는 데이터 처리 시스템에서의 프로그램 실행 방법에 있어서:

   상기 제 1 명령을 실행하는 단계;

   미리 결정된 값과 어떤 하나의 값의 비교가 제 1 결과를 가지면 점프 어드레스에 제 2 어드레스를 제공하고, 상기 미리 결정된 값과 상기 어떤 하나의 값의 비교가 제 2 결과를 가지면 상기 점프 어드레스에 제 3 어드레스를 제공하는 것에 의해 상기 어떤 하나의 값에 기초하여 점프 어드레스를 선택하는 단계로서, 상기 제 2 어드레스와 상기 제 3 어드레스는 모두 상기 제 1 어드레스에 인접하지 않는, 상기 점프 어드레스 선택 단계; 및

   상기 점프 어드레스로 프로그램 실행을 리다이렉팅(redirecting)하는 것에 의해 상기 제 1 명령의 실행에 응답하여 상기 프로그램 실행에서 제어의 변경을 항상 구현하는 단계를 포함하는, 프로그램 실행 방법.
2. 제 1 항에 있어서,

   상기 제 1 결과는 상기 어떤 하나의 값이 상기 미리 결정된 값보다 크다는 비교 결정이고, 상기 제 2 결과는 상기 어떤 하나의 값이 상기 미리 결정된 값보다 작거나 동일하다는 비교 결정인, 프로그램 실행 방법.
3. 제 1 항에 있어서,

   프로그램 실행 동안 증가되는 어드레스 값을 갖는 프로그램 카운터를 유지하고, 상기 어드레스 값의 하위(low order) 비트들의 미리 결정된 수를 자르고(truncate), 상기 점프 어드레스를 생성하기 위해 오프셋과 결과를 조합하는 것에 의해 상기 점프 어드레스를 생성하는 단계를 더 포함하는, 프로그램 실행 방법.
4. 제 1 항에 있어서,

   상기 실행 수단에 의해 실행될 처리 명령들을 저장하는 어드레스들의 미리 결정된 범위를 갖는 저장 디바이스를 제공하는 단계로서, 상기 처리 명령들은 그룹들로 구성되고, 각 그룹은 프로그램의 미리 결정된 OP 코드와 상관되는, 상기 저장 디바이스 제공 단계를 더 포함하는, 프로그램 실행 방법.
5. 제 4 항에 있어서,

   명령 슬롯들의 미리 결정된 수의 섹션들에 상기 저장 디바이스를 구성하는 단계로서, 상기 섹션들의 각각의 미리 결정된 양은 상기 명령들의 저장에 전용되는, 상기 저장 디바이스 구성 단계를 더 포함하는, 프로그램 실행 방법.
6. 삭제
7. 데이터 처리 시스템에 있어서:

   복수의 프로그램 명령들을 저장하는 메모리;

   데이터 버스를 통해 상기 메모리에 결합되어, 상기 메모리로부터 상기 프로그램 명령들을 페치하고 상기 복수의 프로그램 명령들을 선택적으로 실행하는 프로세서; 및

   상기 프로세서에 의해 실행될 복수의 처리 명령들을 저장하는 저장 디바이스로서, 상기 복수의 처리 명령들은 그룹들로 구성되고, 각각의 그룹은 상기 복수의 프로그램 명령들 중 미리 결정된 하나에 상관되는, 상기 저장 디바이스를 포함하고;

   상기 프로세서는 미리 결정된 어드레스에서 미리 결정된 처리 명령을 실행하고, 미리 결정된 값과 어떤 하나의 값의 비교가 제 1 결과를 가지면 점프 어드레스에 제 1 어드레스를 제공하고, 상기 미리 결정된 값과 상기 어떤 하나의 값의 비교가 제 2 결과를 가지면 상기 점프 어드레스에 제 2 어드레스를 제공하는 것에 의해 상기 어떤 하나의 값에 기초하여 점프 어드레스를 선택하고, 상기 제 1 어드레스와 상기 제 2 어드레스는 모두 상기 미리 결정된 어드레스와 인접하지 않으며, 상기 미리 결정된 처리 명령의 실행은 프로그램 실행에서 제어의 변경을 항상 구현하는, 데이터 처리 시스템.
8. 제 7 항에 있어서,

   상기 프로세서는:

   상기 프로그램 명령들을 수신하는 명령 레지스터;

   상기 명령 레지스터에 결합되어, 상기 프로그램 명령들을 특정 OP 코드 값들로 디코딩하는 명령 디코더;

   상기 명령 디코더에 결합되어, 상기 특정 OP 코드 값들에 응답하여 제어 신호들을 제공하는 제어 회로;

   상기 제어 회로에 결합되어, 상기 제어 신호들을 수신하고 상기 점프 어드레스를 생성하는 어드레스 생성 회로;

   상기 어드레스 생성 회로에 결합되어, 상기 제어 회로에 응답하여 오퍼랜드들을 저장하는 레지스터들; 및

   상기 어드레스 생성 회로 및 상기 제어 회로에 결합되어, 상기 레지스터들에 의해 저장된 상기 오퍼랜드들을 처리하는 산술 논리 유닛을 더 포함하는, 데이터 처리 시스템.
9. 삭제

Images