동적 언어 (일반적인 스크립팅 언어와 유사)가 있고 컴파일러를 작성하려고한다고 가정 해 보겠습니다. 유형 태그와 같은 것을 기계 단어의 일부 비트로 예약하는 것이 좋은 생각입니까? 특히 마이크로 컨트롤러 및 유사 장치의 경우 좋은 생각입니까?기계어 프리미티브의 복수가 아닌 것이 좋은 생각입니까?
유형 정보를위한 저장 공간 감소, 메모리 관리 (어쩌면 gc조차도) 및 디버깅의 용이함과 같은 몇 가지 이점을 생각해 볼 수 있습니다. 그러나 이것들은 일반적인 산술 연산이나 완전한 연산을 필요로하는 다른 연산에 대한 오버 헤드를 정당화 할 수 있습니까? 성능 오버 헤드가 훨씬 더 많으므로 바이트 코드 VM이 훨씬 더 심각합니다.
일부 어쨌든 마이크로 컨트롤러 수준의 하드웨어에 대한 숫자 강렬한 코드를 작성하는 것처럼되지 않습니다하지만 여전히 ...
은 유형 비트를 확인해야하는 복잡성 didn 히), 그래서 그것을하지 않는 것이 좋습니다 모든 계산을 통과시키지 않으면 스토리지 절약 효과를 훨씬 능가 할 것입니다. 필요한 메타 데이터/플래그를 포함하는 기본 필드에 유형 필드를 항상 할당 할 수 있습니다. 그런 다음 원하는 유형 및 상태 정보를 저장하는 단어 하나를 제외하면 모든 값의 저장 크기는 항상 n + 1 단어입니다.
아니요, 이것은 일반적인 용도의 컴파일러에서는 적합하지 않습니다. 산술 연산에서 "유형 태그"비트를 처리하는 오버 헤드가 심합니다.
동적 인 형식의 언어는 각 특성에 대한 형식 정보를 저장하기 위해 추가 공간을 필요로합니다. 많은 양의 균질 형식 데이터를 저장해야하는 경우 올바른 방법은 일반적으로 C에서 수행하도록 설계된 원시 코드 모듈을 사용하는 것입니다.
예를 들어, 5 개의 정수 배열을 저장하려는 경우 Python list은 괜찮습니다 (임의로 복잡한 혼합 유형을 저장할 수 있음). 그러나 5 백만 개의 정수 배열을 저장하려는 경우 동등한 C 배열로 저장하는 array 모듈을 사용하거나 비슷한 수학 연산을 수행하는 NumPy를 사용해야합니다.
마이크로 컨트롤러가 "마이크로"상태에 달려 있습니다.
예를 들어, ARM 코어의 배럴 시프터 및/또는로드/저장시 사용할 수있는 무료 마스크가이 플래그를 공정하게 처리하는 데 드는 비용을 절감 할 수 있다고 생각합니다. 합리적. 분명히 그것은 클래스 최상위에 있지만, ARM은 요즘 어디에서나 얻을 수 있습니다.
LISP는 fixnum이 단어보다 작음을 나타내는 유형 플래그를 사용합니다. 따라서 LISP 구현 (자신이 관심있는 프로세서를 찾을 수있는 경우)을 통해 비용을 최소화하는 방법과 최선의 노력이 요구 사항을 충족시키는 지 확인할 수 있습니다.
SPARC 칩은 하드웨어에서 직접 산술 기능을 태그로 지정했습니다.이 종류의 응용 프로그램을 위해 명시 적으로 설계되었습니다. 이 기능이있는 다른 아키텍처에 대한 참조도 보았습니다. 실제로이 언어를 실제로 사용하는 것이 얼마나 큰지는 또 다른 질문입니다. 파이썬과 같은 대부분의 동적 언어는 이식성을 위해 제작되었으므로 아키텍처에서이 언어에 의존 할 수있는 옵션이 없습니다.
작은 정수로 이것을 수행하는 데 사용 된 이전의 작은 토크는 특정 값까지는 int이고 임계 값 이상은 개체 포인터입니다.
컴파일 된 코드에서 각 작업의 플래그를 직접 테스트하기를 원하는 경우, 해석 된 바이트 코드가 느린 것과 같은 종류의 이유 때문에 속도가 느려집니다.아마도 바이트 코드만큼 느리지는 않을 지 모르지만, Amdahl의 법칙이 당신에게 불리하게 작용할 것입니다.
한편 완전 동적 언어를위한 간단한 컴파일러는 어쨌든 형식 검사의 일부 형식을 수행해야합니다. 동적 디스패치의 보편적 인 사용은 최신 프로세서에 심각한 성능 저하를 초래할 수 있습니다. (마이크로 컨트롤러에서는 그다지 심각하지 않을 수도 있습니다.)
컴파일러가 위의 런타임 유형 검사의 대부분을 최적화 할 수 있다면 성능을 다시 얻을 수 있습니다. 그러나이를 구현하는 것은 간단하거나 간단하지 않을 수 있습니다. 내 생각 엔 필요한 마스킹은 불필요한 작업이므로 비트 플래그가 발생하지 않도록하고 싶을 것입니다.