1교시 시작
git 저장소 복제와 디렉토리
백업된 파일 + 변경 기록
로컬로 clone
clone해서 서버에 있는 걸 그대로 가져옴
그리고 가져오게 되면
사용자 홈 : $ USER_HOME
내 전용공간
내 사용자 홈 : C:\Users\bitcamp
사용자가 전용하는 폴더
자바 홈 폴더
자바가 전용하는 폴더
깃 홈
git 폴더 밑에 clone 하는 거
백업된 파일 + 변경 기록
.으로 시작한 건 설정 관련된 파일이 들어 있다.
hidden folder, hidden file로 간주
유닉스에서 옴
objects가 백업파일
백업된 걸 꺼내주는 게 git client
변경된 사항만 추출해서 별도의 파일로 저장함
별도로 저장된 걸 합쳐서 리턴해줌
.git : 백업된 파일을 편집할 수 있도록 꺼낸다
작업 디렉토리
bitcamp-study : 저장소
.git : 깃 디렉토리
저장소 자체가 작업 디렉토리
저장소 안에 깃 디렉토리가 있다
작업하고 싶으면 git 디렉토리 안에 있는 걸 꺼내 checkout
작업한 걸 넣고 싶으면 commit
add / commit / push의 관계
로컬 리파지토리
Local Repo.
hello.txt 변경
스테이지
stage(백업명단)
① add : 백업명단에 등록
② commit : 작업 디렉토리에 있는 파일 중에서 백업명단에 등록된 파일을 Local 저장소에 보관한다.
commit 할 대상자를 stage 명단에 등록해야 됨
집에 가기 전에 Local Repo.에서 Server Repo.에 push
③ push : 로컬 저장소의 내용을 서버에 업로드한다.
작업 디렉토리에 있는 파일을 업로드하는 것이 아니다.
.git 폴더를 서버에 업로드 하는 거
인터넷이 안 되는 곳에서도 commit은 계속 할 수 있다.
로컬에서 이뤄지는 거라서
Local
Remote
push / pull, 충돌 및 병합
이미 서버에는 다음 버전의 파일이 있기 때문에 업로드 할 수 없다.
- 먼저 pull로 당겨서 서버의 변경사항을 가져온다.
- merge : 서버의 변경내용과 로컬의 변경내용을 합친다.
- add, commit
- push
git으로 수업 준비
학생 Server Repo.
Local Repo.
선생님거 가져와서 보기만 하기
강사님 지금거 서버에 올려주세요
pull로 당겨서 보기만 하기
선생님거 보고 내거 편집하고
C:\Users\bitcamp\git>git clone https://github.com/eomcs/eomcs-java.git
C:\Users\bitcamp\git>git clone https://github.com/eomcs/eomcs-docs.git
C:\Users\bitcamp\git>git clone https://github.com/eomjinyoung/bitcamp-20211108
선생님거 수정해버리면 지우고 clone 다시 받기
자바의 소스파일은 대문자로 시작한다
show recommendation
C:\Users\bitcamp\git>cd bitcamp-study
C:\Users\bitcamp\git\bitcamp-study>javac Hello.java
C:\Users\bitcamp\git\bitcamp-study>java Hello
Hello, world!
명단에서 뒤에 확장자 이런이런 것들은 제외해
파일이름이 .으로 시작하면 감춰버림
윈도우라서 보임
.으로 시작하면 주로 설정파일
일렬로 안 맞음
naver d2
https://github.com/naver/d2codingfont
https://github.com/naver/d2codingfont/releases/tag/VER1.3.2
D2CodingAll
한글 한 자가 영어 2자리랑 딱 맞음
.gitignore에 있으면 삭제조차도 무시됨
whitespace = space, tab, enter
java17 검색
google eclipse java style guide
https://github.com/google/styleguide/blob/gh-pages/eclipse-java-google-style.xml
Ctrl + S 누르면 다른 이름으로 저장 뜸
main
Ctrl + Space
통합 개발 환경
소스 코드 편집
실행 결과 출력
디렉토리 구조
디렉토리 안에 어떤 항목들이 있는지 간단하게 요약 정보까지 한 눈에 다 보여줌
=> 통합 개발 환경
이제 세팅이 끝남
Application 빌드와 실행
1. 인터프리터 방식
사람이 작성한 명령어
운영체제가 알 수 없는 명령어
중간에 해석기의 도움을 받아야 함
명령어를 해석해서 운영체제에게 전달하는 해석기의 도움을 받아야 함
해석기를 통해서 운영체제를 통해서 실행
해석기를 인터프리터라고 한다.
예) 자바스크립트 개발자가 명령문을 작성
Hello.js (명령문)
명령문 작성 언어 (programming language)
프로그래밍 : 컴퓨터가 해야 할 일을 기술하는 것
V8(자바스크립트 엔진)과 Node.js
자바스크립트는 CPU가 못 알아들음
V8 : 자바스크립트 인터프리터. 자바스크립트 명령문을 읽어서 운영체제를 통해서 실행을 하는 프로그램.
V8은 웹 브라우저를 만드는 데 기반을 제공하는 오픈 소스 자바스크립트 엔진이다.
구글 크롬 브라우저와 안드로이드 브라우저에 탑재되어 있다.
V8은 자바스크립트를 바이트코드(bytecode)로 컴파일하고 실행하는 방식을 사용한다.(JIT 컴파일)
JIT 컴파일(just-in-time compilation) 또는 동적 번역(dynamic translation)은 프로그램을 실제 실행하는 시점에 기계어로 번역하는 컴파일 기법이다.
구글 크롬에
V8 : 자바스크립트 엔진
크롬 브라우저에 WebKit이라는 엔진과 V8 엔진이 있음
WebKit : HTML을 처리, CSS 처리
V8 : 자바스크립트 처리
안타깝게도 V8 엔진이 웹 브라우저에 갇혀 있음
자바스크립트를 사용하려면 html 파일을 작성해서 script 태그 안에 자바스크립트 코드를 작성해야 된다는 문제점이 있다.
.html 파일 안에 script 태그 안에 넣어야 함
자바스크립트가 HTML에 갇혀있다.
자바스크립트를 자유롭게! => 그래서 등장한 게 Node.js
Node.js는 V8 엔진을 이렇게 만들었다
그래서 자바스크립트를 html에 갇히지 않고 .js 파일로 다이렉트로 실행
자바스크립트를 일반 프로그래밍 언어처럼 CLI 환경에서 바로 실행 가능!
Node.js가 따로 자바스크립트 엔진이 있는 게 아니라 기존에 크롬에서 제공해주는 V8 엔진을 그대로 가져가서 쓴다
다만 데스크탑 환경에서 바로 쓸 수 있도록, CLI 환경에서 바로 자바스크립트 코드를 실행할 수 있도록 만들었을 뿐임
Node.js
Node.js는 오픈 소스 JavaScript 엔진인 크롬 V8에 비동기 이벤트 처리 라이브러리인 libuv를 결합한 플랫폼이다. 다시 말해, JavaScript로 브라우저 밖에서 서버를 구축하는 등의 코드를 실행할 수 있게 해주는 런타임 환경이다.
이제 더 이상 HTML에 갇혀있을 필요가 없음
cmd 열고 node Hello.js 입력하면 실행됨
2. 컴파일 방식
개발자가 명령문을 작성한다
명령문 작성한 걸 번역기(compiler)를 통해서 기계어로 만든다
기계어를 운영체제에서 실행한다
기계어를 실행파일이라고 한다
예) C/C++ 개발자가 C 언어를 사용해서 명령문을 작성
Hello.c
C/C++ 컴파일러를 사용해서 번역을 하면 기계어가 만들어짐
.exe 파일이 만들어짐
운영체제에서 실행
기존의 방식과 차이점 : 컴파일 과정에서 문법 검사를 함. 또는 명령어 최적화도 함. 그리고 기계어를 바로 실행. 이런 이유로 인터프리터 방식보다 실행 속도가 빠르다.
근데 이런 장점만 있는 게 아니라 단점도 있음
단점 : 기계어로 바꾸기 때문에 OS나 CPU가 다르면 실행 불가!
운영체제나 CPU가 다르면 실행 불가
CPU와 명령어
① CPU마다 명령어가 다르다.
• intel CPU (ex.i7, i9, ...)
‐ Intel CPU가 이해할 수 있는 명령어로 작성해야 한다.
인텔에서 제공하는 명령문을 작성해야 한다
이 명령문은 인텔 CPU가 이해할 수 있는 명령어로 작성해야 한다.
• AMD CPU (ex.라이젠, ...)
‐ AMD CPU는 인텔 CPU 명령을 처리할 수 있게 만들었다.
‐ 인텔 호환 CPU라고 부른다.
‐ 인텔용 프로그램을 따로 변환할 필요 없이 그대로 실행 가능하다.
• ARM CPU (M1, M1 Pro, M1 Max, 삼성 엑시노스 등)
‐ 인텔 명령문 실행 불가
‐ ARM 명령문으로 작성된 걸 처리할 수 있다.
‐ ARM CPU가 이해할 수 있는 명령어로 작성해야 한다.
CPU와 OS
Windows 11 ------- 실행 가능 ------> Intel CPU
Windows 11 ------- 실행 가능 ------> AMD CPU
AMD CPU는 Intel CPU 명령을 처리할 수 있다. Intel CPU와 호환된다.
Intel CPU 명령을 그대로 실행할 수 있다.
인텔 CPU 기계어로 번역한 Windows 11는 Intel CPU에서도 돌릴 수 있고 AMD CPU에서도 돌릴 수 있다.
PC 조립할 때 AMD CPU를 장착해도 되는 게 이런 이유 때문임
AMD CPU는 Intel CPU와 호환하기 때문이다. (compatibility: 호환성)
Intel CPU 명령을 그대로 실행할 수 있다.
일을 할 사람이 알아들을 언어로 얘기해야지
CPU가 알아들을 수 있는 언어로 얘기해야지
CPU가 전기적 신호
전기가 들어가는 선
몇 번째 선에 전기를 흘릴 것인가
8088 CPU
전기적 신호를 정해놓음
근데 전기적 신호가 CPU마다 다름
다만 AMD는 인텔과 똑같이 동작하도록 만듦
그래서 AMD CPU를 인텔 호환 CPU라고 하는 거
ARM CPU
스마트 패드 같은 곳에 쓰기 적절함
ARM CPU
Surface Pro
microsoft arm laptop
SQ2 ARM가 장착된 컴퓨터에서는 Windows11을 못 깔아
ARM Windows를 따로 깔아야 됨
Windows 11 ------- 실행 불가능 ------> ARM CPU
CPU 명령어가 다르기 때문에 안 됨
ARM용 Windows 11을 따로 만들었고 그걸 실행해야 됨
‐ CPU 명령이 다르기 때문에 기존의 인텔용 윈도우를 ARM CPU에서 실행할 수 없다.
‐ 그래서 MS에서는 ARM용 Windows를 따로 제공한다.
CPU가 다르면 운영체제도 달라질 수 밖에 없다.
리눅스도 인텔용 리눅스가 따로 있고 ARM용 리눅스가 따로 있다.
CPU가 다르면 명령어가 다르고 명령어가 다르면 프로그램이 달라진다.
운영체제도 프로그램이기 때문에 달라지는 거
다만 AMD는 인텔 CPU와 호환. 인텔 CPU의 명령을 그대로 처리할 수 있음.
인텔용 Windows 11을 AMD CPU가 장착된 컴퓨터에 그대로 실행할 수 있음.
CPU가 다르면 명령어가 다르다.
따라서 CPU에 맞는 특정 CPU의 명령어는 다른 CPU에서는 실행할 수 없다.
같은 CPU / 다른 OS
왜 같은 CPU인데 운영체제가 다르다고 실행이 안 될까?
CPU가 같으면 명령어가 같잖아요.
format이 다름
정해진 포맷이 있으면 포맷대로 명령어를 작성해야
나열할 때 Windows 11의 포맷에 맞춰 명령어를 나열함
Windows 11의 기능을 사용
기계어가 인텔 CPU 명령어는 맞는데 리눅스가 원하는 포맷으로 명령어가 나열되지 않았다.
리눅스에 없는 윈도우 기능을 이용한 명령이 들어 있다.
‐ 인텔 CPU 명령어
‐ Windows 11의 포맷에 맞춰 명령어를 나열함
‐ Windows 11의 기능을 사용
같은 CPU를 사용해도 실행이 불가능한 이유
‐ 기계어가 인텔 CPU 명령어 ← ok
‐ 리눅스가 원하는 포맷으로 명령어가 나열되지 않았다.
‐ 리눅스에 없는 Windows 기능을 이용한 명령이 들어 있다.
윈도우로 작성된 게임을 리눅스에 설치할 수 없는 이유가 이거임
포맷이 다름
왜 같은 CPU를 쓰는데 운영체제가 다르다고 윈도우 프로그램을 리눅스에서 실행 못 하는가
왜 리눅스 프로그램을 윈도우에서 실행 못 하는가
기계어 명령을 나열하는 포맷(방식)이 있음. 그게 다른 거
그래서 같은 CPU여도 운영체제가 다르면 실행시킬 수 없다.
하필이면 그 프로그램이 Windows 11에 있는 기능을 사용
리눅스에서 실행해봐야 안 됨. 리눅스에는 그 기능이 없기 때문
그걸 떠나서 가장 근복적인 이유는 Windows 11의 포맷에 맞춰 명령어를 나열했기 때문이다.
운영체제마다 명령어를 나열하는 포맷이 다르다.
같은 CPU = 명령어가 같다
다른 OS = 명령어 포맷이 다르다
5교시 시작
CPU가 다른데 운영체제가 같으면 실행이 될까?
windows gcc 검색
다른 CPU / 같은 OS
다른 CPU = 명령어가 다르다
같은 OS = 명령어 포맷은 같다
운영체제가 같아도 CPU가 다르면 실행이 안 된다.
명령어를 작성 → 컴파일(번역) → 기계어(Intel CPU용 명령, Windows 11 포맷)
Intel CPU 기반의 Windows 11용으로 만든 기계어는 ARM CPU 기반의 Windows 11에서 못 돌아간다.
같은 CPU인데 왜 실행이 안 됩니까?
Intel CPU + Mac OS
Intel CPU + Windows
Intel Mac용 JDK를 설치해줘야 됨
Linux
• ARM
Archive : 압축을 푸는 방식
Package : install 방식
• Intel
Debian : 우분투 리눅스
RPM : 레드햇 리눅스
컴파일 방식 경험해보기
mingw gcc download
https://sourceforge.net/projects/mingw-w64/
cygwin gcc 설치 검색
c compiler
pull
gcc-core
C:\cygwin64\bin
환경변수에 등록
PATH
환경 변수 편집
새로 만들기
gcc --version
C:\Users\JYH>gcc --version
컴파일
② 컴파일 방식
C언어를 사용해서 Hello.c 파일을 만든다
Hello.c(소스) --- gcc.exe(컴파일러) ---> Hello.exe(기계어: CPU + OS)
기계어 파일
기계어에는 2가지가 들어감
CPU와 OS에 맞춰서 기계어가 만들어짐
Hello.c 파일을 생성한다.
#include <stdio.h>
void main() {
printf("Hello world!");
}C:\Users\JYH\git\bitcamp-study>gcc Hello.c
이름을 따로 지정해주지 않으면 파일이름이 a.exe로 된다.
$ gcc -o Hello.exe Hello.c
: Hello.c 소스 파일을 Hello.exe 라는 이름으로 컴파일 해줘
실행할 때 .exe는 생략해도 된다.
C:\Users\JYH\git\bitcamp-study>Hello
Hello world!
node는 실행할 때마다 node 프로그램이 필요함
실행할 때마다 자바스크립트 인터프리터가 필요함
소스파일도 필요함
C:\Users\JYH\git\bitcamp-study>node hello.js
Hello, world!
소스파일 없이 실행이 불가능
소스코드도 있어야 되고 그 소스코드를 실행해주는 인터프리터도 있어야 됨
근데 컴파일 방식은 한 번 기계어로 바뀌면 컴파일러도 필요 없고, 소스코드도 필요 없다.
고객한테 exe 기계어 파일만 배포하면 됨
고객은 내가 짠 소스코드를 모름. 내가 공개 안 하면 모름.
고객 컴퓨터는 인터프리터를 설치할 필요가 없음
고객 컴퓨터에 컴파일러를 설치할 필요 없음. 내가 이미 기계어로 바꿔놨음.
고객은 그냥 가져가서 기계어를 실행하면 됨.
그런데 자바스크립트는 그게 안 됨.
기계어로 안 바꿨기 때문에 고객 컴퓨터에서 실행하려면 hello.js 소스파일을 줘야 됨
내가 애써 짠 코드를 고객이 볼 수 있음.
소스파일만 주면 끝나는 게 아니라 고객 컴퓨터에 Node.js 즉 인터프리터가 설치되어 있어야 됨. 그래야 실행 가능.
매번 실행할 때마다 인터프리터를 통해서 소스코드의 명령을 읽어서 문법에 맞는지 확인하고 문제가 없다면 그제서야 실행한다.
그래서 컴파일 방식이 더 빠름.
내가 애써 만든 소스코드를 고객한테 노출시키는 게 인터프리터 방식
인터프리터 방식은 고객에게 내 소스를 줄 수 밖에 없음
그래야 실행 가능하니까
Java로 짜면 안 줘도 됨
C로 짜면 안 줘도 됨
C++로 짜도 안 줘도 됨
C#으로 짜도 안 줘도 됨
게임 설치할 때 게임회사에서 소스코드 받은 적 없음. 실행파일만 줌.
이게 컴파일 방식과 인터프리터 방식의 차이다.
• 인터프리터 : 고객에게 내 소스를 줄 수 밖에 없음
‐ 실행할 때 소스 파일이 있어야 한다.
‐ 인터프리터가 설치되어 있어야 한다.
‐ 실행할 때마다 문법검사 수행 => 그래서 컴파일 방식에 비해서 실행 속도가 느리다.
‐ 장점 : 인터프리터만 있다면 OS와 CPU에 상관없이 실행 가능하다.
node hello.js
• 컴파일 방식
한 번 컴파일 해놓으면 다시 컴파일 할 필요가 없다
그 다음부터는 번역기가 필요없음
실행
‐ CPU OS에 맞는 실행파일만 있으면 된다
‐ 소스와 컴파일러가 필요 없다
단, 그 CPU와 OS에 맞게 줘야 된다
포맷이 다름
같은 소스로 다시 컴파일 해야 됨
인터프리터 방식은 매번 실행할 때마다
컴파일 방식은 컴파일해서 기계어 파일을 만들면 그다음부터는 소스파일과 컴파일러가 필요 없다.
친구한테 Hello.exe 파일만 줘도 실행된다. 친구 컴퓨터에 Cygwin이 설치될 필요가 없다.
단, 그 CPU와 OS에 맞는 실행파일이어야 됨
컴파일과 OS, CPU
Hello.c 소스파일
Windows + Intel용 C 컴파일러 ---> 기계어
Windows + ARM용 C 컴파일러 ---> 기계어
Linux + Intel용 C 컴파일러 ---> 기계어
Linux + ARM용 C 컴파일러 ---> 기계어
그래야지 운영체제에 맞는 기계어가 만들어지고 실행할 수 있음
해당 컴퓨터에 맞는 OS와 CPU에 맞는 컴파일러를 갖고 있어야 됨
Android App과 OS / CPU
퀄컴 CPU
삼성 엑시노스 CPU
기타 모바일 CPU
ARM CPU
intel : i9, 제온 → 자체 설계도
ADM : 라이젠 → 자체 설계도
퀄컴 : 퀄컴 → 자체 설계도
삼성 : 엑시노스
ARM에서 설계 도면을 가져가서
ARM CPU 설계도면
ARM CPU + α => 삼성 엑시노스
ARM CPU + β => 애플 M1
ARM CPU + γ => 구글 CPU
지금 ARM이 대상
요즘은 속도롤 따지지 않고
와트당 속도
똑같은 전기를 가지고 누가 더 빨리 돌아가느냐
그게 애플 M1
AWS 아마존에 있는 서버들 다 자체 설계한 걸로 쓰고
Microsoft Azure 서버도 다 자기네가 자체 설계한 걸로 바꾸고 있음
인텔 망하게 생겼음
퀄컴도 지금 ARM 기반으로 CPU를 만들고 있음
중국도 이미 만들고 있음
ARM 설계도면을 만드는 회사가 영국에 있음
ARM은 CPU 설계만 함
설계도면을 가져가서 커스터마이징 해서 CPU를 만듦
진짜 CPU를 만들어야 됨
삼성은 삼성전자가 만듦. 자기네가 공장이 있음.
애플, 구글은 CPU 만드는 공장이 없음.
삼성은 경쟁 업체니까 삼성한테는 안 맡김.
TSMC는 고객 기업들의 반도체 설계도를 가지고 반도체를 만들어주는 대만의 기업이다.
파운드리(foundry) : 외부에서 제품 설계를 넘겨받아 반도체를 생산하는 일. 또는 그런 방식으로 생산하는 업체. 반도체 제조 전담 업체((반도체 설계 전담 업체에서 설계한 대로 제조 생산만 하는 업체))
TSMC가 파운드리.
팹리스(fabless) : 공장을 갖지 않는 (제조 회사가 대규모의 제조 시설을 갖지 않는), 반도체 칩을 설계만 하고 생산은 하지 않는
반도체를 만들 때, 하드웨어 소자를 설계하고 파는 일만을 주로 수행하는 회사. 반도체 제조 설비를 따로 가지지 않는다.
애플, 구글이 팹리스. 설계도면을 만듦. 공장이 없음.
삼성은 아직까지 3나노까지는 못 감. 그리고 경쟁 업체니까 안 맡김
App 개발
CPU가 여러 개인데 CPU에 맞춰서 앱을 컴파일 해야 됨
앱을 개발한 사람이 구글 Play 스토어에 앱을 올린다.
앱을 다운로드 받을 때 그 순간에 기계어로 컴파일 하는 과정을 한다.
여기에 맞춰서 컴파일 후 다운로드
그래서 앱 개발자가 각각의 CPU에 맞게 컴파일 안 하고 한 번만 컴파일 함.
한 번 컴파일해서 Play 스토어에 올려놓으면 이런 방식으로 동작하는 거
이게 Play 스토어의 방법
자바의 경우에는 컴파일까지는 안 하는데
네이티브 앱 중에서 C앱은 이렇게 함
iOS가 특히 그럼. iOS의 CPU가 여러가지여서.
컴파일 방식의 장점
한 번 컴파일 해 두면 실행할 때마다 소스파일이 필요 없다. 그냥 바로 실행하면 된다.
컴파일 방식의 문제점
우리가 만든 자바 프로그램은 서버에서 실행할 건데 서버 운영체제가 다를 수 있고 CPU가 다를 수 있음. 그럼 우리가 만든 자바 프로그램은 각각 운영체제와 서버에 맞게끔 매번 컴파일 해야 되느냐? 일단 자바는 컴파일 방식임. 그런데 여기에 인터프리터 방식이 결합됐음.
3. 하이브리드 방식
자바는 컴파일 방식임. 근데 여기에 + 인터프리터 방식이 결합됐음.
혼합 방식
③ 하이브리드(hybrid) 방식 = 컴파일 방식 + 인터프리터 방식
OS CPU
Solaris Sparc CPU
Linux Intel CPU
Windows Intel CPU
HP-UX Intel CPU
IBM AIX PowerPC CPU.java
명령문
자바 언어로 작성
javac.exe(컴파일러)를 통해서 번역을 한다.
진짜 기계어가 아니라 가상 기계어
가상 기계어 (Bytecode)
바이트코드(Bytecode, portable code, p-code, IR code)
바이트코드는 특정 하드웨어가 아닌 가상 컴퓨터에서 돌아가는 실행 프로그램을 위한 이진 표현법이다. 하드웨어가 아닌 소프트웨어에 의해 처리되기 때문에 보통 기계어보다 더 추상적이다.
IR(intermediate representation) code
중간 표현(IR)은 소스 코드를 나타내기 위해 컴파일러 또는 가상 머신에서 내부적으로 사용하는 데이터 구조 또는 코드입니다.
중간 표현(intermediate representation, IR)은 컴파일러나 가상 머신이 내부적으로 소스 코드를 표현하기 위해 사용하는 데이터 구조 또는 코드이다.
gcc
LLVM(Low Level Virtual Machine)
가상 기계어(중간 코드)
intermediate representation : 중간 표현
IR code = p-code = Bytecode (중간코드)
.class
진짜 기계어가 아니기 때문에 실행할 수 없음
Bytecode 해석기 = 인터프리터 = Bytecode Interpreter = java.exe
Bytecode Interpreter가 설치되어 있어야 됨
Bytecode Interpreter를 통해서 실행한다.
스팍 솔라리스용 Bytecode Interpreter
인텔 리눅스용 Bytecode Interpreter
인텔 윈도우용 Bytecode Interpreter
인텔 HP-UX용 Bytecode Interpreter
PowerPC AIX용 Bytecode Interpreter
개발자는 컴파일할 필요 없음
단, Bytecode Interpreter가 설치되어 있어야 됨
설치되어 있어야 실행할 수 있음
여기까지가 개발자가 할 일 (개발자의 역할)
시스템 관리자가 해당 OS/CPU에 맞게 인터프리터 설치
java.exe
리눅스는 그냥 java
뒤에 확장자가 안 붙음
바이트코드를 해석하는 거
개발자는 운영체제가 뭔지 CPU가 뭔지 알 필요가 없음
‐ 개발자는 CPU와 OS에 상관없이 프로그래밍 및 컴파일 가능!
자바는 하이브리드 방식
기존의 인터프리터 방식보다
자바의 특징
인터프리터 방식과 비교
‐ 컴파일 할 때 문법 검사 완료
‐ 어느 정도 기계어에 가깝게 변경
‐ 그래서 인터프리터 방식보다 실행속도가 빠르다.
컴파일 방식은 컴파일 할 때 문법 검사가 완료됨
근데 hello.js는 실행하기 전까지 모름
한줄씩 해석해서 실행
첫번째줄은 실행됐는데
두번째줄 실행하니까 에러나서 멈춤
C는 컴파일 할 때 컴파일 자체가 안 됨
기계어로 안 해줘!
기계어 파일 안 만들어 줌
컴파일 방식은 컴파일이 됐으면 일단 문법적으로 문제 없다는 거
인터프리터 방식은 문법적으로 문제가 있다고 하더라도 실행하기 전까지 모름
주식 증권 시스템
주식 매매 시스템
병원 시스템
미사일 통제 시스템
실행하기 전까지 문법이 맞는지 안 맞는 판단을 못 내리면
치명적
중요한 시스템 = critical 시스템
critical 시스템을 개발할 때는 자바스크립트처럼 인터프리터 방식은 안 됨
일단 문법적으로 문제가 없어야 됨
자바는 인터프리터 방식의 문제점을 컴파일을 통해서 해결
거의 기계어에 가깝게 해석해서 실행속도가 빠름
인터프리터는 컴파일 방식에 비교해서 CPU와 OS마다
컴파일 방식과 비교
‐ OS/CPU에 상관없이 배포 가능
자바는 운영체제별로 테스트 해봤는지, CPU별로 테스트 해봤는지 안 물어봄
고객사의 컴퓨터의 OS가 뭔지 CPU가 뭔지 알 필요가 없음
한 번 컴파일 하면 해당 컴퓨터에 맞는 인터프리터만 설치가 되어 있으면 바로 실행할 수 있음
인터프리터 방식의 장점과 컴파일 방식의 장점을 합친 게 하이브리드 방식
C#도 하이브리드 방식
인터프리터라고 안 부르고 Java Virtual Machine 이라고 부름
자바 가상 머신(JVM, Java Virtual Machine)
java.exe = JVM
.java 파일에서 일부러 틀리게 쓰고 컴파일 해보기
javac Hello.java
컴파일 할 때 에러 남
인터프리터 용어 정리
Hello.js --해석--> NodeJS --실행-->
↑
자바스크립트 인터프리터
(engine = VM = Player = Runtime)interpreter = Engine = Virtual Machine (VM) = Player = Runtime
V8도 엔진이라고 함. 인터프리터라는 용어 대신 엔진이라는 용어를 씀. 다 같은 용어임.
V8 JavaScript engine = interpreter
플래시 플레이어
윈도우용 파워포인트
맥용 파워포인트
전형적인 인터프리터 방식
