음 ... 과찬이십니다 ㅎㅎ

아직 저는 배울것이 많은 애송이라고 생각됩니다 ㅋ

누군가가 응원해준다는 것은 참으로 감사한 일이라고 생각됩니다 ... 감사합니다 ^^

당근과 채찍을 ... 잘 조합한다는 것이 참으로 어려운 일 같습니다.

너무 당근만을 주다보면, 당근의 달콤함에 빠져 ... 나태해지고 ?!

너무 채찍만을 가하다보면, 참지 못하고 ... 포기하게 되더군요 ㅎㅎ

무언가를 전달할 때, 당근과 채찍을 골고로 배합해주기 위해서는

교육학이라는 것을 따로 공부할 필요가 있을 것 같습니다 ㅋ

많이 배워갑니다 ^^

저 또한 아는 것이 별로 없어 자주 조언을 얻어야 할듯 ... ^^;ㅎ

'내가 스터디를 위해서 무엇을 할 수 있을까?' 라는 생각을 가진 사람은 별로 없고

'내가 스터디에 의해서 무엇을 얻을 수 있을까?' 라는 생각을 하는 사람이 대부분이죠.

스터디를 잘 하는 것과 스터디 운영을 잘 하는 것은 차이가 있습니다.

마치 개발을 잘 하는 것과, 개발 회사를 잘 운영하는 정도의 차이라고나 할까요? ^^

음 ... 참 어려운 문제군요 ㅋ

항상 느끼지만, "내가 스터디를 위해 무엇을 할 수 있을까?"라는 마인드를 가지신 분들이

오히려 "내가 스터디에 의해서 무엇을 얻을 수 있을까?"라는 마인드를 가지신 분들에 비해 보다 더 많은 것을 얻어가는 것 같습니다.

뿐만 아니라 ... 선자의 생각을 하신 분들은 이후에 공부하시는 분들에게도 많은 도움을 주시는 분들이되더군요 ㅎㅎ

진심 어린 gilgil님의 조언 잘 받겠습니다.

외국에서 빡시게 공부하고, 실력을 보다 갈고 닦아 ...

언젠가 한국에 돌아와 OSF(Oepn Source Foundation)을 만들고 싶습니다.

외국에서 수입하는 모든 OS, Compiler, Debugger등이 전부 국산화되어

실질적인 이익을 창출 할 수 있는 날이 왔으면 좋겠습니다.

전에 이런 프로젝트가 있었던 것 같습니다.

인하대 대학생분들을 모아서 항공기에 들어가는 OS를 국산화 할려고 했답니다(인하대 쪽에서 박사 논문 쓰고 계신분이 알려주심)

이 프로젝트는 정부에서 지원해준 프로젝트인데, 2년인가 3년만에 정부가 손을 뗏다고 하더군요 ...

이유는 Compiler가 없기 때문에 OS 자체를 국산화 시킬 수 없다는 결론이였습니다.

저는 원래 OS를 만드는 것에 목적을 두고 있었기에 ... 이 말을 듣고 Compiler가 엄청난 것이구나라는 것을 느꼇죠 ㅎㅎ

그러면서 공부를 하다보니, Compiler의 Optimization Skill이라든지 Computer Architecture에 기반한 Instruction Set,

그리고 버그를 해결하기 위한 Compiler의 정 반대 녀석인 Debugger ... 최종적으로

이 모든것을 총괄하는 Kernel ... 이 모였을때, 정말 OS라고 부를 수 있다는 것을 느꼇습니다.

(Compiler는 Decoder, Debugger는 Encoder)

저는 사실 Kernel을 막 공부하고 났을때는 Kernel을 OS라고 불렀었습니다.

지금 느낀 솔직한 감정으로는 그때 당시 한 말은 수정될 필요가 있다고 생각합니다.

Kernel은 Process, Memory, File System, Device Driver, Network를 관리하는 1개의 Core System Softwar이고,

OS는 Compiler, Library, Binary File Descriptor(BFD), Debugger, Kernel이라는 5개의 Core System Software의 집결체로 말이죠 ...

언젠가는 이 꿈을 꼭 이루고 싶습니다 ^^

 생각해 보니 그이전에 원서 읽을 영어실력이 안되는군...

이런 말을 하면 제가 나온 학교 욕인것 같지만 국내 대학교에 Compiler나 OS에 대한 기반 지식을 요구하는 기대를 한다는 자체는 아직 무리라는 생각이 듭니다.

전 OS에 대해서는 잘 몰랐습니다(지금도 잘 몰라요 ㅋ). 학교 다닐 때 3학년때 OS라는 수업을 들었는데, 시험이 오픈 테스트였고 "책 몇줄에 있는 소스 코드를 없애 버리면 OS 부팅 과정이 어떻게 변하느냐" 식으로 시험 문제가 나왔었습니다. 한마디로 교수님이 얘기해 주시는 OS에 관한 지식 하나 하나를 이해하지 못하면 제대로 된 점수를 따기 힘들었죠. 나름 빡셌습니다. ^^ 그런데 수업 막바지에 가서 교수님께서 그러시더라구요.

"너네는 OS를 책으로 배우기만 하지, 버클리에서는 OS 하나 만들어 오는게 리포트야."

상용에 접근한 OS는 둘째 치고라도 Micro Kernel 구현도 제대로 못하는게 현재 한국의 IT 기술의 현실입니다. 입학이 쉽고 졸업이 어려워야 제대로 된 대학 교육이 이루어 질 수 있는데, 우리나라는 정반대이죠. 국내에서 아무리 잘 해 봐야 우물안의 개구리입니다.

그리고 가급적이면 군대는 가지 마세요. 군대 가서 좋은 점은 나중에 술자리에서 할 수 있는 얘기 거리가 좀 더 생긴다는 정도? 아직 미필이라면 병특으로 가서 한국 IT 실정을 피부로 느끼는 것만으로도 충분합니다. 반드시 외국으로 나가세요. 오히려 그게 애국하는 길입니다. ^^

"버클리에서는 OS 하나 만들어 오는게 리포트야" <<--- 전율을 느꼇습니다 ㅋㅋㅋ

하긴 ... 버클리는 Free BSD를 기반으로해서 TCP/IP 자체를 만들었으니 ... 그럴만도 하다고 생각합니다.

굉장한 인간들인듯 ㅠㅠ

Free BSD는 확실히 박수쳐 줄만 합니다. 이후 대부분의 socket programming에 지대한 영향을 미쳤으니까요.

허나 쫄거 없습니다. 학부 레벨에서 OS 만드는 리포트라 해 봤자 Bootloader 만드는 정도? 그래도 국내 대학생들에게 이러한 리포트를 낸다면 몇명정도가 리포트를 제출할 수 있을런지... ^^ 태어날 때부터 Von Neumann Architecture를 알고 태어 나는 사람이 있을까요? 외국인들이 무조건 잘 할 거라고 생각하지 않아도 됩니다. 국내에서도 훌륭한 사람들 많습니다. 다만 대학 교육 과정뿐만 아니라 사회에 나와서도 개발자로서 올바른 길을 갈 수 있도록 경력을 쌓을 수 있는 문화를 만들어 줄 수 있는 회사가 한국에서는 드문 것이 문제이죠. ^^

Boot Loader라면, +_+ ㅋ

외국인도 외국인 나름의 괴물이 있을 뿐이군요 ㅋ (리누즈 토발즈, 리처드 스톨만, 오드리 탕, 래리 월등 ...)

GNU Project에 참여하여 Program을 개발할 수 있는 정도의 실력으로 갈고 닦고 싶네요 ㅎㅎ

 조건이 좋다뇨...

가진게 아무것도 없어서 요즘 힘들다는..

boost는 나보다 더 잘 알자나. ㅋㅋ

요즘 STL 방식에 익숙해 지려고 노력하는데, 확실히 예전같지가 않네.

남들은 Jave다, Object C 다 세상은 변해 하는데 점점 소외되는 느낌. ㅠㅠ

근데 C/C++도 아직 공부할게 많다는... ^^

C만해도 끔찍하죠 ㅋㅋㅋ

이제부터 Linux 기반이시니 ㅡ_ㅡㅋ

GCC Expansion과 관련하여 __attribute__(); 를 많이 보시겠군요 ㅎㅎ

또, 분기 예측과 관련해서 unlikely(), likely() 같은 GCC의 사기 기술?!이 있습니다.

(주로 Kernel 코드에 많이 사용되는데, Performence를 높이고자 ... ㅎㅎ)

참고로, 이것은 100% 보장이 아니라 99%의 보장성을 지니고 있습니다.

즉, 이 코드는 100번중 1번 꼴로 참, 100번중 1번 꼴로 거짓 ... 이냐에 따라 쓰시면 될겁니다.

(잘못 쓰게되면, 프로그램의 성능에 지대한 영향을 미치기도 하니 ... 조심하셔서 쓰시길 바랍니다 ㅎㅎ)

또, Compiler를 어떤것을 쓰시느냐에 따라 다르겠지만,

GCC의 중간 표현(IR)인 RTL(Register Transfer Language)를 알아두실 필요가 있습니다.

최근 GCC-4.4.0로 올라가면서 Gimple Tree라는 것에 RTL의 역할을 약간 분담했습니다.

그리고 현재 C++0x의 지원과 관련하여 GCC-4.5.0에서는 이와 관련된 것들도 추가되었습니다.

본격적으로 GCC-4.6.0부터 C++0x를 지원한다고 하니, 참고하시길 바랍니다.

또, 분기 예측과 관련해서 unlikely(), likely() 같은 GCC의 사기 기술?!이 있습니다.

오, 찾아 봤습니다. http://kerneltrap.org/node/4705

코드의 실행을 프로그래머가 예측해서 분기(branch)가 가급적이면 일어 나지 않도록 하여

CPU- Memory(Instruction) pipe 처리에 도움이 될거 같네요.

완전 사기 기술인데요? ㅋㅋ 좋은 정보 감사합니다. 나중에 회사 가서 써먹어 봐야 겠습니다. ㅋㅋ

이런거 좋아라 합니다. ^^

이외에도 유용한 GCC Built-in Function들이 존재하니,

적절하게 사용하시면, 상당한 양질의 프로그램을 만드실 수 있을 거라 믿습니다 ㅎㅎ

그리고 개인적으로 개발툴은 vi나 emacs를 추천해드리고 싶습니다 ㅋㅋㅋ

Unix의 설계 철학을 고대로 담고 있는 친구들이기에 ... 더욱 추천드리고 싶네요.

vi, gcc, gdb, binutils(as, ld, objdump, nm, addr2line등)들은 알아두시면,

Linux 환경의 개발에서 굉장한 Performence를 발휘할 수 있습니다.

참고로 전 윈도우쪽에서의 개발은 잘 모릅니다 ㅋㅋㅋ

대충 보니까 아마 #pragma인가 하는게 GCC의 __attribute__()와 유사하더군요.

기능은 GCC가 더 많을 겁니다(2010이 나오면서 어떻게 됫을지는 ... ?!)

흠 ... 그렇군요 ㅎㅎ

나중에 회사에서 어떤 툴 쓰시는지도 좀 알려주세요 ㅋ

저 같은 경우에는 vi외에는 개발시에 사용해본적이 없어서 ㅡ_ㅡ;;;ㅎ

다른분들은 어떤것을 사용하는지 궁금하네요 ...

맨날 찌질이 해킹툴 만드는 것만 관심 있다가

회사 들어 가면 아마 깨갱해야 할 듯 싶습니다.

잘하시는 분들이 많은 지라... ㅋㅋ

나중에 linux 개발 환경에 익숙해 지면 정보 공유해 BOA요. ^^

built-in function... 아, 별게 다 있군요.

일부는 MS 컴파일러 macro로 처리가 가능한 것들도 있고,

일부는 processor(CPU) 와 관련된 것들도 있고(생소하네요), ...

http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html

코드 최적화를 위해서는 반드시 알고 있어야 할 것(달달 외우고 있어야 할 것)들도 많네요.

아, 안돼... 자야 하는데. 이런거 보느라 잠을 못자겠네. ㅠㅠ

위에 말씀드린 ld와 관련해서는 Linker Script라는 것이 있습니다.

Windows CE에서도 이와 비슷한 것을 봤던것 같은데, 잘 기억이 안나네요 ㅡ_ㅡ;;;ㅎ

확장자는 *.lds이고, gcc로 컴파일할때, 같이 던지면, 알아서 링킹시에 처리합니다.

물론, gcc로 다이렉트로 컴파일 할 일은 거의 없고, make라는 녀석을 이용해서 ... make 눌러놓고 놀 수 있습니다 ㅋ

사실 예전에 이걸 악용한 적이 있는데, make에다가 이상한 스크립트 무한 루프 돌려놓고,

아 ... Kernel Compile 너무 오래걸려요 ... 했었던 기억이 ... ㅋㅋㅋ

그러고 플래시 게임했었다는 ;;;

RTL이라... 실제 machine에서 돌아갈 수 있는 object code로 변환되기 이전 단계로 보이는데... 코드 최적화를 분석하기 위해서 assembly보다가 RTL을 보는게 더 편리할 거 같군요. 맞나요? ㅎㅎ

고전적인(classical) C/C++ 언어만 알고 있는 상태에서, 평소 컴파일러의 최적화만 믿고 중간 과정의 최적화에 대해서는 별로 신경을 쓰지 않았는데, 공부를 좀 해 둬야 겠군요. 아, 좋은 정보들 너무나 감사합니다. ^^

스터디 한번 하면 불러 주세요. 저같은 linux-newbie에게 도움이 될 수 있는 정보를 줄 수 있는 자리가 있다면 정말 좋겠군요. ^^

제가 큰 도움이 될 수 있을진 모르겠군요 ^^;ㅎ

워낙 "gilgil"님께서 실력이 출중하시니 ;;; ㅋ

현재 진행중인 Project가 있는데, 아마 이것이 끝나고나면,

대충 8월쯤이 될듯 하고, 이때부터 준비를 많이 해서 Kernel 특강을 할 생각입니다.

그때 더 많은 정보를 공유할 수 있지 않을까 생각되네요 ?! ㅋ

가령 커널에서 메모리 최적화 장벽이라는 barrier()등 ...

이러한 core level에서의 코드 최적화에 대해서는 완전 잼병입니다. End user 를 위한 GUI 기반의 프로그램으로 밥 벌어 먹고 살아 왔기 때문에, 삽질에만 능할 뿐이죠. -_-;

Linux-H4cker님이 얘기하는 이러한 것들을 전혀 모르는 저 같은 사람한테는 큰 도움이 될 것 같습니다. ^^

만약 컴파일러를 고를 수 있는 상황이라면 icc 쪽을 추천.

x86계열(IA32, EM64T, IA64) 에서만 쓸 수 있다는 단점은 있지만..

기능과 성능면에서 타 컴파일러가 따라올 수 없다는

GCC의 경우 Cache Prefetch Skill이 있어서

-march=i686 이런식으로 지정해주는 순간 오히려 더 좋은 성능을 얻을 수 있습니다.

물론 Hardware에 대한 지식과 RTL, Gimple 수준의 분석이 가능하다면, 더더욱 좋겠지요 ...

벤치마킹의 결과 성능 향상이 거의 6배 가량 좋아졌지요 ;;;

Intel Architecture의 경우 Speculation, Dynamic Scheduling등 ... hardware 차원에서 지원해주는 기능이 많습니다.

그래서 Compiler가 이녀석의 Dynamic Scheduling과 Speculation을 더더욱 지원해줄 수 있는 일종의 Tag를 만들어줍니다.

그래서 CPU와 Compiler가 서로 뗼레야 뗼 수 없는 관계에 놓여있습니다.

결론 : 위의 이유로 CPU 제작시 Compiler를 같이 설계하게 됨

물론 성능면에 있어서는 ...

상용 컴파일러들이 훨씬 최적화가 뛰어날겁니다 ?!

뭐, 어떻게 만들었을지는 모르겠지만, 이쪽 부분의 알고리즘들이 전부 NP-Complete이기 때문에

근사치 알고리즘 형태인 Greedy Algorithm, Heuristic Search등을 사용하는데, 결국 상용 컴파일러의 가격은 Binary의 최적화 수준에서 결정됩니다.

가령 나로호에 들어가는 RTOS를 컴파일해야 했다면, Binary 최적화 수준을 거의 99% 수준으로 했어야 ...

현존하는 상용 컴파일러중 Super Optimizer를 탑재하고 있는 컴파일러는 없습니다.

(컴파일 시간이 1년이 걸릴 수도 있는데, 중간에 컴파일 에러나면, 미칩니다 ㅋㅋㅋ)

CPU에 VHDL, FPGA등의 코딩을 할 때도 옛날엔 3일 걸리던 것이 이제야 겨우 1일만에 컴파일 하는데,

1일동안 아 ... 하는데, 이 하루만 해도 컴파일 에러가 나면, 환장합니다 ㅠㅠ

만약 컴파일 6개월동안 하는데, 에러나면 ... gg치고, 접싯물에 코박아야죠

이래서 하드웨어 코딩하시는 분들 성격이 상당히 ;;;

나쁘게 말하면, 까다롭고, 좋게 말하면 꼼꼼합니다.

미국 항공 우주 연구소(NASA)의 경우 VxWorks라는 현존하는 최강의 RTOS와 ...

현존하는 최강의 Compiler, 그리고 Math, Science Library를 보유하고 있습니다.

정말 무서븐 놈들이죠 ㅎㅎ

3축 GPS의 경우 사람 손등에 점을 찍어놓고, 거기에 미사일을 맞출 수 있다고 합니다 ㅡ_ㅡ;;;

(머지 않아 이것이 언젠가 상용화되면, 암살용으로 건물로 미사일이 날라올 삘)

 근데 미사일을 그렇게 정교하게 날릴 이유가 없는듯 =_=a 대충 날려도 알아서 다 작살나줄텐데.

그렇죠 ㅎㅎ

머지 않아 빛을 압축할 수 있는 기술이 나오게되면,

위성에서 레이저가 떨어지겠죠 ㅡ_ㅡㅋ

 오...

FF나 창세기전에서 보던 새틀라이트어택? 실현되면 얌전히 살아야겠군요 =_=a
찍히면 언제 어디서든 원샷이겠네

빛을 압축할 수 있는 기술이 구현된다면,

스타워즈에서 보던 광선검도 ... 실현화 됩니다.

실제 핵폭탄이 터지게 되면, 빛을 엄청난 속도로 응축시키게 됩니다.

순간적으로 응축되었다가 발산하게 되는데,

이때 이 응축된 빛을 맞으면, 형채도 남아있지 않고, 그냥 승화해버리죠 ...

저 멀리서 그 빛을 본사람은 눈이 멀게 됩니다.

이렇게 강력한 응축된 빛으로 구성된 광선검에 스치면, 그 부위는 그냥 싹둑하고 잘리겠죠 ...

이런 핵 기술에 대한 공식이 바로 E=(dm)c^2라는 아인슈타인의 공식이죠 ㅋ

핵이랑 빛이랑 뭔 상관이냐 하실 수 있는데,

위 공식에 보이는 c가 빛의 속도 30만 km/s입니다.

(1초에 지구를 7바퀴 반이나 돌죠 ㅎㅎ)

자세한 것은 현대물리학중 핵물리학을 공부하시면, 좀 더 깊은 내용을 아실 수 있습니다.

실제 GCC 소스 코드를 분석하게 되면, lang_hooks.parse_file();이라는 것을 볼 수 있습니다.

주로 이렇게 멤버 참조, "->" 포인터 참조등을 하는것은 Pointer of Function이죠 ㅎㅎ

저걸 까보면, c_common_parse_file()함수가 동작하는데, 저기서부터 translation_unit()이 들어와서 Generic Tree -> Gimple Tree를 형성합니다.

그리고 막판쯤에 pass -> execute()라는 녀석이 rest_of_handle_final() 함수의 포인터로 저부분에서 RTL Code를 Assembly Language로 변환합니다.

이때, 변환 과정과 그 전에 cgraph_init()에서 CFG(Control Flow Graph)에 대한 것을 생성하는 것을 볼 수 있는데,

실제 GCC의 최적화가 최고의 최적치가 아니라는 것이죠 ㅡ_ㅡㅋ

그래서 Gimple, RTL 수준에서 최적화를 해야합니다.

구글같은 경우에는 Gimple, RTL + 알파(기계어) 수준에서 최적화를 하더군요 ㅎㅎ

물론, 대한민국에서는 Gimple Tree와 RTL, 여기에 추가적으로 기계어 수준까지의 최적화를 기대하기엔 ...

빨리 빨리의 병패가 남아 있죠 ;;; (최적화는 꿈도 못 꾼다고 하네요 ㅋㅋㅋ)