KR20050013257A - 쌍방향 텔레비전용 데이터 처리 디바이스 및 방법 - Google Patents

Abstract

본 발명은, 디지털 TV 셋톱박스용 프로그램 가능한 데이터 처리 디바이스로서: - DSM-CC 캐로셀(DC)로부터 제 1 유형의 코드 및/또는 데이터의 일부분을 수신하기 위한 로딩 엔진(LE)과, - 상기 로딩 엔진에 의해 수신된 일부분을 저장하기 위한 저장 수단(C)과, - 상기 수신된 부분에 의해 구현된 애플리케이션을 수행하기 위한 수행 엔진(EE)과, - 제 1 유형의 코드를 상기 수행 엔진(EE)의 원시 코드로 번역하기 위한 번역 엔진(TE)을 포함하는 프로그램 가능한 데이터 처리 디바이스에 관한 것이다. 상기 번역 엔진(TE)은 상기 수신된 일부분중 적어도 특정한 일부분을 원시 코드로 컴파일하고, 그에 따라 컴파일된 부분을 저장 수단(C)에 저장하고, 코드의 다른 부분을 해석하도록 적응되며, 상기 수행 엔진(EE)은 동일한 애플리케이션 내에서 컴파일된 코드와 해석된 코드를 처리하도록 적응된다.

Description

쌍방향 텔레비전용 데이터 처리 디바이스 및 방법{A DATA PROCESSING DEVICE AND METHOD FOR INTERACTIVE TELEVISION}

이러한 유형의 전형적인 네트워크는 쌍방향 TV 네트워크이다. 이러한 네트워크에서, 단말국은 소위 셋톱박스를 장착한 TV 세트로 형성되며, 중앙국은 방송국이다. 다운링크시, 오디오/비디오 데이터(AV 데이터)와 애플리케이션 데이터는 높은 속도로 개별 TV 세트로 송신되며; 이때 업링크 데이터 속도는 훨씬 더 느리며, 방송국으로의 피드백을 필요치 않는 애플리케이션에 대해서는 0일 수 있다.

비록 이러한 네트워크의 토폴로지가 공통 서버에 연결된 복수의 워크스테이션을 구비한 공통 컴퓨터 네트워크와 유사하더라도, 이들 네트워크의 속성은 다수의 새로운 문제를 야기한다. 하나의 문제로 쌍방향 TV 네트워크에서 단말국의 수가 극히 커져서 백 만개 이상의 단말일 수 있다는 점이다. 로컬 컴퓨터 네트워크에서,각 단말은 임의의 주어진 시간에 각 단말에 다운로드될 특정한 애플리케이션을 자유롭게 요청할 수 있는데 반해, 쌍방향 TV 네트워크에서 이 같은 기능을 허용하기 위해서는 과도하게(prohibitively) 높은 데이터 송신 성능을 필요로 하게 된다. 쌍방향 텔레비전 기술분야에서, 이 문제점은 소위 DSM-CC(Digital Storage Media Command and Control) 캐로셀(carousel)을 사용하여 해결된다. DSM-CC 캐로셀은 AV 데이터와 함께 방송국에 의해 송신된 데이터스트림이며, 여기서 모듈 시퀀스가 송신되고, 각 모듈은 단말국에 의해 실행될 수 있는 하나 이상의 애플리케이션의 데이터 및/또는 코드를 포함한다. 이 모듈 시퀀스의 송신은 무한히 반복된다. 애플리케이션의 수가 한정되므로, 모든 모듈의 송신은 특정한 시간 구간 이후 반복된다. 하나의 애플리케이션을 실행할 수 있기 위해서, 단말국은 이 애플리케이션에 속한 모든 모듈을 수집해야 한다.

만약 단말국이 주어진 애플리케이션을 개시하기 위해 사용자로부터 명령을 수신한 이후에만 이 애플리케이션의 모듈을 수집하기 시작한다면, 명령과 이러한 개시 사이에 상당한 지연이 초래될 수 있으며, 이러한 지연은 사용자를 괴롭힌다.

이 문제점을 경감시키기 위해, DVB(Digital Video Broadcast Forum)의 MHP(Multimedia Home Platform) 표준에 따라, 방송국은, 캐로셀 상에서 송신된 각 모듈에 대해, 이 모듈이 가까운 장래에 실행되어야 할 가능성이 있기 때문에 이 모듈을 단말국에 저장할 가치가 있는지의 여부를 지시하는 소위 프리-페치 신호화(pre-fetch signalization)를 송신할 수 있다. 그에 따라, 단말국은 프리-페치 신호화에 의해 명시된 모듈을 그 내부에 저장하기 위한 저장 수단을 가질 수 있어서,그러한 모듈이 수행되어야 하는 경우에, 이러한 모듈의 재송신을 대기할 필요 없이도 즉시 수행되기 시작할 수 있다.

이것은, DSM-CC 캐로셀 상의 코드 방송이 추가의 사전 처리를 필요로 하지 않고도 단말국에 의해 수행될 수 있는 원시 코드였다면, 만족스러운 해법이 될 수 있다. 그러나, 원시 코드의 사용은 매우 높은 정도의 단말국 표준화를 필요로 한다는 단점을 가지며, 이러한 단말국에는 많은 서로 다른 제조자가 있으므로, 단말국에 자바 버추얼 머신(Java virtual machine)을 제공하고 방송국으로부터 단말국으로 애플리케이션을 자바 중간 코드로서 송신하고자 하는 업계에 이러한 표준화를 부담하는 것은 어렵다. 이러한 해법은 사실 DVB-MHP 애플리케이션이 기저에 놓인 특정한 하드웨어에 상관없이 임의의 DVB-MHP 플랫폼 상에서 실행되게 한다는 장점을 갖는다.

그러나, 이러한 해법의 대가는 상당한 프로세서 속도 및 중요한 메모리 양을 의미하는 강력한 자바 버추얼 머신이 필요하다는 점이다. 시장에서, 상대적으로 고가인 하드웨어 플랫폼에 대한 이러한 필요는 쌍방향 디지털 텔레비전에 대한 DVB-MHP 해법의 중요한 단점으로서 흔히 보여지며, DVB-MHP 해법의 빠른 확산에 대한 심각한 한계로서 간주될 수 있다.

기존의 자바 실행 환경에서, 애플리케이션 처리 속도는 흔히 실행 시간을 감소시킴으로써 이득을 얻는다. 이것은 수행될 수 있기 이전에 머신에 의해 먼저 해석되어야 하는 중간 코드가 아니라 자바 버추얼 머신의 프로세서에 의해 직접 실행될 수 있는 원시 코드로의 자바 종류의 컴파일에 의해 이득을 얻는다.

전술된 유형의 디지털 TV 네트워크에서, 이러한 컴파일이 단말국에서만 수행될 수 있다는 점은 분명하다. 만약 방송국이 미리-컴파일한 애플리케이션을 이미 송신했다면, 상호운용성은 손실될 것이다. 만약 컴파일이 단말국에서 이뤄진다면, 수행 속도는 개선될 수 있지만, 로딩 시간지연(load latency)은 증가할 것이며, 이는 사용자가 주어진 애플리케이션을 개시한다는 명령을 제공했을 때, 사용자는 이 애플리케이션의 모든 모듈이 캐로셀로부터 수신되었을 때까지 대기해야할 뿐만 아니라 추가로 이들의 컴파일에 시간이 필요하기 때문이다.

본 발명은 네트워크의 중앙국으로부터 복수의 단말국으로 애플리케이션을 송신하고, 단말국에서 애플리케이션을 실행하기 위해 특히 적응되는 데이터 처리 디바이스 및 방법에 관한 것이며, 이 단말국에서 다운링크(중앙국에서 단말국으로) 송신을 위한 네트워크 데이터 속도는 업링크(단말국에서 중앙국으로) 송신을 위한 것보다 훨씬 더 높다.

도 1은 본 발명에 따른 프로그램 가능한 데이터 처리 디바이스의 개략적인 블록도.

도 2는 도 1의 디바이스에 의해 실행된 방법의 제 1 흐름도.

도 3은 도 1의 디바이스에 의해 실행된 대안적인 방법의 제 2 흐름도.

도 4의 (a) 및 (b)는 도 3의 상세한 부분에 대한 두 가능한 실시예를 도시한도면.

도 5는 본 발명의 디바이스의 제 2 실시예의 블록도.

그러므로, 본 발명의 목적은, 애플리케이션은 공통 스트림의 일부분으로서 송신되며, 애플리케이션을 개시한다는 결정을 입력하는 것과 애플리케이션의 실제 시작 사이에서 작은 지연이 높은 처리력을 필요로 하지 않고도 달성되는, 네트워크에서 사용하기 위한 프로그램 가능한 데이터 처리 디바이스 및 데이터 처리 방법을 제공하는 것이다.

이 목적은:

- 방송 네트워크의 스트림으로부터 데이터 및/또는 제 1 유형의 코드의 일부분을 수신하기 위한 것으로, 상기 일부분은 반복해서 송신되는, 로딩 엔진과,

- 상기 로딩 엔진에 의해 수신된 상기 일부분을 저장하기 위한 저장 수단과,

- 수신된 부분에 의해 구현된 애플리케이션을 수행하기 위한 수행 엔진과,

- 제 1 유형의 코드를 상기 수행 엔진의 원시 코드로 번역하기 위한 번역 엔진을 포함하는 프로그램 가능한 데이터 처리 디바이스에 의해 달성되며, 이 디바이스는,

번역 엔진(TE)이 그에 따라 컴파일된 부분을 저장 수단(C)에 저장하고, 미리 결정된 신호화 정보가 스트림으로부터 수신될 때 상기 수신된 부분 중 적어도 특정한 하나의 부분을 원시 코드로 컴파일하고, 다른 코드 부분을 해석하도록 적응되는 것과, 상기 수행 엔진(EE)이 동일한 애플리케이션 내에서 컴파일된 코드 및 해석된 코드를 처리하도록 적응되는 것을 특징으로 한다.

본 목적은 또한:

-a) 방송 네트워크의 스트림으로부터 데이터 및/또는 제 1 유형의 코드의 일부분을 수신하는 단계로서, 상기 일부분은 반복해서 송신되며, 상기 스트림에서 송신된 일부분의 세트는 하나 이상의 데이터 처리 애플리케이션을 구현하는, 데이터 및/또는 제 1 유형의 코드의 일부분 수신 단계와,

-b) 상기 일부분 중 미리 결정된 부분을 저장 수단에 저장하는 단계와,

-c) 미리 결정된 신호 정보가 스트림으로부터 수신될 때, 제 1 유형의 코드를 포함하는 상기 일부분 중 적어도 하나를 번역 엔진에서 수행 엔진의 원시 코드로 컴파일하는 단계와;

-d) 수행 엔진에서, 상기 데이터 처리 애플리케이션 중 하나를, 이 하나의 애플리케이션에 속해 있는 선택된 부분의 컴파일된 원시 코드를 수행함으로써, 및 이 애플리케이션의 비-선택된 부분을 해석함으로써, 실행하는 단계를 포함하는 데이터 처리 방법에 의해 달성된다.

이 디바이스 및 방법에서, 주어진 애플리케이션의 코드의 일부분들을 데이터처리 디바이스로 송신할 때의 지연은, 번역 엔진이 데이터 처리 디바이스에서 이미 수신된 코드의 이일부분을 컴파일하게 함으로써, 사용될 수 있다. 애플리케이션의 전체 코드가 수신되자마자, 애플리케이션의 수행이 시작될 수 있고; 그러나, 이때 아직 컴파일되지 않은 코드 부분은 해석에 의해 실행될 수 있다.

바람직하게는, 애플리케이션의 수행은 이러한 효과를 위한 명령이 사용자에 의해 입력될 때만 시작할 것이다. 이것이 일어나기 이전에, 디바이스는 이 애플리케이션의 코드 부분을 이미 최대한으로 수집하고 컴파일했어야 한다.

이미, 수행이 시작될 때, 코드의 일부분이 컴파일된다는 사실은 모든 코드가 해석되는 기존의 디바이스의 수행 속도에 비해 수행 속도를 증가시킨다. 수행 엔진과 번역 엔진이 처리력을 공유하는 데이터 처리 디바이스에서, 이렇게 속도가 증가하는 주요한 이유는, 해석할 때, 처리력이 중간 코드의 일부분을 이 부분이 수행될 때마다 수행 엔진의 원시 코드로 번역하는데 소비되는 반면, 컴파일할 때 이 코드는 한번만 번역되어, 해석이 애플리케이션의 수행에 더 잘 사용될 수 있는 처리력을 항상 흡수한다. 그러나, 심지어 수행 엔진 및 번역 엔진이 처리력을 다투지 않는 시스템에서도, 속도 증가는 가능하며, 이는 컴파일된 코드가 해석된 코드보다 좀더 효율적으로 만들어질 수 있기 때문이다.

만약 디바이스의 수행 엔진과 번역 엔진이 물리적으로 별도인 유닛이라면, 추가적인 개선은 번역 유닛이 애플리케이션을 수행할 때 코드의 추가적인 부분들을 컴파일하게 함으로써 달성될 수 있다. 이것은, 수행 엔진이 컴파일된 코드를 실행할 때 번역 엔진이 컴파일에 이용 가능한 여유 시간을 가지기 때문에 특히 강력한번역 엔진을 제공해야 할 필요 없이도 가능하다. 이렇게 하여, 해석된 코드에 대한 컴파일의 속도는 최종적으로 애플리케이션의 모든 코드가 컴파일될 때까지 수행하는 동안에 계속해서 증가할 것이다.

만약 번역 엔진 및 수행 엔진이 공통 프로세서에서 시간 공유 방식으로 구현된 버추얼 디바이스라면, 컴파일은 또한 전술된 바와 같이 수행 시에 계속될 수 있거나, 대안적으로, 컴파일된 코드가 수행되고 있을 때, 공통 프로세서의 모든 처리력이 수행 엔진에 할당될 수 있다.

가장 유리하게도, 번역 엔진은 번역 엔진이 수신한 신호 정보에 따라서 번역 엔진이 컴파일한 코드 부분을 선택하도록 적응된다.

상기 신호 정보의 한 소스는 코드의 일부분이 송신되는 스트림일 수 있다. 만약 스트림이 DSM-CC 캐로셀이라면, 이러한 캐로셀에 종래에 송신된 프리-페치 신호는 상기 신호 정보로서 사용될 수 있다. 즉, 종래에, DVB-MHP 플랫폼이 프리-페치 신호에 의해 명시된 DSM-CC 모듈을 이것이 송신되었을 형태로 단지 저장할 것이고, 결국 차후에 이것을 해석할 것인 반면에, 본 발명의 데이터 처리 디바이스는 이러한 모듈을 추가로 컴파일할 수 있다.

물론, 컴파일될 부분은 DSM-CC 모듈의 작은 부분(fraction)들 일 수 있다. 이 경우, 컴파일될 이들 작은 부분을 명시하기 위해, DSM-CC 프리-페치 신호 외의 또 다른 유형의 신호 정보가 캐로셀 상에서 송신되어야 한다. 이러한 신호 정보는 예컨대 코드의 하나 또는 또 다른 부분을 수행하게 할 상대적인 빈도수나, 컴파일된 코드의 해석된 코드에 대비한 효율의 예상 증가치(이것은 코드의 여러 부분들에대해 서로 다를 수 있음)와 같은 것을 기초로 해서 애플리케이션을 개발하는 사람에 의해 한정될 수 있다.

대안으로서, 또는 추가로, 처음에, 프리-페치 정보는 캐로셀 상에서 송신된 각 모듈에 대해서 제 1 유형 형태로 이것이 단말국에 저장되어야 하는지를 지시한다. 그러면, 번역 엔진은 수행 엔진으로부터 컴파일될 코드의 부분을 지시하는 미리 결정된 신호 정보를 수신한다. 이것은 애플리케이션이 실행중일 때 특히 유용하다. 방송국은 적절한 시기에 예컨대 애플리케이션을 수행하기 바로 전에 번역을 개시할 수 있다. 이러한 애플리케이션은 복수의 모듈이나 부분들로 구성될 수 있고, 이들 중 일부는 수백 번 수행될 수 있으며, 다른 부분들은 전혀 수행되지 않을 수 있다. 방송국은 어떠한 모듈 또는 부분이 곧 수행될 것인지를 인식하여, 그 수행을 예상할 수 있다. 보통, 애플리케이션이 개발될 때, 코드 중 어떤 부분이 빈번하게 수행될 것인지, 어떤 부분이 그렇지 않을 것인지, 또는 어떤 부분이 곧 수행될 것인지를 추정할 수 있다. 코드의 빈번하게 수행될 부분에 대한 컴파일 명령은 예컨대 개시 부분에서와 같은 애플리케이션 코드의 다른 부분에 포함될 수 있어서, 이 개시 부분이 실행될 때, 이들 컴파일 명령에 따른 신호 정보는 수행 엔진으로부터 번역 엔진으로 전달될 수 있다.

번역 엔진은 수행 엔진으로부터 수신한 신호 정보에 따라서 제 1 유형 코드의 주어진 부분을 컴파일할 것인지 해석할 것인지의 여부를 결정하도록 더 적응되어야 한다. 즉, 번역 엔진은 또한 수행 엔진이 코드의 특정 어드레스로의 점프 또는 분기 명령을 실행해야 할 때 이 특정 어드레스를 명시한 신호 정보를 수신해야할 것이다. 만약 대응하는 코드 부분이 이 명령이 실행되어야 할 시기에 아직 컴파일되지 않았다면, 번역 엔진은 처리 지연을 피하기 위해 점프 또는 분기 명령에서 지정된 코드를 해석해야 할 것이다.

만약 점프 또는 분기 명령의 타깃 어드레스를 포함한 코드 부분이 이 명령이 실행될 때 컴파일 중이라면, 번역 엔진이 해석을 필요로 하는 수행 엔진으로부터의 신호 정보를 무시하고, 코드 일부분의 컴파일을 종료할 하나의 진행 가능성이 있을 수 있다. 수행 엔진이 점프나 분기 명령을 실행할 수 있기 전 얼마동안 대기해야하는 경우에, 이러한 지연은 후에 처리 속도를 증가시킴으로써 보상될 수 있다.

그러한 경우에, 수행 엔진이 대기하는 것을 막기 위해, 번역 엔진은 이러한 코드 부분의 컴파일을 포기하고 이것을 해석하기 시작할 대안적인 가능성이 있게 된다. 번역 엔진이 일부분의 컴파일을 종료하는데 필요한 처리 시간의 추정을 기초로 해서 이들 두 개의 대안 사이에서 선택하는 것이 또한 제안될 수 있다.

본 발명의 추가적인 특성 및 장점은 첨부된 도면과 연계하여 주어지는 바람직한 실시예에 대한 후속한 설명을 통해 분명해질 것이다.

도 1에서 점선 박스에 의해 경계가 정해진 데이터 처리 디바이스는 로딩 엔진(LE)과, 컴파일 엔진(CE)과 해석 엔진(IE)으로 구성된 번역 엔진(TE)과, 캐시(C)와, 수행 엔진(EE)을 포함한다. 이 디바이스는 디지털 텔레비전용 셋톱박스의 일부분이다.

로딩 엔진(LE)은 DSM-CC 캐로셀(DC)로부터 코드 및 데이터 모듈을 수신하도록 적응된다. 이 캐로셀에서, 패이로드 모듈 세트는 순환적으로 송신된다. 두 유형의 패이로드 모듈, 즉 글자(D)가 있는 종이로 표시된 데이터 모듈과, 글자(I)가 잇는 종이로 표시된 코드 모듈이 있다. 코드 및 데이터 모듈은 그에 따라 I 및 D 모듈 각각으로서 또한 지칭될 것이다. 코드 모듈(I)에서의 코드는 수행 엔진(EE)에 의해 수행될 수 있는 하나 이상의 애플리케이션에 속할 수 있다. 코드 모듈(I)에 포함된 코드는 중간 코드, 즉 애플리케이션이 원래 기록되었던 높은 수준의 언어인 코드보다 더 간소할 수 있지만, 사전 번역 없이는 수행 엔진에 의해 수행될 수 없는 코드이다. 바람직하게, 중간 코드를 유도케 하는 높은 수준의 언어는 자바 프로그래밍 언어이다. 중간 코드의 사용은 서로 다른 제조사가 제조한 광범위한 셋톱박스에서 코드 운용성을 보장하기 위해 필요하다.

로딩 엔진(LE)과 캐시(C) 사이에는 연결(1)이 있으며, 이 연결(1)은 로딩 엔진(LE)이 캐로셀(DC)로부터 수신된 I 및 D 모듈을 캐시(C)에 저장한다. 로딩 엔진(LE)과 컴파일 엔진(CE) 사이에 또 다른 연결(2)이 있으며, 이 연결(2)은 로딩 엔진(LE)이 I 모듈을 컴파일하기 위해 컴파일 엔진(CE)에 전송하게 한다. 컴파일 엔진(CE)은 이들을 문자(N)를 가진 종이로 표시된 원시 코드 모듈로 컴파일하며, 이러한 원시 코드 모듈은 도 1에 도시된 바와 같이 연결(3)을 통해 캐시(C)로 전송될 수 있거나 또는 연결(4)을 통해 즉각 수행하기 위해 수행 엔진(EE)으로 직접 전송될 수 있다. 캐시는 그에 다라 세 개의 모듈 유형, 즉 I, D 및 N 모듈을 담을 수 있다.

수행 유닛(EE)이 애플리케이션을 실행할 때, 유닛은 로딩 엔진(LE)에게 필요한 코드 모듈을 연결(5)을 통해 통보한다. 그러면, 로딩 엔진(LE)은 캐시(C)로부터 그에 대응하는 모듈을 페치하여, 만약 모듈이 컴파일된다면 이것을 연결(6)을 통해 서 수행 엔진(EE)에 전송할 것이며, 만약 이 모듈이 중간 코드 상태라면 연결(7)을 통해 해석 엔진(IE)에 전송할 것이다.

분명히, 디바이스의 여러 엔진 각자는 다른 엔진들로부터 구별되는 회로일 수 있거나, 또는 이들 엔진 중 하나 이상은 서로 다른 시간에 전술된 바와 같은 여러 엔진의 서로 다른 임무를 실행하는 마이크로프로세서에 의해 구현될 수 있다.

디바이스의 여러 엔진에 의해 수행된 방법이 이제 도 2 및 도 3을 상세하게 참조하여 기술될 것이다.

본 설명에서, 본 발명의 디바이스는 운영자의 선택에 따라 DSM-CC 캐로셀에 의해 연속해서 송신된 여러 애플리케이션을 수행할 수 있는 디지털 텔레비전용의 셋톱박스라고 가정된다.

도 2는 스위치를 켠 후 운영자가 수행될 애플리케이션을 선택하기 전에, 즉시 셋톱박스의 로딩 엔진(LE)과 컴파일 엔진(CE)에 의해 수행되는 방법 a 및 방법 b로 지칭되는 두 방법을 도시하고 있다. 방법 a 및 b는 동시에 수행된다. 방법 a의 단계(a1)에서, 로딩 엔진(LE)은 DSM-CC 캐로셀(DC)로부터 모듈을 수신한다. 이 모듈은 I 모듈이나 D 모듈일 수 있다. 단계(a2)에서, 로딩 엔진(LE)은 이 모듈이 프리-페치 신호화를 수반하는지를 판단한다. 원칙적으로, 모듈이 프리-페치되도록 신호화되는지에 대한 질문은 캐로셀(DC)의 운영자에게 달려있다. 일반적으로, 만약 이 모듈이 캐로셀(DC) 상에서 송신된 애플리케이션 중 임의의 애플리케이션을 수행하기 시작하는데 필요한 코드나 데이터를 담고 있다면, 모듈은 적어도 프리-페치되도록 신호화될 것이며, 이는 이렇게 하면, 운영자가 애플리케이션을 선택하자마자 지연되지 않고 셋톱박스가 수행을 시작하게 될 것이기 때문이다.

만약 모듈이 프리-페치되도록 신호화되지 않는다면, 로딩 엔진은 이것을 무시하고, 도착할 그 다음 모듈을 대기할 것이다.

만약 모듈이 프리-페치되도록 신호화된다면, 로딩 엔진(LE)은 단계(a3)에서 이것이 캐시(C)에 이미 존재하는지를 검사할 것이다. 만약 그렇다면, 방법은 단계(a1)로 돌아가 그 다음 모듈을 대기할 것이다. 대안적으로, 캐로셀(DC) 상의 후속하는 송신 사이에 모듈이 업데이트될 가능성이 있다면, 캐시(C)에 존재하는 모듈의 기존 버전이 새 버전으로 겹쳐기록될 것이다.

만약 모듈이 캐시(C)에 존재하지 않는다면, 로딩 엔진(LE)은 단계(a4)에서 이 모듈을 저장하기 위해 캐시(C)에 이용 가능한 공간이 있는지를 점검한다. 만약이용 가능한 공간이 없다면, 로딩 엔진(LE)은 단계(a5)에서 겹쳐기록될 캐시에서 저장된 모듈을 선택한다. 선택 기준은 모듈이 캐시(C)에서 얼마나 오랫동안 사용되지 않고 저장되어왔는가하는 점일 수 있다. 대안적으로, 프리-페치 신호화는 여러 우선순위 레벨을 명시할 수 있고, 겹쳐기록하기 위해 선택된 모듈은 현재 수신된 모듈보다 더 낮은 프리-페치 우선순위 레벨을 가질 수 있다. 만약 현재 수신된 것보다 더 낮은 프리-페치 우선순위 레벨을 갖는 모듈이 없다면, 현재 수신된 모듈은 버려져야만 한다. 캐시에서 이용 가능한 공간이 있거나, 캐시가 겹쳐기록하기 위한 모듈을 선택함으로서 이용 가능하게 된다면, 본 수신된 모듈은 단계(a6)에서 캐시에 저장되고, 로딩 엔진(LE)은 캐로셀(DC)로부터 또 다른 모듈을 수신하는 것을 준비한다.

동시에, 컴파일 엔진(CE)은 컴파일되지 않은 모듈을 선택하는 단계(b1)를 순환적으로 반복한다. 이것을 컴파일하는 단계인 b2와 컴파일된 모듈을 캐시(C)에 저장하는 단계인 b3이 다음에 온다. 모듈이 컴파일되자마자, 원래의 중간 코드 모듈을 담고 있는 캐시(C)의 저장 공간은 해제되어, 임의의 새롭게 수신된 모듈이 여기에 저장될 수 있다.

방법 a 및 b는 완벽하게 비동기화될 수 있다, 즉 컴파일 엔진(CE)이 한 모듈에 대해 단계(b3)를 마쳤을 때마다, 엔진은 즉시 단계(b1)로 복귀하여, 컴파일될 또 다른 모듈을 캐시(C)에서 검색할 수 있다. 캐시에 컴파일되지 않은 모듈이 하나보다 많고, 이들에 대해 정의된 프리-페치 우선순위 레벨이 있을 때, 컴파일 엔진(CE)은 항상 가장 높은 우선순위를 갖는 모듈을 선택할 것이다.

로딩 엔진(LE)과 컴파일 엔진(CE)이 단일 마이크로프로세서나 다른 적절한 전자회로 내에 구현되고, 그 처리력을 공유할 때, 방법 a 및 b 중 어느 하나도 마이크로프로세서가 완전히 점유된 상태를 유지하지 않아야 한다. 이 경우, 마이크로프로세서는 예컨대 모듈이 수신될 때마다 인터럽트에 의해 트리거되고, 이 모듈을 저장할 것인지의 여부가 결정되어야 하는 로딩 엔진(LE)으로 동작하거나, 로딩 엔진이 휴지 상태일 때마다, 즉 방법 a가 포어그라운드(foreground) 즉 높은 우선순위 임무로서 수행되고, 방법 b가 필요할 때마다 방법 a를 위해 인터럽트될 수 있는 낮은 우선순위 즉 백그라운드(background) 임무로서 수행되는 컴파일 엔진(CE)으로 동작하는 것이 바람직할 수 있다.

대안적인 실시예에서, 방법 a 및 b는 또한 동기화될 수 있다. 즉 방법 b는 단계(a6)가 수행되었을 때 트리거되고, 단계(a6)에 저장된 모듈을 선택하게 된다.

방법 a, b가 동기화되면, 추가적인 대안에 따라, 단계(a6)는 없어도 되며, 캐시(C)에 수신된 모듈을 저장하는 대신, 이 모듈은 직접 로딩 엔진(LE)으로부터 컴파일 엔진(CE)으로 공급되어, 단지 컴파일한 이후 캐시(C)에 기록된다.

만약 로딩 엔진(LE)과 컴파일 엔진(CE)이 공통 처리 회로의 처리력을 공유하고, 모듈의 컴파일이 추가의 모듈이 프리-페치 신호화를 수반하여 수신될 때 종료되지 않을 수 있는 위험이 있다면, 방법 a 및 b를 동기화하지 않는 것이 바람직할 수 있다. 그러나, 이러한 위험은 프리-페치될 모듈이 프리-페치 신호화가 없는 모듈 사이에 규칙적으로 산재해있도록 모듈이 캐로셀(DC) 상에서 송신되는 시퀀스를 선택함으로써 감소될 수 있다.

일반적으로, 프리-페치되도록 신호화된 DSM-CD 캐로셀(DC)에서의 모듈은 여러 애플리케이션 중 임의의 애플리케이션을 시작하는데 필요한 코드와 데이터를 포함하는 모듈일 것이다. 그에 따라, 만약 캐시의 용량이 충분히 크다면, 캐로셀(DC) 상에서 송신된 모든 애플리케이션에 대한 시작 코드 부분이 컴파일된 형태로 캐시에 존재할 것이며, 그에 따라, 운영자가 셋톱박스에서 특정한 애플리케이션을 선택할 때, 이 애플리케이션의 수행은 지연 없이 시작할 수 있다. 만약 캐시의 저장 용량이 충분히 크다면, 여러 애플리케이션의 다른 중요한 모듈도 또한 캐시에 저장될 수 있어서, 결국 컴파일될 수 있을 것이다. 코드부는, 만약 이것이 빈번하게 수행되고 및/또는 애플리케이션의 시작부분에 후속하여 수행될 높은 가능성이 있다면, 이러한 환경에서 중요하다고 여겨지게 된다.

방송국의 DSM-CC 캐로셀이 서로 다른 캐시 저장 용량을 갖는 여러 셋톱박스에 서비스할 수 있으므로, 프리-페치 신호화는 바람직하게는 로딩 엔진(LE)이 캐시에 저장하기 위한 가장 중요한 코드 부분만을 선택할 수 있게 함을 지시하는 우선순위 레벨을 포함해야 한다.

운영자가 셋톱박스 상에서 수행될 애플리케이션을 선택하고, 이 선택을 입력할 때, 애플리케이션에 필요한 모든 코드가 이미 캐시에 존재할 가능성이 있으며, 이러한 코드는 컴파일되거나 컴파일되지 않은 형태로 존재할 것이다. 만약 컴파일된 형태로 존재한다면, 방법 a는 정지되고, 수행 엔진(EE)은 도 3의 실행 방법 c를 시작할 것이다.

그러나, 대부분의 경우에, 애플리케이션의 모든 코드가 캐시에 존재하지는않을 것이며, 그에 따라, 방법 a는 도 3의 변경된 방법 a'에 의해 대체되고, 이렇게 대체하는 목적은 캐로셀(DC)로부터 손실된 코드부분을 모드는 것이다.

방법 a'에서, 로딩 엔진(LE)은 단계(a1')에서 캐로셀(DC)로부터 모듈을 수신한다. 만약 단계(a2')에서 동일한 모듈이 컴파일되거나 컴파일되지 않은 형태로 캐시에 이미 존재한다고 밝혀지면, 방법은 단계(a1')로 복귀하여 그 다음 모듈을 대기한다. 만약 모듈이 캐시에 없다면, 단계(a3')는 수신된 모듈이 수행될 것으로 선택된 애플리케이션의 일부분인지를 점검한다. 만약 그렇다면, 방법은 후술될 바와 같이 단계(a6')로 분기한다. 만약 그 대답이 아니오라면, 로딩 엔진(LE)은 단계(a4')에서 이 모듈이 수행 엔진이 원했던 것임을 지시하는 임의의 제어 정보를 수행 엔진(EE)으로부터 수신했는지를 점검한다. 만약 현재의 애플리케이션이 제 2 애플리케이션을 호출할 가능성이 있다면, 수행 엔진은 현재 수행된 애플리케이션에서 호출하라는 명령을 기초로 해서 현재 수행되지 않은 제 2 애플리케이션의 특정 모듈에 관한 이러한 제어 정보를 전송할 수 있다.

만약 단계(a4')에서의 대답이 예라면, 방법은 단계(a6')로 분기하며, 만약 그렇지 않다면, 단계(a5')는 모듈이 프리-페치되도록 신호화되는지를 점검한다. 만약 그렇다면, 방법은 또한 a6'로 스위칭하며, 만약 그렇지 않다면, 방법은 a1'으로 복귀하여 또 다른 모듈을 대기할 것이다.

단계(a6')에서, 모듈에는 우선순위 레벨이 할당된다. 만약 이것이 프리-페치 신호화된 모듈이고, 프리-페치 신호화가 우선순위 레벨을 명시한다면, 이 레벨이 할당될 수 있다. 만약 모듈이 현재의 애플리케이션에 속한다거나, 이것이 수행 엔진(EE)이 원하는 것이라면, 이 모듈에는 임의의 프리-페치 신호화 우선순위 레벨보다 더 높은 우선순위 레벨이 할당된다.

그러면, 단계(a7')는 이용 가능한 캐시 공간이 있는지를 점검한다. 만약 없다면, 캐시(C) 내의 모듈이 단계(a8')에서 겹쳐기록하기 위해 선택되어야 한다. 이러한 선택은 단계(a6')에서 현재의 모듈에 할당된 우선순위 레벨 및 캐시(C)에 이미 있는 모듈의 우선순위 레벨을 고려한다. 현재의 애플리케이션에 속해 있거나 수행 엔진이 원하는 모듈이 항상 임의의 다른 애플리케이션에 속할 수 있는 프리-페치 신호화된 모듈보다 더 높은 우선순위 레벨을 가지므로, 이들 다른 애플리케이션의 모듈은 항상 현재의 애플리케이션의 모듈이나 원하는 모듈을 저장할 수 있기 위해서 겹쳐기록될 수 있다. 만약 현재의 모듈의 우선순위가 낮아서, 겹쳐기록될 수 있는 다른 모듈이 캐시에 없다면, 이 모듈은 버려질 것이다. 만약 캐시(C)에 이용 가능한 빈 공간이 있거나, 겹쳐기록될 모듈이 캐시(C)에 있다면, 현재의 모듈은 단계(a9')에서 캐시(C)에서 저장될 것이다.

만약 캐시 용량이 충분하다면, 애플리케이션의 모든 모듈은 캐로셀(DC)의 한 주기 이후 캐시(C) 내에 있게될 것이다.

로딩 엔진(LE)이 방법 a'을 실행하고 있는 동안에, 컴파일 엔진(CE)은 도 2의 방법 b를 계속 진행할 수 있어서, 특정한 시간 이후, 선택된 애플리케이션의 전체 코드가 컴파일된 형태로 이용 가능하게 될 것이다.

컴파일 엔진(CE) 및 수행 엔진(EE)이 공통 처리 회로의 처리력을 공유하고, 처리력이 짧은 실시예에서, 방법 b는 애플리케이션의 수행이 시작할 때 또한 정지될 수 있다.

도 3의 방법 c는 수행 유닛(EE)에 의한 선택된 애플리케이션의 수행에 관한 것이다.

제 1 단계(c1)에서, 수행 유닛(EE)은 애플리케이션의 시작 모듈을 수행할 것이다. 이 시작 모듈은 컴파일된 형태로 캐시(C)에 존재하는 것으로 가정된다. 결국, 수행 유닛(EE)이 단계(c2)에서 애플리케이션의 코드의 또 다른 모듈로 점프하는 것이 필요하게 될 수 있다. 이 때문에, 수행 유닛(EE)은 제어 정보를 필요한 모듈을 식별한 로딩 엔진(LE)에 전송한다.

단계(c3)에서, 로딩 엔진(LE)은 이 필요한 모듈이 캐시(C)에 존재하는지를 결정한다. 만약 존재하지 않는다면, 모듈이 캐로셀(DC)로부터 수신될 때가지 대기하는 것이 필요하다{단계(c4)}. 만약 모듈이 캐시에 존재한다면, 로딩 엔진(LE)이 모듈이 컴파일되었는지의 여부를 더 결정한다{단계(c5)}. 만약 모듈이 컴파일되었다면, 단계(c6)에서 컴파일된 코드는 직접 캐시(C)에서 수행 유닛(EE)으로 전송되며; 그렇지 않다면, 이 모듈은 해석하기 위해 해석 엔진(IE)에 전송되며, 단계(c7)에서, 해석 엔진은 해석된 명령을 수행 엔진(EE)에 공급한다. 컴파일된 코드나 해석의 수행은, 이 방법이 또 다른 모듈로 점프하기 위해 단계(c2)로 복귀하거나 애플리케이션이 종료할 때까지 계속된다.

방법 c의 개선된 실시예에 따라, 방법 c의 흐름도에 도시된 점선 박스(c')는 도 4의 (a) 또는 (b)에 도시된 추가적인 방법 단계들을 포함할 수 있다. 즉, 만약 방법 b가 방법 c와 동시에 계속된다면, 수행 엔진(EE)이 단계(c2)에서 점프를 시도하게될 모듈이 컴파일 엔진(CE)에 의해 컴파일되고 있는 중인{단계(c10)} 상황이 발생할 수 있다. 이러한 상황에서, 충돌을 피할 두 가지 가능성이 있다. 도 4의 (a)에 도시된 바와 같이, 수행 엔진(EE)은, 컴파일 엔진(CE)이 코드를 컴파일하는 것을 종료할 때까지 대기해야 할 것이고{단계(c11)}, 그런 다음 전술된 단계(c6)로 분기한다. 대안적으로, 도 4의 (b)에 도시된 바와 같이, 만약 충돌이 단계(c10)에서 인식된다면, 컴파일은 단계(c11')에서 중지될 수 있고, 모듈은 단계(c7)에서 해석된다.

이제까지 기술된 실시예에서, 로딩 엔진(LE)이 DSM-CC 캐로셀(DC)로부터 모듈을 수신할 때, 수신된 코드 모듈을 컴파일하는 것이 적절한지의 여부를 결정하기 위해 프리-페치 신호화와 같은 캐로셀의 신호화 정보를 사용할 것이라는 점이 가정되어왔다. 물론, 이것은 본 발명을 실행하는 간단하고 편리한 방식이며, 이러한 본 발명은 전송된 신호화와 패이로드에 임의의 변경을 필요로 하지 않고 전송시키지 않는 종래의 DSM-CC 캐로셀과 함께 사용될 수 있다는 장점을 갖는다.

본 발명의 개선된 실시예에서, 패이로드 모듈은 본 발명의 디바이스가 수신된 코드 모듈이 컴파일되어야 하는지의 여부를 결정할 수 있게 하는 제어 정보로서 사용된다. 이 때문에, DSM-CC 캐로셀을 위한 제 3 유형의 패이로드 모듈이 제공된다. 이 모듈은 다음의 코드 분석 표로서 지칭되며, 도 5의 문자(T)를 갖는 종이로 표기된다.

코드 분석 표(T)는 다음과 같은 것을 포함할 수 있다

a) 캐로셀의 중간 코드 모듈(I)이나 사전-컴파일되어야 하는 이러한 모듈의일부분을 식별케 하는 제어 정보. 캐로셀의 한 I 모듈은 여러 애플리케이션에 속해 있는 코드를 포함할 수 있고, 이들 모두가 사전-컴파일에 유용하지는 않을 수 있기 때문에 모듈의 일부분의 컴파일이 유리할 수 있다. 나아가, 단일 애플리케이션에 관계된 코드 중에서, 다른 것보다 훨씬 더 빈번하게 수행될 부분이 있을 수 있다. 그에 따라, 처음부터 애플리케이션의 최적 수행 속도를 달성하기 위해, 해석에 덜 중요한 부분은 남겨두고 I 모듈의 중요한 부분만을 사전-컴파일하여, 그에 따라 절약된 컴파일 엔진(CE)의 처리 시간이 또 다른 I 모듈의 중요한 부분을 컴파일하는데 사용될 수 있는 것이 현명할 수 있다. 이들 부분은 예컨대 중간 코드의 단일 기능이나 메소드(methods)일 수 있다.

이러한 제어 정보는 또한 개별 부분의 컴파일을 위한 우선순위 레벨을 지시할 수 있다. 이것은 컴파일 엔진이 먼저 최대 우선순위 레벨을 갖는 I 모듈의 일부분을 컴파일하고, 그런 다음, 다른 모듈의 동일한 우선순위 레벨을 갖는 일부분을 컴파일하며, 컴파일 시간이 공유될 수 있자마자, 더 낮은 우선순위 레벨을 갖는 모듈의 일부분에 대한 컴파일을 시작하게 할 수 있다.

b) 컴파일 최적화 정보. 이 정보는 최적의 시스템 성능을 달성하기 위해 코드의 주어진 부분을 컴파일하는 방법에 관해 컴파일 엔진(CE)에 힌트를 제공할 수 있다. 이 정보에 명시된 최적화는 예컨대, 펑션 인라이닝(function inlining), 루프 언롤링(loop unrolling), 레지스터 사용, 파이프라이닝(pipelining), 스위치 재기록 등을 수반할 수 있다. 이 정보는 주어진 애플리케이션의 개발자에 의해 준비될 수 있다. 셋톱박스가 T 모듈에서 주어진 컴파일 힌트를 주의할 필요는 없다; 즉, 만약 셋톱박스가 이러한 컴파일 힌트를 주의하지 않는 경우에도, 셋톱박스는 정확하게 컴파일할 수 있을 것이지만, 만약 셋톱박스가 이러한 컴파일 힌트를 주의하는 경우에는, 셋톱박스는 컴파일 엔진의 알고리즘이 상당히 간단해질 수 있을 지라도 매우 효율적인 원시 코드를 생성할 수 있을 것이다. 그 복잡도 레벨에 따라, 셋톱박스는 그러므로 이들 힌트 중 어떤 것도 주의하지 않을 수 있고, 이들 힌트중 일부 또는 이들 힌트 모두를 주의할 수도 있다.

본 발명에 의해 다음의 주요한 장점을 얻을 수 있다. 무엇보다도, 애플리케이션의 코드의 적어도 일부분의 컴파일으로 인해, 애플리케이션의 수행 속도는 상당히 증가한다. 코드의 해석은 컴파일된 코드의 수행보다 상당히 느리며, 이것은, 해석할 때 처리력은 중간 코드의 일부분을 이 일부분이 수행될 때마다 수행 엔진(EE)의 원시 코드로 번역하는데 소비되는데 반해, 컴파일할 때, 이 코드는 한번만 번역된다는 사실에 주로 기인한다.

본 발명은 애플리케이션의 병목부(bottleneck parts)가 컴파일되게 될 때 매우 효율적이다. 사실, 애플리케이션의 단지 일부분만이 수행 엔진에 상당한 부담을 초래하게 될 때 이 애플리케이션의 모든 부분을 컴파일할 필요가 없을 수 있다. 분명히, 많은 횟수동안 반복된 코드 부분이 있을 때, 이들을 컴파일함으로써 얻게된 효율성 증가는 상당할 수 있다. 다른 한편, 단지 한번만 수행되거나 수행될 가능성이 낮은 코드의 일부분이 있을 수 있다. 이들 부분에 대한 컴파일은 효율성의 증가를 유도할 수 없어서, 이들을 컴파일할 가치가 없을 수 있다. 제 2 장점은 일반적으로 컴파일은 코드를 좀더 콤팩트하게 한다는 점이다. 그에 따라, 만약 코드가 컴파일된다면, 주어진 캐시 규모에서 컴파일하지 않는 것보다는 더 많은 모듈을 저장하는 것이 가능할 것이다.

메모리를 좀더 효율적으로 사용한 덕분에, 주어진 MHP가 훨씬 더 많은 애플리케이션을 동시에 호스팅하는 것이 가능하게 된다. 사용자의 관점에서, 이로 인해 셋톱박스는 더 강력하게 보이게 된다.

마지막으로, 말하는 것이지만 중요한 것으로, 코드 분석 표를 현명하게 준비함으로써, 애플리케이션의 개발자는 자신이 기록한 코드가 수행 엔진의 원시 명령으로 번역되는 방식에 대한 제어를 증가시키게 되었다. 이렇게 하여, 더 간소한 컴파일 및/또는 해석 엔진을 사용하여 매우 효율적인 원시 코드가 생성될 수 있다.

상술한 바와 같이, 본 발명은 단말국에서 애플리케이션을 실행하는 데이터 처리 디바이스 및 방법에 이용된다.

Claims (28)

1. 프로그램 가능한 데이터 처리 디바이스로서,

   - 방송 네트워크의 스트림(DC)으로부터 데이터 및/또는 제 1 유형의 코드의 일부분을 수신하기 위한 것으로, 상기 일부분은 반복해서 송신되는, 로딩 엔진(LE)과,

   - 상기 로딩 엔진에 의해 수신된 일부분을 저장하기 위한 저장 수단(C)과,

   - 상기 수신된 부분에 의해 구현된 애플리케이션을 수행하기 위한 수행 엔진(EE)과,

   - 제 1 유형의 코드를 상기 수행 엔진(EE)의 원시 코드로 번역하기 위한 번역 엔진(TE)을 포함하는 프로그램 가능한 데이터 처리 디바이스에 있어서,

   상기 번역 엔진(TE)은, 그에 따라 컴파일된 부분을 상기 저장 수단(C)에 저장하고, 미리 결정된 신호화 정보가 스트림으로부터 수신될 때 상기 수신된 부분 중 적어도 특정한 하나의 부분을 원시 코드로 컴파일하고, 다른 코드 부분을 해석하도록 적응되고,

   상기 수행 엔진(EE)은 동일한 애플리케이션 내에서 컴파일된 코드 및 해석된 코드를 처리하도록 적응되는 것을,

   특징으로 하는 프로그램 가능한 데이터 처리 디바이스.
2. 제 1항에 있어서, 상기 번역 엔진(TE)은 수신한 제어 정보에 따라 상기 특정한 일부분을 선택하도록 적응되는, 프로그램 가능한 데이터 처리 디바이스.
3. 제 1항 또는 제 2항에 있어서, 상기 스트림(DC)은 DSM-CC 캐로셀(carousel)인, 프로그램 가능한 데이터 처리 디바이스.
4. 제 3항에 있어서, 상기 일부분은 DSM-CC 모듈(I)인, 프로그램 가능한 데이터 처리 디바이스.
5. 제 3항에 있어서, 상기 일부분은 DSM-CC 모듈의 작은 부분인, 프로그램 가능한 데이터 처리 디바이스.
6. 제 2항 내지 제 5항 중 어느 한 항에 있어서, 상기 번역 엔진(TE)은 상기 스트림(DC)으로부터 상기 제어 정보를 수신하도록 적응되는, 프로그램 가능한 데이터 처리 디바이스.
7. 제 3항, 제 4항 또는 제 6항 중 어느 한 항에 있어서, 상기 제어 정보는 DSM-CC 프리-페치 신호화 정보인, 프로그램 가능한 데이터 처리 디바이스.
8. 제 3항, 제 6항 또는 제 4항 및 제 5항 중 어느 한 항에 있어서, 상기 번역 엔진(TE)은 상기 DSL-CC 캐로셀(DC)의 패이로드 모듈(T)로부터 제어 정보를 추출하도록 적응되는, 프로그램 가능한 데이터 처리 디바이스.
9. 제 8항에 있어서, 상기 번역 엔진(TE)은 상기 패이로드 모듈(T)로부터 컴파일될 코드의 일부분에 관한 컴파일 최적화 정보를 추출하고, 상기 코드의 일부분을 컴파일하는 과정에서 상기 컴파일 최적화 정보를 주의하도록 적응되는, 프로그램 가능한 데이터 처리 디바이스.
10. 제 2항 내지 제 9항 중 어느 한 항에 있어서, 상기 번역 엔진(TE)은 상기 수행 엔진(EE)으로부터 제어 정보를 수신하도록 적응되는, 프로그램 가능한 데이터 처리 디바이스.
11. 제 1항 내지 제 10항 중 어느 한 항에 있어서, 상기 번역 엔진(TE)은 상기 수행 엔진(EE)으로부터 수신된 제어 정보에 따라 제 1 유형 코드의 주어진 일부분을 컴파일할 것인지 또는 해석할 것인지를 결정하도록 적응되는, 프로그램 가능한 데이터 처리 디바이스.
12. 제 11항에 있어서, 상기 번역 엔진(TE)은 주어진 제 1 유형의 코드의 일부분을 컴파일하는 동안에, 상기 일부분이 해석될 것을 요구하는 제어 정보를 무시하고, 상기 부분의 컴파일을 마치도록 적응되는, 프로그램 가능한 데이터 처리 디바이스.
13. 제 11항에 있어서, 상기 번역 엔진(TE)은, 상기 일부분을 컴파일하는 동안에 주어진 제 1 유형의 코드의 일부분이 해석될 것을 요구하는 제어 정보를 수신할 때, 상기 컴파일을 포기하고 상기 일부분의 해석을 시작하도록 적응되는, 프로그램 가능한 데이터 처리 디바이스.
14. 데이터 처리 방법으로서,

    -a) 방송 네트워크의 스트림(DC)으로부터 데이터(D) 및/또는 제 1 유형의 코드(I)의 일부분을 수신하는 단계(a1, a1')로서, 상기 일부분(I 및 D)은 반복해서 송신되며, 상기 스트림(DC)에서 송신된 일부분의 세트는 하나 이상의 데이터 처리 애플리케이션을 구현하는, 데이터 및/또는 제 1 유형의 코드의 일부분 수신 단계(a1, a1')와,

    -b) 상기 일부분 중 미리 결정된 부분을 저장 수단(C)에 저장하는 단계(a6, a9', b3)와,

    -c) 미리 결정된 신호 정보가 스트림으로부터 수신될 때, 제 1 유형의 코드를 포함하는 상기 일부분 중 적어도 하나를 수행 엔진의 원시 코드로 번역 엔진에서 컴파일하는 단계와;

    -d) 수행 엔진(EE)에서, 상기 데이터 처리 애플리케이션 중 하나를, 이 하나의 애플리케이션에 속해 있는 선택된 부분의 컴파일된 원시 코드(N)를 수행함으로써(c6), 및 이 애플리케이션의 비-선택된 부분을 해석함으로써(c7), 실행하는 단계를,

    포함하는, 데이터 처리 방법.
15. 제 14항에 있어서, 단계(c) 및 d)) 사이에, 단계(d))에서 실행될 애플리케이션을 명시하는 명령을 사용자로부터의 수신하는 단계를 포함하는, 데이터 처리 방법.
16. 제 14항 또는 제 15항에 있어서, 상기 단계(c))에서, 상기 적어도 한 일부분은 상기 번역 엔진(TE)에 공급된 제어 정보를 기초로 해서 선택되는(a2, a3', a4', a5'), 데이터 처리 방법.
17. 제 14 내지 제 16항 중 어느 한 항에 있어서, 상기 스트림(DC)은 DSM-CC 캐로셀인, 데이터 처리 방법.
18. 제 17항에 있어서, 상기 일부분은 DSM-CC 모듈인, 데이터 처리 방법.
19. 제 17항에 있어서, 상기 일부분은 DSM-CC 모듈(I)의 작은 부분인, 데이터 처리 방법.
20. 제 16항 내지 제 19항 중 어느 한 항에 있어서, 상기 제어 정보는 상기 스트림(DC)으로부터 수신되는(a2, a5'), 데이터 처리 방법.
21. 제 18항 또는 제 20항에 있어서, 상기 제어 정보는 DSM-CC 프리-페치 정보인, 데이터 처리 방법.
22. 제 18항, 제 19항 또는 제 20항 중 어느 한 항에 있어서, 상기 제어 정보는 상기 DSM-CC 캐로셀(DC)의 패이로드 모듈(T)인, 데이터 처리 방법.
23. 제 22항에 있어서, 상기 제어 정보는 컴파일될 코드의 일부분에 관한 컴파일 최적화 정보를 더 포함하며, 상기 번역 엔진은 상기 코드의 일부분을 컴파일할 때 상기 컴파일 최적화 정보를 주의하는, 데이터 처리 방법.
24. 제 14항 내지 제 19항 중 어느 한 항에 있어서, 상기 제어 정보는 상기 수행 엔진(EE)으로부터 수신되는(a4'), 데이터 처리 방법.
25. 제 24항에 있어서, 상기 번역 엔진(TE)은 주어진 제 1 유형의 코드 일부분을 컴파일할 것인지 해석할 것인지의 여부를 상기 수행 엔진(EE)으로부터의 상기 제어 정보를 기초로 해서 결정하는, 데이터 처리 방법.
26. 제 25항에 있어서, 상기 번역 엔진(TE)이 상기 일부분을 컴파일하는 동안에주어진 일부분이 해석될 것을 요구하는 제어 정보를 수신한다면, 상기 번역 엔진(TE)은 상기 제어 정보를 무시하고(c11), 상기 일부분의 컴파일을 마치는, 데이터 처리 방법.
27. 제 25항에 있어서, 상기 번역 엔진(TE)이 상기 일부분의 컴파일 동안에 주어진 일부분이 해석되는 것을 요구하는 제어 정보를 수신한다면, 상기 번역 엔진(TE)은 상기 컴파일을 포기하고, 상기 일부분의 해석을 시작하는, 데이터 처리 방법.
28. 제 14항 내지 제 27항 중 어느 한 항에 있어서, 상기 단계(c)) 이후에, 상기 컴파일된 부분의 상기 제 1 유형의 코드에 할당된 메모리 공간은 겹쳐기록되기 위해 해제되는, 데이터 처리 방법.