대화:16비트 컴퓨팅

위키프로젝트 컴퓨팅 (정격화된 출발 등급, 높은 중요도)
WikiProject icon이 글은 위키백과에 관한 컴퓨터, 컴퓨터, 컴퓨터, 정보 기술의 커버리지를 개선하기 위한 공동 노력인 위키프로젝트 컴퓨팅의 범위 내에 있다. 참여하려면 프로젝트 페이지를 방문하여 토론에 참여하고 열려 있는 태스크 목록을 확인하십시오.
Start-Class article 시작 이 기사는 프로젝트의 품질 규모에서 스타트 클래스로 평가되었다.
높은 이 기사는 프로젝트의 중요도에 대한 높은 중요도로 평가되었다.

제목 없음

안녕 친구들.

16비트 단어와 32비트 단어 사이의 기본적인 차이점이 무엇인지를 어느 신체에서나 조금 설명할 수 있을까? 나는 단지 16비트보다 32비트 단어의 실제 이점이 무엇인지 알고 싶다.

안부 전해요

라헬

물론이지
기본적으로 이런 식입니다. 컴퓨터의 워드 크기가 16비트인 경우, 한 단어에 최대 2^16 = 65536의 다른 조합을 저장할 수 있다. 이러한 조합은 종종 0에서 65535까지의 숫자 또는 -32760에서 32759까지의 메모리 위치 또는 메모리 위치로 간주된다.
더 큰 숫자가 필요하거나 더 많은 메모리가 필요한 데이터를 추적해야 하는 경우 두 단어를 사용해야 한다.
숫자를 저장하는 데 두 단어를 사용하면 숫자를 계산하는 데 걸리는 시간이 증가한다. 이는 예를 들어 한 번의 작업에서 두 개의 숫자를 추가하는 대신 더 많은 작업이 필요하기 때문이다.
그러나 32비트 시스템을 사용하는 경우 4294967296의 다른 조합을 사용할 수 있다. 즉, 단일 단어를 사용하여 더 큰 숫자 또는 더 넓은 범위의 메모리 위치에 대한 참조를 포함할 수 있다.
따라서 32비트 기계는 프로그래머들의 삶을 더 쉽게 만드는 보너스를 더하여 동일한 클럭 속도에서 더 나은 성능을 발휘할 것이다. (마지막 비트는 일부 프로세서 제조업체(Intel Spring to Mind)와 OS 개발자(예: Microsoft)가 16비트 단어의 제한을 극복하기 위해 선택한 방식과도 많은 관련이 있다.)
이게 도움이 되었으면 좋겠어.
그럼 안녕히 계세요,
시노부 07:12, 2005년 8월 31일 (UTC)[]

16비트 DOS 및 Windows 1.0/2.0 응용 프로그램

그 애플리케이션들은 8비트가 아닌 16비트였다. 8088은 16비트 명령어 세트와 8비트 버스를 갖춘 프로세서였습니다. 그것은 버스 폭이 아니라 명령어 세트였습니다. 응용 프로그램의 "폭"에 있어서 말이죠. 가이 해리스 (토크) 2008년 1월 20일 18:56 (UTC)[]

메모리 어드레싱

그렇다면 16비트 프로세서 주소가 몇 킬로바이트나 되는가?--169.232.119.28 (토크) 02:11, 2008년 5월 1일 (UTC)[]

이것과 다른 페이지를 보면, = 비트, 즉 8192바이트(옥텟) 또는 8 kibytes를 다룰 수 있는 것으로 보인다. "킬로바이트"라고 하면 8.192KB이지만, "1,024바이트"를 의미한다면, 현재 윈도우와 내 생각에 매킨토시가 사용하고 있는 "8KiB" 입니다. Eebster the Great (talk) 05:04, 2008년 9월 14일 (UTC)[]
이것은 실제로 64 킬로바이트인 65,536 바이트 입니다. CPU는 특정 기법을 사용하여 ALU의 폭보다 더 많은 메모리를 다룰 수 있다. 그 예로는 1메가바이트를 처리할 수 있는 20비트 물리적 주소를 가진 16비트 마이크로프로세서인 Intel 8086이 있다. 리락 (토크) 07:58, 2008년 9월 14일 (UTC)[]
Eebster는 모든 비트에는 자체 주소가 있지만 주소 지정은 바이트 단위로 이루어진다고 가정했다. 그러므로 Eebster는 8인자였다. 시노부 (토크) 03:03, 2008년 10월 4일 (UTC)[]
전화 잘 받았어; 미안해. 나는 내가 실제로 답을 알고 있는 질문에 대답하는 것을 제한해야 할 것 같아. Eebster the Great (talk) 05:12, 2008년 10월 4일 (UTC)[]
하지만 우리가 이미 알고 있는 것을 고수한다면, 우리는 어떻게 아무것도 배울 수 있을까? 나는 플랫 메모리 모델에서 16비트 주소를 사용하여 2 = 주소 지정 가능한 위치 중 최대 하나를 지정할 수 있다는 데 동의한다. 바이트 어드레스 가능한 메모리와 함께 64KiB를 제공한다. 그러나 일부 16비트 디지털 신호 프로세서는 16비트 워드 어드레싱 가능 메모리를 사용하므로 128KiB에 해당하는 메모리를 직접 처리할 수 있다. 그러나 일부 시스템에는 플랫 메모리 모델이 없다. Rilak가 암시했듯이, 일부 시스템에는 CPU가 훨씬 더 많은 메모리를 간접적으로 처리할 수 있도록 은행 스위칭 또는 메모리 분할을 사용하는 하드웨어가 있다. 68.0.124.33 (대화) 20:20, 2008년 10월 24일 (UTC)[]의해 서명되지 않은 의견 추가 준비

좋은 지적이야! 나는 우리가 그 기사, 그리고 아마도 모든 n-bit 기사들을 명확히 해야 한다고 생각한다. 리락 (토크) 08:48, 2008년 10월 25일 (UTC)[]


아직도 68000을 32비트라고 생각하니까 Z80과 6809는 여기로 가야 하지 않을까?

당신은 16비트 ALU와 데이터 버스가 있든 상관없이 항상 등록이 32비트인 것 외에는 68000을 32비트라고 생각하지만, Z80과 6809 16비트를 같은 추론을 가지고 있음에도 불구하고 절대 부르지 않는다? 서명되지 않은 의견75.57.174.145 (대화) 16:06, 2009년 5월 16일 (UTC)[]까지 추가하는 준비

16비트 CPU/MPU 목록을 추가하시겠습니까?

나는 이 페이지에 8비트 페이지의 목록과 같이 16비트 CPU와 MPU의 통합 목록이 있으면 유익할 것이라고 생각한다. 이렇게 하면 독자들이 이리저리 돌아다닐 필요 없이 모든 16비트 아키텍처와 프로세서를 쉽게 탐색할 수 있을 것이다. 그러므로 나는 내가 알고 있는 프로세서와 아키텍처로 이 기사에 불완전한 목록을 추가하고 있다. 이것을 하는 더 좋은 방법이 있거나 목록에 추가할 것이 있다면 얼마든지 도와줘. 다이복스 (대화) 03:10, 2011년 5월 3일 (UTC)[]

16비트 응용 프로그램

[1]이(가) 개선되었는가? 나는 나아질 것 같지 않다. BTW, 나는 급히 롤백을 사용했고 다른 변화들을 파괴했다. 나는 단지 "x86 아키텍처에서, 16비트 애플리케이션은 일반적으로 ...을 위해 작성된 소프트웨어를 의미한다"는 것에 반대하며, 기사의 다른 부분의 변경에 대해서는 무관심하다. Incnis Mrsi (talk) 21:35, 2013년 7월 26일 (UTC)[]

I'm still looking for documentation, but there might have been 16-bit applications written for UNIX System V/286 that ran, along with 32-bit applications, on UNIX System V/386, and the same might have applied to pre-386 and 386 Xenix, so there might have been 16-bit applications not written for "MS-DOS, OS/2 1.x or early versions of Microsoft Windows". 이 용어는 주로 DOS, OS/2 및 Windows 애플리케이션에 적용되지만, 당시 x86용 UNIX 응용프로그램이 상대적으로 적었더라도 그것에만 적용되지는 않을 수 있다. 가이 해리스 (대화) 22:28, 2013년 7월 26일 (UTC)[]
또한, 이론적으로, PC 호환성이 아닌 다른 기계에서 실행되어 16비트 대 32비트 구분이 적용되는 OS의 버전이 있을 수 있다.
(BTW, 당신이 반대했던 것 말고 HLACHman의 모든 변경사항을 되돌려 놓았어.) 가이 해리스 (대화) 22:36, 2013년 7월 26일 (UTC)[]
두 분 모두 이 문제에 관심을 가져주셔서 감사하다. 나는 어느 쪽이든 괜찮다. (둘 다 내 것이다!) 나의 두 번째 문구는 개선되었는가? 32비트 어플리케이션 기사에서 빌려온 것인데, 내 첫 번째 문구보다 더 간결하게 들렸기 때문인데, 동시에 동의어(그 점은 확실하지 않지만)라는 것이다. 어느 쪽이든, 나의 주된 의도는 만약 그 단락이 PC 중심이라면 그렇게 선언하는 것이다. 왜냐하면 나의 첫 번째 문구(04:46, 2012년 6월 11일) 전에는 단지 "16비트 애플리케이션은...을 위해 작성된 소프트웨어일 뿐이기 때문이다. (다양한 PC 플랫폼)...." 그것은 예를 들어 PDP-11 프로그램을 "16비트 애플리케이션"이라고 할 수 없다는 것을 암시하는 것 같았다(호환성 모드에서 VAX에서 실행될 수 있는 경우에도). 그래서 나는 지금 있는 그대로의 문구를 남겨도 괜찮아. 문단(제닉스 등)의 나머지 쟁점에 대해서는, 어떻게 해야 할 것인지 잘 모르겠다. 내 다른 편집사항들을 복구해 준 Guy에게도 고마워. HLACHman (talk) 23:59, 2013년 7월 27일 (UTC)[]

리드 및 타이틀

나는 이것을 64비트 컴퓨팅에서 몇 년 전에 했지만 아무도 따라오지 않았다. 그래서 이제 나는 여기서 그것을 했다. 제목을 명사화하여 리드 템플릿을 폐기한다. 나는 의견을 초대하고, 다른 사람들이 32비트나 다른 곳에서 좋은 일이나 더 나은 일을 하도록 초대한다. 디클라이언 (대화) 06:36, 2014년 12월 14일 (UTC)[]

코드네임 리사는 움직임과 편집을 되돌렸고, 편집 요약에서 사물을 "stupid"로 묘사하는 사람들이 종종 "stupid"로 묘사되는 것의 목적을 신성화하지 못하는 놀라운 방법이라고 말한다. 나는 여전히 바보라고 생각하고 있으며, 모든 기사들을 같은 패턴을 따르도록 하는 것이 요점이라는 것을 이해한다고 생각하지만, 패턴 자체는 어리석고, 고치기 어렵다. 그가 그 문제에 대해 이야기하러 오지 않았으니, 나는 그의 관심을 다시 끌 것이다. 디클라이언 (대화) 02:11, 2014년 12월 15일 (UTC)[]

안녕. 내가 이 글을 쓰는 것은 매우 어려운 일이야. 일전에 이 메시지를 작성하는 동안 딕 라이온은 WP를 위반했을 뿐만 아니라,BRD나를 "애스홀"이라고 부르기도 했는데, 사실상 2번 기둥에 부딪쳤다. 그래서 중간에 낙태했다. 토론은 백과사전을 편집하기 위해 온 사람들을 위한 것이고 딕 라이온은 확실히 WP의 한 예다.NOTHERE, 그의 편집 전쟁에서 보여지듯이. 그래도 나는 내 분쟁 당사자가 토론을 시작했다면 그 전에 한번도 토론을 회피한 적이 없었다. 나는 이 사건이 예외가 되는 것을 원하지 않는다. 실제 논의를 위해 사용자 Jeh와 플리트 커맨드가 이 토론에 참여하도록 요청한다. 전자는 많은 CPU 관련 기사에 기고하고 후자는 MOS:COMPUTING의 주요 저자다.
딕 라이온의 편집 문제는 두 가지다. 첫째, "16비트 컴퓨팅"은 WP:공통 이름 문제. 반면에, 이름을 바꾼 이유는 ... 글쎄, 현상유지가 "무서운" 상태라고 말하는 것 외에는 아무것도 제공되지 않는다. 그리고 그는 명사군이라는 제목에서 어떤 설명되지 않은 가치를 지니고 있는 것 같다.(글쎄, "16비트"는 명사군이며 WP:공통 이름 문제.) 둘째, 다시 쓴 리드는 완전히 잘못된 것이다. 그것은 다음과 같이 주장한다.

컴퓨터 아키텍처에서 16비트 컴퓨팅은 주로 정수 및 메모리 주소를 포함한 16비트 데이터를 사용하는 것이다. 즉, 데이터 요소의 폭은 최대 16비트(2 옥텟)이다. 16비트 폭의 레지스터, 어드레스 버스, 데이터 버스에 기반한 CPU와 ALU 아키텍처는 수십 년 동안 인기 있었다.

사실이 아님:
2014년 12월 17일 업데이트된 15:23(UTC)
  1. "Primary"는 족제비 단어틀린 말이다; 16비트 앱은 8비트 조합을 사용해야 하고 16비트 레지스터를 엄격히 사용할 수 있다; 다른 선택사항은 전혀 없다.16비트 모드의 CPU 레지스터는 엄격히 16비트다. 반면에...
  2. 데이터 요소는 최대 16비트여야 할 의무가 없다. 그것들은 8, 16, 32, 64 또는 128 비트와 같은 어떤 길이도 될 수 있다. 문자열의 길이는 임의로 제한되지 않는다. (실제 길이는 처음에 64KB였습니다.) 데이터 요소의 길이는 CPU 아키텍처가 아니라 프로그래밍의 문제다.
  3. 16비트 CPU와 ALU는 수십 년 동안 인기가 없었다; 그들은 심지어 10년(1978–1985) 동안에도 인기가 없었다. 당시만 해도 컴퓨터는 소비자의 제품이 아니었다.'10년'과 '인기'는 둘 다 출처와 설명이 필요한 족제비 단어다. 정확히 몇 십 년이야? 하나, 둘, 넷, 여덟, 백? 그리고 "인기"는 "일반적인 인기" 또는 "일부 전문분야에서 인기"를 의미하는가? 후자의 경우 필드를 정의하십시오.
안부 전합니다
코드네임 리사 (대화) 2014년 12월 15일 (UTC)[]
안녕, 코드네임 리사 사실 편을 들기 전에 딕리온가 먼저 하는 말을 듣고 싶다. 제는 나보다 훨씬 더 많이 알고 있다. 하지만 나는 딕이 주장을 펴기 위해 오랫동안 위키피디아를 방해하는 선을 넘었다는 것을 알 수 있다. 두 번째로 되돌리는 대신, 그는 틀림없이 당신에게 한 줄 떨어뜨리고 왜 당신이 동의하지 않는지를 물어본 것이다. 아니면... 적어도 이건 내가 항상 안고 있는 기준이야. 함대 사령부 (대화) 22:07, 2014년 12월 15일 (UTC)[]
첫째로, 몇 개의 nits는 CNL의 비판에 동의한다.
1. "기본적으로" 잘못됨; 16비트 앱은 8비트 레지스터와 16비트 레지스터의 조합을 사용해야 하며, 다른 옵션은 절대 없다.
그렇지 않다. 8비트 레지스터가 없는 16비트 아키텍처(HP 2100, Data General Nova, PDP-11)가 많다. 8비트 레지스터가 있다고 해도 "기본" 클레임의 정확성을 배제하지는 않는다.
2. 데이터 요소는 최대 16비트여야 할 의무가 없다. 그것들은 8, 16, 32, 64 또는 128 비트와 같은 어떤 길이도 될 수 있다. 문자열의 길이는 임의로 제한되지 않는다. (실제 길이는 처음에 64KB였습니다.)
나는 딕리온이 기계 "단어"에 맞는 데이터 항목과 그러한 데이터에 작용하는 프로세서의 산술적이고 논리적인 지시사항을 언급하고 있었다고 생각한다. 그렇다, 당신은 16비트 CPU에서 32비트 정수를 다룰 수 있지만, 당신의 모든 기본 운영에는 두 가지 이상의 지시가 필요할 것이다. 물론 어떤 아키텍처든 단어 크기보다 더 큰 데이터 구조에서 작업하기 위해 사용될 수 있지만, 그것은 아키텍처의 문제가 아니라 프로그래밍의 문제다.
3. 16비트 CPU와 ALU수십동안 인기가 없었고, 10년(1978–1985) 동안에도 인기가 없었다. 당시만 해도 컴퓨터는 소비자의 제품이 아니었다.
그것들은 컴퓨터 전체 시장 측면에서 확실히 인기가 있었다. 수명에 관해서는, HP 2100 시리즈는 1967년에 도입되어 약 30년간 지속되었다(HP 1000으로 갱신됨). 마찬가지로, DEC는 1970년에 최초의 PDP-11을 출하했고, 적어도 20년 동안 그들에게는 건강한 사업이었다. 퍼스널 컴퓨팅 세계에서 16비트 머신(8086~80286)이 32비트후드로 가는 길에 디딤돌에 불과했던 것은 사실이지만 퍼스널 컴퓨팅 세계가 컴퓨팅의 전부는 아니다. (대화) 2014년 12월 15일 23:00 (UTC)[]
이것은 컴퓨터 역사에 대한 매우 근시안적인 견해로서 컴퓨터와 "마이크로 컴퓨터"를 동일시한다. IBM 1130과 360/20은 1960년대 중반부터 매우 인기 있는 16비트 기계였다. 다른 시스템의 날짜는 잘 모르겠지만, 여기 어딘가에 목록이 있어. 피터 플래스 (대화) 2014년 12월 16일 (UTC) 17:00[]
안녕. 아래 Jeh에게 말했듯이, "인기"와 "주요 장소에 고용"이 혼동되어서는 안 된다. 어떤 것이 인기 있을 때, 거리의 모든 사람들은 그것에 대해 안다. 1130호는 수십 년 동안 이런 상태를 유지했는가? 거리에 있는 얼마나 많은 사람들이 IBM이 무엇인지 알고 있을까? 안녕하십니까, 코드네임 리사 (대화) 17:39, 2014년 12월 16일 (UTC)[]
인기는 상대적이다. 내가 언급하는 두 기계 모두 널리 사용되었다. 분명히 이것은 모든 책상 위의 컴퓨터 시대 이전이었지만, 1130년대가 1만 대 이상의 시스템을 팔면서 둘 다 시대의 기준으로 매우 인기가 있었다. PDP-11은 의심할 여지 없이 훨씬 더 인기가 있었다. 피터 플래스 (대화)20:20, 2014년 12월 16일 (UTC)[]
안녕, 제. 참여해줘서 고마워. 우선, 나는 나의 의견과 당신의 견적에 1년을 수정했고, 나의 목록 번호도 인용하기 위해 당신의 글의 일부분을 인용했다. 나는 그것이 너의 메시지에 대한 지나친 간섭으로 해석되지 않기를 바란다. 이제 앞으로 이동하십시오.
  1. 사실, 내가 네 말에 동의해서 놀랄지도 몰라. 전적으로. 사실, 나는 x86에도 8비트 주소 레지스터가 없다는 것을 안다; CS, DS, SS, ES는 16비트다. It does have general-purpose 8-bit registers but they are either available under 64-bit mode (R8 through R15) or are taken as a whole of their 16-bit parents, AX, BX, CX and DX. So, if I am going to fix my sentence according to your review, it would become: "Primarily" is wrong; a 16-bit app must use strictly 16-bit integers and address registers; 다른 선택의 여지가 전혀 없다. 그래도 "기본적으로"는 틀렸다.(정수는 8비트일 없다는 것을 명심하고, 반면바이트 순서의 8비트 측면은 항상 존재한다.) 사실 "기본적"은 정확하더라도 WP가 될 가능성이 있다.족제비.
  2. 다시 한 번, 놀랍게도, 나는 전적으로 너의 의견에 동의해. 하지만, 당신이 다루지 않은 것은 딕리온의 문구는 그가 단지 건축에 대해서만 언급하고 있다고 믿을 여지를 전혀 남겨두지 않는다는 것이다. 그것은 심지어 모호하지도 않다; 그는 자신도 모르게 프로그래밍에 대해 이야기하고 있다.
  3. 글쎄, 여기 드래곤이 있다; 알다시피 딕의 기여는 장수만을 다루지는 않는다. (그렇지 않으면 사과하고 동의할 것이다.) 그것은 그들이 "수 십 년 동안 인기가 있었다"고 말한다. 먼저 본질적인 WP를 다루자.족제비 문제: 몇 십년? 20년? 10년? 100개? 둘째, 이 컴퓨터들이 2000년 대학과 연구소에서 채택되었다고 하자; 20억 대의 컴퓨터가 있는 세계에서는 인기가 없다; 그것은 "주요 장소와 역할에 고용된" 것이다. 잘 들어, 이것은 인기 있는 것보다 더 중요해. 마이크로소프트의 사업계획은 다음과 같다. 그들은 대중에게 팔지 않고, 대량으로 사는 소수의 사람들에게 팔았다. 자, 이 사실 자체는 수정과 타협에 대한 전망을 보여주고 있다고 생각하지 않으세요?
안부 전합니다
코드네임 리사 (토크) 2014년 12월 16일 (UTC)[]
왜 정수는 8비트가 될 수 없는가? 피터 플래스 (대화) 2014년 12월 16일 (UTC) 17:00[]
내 위키백과 사용자 이름이 "피터 플래스"가 될 수 없는 것과 같은 이유! "Integer"는 어떤 것에 붙여진 이름이다. "8비트"는 이미 "바이트"라고 불린다. 안녕하십니까, 코드네임 리사 (대화) 2014년 12월 16일 (UTC)[]
예, 컴퓨팅에서 "integer"는 가능한 값이 정수의 하위 범위인 데이터 형식에 주어지는 이름이다. -128 ~ 127은 정수의 하위 범위여서 정수 데이터 형식은 8비트 길이일 수 있다. 그리고, 많은 플랫폼에서 16비트를 "하프워드" 또는 "워드"라고 부르기 때문에, 바이트가 8비트라는 사실은 바이트에 적분 값이 저장되는 것을 막지 못한다. 가이 해리스 (대화) 22:23, 2014년 12월 16일 (UTC)[]
CNL, 네가 완전히 틀렸어. 컴퓨팅에서 "integer"는 특정 크기의 특정 데이터 유형의 이름이 아니며, 그것보다 더 일반적이다. 당신이 주장하는 것은 당신이 이미 코드네임 리사라고 불리기 때문에 WP 에디터라고 불릴 수 없다고 말하는 것과 같다. 8비트 기준점은 일반적으로 "바이트"(또는 어떤 장소에서는 "옥텟")이라고 불리는 곳에 저장되더라도, 기계 지침에 의해 정수로 해석되고 조작되는 값을 거의 확실히 포함할 수 있다. C(예: 예)는 "char"라는 이름을 사용하며, 서명되지 않은 문자와 서명된 문자를 모두 사용할 수 있으며, 이 문자에 대해 일반적인 정수 산술을 수행할 수 있다는 점에 유의하십시오. 그게 정수가 아니라면 뭐지? 확실히 부동 소수점은 아니다! (토크) 23:52, 2014년 12월 16일 (UTC)[]
@: 인정. 관통했다. 다른 건 없어? 안녕하십니까, 코드네임 리사 (대화) 14:38, 2014년 12월 17일 (UTC)[]
나는 현재의 멍청한 템플릿이 만들어 내는 것보다 더 유연하고, 읽기 쉽고, 의미 있고, 관련성이 있고, 흥미로운 것을 위해서 특정한 표현을 강요하는 것이 아니다. 인기에 관해서는, 16비트 시스템이 8비트 시스템을 제외한 그 어떤 시스템보다 여전히 더 인기가 있다고 장담한다. 만약 당신이 그것을 보지 않는다면, 당신은 단지 매우 넓은 범위를 보고 있지 않을 뿐이다. 모든 차와 집에는 아마 각각 몇 대 이상이 있을 것이다. 디클라이언 (대화) 2014년 12월 16일 17:09 (UTC)[]
1960년대/1960년대의 16비트 미니컴퓨터는 20억대의 컴퓨터가 있는 세계에서는 채택되지 않았다. 개인용 컴퓨터가 도입되고 널리 사용되기 전에는 어떤 컴퓨터도 "인기"라고 표현할 수 없었다는 말인가? 가이 해리스 (대화) 22:27, 2014년 12월 16일 (UTC)[]
여기서도 GH에 동의하십시오. 테크트로닉스 465는 비록 길거리에 있는 보통 사람들이 들어본 적도 없고 아마도 상품 카테고리조차 알지 못하더라도, 합법적으로 그 날의 매우 "인기적인" 범위라고 불릴 수 있다. (토크) 23:52, 2014년 12월 16일 (UTC)[]
@Jeh and Guy Harris: 나는 정수형과 인기 둘 다 네 편이야. 먼저, 내 앞에 인텔 64와 IA-32 아키텍처 소프트웨어 개발자 설명서가 있는데, 4-3 Vol. 1페이지에서 정수를 부동 구성요소가 없는 숫자 데이터 유형으로 정의하고 있다. 그녀는 정수의 2바이트 정렬에 대해 정수의 정의와 혼동한 것 같다. 둘째로, 나는 컴퓨터가 전략적 자산이 아닌 비용이기 때문에 이전에 인기 있었던 적이 없었다고 주장했던 빌 게이트의 2002년 인기 코드네임 리사의 아이디어에 더 가깝다고 생각한다. 두 아이디어 모두 자신의 영역에서 유효하고 서로 다른 매개변수 집합을 사용하기 때문에 코드네임 리사의 무효 주장은 무효다.
하지만, 나는 여전히 CL의 반대 #1과 #3이 그들의 다른 이유 때문에 여전히 유효하다고 믿는다. 우리는 WP를 진지하게 가지고 있다.위즐WP:여기서의 부담 문제. 대체로 딕 리옹은 그의 이름값을 만한 비난받을 만한 태도를 유지하면서 문제가 없는 글을 문제없는 것으로 개종한 것으로 보인다. 그래서 나는 더 나은 버전이 작성되고 모든 이의 제기가 해결될 때까지 원본을 보관하는 것을 지지한다. 함대 사령부 (대화) 01:18, 2014년 12월 17일 (UTC)[]
BTW, {{subst:}}}템플릿을 편집하고 "컴퓨터 아키텍처에서 48비트 정수, 메모리 주소 또는 기타 데이터 단위는 최대 48비트(6옥텟)의 너비"를 "컴퓨터 아키텍처에서 48비트 정수, 메모리 주소 또는 기타 데이터 단위는 48비트(6옥텟) 너비"로 변경, 즉 "최대"를 이전에서 "최대"로 제거한다. "48비트(6옥텟) 폭" 가이 해리스 (대화) 03:30, 2014년 12월 17일 (UTC)[]
이의 #1:
레지스터 지향 기계의 16비트 앱은 당연히 최대 레지스터 너비보다 더 넓은 레지스터를 사용하지 않아야 한다. :-) 단, 그렇다고 해서 데이터 항목이 최대 레지스터 너비보다 더 넓은 것은 아니다. 1970년대 후반 16비트 PDP-11의 C 버전에는 32비트 통합 데이터 유형이 포함됨 장광설을 늘어놓다
{{n-bit} 템플릿에는 "컴퓨터 아키텍처에서 {{{1}}비트 정수, 메모리 주소 또는 기타 데이터 단위는 최대 {{1}비트 {{{2}}비트 폭의 정수"라고만 되어 있다. 그것은 특히 컴퓨터 구조를 언급하기 때문에 더 넓은 정수 산수를 허용하는데, 이것은 다중 산술 명령으로 수행되어야 할 것이다.
이 템플릿을 사용하지 않는 64비트 컴퓨팅은 "컴퓨터 아키텍처에서 64비트 컴퓨팅데이터패스 폭, 정수 크기, 메모리 주소 폭 등이 64비트(8옥텟)인 프로세서를 사용하는 것"이라고 말한다. 이것은 유사하다; 그것은 "프로세서"를 말하지만, 여전히 명령 집합 수준에서 말하고 있다.
나는 "컴퓨터 아키텍처에서 16비트 컴퓨팅은 주로 정수와 메모리 주소를 포함한 16비트 데이터를 사용하는 것이라고 확신할 수 없다. 즉, 데이터 요소의 폭은 최대 16비트(2 옥텟)이다." 리옹의 버전에서 보면 개선된 것이다. 예를 들어, 32비트 길이의 장신구를 허용하지 않는 것에서 장신구를 허용하지 않는 것으로 바꾸지는 않는다. PDP-11은 플로팅포인트 명령어 세트 중 하나(11/45의 플로팅포인트 프로세서와 함께 도입된 명령어 세트)가 24비트 분할 주소를 사용하여 32비트 정수(플로팅포인트와 변환되지만 산술은 없음)를 제한적으로 지원했지만, 약간 더 많은 족제비를 추가하여 그렇게 수 있다.엘리트어인 "primarily"
이의제기 #3:
"인기"는 시간과 시장 부문에 따라 다르다. 16비트 미니컴퓨터는 1970년대 내내 컴퓨터 시장에서 꽤 인기가 있었고, 16비트 개인용 컴퓨터는 적어도 1980년대 전반기에 꽤 인기가 있었다. 하지만, 여러분은 요즘 16비트 미니컴퓨터와 개인용 컴퓨터를 많이 찾을 수 없을 것이다. 이제 임베디드 애플리케이션에서 16비트 마이크로프로세서를 많이 찾을 수 있을 것이다. "인기"에 대한 어떤 이야기라도 단순히 "등록기, 주소 버스, 16비트 폭의 데이터 버스 기반의 CPU와 ALU 아키텍처는 수십 년 동안 인기가 있었다" 이상의 상세한 내용을 텍스트에 담는 것에 속한다고 말하고 싶다. BTW는 {{n-bit} 템플릿을 사용하는 동안 수행할 수 있다. 템플릿 뒤에 다른 섹션, 다른 단락 또는 해당 단락의 다른 문장에 넣으십시오.
그래서, 지금으로서는, 나는 "더 많은 논의가 있을 때까지, 있는 그대로 내버려두라"고 말할 것이다. 64비트 컴퓨팅에서 64비트 컴퓨팅으로 이름을 바꾼 Lyon의 근거와 {{n비트} 템플릿의 문제에 대한 일부 논의는 Talk:64비트 컴퓨팅#에서 확인할 수 있다.제목. 템플릿에 대한 그의 주장은 템플릿 토크에서 찾을 수 있다.N-bit#고대 템플릿의 지속적인 문제 템플릿의 장점에 대한 추가 논의가 거기서 이루어져야 하며, 이 또는 다른 "n-bit" 기사에서 템플릿을 교체하는 일은 거기서 거의 합의에 도달할 때까지 수행되지 않아야 한다고 제안하고 싶다. n-bit을 n-bit computing으로 개명하는 장점이 어디에 있는지 잘 모르겠지만, 나는 그것이 좀 더 논의되었고, 다른 기사의 개명을 하기 전에 합의에 가까운 무언가에 대해 논의되었으면 한다. 가이 해리스 (대화) 03:18, 2014년 12월 17일 (UTC)[]
나는 "16비트 컴퓨팅"에 열광하지 않지만, WP:TITLE은 제목이 명사나 명사등가여야 한다고 말한다. 이것은 확실히 "16비트" 그 자체로는 그렇지 않을 것임을 시사한다. (대화) 08:54, 2014년 12월 17일 (UTC)[]
아주 잘한다. 만약 당신이 "16비트 컴퓨팅"을 지지한다면, 나는 그것에 대한 나의 반대도 인정한다. 어쨌든 그것은 원래 내가 세 번 반대했던 것의 일부가 아니었다. 안녕하십니까, 코드네임 리사 (대화) 15:02, 2014년 12월 17일 (UTC)[]
@Guy Harris: 나는 이 실에서 네가 말한 모든 것에 전적으로 동의해. (그래, '기각 #3'에 기재된 내용에 동의한다는 것은 FC가 요청한 대로 유효점을 인정한다는 뜻이다. 「주장 #1」에 기재된 내용에 대해서는, 사실 제1항은 나의 이의 #2이다. Jeh가 말했듯이, 프로그래밍 문제는 건축 문제와 혼동해서는 안 된다. 그러나 이 문서에서는 16비트 아치 및 16비트 데이터 유형 모두를 별도로 다루도록 할 수 있다. 안녕하십니까, 코드네임 리사 (대화) 15:02, 2014년 12월 17일 (UTC)[]
좋아, 나는 그가 내가 여기서 시작한 대화에 대한 반응보다는 다른 곳에서 편집을 하러 갔다는 것이 약간 당황스러웠고, 그가 내 편집 내용을 다시 되돌리기로 결정했을 때 대화에 참여하겠다는 나의 제안을 받아들이기 전에 나는 조금 더 화가 났다. "멍청한" 동작이라고 생각하고 나는 그렇게 말했다. 물론, 비록 내가 다른 곳에 속박당했더라도, 이 특별한 자기 통제력 상실에 대한 변명은 없다. 그래서 나는 사과한다. 이제 본론으로 돌아가자. 내가 편집 요약에서 말했듯이 템플릿은 "stupid"이다. 편집자가 리드를 향상시키는 것은 매우 어렵게 만들는데, 이것은 극도로 어색하고 무의미하다. 그리고 제목에 대해서는, "컴퓨팅"이 이상적인 명사가 아니라면, 다른 명사를 찾아라. 현재의 형용사 제목은 그저 어리석다. "컴퓨팅"의 움직임은 64비트 컴퓨팅에서 받아들여졌다. 좋은 대안이 무엇인가? 디클라이언 (대화) 04:49, 2014년 12월 16일 (UTC)[]
그러나 당신은 비난받을 만한 행동을 계속하려고 하는 것 같다: [2]. 그렇지 않았다면 사과가 더 진실해 보였을 것이다. 솔직히 말해서, 나는 그녀의 복귀 이유가 당신이 편집한 이유보다 덜 그럴듯하다고 생각하지 않는다. (9.8이 멍청하다고 생각하고 진행 중에 뉴턴을 모욕하기 때문에 내가 g를 9.8m/s에서2 28로 바꾸는 것을 보지 못할 것이다!) 그리고 당신은 그녀가 돌아온지 15분 후에 반반전할 권리가 없었다. 내가 말했듯이, 그녀에게 공손한 말을 건네는 것이 옳은 일이었다. 함대 사령부 (대화) 01:18, 2014년 12월 17일 (UTC)[]
그럼 이제 "거짓말할 수 있는" 토크 페이지 코멘트의 리팩터링을 되돌리는 겁니까? 좋아, 내가 가서 너희들이 정리하거나 몇 년 더 두고 갈게. 디클라이언 (대화) 01:27, 2014년 12월 17일 (UTC)[]
당신의 요점 편집 요약은 그것이 당신의 의도가 아니었다는 것을 분명히 보여준다; 괴롭힘은 당신의 의도였고 그렇다, 괴롭힘은 비난받아 마땅하다. 우리 사랑하는 플래스 씨는 다른 사람의 메시지에 손대면 안 되고 내가 CL이라면 되돌리기 버튼을 눌렀을 것이다.(그러나 CL은 내가 알 수 있는 한 공정하게 대했다.) 물론, 만약 당신이 그런 거절을 좋아한다면, 나는 기꺼이 당신의 메시지 중간에 위키피디아에 있는 방해물을 따라다닐 수 있다. 하지만 더 공손한 방법은 내가 요점을 말할 수 없다는 것을 네가 이해한다는 것이다. 함대 사령부 (대화) 01:54, 2014년 12월 17일 (UTC)[]

인기, 일반 또는 기타

타이틀을 고치고 바보 같은 리드 템플릿에서 벗어나는 것에 관한 위의 부분은 16비트 컴퓨터가 오래 있었고 지금도 인기가 있다는 나의 제안에 의해 크게 탈선된 것 같다. 물론 내가 진정으로 의미하는 것은 소비자들에게 널리 알려지지 않은, 널리 사용되고, 널리 선택되고, 디자인된 것 등이었다. 하나 이상의 소스(List_of_common_microcontroller#에서 인용됨)텍사스_인스트루먼트사는 16비트 마이크로가 "가장 인기 있는 것"이라고 말하지만, 나는 그것이 의심스럽다. 거의 확실히 8비트 8051과 PIC가 더 인기가 있다. 디클라이언 (대화) 2014년 12월 17일 01:12 (UTC)[]

내 버전의 페이지로 돌아가기 위한 요청.

이 구간은 내가 이 구간에서 발견한 잘못된 정보로 인해 실제로 도전받을 수 있다. 섹션에서는 16비트 애플리케이션이 MS-DOS 운영 체제에서만 실행될 수 있다고 기술했다. 그것은 완전히 틀렸다. MS-DOS를 먹지 않은 32비트 Windows XP 또는 Windows 7은 16비트 응용 프로그램을 실행할 수 있다. 이러한 이유로 나는 그 절에 인용된 인용문들이 반드시 있어야 한다고 말하고 있다. 또한 이 섹션은 16비트 응용 프로그램에 대해 이야기하는 주요 목적이 무엇인지에 있어서 너무 작다. 이 섹션에는 더 이상 만들어지지 않는 이유부터 64비트 운영 체제에서 실행할 수 없는 이유까지, 이 섹션에 넣을 수 있는 다른 많은 것들이 있다. 그것이 내가 확장 섹션 태그를 배치한 이유다. 이것이 내가 내 버전의 페이지로 돌아가기를 요구하는 이유다. 미리 고맙다. 문의 손잡이747 (대화) 01:20, 2015년 3월 22일 (UTC)[]

어디에
IBM PC 호환Wintel 플랫폼의 맥락에서, 16비트 애플리케이션은 원래 16비트 Intel 8088Intel 80286 마이크로프로세서에서 실행되었던 MS-DOS, OS/2 1.x 또는 Microsoft Windows의 초기 버전을 위해 작성된 소프트웨어다. 그러한 애플리케이션은 주소 지정 가능한 메모리 위치의 범위를 16비트 주소만 사용하여 가능한 범위 이상으로 확장하기 위해 20비트 또는 24비트 세그먼트 또는 선택기 오프셋 주소 표현을 사용했다. 따라서 2바이트16(64 킬로바이트) 이상의 명령과 데이터를 포함하는 프로그램은 64 킬로바이트 세그먼트 간에 전환하기 위한 특별 지침을 요구하여 16비트 응용 프로그램 프로그래밍의 복잡성을 증가시켰다.
(이 섹션의 현재 버전) 특정 운영 체제에서만 실행할 수 있는 16비트 응용 프로그램에 대한 내용이 있는가? 특정 운영 체제용으로 작성된 것으로 알려지지만, MS-DOS용으로 작성된 일부 애플리케이션은 DOSBox를 사용하여 Android에서 실행될 수 있다. 즉, Linux 커널이 있는 운영 체제에서 실행될 수 있고 x86 프로세서가 아닌 ARM 프로세서에서 실행될 가능성이 있다! 요점은 사람들이 32비트 또는 64비트 Windows용 16비트 응용 프로그램을 쓰지 않는다는 것이다. - 16비트 DOS, OS/2 또는 Windows에 관한 것을 배우는 것 외에, 또는 Win32 또는 Win64 이외의 어떤 것에서도 실행될 것인지 신경 쓰지 않는다면, 16비트 응용 프로그램을 쓸 필요가 없다. 가이 해리스 (토크) 2015년 3월 22일 01:40, (UTC)[]

그 레드가 재미있는지 슬픈지 모르겠어...

나는 레드가 16개의 이진 비트의 값을 정의하지 않는 것이 재미있는지 슬픈지 잘 모르겠다. 나는 그것이 기사 어디에도 정의되어 있는지조차 확신할 수 없다. 재미있어야 하는데, 그냥 슬프다. 나는 "수학적으로 16개의 이진수 비트는 2^16 또는 65536까지의 다른 값을 나타낼 수 있다"라는 문장을 추가하려고 한다. 일반적으로 사용되지 않는 반면, 나는 트라이와 다른 다국가의 가능성이 존재한다는 것도 주목한다. 즉, 공식적으로 BININE 비트라고 불리는 이유가 있다. 또한 "16비트 정수"는 적어도 고전적인 의미에서 "컴퓨터 [cpu] 아키텍처"의 일부가 아니라는 점을 언급하고 싶다. (16비트) 산술 단위를 포함하는 CPU 아키텍처는 물론 그것과 함께 작동한다.) 나는 또한 버스 폭에 대한 언급이 기억력만큼이나 레더(또는 여러 버스)에서 두드러져야 한다는 점에 주목한다. 16비트 정수가 16비트 메모리 주소와 동일하다고 암시하는 것은 정말 오해의 소지가 있다. 또한 정말로 도움이 되지 않는 구절 "또는 다른 데이터 단위"는 제거되어야 한다. 16비트는 16개의 이진 비트를 의미하며, 각 비트는 1 또는 0 또는 +와 - (또는 불가사의하게 "ON"과 "OFF", "High"와 "Low" 또는 -1과 +1)를 나타내며, 총 65536개의 가능한 조합을 의미한다. (정수 0, 1, ..., 65535는 한 번에 16비트를 사용하여 가장 많이 나타낼 수 있다.) 현대 디지털 전자제품에서 트랜지스터(또는 다른 이진 논리 장치)는 정보를 저장(및 처리)하는 지배적인 수단이다. 데이터를 저장하는 트랜지스터는 더 효율적이고 더 빠른 데이터 처리를 위해 대개 더 큰 비트 그룹으로 결합된다. 비슷하게, 디지털 전자 칩(버스)의 다양한 부분들 사이의 연결은 보통 비트 그룹으로 데이터를 전송한다. 물리적 구현은 전압, 전류, 저항, 페이지의 표시, 자기 양극화, 스핀 양극화 등이 될 수 있기 때문에 비트는 정의상 추상적이다. 그러므로 이 글은 정보이론, 디지털전자, TTL, 디지털논리학(불행히도 여기서 부울대수학으로 명명된)과 논리 게이트.216.96.78.101 (토크) 17:58, 2015년 6월 11일 (UTC)[]을 참조해야 한다.

"bit"의 "b"는 "binary dig"에서와 같이 "binary"를 위한 것이기 때문에 "binary bit"라고 부르는 사람들은 중복성 부서 소속일 것이다.아마 "이진 숫자"를 의미했을 겁니다
첫 번째 단락의 처음 두 문장은 템플릿 N-bit에서 나왔으며, 템플릿의 토크 페이지에서 논의되어야 한다. 가이 해리스 (대화) 2015년 6월 11일 18:17 (UTC)[]
기묘한 형용사의 제목을 가진 이 기사들은 그들을 구속하는 기묘한 템플릿 때문에 더 이치에 맞는 편집조차 할 수 없다는 것이 참으로 슬프고 재미있다. 디클라이언 (대화) 2015년 12월 31일 (UTC) 20:23[]