KR20040034601A

KR20040034601A - 바이트 컴파일된 자바 코드를 실행하는 마이크로 프로세서

Info

Publication number: KR20040034601A
Application number: KR10-2003-7013746A
Authority: KR
Inventors: 스트롬오이빈트
Original assignee: 아트멜 코포레이숀
Priority date: 2001-04-23
Filing date: 2002-04-01
Publication date: 2004-04-28
Also published as: US20040015678A1; NO20034743D0; WO2002086699A2; AU2002307080A1; US7917732B2; US8533433B2; JP3786644B2; US8166280B2; NO20034743L; US20070168954A1; US20120204017A1; US20110145548A1; CA2444968A1; WO2002086699A3; TW575827B; EP1410174A2; JP2004532466A

Abstract

본 발명은 바이트 컴파일된 자바 프로그램을 하드웨어에서 바로 실행하는 마이크로 프로세서 아키텍쳐(30)에 관한 것이다. 마이크로 프로세서는 내장형 시스템의 영역의 하단부를 타겟으로 하고, 두 개의 직교 프로그래밍 모델, 즉, 자바 모델 및 RISC 모델을 특징으로 한다. 이 모듈들은 공통된 데이터 경로를 공유하며 독립적으로 동작하지만, 병렬적으로 동작하지는 않는다. 마이크로 프로세서는 조합된 레지스터 파일을 포함하는데, 이 레지스터 파일에서는 자바 모듈(31)이 레지스터 파일(35)의 원소들을 순환 피연산자 스택으로 보고 RISC 모듈(33)이 이 원소들을 종래의 레지스터 파일로 본다. 이러한 통합된 마이크로 프로세서 아키텍쳐는 하드웨어에 가까운 명령어들을 액세스하는 것을 용이하게 하고 강력한 인터럽트 및 명령어 트래핑 능력을 제공한다.

Description

바이트 컴파일된 자바 코드를 실행하는 마이크로 프로세서 {MICROPROCESSOR FOR EXECUTING BYTE COMPILED JAVA CODE}

자바는 네트워크 프로그래밍에서 사실상 표준이 된 객체 지향 프로그래밍 언어이다. 오늘날 자바는 내장형 시스템 또는 마이크로 프로세서나 마이크로 컨트롤러를 포함하는 시스템의 영역에 이용되기 시작하고 있다. 객체 지향, 자동 가비지 컬렉션(garbage collection), 및 런 타임 보안 특징과 같은 자바 환경의 강점들 중 일부는 내장형 애플리케이션에서 성공적으로 사용될 수 있다. 그러나, 런 타임 환경은 인터프리터 또는 JIT(just-in-time) 컴파일러와 같은 가상 머신에서 자바 코드를 실행시키는 것과 관련된 리소스 오버헤드 때문에 시스템 설계자에게 어려움을 주고 있다. 바이트 코드라고 불리는 자바 이진 코드는 하나 이상의 클래스 파일에 분산되어 있다. 바이트 코드는 자바 프로그램의 실행을 위해 특별히 설계된 가상적인 컴퓨터(hypothetical computer)의 명령어이다. 종래의 CPU는 이러한 바이트 코드를 실행할 수 없으므로, 이 바이트 코드를 자바 가상 머신(Java VirtualMachine)이라고 불리는 소프트웨어 층에서 실행한다. 자바 가상 머신은 추상적인 머신 스펙(specification)이며, 구현 가이드라인은 주어져 있지 않다. 자바 가상 머신 스펙은 선 마이크로시스템사(Sun Microsystems)에 의해 발표되었다.

도 17을 참조하면, 기본적으로 자바 프로그램을 물리적 컴퓨터 플랫폼에서 실행하기 위한 네가지 방식이 있다. 제1 방법(902)에서 연산 코드(op code)가 자바 컴파일러(915)에서 계산되고, 자바 바이트 코드(925)가 인터프리터(930)로 전송된 후, OS(950)로 보내져서 CPU(960)에 의해 실행된다. 그러나, 인터프리터(930)는 원시 코드로 컴파일된 프로그램을 실행하는 것과 비교하여 속도에 있어 5배(a factor of five)의 불이익을 나타낸다.

제2 방법(903)은 인터프리터를 사용하는 대신, 자바 바이트 코드가 JIT 컴파일러(935)에 의해 원시 플랫폼을 위한 이진 포맷(940)으로 동적으로 컴파일된다는 점만 제외하면 제1 방법과 유사하다. 이 과정은 가상 머신 내부에서 일어나고 프로그램이 종료된 다음에는 저장되어 있지 않다. 최신 자바 JIT 기술은 핫 스팟(hotspot)이라 불리는데, 프로그램 실행 동안 체증이 일어나는 곳(bottlenecks)을 분석하고 재컴파일하는 원리를 사용한다. 그러나, JIT 컴파일러는 동일한 애플리케이션을 실행하면서 2 배 내지 3 배(a factor of two or three)의 메모리 오버헤드를 겪는다.

제3 방법(901)은 자바 소스 코드를 원시 플랫폼을 위한 이진 포맷(920)으로 컴파일하는 크로스 컴파일러(cross compiler, 910)를 사용한다. 그러나, 플랫폼의 독립성을 잃게 되어, 이진 프로그램은 다수의 플랫폼에서 실행될 수 없다.

제4 방법(904)에서 자바 OS(945)와 자바 프로세서(970)가 바이트 코드를 직접 실리콘에서 실행하는데 사용된다. 어떤 자바 프로세서들은 폴딩(folding) 메카니즘을 가지고 있는데, 이는 여러 명령어가 결합되어 하나로서 실행됨을 의미한다. 그러나, 대부분의 자바 프로세서들은 인터프리터로서 실행되고 각 연산 코드가 판독된 다음에 적당한 액션을 취하여 명령어를 실행한다.

일반적으로 선호되는 런 타임 환경은 존재하지 않는다. 각 런 타임 환경은 그들의 요건 조건에 따라 상이한 시스템들에 대하여 성공적으로 사용될 수 있다. 그러나, 내장형 시스템의 경우 자바 프로세서를 사용하는 것은(제4 방법(904)) 자바가 내장형 시스템에서 구현될 경우 매우 바람직한 기술적 솔루션이다. 최근 몇 년간, 여러 자바 가상 머신이 내장형 프로세서 플랫폼에 대하여 개발되었다. 소프트웨어 솔루션의 대부분은 100K 메모리 크기를 가진 32 비트 프로세서를 목표로 한다. 또한, 실리콘에서 자바 프로그램을 실행하는 자바 하드웨어 프로세서들도 일부 개발되었다. 이러한 프로세서들은 자바 명령어의 직접적인 실행을 지원하며, 32 비트 스택 머신을 구현한다. 어떤 프로세서들은 직접 어드레싱(direct addressing) 및 비트 처리(bit manipulation) 명령어와 같은 특징을 제공하기 위하여 자바 이진 포맷으로의 확장에 의존한다. 다른 프로세서들은 자바 이진 코드를 직접 실행하지는 않지만, 아키텍쳐가 매우 유사하므로, 가상 머신의 성능을 증가시킨다. 프로세서들은 모두 중형 내지는 대형 내장형 시스템을 목표로 한다. 8 비트 프로세서 시장이 32 비트 프로세서 시장보다 상당히 더 커지긴 했지만, 현재 자바 바이트 컴파일된 코드를 직접적으로 실행하는데 이용할 수 있는 8 비트 또는16 비트 프로세서는 없다.

본 발명은 일반적으로 마이크로 프로세서에 관한 것이고, 보다 구체적으로는 자바 가상 머신(Java Virtual machine) 코어 아키텍쳐를 가진 마이크로 프로세서에 관한 것이다.

도 1은 자바 명령어 집합과 전형적인 RISC 명령어 집합과의 교집합을 보여주는 벤다이어그램.

도 2는 본 발명에 따른 마이크로 프로세서의 아키텍쳐의 블록도.

도 3은 도 2의 마이크로 프로세서에 대한 정상적인 런 시퀀스를 도시하는 흐름도.

도 4는 도 2의 마이크로 프로세서의 레지스터 파일의 일부의 블록도.

도 5는 도 2의 마이크로 프로세서의 전체 레지스터 파일의 블록도.

도 6은 도 2의 마이크로 프로세서의 인터럽트 처리 메카니즘을 나타내는 블록도.

도 7은 도 2의 마이크로 프로세서의 모드 이동 메카니즘을 나타내는 블록도.

도 8은 도 2의 마이크로 프로세서가 구현될 런 타임 시스템을 나타내는 블록도.

도 9는 도 2의 마이크로 프로세서의 RISC 부분에 대한 명령어 포맷을 나타내는 블록도.

도 10은 본 발명에서 사용된 상태 레지스터들에 대한 어드레싱 모드를 나타내는 블록도.

도 11 내지 도 16은 도 2의 마이크로 프로세서의 실행 시퀀스 동안의 타이밍 신호를 나타내는 타이밍도.

도 17은 종래 기술로서, 물리적인 컴퓨터 플랫폼에서 자바 프로그램을 실행하는 여러 가지 방법을 나타내는 블록도.

도 18은 SMILE RISC 아키텍쳐의 상태 레지스터에 대한 어드레싱 모드를 나타내는 블록도.

도 19는 본 발명에서 사용되는 SMILE RISC 아키텍쳐의 이동, 산술, 및 논리 명령어들에 대한 명령어 포맷을 나타내는 블록도.

도 20은 본 발명에서 사용되는 SMILE RISC 아키텍쳐의 제어 명령어들에 대한 명령어 포맷을 나타내는 블록도.

도 21은 본 발명에서 사용되는 SMILE RISC 아키텍쳐의 LL 명령어들의 명령어 포맷을 나타내는 블록도.

본 발명의 목적은 자바 바이트 컴파일된 코드를 하드웨어에서 실행하는 마이크로 프로세서를 제공하는 것이다.

본 발명의 다른 목적은 소형 내지는 중형 크기의 내장형 애플리케이션에서 바람직한 솔루션이 되기에 충분할 정도로 작고 전력이 효율적인 자바를 실행하는 마이크로 프로세서 아키텍쳐를 제공하는 것이다.

상기 목적들은 RISC 프로세서, RISC 프로세서에서 첫 번째 자바 명령어들의 집합을 실행하는 자바 모듈, RISC 프로세서에서 두 번째 자바 명령어들의 집합을 마이크로 코드로서 실행하는 RISC 모듈, RISC 프로세서에서의 데이터 경로, 이 두 모듈에 의해 공유되는 레지스터 파일을 포함하는 하드웨어에서, 바이트 컴파일된 자바 코드를 실행하는 마이크로 프로세서에 의해 달성된다. 자바 모듈은 레지스터 파일에 있는 원소(element)들을 순환 피연산자 스택(circular operand stack)으로 간주하고, RISC 모듈은 다수의 원소를 레지스터 파일로 간주한다. 마이크로 프로세서 아키텍쳐는 자바가 고도의 구조 정보를 가진(highly semantic content) 명령어 집합에도 불구하고 상당수의 실행 명령어들을 일반적인 RISC 프로세서의 명령어와 공유한다는 관찰로부터 유도된다. 이 아키텍쳐는 내장형 애플리케이션의 설계자에게 잘 정의된 프로그래밍 모델을 가진, 통합하기 쉽고 작고 비용 효율이 좋은(cost effective) 프로세서 솔루션을 제공하는 것을 목적으로 한다. 이에 따라 두 개의 프로그래밍 모델을 포함하고, 자바를 소형 내지 중형 크기의 내장형 애플리케이션에서 통합하기 쉽게 만드는 프로세서 아키텍쳐가 고안되었다.

도 1을 참조하면, 자바 명령어 집합(20)과 일반적인 RISC 명령어 집합(22)이 겹친다는 것을 알 수 있다. 자바 가상 머신 명령어는 수행될 연산을 나타내는 연산 코드(opcode) 및, 그 뒤에 따라나오는, 연산이 수행될 값을 나타내는 제로 또는 그보다 많은 피연산자(operand)로 구성된다. 자바 가산 머신 명령어 집합에는 총 201 개의 연산 코드가 있다. 자바 가상 머신 명령어 집합의 중요한 특징은 많은 수의 명령어들이 고도의 의미적 내용(high semantic content)을 가지고 있다는 것이다. 이러한 명령어들은 실리콘으로 구현하기 어렵다. 일반적으로 하나의 클럭 사이클에 높은 구조 정보를 가진 명령어들을 실행하는 것은 불가능하며, 이들을 여러 개의 덜 복잡한 명령어들로 나누는 작업은 리소스 할당과 타이밍 제한 면에서어렵다. 자바 명령어들 중 많은 수는 타입에 따라 다르기 때문에(type specific), 동일한 문법적 의미를 가진 명령어들이 많이 있다.

RISC는 "축소된 명령어 집합 컴퓨터(reduced instruction set computer)"의 약자이다. RISC 아키텍쳐에 깔려있는 아이디어는 더 간단한 명령어 집합이 더 높은 클럭 주파수와 더 효율적인 파이프 라이닝을 가지고 실행될 수 있으므로 종래의 스택 머신보다 더 높은 쓰루풋을 보장한다는 것이다. RISC의 명령어 집합은 물론 프로세서마다 상이할 것이지만, 일반적으로 다음 명령어들을 가지고 있다: LOAD, STORE, ADD, SUB, AND, OR, SHIFT, BRANCH. 또한, RISC 아키텍쳐는 일반적으로 어떤 형태의 비트 처리 명령어를 포함할 것이다. 자바의 명령어 집합과 일반적인 RISC 명령어 집합을 비교하면, RISC 명령어 대부분이 자바 명령어 집합에 나타난다는 것을 발견할 수 있다. 공통된 명령어들이 겹쳐지는 것(25)은 도 1의 벤다이어그램에 도시되어 있다. 나머지 명령어들은 RISC 하위 레벨 비트 처리 명령어(23), 자바의 상위 레벨 오브젝트 생성 및 처리 명령어(21)로 나뉘어진다. 이러한 관찰로부터 RISC와 자바 스택 머신 모두 대략 같은 하드웨어 리소스를 필요로 한다는 아이디어가 생겨난다. 또한, 자바 가상 머신을 실리콘으로 구현하는 것은 비트 처리, 직접 메모리 어드레싱(direct memory addressing), 및 복잡한 연산 코드의 트래핑(trapping)을 위한 명령어를 지원할 필요가 있다. 또한, 두 아키텍쳐에서 가장 자주 실행되는 명령어는 LOAD/STORE 명령어이다. 두 아키텍쳐에서 이들은 모두 동일한 구조 정보(semantic content)를 가지고 있다. 이들 명령어는 실리콘에서 구현될 때 동일한 하드웨어 리소스를 공유할 수 있을 것이다. 두 개의 명령어 집합의 성질에 대한 이러한 관찰로부터 본 발명의 마이크로 프로세서 아키텍쳐가 개발되었다.

도 2를 참조하면, 본 발명의 마이크로 프로세서(30)는 동일한 데이터 경로를 공유하는 자바 제어 유닛(31)과 RISC 제어 유닛(33)을 포함한다. 두 개의 제어 유닛(31, 33)은 독립적으로 동작하지만, 동시에 동작할 수는 없다. 다시 말해서, 두 개의 가상 프로세서는 하나의 데이터 경로를 공유하지만, 이들이 독립적으로 동작한다고 할지라도 병렬적으로 동작하지는 않는다. 프로세서(30)는 다른 자바 프로세서들과 같은 자바 이진 포맷으로 트랜스레이션(translation)하거나 확장하는 것에 의존하지 않고, 두 개의 직교하는 프로그래밍 모델을 제공한다. 마이크로 프로세서(30)는 본질적으로 폰 노이만(von-Neuman) 아키텍쳐이지만, 별개의 데이터 및 명령어 버스를 가진 하버드(Harvard) 아키텍쳐로 용이하게 확장될 수 있다. 마이크로 프로세서(30)는 상태 레지스터(32)와 프로그램 카운터(34)를 가진 레지스터 파일(35)을 포함한다. 레지스터 파일은 데이터 버스(40)에 접속된다. ALU(arithmetic logic unit, 42)가 레지스터 파일(35)에 접속되고, ALU의 출력이 데이터 버스(40)에 공급된다. 이것은 중요한 경로의 상당 부분이 ALU를 거치기 때문이기도 하고, 이것이 내장형 마이크로 프로세서 내의 더 큰 모듈들 중 하나이기 때문이기도 하다. 최소한의 ALU 구현은 ADD, SUB, AND, OR, XOR, MOVE, SET, CLEAR, SHIFT, ROTATE 연산을 수행해야 한다. 레지스터 파일(35)과 프로그램 카운터(34)의 출력은 가산기(36)를 통하여 처리되어, 어드레스 멀티플렉서(37)로 보내진다. 어드레스 멀티플렉서(37)는 또한 어드레스 버스(41)에 접속된다. 명령어페치 디코더(39)는 데이터 버스(40)로부터 신호를 수신하고, 스택 제어 유닛(38)으로 출력을 제공한다.

도 3을 참조하면, 마이크로 프로세서는 먼저 초기화 코드가 실행되도록 하기 위하여 RISC 동작 모드에서 전력이 공급된다. 초기화(52) 후에, 마이크로 프로세서는 자바 모드로 전환하여(53) 자바 프로그램을 실행하기 시작한다(54). 마이크로 프로세서는 세가지 이벤트, 즉, 인터럽트(59), 구현되지 않은 자바 명령어(60), 및 RISC 모드로 다시 전환하기 위한 지정된 자바 연산 코드(58) 중 하나의 이벤트가 발생할 때까지 자바 모드로 동작한다. 만일 이 이벤트들 중 어느 하나가 발생하면, 프로세서는 미리 정해진 어드레스로 점프하여 RISC 모드로 전환하여(55), 이러한 방식으로 이벤트를 처리할 것이다. RISC 루틴(56)을 마치자 마자, 프로세서는 다시 자바 모드로 전환하여(57), 떠났던 위치에서 자바 코드를 계속 실행한다.

이렇게 해서, 자바 모델은 프로그램의 자바 부분을 실행할 수 있다. 이러한 부분은 회사의 소프트웨어 라이브러리에서 이미 구현되어 있는 네트워크 기능 또는 알고리듬이 될 수 있고, 재사용을 위한 기존(legacy) 소프트웨어의 모듈을 형성한다. RISC 모델은 복잡한 명령어들을 마이크로 코드로서 실행함으로써 자바 코드의 실행에 도움을 준다. RISC 모델은 또한 센서와 액츄에이터(actuator)와 같은 고도로 전문화된 주변 장치를 제어하는데 사용될 수 있는 유연성 있는(flexible) 하드웨어 인터페이스를 제공한다. 자바 가상 머신 스펙과 호환성이 있기 위해서는, 모든 자바 명령어가 구현될 필요가 있다. 그러나, 소형 내지 중형 애플리케이션을 목표로 하는 내장형 프로세서에서 자바 가상 머신에 의해 지원되는 숫자 포맷들 중몇 개는 과도하다(excessive). 예를 들어, 부동점 유닛(floating point unit)을 제공하는 이 세그먼트에는 프로세서가 거의 없다. 자바의 보다 복잡한 명령어들 중 몇 개는 트래핑(trapping)되어 마이크로 코드로서 실행되어야 한다. 어느 명령어를 트래핑하고 어느 것을 바로 하드웨어로 구현할 것인지는 대개 설계자가 결정하는, 구현에 따른(implementation specific) 이슈이다. 또한, 본 발명은 본 명세서에서 설명하는 RISC 아키텍쳐 외에 다른 유형의 RISC 아키텍쳐에서도 사용될 수 있기 때문에, 어느 RISC 명령어 집합을 사용할지는 선택하는 RISC 모델에 달려 있다.

고안된 마이크로 프로세서의 아키텍쳐에 있어 중요한 아키텍쳐 요소는 레지스터 파일이다. 이 모듈은 자바 모드에서 푸시(push)-팝(pop) 스택의 기능을 가지고 있고, RISC 모드에서 종래의 load/store 레지스터 파일로서 작용한다. 이것은 또한 두 개의 가상 프로세서가 서로 통신하는 것을 가능하게 하는 모듈이다. 도 4를 참조하면, 아키텍쳐의 RISC 부분(71)에 N 개의 레지스터를 가진 레지스터 파일이 보이고, RISC 아키텍쳐는 load/store 명령어(72, 73, 74)를 통하여 데이터 메모리를 가진 레지스터들과 인터페이스한다. 프로그램 카운터와 상태 레지스터는 레지스터 파일에 포함되어 있다. 직교성(orthogonality)을 유지하기 위하여, 이러한 특수 레지스터들은 다른 임의의 레지스터와 같이 액세스 가능하다. 자바 제어 유닛(61)은 동일한 레지스터 파일을 M = N/2 원소를 가진 푸시/팝 스택으로 간주한다. 데이터는 레지스터 스택으로 푸시되고(62), 레지스터 스택으로부터 자바 제어 유닛으로부터 팝된다(63). 도 4는 RISC와 자바 모드에서 볼 수 있는 레지스터 파일의 절반을 보여준다. 레지스터(80, 81, 82)는 자바 제어 유닛(61)과 회로의 RISC 부분(71) 모두에서 볼 수 있다. 나머지 N/2 레지스터들은 무엇보다도 프로그램 카운터, 상태 레지스터, 스크래치(scratch) 레지스터, 및 스택 제어 레지스터용으로 사용된다. 스택은 순환 스택(circular stack)으로서 구현되므로, 필요한 스택 사이즈는 상대적으로 작다. 스택 사이즈는 조절가능하고(scalable), 스택 원소의 개수는 구현에 따른 이슈로 남겨둔다. 스택 오버플로우(overflow)/언더플로우(underflow)는 오버플로우/언더플로우 메카니즘을 통하여 메모리(83)에서 복사될 수 있다. 가능한 스택 오버플로우/언더플로우 메카니즘은 또한 여러 경우에 맞게 개발될 수 있다.

도 5를 참조하면, 전체 레지스터 파일(90)이 도시되어 있다. RISC 모듈은 모든 레지스터들로부터 판독하거나 기록할 수 있고, RISC 모듈이 어느 레지스터를 액세스할 것인지에 대하여서는 하드웨어 제한이 없다. RISC 모듈이 프로그램 실행 동안에 특수 레지스터에 덮어쓰기하지 않는다는 확인이 소프트웨어 층에서 이루어져 있다. 프로그래머가 특수 레지스터들 중 하나를 임시 메모리로 사용하기를 원할 경우, 만일 이 레지스터에 있는 값이 실행 동안에 나중에 복구되어야 할 필요가 있다면 이 값이 RISC 모듈 스택에 저장되어야 할 것이다. 도 5에 도시된 바와 같이, 전체 RISC 레지스터 파일(90)이 자바 피연산자 스택(91)을 포함하는데, 이 자바 피연산자 스택(91)은 도 4를 참조하여 설명한 바와 같이, 다수의 레지스터(92, 93, 94, 95)를 포함한다. RISC 레지스터(90)는 또한 다수의 특수 레지스터를 포함한다. 특수 레지스터는 프로그램 카운터(106), 프로그램 카운터 베이스(105), 상수 풀(constant pool) 베이스 어드레스(107), 로컬 변수 베이스 어드레스(104), 자바 스택 포인터(103), 상태 레지스터(101), RISC 스택 포인터(102)를 포함한다. 이들 레지스터 기능들의 대부분은 자명하다(self explanatory). 프로그램 카운터 베이스 레지스터(105)는 자바 프로세서에 의해 사용된다. 새로운 메서드(method)가 호출될 때, 자바 모듈의 프로그램 카운터는 제로로 설정된다. 프로그램 카운터 베이스 레지스터는 이 메서드가 호출되는 주소를 저장한다. 어드레스 버스 상에서 이 레지스터는 프로그램 카운터와 더해져서, 프로그램 메모리의 정확한 위치로부터 명령어들을 페치해온다. 로컬 변수 베이스 어드레스 레지스터(104)는 유사한 기능을 수행한다. 이것은 자바 메서드에서 로컬 변수에 대한 베이스 어드레스를 저장한다. 이러한 레지스터들은 레지스터 파일(90) 외부에 상주하도록 선택될 수도 있을 것이다. 그러나, 임의의 RISC 명령에 의해 레지스터에 도달할 수 있기 때문에, 특수 레지스터에 대하여 연산하는 특수 명령어들을 구현해야 하는 것보다 레지스터 파일 내부에 이러한 레지스터들을 구비할 수 있는 것이 장점을 나타낸다. 자바 스택 포인터(103)는 자바 피연산자 스택의 정상의 위치를 계속 추적하므로, 피연산자가 어디로부터 페치될 것인지 또는 피연산자가 어디에 기록될 것인지 M 개의 레지스터들 중 특정한 레지스터를 계속 추적한다. RISC 스택 포인터(102)는 레지스터 파일이 꽉 찰 경우, RISC가 변수들을 임시로 저장할 수 있는 메모리 내의 장소를 가리킨다.

가상 프로세서들은 레지스터 파일을 통하여 서로 통신할 수 있다. RISC 유닛은 무엇보다도 복잡한 자바 명령어들을 실행한다. 이러한 작은 RISC 프로그램들은 자바 피연산자 스택의 정상으로부터 그들의 피연산자들을 페치해야 하고, 그 결과를 다시 자바 피연산자 스택의 정상에 두며, 동시에 자바 스택 포인터가 수행된 연산에 따라 증가 또는 감소되는지를 확실히 한다. 이것은 RISC 명령어 포맷이 단지 정적인(static) 레지스터들만을 처리할 것이기 때문에 문제가 된다. 이 문제는 상태 레지스터의 두 개의 상태 비트를 설정하고 클리어(clear)함으로써 해결된다. 각 상태 비트는 소스(X) 또는 목적지(destination, Y) 피연산자가 명령어에 나타난 레지스터로부터 페치될 것인지 또는 레지스터 번호가 자바 스택 포인터 레지스터로부터 동적으로 판독될 것인지를 제어한다. 자바 명령어를 대체하는 RISC 프로그램은 적당한 때에 이러한 비트들을 설정하고 클리어해야 한다. 레지스터 파일의 이 두 개의 비트를 설정함으로써, RISC 프로세서는 스택 레지스터의 정상의 내용을 어느 레지스터를 액세스할 것인지에 대한 인수(argument)로서 사용할 수 있다.

도 7을 참조하면, 마이크로 프로세서의 모드 이동 메카니즘을 구현한 것이 도시되어 있다. 자바 제어 모듈(120)과 RISC 제어 모듈(122)이 데이터 경로로의 제어 라인(130)을 생성하는 멀티플렉서(124)에 연결되어 있다. 레지스터 파일 내의 상태 레지스터(126)는 자바 제어 모듈(120) 및 RISC 제어 모듈(122)에 공급되는 제어 비트(128)를 포함한다. 제어 비트(128)는 또한 멀티플렉서(124)로의 제어 입력으로서의 역할을 한다. 제어 비트는 제어 유닛, 자바 제어 유닛(120), 또는 RISC 제어 유닛(122) 중 어느 것이 동작 중에 있는지 결정한다. 제어는 양쪽 제어 모듈에서 미리 정해진 상태에서 이동된다. 따라서, 제어는 양쪽 머신이 동일하게정의된 상태에 있을 때 동시에 이동된다.

자바 가상 머신 스펙은 인터럽트의 개념을 설명하지는 않는다. 따라서, RISC 모듈에 의해 디폴트(default)로 인터럽트가 처리된다. 도 6을 참조하면, 인터럽트 처리 메카니즘이 도시되어 있다. 일반적으로 인터럽트가 발생하면, 프로세서는 미리 정해진 어드레스로 점프하여 RISC 모드로 전환하기 전에, 특정 플래그와 같은 구현에 따른(implementation specific) 조건들이 참(true)인지 체크한다. 그 후, 복귀 어드레스가 RISC 스택의 정상 위에 저장된다. 도 6에서 점프 어드레스(0x63)(112)가 미리 정해진 어드레스(0xaf)(111)에 저장되는 것이 도시되어 있다. 이 미리 정해진 어드레스에서 점프 어드레스가 판독되고 새로운 어드레스로의 적당한 분기(branch) 명령어가 수행된다. 이 새로운 어드레스에서 RISC 모드로 실행이 계속된다. 정상적인 프로그램 수행으로 복귀하기 위해서 프로세서는 "Return from Interrupt"라는 RISC 명령어를 수행하는데, 이에 따라, 복귀(return) 어드레스가 RISC 스택의 정상으로부터 팝된다.

명령어 트래핑 메카니즘은 인터럽트 메카니즘과 유사한 단계들을 포함한다. 구현되지 않은 명령어가 발생할 때, 자바 제어 모듈이 이것을 검출하고, 복귀 어드레스가 스택의 정상 위에 저장된다. 그 후, 프로세서가 RISC 모드로 전환하고, 메모리의 미리 정해진 위치로부터 점프 어드레스를 페치한다. 그 후 RISC 모듈은 마지막 단계에서 페치된 어드레스에서 실행을 계속한다. 인터럽트 메카니즘과 유사한 트래핑 메카니즘을 가짐에 따라 최대한의 유연성(flexibility)을 달성한다. 왜냐하면, 첫 번째 점프 어드레스만이 설계시 미리 정해지기 때문이다. 이것은 소프트웨어 링커(linker)가 프로그램에 실제로 존재하는 자바 연산 코드에 대한 RISC 루틴을 연결하기만 함으로써 메모리 사용을 최적으로 계획할 수 있도록 하기 때문에, 소중한 메모리 공간을 절약할 수 있다. RISC 루틴은 스택의 정상으로부터 프로그램 카운터를 팝하고 이 프로그램 카운터를 프로그램 카운터 레지스터에 저장함으로써 종료된다. 이것은 자바 프로그램이 정확한 장소에서 계속되는 것을 보장할 것이다. 또한, 마이크로 프로세서는 스택 오버플로우/언더플로우 처리 메카니즘을 가지고 있다. 자바 푸시-팝 스택에서의 이 메카니즘은 명령어 트래핑을 위한 기존 로직을 재사용함으로써 구현될 수 있다. 오버플로우가 발생할 때, 프로세서는 오버플로우 플래그를 트래핑하고 소정의 어드레스로 점프하게 되는데, 이 소정의 어드레스에서 오버플로우/언더플로우 상태를 처리할 소프트웨어 프로시져로의 점프 벡터를 알 수 있다.

도 8을 참조하면, 이러한 프로세서 개념을 가진 시스템을 위한 일반적인 런 타임 환경이 도시되어 있다. 개발자는 보통의 자바 컴파일러(142)에서 자바 소스 코드(141)를 컴파일할 수 있고, 자바 클래스 파일(144)을 마칠 수 있다. 프로세서가 파일 로더(file loader)와 자동 메모리 관리 시스템을 가진 OS를 가지고 있다면, 이 프로세스의 나머지는 동적으로 그리고 자동적으로 일어날 수 있다. 그러나, 작은 내장형 시스템은 종종 OS가 필요 없고, 프로그램의 메모리 이미지가 외부 플랫폼에서 생성되어야 한다는 점에서, 그 후 이 프로세스의 나머지는 수동으로 행해져야 한다. 자바 클래스 파일(144)은 링커(linker, 148)를 통하여 파싱(parsing)되어야 한다. 링커를 통한 프로그램 실행은 클래스 파일이불법적인(illegal) 연산 코드를 포함하고 있지 않다는 것을 증명하고, 인스트루먼테이션 솔루션(instrumentation solution)에 따라 코드 또는 피연산자를 수정하고, 애플리케이션을 특정한 자바 클래스 라이브러리(145)와 링크시키고, 어셈블리 코드를 RISC 부분(143)과 링크시키고, 힙(heap) 영역을 설정하고, 분기 및 점프 어드레스를 설정하며, 메모리 맵을 작성할 것이다. 링커로부터의 출력은 메모리 이미지가 될 것이며, 이 메모리 이미지는 내장형 시스템(152)의 ROM 또는 플래시 메모리(151)로 전송될 것이다. 자바 프로세서를 만드는 목적 중 큰 부분은 프로그래머가 가능하면 제한을 받지 않고 자바 프로그래밍 언어를 사용할 수 있어야 한다는 것이다. 그러나, 이 경우 지원되는 타입들만이 사용될 수 있고, 제한된 런 타임 라이브러리만이 이용가능할 것이다. 그러나, 이러한 제한은 자바의 주요 특징을 사용하는데 제한이 되지는 않는다.

자바 가상 머신 스펙은 201 개의 명령어를 가지고 있는데, 이들 중 많은 부분은 타입에 따라 다르다(type specific). 하드웨어로 구현되는 명령어의 수와, 트래핑되는 명령어의 수는 사용되는 RISC 아키텍쳐에 따라 다르다. 다른 타입들의 RISC 아키텍쳐는 하드웨어적으로 구현되고 트래핑되는 명령어의 수에 영향을 미칠 것이다. 다음 명령어들은 작은 내장형 프로세서에서는 중요하다고 간주되지 않기 때문에, 본 발명의 바람직한 실시예에서 하드웨어적으로 구현되지는 않았다. 이러한 명령어들로 "float" 타입의 모든 명령어, "double" 타입의 모든 명령어, "long" 타입의 모든 명령어가 있다. 이것은 201 개의 가능한 자바 명령어로부터 약 90 개의 명령어를 없앤다. 나머지 명령어들 중에 68 개의 명령어는 자바 가상 머신에서구현되고 43 개의 명령어는 RISC 루틴으로서 트래핑되고 실행된다. RISC 루틴으로서 트래핑되고 실행되는 명령어들은 다음 표 1에 나와 있다.

[표 1]

연산코드(opcode)	니마닉스(Mnemonics)	연산코드	니마닉스	연산코드	니마닉스
18	ldc	104	imul	182	invokevirtual
46	iaload	108	idiv	183	invokespecial
50	aaload	112	irem	184	invokestatic
51	baload	170	tableswitch	185	invokeinterface
52	caload	171	lookupswitch	187	new
53	saload	172	ireturn	188	newarray
79	iastore	173	lreturn	189	anewarray
83	aastore	176	areturn	190	arraylength
84	bastore	177	return	191	athrow
85	castore	178	getstatic	192	checkcast
86	sastore	179	putstatic	193	instanceof
90	dup_x1	180	getfield	194	monitorenter
91	dup_x2	181	putfield	195	monitorexit
92	dup2			197	multianewarray
93	dup2_x1
94	dup2_x2

구현에 있어서 이러한 선택을 한다면, 실행되는 명령어의 약 70%가 프로세서에서 직접 실행될 것이고, 약 30%가 RISC 프로그램으로서 트래핑되고 실행될 것이다. 이러한 퍼센티지는 동적 측정으로부터 유도된다.

RISC 아키텍쳐의 경우 SMILE RISC 아키텍쳐가 선택되었다. SMILE은 "Scalable Microcontroller Library Element"의 약자이고, 런던 대학교의 앤드류 케이. 베츠(Andrew K. Betts)에 의해 개발되었는데, 다음 간행물에 내용이 설명되어 있다.

1993년 앤드류 케이. 베츠, 아이. 볼센스, 이. 시카드, 엠. 레노딘, 및 에이. 존스턴 저 "유로마이크로 진행에 있어(In Proceedings of Euromicro)"중 "SMILE, scalable microcontroller library element"

1994년 앤드류 케이. 베츠, 아이. 볼센스, 이. 시카드, 엠. 레노딘, 및 에이. 존스턴 저 "마이크로 프로세서와 마이크로프로그래밍". "SMILE, scalable microcontroller library element"의 39쪽 259-262행

1993년 앤드류 케이. 베츠 저 런던대학교 기술 보고서 V.6. "SMILE, scalable microcontroller library element"

SMILE 스펙의 핵심적인 세부사항은 이하 본 명세의 끝 부분에 설명되어 있다. SMILE은 작은 내장형 시스템을 타겟으로 하고 있고, 특정한 범위성 퀄리티(certain scalability qualities)를 가진다. 본 발명의 가상 RISC는 도 9에 도시된 레지스터 어드레싱을 수용하기 위하여(32) 명령어 포맷이 약간 바뀌었다는 점만 제외하면, 변경된 SMILE 명령어 집합을 구현한다. 또한, 본 발명의 상태 레지스터들은 아래의 도 18을 참조하여 설명되는 표준 SMILE 스펙 레지스터로부터 변경되었다. 본 발명의 상태 레지스터들은 도 10에 도시되어 있고, 판독/기록 레지스터 SR1(180), 및 판독 전용 부분(185)과 기록 전용 부분(188)을 가진 제2 레지스터 SR2를 포함한다. 판독/기록 레지스터 SR1(180)은 자바 플래그(183)를 포함하는데, 이는 위에서 도 6을 참조하여 설명되었다. 또한 판독/기록 레지스터 SR1(180)은 Rx 플래그(182)와 Ry 플래그(181)를 포함하는데, 이하에서 도 14를 참조하여 설명할 것이다. 이 레지스터의 나머지 비트들은 도 18 내지 도 21을 참조하여 이하에서 설명되는 SMILE 스펙과 동일하다. 또한, 어떤 명령어들의 범위는 확대되었고, 모든 레지스터는 타입이 "long"으로 정의되고, 레지스터 스케일링 파라미터들이 변경되었으며, 새로운 명령어 몇 개가 추가되었다. 새로운 명령어는 returnfrom Java trap(RJ), RISC to Java control transfer(R2J), shift Java alignment left(SJL), 및 shift Java alignment right(SJR)이다. 이러한 새로운 명령어의 의미(semantics)는 도 11 내지 도 16을 참조하여 이하에서 설명한다.

도 11 내지 도 16에 도시된 신호들은 리셋 신호(241), 클럭 신호(242), 자바 명령어 레지스터(243), RISC 명령어 레지스터(244), 자바 플래그(245), 데이터 버스(246), 프로그램 카운터(247), 어드레스 버스(248), 자바 스택 포인터(249), 및 실제 시간(250)이다. 또한, 각 시간 주기에 대한 명령어 시퀀스(201-206)가 도시되어 있다.

도 11에 처음 10 개의 클럭 사이클이 도시되어 있다. 리셋 신호(241)가 비활성화된 후에, 프로세서는 RISC 모드에 있고, 어드레스 0x0000에서 판독한 명령어를 실행함으로서 초기화된다. 그 후 프로세서는 일련의 load 명령어를 실행함으로써 특수 레지스터인 스택 포인터(Stack Pointer), 로컬 변수 베이스 어드레스(Local Variable Base Address), 및 프로그램 카운터 베이스 어드레스(Program Counter Base Address)를 초기화한다. 여기서 설명된 초기화는 리셋 루틴에 대하여 유효하다. 자바 호출(call)은 로컬 변수 베이스 어드레스와 프로그램 카운터 베이스 어드레스만을 초기화하는 것을 포함할 것이다. 또한, 새로운 클래스(class)가 호출되었다면, 상수 풀 베이스 어드레스(Constant Pool Base Address)가 초기화되어야 할 것이다. 시간(95)에, 프로세서는 상태 레지스터의 비트 6을 설정하는 것에 상당하는 명령어 R2J를 실행한다.

명령어 R2J가 실행된 이후에, 프로세서는 다음 클럭 사이클에서 자바 모드로전환한다. 제어의 이동은 도 12에 도시된 바와 같이, 끊기지 않고 연속적이다(seamless). 자바 플래그 신호(245)가 시간(105)에 하이(high)로 설정되고, 프로그램 카운터(247)는 모든 자바 메서드가 제로에서 시작하기 때문에 제로로 설정된다는 것을 유의해야 한다. 어드레스 버스(248) 상의 어드레스는 프로그램 카운터와 프로그램 카운터 베이스 어드레스 레지스터의 합이다.

도 13에 도시된 바와 같이, 시간(125)에서 자바 명령어 "istore <index>"가 실행된다(자바 명령어 레지스터(243)의 "36"). 이 명령어는 "Top of Stack" 변수를 팝 하고, 그것을 어드레스 "<index>"의 로컬 변수에 저장한다. 숫자 "0"(데이터 버스(246) 참조)이 어드레스 버스(248) 상의 어드레스 "184"에 저장된다는 것을 알 수 있다. 어드레스는 LV 베이스 어드레스와, PC 베이스 어드레스와, 명령어에 속한 피연산자 <index>를 더하여 계산된다. 여기서 <index>는 0x4였고 따라서, 주소는 0x69 + 0x4B + 0x04 = 0xB8 = 184가 된다. 또한, 현재 "Top of Stack"인 레지스터를 가리키는 스택 정상 포인터(Top of Stack Pointer, 249)는 숫자가 스택으로부터 팝될 때 감소된다는 것을 관찰할 수 있다.

시간(215)에서 "istore"의 실행은 도 13에 도시된 바와 같이 두 개의 클럭 사이클이 소요된다. 나중에 도 13에서 "istore"가 시간(245)에 다시 실행된다. 이 때, 메모리에서 명령어를 정렬하는 것(alignment)은 연산 코드와 피연산자가 상이한 클럭 사이클에서 판독되도록 한다. 이렇게 해서 이 명령어의 실행이 3 개의 클럭 사이클 동안 행해진다.

도 14에서 시간(315)에 자바 제어 모듈이 구현되지 않는 명령어 "newarray"에 도달한다. 이 명령어는 트래핑된다. 전술한 바와 같이, 트래핑 시퀀스는 4 개의 클럭 사이클을 차지한다. 정상 시퀀스(top sequence)의 끝(350)에서 자바 플래그는 "low"로 된다. 프로세서는 이제 RISC 루틴으로서 명령어 newarray를 실행하기 시작한다. 이 명령어는 어레이를 초기화하고 이 어레이에 대한 시작 어드레스로 돌아온다. RISC 명령어 SJL과 SJR은 메모리에서 자바 연산 코드의 정렬을 처리하는 move 명령어이다.

도 15를 참조하면, 자바 스택 포인터가 사후 증가(post-increment) 기능을 가진다. 시간(435)에서 RISC가 정확한 레지스터를 액세스하도록 하기 위하여 스택 포인터가 감소된다. 다음으로, 도 14의 시간(455)에서 상태 레지스터의 RX 플래그가 설정된다. 이는 RISC가 자바 스택 포인터 레지스터를 판독하여 "Top of Stack"을 결정하고, 이를 다음 명령에서 RX 레지스터로서 사용함을 의미한다. 이는 상수가 "Top of Stack"으로 로딩되는 시간(465)에 발생하는 것이다. 이 상수는 새로 생성된 어레이의 어드레스를 돌려주는 RISC 루틴으로부터 나오는 복귀(return) 값이다. 이 예에서 어레이는 정적이고(static), 따라서 리턴 값은 상수로서 로딩된다.

마지막으로 RISC가 도 16의 시간(515)에서 자바 모듈로 다시 제어를 돌려주기 전에 시간(495)에서 자바 스택 포인터가 다시 증가된다. 그 후 프로세서는 자바 모드로 계속 실행된다.

Smile 스펙

전술한 바와 같이, SMILE RISC 스펙이 본 발명의 구현에 있어 선택되었다.본 발명에서 사용된 SMILE 구현의 스펙이 여기서 설명된다.

SMILE 마이크로 컨트롤러는 여러 가지 조건들, 즉, 조절가능한(scalable) 사이즈, 디자인 단순성, 적당한 속도 및 적당한 코드 효율을 만족시켜야 한다. 일반적으로 SMILE은 타이머, 메모리 및 어떤 형태의 아날로그 인터페이스를 포함하는 더 큰 시스템의 일부가 될 것이다. 설계는 실지로 응용할 수 있고 관련이 있을 때마다 RISC 원리를 따를 것이다. 컴팩트한 명령어 집합(24 개의 명령어)은 다음 특징을 가질 것이다.

* 균일성(uniformity): 모든 타입의 연산은 모든 프로세서 레지스터와 모든 프로세서 레지스터의 조합에 같은 방식으로 적용될 것이고(상태 레지스터에 대한 몇가지 연산을 제외함), 모든 명령어가 조건부가 될 것이다(conditioned).

* 완전성(completeness): 명령어 집합이 내장형 제어의 애플리케이션 분야에 관하여 완전한 것이 될 것이다.

* 직교성(orthogonality): 명령어 집합은 직교적일 것이고, 디코딩되지 않은 명령어는 존재하지 않을 것이다.

* 파라미터화(parameterization) 및 조절가능성(scalability): 사용자가 코어 하드웨어를 변경하는 입장에 있을 수 있기 때문에, 설계는 파라미터화될 것이다. 또한 메모리의 폭에 따라(가장 작은 폭은 4 비트임) 설계의 크기를 조절(scale)하는 것이 가능할 것이다. 메모리 폭이 감소될 때, 기능성이 적절하게(gracefully) 저하될 것이다. 마지막으로 명령어 집합의 확장이 애플리케이션에 따른(application specific) 명령어의 추가를 통하여 가능할 것이다.

다음 세 개의 파라미터가 SMILE의 특정한 버전을 특징화하기 위하여 지정될 것이다.

WSR 짧은 레지스터의 폭(비트)WSR≥4

WIR 명령어 레지스터의 폭 WIR≥12

NRE 레지스터의 수 NRE≥8

다음 제한이 상기 파라미터들의 선택에 적용된다. NRE는 2의 제곱이다.

6 ≤ WIR - 2log₂(NRE) ≤ 10

SMILE 버전은 SMILEWSR_WIR_NRE로서 지정될 것이다.

다음 파라미터들이 위로부터 유도된다.

WRFinsn에서 레지스터 필드의 폭2log₂(NRE)

WCFinsn에서 condn. 필드의 폭WIR - WRF - 6

NISinsn 레지스터에서 segs의 수(WIR + WSR - 1)/WSR (정수의 끝을 버림(truncated))

WLR긴 레지스터의 폭2·WSR

WIF명령어 필드의 폭= 3

WAF어드레스 모드 필드의 폭= 3

NSR짧은 레지스터의 수2^(WRD/2)/ 2

NLR긴 레지스터의 수NSR

NPA 프로세스 어드레스의 수2^WLR

NTA총 어드레스의 수2^2WLR

프로세서는 인터럽트시 프로세스간에 전환된다. 각 프로세스는 NSR + NLR 의 집합을 범용 레지스터로 간주할 것이다. 레지스터 L[NLR-1]은 프로그램 카운터, PC가 될 것이다.

레지스터 L[0]는 스택 포인터, SP가 될 것이다. 레지스터 S[NSR-1]는 인터럽트 제어(Interrupt Control) 및 상태 레지스터(Status Register), SR가 될 것이다. "로컬"로 지정된 레지스터들은 인터럽트시에 스택된다. 로컬 레지스터들은 프로그램 카운터, PC(L[NLR-1]), 상태 레지스터, SR((S[NSR-1]), 메모리 구성 레지스터, MCR이 될 것이다. 다른 모든 레지스터는 "글로벌(global)"로 지정될 것이다. 짧은 레지스터들이 긴 레지스터들과 연산시 결합될 때, 또는 이들이 어드레스로서 사용될 때, 이들은 제로를 가지고 확장된다(zero-extended). 이는 짧은 레지스터가 데이터 메모리의 제1 페이지(2^WSR위치)를 가리키도록 사용될 수 있게 한다.

다음 다이어그램에 의해 정의되는 바와 같이, 상태 정보가 두 개의 레지스터, SR1과 SR2에 저장된다. 이 정보를 액세스하는데 사용되는 어드레싱 모드는 도 18에 도시되어 있는데, 이하에서 설명한다.

도 18을 참조하면, 상태 비트는 다음과 같다.

SR1 (판독/기록), 411:

U 사용자 비트 - 지정된 기능이 없음

N부정(negative) 플래그

V오버플로우 플래그

Z제로 플래그

C 캐리 플래그

SR2(판독 전용), 421:

M= Z + Cbar ("더 낮거나 같은" 조건을 편리하게 액세스함)

I= Z + L ("더 작거나 같은" 조건을 편리하게 액세스함)

L= N ^ V("더 작은" 조건을 편리하게 액세스함)

E이것이 설정될 때 인터럽트가 인에이블됨

SR2(기록 전용), 422:

S 다른 명령어들에 의해 1로 설정된 TB & FB 명령어들의 결과를 보관함

K 명령어가 명시적으로 클리어하지 않는다면 1로 설정됨

P 명령어가 명시적으로 클리어하지 않는다면 1로 설정됨

E위와 같음

이러한 스펙 버전에서 데이터와 명령어 메모리는 동일할 것이다. 프로그램 카운터를 포인터로서 사용하는 메모리 액세스는 명령어 메모리를 판독할 것이고, 다른 모든 것들은 데이터 메모리를 판독하거나 기록할 것이다(nb, 따라서, 즉시 상수(immediate constant)가 명령어 메모리에 있음). 명령어 메모리에 대한 액세스는 판독 전용이다. 메모리는 연산에 따라 shorts로서 또는 longs 으로서 액세스될 것이다. longs의 상위 부분과 하위 부분은 변환 규칙(little endianconvention)에 따라 배열될 것이다.

다음의 표 2에 명령어 집합이 나타나 있다.

[표 2]

다음은 표 2에 도시된 명령어 집합의 속성이다. ST x, y는 허용된 명령어가 아니다. 상태 비트 K와 P는 모든 명령어에 의해 영향을 받는다. 모든 명령어는 조건(위 표에는 도시되지 않음)을 지정하기 위하여 추가된 부가적인 필드 <cdn>를가질 수 있다. 이것이 지정되지 않는다면, 디폴트 조건이 S 비트를 테스트한다. 이 비트는 TB와 FB를 제외한 모든 명령어에 의하여 설정되며, 명령어는 테스트의 결과에 따라 이 비트를 설정하거나 클리어한다. 명령어들은 항상 실행되고, 적당한 상태 비트들이 설정된다. 그러나, <cdn>이 참일 때 결과는 저장되기만 한다. y 결과가 pre-decrement 명령어와 post-increment 명령어에서 항상 저장된다. VS 명령어는 점프 어드레스가 명령어 뒤에 오는 것이 요구되지 않는다는 점에서 JS 명령어와 동일하다. 대신, 이 이드레스는 SMILE 코어의 내부인 어드레스 테이블로부터 페치되고 적당한 어드레스를 검색하는데 사용되는 인덱스가 n - VS 인수(argument)이다. 따라서, 이 명령어는 점프의 목적지가 명령어 그 자체로 코딩되는 서브 루틴 점프를 허용한다.

Ax 피연산자에 대한 어드레싱 모드가 다음과 같이 정의된다.

어드레싱 모드 <피연산자> Ax에 대한 유효 어드레스

단순(simple)xx

간접(indirect (xid))(x)M[x]

Ay 피연산자에 대한 어드레싱 모드는 다음과 같이 정의된다.

어드레싱 모드 <피연산자> Ay에 대한 유효 어드레스

레지스터(register)yy

사전 감소(pre-decr)-(y)M[y-1], y decremented

사후 증가(post-incr)(y)+M[y], y incremented

변위(displacement)<disp>(y)M[<disp>+y]

즉치(immediate)<constant>M[PC]

변위(displacement) 어드레싱 모드의 경우, 메모리에서 변위가 명령어 뒤에 따라 나온다. 사후 증가(post-incr) 어드레싱 모드와 사전 감소(pre-decr) 어드레싱 모드의 경우, x 필드의 레지스터가 짧을 때 증가/감소 값이 1이고, 아닐 때는 증가/감소 값이 2이다. <disp>는 변위(displacement)이고, y와 폭이 동일하다. 이것은 y에 더해진 후, y가 짧을 때, 모드가 메모리의 첫 페이지의 임의의 원소를 액세스하는데 사용될 수 있도록 결과가 제로를 가지고 확장된다(zero-extended). 인수(argument) Ay와 Ay는 항상 레지스터 x와 동일한 폭을 가지는 것으로 간주된다. 만일 y 어드레싱 모드가 "레지스터(register)"이고, y가 x보다 길다면, y의 최하위 부분이 연산에 사용된다. 만일 y 어드레싱 모드가 "레지스터(register)"이고 y가 x보다 짧다면, y가 연산을 위해 제로를 가지고 확장된다. 상태 레지스터 어드레스는 특수한 논리 해석(interpretation)을 가지고 있다.

명령어 인수 유효 인수(effective argument)

Ax = SRAy = SR1

Ax = (SR)Ay = SR2

Ay = SRAy = SR1

Ay = -(SR)Ay = -(SR)

Ay = (SR)+Ay = (SR)+

Ay = <disp>(SR)Ay = M[<disp>]

다르게 지정되지 않는 한, S, K, Y는 모든 명령어에서 1로 설정된다(set toone every instruction).

표 3은 상태 계산을 정의하는데, Ax_result가 Ax에 대한 계산 결과를 나타내며, 이는 사실상 연산에 대응하는 조건을 만족할 때만 저장될 것이다. Ay_result는 사전 감소(pre-decrement), 사후 증가(post-increment), 변위(displacement) 어드레싱 모드에서 y 필드에 대한 유효 어드레스의 계산 결과를 나타낸다.

[표 3]

이동(Transfers)

LDAx, AyZ = if (Ax_result == 0 ? 1 : 0)

STAx, AyZ = if (Ay_result == 0 ? 1 : 0)

산술 및 논리

ADAx, AyC = if (carry out of Ax_result ? 1 : 0)

Z = if (Ax_result == 0 ? 1 : 0)

N = msbit of Ax_result

SUAx, AyC = if (borrow from Ax_result ? 0 : 1)

Z = if (Ax_result == 0 ? 1 : 0)

V = if (overflow of Ax_result ? 1 : 0)

N = msbit of Ax_result

ANAx, AyZ = if (Ax_result == 0 ? 1 : 0)

N = msbit of Ax_result

ORAx, AyZ = if (Ax_result == 0 ? 1 : 0)

N = msbit of Ax_result

EOAx, AyZ = if (Ax_result == 0 ? 1 : 0)

N = msbit of Ax_result

처리(manipulation)와 테스트

TB Ax, n S = Ax·2ⁿ

Z = Ax·2ⁿ

FBAx, nS = !(Ax·2ⁿ)

Z = !(Ax·2ⁿ)

SBAx, nZ = if(Ax_result == 0 ? 1 : 0)

CBAx, nZ = if(Ax_result == 0 ? 1 : 0)

SLAx, nC = if(carry out of Ax_result ? 1 : 0)

Z = if(Ax_result == 0 ? 1 : 0)

SRAx, nC = if(carry out of Ax_result ? 1 : 0)

Z = if(Ax_result == 0 ? 1 : 0)

SAAx, nC = if(carry out of Ax_result ? 1 : 0)

Z = if(Ax_result == 0 ? 1 : 0)

RLAx, nC = if(carry out of Ax_result ? 1 : 0)

Z = if(Ax_result == 0 ? 1 : 0)

RRAx, nC = if(carry out of Ax_result ? 1 : 0)

Z = if(Ax_result == 0 ? 1 : 0)

RCAx, dC = if(carry out of Ax_result ? 1 : 0)

Z = if(Ax_result == 0 ? 1 : 0)

버전에 따른 것(version specific)

LLAx, nZ = if (Ax_result == 0 ? 1 : 0)

즉치(immediate) 모드 명령어에 대한 코드, IN Ax, <constant>는 <constant> 값 앞에 나오는 IN Ax, (PC)+에 대한 코드와 동일하다. 여기서 후자값은 x 레지스터의 크기를 가진다. 이 문맥에서 IN은 LD ST AD SU AN OR EO를 나타낸다. LD ST AD SU AN OR EO에 대한 명령어 포맷이 도 18에 도시되어 있는데, instr(506)이 명령어 필드이고, ax (formerly id)(504)는 x에 대한 어드레싱 모드 필드이고, ay(503)는 y에 대한 어드레싱 모드 필드이고, cdn(505)은 조건 필드이고, rx, ry(501. 502)는 레지스터 필드이다. 도 19에서 필드의 배열은 최상위 끝에 rx 필드(501)를 가지고 있다. BR, JS, JI, RI, VS, FN의 경우 도 20에 포맷이 도시되어 있다. 이 경우, 포맷 1의 instr, ay, ax에 대응하는 필드는 ST(555), "레지스터(register)", "단순(simple)"(553)에 대응하는 코드가 각각 차지하고 있다. 나머지 세 개의 필드는 그 후 명령어(551)를 지정하는 부분과 조건(554)을 지정하는 부분으로 나뉘어져야 한다. 조건 부분은 조합된 필드의 최하위 비트 4 개이다. 나머지 명령어들은 "처리(manipulate)" 명령어(MA 명령어)로 일컬어진다. LL 명령어가 이 카테고리에 포함된다. 이들의 포맷은 도 21에 도시되어 있다. MA명령어(582)를 코딩하는데 이용가능한 비트의 수는 WIR과 NRE의 함수가 될 것이고, 비트의 최소 수는 5가 될 것이다. 이는 상기 명령어 표에서 TB에서 RC까지 명령어 코딩을 가능하게 하기에 충분하다. 나머지(surplus) 비트는 명령어 LL을 코딩하는데 사용되고, 코딩될 수 있는 문자(literal)의 수는 이용가능한 나머지 비트의 수에 달려 있을 것이다.

SMILE 명령어의 필드는 다음과 같이 코딩된다.

instr:

000 LD

001 ST

010AD

011SU

100AN

101OR

110EO

111MA(즉, 모든 처리(manipulate) 명령어에 대한 instr 필드에서의 코드)

ax:

0Ax = x

1Ax = (x)

ay:

00Ay = y

01Ay = -(y)

10Ay = (y)+

11Ay = #(y)

나머지 필드는 고정된 폭을 가지고 있지 않고, 따라서, 다음 스펙은 특정한 애플리케이션에서 이용가능한 비트의 수에 따라 해석되어야 한다.

rx와 ry:

000...000s[0]

000...001s[1]

등..

011...111s[NSR-1] (= SP)

100...000L[0] (= SP)

100...001L[1]

등..

111...111L[NLR-1] (= PC)

cdn:

000 Sif_set("always")

0001 Sbarif_not_set("never")

0010 Cif_carry

0011 Zbarif_not_zero

0100 Cbarif_not_carry

0101 Zif_zero

0110 Nif_negative

0111 Vif_overflow

1000 Nbarif_not_negative

1001 Vbarif_not_overflow

1010 Lif_less (< 0)

1011 Lbarif_ge (≥ 0)

1100 1if_le (≤ 0)

1101 Mif_ls (lower/same)

1110 Ibarif_gt (> 0)

1111 Mbarif_hi (higher)

control_instr:

00...000BR

00...001JS

00...010JI

00...011RI

00...100VS4

00...101VS5

등..

11...111VS 2^n-1(n == control_instr에 대한 비트 필드의 폭)

만일 애플리케이션에 따른 명령어가 구현된다면, 이들은 가장 높은 숫자가 매겨진 VS 코드의 코드를 취한다.

ma_instr:

00...000000LL0

00...000001LL1

00...000010LL2

등...

11...011111LL2^n-1- 32 ( n == ma_instr에 대한 비트 필드의 폭)

11...100000TB0

11...100001TB1

11...100010TB2

11...100011TB3

11...100100FB0

11...100101FB1

11...100110FB2

11...100111FB3

11...101000SB0

11...101001SB1

11...101010SB2

11...101011SB3

11...101100CB0

11...101101CB1

11...101110CB2

11...101111CB3

11...110000SL1

11...110001SR1

11...111010RL1

11...110011RR1

11...110100SL2

11...110101SR2

11...110110RL2

11...110111RR2

11...111000SL4

11...111001SR4

11...110010RL4

11...111011RR4

11...111100SA1

11...111101SA2

11...111110RCL

11...111111RCR

Claims

바이트 컴파일된 자바 코드를 하드웨어에서 실행하기 위한 마이크로 프로세서에 있어서,

RISC 프로세서와,

상기 RISC 프로세서에서 첫 번째 자바 명령어들의 집합을 실행하는 자바 모듈과,

인터럽트를 처리하는 수단, 및 고도로 전문화된 주변 장치를 제어하는 유연성 있는(flexible) 하드웨어 인터페이스를 포함하고, 상기 RISC 프로세서에서 마이크로 코드로서 두 번째 자바 명령어들의 집합을 실행하는 RISC 모듈과,

다수의 원소를 가진 레지스터 파일을 포함하는 상기 RISC 프로세서 내의 데이터 경로를 포함하고,

상기 데이터 경로, 상기 다수의 원소, 및 상기 레지스터 파일은 상기 자바 모듈과 RISC 모듈에 의해 공유되고,

상기 자바 모듈은 상기 다수의 원소의 첫 번째 부분을 순환 자바 피연산자 스택(circular Java operand stack)으로 보고, 상기 다수의 원소의 나머지 부분을 저장 매체 레지스터들(storage registers)로 보며,

상기 RISC 모듈은 상기 다수의 원소를 레지스터 파일로 보는 것인 마이크로 프로세서.
제1항에 있어서, 상기 레지스터 파일은 어느 모듈이 동작 중인지 추적하는 제어 비트를 포함하는 것인 마이크로 프로세서.
제1항에 있어서, 상기 레지스터 파일은 실행될 명령어의 어드레스를 담고 있는 프로그램 카운터를 포함하는 것인 마이크로 프로세서.
제1항에 있어서, 상기 레지스터 파일은 호출될 새로운 메서드(method)의 어드레스를 저장하는 프로그램 카운터 베이스 레지스터를 포함하는 것인 마이크로 프로세서.
제1항에 있어서, 상기 레지스터 파일은 자바 메서드에서 로컬 변수들에 대한 베이스 어드레스 정보를 저장하는 로컬 변수 베이스 어드레스를 포함하는 것인 마이크로 프로세서.
제1항에 있어서, 상기 레지스터 파일은 상기 자바 피연산자 스택의 정상의 위치를 추적하는 자바 스택 포인터를 포함하는 것인 마이크로 프로세서.
제1항에 있어서, 상기 레지스터 파일이 꽉 차는 경우, 상기 RISC 프로세서가 변수들을 임시적으로 저장할 수 있는 위치를 가리키는 RISC 스택 포인터를 상기 레지스터 파일이 포함하는 것인 마이크로 프로세서.
제1항에 있어서, 상기 레지스터 파일은 한 쌍의 상태 비트를 가진 상태 레지스터를 포함하고, 상기 한 쌍의 상태 비트는 상기 RISC 모듈에게 자바 명령어를 실행할 때 상기 자바 피연산자 스택의 정상에 있는 값을 레지스터 피연산자로서 사용하라고 알리며, 각 상태 비트가 소스 또는 목적지(destination) 피연산자를 제어하는 것인 마이크로 프로세서.
제8항에 있어서, 상기 상태 비트들이 설정될 때, 상기 RISC 모듈은 상기 소스 또는 목적지 피연산자를 무시하고, 미리 정해진 레지스터의 내용을 소스 또는 목적지 피연산자로서 사용하는 것인 마이크로 프로세서.
제8항에 있어서, 상기 상태 비트들은 상기 자바 명령어를 대체하는 RISC 프로그램에 의해 설정되고 클리어(clear)되는 것인 마이크로 프로세서.
제1항에 있어서, 상기 RISC 프로세서는 SMILE RISC 아키텍쳐를 가지는 것인 마이크로 프로세서.
제1항에 있어서, 상기 레지스터 파일의 외부에 위치한 상태 레지스터에 제어 비트가 저장되는 것인 마이크로 프로세서.
자바 코드를 RISC 프로세서에서 실행하는 방법에 있어서,

자바 모듈로 상기 RISC 프로세서에서 첫 번째 자바 명령어들의 집합을 실행하는 단계와,

RISC 모듈로 상기 RISC 프로세서에서 상기 첫 번째 자바 명령어들의 집합보다 복잡한 두 번째 자바 명령어들의 집합을 실행하는 단계와,

상기 자바 모듈에 의해 실행하기에는 너무 복잡한 명령어가 나타날 때 상기 RISC 프로세서를 인터럽트하는 단계와,

상기 RISC 모듈에서 다른 명령어들과 별개로 상기 복잡한 명령어를 실행하는 단계와,

상기 RISC 모듈이 상기 복잡한 명령어를 실행하는 것을 마쳤을 때 상기 자바 모듈로 돌아오는 단계를 포함하는 자바 코드 실행 방법.
제13항에 있어서, 상기 RISC 프로세서를 인터럽트하는 단계는,

구현에 따른(implementation specific) 조건들의 집합이 상기 RISC 프로세서가 인터럽트되는 것을 요구하는 것을 확인하는 단계와,

상기 RISC 모듈에서 스택의 정상 위에 복귀(return) 어드레스를 저장하는 단계와,

미리 정해진 어드레스로 점프하여, 새로운 분기 어드레스를 판독하는 단계와,

상기 RISC 모듈에서 상기 새로운 분기 어드레스로 가는 분기 명령어를 실행하는 단계와,

상기 자바 모듈을 사용하는 프로그램 실행으로 돌아가는 복귀 명령어를 실행하는 단계를 포함하는 자바 코드 실행 방법.