1.5. Applications of Compiler

1.5. Applications of Compiler 

컴파일러 설계는 많은 사람들이 학교에서 배우는 컴파일러 기술을 배우지만 대부분 PL을 만들지는 않는다.

컴파일러 설계는 컴퓨터 과학 분야에 영향을 준다.

이번 section에서 상호작용과 기술 응용에 대해서 배움.

1.5.1. Implementation of High-Level Programming Languages

Programmer는 알고리즘을 만들고

Compiler는 program을 target program으로 만듬.

high-level language는 쉽지만 느리다.

low-level programmer는 결과물에 비해 많은 노력을 하지만 효율적인 코드를 만든다.

high-level의 비효율적임을 상쇄가능하다.

Example 1.2.

high-level을 바로 machine code로 바로 만드는 것은 비효율적이다.

data-flow optimization이 효율적인 코드를 생성해내기 때문이다.

(1.4.2. 참조 - 2019/02/03 - [분류 전체보기] - 1.4. The Science of Building a Compiler)

Object-orientation

1. data abstraction

2. Inheritance of properties

modular and easier

더 많고, 더 작고, 많은 절차들로 구성

Java는 type-safe 언어다.

관계없는 타입의 객체는 사용되지 않는다.

Java는 pointer와 pointer 연산을 허용하지 않는다.

Java는 garbage-collection이 오래동안 사용하지 않은 메모리 변수를 자동으로 해재시킴.

compiler optimization은 overhead를 감소하려고 개발됨

overhead : 불필요한 범위 검사 제거,  접근할 수 없는 객체 할당...??

효율적인 알고리즘은 garbage-collection의 overhead를 최소화하기 위해 개발

Java는 호환성과 mobile code를 위해서 설계됨.

bytecode는 런타임에서 해석되거나 자연어로 컴파일(dynamically) 되어야만 한다.

1.5.2. Optimizations for Computer Architectures

Computer Architecture가 빠르게 변할 수록 compier 기술은 불안정.

high-performance system 은 2 가지 이점이 있다.

1. Parallelism

2. memory hierarchies

Parallelism

- 현대 microprocessor는 보통 instruction-level parallelism을 뜻함.

- 하드에어는 동적으로 순차적인 명령들을 check 한다. 그리고 가능한 별렬로 실행한다.

- 어떤 경우에는 machine은 hardware scheduler를 가르킨다.

hardware scheduler는 병렬의 개수를 늘리기 위해서 명령 순서를 바꿀 수 없다.

-H/W가 명령들을 다시 정렬하든 안하든, Compiler는 명령들을 재정렬 할 수도 있다.

(더 효과적인 instruction-level parallelism을 만들기 위함)

VLIW(very long Instruction Word)

VLIW machines은 명령어들을 병렬로 처리할 수 있다.

컴파일러 기술은 절차지향 프로그램을 자동으로 코드 생성하기 위해서 개발됨.

Parallelization 개발의 목적

Sequntial scientific programs  ->  multiprocessor code

Memory Hierarchies

-속도와 크기가 다른 몇 단계로 구성

-Processor에 가까울 수록 빨라짐. 하지만 작아짐.

-Parallelism and memory hierarchy

-machine의 성능에 항상 도움.

-하지만 효과적이지 못함. 왜냐하면, compiler가 real performance를 app에 제공하기 때문임.

- Processor usally has

- 작은 레지스터 (byte)

- 몇 단계의 캐쉬 (Kb~ Mb)

- 물리적 메모리 (Mb ~ Gb)

- Secondary 메모리 (Gb ~ )

- 인접 메모리 계층의 접근은 속도차가 발생할 수도 있음

이유 : by two or three orders of magnitude

- system 성능은 processor의 속도에 따른 제한은 없지만, memory subsystem 때문에 제한이 없다.

- compier는 processor 실행 최적화에 초점을 두었었지만, 지금은 메모리 계층을 더 효율적으로 만드는데 초점을 둠.

- optimizing program에서 register를 효율적으로 사용하는 것이 가장 중요!!!!!!!!!!!!!!!

- register SW에서 명시적으로 관리됨.

- caches and physical memory 명령들에서 숨겨져 있고, HW에 의해 관리.

- Cache-management polices는 larage data structure에서 비효율적

(Cache-management polices : HW에서 구현) (larage data structure : array가 대표적)

효율적이려면 data의 양식을 바꾸거나 명령 순서를 바꿔야함.

- cache 명령을 효율적으로 바꾸기 : code layout 바꾸면 가능할 수도 있음.

1.5.3. Design of New Computer Architectures

high-level language가 대중화 되면서 compiler를 잘사용하는지?,  its raw speed 가 컴퓨터 시스템 성능을 결정하지 않음.

in modern computer architecture development, 

컴파일러는 제안된 architecture features 평가하는데 사용되어짐.

compilers are developed in the processor-design, and compiled code, running on simulators

RISC

- Compiler 가 computer architecture 설계에 어떻게 영향을 줄지에 대한 잘 알려진 발명임.

- RISC 이 전에는 assembly programming을 쉽게 만들어내는 것이 trend 였음.

= Typically CISC(Complex Instruction-Set Computer)

CISC 명령 집합

- 복합 메모리주소 모드 포함. 데이터 구조 접근과 프로시져 호출 명령들 지원

(프로시져 호출 명령들 : stack에 register, 통과 매개변수 저장,)

- compiler optimization은 구조에서 중복을 제거해서 명령들을 간단하게 만듬.

=> 그래서  HW는 최적화하기 많이 쉬워짐.

- 범용 processor architecture는 RISC를 기반으로 함.

- x86 architecture는 CISC 명령set을 가지지만, 많은 ideas는 RISC를 위해서 개발됨.

많은 ideas는 processor 자체 개발에 사용되어졌음.

Specialized Architectures

- 지난 30년간 VLIW, SIMD 등 많은 architectural concepts 제시됨.

- architectural concepts 개발은 (컴파일 기술)연구와 개발이 동반됨.

- 이러한 의견들은 임베디드 설계로 만들어짐

- 맞춤식 processors는 특정 app의 cost-effective 향상 시키기 위해서 나옴.

- 이와 달리 범용 processor는 경제규모 때문에 나옴. 앱별로 다양한 아키텍처를 출시.

- 결론 : compiler 기술은 아키텍처를 위한 programming 뿐만 아니라, 제안된 아키텍처 설계를 평가하기 위해 필요해짐.

1.5.4. Program Translations

- 전혀 이해 안됨. 그래서 영문으로 남김

While we normally think of compiling as a translation from a high-level language to the machine level, the same technology can be applied to translate between different kinds of languages. The following are some of the important applications of program-translation techniques.

Binary Translation

- Binary Translators는 x86 code를 변환(Alpha code, Sparc code)하기 위해서 개발됨.

- Trensmeta Inc에 의해서 Binary Translation 사용되어짐.

- 이 회사는 HW에서 직접 x86 명령을 실행하는 것이 아니라,

x86 code  ->  native VLIW code 이진 변환함.

(the Trensmeta Crusoe processor is a VLIW processor

- backward 호환성을 제공하기 위해 Binary translation 사용

- 1994년에 매킨토시 processor가 Motorolar MC68040에서 PowerPc로 바뀜.

이 때, PowerPC processors는 MC68040의 코드를 그대로 사용했음.

Hardware Synthesis

- SW는 high-level languages로 쓰여짐.

- HW설계는 VHDL처럼 high-level HW에서 설명되어졌음.

- HW설계는 대표적으로 register transfer level에서 설명됨.

- HW Synthesis tools은 RTL -> Gates, 그리고 transistors에 mapping, 물리적 layout으로 변환.

- Compilers와는 다르게 종종 최적화 circuit을 가짐

- 높은 단계에서 설계변환 기법도 존재함.

 (Behavior of functional level)

Database Query Interpreters

- DB 쿼리는 관계적이고 boolean 연산자들을 포함하는 술부로 구성된다.

- 술부에 만족하는 records를 검색, 해석에 사용.

Compiled Simulation

- Simulation은 현상 이해나 design을 증명하기 위해서 사용되는 기술임.

- Simulation에는 가능한 많은 input set이 좋고, simulation으로 몇 일을 보낼 수도 있음.

- design simulator 작성보다 design을 compile하는게 더 빠름.

- 컴파일된 시뮬레이션은 interpreter-based 접근보다 빠르게 run orders of magnitude

1.5.5 Software Productivity Tools

- Programs은 완벽하게 일하는 것보다 정확하게 일하는 것이 더 중요함.

- 에러가 많으면 System 파괴, 잘못된 결과 생산, 보안에 취약한 프로그램을 만들고, 중요한 시스템을 치명적인 실패로 만듬.
- test는 에러 찾는 것에서 가장 중요한 기술이다.

- 좋은 test 접근법은 data-flow analysis 를 이용해서 자리잡은 에러를 찾는 것이다.

- compiler optimization과 달리 error 감지 기술은 불완전할 수도 있다.

- Optimizaer는 보수적이라 어떠한 상황에서도 안바뀔 경우가 높다.

- 프로그램이 취약점으 가지면 특별한 기술을 사용하는 것은 중요.

Data-Flow Anaysis

- 가능한 모든 실행 경로에서 에러 찾을 수 있음.

이는 test case에 의한 사용이 아님

- compiler optimization을 위해 개발된 많은 data-flow analysis는 programmers의 engineering tasks를 돕기 위한 툴 개발에 이용됨.

- error 경고를 위해 만들어짐.

Type Checking

- 잘못된 객체 타입 사용시 적용.

- 파라미터가 procedure를 통과시.

- 보안 취약점 : 주의할 필요 없는 data나 string을 공격.

=> 크래커에 의해 제공된 string은 "dangerous"로 표기 되야함.

적절한 format이 check 안되면 "dangerous"가 여전히 남고

program 속의 코드는 잠재적인 보안 취약점을 가지고 있을 수 있음. ( C의 버퍼오버플로우가 특히 그런거 같음. )

Bounds Checking

- low-level programming 많은 실수를 많듬.

- C의 Buffer overflow는 보안 문제를 야기함.

C는 arrays의  bounds를 check 안함. 그래서 사용자가 알아서 잘 써야함.

크래커는 input data로 조종함. - system 보안을 건드리거나 잘못된 행동들을 발생시킴.

- Buffer overflows를 찾기 위한 기술 개발은 완벽하게 개발 안됨.

- Data-flow analysis는 buffer overflow를 찾는데 사용됨.

- 포인터 추적 기술은 고급 에러 검사 기술임.

- potential buffer overflow는 시스템 보안을 위협함.

Memory-Management Tools

- Gabage Collection은 효율성, 쉬운 프로그래밍, SW 신뢰성에서 매우 훌륭함!

- Automatic memory management 는 C와 C++의 memory-management errors를 해결함.

- Tools는 프로그래머의 memory-management error를 찾는 것을 돕기 위해 개발됨.

(Typically, Purify)