C가 컴파일 / 통역 / JIT되는 것을 막는 것은 무엇입니까?

Java는 종종 놀라운 이식성으로 인해 칭찬받습니다. 내 질문은 C가 컴파일 / 해석 / JIT '되는 것을 막는 것입니다. 그렇다면 C를 한 번 작성하여 어떤 장치에서나 사용할 수 있습니다. 그러나 이것은 C 프로그램을 처리하는 데 널리 사용되는 메커니즘이 아닙니다.

이 방법으로 C를 처리하는 것의 단점은 무엇입니까? 또한이 방법으로 Java를 처리하고 머신 코드로 컴파일하지 않는 장점은 무엇입니까?

C는 내가 중급 언어라고 부르는 것입니다. 그 목적은 "매우 높은 수준의 어셈블러"역할을하는 것입니다. 이것이 컴파일러 대상으로 잘 작동하는 이유와 이식성을 잘 수용하는 이유입니다.

역사적으로 인터프리터는 일반적으로 메서드 호출의 맥락에서 고급 언어 와 함께 사용되었습니다 . 가장 간단한 형식으로, 인터프리터는 소스 언어의 각 키워드를 관련 토큰과 함께 구문 분석하고이를 메소드 호출 및 매개 변수로 변환합니다. 실제로 대부분의 통역사가하는 일은 소스 언어를 중간 표현으로 변환하는 것이며 해석되는 표현입니다.

C가 해석되거나 Jitted되는 것을 막는 것은 무엇입니까? 아무것도. 그러나 그것은 C의 raison d' être가 아닙니다.

우선, Sun의 JVM은 C로 작성되었습니다. C는 이식성이 필요할 때 가장 널리 사용되는 언어입니다.

많은 C 프로그램 이 없지만 C 언어 는 이식성 이 있습니다. C는 프로그래머에게 많은 제한을 두지 않거나 많은 가정을하기 때문입니다. C 프로그래머가 자신의 프로그램을 이식 가능하게하려면 이러한 제한을 스스로 적용해야합니다.

실제로, 그것은 당신에게 Java 강제의 제한을 가지고 사는 것보다 훨씬 어렵지 않습니다. 이는 엔디안과 기본 크기를 염두에두고 플랫폼 별 라이브러리 대신 GTK + 와 같은 휴대용 라이브러리를 사용하는 문제입니다 .

가상 머신, 심지어 JVM을 지원하는 GTK + 대상 및 C 컴파일러를 작성하고 기존 코드를 거의 변경하지 않고 작업 할 수 있습니다. 실제로 가비지 콜렉션이 없으면 C 가상 머신이 훨씬 단순 할 것입니다. 그래도 왜 하시겠습니까?

Java를 원시 코드로 컴파일하는 반대의 경우도 마찬가지입니다. 기본적으로 JIT가하는 일입니다. 그래도 왜 하시겠습니까? 나는 "그냥"그렇게하는 애완 동물 프로젝트가 있다고 확신하지만, 심각하게 사용되지는 않습니다.

당신은 말했다 :

Java는 종종 놀라운 이식성으로 인해 칭찬받습니다.

그리고 첫 문장에서 당신은 틀 렸습니다. JVM으로 인해 Java를 이식 할 수 없습니다. Java는 이식성이 뛰어납니다. Java 언어는 구현자가 프로그램의 작동 방식에 영향을주지 않는 방식으로 정의되기 때문입니다.

예를 들어, Java에는 "int"(부호 32 비트 정수)와 "long"(부호 64 비트 정수)의 두 가지 유형이 있습니다. C 및 C ++에는 "int"(최소 16 비트 부호), "long"(최소 32 비트 부호) 및 "long long"(최소 64 비트 부호)이 있습니다. C는 많은 다른 프로세서에서 실행되어야하고 다르게 동작 할 수 있기 때문입니다.

C는 이러한 유형에 대해 고정 크기를 정의 할 수 있습니다. 만약 그렇다면, 36 비트 프로세서는 C 언어를 구현할 수 없었습니다. 그리고 실제로 Java를 구현할 수 없습니다! C는 언어가 다양한 컴퓨터에서 작동 할 수 있도록했습니다. 이식성이없는 코드를 생성 할 수는 없습니다. 언어의 문제입니다.

Java는 이름에서 알 수 있듯이 실제 시스템 이 아닌 Java Virtual Machine을 대상으로하기 때문에 이식성이 뛰어납니다 . 다양한 유형의 실제 머신 아키텍처에서 가상 머신을 구현할 수 있으므로 JVM 기반 프로그램은 이식성이 뛰어납니다.

반면에 C는 전체 하드웨어 액세스가 필요한 운영 체제 구현의 특정 목적으로 만들어 졌기 때문에 실제 하드웨어에 대해 실행되도록 특별히 설계되었습니다. 즉, C 코드는 설계 상 특히 이식성이 없으며 C 프로그램을 한 플랫폼에서 다른 플랫폼으로 포팅 할 때 대상 아키텍처에 특정한 다양한 부분을 어느 정도 다시 작성해야합니다.

실제로 해석 된 버전의 C 가 있지만 프로덕션 시스템이 아닌 빠른 실험에 주로 사용됩니다.

작고 빠르며 정적 인 실행 파일을 얻지 못하면 왜 모든 Cidiosyncrasies를 겪을 것입니까?

이론적으로 C와 Java는 모두 원시 코드로 컴파일되거나 해석되거나 가상 머신으로 컴파일 될 수 있습니다.

C가 가상 머신으로 컴파일되지 않은 기술적 이유는 단순히 표준 가상 C 머신이 없기 때문 입니다.

그리고 아무도 가상 C 머신을 정의하거나 Java 가상 머신으로 컴파일하기를 원하지 않는 것 같습니다 (완벽히 가능합니다). 아마도 C를 사용하는 사람은 그 누구도 타의 추종을 불허하는 속도를 잃고 싶지 않기 때문일 것입니다. 아마도 C는 오픈 소스 커뮤니티에서 가장 강력하기 때문에 컴파일 (소스 배포 및 재 컴파일 및 실행)을 통해 이식성을 쉽게 수행 할 수 있기 때문에 폐쇄 형으로 실행 (이진 배포 및 실행)의 이식성에 대한 필요성을 느끼지 못합니다. 소스 개발자.

실제로이 작업이 완료되었습니다. LLVM으로의 컴파일을 지원하는 주요 컴파일러가 있습니다 (clang은 알고 있으며 gcc도 마찬가지라고 생각합니다). Java 코드가 JIT 된 바이트 코드로 컴파일 된 것처럼 LLVM을 JIT 할 수 있습니다.

그러나 C와 비교하여 Java를 "크로스 플랫폼"으로 만드는 것은 Java에 많은 런타임 라이브러리가있는 큰 런타임 라이브러리가 있다는 것입니다. C는 명시 적으로이 패러다임을 따르지 않습니다.

Java와 C 사이에는 몇 가지 주요 차이점이 있습니다. Java는 JVM (Java Virtual Machine)을 통해 운영 체제와 분리되어 있습니다. JVM은 운영 체제를 프로그램에서 추상화합니다. Java 응용 프로그램은 JVM에 메모리 청크를 요청하고 JVM은 OS에 해당 메모리를 요청합니다. 플랫폼 / 운영 체제에 따라 많은 JVM이 있습니다. JVM은 동일한 Java 프로그램이 다른 플랫폼에서 실행될 수있게합니다.

C를 사용하면 OS 격리가 없습니다. C 프로그램은 (일반적으로) OS 위에서 직접 실행되어 직접 OS를 호출합니다. 이 C 프로그램을 특정 운영 체제 / 플랫폼에 연결합니다. 사소하지 않은 프로그램은 운영 체제를 호출합니다. 또한 C 프로그램은 하드웨어에 따라 기계 코드로 컴파일됩니다. x86 용 컴파일 된 C 프로그램은 ARM 프로세서에서 직접 실행할 수 없습니다.