나는 호환성 보단 이식성이라 부르고 싶은데..
왜냐면 이것은 언어 자체의 특성이고 일단 바이너리로 바뀌면 전혀 상관없기 때문임
즉 이미 바이너리 화 한 프로그램, 즉 빌드된 프로그램은 호환성이 일단 날아가버린거고
여기서 말하는 호환성, 즉 이식성은 소스를 컴퓨터의 컴파일러나 어셈블러에게 먹히느냐 안먹히느냐 가 기준임
어셈블리를 먼저 보자
어셈블리 소스 -> 어셈블러 -> 바이너리
ARM 어셈블리 소스를 MIPS 어셈블러(MIPS 바이너리로 빌드된)에게 던지고 어셈블 하라고 해보자.
안된다. MIPS 어셈블리랑 ARM 어셈블리가 명백히 다르기 때문인데 더 쉽게 따지면 C# 을 C++ 컴파일러에게 던진 정도임
그럼 이번엔 ARM 에서 짠 C 소스를 MIPS C 어셈블러(역시 MIPS 바이너리로 빌드된)에게 던지고 컴파일 시키면?
C 소스 -> C 컴파일러 -> 바이너리
된다. C는 이식성이 좋은 언어, 즉 고급 언어거든. 전처리 할거 하고 준비 다 된 C언어를 공통 C 문법으로 MIPS 바이너리로 바꾸는 거다.
이렇게 ARM에서 짠 C 소스, 뭐 사실 어디에서 짜든 상관은 없지만 결국 C가 다른 컴퓨터 환경에서도 이식된거임
여기서 말하는 다른 컴퓨터 환경은 즉 아키텍쳐인건 다 알았을거고.
그럼 자바의 경우는?
자바는 위의 두 경우랑 좀 다르다. 위 두개는 결국 실행하려면 일단 바이너리 화 되야하는데 바이너리 되는순간 즉시 (아키텍처 간) 호환성은 소멸한다. 자바는 다르다. 자바의 구조는 아래와 같음.
JAVA 소스 -> 자바 컴파일러 -> 자바 바이트코드
컴파일러는 원래 부터 어떤 언어간 이라도 일단 A 언어가 B 언어로 바뀌면 컴파일러임. 자바가 그런 컴파일러인데 진짜 그 아키텍처의 바이너리, 또는 기계명령(머신 인스트럭션)이 되는것이 아니다. 자바 바이트코드라는게 되는데,
자바하면 자바가상머신, JVM을 알거야. 이 가상 머신, 이것도 일종의 컴퓨터를 구현한거니깐 당연히 해당하는 기계명령이 있고 그게 자바바이트코드다. 이 가상머신이 자바 바이트코드를 실행하는거지. 이 가상머신은 당연히 해당 컴퓨터에 맞는 바이너리고, 그러니깐 처음 자바를 실행할때 필요한 자바런타임(JRE)는 각 아키텍처에 맞게 설치해야 하는거야.
전체적으로 실행을 보면
자바 바이트코드 -> 자바 가상 머신 -> 해당 아키텍처의 바이너리로 구동되는 자바 가상 머신이 그걸 처리
어떻게 보면 에뮬레이터 라고 보면됨. 다른 명령,연산을 소프트웨어적으로 구현하는게 에뮬레이터 인데 자바 가상 머신이 그렇지. 그렇기에 성능이 당연히 떨어지는거고. 근데 자바 자체가 느린건 아냐. 자바 바이트코드를 하드웨어상으로 처리하는 CPU를 자바 프로세서 라 하는데 이걸로 돌리면 네이티브 적으로 하드웨어 적으로 처리하는거니깐 다른 아키텍처들하고 비슷한 성능의 CPU면 당연히 비슷하게 처리하겠지.
첫번째 영어 문장은 Cross compiling 얘기 같은데?
음. 그렇게 너가 전제를 내리고 글을 쓴 거라면 내가 할 말은 없네. 글 제대로 안 읽고 까서 미안.
compile - 4.(Computer) to translate (a computer program) from a high-level language into another language, usually machine language, using a compiler. -> JAVA와 .NET언어 모두 컴파일언어라고 불리는데 전혀 문제없어 너가 말하는 JIT 도 컴파일러야
난 어떤 개념을 일부 정의만 가지고 뭉뚱그려서 말하는 걸 싫어해서 반박한 건데 밑에 한 줄로 여기서 말하는 호환성은 소스 코드 레벨에서의 호환성을 말하는 겁니다 라고 말을 해서 뭐라 할 말은 없군.
병신 새끼야 몇 번을 쳐 말해. 크게 언어를 컴파일 언어와 인터프리터 언어, 이렇게 둘로만 나누면 컴파일 언어에 속하는 건 맞지만 좀 더 세세하게 컴파일 언어, 중간 언어, 인터프리터 언어로 나누는 것이 일반적이고 중간 언어에 속한다니깐. 컴파일 언어에서 중간 언어라는 혹을 떼어내서 다른 카테고리로 따로 분류한 거라고.
ㅅㅅㅅ / ㅇ.. 내가 한말 어디에도 틀린말은 없어 나도 JIT 이 뭔줄 알아 굳이 복잡하게 설명하지않았던이유는 이식성의 설명에서 전혀 중요하지 않기 때문이야 자바에서 대충 설명하기도 했고.. CLR은 좀 다르지만 46.165.*.* 2015.05.15 00:31:03 -> 댓글도 좀 똑바로 읽어줘..
병신 새끼야. 니가 내가 Java나 .NET platform은 중간 언어로 분류된다는 말을 반박하고 나서서 내가 역공 들어간 거잖아 씹새끼야.
니가 내 말을 반박한 저의가 뭔데. 중간 언어라고 설명한 내 말은 틀렸고 중간 언어가 아니라 컴파일 언어로 봐야 한다는 심산이 바닥에 깔려 있는 거잖아. 씨발놈아. 아니면 반박을 취소하던가.
난 애초에 Java나 .NET 가지고 니 글을 반박한 적이 없다. 그냥 언어 분류의 예시를 든 거 뿐인데 Java나 .NET 가지고 반박하고 나선건 너잖아.
ㅅㅅㅅ/ 너가 맨처음 썼던 댓글 보고와 넌 컴파일언어랑 중간 코드 언어 라는 분류로 나누었어. 그리고 중간 언어는 아는데 그 패러다임을 컴파일이 아니라 뭐라하는지 영문으로 좀 말해주겠어? 자료를 좀 보여주고 싶은데 그런 이름조차 모르겠어서
ㅅㅅㅅ / 난 처음부터 컴파일언어라는 말이 틀리지 않았다고 한거야. 틀리지 않았고
릴렉스하고 자라.
말 바꾸기 갑이네. 니가 애초에 내 덧글을 반박하면서 쓴 덧글이 ".NET 의 MIDL 이나 자바의 바이트코드나 둘다 일단 바뀐거라 컴파일언어로 보는게 맞아 아까 말한대로 언어의 종류가 다르게 바뀌면 컴파일임
http://en.wikipedia.org/wiki/Compiler"다.
.NET 얘기 처음 꺼낸 건 내 덧글에서이고 그걸 반박하고 나섰다는 건 중간 언어라고 분류했던 내 덧글이 틀렸다는 걸 말하고 싶은 거잖아. 말 존나 안 통하네. 왜 자꾸 변명하고 물타기해. 나처럼 그냥 미안하다고 하던가.
ㅅㅅㅅ / 너가 맨처음 썼던 댓글 보고와 넌 컴파일언어랑 중간 코드 언어 라는 분류로 나누었어 46.165.*.* 2015.05.15 00:51:23 니댓글은 너무 길어서 복붙 안할테니 앞에가서 보고.. 그래서 내가 뒤에서 둘다 컴파일언어라고 보는건 문제없다고 적은거야 태클건게 아니라... 난 그냥 말한건데 뭘 미안하다고 해야하는지 좀... 그리고 내가 말한거 봤어? 중간 언어 는 아는데 그런 JIT 컴파일을 컴파일이 아니라 다른 뭐로 표현한다는건지 모르겠어 패러다임을
ㅅㅅㅅ / 난 한번도 말 바꾼적 없어 내 글 다 인용해봐도 좋아
내가 중간형 언어라는 분류를 지어낸 게 아니라 엄연히 프로그래밍 언어론 책에서 보았던 분류다. 지금 집에는 그 책이 없어서 정확한 영문 표기가 뭔지 기억이 안나는 구나. 대충 Intermediate Language 정도 였던 거 같은데 이건 다른 언어 분류가 아니라 Java나 .NET의 Builder가 생성해 내는 Virtual CPU의 Operation Code의 Language를 말하는 거니까.
니가 처음에 나한테 시비 건 시발점이 내가 그냥 언어 분류의 예시를 들면서 중간 언어에 Java랑 .NET이 있다는 말에 니가 컴파일 언어라고 보는 게 맞다면서 글 하나 올린 게 시발점이 됐잖아. 니가 나중에 둘 다 컴파일 언어라고 보는 건 문제 없다고 했지만 그렇게 생각하면서 왜 내 첫 덧글에 대한 답으로는 "컴파일 언어로 보는 게 맞아"라고 쓴 거야? 이걸 너의 의도까지 섞어서 좀 길게 늘여서 쓰면 "중간 언어라고? (중간 언어가 아니라) 컴파일 언어로 보는 게 맞아"라는 의도로 쓴 거잖아. ~로 보는 게 맞아 는 왜 쓴 건데. 아니 애초에 왜 반박하고 나선 건데? 내 덧글이 틀렸다는 말 밖에 더 되냐.
ㅅㅅㅅ/ 그럼 결국 내가 말한 둘다 컴파일 언어 라는 말은 틀리지않았군 둘다 중간언어 를 사용함은 나도 위에서 글쓴대로 너도 니가 글쓴대로 서로 둘다 알았던거고 난 거기에 대해 반박한건 아니고 니가 첫 댓글을 그렇게 적었으니 난 거기에 맞게 설명을 해줬을 뿐 내말 어디에도 틀린 부분은 없다 생각하는데? 중간언어라는건 그 언어들이지 컴파일,인터프리트 같은 패러다임이 아니자나
ㅅㅅㅅ/태클건게 아니야 잘 봐...
감정만 안상하면 유의미한 주제의 토론이긴한데, 내용에 비해 너무 길게 내려왔다.
스크립팅 언어들이 인터프리터에 의해 해석되기도 하지만, 일반적인 OS의 실행형 바이너리(로더로 부터 직접 해석되는) 가 아닌 중간 단계의 바이너리로 만들어지는 경우들이 생겼고
그걸 컴파일 이라고 부르는 사람들도 있고, 다른 용어로 부르는 사람들이 있었다. 이름도 제각각.
그런데 일반적인 C/C++ 컴파일러들의 기능이 통합되고, 링커의 의미가 점점 사라지면서, 컴파일의 의미도 변해갔지.
obj 라는 중간 바이너리를 생성시키던 존재에서 그냥 로더를 통해 실행가능한 파일을 만들어내는 녀석이 되어버리니까. 컴파일이란 단어를 혼용하기 찝찝해진거다.
그래서 어느쪽이 전통이되어버렸는진 모르지만, 컴파일이라고 부르는 사람들이 있고 아닌 사람들이 있고. 그게 중요한건 아님.
다만 여기서 누군가는 상세 설명을 시도했고 누군가는 거기에 의문을 제기했고 그게 부정의 의미로 받아들여졌다는거지.
글로 전달하는 한계상의 문제같으니 적당히 맺으면 좋을 것 같다. 내가 접시 이야길 했을때 고깝게 받아들인게 아닌거 보면, ㅇㅇ는 단지 확실한 앎을 원했던것 같긴 하다. 그리 시비트거나 삐딱선 타려고 의도한건 아닐듯.
코세 / 두번째 댓글에 대해 말하자면 그건 스크립트언어를 인터프리터가 아닌 컴파일러(바이너리가 아닌 중간언어로의)에 던진거지 컴파일이나 인터프리트의 패러다임이 바뀐건 아니지않을까? 자바도 그런식이였고
코세 / 마지막 댓글에 대해 답하면 ㅇㅇ 이글은 애시당초 흔히 말하는 호환성, 이식성이 뭔지 모르고 바이너리도 언어 따라 어딘 호환되고 어딘 안되고 그렇게 생각하는 애들 보라고 만든거야 용어자체가 컴파일언어임은 틀린게 아니니깐
근데 난 첨 이 글 레이아웃 보고 직감했다. 나랑 정서가 다른 사람이란걸.
글쎄다. 특별의 로더에 의해서 해석되는 바이너리를 만드는 행위를 컴파일 말고 다른 이름으로 부른다고 해도 아무 문제 없잖아.
코세 / JVM 이나 CLR 같은걸 로더로 봐야할려나... 로더는 JVM,CLR 을 적재하고 또 중간언어를 적재하고 그거 아닐까 뭐 말하는 바가 뭔지는 알겠는데
ㅇㅇ // "중간언어라는건 그 언어들이지 컴파일,인터프리트 같은 패러다임이 아니자나"라고? 또 이상한 소리를 하네. 중간형 언어도 컴파일형 언어, 인터프리터형 언어와 동등한 언어 분류로 인정이 돼. 옛날에 JAVA만 있었던 시절에는 JAVA 밖에 없으니까 딱히 뭔가 분류를 만들지는 않았고 컴파일형 언어로 분류했었는데 .NET 플랫폼이 나오면서 점점 이런 언어들이(VB.NET, C# 등) 많아지고 JVM 쪽도 JAVA 뿐 아니라 다른 언어들도 나오면서 컴파일형 언어에서 갈라져 나와서 중간형 언어라고 분류를 만든 거야.
요즘음 컴파일러와 인터프리너 경계가 모호해지니까.
요즘은
내가 지어낸 게 아니라 프로그래밍 언어론 책에서 그 세 개로 언어 분류를 내린 걸 본 기억이 있어서 이렇게 말하는 건데 웃기네.
더 일반적인 표현을 빌면 translator 고 encoder 지. 하지만 compiler 라는 단어를 쓰게 된덴 convention 이 존재하는거다.
그 convention 이란에 원래는 국지적인 영역에서 발생하는거고.
Personal Computer 란 단어가 IBM의 brand name 이었던 것 처럼 말야.
그래서 세분화된 전통을 고수하는 사람들은 중간형태의 언어로의 변환을 별도로 구분한다.
그리고 컴파일 언어는 기본이 원시 프로그램(Source code) -> (compile) -> 목적 프로그램(Object file) -> (link) -> 실행 파일(Executable file)의 과정으로 만들어지는 걸 말하고 이 Executable file은 OS에 의해 바로 실행이 가능해야 되고 Object file은 Target processor의 Machine code가 담겨 있어야 해. 그런 의미에서 Java나 .NET은 컴파일 언어라고 볼 수 없어. 개념적으로 인터프리터 언어지. 그저 JIT Compile이 추가된 건데 그건 Java VM이나 .NET Framework 레벨에서 Performance를 최적화한 거잖아. .NET 프로그램을 컴파일한다고는 안하고 빌드한다고 말하는 것도 같은 이유야.
ㅅㅅㅅ/ 그니깐 그런 언어분류로 인정된다는 자료를 보여달라고... 태클건건 아니였는데 자꾸 이상한 소리하네 뭐 이러니깐 끝까지 캐묻고싶어지네 공부할때 그런 분류 보지못했는데
A compiler is a computer program (or set of programs) that transforms source code written in a programming language (the source language) into another computer language (the target language, OFTEN having a binary form known as object code).[1]...
너도 지금 JIT "COMPILE' 이라고 하네?... C# Compiler Options
https://msdn.microsoft.com/en-us/library/2fdbz5xd.aspx
검색하기 쉽지 않을껄. 나도 오래전 기억이라 키워드가 쉽게 안떠오르는데
분명 아까 보여준 CLR 도약도에서도 컴파일이라고 나온거 봤을텐데...
Translators(Compiler, Assembler) and interpreter.
컴파일러도 어셈블러도 Translator 의 일부일 뿐인데
이게 예전엔 몇 종류가 더 있었다.
코세 / 그렇지 인터프리터는 적재되서 소스를 실행, 트랜슬레이터는 프로그램의 번역을 의미하고 실제 실행은 그걸 다시 로드해야겠지
실제 인터프리트 나 트랜슬레이트 의미가 그렇지만 통역과 번역 ㅋㅋ
어셈블도 조립이고 컴파일도 엮다다 하지만 컴파일러를 어셈블러라고 부르지 않는덴 역시 convention 이 있는거지.
이제 나 좀 딴거 하게 해주면 안될까. 자료도 다 보여줬는데 자꾸 이러면 무의미한거같은데
요즘처럼 compile 의 의미가 광역화된 상황에서 구글링해도 쉽진 않을꺼야. 예전 다른 개념 이름들 찾는거.
코세 / 그거 말고도 어셈블러는 언어간 변환의 컴파일러가 아니라 그냥 어떤언어(어셈블리)를 실행 가능한 목적코드로 만드는게 어셈블러지
미리 말했지만, 적당히 끊고 각자 일 해라. 이렇게 길게 이야기 할 주제는 아니다.
지금 니 설명 컴파일러의 정의라고 해도 무방할껄?
근데 아무리봐도 그런 패러다임은 본적이없는데... 모든곳에서 컴파일이라고 나와있기도하고 중간언어를 사용하든 안하든 간에
컴파일러의 정의는 언어간 변환이지 반드시 실행가능한 목적코드를 만들 필요가 없지
범 언어적 용어가 되어버린건 태생부터 그런게 아니란거야. 어셈블리어에 국한된 차이를 몰라서 이야기 하는게 아니라.
예전의 컴파일러들은 반드시 실행가능한 목적코드를 만들었었지.
니가 구글링 해서 찾을 수 있는 컴파일의 의미는 이미 여러번 변해온거고.
인터프리터도 내가알기론 인터프리터의 방식을 따르면 다른언어로 변환해도 인터프리터, 즉 컴파일러와 인터프리터가 어찌됐던 주체는 고급언어고 그 변환 대상은 목적코드든 다른 언어든 변환하는거, 어셈블러는 실행가능한 코드로 어셈블(조립)하는거
과거를 이야기 하는데 현재의 개념을 이야기 해 봐야 무의미한거야.
예전의 컴파일러들이 반드시 실행 가능한 목적코드를 만들었다고? C++ 도 첫 컴파일러는 C로 컴파일 하고 다시 바이너리화 했는데
그러니까 내 말의 요지는, 알만한 선수들끼리 이렇게 길게 이야기 할 필요없다고.
단어 자체는 예전부터 반드시 목적코드를 뽑을 필요는 없는데, 언어관 변환이 반드시 필요한것도 아니고 당연히 목적코드를 만드는것들이 먼저나왔다 가 정확한 말인듯
포트란 컴파일러.
ㅇㅇ 알았으
ㅇㅇ 말 듣고 가지고 있는 프로그래밍 언어론 책을 하나 찾아 봤는데 컴파일 언어도 인터프리터 언어도 아닌 하이브리드 언어라고 분류해 놨네. 내가 중간형 언어라고 한 건 내 기억이 온전하지가 않아서 내가 만들어낸 용어에 가깝고 하이브리드 언어로 분류하는 듯.
내가 봤던건 하이브리드가 아닌 다른 단어였는데 뭐 여튼.
하이브리드 언어 는 처음들어서 쳐보니 나오는게 MPPL 멀티 패러다임 밖에 안뜨네
아무튼 별도로 분류한다. 컴파일형 언어도, 인터프리터형 언어도 아니야. Bytecode || MSIL로 Compile → VM이 Interpret로 진행되기 때문에 혼합되었다고 보는 거지. JAVA도 .NET 플랫폼 언어들도 VM을 순수 인터프리터로 구현하면 느리다는 걸 잘 아니까 JIT compile 기능을 넣어서 최적화한 거고. JAVA에도 JIT compile이 있는데 JAVA는 Interpreter 언어의 예에 들어간다. PyPy에도 JIT compile이 있는데 Python도 Interpreter 언어의 예에 들어가고.
잠깐 컴파일러 책도 찾아볼게.
포트란 컴파일러도 수많은 컴파일러들중 포트란을 실제 실행가능한 프로그램으로 바꾸는 목적이였고 그건 지금의 컴파일러도 대부분 그렇지않나?
자바는 JVM 이 인터프리트도 JIT컴파일도 가능하니깐 논쟁의여지가 있지만 CLR은 컴파일이고 .NET언어는 컴파일언어가 맞다 그리고 저경우 자바는 컴파일언어나 인터프리트언어 둘중 실행되는 방식에 따라 결정되는거고
JIT컴파일을 통하는 순간 그 언어는 더 이상 인터프리트어나 스크립트가 아니지... 그건 어떻게 동작되냐에 따른 분류인데
C# 올려준거 봤자나 컴파일 랭귀지라는거...
이상하다. 중간 언어 비슷한 분류 이름도 분명히 본 거 같은데 역시 기억이 온전치 않아서 내가 만들어낸 용어인가.
이건 이렇게 길게 토론할 주제가 아니야. 개념은 어차피 overlap 되어 있어.
현대의 의미를 모르는 사람 여기 없고
과거의 기억을 가진 사람이 있을 뿐이지.
포트란 컴파일러를 예로 든건, 중간 파일이 있냐 없냐에 대한 이야기야.
초기엔 중간파일이 없었음.
그러가 모듈을 합치고 메모리를 재정렬하기 위해 중간파일이 생긴거고
그래서 컴파일과 링커의 개념이 확실히 나뉘었던 적이 있었지.
컴파일의 의미도 그렇게 변해온거라고. 초기엔 컴파일과 인터프리터 사이에 다른 개념들도 있었음
쉽게 생각하면 그냥 어떤 언어가 있으면 그 언어의 컴파일러와 인터프리터 둘다 나온거임 이런 경우는 어디다 넣느냐에 따라 부름을 달리해야지 딱히 두개가 혼재한다해서 다르게 부르는건 없는거같은데 그거 두개를 모두 지원한다고 다른 특징이있는것도 아니고 그냥 두 경우의 문법만 같은거지..
오늘 날엔 링커 뿐만 아니라 로더까지 흡수하는 추세여서
그건 지금 대부분의 컴파일러가 마찬가지아냐? C 나 C++ 파스칼 델파이 도 다 마찬가지인데 대부분의 네이티브 언어가 그렇지뭐
OS 조차도 메모리 로더가 실체화되어 있는 놈이 있고 다른 모듈안에 녹아 있는 놈이 있으니
그리고 CLR 도 지금같이 .NET이 멀티플랫폼이 되기전엔 그냥 코드 최적화를 위해 일단 닷넷언어들을 다 MSIL로 바꾸고 그걸 최대한 최적화하는 방식이였고
굳이 과거의 세분류가 틀린것도 아니고, 오늘날의 용어를 다시 쓸 필연성도 없다고 생각.
그러니 이 쓰레드는 여기까지가 좋겠다. 너도 다른일 해야하고. 나도 타원 좌표계 변환으로 머리가 아프구나.
요즘 대부분 컴파일러가 링커는 포함하고있는데 로더를 흡수한다고? 로더는 OS 서비스 아님?
ㅇㅇ 알았어 나도 이만 나가봐야함
그럼 나 간다 ㅂㅂ
로더는 OS 서비슨데 VM 이나 이미 로더에 의해 불린 녀석이 스크립트나 중간 바이너리를 돌리면 애매해진다는거지.
잘가~
ＳＴ7 7 ８．℃ ○Ｍ qzinrsq2