컴파일,compile

컴파일,compile (rev. 1.5)

처리 과정
Source Program

Lexical Analyzer ... (lexical_analyzer, lexical_analysis)
↓ Tokens ... (토큰,token)
Syntax Analyzer ... (syntactic_analysis)
↓ Tree ... (AST)
Intermediate Code Generator
↓ Intermediate Code ... (intermediate_code) // intermediate_representation { https://en.wikipedia.org/wiki/Intermediate_representation }
Code Optimizer ... (code_optimization)
↓ Optimized Code
Target Code Generator

Object Program



rel.
컴파일러,compiler =컴파일러,compiler =,compiler 컴파일러 compiler
{
Sub:
just-in-time_compiler (JIT_compiler)
source-to-source_compiler
구성: // due to libre
frontend / backend
front-end : source_code { 소스코드 말고 다른번역: 원시코드 } dependent
lexical_analyzer / lexical_analysis : lexeme(단순한 어휘소)
scanner = tokenizer : 토큰,token 분리. token(의미를 가짐)
정규식,regular_expression,regex을 기반으로 한 DFA deterministic_finite_automaton 을 구현하여 제작됨 (? chk)
parser 파서,parser말고 좋은 번역은 없을지.. =,parser .
scanner에서 얻은 token을 이용해 parse_tree를 생성.
이 때 source_code 가 신택스,syntax에 맞는지 파악할 수 있으므로, WtEn:syntax_analyzer ( WpEn:syntax_analyzer = WpEn:syntactic_analyzer ?? chk) 라고도 부른다.
parser의 분류 기준
  • code를 : 왼쪽에서 오른쪽으로 해석하는지 / 오른쪽에서 왼쪽으로 해석하는지
  • token의 string 유도가 : 왼쪽에서 오른쪽으로 일어나는지 / 오른쪽에서 왼쪽으로 일어나는지
  • lookahead { 현재 토큰의 다음에 올 토큰,token. Ggl:파서 lookahead Naver:파서 lookahead Bing:파서 lookahead } 를 최대 몇 개 고려해 설계되는지
  • 어떻게 실행되는지
등의 기준에 따라 몇 가지로 분류 가능.
parser의 분류
dddddddddddddddddddd
back-end : machine dependent

Cmp:
인터프리터,interpreter =인터프리터,interpreter =,interpreter 인터프리터 interpreter
{
scripting_language{}는 컴파일러,compiler보단 이걸로 작성되는 경우가 많다. - 컴파일 속도로 인한 REPL의 지연,delay, ... +?
JIT_compilation때문에 컴파일러와 인터프리터의 기술적(? 정확히) 경계는 흐려지는 경향이 있다.









WpKo:JIT_컴파일
= https://ko.wikipedia.org/wiki/JIT_컴파일
"JIT 컴파일(just-in-time compilation) 또는 동적 번역(dynamic translation)은 프로그램을 실제 실행하는 시점에 기계어로 번역하는 컴파일 기법"

WpSimple:Just-in-time_compilation
WpEn:Just-in-time_compilation
}


Sources
처리과정: 최린 컴구 slide #2 p5