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

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

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

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

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

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

하지만 다시 ...

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

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

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

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

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

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

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

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

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

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

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

당신이 경우 않는 어셈블러의 비트를 배울하기로 결정, 당신은 아마 (물론, 에뮬레이트 된) 제독 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 명령어 세트 세부 사항에 얽매이지 않고 다형성 메소드 호출이 작동하는 방법을 알고 싶다면 이와 같은 책을 친구로 삼아야하며 곧 새로운 버전이 나옵니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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