64bit CPU에서 32bit OS 돌리는 것에 관한 궁금점
글쓴이: kaeri17 / 작성시간: 화, 2011/02/22 - 3:16오후
자게에 글을 쓰는건 오랜만이군요. 궁금한 점이 생겨서 물어보고 싶습니다.
제가 x86_64 CPU에 64 bit Ubuntu를 깔아서 사용 중입니다. 근데 몇몇 패키지는 32bit 밖에 지원을 안하더군요. Flash 플러그인도 64bit용 정식버전이 없는것 같고요. 그래서 32 bit Ubuntu를 깔아 보려고 하는데 궁금한 점이 생겼습니다.
만약 32bit 용 Ubuntu를 깔아도 64bit 용 프로그램이 잘 돌아가려는지 모르겠습니다. 뭐 당연히 실행하는거야 프로세서가 x86_64니까 문제가 없겠지만 관련 라이브러리들이 전부 다 32bit 용으로만 깔리니까 좀 출동이 생길 듯 한데요. 따로 64bit용 라이브러리들을 깔아줘야 하는 건가요?
혹시 이렇게 사용중이신분들은 어떠신지 알고싶습니다.
Forums:
OS가 32bit용이면 64bit용 응용프로그램은
OS가 32bit용이면 64bit용 응용프로그램은 돌아가지 않습니다.
꼭 그렇지는 않은걸로 아는데요...
Mac OS X의 경우 커널은 32bit지만 64bit 프로그램을 잘 실행 합니다. OS라고 말씀하신게 어디까지인지는 모르겠지만 커널에 한정지었을 경우에 32bit OS라도 64bit 프로그램을 돌릴 수 있습니다.
신기하네요. wow64 의 역으로 32비트 커널에
신기하네요. wow64 의 역으로 32비트 커널에 64비트용 서브시스템이 존재하는건가요?
======== 서명 =======
주거지는 www.indidev.net 입니다.
확인해보진 않았지만 안될것 같은데....
그게 가능하다면 32bit OS에 64bit 확장을 내놓았을것 같은데. 윈도든 리눅스든...
읽어볼수 있는 링크를 알려주시면 고맙겠습니다.
그건 그냥 macosx가 변태라서 그런거고 다른 데선
그건 그냥 macosx가 변태라서 그런거고 다른 데선 안되요. 별로 그렇게 할 이유도 없구요. 64bit 써도 별로 불편한 건 없을거고 32bit 유저스페이스 64bit 커널위에서 잘 돌아요.
응? 유니버셜 바이너리 아닌가요?
64비트가 진짜 64비트용으로만 컴파일 된건지 확인된 사항인가요?
보통 프러덕트 제품은 32/64 바이너리를 모두 포함하는 유니버셜 바이너리로 출시되는걸로 아는데요.
음.. 이상하네요-.-;
.
http://support.apple.com/kb/ht3773
64bit 커널을 의미하시는거 아닌가요? 32bit가 어떻게 64bit 주소체계를 다룰수 있을지 이해가 안갑니다.
userspace에서 아무리 주소를 던져봤자 전부
userspace에서 아무리 주소를 던져봤자 전부 virtual address에 불과합니다
이 64bit virtual address를 커널에서 physical address로 mapping하는거죠.
여기서 physical address는 32/64bit 두가지 다 가능합니다만,
4GB 이상 메모리 지원을 위해 64bit인 경우가 많죠.
참고로 PAE의 경우
32bit virtual address를 64bit physical memory로 mapping합니다.
.
제가 알고 있는 PAE는 한 어플리케이션이 쓸수있는 메모리의 양을 늘리는게 아니라, 커널이 다룰수 있는 메모리의 양을
늘리는 것으로알고 있습니다. 당연히 단일 프로그램은 4GB영역 밖에 접근할 수 없습니다. 32bit니까요.
64bit로 작성된 메모리 메핑과 관련이 없죠.
아직까지는 32bit 커널로 64bit을 메핑한다는걸 들어 본적이 없습니다. 그게 가능하더라도 구현할지 의문입니다.
메 포인팅마다 에뮬레이션해야 하는데, 전체 속도가 대단히 느려질겁니다.
그래서 Mac OS X가 32bit 커널을 쓴다는게 이해가 안가네요
일부만 32 bit을 쓴다면 모를까, 허나 일부만 쓰는것도 이해가 좀 힘들구요. ;;
이렇게 말하면 좀 웃기지만, 일단 제 말은
이렇게 말하면 좀 웃기지만, 일단 제 말은 맞습니다.
단지 저기에 뭐라고 설명을 달아야할지를 모른다는게 문제지요 - _-)...
이 자료가 도움이 될지도.... (바로 밑에 4개 그림)
paging에 대한 깊숙한 이해가 없다면 이해하기 많이 힘듭니다.
제 짐작으로는..
CPU가 64비트이고 응용 프로그램과 관련 라이브러리가 모두 64비트로 작성된 상태에서
커널만 32비트인 경우라면 일반적인 사용자 모드 코드에서는 별 차이가 없을 것 같습니다.
아마도 문제가 될 만한 경우는 시스템 콜을 통해 커널을 호출할 때
사용자 공간의 주소를 인자로 넘겨야 하는 경우 (ex. open/read/write)일텐데
응용 프로그램의 주소 공간 구성도 사실 커널이 담당할테니
64비트 주소 공간을 다 못쓰고 4G 이내의 주소 공간만 사용할 수 있을테고
만일 그렇다면 별다른 매핑 없이 64비트 주소 중 하위 32비트만 참조해도 문제가 없을 것 같습니다.
64비트 정수형 인자의 경우는 그냥 상위 word?를 무시해버리는 방법을 써도 되지 않을까 싶군요..
4GiB 이상 맵핑 해주는 걸로 알고 있어요.
4GiB 이상 맵핑 해주는 걸로 알고 있어요. 맥에서 멀티미디어 다루는 어플들 많이 쓰니까 걔네들 64bit 어드레스 스페이스 지원해주는 게 주목적이었을테구요. 리눅스처럼 커널이랑 유저스페이스 같은 어드레스 스페이스에 맵핑돼 있는 게 아니고, 유저 -> 커널 넘어갈 때 어드레스 스페이스 바뀌고 (리눅스에서도 32bit에서 4GiB 커널 스페이스 쓰는 패치가 이렇게 했었어요, 메인라인에 들어가진 못했구요) 커널에서 유저랜드 어드래스 참조는 하드웨어 트랜슬레이션 사용하지 않고 그냥 VM 테이블 찾아서 해당 물리 주소 찾아서 임시 맵핑해서 쓰면 되구요.
지저분한데다가 커널/유저스페이스 스위칭 오버헤드가 꽤 크고 (page table이랑 32/64모드 매번 바꾸니까 TLB야 코드캐쉬야 다 플러슁) 커널에서 유저스페이스 메모리 엑세스 비용도 되게 높지만, 커널 서비스 많이 사용하지 않는 어플들(멀티미디어 편집 같은)은 별로 상관없으니까요.
AMD64에서 physical address는 처음에
AMD64에서 physical address는 처음에 40bit였고 나중에 48bit가 되었습니다.
페이지 테이블상에는 52bit이고요.
physical address가 64bit인것은 못본거 같네요.
그건 맞긴 맞습니다만 - ㅅ-) 40bit,
그건 맞긴 맞습니다만 - ㅅ-)
40bit, 48bit이라는 숫자는 아키텍쳐에 따라 크게 변동되는 사항입니다.
그리고 page table이 52bit로 되있는 이유는
나중에 AMD64가 52bit physical address로 확장되기 때문이고
64bit 전부를 활용하지 못하는건 entry의 형식 때문입니다.
하여간 PAE의 이론에서는 크게 중요한 이야기는 아닙니다.
PAE에서도 physical address는
PAE에서도 physical address는 36bit 입니다.
그런데 그게 중요한 이야기가 아니면 뭐가 중요한 건가요?
도대체 무슨 근거로 physical address가 64bit인 경우가 많은건가요?
크고 아름다운 64bit page
크고 아름다운 64bit page directory/table entry
http://technet.microsoft.com/en-us/library/cc736309%28WS.10%29.aspx#w2k3tr_pae_how_khwu
http://en.wikipedia.org/wiki/Physical_Address_Extension#Page_table_structures
이래도 반박하시겠다면 그 전에 32bit paging system이라도 직접 구현해보세요.
칠판에 적어도 설명이 쉽지않은 주제라서 설명하는게 무척이나 힘듭니다.
PS
혹시나 해서 쓰지만
아주 정확하게 말해서 physical address는 64bit가 아닌건 맞습니다.
하지만 커널에서는 이걸 언제나 64bit chunk로 이용합니다.
실제 physical address의 size가 상관되는 부분은 PD/PT entry를 만들 때 뿐이고,
그 마저도 64bit chunk 주소값과 flag 값을 OR 시키는 작업에 불과합니다.
이래도 실제 physical address의 크기가 중요합니까?
그리고 64bit인 경우가 흔하다고 말한건
요즘 사용되는 시스템은 32bit라고 PAE가 많이 쓰이기 때문에 쓴 말입니다.
하지만 실제로 32bit 커널로 64bit application을 돌리는건 mac os가 유일무이하기 때문에 그다지 의미없는 말이죠.
http://en.wikipedia.org/wiki/
http://en.wikipedia.org/wiki/Physical_Address_Extension 에서도 "physical address size increases from 32 bits to 36 bits" 라고 되어있는데 님은 "참고로 PAE의 경우 32bit virtual address를 64bit physical memory로 mapping합니다." 라고 했습니다. 분명히 잘못되었다고 생각이 들지 않나요?
실제 physical address의 크기가 중요하냐고요? 어차피 커널이나 디바이스 드라이버를 코딩할때 physical address 크기가 36bit 든 40bit든 64bit 크기의 자료형에 집어넣기 때문에 중요하지 않다고 생각할 수 있습니다. 하지만 관점을 바꿔서 생각해보죠. 128GiB의 메모리를 가진 x86-64 컴퓨터가 있다고 합시다. 64bit 운영체제에서는 128GiB의 physical 메모리를 전부 사용할 수 있을 것입니다. 하지만 32bit 운영체제에서 PAE를 사용할때에는 64GiB의 physical 메모리만 사용할 수 있습니다. 왜냐하면 PAE에서 physical address의 크기가 36bit이기 때문이죠. "PAE의 경우 32bit virtual address를 64bit physical memory로 mapping"한다고 알고 있는 사람은 128GiB를 전부 사용할 것이라고 잘못된 판단을 내릴 수 있죠.
물론 님이 말하고자 하는 점이 physical address의 크기가 36bit든 64bit든 별 상관이 없을지도 모릅니다. 하지만 이 게시판을 많은 사람들이 보고있고 일부는 님의 글을 보고 "PAE에서 64bit의 physical 메모리를 지원한다"는 잘못된 지식을 가질수 있어서 제가 언급한 것입니다.
것보다는 그냥 단순히 용어가 정리가 안되서 그런 것
것보다는 그냥 단순히 용어가 정리가 안되서 그런 것 같습니다. - _-)
저도 저 글 쓰다가 중간에 용어가 꼬여서 좀 고생했다죠 [...]
제가 쓰는 기준으로는
address size라는 이름으로는 64/32/16bit를 의미하고
address space size로 2^40, 2^48, 2^52를 의미합니다.
제가 전자의 의미로 xx bit address라고 쓴걸
dg님께서는 실제 addressing에 사용되는 bit 수, 그러니까 log2(address space size)로 해석하셨네요.
그 의미를 제 방식으로 표현하자면 xx-bit (physical/virtual) address space 정도...?
으으으으음....
오해가 생기고도 남을 표현이기는 합니다만, 딱히 대체할 표현이 없네요 - _-)
32비트에서 64비트를 돌릴수 있다는게 말이 되는건가요?
논리적으로 64비트에서 참조 가능한 포인터가 있다면 32비트 커널에서 어떤식으로 참조하는지 참 궁금해지네요,
그냥 생각으로는 메모리가 32비트로 짤려서 왠지 돌아가질 않을거 같은데 말이죠
-----------
변태라는 그 소스코드가 설마 2개의 포인트를 조합해서 코드가 짜여져
있는건가요? 도스 시절 같은?
납득할만한 자료를 제시해주시면 좋겠습니다
승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스
소스를 직접 본적은 없어서 정확힌 모르겠는데,
소스를 직접 본적은 없어서 정확힌 모르겠는데, 32bit 커널에서 PAE 지원하는 것도 비슷해요. 피지컬 메모린 64bit으로 다루고, 맵핑안된 부분 필요할 때마다 맵핑해서 액세스하고 언맵하고, 드라이버에서 PIO해야 되면 버퍼 바운싱하고 그러면서 쓰거든요. 거기다 64bit 커널에 32bit 시스템콜들 맵핑하는 것처럼 반대로 만들어주면 지저분해서 그렇지 될거 같아요. 대게의 경우엔 64bit 커널 + 32bit 어플이 잘 돌면 문제 없으니 저렇게 거꾸로 하진 않는데, osx 경우엔 64bit 전환이 워낙 늦어진데다 써드파티 드라이버 업데이트 문제때문에 우선 저렇게 간 걸로 알고 있어요.
_
http://stackoverflow.com/questions/49934/how-come-a-32-bit-kernel-can-run-a-64-bit-binary
오 생각보다 많은 생각이 필요한 문제였군요..
저는 그냥 커널에서 간단히 해결하였을거라 생각했는데... 모두 감사드립니다. 많은걸 알게 되었네요. 결국 보통의 32bit OS에서는 64bit 프로세서의 기능을 전부 다 활용하지는 못한다는 말이네요... OS를 옮기는 것은 생각을 다시 좀 해 보아야 겠습니다.
일단 ㄱㄴ 부터 짚고 하고 가야합니다.
진정한 64bit, 32bit CPU의 정의.
진정한 64bit, 32bit OS의 정의.
AMD x86-64 구조.
AMD x86-64를 지원하는 OS의 구조
위 사항에 대해 머리속에 잡혀있다면 복잡할 거 없죠. 대게 질문자의 머리속에 진정한 64bit CPU의 대한 정의와 AMD x86-64에 대한 이해가 혼재되어 있어서 이런 질문이 나오죠.
추가로 말씀드리면 AMD x86-64는 진정한 64bit와는 거리가 있고,인텔 x86에서 PAE로 4기가 이상 어드레싱이 된다고 64비트라 절대 인정 하지않는다는 겁니다.
정품 소프트웨어 사용 캠패인
저도 그렇게 보이네요. 진정한 64bit CPU,
저도 그렇게 보이네요.
진정한 64bit CPU, kernel 인지 정의가 서로 달라서 의견이 뱅뱅 돌고 있는 것 처럼 보입니다.
진정한 64bit CPU가 뭔가요? 왜
진정한 64bit CPU가 뭔가요? 왜 x86-64가 진정한 64bit CPU가 아닌가요? 진정한 64/32bit OS의 정의는 또 뭔가요? 무슨 말씀하시는 지 전혀 모르겠어요.
이게 진정한 64bit 아키텍쳐라고 정의를 내리기
이게 진정한 64bit 아키텍쳐라고 정의를 내리기 간단하지 않다는 말이죠.
AMD x86-64 그리고 Intel EM64T 와 IA64 의 차이에 대해 이해 하신다면 왜 정의가 쉽지 않은지 이해 되실 겁니다.
음... 셋 다 나름 잘 이해하고 있다고
음... 셋 다 나름 잘 이해하고 있다고 생각하는데요. 어떤 차이가 있는건가요? 너무 두리뭉실해서 어떤 부분을 얘기하는 건지 전혀 모르겠어요.