좋은 프로그래머가 되려면 하드웨어 수준에서 무슨 일이 일어나고 있는지 이해해야합니까?


24

CS 101에서이 질문에 대한 답을 구할 수있는 경우를 대비하여, 나는 독학 프로그래머입니다. 나는 대부분 개인적으로 사용하기도하지만 때로는 전문적인 목적으로도 많은 언어를 배우고 사용했습니다.

문제가있는 프로그래밍에 빠질 때 항상 같은 벽에 빠져있는 것 같습니다. 예를 들어, 방금 다른 포럼에서 함수에 의해 반환 된 포인터 대 배열을 처리하는 방법에 대한 질문을했습니다. 처음에는 C ++의 디자이너가 상황을 처리하기 위해 설정 한 적절한 기술을 모른다고 생각합니다. 그러나 다음 답변과 토론에서 나는 무언가가 '돌아올 때'어떻게되는지 알지 못한다는 것을 알았습니다.

좋은 프로그래머는 프로그래밍 프로세스에 대한 어느 정도의 이해 수준을 달성해야합니까?


3
내 충고 : 일부 x86 어셈블리 (DOS 또는 기타)를 배우십시오. 그런 다음 작은 C 코드 조각의 어셈블러 출력을 읽는 방법을 배웁니다. 결과를 이해하지 못하면 질문하십시오. 반복. 이를 통해 CPU 수준에서 무슨 일이 일어나고 있는지 이해할 수 있습니다.
Earlz


Earlz-x86 명령어 세트를 사용하여 프로그래밍하는 법을 배워야합니까? 이것이 'CPU 레벨'입니까?
bev

직업-thx, 그것은 재미 있었다. 그는 실제로 몇 가지 오류를 만들었습니다.
bev

답변:


33

아니요. 아무도 하드웨어 수준에서 무슨 일이 일어나고 있는지 이해하지 못합니다.

컴퓨터 시스템은 양파와 같습니다. 많은 레이어가 있으며 각 레이어는 그 아래의 레이어에 따라 지원됩니다. 외부 층 중 하나를 작업하는 사람이라면 양파 중간에 일어나는 일을 너무 신경 쓰지 않아야합니다. 양파 한가운데가 항상 변하기 때문에 좋은 일입니다. 특정 레이어를 지원하는 레이어가 계속 동일하게 보이고 레이어를 지원하는 한 좋습니다.

하지만 다시 ...

예. 양파 내부 에서 실제로 무슨 일 일어나고 있는지 이해할 필요는 없지만 전형적인 양파의 내부 모습을 정신적으로 보여주는 데 도움이됩니다. 아마도 가장 깊은 부분, 트랜지스터 등으로 구성된 게이트가 있거나 다음 레이어 또는 마이크로 레이어, 클럭, 명령 디코딩 장치 등이있는 다음 레이어 또는 두 레이어가 아닐 수도 있습니다. 레지스터, 스택 및 힙이 있습니다. 이것들은 당신이 일어나는 일에 많은 영향을 미치는 가장 깊은 층입니다-컴파일러는 코드를이 수준에서 실행되는 명령어로 변환합니다. 원한다면 일반적으로 이러한 명령어를 단계별로 수행하고 "실제로"발생하는 것을 찾을 수 있습니다.

대부분의 숙련 된 프로그래머는 머리에 약간의 동화 버전이 있습니다. "잘못된 주소 예외"또는 "스택 오버플로 오류"또는 이와 유사한 내용이 있음을 알려줄 때 컴파일러가 말하는 내용을 이해하는 데 도움이됩니다.

관심이 있다면 컴퓨터 아키텍처에 관한 책을 읽으십시오. 특히 새로운 책일 필요는 없습니다. 디지털 컴퓨터는 오랫동안 같은 방식으로 작동 해 왔습니다. 양파의 내부에 대해 더 많이 배울수록이 재료가 전혀 효과가 없다는 사실에 더 놀라게 될 것입니다! 하위 계층에서 진행되는 일을 (대략) 학습하면 프로그래밍이 덜 신비적이며 어쨌든 더 마술처럼됩니다. 그리고 정말로 더 재미 있습니다.

당신이 볼 수있는 또 다른 것은 내장 양파입니다. 어, 나는 임베디드 시스템을 의미합니다. 사용하기 쉬운 임베디드 플랫폼이 많이 있습니다. ArduinoBASIC Stamp 가 두 가지 예입니다. 이것들은 기본적으로 내장 기능이 많은 소형 마이크로 프로세서입니다. 일반적인 데스크탑 PC보다 적은 수의 층을 가진 양파로 생각할 수 있으므로 하드웨어에서 소프트웨어에 이르기까지 전체 시스템에서 일어나는 일에 대해 완전히 철저히 이해할 수 있습니다.


2
감사. 이것은 기본적으로 내 질문에 대답합니다. 레지스터, 가산기, 멀티플렉서 등의 칩 레벨 (예 : 트랜지스터 레벨) 설계를 수행 한 EE이므로 가장 낮은 레벨을 얻습니다 (양자 역학을 이야기하지 않는 한). 또한 내가 잘 알고있는 언어를 사용할 수 있습니다. 컴파일러가 작동한다고 말하는 중간 수준 (스택, 힙)에 큰 차이가 있습니다. 당신이 그것을 넣을 때부터, 나는 나의 프로그래밍 경험이 "보다 신비 롭고 더 마술 적"이되기를 원한다. 아직 나에게 알려지지 않은 레벨을 연구해야 할 것 같습니다.
bev

@bev :이 경우 Arduino와 같은 플랫폼을 실제로 확인해야합니다.
Caleb

미안하지만 Arduino를 확인했는데 컴파일러를 사용하여 포인터와 배열을 다르게 처리하는 방법을 이해하는 데 실제로 도움이되는 방법을 알 수 없습니다. 무엇을 볼 수 없습니까?
bev

@bev : 함수가 어떻게 호출되는지 알고 싶다면 30 분 동안 읽은 다음 완료해야합니다. 모든 것이 어떻게 작동하는지 더 잘 이해하려면 작은 시스템을 사용하는 것이 가장 쉽습니다. 머리 전체에 양파를 한꺼번에 넣는 가장 좋은 방법입니다. Arduino의 기반이되는 칩 제품군 인 AVR은 많은 문제없이 배울 수있는 작은 명령어 세트를 갖춘 훌륭하고 범용적인 사용하기 쉬운 시스템입니다.
Caleb

그래. 홈페이지는 제품 측면에서 약간 어둡습니다. 다시 볼게요
베브

10

하드웨어 수준에 대해 이야기하는 것이 아니라 컴파일러가 지시 한 내용으로 컴파일러가 실제로하는 일에 대해 이야기하는 것입니다.

분명하지 않은 경우, 특히 메모리 스톰프 상황을 처리 할 때 무엇이 ​​잘못되었는지 파악하려면이 수준의 이해가 필요합니다.


로렌-네! 간단한 진실에 감사드립니다. 이제 C ++ 컴파일러가 데이터 유형으로 수행하는 작업을 배우는 가장 좋은 방법을 찾아야합니다. BTW는 EE로서 말 그대로 하드웨어 수준이 아니라는 것을 알고 있습니다. CS 괴짜들이 뭐라고 부르는지 몰랐습니다. (아직 문제는 아닙니다. 컴파일러 수준?)
bev

BTW-메모리 스톰프?
bev

@Bev : 방금 내 요점을 증명했습니다. 메모리 스톰이 무엇인지 모르는 경우 버그로 인해 끔찍한 시간을 갖게 될 것입니다. 메모리 스톰프는 무언가가 예상되지 않은 위치에 쓸 때 발생하는 모든 일을 지 웁니다. 운이 좋으면 적중 한 것이 즉시 중요하고 적어도 폭발합니다. 운이 좋지 않으면 프로그램은 데이터에 약간의 구멍이 생깁니다.
Loren Pechtel

설명 주셔서 감사합니다. 또한 내가 아는 한 더 잘 제어하지 않고 힙이나 스택에 쓰므로 알지 못하는 정도를 보여줍니다.
bev

@Bev : 문제가 있다고 생각하지 않는 장소를 작성할 때 문제가 발생합니다. 스택에 무언가가 있으며 포인터를 만듭니다. 당신은 루틴을 떠납니다. 항목은 사라지고 포인터는 그렇지 않습니다. 이제 그 포인터에 쓸 때 어떻게됩니까? 또는 100 개의 항목이 있습니다. 200 번 항목에 쓰면 어떻게됩니까?
Loren Pechtel

6

프로그램 메모리 이해! = 하드웨어 이해

메모리 계층 이해 == 하드웨어 이해


일반적인 질문에 대답하려면 다음과 같이하십시오. 하드웨어를 이해하는 것은 아프지 않지만, 이해하는 것이 모든 경우에 도움이되지는 않습니다.

예제를 기반으로 프로그램을 실행할 때 메모리가 어떻게 분할되고 어떻게 구성되는지에 대해 더 이해하면됩니다. 가상 메모리의 마법 덕분에 메모리 (프로그램에서 볼 수있는)가 실제로 하드웨어를 나타내지 않기 때문에 하드웨어를 이해하는 것이 도움이되지 않습니다.

메모리에 액세스하는 순서에 따라 성능 문제가 궁금한 경우 이제 하드웨어, 메모리 계층 구조, 캐시 누락, 페이지 결함 및 하드웨어에서 제공되는 모든 영광스러운 장점을 이해하면 도움이됩니다.


Stargazer-아직 성능 문제에 대해 걱정할 수있는 시점이 아닙니다. 조만간 의견 주셔서 감사합니다.
bev

5

당신이 경우 않는 어셈블러의 비트를 배울하기로 결정, 당신은 아마 (물론, 에뮬레이트 된) 제독 64 6502 어셈블러와 같은 뭔가를 배울 또는 아미에 68,000한다.

Commodore 64에 대한 아이디어를 얻을 수 있습니다 ...

http://thepiratebay.org/torrent/4609238/Tag3-Saal2-Slot16_00--ID2874-the_ultimate_commodore_64_talk-Main

알아야 할 고전적인 모든 것이 여기에 설명 된 것입니다 ...

http://reprog.wordpress.com/2010/03/12/programming-books-part-3-programming-the-commodore-64/

둘러 보면 PDF 스캔을 찾을 수 있습니다.

IMO, 6502는 Z80보다 쉽고, 68000은 8086보다 쉽습니다.보다 일반적인 명령어 세트 등

그러나 CPU는 하드웨어의 한 측면 일뿐입니다. 또한 최신 CPU는 엄청나게 다른 짐승이며 가상 주소 공간 표시와 같은 컴파일러의 관점에서도 투명한 작업을 수행합니다.

C64에서 6502의 특별한 장점은 CPU가 단순 할뿐만 아니라 하드웨어를 해킹하는 것이 매우 간단하다는 것입니다. 나는 SID 음악 칩을 가지고 놀았었다.

따라서 시간을 너무 많이 쓰지 않으면 가치있는 운동 일 것입니다. 나는 코모도어 베이직 직후, 14 살쯤되었을 때 6502 어셈블러를 제 2 언어로 배웠습니다. 그러나 대부분 매우 간단한 작업 모델을 사용하므로 최소한의 오해로 더 세련된 아이디어를 추가 할 수 있습니다.

어셈블러에서 작업하면서 배울 수있는 유용한 것들 ...

  • CPU 레지스터 작동 방식
  • 간접 처리를 포함하여 메모리 주소 지정 작동 방식
  • CPU 스택 작동 방식
  • 비트 논리의 작동 방식
  • CPU가 I / O 장치를 제어하는 ​​방법
  • 인터럽트 작동 방식

제가 추천하는 한 가지 특별한 이유는 간단한 단계가 지능이나 상식없이 완전히 결정적이고 기계적으로 그리고 완전히 작동하는 방식을 더 잘 이해하기 위해서입니다. 기본적으로 명령형 실행 모델에 익숙해지는 것은 가장 순수하고 완고하게 무지한 형태입니다.

정확히 어떻게 지금 그 일의 대부분을 아는 것입니다 유용하지만, 어려운 질문이다.

배우지 않을 것 중 하나는 메모리 계층 구조로 잘 플레이하는 방법입니다. 이러한 오래된 시스템에는 대부분 캐시 계층과 가상 메모리가없는 간단한 메모리 모델이있었습니다. 또한 동시성에 대해 많이 배우지 않을 것입니다. 확실히 그것을 처리하는 방법 이었지만 대부분 인터럽트를 의미했습니다. 뮤텍스 등에 대해 걱정할 필요가 없었습니다.

때때로, 방법의 정신 모델은 이러한 일들이 한 번 , 심지어 오해, 또는 어떻게 어셈블러 작품의 수했다. 예를 들어, C 포인터를 주소로 생각하면 정의되지 않은 동작 문제가 발생할 수 있습니다. AC 포인터는 일반적으로 주소를 포함하는 정수로 구현되지만 이것이 사실이라는 보장은 없습니다. 예를 들어, 일부 기이 한 플랫폼에서는 다른 포인터가 다른 주소 공간을 가리킬 수 있습니다. 이것은 두 개의 포인터로 산술 또는 비트 논리를 수행하려는 경우 중요합니다.

이 기괴한 플랫폼 중 하나를 가지고 있지 않다면, 당신은 그것에 대해 신경 쓰지 않을 것입니다. 그러나 요즘 컴파일러는 최적화를 위해 표준 정의되지 않은 행동을 이용할 가능성이 점점 더 높습니다.

따라서 시스템 아키텍처의 정신적 모델은 유용 할 수 있지만, 언어 및 플랫폼이 존중하지 않을 수있는 가상의 모델이 아니라 언어 사양을 코딩하는 것이 여전히 중요합니다.

마지막으로, 컴파일러가 코드를 생성하는 방법에 대한 아이디어를 얻는 데 도움이되는 많은 유용한 정신 모델 자료가 있습니다. 현대 언어의 코드 생성은 당시 사용 가능한 아주 간단한 컴파일러와는 매우 다릅니다.

이것은 저의 가장 좋아하는 책입니다 ...

http://dickgrune.com/Books/MCD_1st_Edition/

구문 분석 및 AST 등에 관한 것 외에도 명령, OOP, 기능, 논리, 병렬 및 분산과 같은 다양한 언어 패러다임 및 메모리 관리를위한 코드 생성을 다룹니다. CPU 명령어 세트 세부 사항에 얽매이지 않고 다형성 메소드 호출이 작동하는 방법을 알고 싶다면 이와 같은 책을 친구로 삼아야하며 곧 새로운 버전이 나옵니다.


스티브-와우 내 질문에 대한 귀하의 답변의 완전성과 초점에 대해 말이 거의 없습니다. 이 모든 것을 쓸 시간을 내 주셔서 감사합니다. 나는 당신의 제안을 확실히 취할 것입니다.
bev

1
PDP-11 어셈블러가 언급 된 다른 모든 것보다 배우기가 조금 더 좋습니다. 다른 모든 사람들이 가르치는 것은 더 제한된 하드웨어 자원 및 / 또는 더 제한된 하드웨어 설계 및 예측에 의해 강제되는 제한입니다. 너무 일반적인 8051 제품군 중 하나와 같이 프로그래밍 모델이 그러한 제한된 하드웨어 (예를 들어, 스티브가 다른 주소 공간을 언급 한 곳)에서 실제로 얼마나 기이한지를 배울 수 있습니다.
Greg A. Woods

@ 그레그-PDP-11로 놀아 본 적이 없어요. 또한 8051도-한동안 임베디드 작업을했지만 8096 제품군 칩을 사용했습니다. 나는 단지 여기를 보았습니다 -흥미 롭습니다. 나는 얼마 전에 하버드 아키텍처에 대해 들었지만, 매우 인기 있고 여전히 사용되고있는 이와 같은 것이 있는지 전혀 몰랐습니다.
Steve314

4

20 년 전에는 중요했지만 지금은 그리 중요하지 않습니다. 소프트웨어와 최신 하드웨어 사이에 더 많은 추상화 계층이 있습니다.

다중 코어를 활용하기 위해 다중 스레드가 필요하거나 시스템에 존재하는 것보다 더 많은 메모리를 사용하는 것은 나쁜 일이지만 그 이상의 추상화를 작성하는 것이 아니라면 실제로는 필요하지 않습니다. 층.

나머지 질문은 하드웨어보다 컴파일러에 더 관심이있을 수 있음을 시사합니다. 중요한 경우가 발생할 수 있지만 사소한 경우 (무한 재귀가 잘 작동하지 않음) 또는 해결에 대해 좋은 느낌을 줄 수 있지만 결코 같은 문제가 발생하지 않는 최첨단 사례 인 경향이 있습니다. 다시.


네, 맞습니다. 컴파일러에 더 관심이 있습니다. 또한 여러 스레드, 여러 코어 등에 대한 제안에 대해서는 thx입니다. 방금 toLearn 노트 파일에 들어갔습니다.
베브

@bev 멀티 스레딩은 배우기 쉬우 며, 실제로해야 할 필요가없는 한하지 마십시오. 내 경험보다 가치가 더 큽니다.
Skeith

@ Skeith-팁 주셔서 감사합니다. 명심하겠습니다.
bev

4

그것은 알고 하드웨어가 제시 한 추상화하고, 이해하는 많은 도움이 작은 그 환상이 생성 방법에 대한 일반적인 생각의를 -하지만하려고하는 것은 참으로 현대적 하드웨어 이해 정말 어떤에서 당신의 작품의 엄청난 양의 작품입니다 최소한의 수익 만 볼 가능성이 높습니다.

약간의 기분 전환을 용서한다면, 이것은 몇 년 전에 내가 언급 한 것을 떠올리게합니다. 수십 년 전 (1970 년대 후반까지), 대부분의 사람들은 컴퓨터가 마술보다 한 걸음 짧았다 고 생각했습니다. 물리학의 법칙에 거의 영향을받지 않았으며, 거의 모든 의미를 갖지 못하는 모든 방법을 사용할 수있었습니다. 그 당시 나는 사람들에게 마술이 아니라고 설득하기 위해 많은 시간을 보냈다. 그들은 매우 신속하고 신뢰성있게 사물의 수를 제한했다 정말 상당히 일반 기계 있었지만, 그렇지 않으면이었다 매우 평범한.

요즘 컴퓨터에 대한 대부분의 사람들의 시각이 바뀌 었습니다. 그들은 매우 평범한 사람들입니다. 아주 평범한 사람들 중 일부는 실제로 이해하고 있습니다. 예를 들어, 저녁 식사를하는 동안 얼마 전에, 나는 웨이터와 웨이트리스가 그녀가 새 컴퓨터에 무엇을 가져야하는지 논의하는 것을 보았습니다. 그가 준 조언은 전적으로 합리적이고 현실적이었습니다.

컴퓨터에 대한 나의 견해도 바뀌 었습니다. 저는 Hot Chips에 갔고 그 전에 마이크로 프로세서 포럼은 1990 년대 중반으로 거슬러 올라갑니다. 아마 프로그래머의 99 이상 % 이상의 마이크로 프로세서 하드웨어에 대해 더 알고 - 내가 무엇을 알고, 나는 이것을 말할 것이다 : 그들이있어 하지 더 이상 평범한. 그들은 않습니다 물리학의 법칙을 깰 거의. 나는 많은 저수준 테스트를 해왔으며 이것을 확실히 말할 수 있습니다 .CPU가 만든 환상을 지나고 하드웨어가 실제로 어떻게 작동하는지 보여주는 수준으로 가져 오는 것은 종종 매우 어렵습니다. 난 그냥 제대로 측정하기 위해 나는 아무 미만 4 로직 분석기에서 케이블에 묻혀 컴퓨터와의 설정 중 하나의 사진을 게시 할 수있는 소원 하나를 캐싱이 최신 CPU에서 작동하는 방식의 측면 (실제로 까다로운 프로그래밍은 말할 것도없고 CPU가 수행 한 작업과 그 밖의 다른 작업은 수행하지 않았습니다).


Jerry-귀하의 의견에 감사드립니다. EE이기 때문에 더 높은 추상화 수준보다 트랜지스터 수준에 더 익숙합니다. 좋은 C ++ 프로그래머가되기 위해 알아야 할 것이 무엇인지 궁금합니다.
베브

그 사진은 흥미롭게 들립니다. 왜 게시 할 수 없습니까?
메이슨 휠러

@Bev : 좋은 프로그래머가되기 위해 트랜지스터 레벨에서 아무것도 알 필요가 없습니다 . 이러한 추상화는 이유가 있기 때문에 거의 항상 머신 코드 / 어셈블리의 추상화 수준보다 낮은 추상화 수준의 항목은 완전히 관련이 없으며 작동한다고 가정 할 수 있습니다.
메이슨 휠러

@MasonWheeler : 내가 일했던 곳에서 가져 왔지만 더 이상 일하지 않기 때문에 접근하기가 조금 더 어려울 것입니다. ..)
Jerry Coffin

1

다른 언어는 하드웨어와는 다른 추상화 수준에서 작동합니다. C와 C ++는 매우 저수준입니다. 반면에 스크립팅 언어는 기본 세부 사항에 대해 덜 알아야합니다.

그러나 나는 여전히 모든 경우에, 당신이 알수록 프로그래머가 더 좋다고 말할 것입니다. 프로그래밍의 일부는 여러 레벨의 추상화를 동시에 저글링 할 수 있습니다.

C ++로 프로그래밍하는 경우 적어도 컴파일러가 작동하는 추상화 수준에서 최신 CPU의 작동 방식에 대해 잘 이해해야합니다. (컴파일러에게도 투명한 CPU 내부의 것들도 있습니다).


Scott- "현대 CPU의 작동 방식에 대해 잘 이해하고 있습니다."디지털 논리의 작동 방식 (예 : karnaugh 맵, 진리표 및 AND / OR / NOR / XOR 게이트 작동 방식)을 의미합니까? 또는 컴파일러가 직접 사용하는 리소스 (즉, 레지스터)를 의미합니까?
bev

더 많이 아는 것이 좋습니다. 그러나 실제 트릭은 어떤 종류의 "더 많은 것"이 당신의 벅에 가장 큰 타격을 줄지 아는 것입니다. 예를 들어, 명령어 타이밍을 아는 것은 컴파일러가 사용할 명령어를 예측하기가 거의 불가능할 때 많이 사용되지 않습니다. 프로파일 러를 사용하는 방법을 배우면 비용 / 이익 비율이 훨씬 높아질 것입니다.
Steve314

1
@bev-아니요, 게이트 레벨로 내려갈 필요는 없습니다. 기본 아키텍처 (메모리, 버스, CPU), 명령어로드, 실행, 결과 저장 방법 등을 알고 있다면 괜찮을 것입니다. 또한 컴파일러가 스택 및 힙을 사용하는 방법을 포함하여 프로그램의 메모리 공간을 배치하는 방법을 이해해야합니다.
Scott Whitlock

@ ScottWhitlock-감사합니다-이것은 내가 찾고있는 특정 권장 사항입니다.
bev

0

C와 같은 고급 언어의 전체 디자인에 대한 요점을 추가하고 싶습니다.

일반적으로 이러한 언어는 추상 기계를 구현하는 것으로 볼 수 있다고 생각하는 것이 안전하다고 생각합니다. 실제로 Dennis Ritchie가 C의 작동 방식과 C의 추상 기계의 특정 설계로 인해 더 이식 가능한 언어가 된 방법을 설명했습니다. 컴퓨터 아키텍처와 기계 수준 기능에 대해 어느 정도 이해하고 있으므로 언어의 추상 기계를 이해하는 데 매우 도움이 될 수 있습니다.

DMR의 논문 C 프로그램과 UNIX 시스템의 이식성은 C에 대한 (추상적 인) 머신 모델을 논의한 첫 번째 기억입니다.

: 나는 C의 역사와 개발에 대한 DMR의 논문은 또한 실제 하드웨어가 언어 설계에 영향을 미치는 방법을 보여주는 매우 유용하며, 아마도 조기 프로그래밍 언어 설계의 모범 생각 은 C 언어의 개발


여기에 처음 오셨을 때 이것이 포럼이라고 생각하는 것 같습니다. 질문에 대한 답변은 추가 한 점이 아니어야하며, 의견으로 강등되어야하며, 답변은 질문에 대한 포괄적 인 답변이되어야합니다. 그것은 당신이 좋은 지적을했다고 말했고 이것은 주제 정보에 가치가 있습니다. 아마도 그 대답에 몇 줄을 넣을 수 있다면이 설명과 함께 질문에 직접적으로 도움이 될 것입니다. 여기서 공유하고있는 멋진 정보. 프로그래머에 오신 것을 환영합니다!
Jimmy Hoffa

주석은 버전이 없으며 영구적이지 않으므로 일련의 답변에 추가 할 수 없습니다. 대부분의 포스터는 또한 답변을 업데이트하기 위해 의견 사용을 무시하는 경향이 있으며, 대부분의 답변은 "커뮤니티 위키"답변으로 태그가 지정되지 않으므로 후속 기고자에 대한 일부 속성을 유지하는 방식으로 다른 사람이 편집 할 수 없습니다. . 게다가,이 특정한 질문은 진정한 토론을 시작했고, 그것이 좋아하든 그렇지 않든 이런 것들 중 일부가 진행되는 방식입니다. 하나의 몰드에 모든 기여를 강요하는 것은 스택 교환 개념의 주요 실패입니다.
Greg A. Woods

그리고 btw, 나는 실제로 OP에 대한 하나의 진정한 질문에 대해 암묵적으로 대답했다. 언어 설계의 핵심에서 추상 기계를 모델링 할 수 있도록 하드웨어에 대해 충분히 이해하고 있어야한다.
Greg A. Woods
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.