Linus Torvalds는 Transmeta라는 프로세서 회사에서 근무했습니다. 그들이 만든 프로세서는 핵심적인 RISC 기반 개체였습니다. 내가 올바르게 기억한다면, 코어는 임의의 업그레이드 가능한 "프로세서 에뮬레이션 레이어"(x86, powerpc 등일 수 있음)를 실행하여 RISC 코어 명령어 세트로 높은 수준의 opcode를 변환하는 것이 었습니다.코드 모핑은 어디로 갔습니까?
이 아이디어에는 어떤 변화가 있었으며, 그러한 접근법이 장점 (프로그래밍면에서)을 가질 수 있었던 장단점과 단점은 무엇이라고 생각하십니까?
회사는 기대했던 것뿐만 아니라 결국 Novafora에 의해 절전 기술로 인수되었습니다. (http://www.novafora.com/pr01-28-09.html)
내가 알고있는 모든 계정에서이 기술은 기존 시스템과 단순히 경쟁하지 않았습니다. 그들은 성능 수치에 훨씬 미치지 못했습니다. 또한 VLIW 디자인 위에 다른 번역가를 추가하는 것도 가능했지만, 제작 한 제품에 대해서는 전혀 알지 못합니다. 나는 Crusoe 칩이 대체 "번역"마이크로 코드 다운로드를 수용 할 수 있다는 것을 기억하지 못합니다.
나는 개인적으로 Crusoe 프로세서를 사용하는 장치를 소유하고 있었으며 배터리 수명이 길어졌지만 장치 성능은 저조했습니다. 일부 비난은 아마도 사용 된 Windows의 특별 버전에서 평준화 될 수 있지만 여전히 느립니다.
기껏해야 휴대용 리모컨 데스크톱에 적합했습니다.
이럴 기술은 소프트웨어 VM의 닷넷 같은과 JVM과 같은 이점이 있습니다
현대의 x86 칩을 매우 전문화 된 것으로 생각할 수도 있지만 코드 모핑으로 생각할 수 있습니다.그들은 x86 아키텍처를보다 효율적인 RISC와 같은 하위 명령 세트로 변환 한 다음 실행합니다.
이러한 종류의 기술의 또 다른 예는 회로 수준에서 다양한 프로세서 또는 원시 회로를 에뮬레이트하도록 프로그래밍 할 수있는 FPGA 일 수 있습니다. 나는 몇몇 Cray 시스템이 이런 종류의 "가속기 노드"를 가질 수 있다고 믿습니다.
명백한 장점 : 어떤 OS를 실행하는
명백한 단점 :
대부분의 CISC 프로세서는 RISC 연산과 비슷한 uops 마이크로 연산으로 내부적으로 opcode를 변환합니다. 파이프 라이닝과 다중 코어 덕분에 RISC 프로세서의 갭이 존재하는 경우 그 차이가 매우 작습니다. C 소스 또는 다른 어셈블리 프론트 엔드에서 상호 호환성이 필요한 경우 LLVM을 사용할 수 있습니다. http://llvm.org/
대부분의 최신 프로세서는 실제로 microcode을 사용하여 명령어 세트를 구현합니다. 호환성 문제를 비롯한 여러 가지 이유가 있지만 이유는 다른 입니다.
"하드웨어"와 "소프트웨어"의 차이점은 실제로 만들기가 어렵습니다. JVM 또는 CIL (.NET)과 같은 최신 가상 시스템을 하드웨어로 구현할 수도 있지만 어쨌든 마이크로 코드를 사용하면 쉽게 완료 할 수 있습니다.
시스템에서 여러 계층의 추상화가있는 이유 중 하나는 높은 수준에서 작업 할 때 프로그래머/엔지니어가 관련없는 세부 사항을 생각할 필요가 없다는 것입니다.
운영 체제 및 시스템 라이브러리는 추가 추상화 계층도 제공합니다. 그러나이 레이어를 사용하면 시스템이 제공하는 기능 (즉, OS에 의해 수행되는 스레드 스케줄링)이 필요하지 않은 경우에만 시스템의 속도가 느려집니다. 리눅스 커널에서 프로그램 고유 스케줄러를 깨는 것은 쉬운 일이 아닙니다.
비용 절감에는 많은 양이 따르므로 Transmeta 칩과 같은 제품은 대량의 대량 판매해야만 기존의 대량 x86 칩과 가격 경쟁을 할 수 있습니다.
내가 기억한다면 Transmeta 칩의 포인트는 저전력이라는 점이었습니다. 매 클럭주기를 앞뒤로 뒤집어 쓰는 실리콘 게이트가 적 으면 에너지가 절약됩니다. 코드 모핑은 저전력 RISC 칩에서 복잡한 명령어 세트 (CISC)를 실행할 수 있도록 만들어졌습니다.
트랜스 메타의 첫 번째 프로세서 인 크루소 (Crusoe)는 벤치 마크 소프트웨어를 실행하는 데 문제가있어 잘 수행하지 못했습니다. 두 번째 프로세서 인 Efficeon은 Intel Atom (동일한 성능 범주)보다 적은 전력을 사용하고 동일한 전력 봉투에서 Centrino보다 성능이 뛰어납니다.
코드 모핑은 현재 소프트웨어와 유연성 관점에서 보았을 때 코드 모핑은 Just-In-Time 컴파일의 한 형태이며 그 기술의 모든 이점과 단점이 있습니다. x86 코드는 기본적으로 가상 머신에서 실행되며 다른 프로세서에서 에뮬레이트됩니다. 현재 가상화의 가장 큰 이점은 여러 가상 시스템에서 단일 프로세서를 공유 할 수있어 유휴 CPU 사이클이 줄어들어 하드웨어 비용과 에너지 비용이 더 효율적이라는 것입니다.
그래서 어떤 형태의 가상화와 마찬가지로 코드 모핑은 자원으로 인해 더욱 효율적이라고 생각합니다.
하드웨어 지원 x86 ISA 가상화에 대한 또 다른 접근법은 Loongson 3 CPU에 대해 읽는 것이 좋습니다.
+1 매우 흥미로운 질문입니다. 저는 누군가 x86 플래시 플레이어를 ARM으로 번역하기를 기다리고 있습니다. :-) – Zifre
코드 모핑은 HTC Google Nexus 9 태블릿 (Tegra K1 SoC에 2 개의 * Denver * 코어가 있음)에서 처음 사용 된 NVIDIA * Denver * 코어에서 리바이벌을 보았습니다. 내부적으로는 7-wide VLIW입니다. NVIDIA는 코드 모핑 기술인 "동적 코드 최적화"를 호출합니다. 기본적으로 런타임시 ARMv8-A 코드를 기본 코어에 대해 변환 및 최적화하고 결과를 전용 메모리 블록에 캐시합니다. 이상적인 조건 (예 :반복적이고 예측 가능한 코드), 데스크톱과 거의 같은 성능을 발휘합니다 * Haswell *; 덜 이상적인 조건에서는 Cortex-A53보다 훨씬 빠르지 않을 수 있습니다. – bwDraco
Nexus 9를 소유하고 있으며이를 광범위하게 사용합니다. 가장 가벼운 단일 스레드 작업에서는 성능이 뛰어나지 만 한 번에 많은 작업을 수행해야하는 경우 성능이 좋지 않습니다. 2 개의 코어 만 가지고 있으며 예측할 수없는 코드 (최적화 된 버전이 아직 캐시되지 않았고 처음 컴파일되거나 128MB 캐시에 완전히 들어 가지 않은)를 선호하지 않는 경우 복잡한 워크로드 성능이 눈에 띄게 저하됩니다. 이 프로세서는 내부적으로 아직 변환 및 최적화되지 않은 코드의 대체로 ARM 디코더를 가지고 있지만 매우 느립니다. 높은 클럭 속도 (2.3 GHz)가 약간 만회합니다. – bwDraco