1960년대 제조사들처럼 전자식 논리가 아니라 전기기계식 논리를 쓴다면, bit paired keyboard가 훨씬 구현하기 쉬움
Shift 키는 ASCII 문자에서 비트 하나만 토글하면 됨. 지금은 모든 키보드에 범용 CPU를 넣고 논리가 사실상 공짜지만, 범용 컴퓨터가 방 하나 크기였던 시대에는 그런 해법이 훨씬 비쌌음
글은 ASCII 배치의 동기로 대소문자 변환을 비트 연산으로 효율적으로 구현할 수 있다는 점을 제시하지만, 그 가치는 역사적으로는 몰라도 현대적으로는 꽤 얇아 보임 a→A 변환은 단순 텍스트에서만 통하고, ISO-8859-1이나 Unicode가 ü, ç 같은 문자에도 이 배치를 일부 확장하더라도 대소문자 변환은 지역·문맥·시점에 따라 달라짐. ß나 ï의 올바른 대문자/소문자 대응은 언어, 규제 기관, 사용 지역, 시대에 좌우됨
Unicode는 https://www.unicode.org/charts/case/ 같은 대소문자 매핑과 접기 표를 제공해 흔한 경우에는 꽤 가까운 답을 주지만, 인간의 정책이 개입되는 문제라 복잡도는 사실상 무한하고 맞추려면 맞춤 소프트웨어가 필요할 수 있음
오늘날 Unicode의 처음 2⁷ 코드포인트에만 제한된다고 보장할 수 없다면 0b0010_0000 오프셋은 쉽게 깨지고, 단일 비트 연산보다 비싼 코드 경로가 필연적으로 들어감. CPython에서도 ''.upper는 unicode_upper{,_impl}의 ASCII 빠른 경로를 거치지만, 실제로는 분기, 인라인 함수, 구조체 접근, 여러 함수와 함수, 매크로를 거쳐 테이블 조회를 수행함
현대 언어의 ''.upper 구현은 대체로 비슷한 수준의 복잡도를 가질 것이고, 컴파일러가 최적화하더라도 현대적 접근은 단일 비트 연산보다 비싸질 수밖에 없어 보임. 이 설계의 이점은 원시 바이너리나 2⁷ 이하 코드포인트 Unicode 데이터를 담은 dtype=uint8의 numpy.ndarray에 산술 연산을 하는 식의 맞춤 소프트웨어에서나 두드러질 가능성이 큼
궁금한 건 이것임: 이 설계 선택의 유일한 동기가 글에서 말한 것이라고 가정하면, 당시에도 128바이트 조회 테이블이라는 대안이 있었을 텐데, 컴퓨팅 역사에서 단일 비트 연산이 128바이트 테이블 조회보다 더 효율적이거나 더 실현 가능했던 기간은 언제였을까?
오래 성공한 대중 기술을 파고들면 이런 종류의 비트 트릭이 자주 보임
어느 시점의 설계 선택이, 나중에 깨질 가정에 기대어 무언가의 형태를 고정하고 이후 확장을 어렵거나 불가능하게 만듦. 최근 IPv6 관련 글들에서도 IPv4와 IPv6의 당시에는 옳았던 선택들이 오늘날에는 거대한 부담이 됐다는 점이 드러남
호의적으로 보면, 이런 선택은 위험과 이득을 저울질해 내려졌을 것임. “문자 하나를 대문자로 바꾸는 데 단일 비트 연산이면 훨씬 빠르니, 언젠가 일본어 사용자가 생겼을 때 깨질 위험을 감수할 만하다” 같은 식임
현대인의 입장에서는 1976년의 선택이 2026년의 삶을 더 어렵게 만들지만, 1976년에 컴퓨터를 가진 적이 없다면 그 이득은 누리지 못했고 단점만 남음. 이런 이기심을 내려놓고 보면, 20년 뒤에도 인기 있을 소프트웨어를 만든다고 할 때 이런 선택의 지속 가능성을 어떻게 더 잘 예측할지 궁금함
Lobste.rs 의견들
설명은 괜찮지만 https://garbagecollected.org/2017/01/31/four-column-ascii/ 쪽이 더 잘 설명한다고 느낌
단순히 Shift만의 문제가 아니라 Ctrl도 관련됨. 예를 들어 Tab은 Ctrl-I인데, I가
1001001이고 Ctrl이 첫 비트를 마스킹해서 Tab의0001001을 남기기 때문임1960년대 제조사들처럼 전자식 논리가 아니라 전기기계식 논리를 쓴다면, bit paired keyboard가 훨씬 구현하기 쉬움
Shift 키는 ASCII 문자에서 비트 하나만 토글하면 됨. 지금은 모든 키보드에 범용 CPU를 넣고 논리가 사실상 공짜지만, 범용 컴퓨터가 방 하나 크기였던 시대에는 그런 해법이 훨씬 비쌌음
글은 ASCII 배치의 동기로 대소문자 변환을 비트 연산으로 효율적으로 구현할 수 있다는 점을 제시하지만, 그 가치는 역사적으로는 몰라도 현대적으로는 꽤 얇아 보임
a→A변환은 단순 텍스트에서만 통하고, ISO-8859-1이나 Unicode가ü,ç같은 문자에도 이 배치를 일부 확장하더라도 대소문자 변환은 지역·문맥·시점에 따라 달라짐.ß나ï의 올바른 대문자/소문자 대응은 언어, 규제 기관, 사용 지역, 시대에 좌우됨Unicode는 https://www.unicode.org/charts/case/ 같은 대소문자 매핑과 접기 표를 제공해 흔한 경우에는 꽤 가까운 답을 주지만, 인간의 정책이 개입되는 문제라 복잡도는 사실상 무한하고 맞추려면 맞춤 소프트웨어가 필요할 수 있음
오늘날 Unicode의 처음 2⁷ 코드포인트에만 제한된다고 보장할 수 없다면
0b0010_0000오프셋은 쉽게 깨지고, 단일 비트 연산보다 비싼 코드 경로가 필연적으로 들어감. CPython에서도''.upper는unicode_upper{,_impl}의 ASCII 빠른 경로를 거치지만, 실제로는 분기, 인라인 함수, 구조체 접근, 여러 함수와 함수, 매크로를 거쳐 테이블 조회를 수행함현대 언어의
''.upper구현은 대체로 비슷한 수준의 복잡도를 가질 것이고, 컴파일러가 최적화하더라도 현대적 접근은 단일 비트 연산보다 비싸질 수밖에 없어 보임. 이 설계의 이점은 원시 바이너리나 2⁷ 이하 코드포인트 Unicode 데이터를 담은dtype=uint8의numpy.ndarray에 산술 연산을 하는 식의 맞춤 소프트웨어에서나 두드러질 가능성이 큼궁금한 건 이것임: 이 설계 선택의 유일한 동기가 글에서 말한 것이라고 가정하면, 당시에도 128바이트 조회 테이블이라는 대안이 있었을 텐데, 컴퓨팅 역사에서 단일 비트 연산이 128바이트 테이블 조회보다 더 효율적이거나 더 실현 가능했던 기간은 언제였을까?
어느 시점의 설계 선택이, 나중에 깨질 가정에 기대어 무언가의 형태를 고정하고 이후 확장을 어렵거나 불가능하게 만듦. 최근 IPv6 관련 글들에서도 IPv4와 IPv6의 당시에는 옳았던 선택들이 오늘날에는 거대한 부담이 됐다는 점이 드러남
호의적으로 보면, 이런 선택은 위험과 이득을 저울질해 내려졌을 것임. “문자 하나를 대문자로 바꾸는 데 단일 비트 연산이면 훨씬 빠르니, 언젠가 일본어 사용자가 생겼을 때 깨질 위험을 감수할 만하다” 같은 식임
현대인의 입장에서는 1976년의 선택이 2026년의 삶을 더 어렵게 만들지만, 1976년에 컴퓨터를 가진 적이 없다면 그 이득은 누리지 못했고 단점만 남음. 이런 이기심을 내려놓고 보면, 20년 뒤에도 인기 있을 소프트웨어를 만든다고 할 때 이런 선택의 지속 가능성을 어떻게 더 잘 예측할지 궁금함
tolower는 아직도 유용함. https://dotat.at/@/2022-06-27-tolower-swar.html적어도 ASCII에서는 글자들이 연속되어 있음. EBCDIC은 간격이
0x40(64)이고, ASCII와 비교하면 9개짜리 줄 두 개와 8개짜리 줄 하나가 위아래로 쌓인 형태임https://en.wikipedia.org/wiki/EBCDIC
5비트 코드 http://www.quadibloc.com/crypto/images/tele38.gif 와, 기억이 맞다면 페이지 전환 제어 문자가 잔뜩 들어간 6비트 코드를 쓰던 일부 CDC 주변장치에 대해서는 말을 아끼는 편이 나음
IRC 닉네임이 ASCII 대소문자 무시라서
foo{가foo[와 같고bar|가bar\와 같았던 게 떠오름아직도 일부 클라이언트가 이 때문에 헷갈려도 놀랍지 않음