geekforum: 64 bit로의 발전이 갖는 의미는?

김세권의 이미지

@ 64 bit로의 발전은 어떤 의미를 갖는가?

지금 널리 쓰이고 있는 PC들은 32 bit cpu를 쓰죠. Data Bus 크기도 32 bit이고요. 이제 슬슬 64 bit로 넘어가려고 하고 있습니다. 과연 computer가 64 bit가 되는 것이 어떤 의미가 있을까요? OS가 아주 많이 바뀌어야 할 것 같은데요. (컴파일러를 제외한 보통의 응용 프로그램들도 바뀔지는 잘 모르겠네요.) cpu가 64 bit로 바뀌면 다른 하드웨어들도 다 64 bit로 바뀌어야 할텐데.... 과연 64 bit로의 변화는 어떤 의미를 가지는 걸까요?

댓글

임택균의 이미지

원 질문 부터 이런 저런 문제가 있습니다.

보통 버스를 이야기 할때, 어드레스와 데이터 버스의 크기는 별개의
것이며, 이것 또한 내부 레지스터에 의존적이지 않습니다. 특히
데이터 버스의 경우 내부 레지스터보다 두배 이상인 것이 좀더
인스트럭션 수행에 원활한 결과를 갖고 옵니다. 그리고, 이미 PPro.이후
데이터 버스는 64비트 인 것으로알고 있습니다.

그리고, 만약, 64비트 시스템이라면, 당연히 데이터 버스는 128비트
이상인 경우에 원활한 파이프 관리가 가능합니다.

또한 파이프에 관한 인스트럭션 처리에 대하여 바이트 오더 처리에 대하여
알고리즘적 또는 아키택져의 부분적 속도 증가에 의한 빠르기는 있을지
모르지만 근본적인 처리방식의 변화는 거의 없을 것입니다.

오히려 64비트로의 진입은 32비트 이상 데이터 처리가 빠르고 원활해 지며,
따라서 사용자의 가변 데이터의 크기가 커지는 것을 의미있게 생각할 수
있을 뿐입니다.

어드레스 버스의 경우도 단인 레지스터가 64비트를 컨트롤 하게 되면,
당연히 주소 연산 작업이 빨라지겠지요! 그리고, 당분간 추가 레지스터의
도움 또한 필요 없을 것입니다.

제가 생각하기에는 이정도 인 것 같습니다.

임택균.

익명 사용자의 이미지

외계인의 계략이라 ^^;
한때 우리과 전공자들(전자공학)사이에 인텔 기술진들이 외계인이라는
농담이 유행했었죠. 영화 '인디펜던트 데이'에서는 지구의 컴퓨터 기술이 외계의 기술이라는 것을 증명하기 위해서 만들어졌다는 둥(왜 바이러스 코드가 호환되니까..^^;)
저는 64bit보다 예전에 만우절 거짓말로 만들어진 아날로그CPU가 진짜로
만들어 진다면 어떨까 하는 생각을 해봅니다. 진정한 인공지능이나 인공두뇌가 되려면 디지털이 아니라 아날로그를 100%활용할수 있어야 하지 않을까요? 단위 클럭당 비트연산이 아니라 말그대로 연속처리가 진짜로 가능하다면....
괜한 잡설이었습니다.

익명 사용자의 이미지

이건 분명 외계인의 개략입니다.

우리를 좀 더 어지럽게 64비트로 올려서 두배로 고생하게 할려고 말이죠

32비트일때도 용량 계산하는것도 헤메는데,,,

64비트면 더욱 엄청난 혼란으로 인류는 망할것입니다.

왜냐고요? 인텔과 삼성같은 반도체회사는 원래 우주에서

외계인들의 기술이전으로 반도체 만들어 팔아먹는

외계인 회사입니다.

익명 사용자의 이미지

인디펜던스데이 보면
외계인은 매킨토시 쓰는 것 같던데...

redbaron의 이미지

Linux가 64Bit 시대의 주인공이 되어야 한다는 의미.

64Bit 에서만은 독점운영체제들이 판치지말았으면...(이미 판치고 있지만..ㅋㅋㅋ)

이로써 좀 더 큰 패러다임을 가져야 한다는 의미.

클라이언트/서버 구조가 점차적으로 P2P 에 가까워 진다는 의미.

(왜? 클라이언트와 서버의 성능의 격차가 줄어들 것이므로..)

꼭 그렇다고 보장하진 못하지만 아니라고 할수없는 일.

가장 원하는 것은 Linux가 시장을 주도해 나가는 일.

잠이 오니 잡담이 되어군여...

그럼..이만.

꾸벅.

리눅스 만쉐~~(/`0`)/

익명 사용자의 이미지

아무리... 소용이 없다고 해도... 언젠가는 되겠죠.
2040년까지도 셀수없는...
.... 물론, 이것은 초단위 카운팅입니다.
32비트이기 때문에...
언젠가는 64비트로 넘어가야 한다는 군요...
(물론, gcc의 long long 과 같은 타입을 정의하면 되기는 하지만... ㅡ.ㅡ;)

익명 사용자의 이미지

제생각엔 32비트 메모리는 2^32 = 4G 메모리까지 어드레싱이 되겠죠...
그런데 펜티엄프로이상에서는 인텔은 PAE(물리적 주소확장) 모드로서 주소비트를 4비트 더늘려 2^36 = 64G 까지 어드레싱이 가능합니다.
커널 2.4 부터 인텔 PAE 모드를 지원해서 64G 까지 쓸수 있구요

윈도우즈 2000씨리즈는 서버는 4G가 한계
어드밴스서버는 8G까지
데이타 센타서버는 32~64G 입니다.
그런데 MS측은 64G를 지원하긴하지만 지원하는 보드나 아키텍쳐가 없다고 32G만 제대로 지원된다구 아주 애매한 문구를.... (저도 영어가 딸려서 제대로 이해를 했는지는 잘 모르겠습니당..)

64비트면 그런부분에서 더 유리지 하지 않을까 생각 됩니다.

요즘 DB 엑세스가 많은 데이타 같은거 4G 이상 우숩게 메모리 한번에 덤프할 필요가 있을때도 있거던요... 흠...

요즘 램 값도 떨어졌는데... 고용량 메모리 시대가 ... 흠,,

익명 사용자의 이미지

제 생각으로는 일반 유저 시장에서 64비트라는 것이 별로 큰 의미를 갖지는 않을 것 입니다. MIPS 나 Sparc이 64비트로 이행하였다고 해서 유저가 큰 득을 보는 것도 아니고 리눅스의 IA-64가 크게 진전을 보이는 것도 아니라는 것입니다.

개발 툴이나 어플리케이션이 따라 주어야 하고 (많은 시간이 걸리겠죠) 어쩌면 새로운 버스까지도 개발되어야 겠고 .. 아이태니움의 구조중 가장 중요한부분중 하나인 EPIC 의 사용법이나 이를 뒷받침하는 툴같은 것은 이제 시작이라고 보아야 합니다.

울트라 스팍에서도 개발된 코드가 솔라리스용 gcc인 경우와 선의 컴파일러를 사용한 경우와는 성능차이가 크게 납니다. 물론 시장이 커진다면 대규모의 개발이 이루어지겠지만 많은 시간이 소요돨 것으로 보입니다. x86의 경우 약 10여년 이상의 시간을 소모하였고 현재에도 gcc는 mmx나 simd같은 기능은 지원하지 않습니다.

물론 64비트는 중요한 영향을 미칠 것이고 많은 리눅스 업체가 이미 아이태니엄 버전을 출시 대기중이지만 특별히 아이태니엄을 선호할 이유는 없을 것이라는 점입니다.

대부분의 고성능 RISC 중 크게 성공한 것이 별로 없고 휴렛패카드의 HP-PA(아이태니엄에 가장 영향을 크게 미친)의 평가를 놓고 볼때 과연 무언가 확 좋아 질거라고 볼 수 있을지...

제 개인의 생각입니다.

익명 사용자의 이미지

몇가지 답변을 하려고 합니다.

mmx같은 것을 지원하는 컴파일러는 몇개 있습니다.
코드워리어(메트로워크)같은 제품은 c코딩에서도 mmx를 지원할 수 있습니다.
vc가 mmx를 지원하지 않는 것은 마이크로소프트의 사정이고요..

그리고 risc은 반드시 느리다는 것은 이해가 안됩니다. 각 risc구조마다 서로 자신들이 주장하는 설계논리가 있습니다. 상대적으로 우리가 진보된 cisc인 펜티엄이나 펜티엄 iii같은 것을 쓰고 있어서 그렇지 486 시절만 해도 risc구조의 워크스테이션이 더 빠른 것이 보통이었습니다. 펜티엄 이후 엄청난 개선이 이루어져서 86이 무지 빠르게 변한 것입니다.

현재 대표적인 cisc은 86계열과 68k정도이며 역시 대부분의 칩은 risc입니다. 아뭏든 아이태니엄에 대해 포팅이 이루어진 것만 발표하는 개발팀이 대부분이며 발표가 나야되겠지만 다른 64비트에 대해 이러이러한 점으로 인해 무척 좋다는 발표는 아직 본적이 없습니다. 그리고 개발 커뮤니티에서 이러한 점을 얼마나 빨리 반영하는 가에 대해서도 개인적으로는 무척 회의적입니다.

리눅스를 비롯하여 현재 우리가 사용하는 운영체제의 베이스는 20년간 별로 변한게 없습니다. System V 나 4.x BSD 코드는 거의 20년을 묵은 것들입니다. 리눅스도 따지고 보면 별로 새로울 것도 없습니다. 64비트의 칩이 하나 나왔다고 이들이 확 바뀔까요?

완전히 새로운 운영체제가 나오거나 대단한 개발팀이 새로 나타나지 않는한 별로 새로울 게 없는 상황입니다. 64비트 서버가 흔해지거나 가격대 변동이 없는 것을 빼놓고는 ...

제 개인의 주장입니다.

익명 사용자의 이미지

무엇이 mmx를 지원하는 컴파일러인가요? VC++도 인라인어셈블리를
써야 하는데.. 그건 gcc에서도 똑같이 가능합니다.

스팍에서 gcc가 느린 이유는 64비트라기보다는 RISC이기 때문입니다.
32비트 스팍에서도 gcc가 느린데요 뭐..

익명 사용자의 이미지

음냐.. gcc가 스팍에서 전용컴파일러보다 느린건... 당연한게 아닌가여?
SPARC CPU만 집중적으로 파서 성능좋은 컴파일러를 만들수 있는 환경을 가진 아마추어들이 얼마나 있을까요. SPARC CPU가 아마추어들이 가지고 노는 컴에 들어 있을 만한 물건도 아니고요.

임택균의 이미지

SPARC이 RISC라는 또는 RISC는이 범용 컴파일러에 주는 문제점은
RISC의 경우 대부분 특점 시스템의 여러 기능에 맞추어 최적화가
필요하기 때문입니다. 그것도 철저한.

임택균.

익명 사용자의 이미지

64비트로 발전한다는 것은 데이터 처리량이 제곱으로 늘어났다고 생각해보 되겠지요.

소니 플레이 스테이션이 128비트 프로세스로 광고되고 있습니다. 요즘은 엄청난 자료들이 처리되는 시대이니깐 기존의 32비트는 여러모로 역부족 있었을 겁니다.

초고속 인터넷도 급속도로 보급되고 VOD 조차도 포스트PC 같은 것으로 받아보는 여건이 조성되니깐 PC급에서도 이제 64비트의 상업화 부분이 맞아진다는 의미겠죠.

기존의 포화된 하드웨어와 소프트웨어의 새로운 수요창출을 일으키면 엄청난 경제성장이 발생될꺼고...

자꾸 지능화 되어가는 전산환경을 나타나는 것이겠죠.

2년정도 지나면 메니아급에서는 64비트의 환경인 PC를 사용하지 않을까 생각합니다.

성능이 제급으로 늘어난다면 그것의 응용분야는 정말 무궁무진 할겁니다.
몇년 후에 저장능력도 테라로 간다면 새로운 전산 패러다임이 이루어질지 모릅니다.

익명 사용자의 이미지

질문있습니다.

다룰 수 있는 메모리의 양이 32bit, 64bit 아키텍쳐냐에 따라 달라지는 겁니까? 32bit면 4기가만 addressing할 수 있다. 왜냐면 2의 32승이 4기가 라서 ... 이렇게 얘기를 하시는군요

32bit 컴퓨터에서 포인터를 64bit로 만들어쓰면 안되는건가요?

익명 사용자의 이미지

아키텍쳐 따라 달라집니다.

32비트라고 2^32 인건 아니고요, 아마 2^(32+8)=2^40승 일겁니다. ( 정확힌 모르겠음 )
그런데 상위 비트들을 os에서 사용하기 때문에, 실제로 각 프로세스 별로 사용할 수 있는 최대 메모리 양은 줄어듭니다. 이건 os별로 다릅니다.

인텔은 다른 cpu와 좀 다릅니다. 인텔이 원래 1M 가 바다만큼이나 넓게 여겨지던 시대에 나왔기 때문에, 처음에 1M 이상은 다루지도 못했습니다. 286 이후에 32 비트 메모리 체계로 바뀌었는데, 그래도 원래 칩과 호환성때문에 어드레스 체계가 좀 복잡해졌습니다. 오래되서 저도 정확히는 기억이 안나네요.

어드레스 할 수 있는 양이, 2^32 나 2^64 식으로 구해지는 것은 아니지만, 어쨌건 32bit냐, 64bit냐에 따라 다룰 수 있는 어드레스 양이 정해지는 것은 맞습니다. os 따라서도 다르고요.

익명 사용자의 이미지

과거 도스에서도 64KB 한계를 극복하기 위해 huge 포인터를 사용했었죠.
32비트 아키텍쳐에서 64비트 포인터를 사용하게 하면, 하드웨어적
한계를 제외하고라도 어쨌건 속도가 떨어지는 문제가 가장 클 것 같습니다.

익명 사용자의 이미지

64비트로의 발전은 이미 오래전 서버나 엔터프라이즈급 컴퓨터에서는 수년전 알파, 스팍등 64비트 cpu가 개발되었으며 발전하고 있습니다.
현대사회와 같이 빠르게 변화하는 정보화 사회에서는 대량의 데이터를 처리하고 가공하여 새로운 정보를 재생산하는 그런 반복적인 작업들이 많이 생기게 되었습니다.
대기업이나 중소기업들도 차츰 전산시스템을 도입하기 시작하였으며 이런 기업환경에 맞춰 대형 하드웨어 벤더에서 기존 32비트 cpu에서 성능이 향샹된 64비트 cpu를 개발하였으며 이를 탑재한 서버 컴퓨터가 출시되었습니다.
대표적인 것으로 썬의 스팍이나 컴팩의 알파 cpu가 되겠습니다.
서버나 엔터프라이즈급에서는 그리 이슈가 되지 않는 이야기입니다.
그러나 데스크탑 PC에서는 상당한 이슈가 되겠쬬!
실제로 서버의 대수보다 클라이언트, 데스크탑 PC의 숫자가 더 많습니다. 당연한 얘기죠!
서버 컴퓨터는 클라이언트와 비교할때 수많은 트랙잭션을 처리하기 위해 32비트로는 한계가 있으니 64비트로 데이터 버스 속도나 명령어를 확장했습니다.
기존의 32비트 명령어 셋과 64비트 명령어 셋을 동시에 지원하는 cpu도 있고, 완전히 64비트 명령어 셋만 있는 cpu도 있습니다.
즉, cpu에 따라 32비트 응용프로그램과 62비트 응용프로그램을 동시에 지원하기도 하며, 완전히 62비트 응용프로그래만 지원하기도 합니다.
컴파일러나 응용프로그램을 cpu에 따라 재컴파일해야 할때도 있고, 재컴파일없이 쓸수도 있습니다. 이것은 각 벤더들이 개발한 64비트 cpu에 따라 다릅니다. (자세한건 전문잡지를 보심이 ㅠㅠ)
그런데 인텔 cpu는 원래 데스크탑 pc에 장착되어 판매되었으며 펜티엄 출시 이후 꾸준히 발전하였습니다.
그러면서 cpu의 파워도 장난아니게 빠르고 높아졌습니다.
PC의 파워가 날아갈수록 서버파워에 가까워지고 있으며 현재 PC의 활용도가 날이갈수록 높아지기시작하면서 기존 32비트 cpu로는 한계에 다달았다고 합니다. 더이상 물리적으로 성능향샹은 힘들고 클럭속도만 높여가는 추세하고 합니다.(인텔인경우) 인텔씨퓨를 탑재한 중저가의 PC서버가 많이
팔리는 것도 그만큼 데스크탑용 cpu도 파워가 높아졌다는 단적인 사례입니다. 이런저런 이유로 인텔에서 64비트 cpu를 개발하고 있으며 곧 출시될 예정이며 이미 64비트에서 동작하게끔 포팅된 os(수세 7.2)가 다수 있습니다.
32비트에서 64비트의 전이는 단순한 cpu 파워 업그레이드뿐만이 아닌 32비트에선 한계가 있었던 많은 작업들이 64비트에서는 빠르게 처리하므로써 지금까지 기술적, 물리적으로 불가능했던 작업등을 가능하게 해주는 진정한 컴퓨팅 환경의 변화라고 볼수 있습니다. 데스크탑 PC에서는요!! ^^; 그리고 MS사도 64비트용 os를 준비, 개발하고 있답니다.
윈텔이라고 할 정도로 인텔과 긴밀한 관계를 가지고 있는 MS가 인텔 64비트 cpu를 지원안할수게 없겠죠!
짭짤하게 장사게 되었거든요! -_-+
리눅스 진영에서도 인텔 64비트 cpu에 포팅된 배포판이 많이 나왔으면 합니다. 좀더 빨라지고 확장된 리눅스의 파워풀한 모습을 보게 될려니
엄청 흥분됩니다. 64비트를 지원하는 리눅스와 MS 윈도우와 벤치마크했을때 과연 누가 강자가 될련지...

익명 사용자의 이미지

32bit 아키텍쳐들이 한계에 다달았다는 의미를 갖겠죠.

익명 사용자의 이미지

32bit 아키텍쳐 시장이 한계에 다다랐다는 게 더 정확하지 않을까요? 돈을 쫓아 움직이는 사람들이니까.

익명 사용자의 이미지

데몬들이 더 많이 돌수 있는건가 --;
현재 32bit도 개인이 쓰기에는 떡을치는 메모리 양인데

서버 형님들이야 부족하니까요. (몇기가인지 기억이 안나네요)
이제까지 온갖 잡기로 메모리를 늘려쓰던 서버 형님들께서

이제 진짜로 하드웨어 적인 메모리를 사용지원이 있으니
그쪽은 숨통이 트이겠죠.

물론 인텔이나, Windows, AMD 모두 자신들의 생산 라인을 32,64
로 잘라서 생산보다 64로 일원화 해서 판매하는것이 더 싸게

먹힌다면 개인용까지 내려 오겠죠 뭐 --;

정규현의 이미지

요즘쓰는 작업엔 턱없이 부족한 경우가 다수입니다.
예를 들면...
1. 수기가단위의 의 동영상 편집작업
( 1~2시간짜리 영상 편집하면 흔히 발생합니다. )
2. 수백메가 용량의 이미지 파일 편집작업
( 편집쪽에서 이런일 흔합니다. )
3. 레이트레이싱 방식 렌더링

이런 특수한 경우 말고도
제 경우에도 6만개 넘어가는 레코드 있는 엑셀파일 안열립니다...
이런 일 상당히 자주 있는데...

글고

파일용량 100메가 넘어가면, 이동하는데도 시간 꽤 걸립니다...
요즘엔 그런 파일 굉장히 자주 나오는데...

따라서
제가 보기에
이미 32bit 아키덱쳐는 한계에 이르렀다고 봅니다.

익명 사용자의 이미지

떡을 치기는 무슨... 항공기 도면도 하나 제대로 못여는데... 64bit이 되면
1장은 제대로 열 수 있겠지요?

익명 사용자의 이미지

한번에 4바이트씩 처리하는것보다 한번에 8바이트씩 처리하는게 당연히 빠르져...
2의 32승이면 4G밖에 안되잖아요. 요즘은 하드도 다들 30G씩 쓰는데.......

익명 사용자의 이미지

64비트의 의미는 128비트의 전 단계라고 할수가 있죠!!!

헐!! 128비트면 엄청 빠르겠죠!!!

익명 사용자의 이미지

그런답은 나도 하것다.
128 bit 은 256 bit 의 전단계겠죠.쩝

익명 사용자의 이미지

256bit 는 512bit의 전단계겠죠?

익명 사용자의 이미지

두 세살 먹은 아이들도 아니고... 말꼬리잡기 장난 같은 건 좀... --;

PS. 관리자께서 판단하시어 문제 있음 삭제하셔도 무방합니다. --

익명 사용자의 이미지

1024bit는 512bit의 전단계인가엽? -.-

익명 사용자의 이미지

트렌스메타의 크루소 칩은 128bit cpu 입니다.
조만간 등장하는 차기버전은 256bit라 하더군요.

일련의 64bit의 이슈들은 서서히 64bit가 대세로 등장함을 의미한다고 저는 생각합니다.
실제로 몇몇 64bit이상의 risc칩들은 수년전 부터 사용되어 왔으니까요...

익명 사용자의 이미지

Transmeta가 128Bit CPU를 만들어봤자...
x86구조이고 이 위에서 돌아가는 OS나 응용프로그램들이 32/16Bit인데
과연 128Bit CPU의 성능을 십분 발휘 할 수 있을까요?
제가 생각하기엔 Transmeta의 128Bit는 별로라고 생각합니다.
그들이 내놓는건 128Bit의 Register들이 아니라 트렌지스터 수를 줄여
소모전력을 줄이는 기술이니까요...

64Bit가 이슈를 타는것은 대세로 등장이 아니라 가장 많은 사람이 쓰는
x86 CPU가 64Bit로 가니까... 그것에 따른 당연한 관심아닐까요...

익명 사용자의 이미지

트랜스메타의 VLIW라는 기술은 아키텍쳐쪽 공부를 좀 해보시면 아실듯...
RISC나 CISC적인 접근과는 다른 제 3의 아키텍쳐인데요. 아직은 시작입니다만
만일 트랜스메타가 성공한다면 CPU역사를 바꾸게될지도 모를일입니다.
관심있게들 지켜보시길...

익명 사용자의 이미지

VLIW는 전혀 새로운 기술도 아니고 트랜스메타의 기술도 아닙니다.

이미지처리를 전문으로 하는 수많은 프로세서들을 보면 십중팔구 VLIW
아키텍처로 수년전에 나와 있습니다. 그렇다고 그런 프로세서들이
성공한 것도 아닙니다. 유연성이 떨어지고 거기에 맞게 최적화할
컴파일러 기술이 안 따라주니까요..

익명 사용자의 이미지

컴파일러 기술이 발전하길 기다리고 있는거죠 뭐 ^^;
HARDWARE의 발전과 SOFTWARE의 발전속도중 SOFTWARE의 발전이
빠를꺼라 기대하는게 VLIW가 다음 시대의 프로세서이길 기대하는
부류가 아닐까 생각되네요. RISC가 전혀 새로운 기술은 아니지만
90년도 들어와서 각광받는것처럼 시기가 무르익으면...... 뜰지도
모른다는거죠 뭐 그냥.. 헤헤~~

익명 사용자의 이미지

이전에 하버드 구조나 슈퍼 하버드 구조가 일반 computer의 cpu에 쓰이지 않았듯이 VLIW나 Hammer head등도 일반 computer의 cpu로는 적합하지 않은 것 같습니다. 그야말로 전용 processor로 적합한거죠. 써보니까 UI등의 연속성이 없는 곳에서 쓸때는 일반 cpu보다 효율이 적은 것 같더라구요.

그러나 여전히 필요한 분야가 있고, 앞으로도 쓰이겠죠.
사실 제가 듣기로는 한 십년전에도 그래픽 하는 사람들은 64비트 운용체계나 128비트 운용체계가 필요하다고 계속 주장했던 것 같은데 이제서야 시장의 흐름이 64비트로 온 것 같군요. 빨리 출발한 리눅스가 많은 성과를 얻기를 바랄뿐입니다.

익명 사용자의 이미지

이타니움은 X86아키텍쳐가 아닙니다.
단 인텔이 만들었다는 것 뿐이지요.

에이엠디의 해머는 X86아키텍쳐를 기반으로 하지만요;...

그리고 트렌스메타의 크루소는 X86아키텍쳐가 아닙니다.
소프트웨어 계층을 통해 에뮬레이션 해줄 뿐이지요....

익명 사용자의 이미지

제가 쓴 글에서 x86의 의미는 구리배선을 일리로 깔고
실리콘라인을 어떻게 한다는 의미의 구조가 아니라

mov eax, 1234
mov dl, 12
int 21
nop

이 x86을 얘기한겁니다.
즉! Assembly에서의 x86언어구조를 얘기한거죠.
만약 Itanium이 저 x86을 안쓴다면 기존의 프로그램들과
완벽한 벽을 만드는것인데... Intel이 그런식으로 할까요?
제 생각은 절대입니다.
그리고 크루소가 에뮬레이션을 한다고 해도,... 그리고
큰 레지스터는 필요없다 봅니다.

익명 사용자의 이미지

그것은 씨퓨 안에... 따로... 소프트웨어를 넣은 것입니다.

크루소도 그렇구요.

씨퓨라고 해서 소프트웨어를 넣지 말라는 법은 없죠.
(소프트웨어와 하드웨어의 구분이 모호하긴 해두... ㅡ.ㅡ;)

익명 사용자의 이미지

전에 인텔 홈페이지에서 이타니엄 메뉴얼을 다운받아 보았는데,

이타니엄은 상황에 따라 자신만의 명령어셋으로 작동하기도 하고,
이전의 x86 명령어로 작동하기도 합니다. 물론 이것을 설정하는
명령어와 레지스터도 있습니다.

이타니엄의 명령어셋은 x86과 완전히 다릅니다.

익명 사용자의 이미지

인텔 그런식으로 합니다.

익명 사용자의 이미지

제가 알기론.. IA-64 던가...? 하여튼..절케 불리는걸..쓴다더군요...
그래서..이전의 x86 계열의 호환성에..문제가 있을수 있다는...건..사실입니다

에뮬레이션..해서..돌아가는.걸로 아는데..
그것때문에..AMD 애들이 다른..64bit...명령어들을..x86-64..라고 하던가요~!?

(틀렸음..리플 달아주세욤;;에이 쨩퓌햇;;)
이걸 이용해서..기존의 x86-32 와 호환성을..유지하면서..64bit 로 넘어간다..

머 그렇게 한다는데..

어느쪽이..더 낳을진..인텔의..이테니엄..이..이나..AMD 의..해머씨리즈가..나오면
결판 나겠죠...그러고보니..해머씨리즈..제작에..트렌스메타가..지원해주는걸로..
아는데...맞나.?

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.