CbC: 새로운 프로그래밍 패러다임으로 GCC 업그레이드

읽는 시간: 6 분
...

📝 원문 정보

  • Title: Implementing Continuation based language in GCC
  • ArXiv ID: 1109.4048
  • 발행일: 2011-09-20
  • 저자: Shinji Kono and Kento Yogi

📝 초록 (Abstract)

: 이 논문은 GNU C 컴파일러와 동일한 속도로 실행되는 연속 전달 스타일의 프로그래밍 언어인 Continuation 기반 C(CbC)를 설계하고 구현하는 방법을 설명합니다. CbC는 C의 하위 집합으로, CPS 변환 기법을 사용하여 C 코드를 CbC로 컴파일할 수 있어 후퇴 호환성을 제공합니다. 논문에서는 GCC 4.2.3을 기반으로 한 새로운 부분적 CbC 컴파일러 구현을 보고하며, 이 컴파일러는 C와 CbC를 혼합하여 사용할 수 있는 CwC 언어를 지원합니다.

CbC의 기본 프로그래밍 단위는 코드 세그먼트로, 입력과 출력 인터페이스를 가집니다. 이를 통해 제어 구조가 간단하게 표현되며, 특히 Tail Call Elimination(TCE)와 goto 문을 활용한 스케줄링이 가능합니다. 이러한 특징은 CbC를 OS API의 실행 사양 언어로 사용할 수 있게 하며, 모델 체커도 CbC로 작성할 수 있습니다.

💡 논문 핵심 해설 (Deep Analysis)

Figure 1
:

1. CbC의 설계 목표와 배경

CbC는 Continuation Passing Style(CPS)을 기반으로 한 새로운 프로그래밍 언어로, GNU C 컴파일러와 동일한 속도로 실행되는 것을 목표로 합니다. CPS 변환은 함수 호출을 연속 전달 스타일로 변경하여 코드의 효율성을 향상시키는 기법입니다. 이 논문에서는 이러한 CPS 변환을 GCC에 통합하는 방법을 제시하며, 이를 통해 C와 CbC를 혼합 사용할 수 있는 새로운 언어인 CwC를 소개합니다.

2. CbC의 핵심 특징

CbC는 코드 세그먼트를 기본 프로그래밍 단위로 사용하며, 각 세그먼트는 입력과 출력 인터페이스를 가집니다. 이 구조는 제어 흐름을 명확하게 표현하고, 특히 Tail Call Elimination(TCE)와 goto 문을 활용한 스케줄링이 가능합니다.

  • Tail Call Elimination (TCE): TCE는 함수 호출의 최적화 기법으로, 마지막 연산이 함수 호출인 경우 스택 프레임을 재사용하여 메모리 사용량을 줄입니다. CbC에서는 이러한 TCE를 GCC에 통합하여 코드 효율성을 향상시킵니다.
  • goto 문: goto 문은 CbC에서 스케줄링과 제어 전환에 활용됩니다. 예를 들어, goto scheduler(self, task_list);와 같은 구문을 통해 스레드 간의 제어권 이동이 가능합니다.

3. CbC의 실용적 적용

CbC는 OS API의 실행 사양 언어로 사용할 수 있으며, 모델 체커도 CbC로 작성할 수 있습니다. 이를 통해 프로그램의 정확성과 안정성을 검증하는 데 활용됩니다.

  • 모델 체커 구현: SPIN이나 Java PathFinder와 같은 기존 모델 체커는 특수 사양 언어나 JVM을 사용하지만, CbC에서는 상태 열거기가 CbC로 작성되며, 동시성 의미론은 CbC 자체에 내장되어 있습니다. 이는 구현과 매우 가깝게 접근할 수 있는 장점이 있습니다.
  • 실용적인 컴파일러 개발: 현재 GCC 4.2.3을 기반으로 한 부분적 CbC 컴파일러가 구현되었으며, 이 컴파일러는 모든 아키텍처에서 이동 가능해야 합니다.

4. CbC의 제한점과 향후 개선 방안

CbC는 현재 GCC 버전에 종속적이며, 새로운 GCC 버전이 출시될 때마다 적절한 수정이 필요합니다. 또한, 일부 아키텍처에서는 TCE 자체가 지원되지 않을 수 있습니다.

  • TCE의 한계: 모든 TCE 테스트를 통과하도록 보장하는 것은 비실용적입니다. 따라서 expand_call() 함수를 TCE 전용 버전으로 구현하여 코드 세그먼트 간 인자 공유를 가능하게 합니다.
  • goto 문의 제한점: 현재 goto 문은 환경과 __return, __environment를 지원하지 않으며, 이는 향후 개선 방안 중 하나입니다.

5. 벤치마크 결과

CbC와 C의 성능을 비교한 벤치마크 결과에 따르면, CPS 변환된 소스 코드는 원래 함수 호출 버전보다 빠른 경우가 많습니다. 특히 IA32 아키텍처에서 GCC의 최적화 플래그를 사용할 때 더 좋은 성능을 보입니다.

6. 결론

CbC는 새로운 프로그래밍 패러다임으로, CPS 변환과 TCE를 활용하여 코드 효율성을 향상시킵니다. GCC에 통합된 CbC 컴파일러는 실용적인 사용을 위해 설계되었으며, 모델 체커와 OS API의 실행 사양 언어로도 활용 가능합니다. 향후 개선 방안은 GCC 버전 종속성 해결과 goto 문 지원 확장 등이 있으며, 이들 개선을 통해 CbC는 더욱 강력한 프로그래밍 언어로 발전할 것입니다.

CbC의 이러한 특징들은 기존 C와 다른 새로운 프로그래밍 패러다임을 제시하며, 특히 복잡한 시스템에서 코드 효율성과 정확성을 향상시키는 데 큰 도움이 될 것으로 예상됩니다.

📄 논문 본문 발췌 (Excerpt)

**전문 한국어 번역:**

CPS 이론이 성공한다면, 실제 영역에서도 효과적으로 작동해야 합니다. 우리의 아이디어는 간단합니다. 왜 현재 GNU C 컴파일러와 동일한 속도로 실행되는 연속 전달 스타일의 프로그래밍 언어를 만들지 못할까요? 완전한 새로운 프로그래밍 언어 대신, C의 하위 언어인 Continuation 기반 C(CbC)를 설계했습니다. CPS 변환 기법을 사용하여 C를 CbC로 컴파일할 수 있으므로, 일종의 후퇴 호환성을 확보하게 됩니다.

우리는 다양한 아키텍처에서 마이크로-C를 기반으로 CbC를 구현했으며, 여러 CbC 프로그래밍 실험을 시도했습니다. 여기서는 GCC 4.2.3을 기반으로 한 새로운 부분적 CbC 컴파일러 구현 [5]를 보고합니다 [1]. 이 컴파일러는 완전한 C 기능을 갖추고 있어 CbC와 C를 혼합하여 사용할 수 있으므로, 이를 후칭하여 CwC라고 합니다.

먼저 CbC 언어 개요를 살펴보겠습니다.

CbC의 기본 프로그래밍 단위는 코드 세그먼트입니다. 이는 서브루틴이 아닌 기능처럼 보이지만, 입력과 출력을 가지고 있기 때문에 유사합니다. C 구조체를 입출력 인터페이스로 사용할 수 있습니다. 이 예시에서 코드 세그먼트 f는 입력 a를 받아서 출력 b를 코드 세그먼트 g로 보냅니다. 코드 세그먼트 b는 반환 없이 다른 연속을 호출하기 위해 goto를 사용해야 합니다. CwC 언어에서는 모든 제어 구조가 허용되지만, CbC의 경우 if 문만 사용하는 것으로 제한합니다. 이는 C를 CbC로 변환하는 데 충분하기 때문입니다. 이 경우 코드 세그먼트는 하나의 입력 인터페이스와 여러 출력 인터페이스를 가집니다 (그림 2).

__code 및 매개변수화된 글로벌 goto 문은 Continuation 기반 C의 확장입니다. 이러한 문을 C에서 직접 작성하는 것은 불가능합니다. 일반적으로 어셈블리 언어의 도움이 필요하며, 이는 물론 포터블하지 않습니다. 하지만 CbC에서는 이러한 것을 쉽게 작성할 수 있습니다. 왜냐하면 CbC는 C 스택 프레임 뒤에 숨겨진 정보가 없기 때문입니다. 스레드는 단순히 스케줄러로 이동합니다: goto scheduler(self, task_list); 스케줄러는 작업 큐에 있는 다음 스레드에 제어권을 넘깁니다. 물론 시뮬레이터이지만, 구현이기도 합니다. CPU 리소스 API가 있다면, CbC에서 실제 다중 CPU 스케줄러를 작성할 수 있습니다. 이는 C에서는 불가능한 일입니다. 왜냐하면 C는 스케줄러로 전환하기 위해 숨겨진 스택에 접근할 수 없기 때문입니다. CbC에서는 모든 것이 보이기 때문에 스레드 전환이 매우 쉽습니다.

이는 CbC를 OS API의 실행 사양 언어로 사용할 수 있음을 의미합니다.

스케줄러를 CbC로 작성할 수 있다면, 동시 프로그램의 모든 가능한 상호작용을 열거할 수 있습니다. 우리는 CwC에서 모델 체커를 구현했습니다. CbC는 자기 검증 언어가 될 수 있습니다 [7].

SPIN [3]은 매우 신뢰할 수 있는 모델 체커이지만, PROMELA라는 특수 사양 언어를 사용해야 합니다. 우리는 직접 PROMELA를 구현 언어로 사용할 수 없으며, 동시 실행 의미론, 특히 통신 포트를 포함하는 것을 공부하기가 약간 어렵습니다.

실제 프로그래밍 언어에 대한 다른 종류의 모델 체커도 있습니다. 예를 들어, Java PathFinder [2]는 JVM(Java Virtual Machine)을 상태 공간 열거를 위해 사용합니다. 이는 때때로 매우 비쌉니다.

CbC에서는 상태 열거기가 CbC로 작성되며, 동시성 의미론은 CbC 자체에 내장되어 있습니다. 또한 이는 구현과 매우 가깝습니다. 실제로 CbC는 구현 언어로도 사용할 수 있습니다. 열거기는 애플리케이션 자체에 작성되므로, 애플리케이션 특정 방식으로 추상화하거나 근사화를 수행할 수 있습니다. 물론 JVM API를 처리하는 것도 가능합니다.

CPS 변환된 CbC 소스 코드를 검증에 사용할 수 있지만, 모든 코드를 변환할 필요는 없습니다. 왜냐하면 CwC는 모든 C 구성 요소를 지원하기 때문입니다 (하지만 C++은 아닙니다… 이론적으로는 cfront 변환기를 사용하여 가능하지만, 어려울 것입니다).

현재 GCC 구현을 갖춘 CbC가 있습니다. 이 컴파일러는 매우 빠릅니다. 많은 인기 있는 언어들은 C 위에 구현되어 있습니다. 그 중 일부는 바이트코드 인터프리터에 매우 큰 스위치 문을 사용합니다. 우리는 이러한 것을 사용하지 않습니다…

CbC(Control-Based Code)와 GCC(GNU Compiler Collection)에 대한 연구

CbC의 언어적 특성:

…(본문이 길어 생략되었습니다. 전체 내용은 원문 PDF를 참고하세요.)…

📸 추가 이미지 갤러리

cover.png

Reference

이 글은 ArXiv의 공개 자료를 바탕으로 AI가 자동 번역 및 요약한 내용입니다. 저작권은 원저자에게 있으며, 인류 지식 발전에 기여한 연구자분들께 감사드립니다.

검색 시작

검색어를 입력하세요

↑↓
ESC
⌘K 단축키