|
|
||||||||
| 경고! 게시물 작성자의 사전 허락없는 메일주소 추출행위 절대 금지 |
|
컴파일.jpg
403.1KB
컴파일.png
79.2KB
mslink.jpg
76.9KB
64bit.jpg
82.7KB
저 또한 위에 본문 글 쓰신 분의 의견에 동의합니다.. 그리고 역량이 모자람에 대해서 나무라신 것 같은데요,
역량이 모자람을 탓하시면 안될것 같아요.. 그만큼 C++ 컴파일러 분야가 엄청나게 발전을 했다는 얘기와 같은 거니까요.. 대세는 LLVM 이 차지했고 한두분야 뿐만아니라 전체 영역에서 LLVM 광풍이 불어닥친 상태입니다. 그런데다 가장 이슈는 왜 델파이는 모바일(다중타켓 플랫폼)에서 되는데 C++ 은 안되느냐에 대한 의문을 가진 사람들이 많았을 것이고 요청도 쇄도했을 것인데 해결을 못하면 약간 삐꾸 느낌이 들죠.. 당연히 델파이는 될수 밖에 없었던 것이 FPC(프리 파스칼 컴파일러)가 맥에서 작동될 수 있는 버전이 있었기 때문인 것이고.. C++ 은 그런게 없었으니까 못한거였던 거죠.. GCC 라는 놈을 이용할 수는 없는 노릇이죠.. 아예 근본이 다른 놈인데.. 근데, LLVM 이라는 엄청유연한 컴파일러가 나와버린 상황이고.. 광풍이 불고 있는 상황에다가 굳이 컴파일러를 만들어야할 필요성을 못느낀겁니다.. 게다가 새로 만든다고 해도 LLVM 을 능가할 수 있겠는가? 라고 봤을때 계산을 해봐도 도저히 이길수 없다는 걸 잘 알고 있었을 것이구요.. 자기네들의 역량으로는 한참을 개발해서 겨우 따라가야될 정도라는 사실을 알았던거니.. 굳이 그 싸움을 해낼 수가 없다고 판단했겠죠.. 당연히, 컴파일러 개발을 한다는 것 자체가 C++ 과 파스칼이 기술적으로 차이가 극단적으로 갈리는데 파스칼이야 해결이 어떻게 보면 손쉽게 된 케이스이지만 C++ 은 할 수가 없었던거겠죠? 잘 알다시피 멀티 타켓에서 컴파일 되게하기위해서 IR 로 변환시킨 후에 그걸 다시 최종 타켓 플랫폼의 머신코드(OPCODE)로 생산하는 작업이 절대적으로 쉽지 않은 작업이거든요.. 아마, 파스칼 조차도 그걸 만들기는 쉽지않은 작업일거라고 봅니다.. 아마도, 그래서 FPC 를 사용했겠죠.. 이미 잘 만들어져 있으니까요.. 굳이 컴파일러를 새로 만들어가면서 까지 잘못하면 치명타를 맞을수 있을지도 모르는 것을 투자하지 않았겠죠.. 좀 얌시로운 면이 있기는 하지만은.. 차라리 나은 선택이라고 봅니다.. 만약, 자체적으로 간다고 한다면 앞으로 몇년동안은 컴파일러의 개선은 기대하기 힘들어야 정상일듯 하네요.. LLVM 으로 간 이유는 딱 하나.. 멀티타켓으로 개발할 수 있다는거.. 이얘기는 델파이 뿐만 아니라 C++ 빌더로도 iOS 용 어플리케이션을 만들수 있단 얘기.. 이 얘기는 곧, LLVM 의 IR 변환이 멀티타켓으로 머신코드화 변환이 아주 잘 되있다는 거.. 이정도로 만들라면 머리통이 뿌서질 정도로 똑똑해야 하는데.. 그렇다고 엠바카데로가 안똑똑한 사람을 데려다가 개발시키진 않을 것이기에.. 할 수는 있겠지만.. 시간이 미칠듯이 오래걸릴거라는거.. 이 계산이 크게 작용했다고 보는게 맞겠죠.. 여튼, 전 전반적으로 봤을때는 메인본문 글을 쓰신 분의 의견에 동의합니다.. 그리고, C++ 하고 파스칼하고 비교하는 것은.. 좀 안맞는거 같네요.. C++ 이 아무래도 네이티브에 더 가까운 언어적 특성을 갖고 있기 때문에 정형화적인 면을 파스칼처럼 잘 맞춰주지 못합니다.. 심지어 LLVM 으로 작성되어져있는 현재의 Xcode 컴파일러에서 인라인 어셈블리를 이용해서 컴파일러가 오류가 나는 일들이 벌어지는 것은 파스칼 쪽이 아니라 C++ 쪽이라는거.. 애플도 제대로 처리를 못해서 오류가 나오고 있는 쪽이라는 점을 인지하셔야 할 듯 함.. 파스칼로 짤때는 인라인을 쓰는게 일반적인 개발방향은 아니잖아요?(사용할 수는 있다하여도..) C++ 은 그게 상당히 일반화되어 있다라고 보셔야 할듯..(역사속을 들춰볼때 그렇다는 것임) 그렇기 때문에 쉽게 생각을 하지 못하고 복잡하게 얽힌 변수들을 고려해야할게 많으니.. 그냥 LLVM 으로 가면서 손 보는게 훨씬 이득이겠죠.. 다른 분야이지만 이제 ARM 용 윈도우도 나온다고 하니 이걸 대상으로 예를하나 들어보죠..
만약, 윈도우 프로그램을 짤때 어떤 사람들은 TEB 를 이용해서 어떤 특정한 값을 얻어올려고 인라인 어셈블리를 사용합니다. 근데, 이게 사람들에게 워낙에 블로그에도 많이 긁혀갖고 워낙에 많이 인터넷상에 뿌려져있고 워낙 일반적인 코드여서 그 기능을 구현할려면 어쩔수 없이 인라인 어셈블리를 사용하지 않으면 안되는 것이 있다고 생각해봅시다. 그리고, 실제로 이런부분이 심심찮게 있습니다. 마치, 비유하자면 리눅스의 로컬쓰레드스토리지(Local Thread Storage)만을 이용해서 짜여져 있는 소스는 윈도우에서 아무리 cygwin 이 리눅스 소스를 잘 컴파일해준다고 해도 컴파일 자체가 될 수 없는 경우입니다. 왜냐면 Local Thread Storage 자체는 리눅스 고유 커널의 기능이라서 사용자체가 될 수 없는 경우이거든요.. 근데, 만약 Local Thread Storage 를 이용하지 않고도 사용될 수 있는 대체용 코드가 마련되어 있는 경우에는 그 대체기법을 사용하도록 해서 호환 시켜 컴파일이 가능합니다. 그런데 어떤 놈은 이 대체코드 자체를 아예 사용하지 않아서 해커들이(개발자 해커들) 직접 이런 대체코드를 작성해서 port(포팅)해서 인터넷에 뿌리곤 합니다. 그런놈은 cygwin 에서도 컴파일이 가능해지는거죠.. 이런 경우와 비슷하게 만약, 어떤 기능을 구현하려 하는데 일반적으로 인라인 어셈블리 코드로 TEB 에서 뭔가의 값을 꺼내와야만 하는 그런 코드가 들어갈 수 밖에 없다면 어떻게될까요.. 인텔 코드로 짜야될까요 ARM 코드로 짜야될까요..? 아마도, 이런 코드는 작성해서는 안된다 그건 개발자가 잘못하는 것이다라고 하실게 분명합니다.. CPU 의존적인 코드를 짜는 것 자체부터가 멀티플랫폼 환경을 고려한다면서 맞는 일인것이냐? 라고 반문하실게 뻔합니다.. 그러나, 지금은 아주 흔하게 볼 수 있는 단순한 예인 TEB 안에 값을 얻기위한 인라인 어셈블리에 대한 예만 들은겁니다.. 이런식으로 인라인 어셈블리를 이용해서 뭔가의 특정작업을 하는 일들은 C++ 쪽에서 굉장히 많다는 것입니다.. 이런 코드를 전부 그럼 타켓 플랫폼(CPU)의 코드로 전부 재작성을 해야겠군요..? 그 작업은 저도 일전에 해봤지만 정말 새로 프로그램을 개발하면 했지 못해먹을 작업입니다.. 얕은 지식 갖고는 건드리지도 못하는건 둘째치고 건드릴 수 있는 지식을 갖고 있어도 장담을 못하는 수정밖에는 할 도리가 없는 상태가 되버리기도 합니다.. 앞에서 제가 말한 것도 누군가가 Xcode 에서 인라인 어셈블리를 이용해서 코드를 짰는데 작동을 하지 않고 뻗었다고 한 경우인거죠.. 알다시피 애플에 Xcode 는 현재 llvm-gcc 를 사용합니다. 이런 경우들이 C++ 쪽에서는 빈번히 발생할 수 있는 일들이며 이럴때 어셈블리 코드의 작동을 호환시켜 변환까지 해주지는 않을거라고 예상을 하지만요..(아마, 그렇게 인라인어셈까지 변환해주지는 않을겁니다.. 아니, 못할거 같은데요..?) 그건 둘째치고서라도(인라인어셈 변환까진 바라지도 않음) 타켓 플랫폼에(실행될 플랫폼: CPU) 맞는 인라인 어셈블리를 사용하는 경우에도 llvm-gcc 가 제대로 작동을 못하고 뻗는 경우가 간혹 생기는가 보더군요..(간혹이겠죠.. 아마도.. 근데, 찾아보니까 은근히 사례가 좀 보이는 편이네요..) 이런 일이 주로 발생되는 것은 인라인 어셈블리를 사용하는 C/C++ 언어들의 특징이 많이 반영된 사항이라는 겁니다.. 달래 컴파일러 간에 구현어려움 차이가 발생하는건 아니라고 봅니다.. 그 언어의 관례(역사)에서 비롯된 일인거지요.. 그렇다고 어셈블리 코드를 사용하지 못하도록 강제로 막는다면 그건 C 라는 언어의 능력을 스크립트 레벨로 끌어내리는 것과도 동일한 저지(?)와도 같기 때문에 또 그렇게는 못합니다.. 능력을 그정도까지 제어하는 수순이라면 스크립트레벨이 될 수 밖에 없죠.. 사용을 되도록 하지 말라고 한다고 하더라도 되기는 되야 하는거거든요.. 그게 바로 언어의 확장성과 능력이 얼마나 되는가를 쟤는 척도이니까요.. 파스칼도 가능 하다고 우기실지는 모르겠으나.. 그런 소스들이 인터넷을 범람할 정도로 채우고 있는가?(그렇게 사용되어온 행태가 만연 한가?) 의 상황이 존재한다는 것을 알아야 한다는 겁니다.. 대부분의 C/C++ 의 경우에는 프로젝트 규모가 좀 되면서 고급 기능이 들어간 놈인 경우 소스 분석하다가 하부단으로 기어들어가서 코드를 읽게되는 경우 심심찮게 인라인 어셈블리를 보게되는게 다반사입니다.. 이게 역사적 관례이기 때문에 어쩔수가 없죠.. 이런 상황에서 컴파일러를 제작해야 하는 입장을 고려한다면.. 정말로.. 끔찍한 작업이지 않을까 생각을 해봅니다.. 제가 말씀드린 부분은 그런거였습니다.. 반면에 파스칼은 그런부분에 있어서도 C/C++ 영역쪽 보다는 아무래도 많이 자연스럽다라는 것이며, 그렇기 때문에 상대 적으로 더 컴파일러의 구현이 쉬울수 밖에 없을 겁니다.. 이건 팩트일 뿐입니다.. 오직.. 팩트.. 사견이 반영될 수 없는 거라고 봄.. 여튼.. 그렇네요.. 고생들 하십시요.. ㅎㅎ 아, 만약에 LLVM 에서 이런 인라인 어셈들도 컴파일 시에 다 분해시켜서 IR 화 시키고 최종 타켓 플랫폼에서 작동
되는 머신코드로 생성해내는 기능이 이미 탑재되어 있는 것이라면.. 바로, 이러한(이정도 난이도 레벨) 부분을 엠바 카데로 애들이 구현하기에는 미친 난이도일듯.. 시간도 엄청 걸릴 것이고.. 뭐.. 상상도 사실 잘 안될수도 있고.. 그럴꺼면.. 걍 이미 다 구현된 LLVM 쓰는게 났다는 거겠져.. 엠바카데로 애들이 능력이 있다손 치더라도.. 이런걸 구현하는데는 엄청난 기력이 소진될 거라는 얘기이고.. 참고로, 지금은 단순히 인라인 어셈블리라는 단 한가지 이슈만 갖고도 이정도로 제가 지껄일수 있다는 것인데요.. 이런 이슈 하나만 있겠습니까..? 이건 단지 하나의 우려(?)만 갖고도 이런 깊은 내용으로 빠져들면서 고민할 수 밖에 없는데.. 이런 문제꺼리들은 C++ 컴파일러를 멀티타켓용으로 만든다고 할때 수도없이 산재해 있을 겁니다.. 단순히 한가지 문제도 이렇게 복잡해 진다면..? 과연.. 엠바카데로에서 이런 산재한 모든 문제를 해결하려 들까요? 애플도 마찬가지 입니다.. 애플은 이미 LLVM 을 채택해버렸죠..? 결국, 어쩔수 없는거라고 볼 수 밖에요.. 이젠 오픈소스의 힘은 단지, 오픈커뮤니티들의 힘이 아니라.. 전세계의 모든 개발자들.. 모든 광적인 개발자들(해커들)에 의해서 대세물결이 되었고 그 힘은 어마어마하게 쏟아져 나오는 소스분량들이 증명하고 있죠.. 이젠 기업이 쪽도 못쓰게 된거라고 봐야겠죠.. ㅎㅎ 관련 글 리스트
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Copyright © 1999-2015, borlandforum.com. All right reserved. |
저처럼 적지 않은 나이인데, 아마도 컴 1세대이신가 보네요.
저는 Apple ][로 시작했었죠.
아직도 86년도인가에 나온 컴파일러 제작 번역본을 소장하고 있죠. 웬지 버려지지 않아서.
VC는 윈도의 대표 컴파일러이니,
개발진들이 적어도 VC로 사전에 컴파일은 해 봤었겠죠.
64Bit 컴파일러 제작은 본래의 C++ 컴파일러 오리지널본 제작에 비해서는
아주 쉬운 작업에 속할 것입니다. 델파이가 무리 없이 64bit를 내 놓은 것을 봐도
그렇고 64bit 컴파일러의 이슈를 봐도 그렇고.
그래서 엠바가 그 정도 역량이 없다고는 전혀 보여지지 않고요,
아마도 그 쪽 회사 사정이 있겠죠.
컴파일러 발표 주기가 짧으니 만큼 64Bit 쪽에 투입할 시간이나 인력이 부족하지 않나 싶습니다.