Programming Language & Automata 1 - Lexeme & token

-

프로그래밍 언어론과 오토마타와 형식언어 라는 수업은 두 개의 수업으로 취급되고 있다. 그러나 공부하면서 개인적으로 느꼈을 때, 둘을 함께 공부하는 것이 이해가 더 쉽다고 생각하여 하나의 분류로 묶어 정리하였다.

 

우리가 프로그래밍을 할 때 컴퓨터가 어떻게 받아들일지, 컴파일러의 작동과 컴퓨터 구조에 대한 작동을 알아보는 것이 해당 과목들의 내용이다.

 

1. Lexeme 

우리가  프로그래밍을 할 때 컴파일러에 코드를 입력하면, 해당 내용들을 컴파일러가 읽고 단어와 식별자, operator 등으로 분류하여 해석해야 한다. 

이 때 입력되는 구문의 가장 작은 단위를 Lexeme이라 한다. 이 lexeme은 대부분의 언어에서 비슷하게 구분된다.


2. Token

Token은 각 Lexeme 종류의 그룹이다. 쉽게 말해 +, -, *, / 등은 operator라는 분류로 묶이고, int, float, char 등은 type이라는 분류로 묶는 것이다.


ex)    int        i                =              2               +           j      ;

        ^type   ^indentifier  ^assignOp  ^int_literal    ^plusOp ^identifier

댓글

댓글 쓰기

이 블로그의 인기 게시물

IIKH Class from Timothy Budd's introduction to OOP

-
 Timothy Budd의 An Introduction to OOP 3ed. IIIKH(Intelligent Interactive Kitchen Helper) 앞서 객체 지향 프로그래밍의 가장 큰 특징은 Separation of implementation and interface라고 하였다. 즉, 사용자는 해당 오브젝트의 기능들이 어떻게 실현되었는지 알 필요 없이 해당 오브젝트가 제공하는 기능들 만 사용할 수 있는 것이다. 그래서 책의 예제에 제공되는 6개의 클래스가 어떤 기능을 가져야 하는지 public / private 에 대해서 attribute와 method를 생성하였다. #pragma once class Greeter { //greeter component that starts at the very beginning of IIKH. It provides several menu for user to choose. private:     void show_menu(); // main display window when IIKH is started and offer several choices. public:     void call_RecipeDatabase(); // if user selects browse, add, edit recipe.     void call_PlanManager(); // if user selects review or create meal plan. }; class RecipeDatabase { // RecipeDatabase component that store recipes and manage them. private:     Recipe recipeList[100]; //store list of recipe components(objects) and can return, edit, add whenever nee...
자세한 내용 보기

Compiler 9 - Efficient Code generation

-
 이전의 코드 생성은 모두 가정(무한한 레지스터 등)에 의해 리소스를 낭비하였다. 따라서 이를 개선하는 방법이 필요하다. 따라서 memory access의 횟수를 줄여 실행속도를 증가시키고, 쓸모 없는 register의 사용을 줄여 리소스의 낭비 또한 방지한다. 이는 각 레지스터에 가능한 많은 변수를 가지고 있게 하는 방식으로 구현할 수 있다. 이를 위해서 서로 겹치지 않는 live variable을 하나의 레지스터가 공유하여 저장하도록 하면 된다. (덮어씌워도 더이상 사용되지 않는 변수라면 필요 없으므로) 이를 위해서 앞서 진행했던 live variable analysis를 global scope에서 모두 실행한다. 그리고 각 variable을 노드로 가지고, 동시에 존재하는 live variable 사이에 edge가 존재하도록 graph를 그린다. (Register Interference Graph - edge가 존재하는 노드 끼리는 서로 같은 레지스터를 공유하면 안된다) 이 RIG를 통해 연결되지 않은 노드는 같은 레지스터에 할당되어도 문제가 없다는 것을 알 수 있다. 따라서 전체 노드 수보다 적은 레지스터에 모든 변수를 저장할 수 있다. 그리고 TAC로 표현된 각 노드 변수에 서로 연결되지 않았다면 같은 레지스터를 할당하여 어셈브릴 코드를 완성할 수 있다. - k colorable (transform into graph coloring problem) 서로 연결되지 않은 노드에 같은 색을 할당하여 색칠할 때 k개의 색이 필요하다면, k개의 레지스터에 모든 variable을 저장할 수 있다. 따라서 이를 그래프 색칠 문제로 확장하여 이해할 수 있다. 그러나 해당 문제는 NP-hard problem이므로 답은 존재하지만, 효율적으로 풀 수 있는 방법이 없다. (가장 간단한 것이 O(n*2^n)) 따라서 이를 직접적으로 해결하기보다는 heuristic을 사용해야 한다. - Heuristics for graph coloring (not optimal, ...
자세한 내용 보기

Software Engineering 10 - V&V, SOLID principle

-
 Verification & Validation(V&V) - Verification : inspection 과 review를 통해 우리가 올바르게 제품을 만들고 있는지 각 스텝을 검사하는 것 inspection(static) : system의 실행이 필요하지 않고 코드나 requirement, design 등등 representation에 대해서 검사 가능. 소프트웨어의 퀄리티를 올리기 위한 가장 좋은 방법(Best Known Method) -Validation : 만들어낸 artifact가 requirement를 만족하는가? 주로 testing을 통해서 올바른 제품을 만들고 있는지 확인하는 것. testing(dynamic) : 현재 존재하는 에러를 입증 (에러가 없다는 것을 보장해주지 않음) 가장 cost가 많이 필요한 단계. inspection과 testing은 서로 상호보완적인 관계. inspection은 고객의 requirement를 만족하는지 실제로 확인하기 어려움. development testing - release testing - user testing의 stage로 구성된다. - Development testing = unit testing + component testing + system testing 각 unit의 functionality를 먼저 테스트하고, 이들을 합친 component의 interface를 확인한 다음 전체를 합쳐 integration된 시스템이 잘 작동하는지 확인하게 된다. Black box & White Box 내부 작동원리를 모르고 주어진 시스템에 대한 input/output만 구현하는 것이 black box, 내부 작동 원리와 유닛들 사이 interaction, 코드 등을 알고 수행하는 테스트가 white box이다. 주로 development 과정에서 개발자들에 의해 시행되는 테스트는 white box test가 되고, 제 3자가 테스트하는 경우(user / release tes...
자세한 내용 보기