프로그램과 실행 1 : 실행, 프로그램, 프로세스, 컴파일



실행


컴퓨터 혹은 Virtual Machine이

컴퓨터 프로그램의 코드로 작성된 Logic을 수행하는 행위.




프로그램, 프로세스


예를 들어,

'A 프로그램'은 하드디스크 등의 매체에 바이너리 형식의 파일로 저장되어 있다가

사용자가 실행시키면 메모리로 적재되어 실행된다.

이 과정은 OS가 관여한다.

OS가 'A프로그램'을 실행시키면 'A프로그램'의 1개의 인스턴스가 생성되는데

이를 프로세스라고 부른다.

프로세스화(인스턴스화) 된 이후로는 CPU의 자원을 점유하면서 코드에 명세된 작업을

수행한다.

1개의 프로그램에서 여러개의 인스턴스가 생성될 수 있고,

이는 곧 여러개의 프로세스가 생성되는 것을 말하며

OS는 한 프로그램에서 생성된 여러개의 프로세스를 PID ( Process ID )로 관리한다.

프로세스는 OS가 관리하는 가장 기본적인 단위이다.

프로세스는 Process를 기준으로 프로그램 수행 및 스케줄링을 조정한다.







컴파일


컴파일 특정언어를 다른 특정언어로 번역하는 과정이다.




어셈블리어는 기계어의 바로 상위단계 언어이다.

어셈블리어를 기계어로 번역하는 과정을 컴파일

기계어를 어셈블리어로 번역하는 과정을 역컴파일 과정이라고한다.




초기 컴퓨터 프로그램들은 어셈블리어로 작성되었다.

어셈블리어는 하드웨어가 인식할 수 있는 기계어로 바꾸어주어야

어셈블리어로 작성한 프로그램 로직을 수행할 수 있다.

모든 프로그램 언어가 마찬가지이다.




서로 다른 CPU 아키텍처가 등장할 때마다 매번 똑같은 프로그램을

서로 다른 어셈블리어로 작성하는 비용이 커지면서,

고급 프로그래밍 언어의 필요성이 대두되었다.




이를 테면 같은 계산기 프로그램을 판매하려면,

Intel이 제조한 CPU

AMD가 제조한 CPU

ARM이 제조한 CPU...등

갖가지 하드웨어 제조사의 명령어셋에 맞게 다시 작성해야했다.




프로그램 제조사 입장에서는 상당히 비용과 시간이 드는 작업이며,

이는 게임업계도 마찬가지였다.




당시의 각 소프트웨어 제조 업체들이

어떻게 다양한 하드웨어에 맞게 프로그램을 출시했고

판매 전략을 세웠는지 스토리를 들어보면 재미있다.



그러나, 초기 컴퓨터 하드웨어의 메모리 크기가 너무 작아
컴파일러의 등장에 기술적 장애물이 되었다.




컴파일러 vs 인터프리터


원시 코드 -> 목적 코드 로 변환(컴파일)하는 언어 번역 프로그램.

고급 언어 -> 저급 언어 로 변환(컴파일)하는 언어 번역 프로그램.

컴파일러는

사람에게 이해하기 쉬운 형태의 고수준 언어로부터

실행가능한 기계어 프로그램을 만든다.




컴파일러는 소스 프로그램을 읽어서 즉시 결과를 출력하는 인터프리터와는 구분된다.

Java는 java파일이 컴파일 된 후 JVM 위에서 실행되는 Compile언어지만

Python은 인터프리터 언어다.




Java는 바이트코드로 변환하기까지는 일반적인 컴파일 과정처럼 보이지만,

바이트코드를 JVM에서 해석하는 과정은 다르다.

ex) .java 파일 -> 컴파일 -> 바이트코드 .class 클래스 파일 -> JVM에서 해석




JVM에서 JAVA바이트 코드를 해석하는 부분은 JVM구조 글에서 다루겠다.

자바 바이트코드는 플랫폼에 독립적이며

모든 자바 가상 머신은 자바 가상 머신 규격에 정의된 대로 자바 바이트코드를 실행한다.




표준 자바 API까지 동일한 동작을 하도록 구현한 상태에서는

이론적으로 모든 자바 프로그램은

CPU나 운영 체제의 종류와 무관하게 동일하게 동작할 것을 보장한다.




그러나 현대에 들어 많은 인터프리터가 JIT 컴파일 등의 기술로 실시간 컴파일을 수행하므로

컴파일러와 인터프리터 사이의 기술적 구분은 사라져 가는 추세이다.




IDE

위 내용을 바탕으로 IDE의 역할을 간략하게 정리하면

- 소스 코드 -> 실행파일로 만드는 과정에서
- 전처리기 : 주석 제거, define과 같은 예약어 처리 등
- 컴파일러 : 소스 코드 -> 어셈블리 파일
- 어셈블러 : 어셈블리 파일 -> 목적 파일(obj)
- 링커 : 목적 파일을 연결하여 실행파일 생성


*참고1 MCU환경 환경에서 프로그램
Desktop이 아닌 임베디드 혹은MCU 환경에서 프로그램을 업로드 할 때는
보드의 사양에 따라 천차만별이지만 주로 USB Port를 사용하여
USB Serial 형태로 데이터를 전송한다.

MCU는 PC와 같이 넉넉한 전력을 제공 받을 수 없다.
때문에 보드 내에서 MCU-MCU간 혹은 MCU-센서 간 통신에는
USB보다 단순한 프로토콜, 낮은 데이터 전송 대역 -> 저전력 특성을 가진
UART를 사용하는데 USB와는 인터페이스가 맞지 않으므로
USB-to-UART 브릿지가 필요하다.


USB-to-UART 브릿지는
USB 데이터 패킷을 순차적 데이터 스트림으로 바꿀 수 있고
그 역도 가능하다.

USB-to-UART 브릿지를 통해 MCU의 부트로더와 상호작용 가능하고
MCU의 부트로더가 작동하여 기계어 코드가 플래시 메모리에 쓰여진다. 


*참고2 USB, UART의 차이

아래 링크에 정리가 아주 잘 되어있다.
https://www.leadtekdisplay.com/what-is-the-difference-between-uart-and-usb-a-1347.html

가장 일상에서 볼 수 있는 특징으로 USB는

1. plug-and-play 
PC에 연결하면 운영체제가 자동으로 새로운 장치를 인식하여
파일 시스템 및 프로그램을 실행시키는 것

2. 충전 모드
특별한 데이터 통신 없이 USB와 연결된 기기의 충전만 하는 모드
와 같이 UART에 없는 특징도 많다.

이를 지원하기 위해 선로 또한 4개(power, ground, data line x2 )
이지만 UART의 경우(TX-RX)의 2개이다.



출처

https://ko.wikipedia.org/wiki/컴파일러

https://ko.wikipedia.org/wiki/자바 가상 머신

댓글

댓글 쓰기

이 블로그의 인기 게시물

Blogger 커스터마이징 : CSS 수정 (sticky-header)

이미지
sticky-header, centered-top-container sticky animating 삽질1 google blogger의 템플릿 테마중 하나인 Contempo에서는  스크롤을 어느 정도 내린 상태에서 다시 올리면 상단의 검색창이 내려와서 스크롤을 다시 내릴 때까지 유지된다. (이 "어느 정도"에 해당하는 값은  기본 테마의 javascript에 코딩 되어있을 것으로 추측한다.) css 수정 후 이 부분에 문제가 생겨서 내릴때에도 올릴 때에도 계속 검색창이 내려오고 사라졌다를 반복한다. < 페이지 최하단 모습 > 데이터를 색인하여 찾을 때는 유용한 기능이라고 생각하지만 검색 기능은 이미 블로그 최상단에 존재한다. 따라서 해당 기능을 제거하기로 했다. scroll event를 감지하고 그에 따라 html이나 css문서를 수정하는 작업은  javascript가하는 일이다. html 편집기를 통해 코드를 살펴본 결과 이 javascript 코드는 외부 cdn 서버에서 가져오는 것 같다.  javascript 코드를 직접 건드려야되나 싶어서 구글링 해 본 결과 간단하게 css 코드를 수정해서 없앨 수 있었다. sol) sticky-header 제거 https://joshua-dev-story.blogspot.com/2020/04/blogger-remove-sticky-header.html FE, Publishing 에서는 '고정 헤더'라고 부르고 있는 이 태그의 css를 수정하면 된다. display 옵션을 none으로 바꿔서 기존 요소의 block을 전부 없애고 기능까지 해제해버리는 것. 이 sticky header를 보이지 않게하는 방법은 opacity를 0으로 만들거나 visibility를 hidden으로 할 수도 있지만 display : none 옵션이 가장 확실해보인다. 수정 후 여전히 scroll 이벤트에 따라 DOM의 변경이 일어나는 것 같지만 sticky header는 더이상 보이지 않는다. 삽질2...
Read more »

노마드코더 개발자북클럽 Clean code 완주, 독후감

이미지
짧은 기간 동안 Java로 쓰여진 클린 코드 책을 읽으며 코드를 짤 때 더 정성을 들여 쓰는 습관을 들였다. 당장 작동하는 코드보다는 유지 보수가 편한, 수정보다는 확장을 할 수 있는, 잘 읽히는, 정직하고, 하나의 일에 몰두하는 그런 코드를 짜려고 했다. 퇴근을 하고 책상 앞에 앉으면 오늘 작성했던 class가 아른거리고 과연 이게 최선이었을까 생각하게 되었다. ========================================================== 책을 읽으면서 대부분 공감하고 고개를 끄덕일 수 있었지만 좋은 코드를 쓰는 법을 아는 것과 좋은 코드를 쓰는 것에는 큰 차이가 있다. 좋은 코드를 쓰는 법을 알기만 해서는 그저 말로만 잘난 체 할 수 밖에 없을 것이다. 좋은 코드를 쓰는 사람은 코드 리뷰를 하며 시스템 변경에 유연한 구조인지 고민한다. 확실히 후자가 더 고된 작업이지만 견고한 프로덕트를 만드는, 실체가 있는 실력이 는다고 생각한다. ========================================================== Java기 반의 코드를 이해하기는 쉽지 않았지만 확실히, Java가 객체 지향적인 장치가 많다고 느꼈다. Python 웹 개발자라면 당장 객체지향 원칙이나 디자인 패턴을 익히기 보다는 웹 애플리케이션 프레임워크를 익히기를 추천한다. 그 중에서도, FastAPI를 추천하는데 Layer와 Depends를 사용한 설계 장치를 사용하며 실전 감각을 기르면서 객체지향적인 사고를 할 수 있다. 혼자 상향식으로 배우기 버겁다면 Framework의 규칙을 따르며 배워나가는 것이 효율적이라고 생각한다. 그리고 이렇게 해야 실전 감각을 느낄 수 있다. ========================================================== 클린 코드 북클럽 챌린지 덕분에 오늘도 나는 하나의 괴이한 모듈을 처리했다. util 패키지의 fileutil이라는 모듈인데 온갖 잡다한 파일 처리를 다 도맡아 하...
Read more »

노마드코더 개발자북클럽 Clean code TIL 7 : 7장. 오류 처리

이미지
       오늘 TIL 3줄 요약 논리가 오류 처리 코드와 뒤섞이지 않으므로 오류가 발생하면 예외를 던지는 편이 낫다. 확인된 예외는 OCP를 위반한다. 하위 단계의 코드 변경이 상위 단계 메서드 선언부 전부를 고치게 만들기 때문이다. 외부 라이브러리, API 가 던지는 예외를 전부 잡아내지말고 감싸는 클래스, Wrapper를 사용하여 의존성을 줄이자. 가능하다면, 예외 유형 하나로 오류를 구분하자. TIL (Today I Learned) 날짜 2025. 06.03 오늘 읽은 범위 7장. 오류처리 기억하고 싶은 내용을 써보세요. 오류 플래그, 호출자에게 오류 코드 반환하기  vs 예외 던지기. 에외를 지원하지 않는 프로그래밍 언어가 많았다. try-catch-fianally try 블록은 트랜잭션과 비슷하다. catch 블록에서 예외 유형을 좁혀라. 확인된 예외는 OCP를 위반한다. 하위 단계의 코드 변경이 상위 단계 메서드 선언부 전부를 고치게 만들기 때문이다. 예외에 의미를 제공하라. 특히, 애플리케이션이 로깅을 제공한다면 catch 블록에서 오류를 기록하도록 충분한 정부를 넘겨준다. 오류를 처리하는 대부분의 로직. 1) 오류를 기록하고 2) 프로그램을 계속 수행해도 좋은지 확인한다. 정상 흐름부터 정의하라. NULL을 반환하지 마라. 호출자에게 문제를 떠넘기는 것이다. NULL확인이 누락된 코드를 고치는 게 아니라 특수 사례 객체를 통해 NULL확인을 만들지 마라! NULL을 전달하지 마라. null을 전달받는 쪽에서 처리하지 말고 null 을 전달하는 쪽에서 전달을 막아라. 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요 NULL을 확인할 일 자체를 최소화해야겠다. NULL대신 적합한 기본값을 사용하자. 깨끗한 코드는 가독성도 좋아야하지만 안전성이 높아야한다. 그리고 이 둘은 시간-공간 개념처럼 Trade off되는, 상충되는 개념이 아님. 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면...
Read more »