대화:64비트 컴퓨팅
Talk:64-bit computing| Wiki Project 컴퓨팅 / 소프트웨어 / 하드웨어 | (정격 C급, 높은 중요도) | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||
색인
| ||
| 60일 이상 된 섹션은 소문자 Sigmabot III에 의해 자동으로 보관될 수 있다. |
언제?
이런 진술이 있으면 좋겠다.
현재 대부분의 독점적 x86 소프트웨어는 32비트 코드로 컴파일되고 있으며, 64비트 코드로 컴파일되는 것도 적다(트렌드가 급속도로 균등해지고 있지만).
"현재"가 언제였는지 독자들이 알 수 있도록 날짜가 적혀 있었다.
'Exabyte/Exbibyte' 용어의 사용 또는 동등성과의 불일치
나는 다음과 같은 두 문장이 다소 상반되는 정보를 담고 있다는 것을 알아차렸다.
- 소개 단락에서:
따라서 64비트 메모리 주소를 가진 프로세서는 바이트 주소 지정 메모리의 2바이트64(=16EB)에 직접 액세스할 수 있다.
- "프로세서의 제한"에서:
원칙적으로 64비트 마이크로프로세서는 16개의 EiB(16 × 10246 = 2 = 1864,446,744,073,709,551,616바이트 또는 약 18.4EB)의 메모리를 처리할 수 있다.
아마도 내가 여기서 뭔가 오해하고 있는 것 같지만, 내 눈에는 그런 것 같다. 264 == 264, 바이트는 바이트, 엑사바이트는 엑사바이트. 단위가 같을 경우 동일한 값, 동일한 단위 및 최종 결과는 동일한 값을 가져야 한다. 둘 다 18.4EB(EB) 또는 16EB(Exbibytes) 중 하나인데, 다른 것? 바이트 단위는 두 리퀴드 시스템의 공통 접지(1000 대 1024)이므로, 264 == 18446744073709552000 == 16 * 10246 ≈ 18.4 × 10006 ≈ 18.4 × 1018첫 번째 문장은 아마도 엑사바이트 대신 엑사바이트를 사용하는 것이었다. 주로, 16 Exbibytes ≈ 18.4 Exabytes그러나 일관성을 위해 값을 변경하고 같은 용어를 사용해야 한다. 댓글? Joedf (토크) 16:13, 2019년 10월 30일 (UTC)[]
2019년 12월 26일 이동 요청
- 다음은 요청된 움직임에 대한 비공개 논의다. 수정하지 마십시오. 후속 코멘트는 토크 페이지의 새로운 섹션에서 작성되어야 한다. 마무리 결정에 이의를 제기하고 싶은 편집자들은 마무리 토론 페이지에서 논의한 후 이동 검토를 고려해야 한다. 이 논의는 더 이상 수정해서는 안 된다.
이동 요청의 결과: 이동하지 않음. 다른 사람들은 이것과 일치하도록 움직일 것이다. — 아마쿠루 (토크) 16:42, 2020년 1월 2일 (UTC)[]
64비트 컴퓨팅 → 64비트 – 다른 "n비트" 기사들과 일치. WP:COMPANNAME + WP:타이틀콘이 WP를 능가한다.명사. (기술적 요청을 시도하였으나 이전 논의를 파악한 후 신속히 철회됨)네모스쿨 (토크) 20:36, 2019년 12월 26일 (UTC)[]
- against "64비트"는 64비트를 가진 것을 설명하는 형용사다. 나는 컴퓨터 아키텍처라는 이름을 가진 "n-bit 아키텍처"로 모든 기사를 옮기는 것을 지지한다.ZXCVBNM (TALK) 06:55, 2019년 12월 28일 (UTC)[]
- Oppose – 다른 것을 대신 수리하십시오. 디클라이언 (대화) 06:06, 2020년 1월 1일 (UTC)[]
역호환성
여기에는 양립할 수 없는 점이 있는 것 같다. 한편, 32비트 대 64비트 섹션에서는 '64비트 프로세서는 역호환성을 가지며 대부분의 32비트 소프트웨어를 처리할 것이다'라고 되어 있는 반면, 타임라인 섹션에서는 '2019: Apple이 macOS 10.15 "Catalina"를 출시하여 32비트 Intel 애플리케이션에 대한 지원을 중단한다. 어쩌면 둘 다 맞을지도 모른다(두 번째 것은 내가 알고 있다), 그러나 어느 정도의 명확화(아마도 '가장'이 의미하는 것에 관해서)는 순서인 것 같다. 이것은 사소한 문제가 아니다. 계속 사용하고 싶은 32비트 소프트웨어가 있어 Mac 업그레이드를 미루고 있다. --Brian Josephson (대화) 18:12, 2020년 12월 2일 (UTC)[]
- 기존 32비트 명령 집합에 64비트 지원을 추가하여 역호환 가능한 32비트 명령 집합이 있는 64비트 프로세서는 64비트 코드뿐만 아니라 이전 32비트 코드를 실행할 수 있는 운영 체제를 지원할 수 있도록 만들 수 있다. 대부분의 그런 프로세서는 그럴 수 있고, 그 프로세서들 중 일부는 32비트 모드에서 완전히 실행함으로써 32비트 운영 체제를 실행할 수 있지만 그렇지 않은 것도 있을 수 있다. 애플은 나중에 A 시리즈 프로세서와 M1에서 32비트 코드를 지원하려고 애쓰지 않았을 것이다.
- 그러나 이 프로세서에서 실행되는 운영 체제는 32비트 프로그램을 지원하지 않을 수 있다. iOS 11 이상 버전(따라서 iPadOS 13으로 시작한 iPadOS의 모든 버전)이 그러하며, macOS 카탈리나 이후 버전도 그러하다.
- 따라서 이 글에는 모순("호환성"보다 당신이 묘사하고 있는 것에 더 좋은 용어)이 없다. 첫 번째 인용문은 일부 64비트 프로세서의 기능을 설명하고, 두 번째 인용문은 특정 운영 체제의 특정 버전이 제공하는 기능을 설명한다. 가이 해리스 (대화) 19:09, 2020년 12월 2일 (UTC)[]
IEC 단위
@Guy Harris and Joedf: EXB 대 Exbibytes에 대해 위에서 사소한 논의가 있었음을 알 수 있으며, 이 기사는 WP의 지침에 반하는 것처럼 보이는 IEC 장치들로 가득 차 있다는 점에 유의한다.컴푸니츠. 소스 중 하나(AMD64 Programmer's Manual Volume 2: System Programming)를 확인하였고, 섹션 2.2.1 - 메모리 어드레싱의 24페이지(PDF 88 페이지)에 다음과 같은 구절이 있다(명확하게 하기 위해 강조된 부분이 추가됨).
가상 메모리 주소 지정. 가상 메모리 지원은 롱 모드에서는 64개의 주소 비트로 확장된다.
이를 통해 최대 16엑사바이트의 가상 주소 공간을 액세스할 수 있다. 레거시 모드에서 지원되는 가상 주소 공간은 변경되지 않는다.
물리적 메모리 주소 지정. 물리적 메모리 지원은 롱 모드와 레거시 모드에서 52 어드레스 비트로 확장된다. 이를 통해 최대 4페타바이트의 물리적 메모리에 액세스할 수 있다. 그
확장된 물리적 메모리 지원은 페이징과 페이지 크기 확장을 사용하여 달성된다.
이 출처는 결코 역사적인 것이 아니며, 올해 3월에 개정되었다. 인용된 다른 출처를 확인하지는 않았지만, 만약 우리의 출처가 페타바이트, 엑사바이트, 테라바이트(및 관련 PB, EB, TB)를 사용하고 있다면, 우리의 기사도 그렇게 해야 한다(WP가 아니더라도:MoS의 COMPUNITS 지침은 자체만으로도 충분해야 하지만, 단순히 말하자면, 출처도 IEC 단위를 사용하지 않고 있다.) 킬로바이트(KB), 메가바이트(MB) 및 기가바이트(GB) 대 IEC 접두사 변형에서 JEDEC 메모리 표준을 고려하십시오. 기사가 출처와 일치하도록 만드는 데 합리적인 이의가 없는 경우 기술 문서에서 표준 용도를 준수할 수 있도록 전환하겠다(GB 및 TiB의 예는 Windows 및 Windows Server의 다양한 버전에 있는 메모리 제한에 대한 Microsoft 개발자 기사 참조). 그리고 더 큰 매체에서. —Locke Cole • t • c 18:21, 2021년 4월 14일 (UTC)[]
- 수정을 실행했다. —Locke Cole • t • c 16:56, 2021년 4월 16일 (UTC)[]
