[Chapter1] 프로그래밍 언어부터 프로그램 실행까지, 이렇게 진행된다

[sunhpark42]

감상평을 남겨주세요~!
6/8 11시 전까지!

[yunseorim1116]

[링커]
컴파일러만 들어봤지 '링커' 라는 개념은 처음 들어봤다. 대상 파일 여러 개를 하나로 묶어 하나의 최종 실행 파일을 생성한다.
컴파일러와 링커는 ( 기록자 & 참조자 ) 같다 .

[라이브러리]
동적 라이브러리, 정적 라이브러리 개념이라던지 책에서 나오는 내용만으로는 이해하기가 어려워서 부가적인 설명이 필요했다.
먼 옛날 옛적에는 이런식으로 소스 코드를 배포해서 라이브러리를 사용했구나
install해서 npm으로 가져오는 것과는 다른 개념이라.. 신기했다!

https://github.com/gypified/libmp3lame/blob/master/INSTALL
예시 레포 ..
이런식으로 소스코드를 통으로 include해서 사용했다고 한다.

+++)로 리눅스에 기본으로 설치된 동적/정적 라이브러리를 첨부합니다
사진제공: 사수님!

[추상화]
추상화란 결국 복잡한 것을 간단하게 만드는 것,
역할을 분담하기 위한 것
이라는 생각이 들었다.

[전체적인 감상평]
c언어 기반이라 이해하기가 js로 처음 개발을 시작한 나에겐 조금 어려웠다. cs 지식을 공부해본적이 거의 없는 나에게 꼭 필요한 책이라는 생각이 들었다!
다만 비유적인 표현이 더 헷갈리기도 했다.

낯선 개념들이 많아서 꾸준히 읽고 복습해야겠다.

1장 공부 후기

매우 만족

[yunseorim1116]

저도 1장 정리했습니다! ^ㅁ^

[ella-yschoi]

감상평

📝 내 코드는 어떻게 실행되는걸까?

1장 내용을 참고해 블로그 포스팅을 해보았습니다.
되도록 책보다 더 쉽게 풀어 쓰려 했고, 책에 없는 자료들도 찾아보고 하니 이해가 잘 되더군요.
조금 오래 걸렸지만.. 단순 요약 정리보다 저만의 언어로 쓰니 효과적이었던 것 같아 다음에도 도전..!

나누고 싶은 이야기

평소 코드가 어떻게 동작하는지, 내가 쓴 코드를 컴퓨터가 어떻게 인식할 수 있는지 궁금했어요.
또한 개발자라면 이런건 알아야지 생각했고요.
여러분은 개발하면서 로우레벨 개념이 도움된적이 있었나요? (근데 생각보다 흔하진 않을 것 같아요 🫤)

[hanana1253]

와 국제통용어 영어로 인터프리터를 설명하다니 엄청난 비유네요

[ddongule]

1장 감상평

프로그래밍을 하면서 항상 궁금했던(하지만 게을러서 핑계를 대며 찾아보지는 않았던) 내용들에 대해 다루고 있어서 매우 흥미로웠다.
사실 몇번 찾아보기는 했었지만 항상 어려운 단어들에 막혀 이해를 포기했던 내용들을 시원하게 알려주어서 왕 좋았다.
물론 100% 이해했다고 생각하지는 않지만(1장 뒤로 갈수록 .. ㅎ.. 어려웠음), 천재 작가와 천재 번역가 분의 합작으로 진짜 이정도로 쉽게 읽힌다고?!! 라고 생각하면서 읽었다. 갓샤오펑님 갓진호 번역가님 최고에요 🥹 적게 일하고 많이 버세요
제발 2장 이후로도 쭉 재밋길 ..ㅎ. ..

저두.. 정리해봤어요 🥹

1.1

내가 작성한 코드를 컴퓨터가 어떻게 인식하지?

1. 스위치 ON / OFF → boolean 논리 → 이걸 기계로 만들면?
2. CPU (0, 1) 등장
   • 데이터를 다른 곳으로 옮기고 연산한 후 다시 다른 자리로 옮기는 작업만 할 수 있음
   • 인간보다 훨씬 빠름
   • CPU가 조금 더 똑똑하니깐.. 인간이 CPU의 언어로 CPU와 대화함
   • 인간이 수치심 느낌
   • CPU에 대해 조금 더 파헤침 (CPU는 가산 명령어, 점프 명령어 등 몇가지 명령어만 실행할 수 있음)
   • 기계어와 해당 특정 작업을 대응시켜 기계어를 인간이 이해할 수 있는 단어와 대응시키자! → 이걸 언어로 만들면?
3. 어셈블리어 등장 (low level language)
   • 인간이 이해할 수 있는 단어와 대응은 시켜놨지만 아직 세부사항에 신경은 써줘야 함
   • ex) 물 한잔 줘 → 오른쪽 다리를 들고 어쩌고 수도꼭지를 틀고 어쩌고 반복하고 어쩌고..
   • 고수준 언어의 필요성 느낌 (추상적으로 표현해도 알잘딱깔센으로 수행하는 그런..)
   • ↑ 예시에 나온 세부사항을 보니 규칙과 패턴, 그리고 단도직입적인 명령어(문(statement))들이 잔뜩 있음
   • 또, 세부사항(매개변수(parameter))에 죄금 차이가 있고 계속 반복됨 → 하나의 코드로 묶음 (함수 탄생)
   • 문 안에서 실행되는 코드들이 계~속 반복되면? 그것은 재귀
   • 컴퓨터가 재귀를 이해하도록 만드려면? 구문 트리(Syntax tree)를 만들면 됨
   • 자식 → 부모로 계속 기계어 번역을 하다보면 전체를 번역할 수 있게 됨
   • 이걸 하는 친구가 바로 컴파일러 (고-급 프로그래밍 언어)

     Syntax (구문): 프로그래밍 언어에서 문법적으로 올바른 프로그램을 작성하기 위한 규칙과 구조. 구문은 프로그램의 형태와 구성을 정의합니다.
     Statement (문): 프로그래밍 언어에서 실행 가능한 단일 명령이나 명령 집합. 각 문은 특정 작업을 수행하며, 구문 규칙에 따라 작성됩니다.
   

4. 해석형 언어 탄생
   • 세상에는 다양한 하드웨어사에서 만든 다양한 CPU가 존재
   • 그럼 각각 CPU들은 서로 실행할 수 없음 ㅠㅠ
   • 하지만 표준어 명령 집합을 정의하고 만들어서 사용한다면? 가능 ㅎㅎ
   • 이걸 하는 친구의 이름은? 가상 머신(virtual machine)이고 별명은 인터프리터(interperter)임
   • 요 내용을 바탕으로 C, C++, Python, JAVA 등의 언어들이 탄생!

      정리) 
         개발자가 프로그래밍 언어를 특정 구문 형태에 맞추어 작성 
         → 컴파일러는 구문을 분석해 구문 트리로 만듦 
         → 이 구문 트리를 기계 명령어로 번역 
         → CPU로 직접 넘김 or 바이트 코드(byte code)로 변환 후 가상 머신에 넘김 
         → 실행
   

1.2

컴파일러 (번역기 / 텍스트 처리 프로그램)

1. 컴파일러: 고수준 언어를 저수준 언어로 번역하는 프로그램
   • 개발자가 저장한 코드 텍스트 파일(소스 파일 source file)을 컴파일러에게 주면, 컴파일러는 실행 파일 형태로 내보냄
   • 이 실행 파일이 CPU가 직접 실행할 수 있는 기계 명령어를 나타냄
2. 그럼 어케 번역하누?
   • 1. 텍스트 파일(소스코드)를 돌아다니며 모든 토큰을 찾아냄 (토큰: 항목 + 정보 결합) → 이 과정을 어휘 분석(lexical analysis) 라고 함
   • 2. 바뀐 토큰은 아무 소용 없음. 개발자가 전달하고자하는 토큰 의도를 해석해서 표현해야 함
   • 3. 구문에 맞추어 토큰을 해석하는 과정을 파싱(parsing)이라고 함
   • 4. 해석된 구조는 트리로 표현할 수 있음
     • → 여기까지 이 트리를 생성하는 전체 과정을 구문 분석 이라고 함
   • 5. 이 구문 분석으로 만들어진 구문 트리가 이상이 없는지 확인해야 함(의미 분석(semantic analysis))
   • 6. 의미 분석이 끝나면 중간코드(IR Code)를 생성함
     • 중간 코드에 추가적인 최적화가 진행되기도 함
   • 7. 중간 코드를 어셈블리어 코드로 변환
   • 8. 어셈블리어 코드를 기계명령어로 변환
3. 변환 끝! 근데 각 소스 파일마다 각각 대상 파일이 있네? 합치고 싶음 → LINK(링크)
   • 대상 파일을 병합하는 작업
   • 링크를 담당하는 프로그램은 링커(linker)

1.3

링커

1. 링커: 컴파일러가 생성한 대상 파일 여러개를 하나로 묶어 하나의 최종 실행 파일을 생성

   • 예시) exe 파일, elf 파일 등

2. 링커가 하는 일

   • 1. 종속성이 올바르게 설정되어 있는지 (인터페이스 구현이 종속된 모듈에서 사용가능한지) 확인
     • 우리가 참조하고 있는 외부 심벌(external symbol)에 대한 구현이 단 하나만 있어야 함
     • 그러면 링커는 이를 찾아내 연결하는 작업(심벌 해석(symbol resolution))을 함
       • 대상 파일에서 참조하고 있는 모든 외부 심벌마다 대상 정의가 반드시 존재하는지, 단 하나만 존재하는지 확인
   • 2. 재배치(relocation)
     • 특정한 소스파일에서 다른 모듈에 정의되어있는 무언가를 참조할 때, 컴파일 시점에는 무언가가 어느 메모리 주소에 위치할지 정확히 알 수 없음
     • 그걸 N으로 표시해두고 넘어가면, 링커가 실제 메모리 주소로 대체해줌

     Symbol (심벌): 전역 변수와 함수의 이름을 포함하는 모든 변수 이름을 의미
     - 지역변수는 아님. 모듈 내에서만 사용되어 외부 모듈에서 참조할 수 없기 때문
   

3. 링커가 관심을 갖는 것

   • 소스파일에 다른 모듈에서 참조할 수 있는 심벌이 있는가
   • 소스파일이 다른 모듈에서 정의한 심벌을 참조하는가
   • 이 정보들은 컴파일러가 링커에게 알려줌!
     • 컴파일러가 만든 대상파일에는 명령어부분 + 데이터부분이 모두 있음
     • 컴파일러가 외부 심벌 정보를 기록하는 표를 심벌 테이블(symbol table) 이라고 함

4. 정적 라이브러리

   • 소스파일 여러개를 미리 개별적으로 컴파일하고 링크해 정적 라이브러리로 생성 가능
   • 소스파일마다 단독으로 컴파일함
   • 이후 실행파일을 생성할 때에는 자신의 코드만 컴파일, 미리 완료된 애는 그대로 실행파일에 직접 복제
     → 디스크와 메모리 낭비 가능! 🗑️ → 동적 라이브러리 사용해봐라
   • 실행 시점: 컴파일 단계에서 실행 파일에 복사됨

5. 동적 라이브러리 (공유 라이브러리 / 동적 링크 라이브러리)

   • 사용 방식과 실행 시점이 정적 라이브러리와 다름

   • 실행 파일에 라이브러리 내용을 모두 복사했던 정적 라이브러리와는 달리, 참조된 동적 라이브러리의 필수 정보만 실행 파일에 포함
     → 크기를 확실히 줄일 수 있음

     • 이 정보들은 동적 링크가 일어날 때에 사용됨

   • 실행 시점: 동적 링크는 실제 프로그램의 실행 시점까지 미룸

   • 1. 프로그램이 메모리에 적재될 때 동적 링크가 진행
   • 2. 프로그램이 먼저 실행된 후, 프로그램의 실행시간(runtime) 동안 코드가 직접 동적 링크를 실행

   • 장점

     • 프로그램의 업그레이드와 버그 수정을 매우 쉽게 만들어줌
     • 메모리 적재와 디스크 저장에 필요한 리소스 절약
     • 여러 언어를 혼합하여 개발할 때 유용 (빨라야 하는건 C++ 사용하고 나머지는 Python 사용)
     • 코드의 재사용 효율 올라감
     • ex) 플러그인

   • 단점

     • 프로그램의 적재되는 시간 또는 실행 시간에 링크되기 때문에 성능이 죄금 떨어짐
     • 동적 라이브러리의 코드는 임의의 메모리 절대 주소로는 참조할 수 없음
     • 적재할 때 동적 링크를 수행하는 프로그램은 실행 파일로만은 실행이 불가능

6. 링커는 어떻게 변수의 실행시간 메모리 주소를 미리 알 수 있을까?

   • 가상 메모리 (virtual memory)
     • 물리적으로 존재하지 않는 가짜 메모리
     • 링커는 가상 메모리를 사용함으로써 링커는 프로세스 메모리 구조를 미리 알 수 있음
     • 실제 메모리 주소는 신경안씀 ㅋ

    가상 메모리의 기본 원리
     - 모든 프로세스의 가상 메모리는 표준화 되어있고 크기가 동일
     - 프로세스마다 영역의 크기가 다를 수는 있지만 배치 순서는 같음
     - 실제 물리 메모리 크기와 가상 메모리 크기는 관련 없음
     - 물리 메모리에는 힙 영역, 스택영역 등 영역 구분이 존재하지 않음 (가상 메모리에는 구분됨) / 운영체제마다 조금씩 다를 순 있음
     - 모든 프로세스는 자신만의 페이지 테이블을 가지고 있어서 동일한 가상 메모리 주소에서 서로 다른 내용을 가져올 수 있음
   

추상화 부분은 호로록이라 넘어갔어요 ㅋ 우하하

[hanana1253]

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 갑자기 작가와 번역가 축복 ㅋㅋㅋ 넘웃겨용

[iborymagic]

감상평:
웬만한 다른 개념들은 한 번 쯤은 다 들어봤는데, 링커라는 몰랐던 새로운 개념을 알게 되었읍니다..
나머지도 사실 말 그대로 들어만 봤다는 것이지.. 잘 모르긴 합니다..
어쨌든 링커에 관해 읽으면서 자바스크립트 번들러가 떠올랐읍니다..

모듈간의 의존 관계를 분석하여 브라우저가 알아먹는 하나의 큰 파일로 합쳐주는 번들러와
대상 파일들 간의 의존 관계를 분석하여 실행 파일을 만들어주는 링커.. 그런 느낌이랄까요..

웹팩에서 모듈 간의 중복을 방지하기 위해 빌드 파일과 원본 파일을 연결해주는 소스맵을 사용하는 것과
가상 메모리와 물리 메모리를 연결해주는 페이지 테이블을 사용하는 것 등등.. 그런 느낌이랄까요..

컴퓨터 구조에 관해 공부하다보면 자바스크립트의 많은 개념들이 새로 생긴 것들이 아니라
뭔가 기존에 존재하던 것들에서 아이디어를 차용해왔구나 하는 생각이 종종 드는 것 같습니다..

사실 뭐 어거지로 연관짓긴 했지만.. 번들러를 처음 만들 때 사람들의 머릿 속에 들어있던
저런 컴퓨터 구조 지식들에서 자연스럽게 번들러의 구조가 튀어나온게 아닐까.. 생각합니다..
결론은.. 온고지신.. 아는 것이 힘이다.. 그런 것들을 느꼈읍니다..

저는 읽기에 급급해서 따로 정리는 안했습니다.. 허허.. 수고하십쇼..

[hanana1253]

오 뭔가 깊이있는 감상평이네요. 그와 별개로 점을 꼭 두개씩 찍어주는 게 묘한 매력이 있는 글입니다.

[sa02045]

감상평

책에 나온 개념들이 프론트엔드에서는 어떻게 적용되었는지? 곱씹으면서 읽었습니다 🔥

• 타입스크립트 -> 자바스크립트 컴파일 과정은?
• 자바스크립트는 엔진에서 어떻게 동작하는지?
• JIT 컴파일이란 뭔지?
• 마이크로 프론트엔드 module federation도 넓게 보면 동적 링크와 비슷해보이는 개념이지 않을까
• 번들러는 어떻게 동작할지? (위에서 현철님이 말씀해주신)

그리고 애매하게 알고 있었던 개념과 잘 몰랐던 개념을 다시 찾아보면서 제대로 되짚어보았습니다.

• syntax tree의 종류: AST vs CST
• 자바스크립트는 인터프리터 언어인가? (또는 인터프리터 언어라고 부를 수 있는가?)
• 자바는 컴파일 언어인가? 인터프리터 언어인가?
  • 자바는 오로지 컴파일만 하는 언어인줄 알았는데 아니였군요
• 자바 중간 코드(byte code)는 무엇인가?
• 인터프리터 언어가 컴파일 언어에 비해 가지는 장점은?

정리 링크: https://victorywin.notion.site/49f4b93f4d6341d78ff0a2c90844bcfc

[sa02045]

1분만에 푸는 OX 퀴즈 https://docs.google.com/forms/d/114jxjFHJzeu55i3qTsab14NQVtW4eeseSskYPiKR4Hw/edit

[ddongule]

노션 접근이 안돼요 흑흑흑

[sa02045]

헉 수정했습니다

[thgr8ganzi]

감상평

1. 컴퓨터의 논리적인 흐름을 다시 인식할수 있었습니다.
2. 링크 와 심벌이라는 새로운 개념을 들었습니다.
3. 링커의 구조가 파일들을 모아서 하나의 수행파일을 만들고 각각의 주소를 참조하는게 역색인 이라는것과 개념이 비슷하지 않나 생각이 들었습니다.
4. 요즘??? 핫한 가상 메모리라는것을 봐서 반가웠습니다. 좀 더 책을 읽어보고 싶은 생각이 들었습니다.

[hanana1253]

감상평

들어가며: 쓰잘데기 없는 TMI

• 지지난주에 시작할 줄 알고 미리 많이 읽어두었던 덕에 이번 주는 마음이 편-안. 앞으로도 예습을 미리 하면 참 좋겠다.
  • 그러나 또 끝까진 못함.. 열심히 하자.
• 깊이 있는 내용을 나름 쉽게, 과하지 않은 비유로 설명해서 좋은 책이라고 느낌

1장을 읽으며

• 컴파일 과정에 대해 이렇게 하나하나 알게 되니까 잘 몰라서 두려웠던(?) 프로그래밍이 조금은 친근하게 느껴졌다.

  프로그래머가 작성한 코드는 실제로 문자열 나열에 지나지 않으며, 텍스트 파일에서 볼 수 있는 단락과 다를 바 없습니다.

• 예전에 파이썬이 컴파일 언어인지 인터프리터 언어인지 발표 준비하면서 깊이 공부했던 내용들이 생각나 감회가 새로웠다.
• 지금은 인간이 읽고 이해할 수 있는 방식으로 프로그래밍 언어가 진화했지만, AI가 직접 인간의 요구사항을 받아 프로그래밍을 하는 시대가 온다면 인간이 이해할 수 없는 언어, 또는 컴파일 없이 기계어로 바로 프로그램을 만드는 시대가 오지 않을까 라는 상상의 나래를 펼쳐본다. (실제로도 데이터를 통해 학습을 시켜 나오는 결과는 그 수식을 쉽사리 밝히기 어렵다고 듣기도 했고...)
• 코드 영역, 데이터 영역, 스택 영역 등은 내가 영원히 이해하지 못할거라 생각했는데 뜻밖에 링커에서 이를 설명해주다니... 신난다.

질문거리

• p.54 undefined reference to 오류는 함수 정의를 못 찾았을 뿐 컴파일 오류는 아닌건가?
• p.60 참조하는 라이브러리가 여러개라면?

정리

1장 정리 노션

[sunhpark42]

감상평

1. 전공 수업에서 배웠던 내용을 복습하는 것 같아서 좋았다. 그땐 분명 이해하기 어려웠던 것 같은데.. 이런 책이 대학생때 있었다면...
2. 최근에 한글로만 자바스크립트 코드 짜보겠다고 비슷하게 파싱하고, 사전 만들어서 파싱 돌린적이 있는데 하다 말았지만 다시 해볼까 싶기도 하다.
3. 늘 생각하지만 On/off(1과 0)의 전자신호가 이렇게 빠르게 도는게 신기하긴 하다. 사실상 책 1장에 있는 내용들이 엄청 빠른 속도로 연산되고 있다고 생각하면 그것도 그것나름 대단한 것 같기도.

[chloe-codes1]

1장 감상평

링커 부분이 인상깊었다. JVM 환경에서 개발하면서, 링커의 역할을 JVM의 classloader가 수행하고 있는데 링커의 동작방식을 알 수 있어서 좋았고, classloader와 비교해볼 수 있어 좋았다.

JVM의 classloader

Classloader는 class를 동적으로 로드하고, 검증하고, 심볼릭 레퍼런스를 실제 메모리 주소로 재배치하고, 필요한 경우 클래스를 초기화 한다.
즉, 전통적인 링커가 수행하는 역할을 JVM에서는 classloader가 수행한다!