Có cần thiết phải hiểu những gì xảy ra ở cấp độ phần cứng để trở thành một lập trình viên giỏi?

Tôi là một lập trình viên tự học, chỉ trong trường hợp câu hỏi này được trả lời trong CS 101. Tôi đã học và sử dụng nhiều ngôn ngữ, chủ yếu cho mục đích sử dụng cá nhân của tôi, nhưng đôi khi cho các công cụ chuyên nghiệp.

Có vẻ như tôi luôn chạy vào cùng một bức tường khi tôi gặp rắc rối với việc lập trình. Ví dụ, tôi vừa hỏi một câu hỏi trên một diễn đàn khác về cách xử lý một con trỏ tới mảng được trả về bởi một hàm. Ban đầu tôi nghĩ rằng đơn giản là tôi không biết kỹ thuật phù hợp mà các nhà thiết kế của C ++ đã thiết lập để xử lý tình huống. Nhưng từ những câu trả lời và thảo luận theo sau tôi thấy rằng tôi không thực sự hiểu điều gì xảy ra khi một cái gì đó được 'trả lại'.

Làm thế nào một mức độ hiểu biết sâu sắc về quá trình lập trình phải là một lập trình viên giỏi phải đạt được?

Số Không ai hiểu những gì đang xảy ra ở cấp phần cứng.

Các hệ thống máy tính giống như hành tây - có nhiều lớp, và mỗi lớp phụ thuộc vào lớp bên dưới để hỗ trợ. Nếu bạn là chàng trai làm việc ở một trong các lớp bên ngoài, bạn không nên quan tâm quá nhiều đến những gì xảy ra ở giữa củ hành. Và đó là một điều tốt, bởi vì giữa hành tây luôn thay đổi. Miễn là lớp hoặc lớp hỗ trợ lớp cụ thể của bạn tiếp tục trông giống nhau và hỗ trợ lớp của bạn, bạn vẫn ổn.

Nhưng sau đó một lần nữa ...

Vâng. Ý tôi là, bạn không cần phải hiểu những gì thực sự xảy ra bên trong củ hành, nhưng nó giúp ích rất nhiều để có một mô hình tinh thần về những gì bên trong của một củ hành điển hình trông như thế nào. Có lẽ không phải là phần sâu nhất, nơi bạn có các cổng được tạo thành từ các bóng bán dẫn và như vậy, hoặc lớp hoặc hai lớp tiếp theo, nơi bạn có microcode, đồng hồ, đơn vị giải mã hướng dẫn, v.v. Tuy nhiên, các lớp tiếp theo là nơi bạn Đã có thanh ghi, ngăn xếp và đống. Đây là các lớp sâu nhất nơi bạn có nhiều ảnh hưởng đến những gì xảy ra - trình biên dịch dịch mã của bạn thành các hướng dẫn chạy ở cấp độ này và nếu bạn muốn, bạn có thể thường xuyên thực hiện các hướng dẫn này và tìm hiểu điều gì "thực sự" đang xảy ra.

Hầu hết các lập trình viên có kinh nghiệm đều có một phiên bản hơi cổ tích của các lớp này trong đầu. Chúng giúp bạn hiểu trình biên dịch đang nói về điều gì khi nó cho bạn biết rằng có "ngoại lệ địa chỉ không hợp lệ" hoặc "lỗi tràn ngăn xếp" hoặc đại loại như thế.

Nếu bạn quan tâm, hãy đọc một cuốn sách về kiến ​​trúc máy tính. Nó thậm chí không cần phải là một cuốn sách đặc biệt mới - máy tính kỹ thuật số đã hoạt động theo cách tương tự trong một thời gian dài. Bạn càng tìm hiểu nhiều về bên trong củ hành, bạn sẽ càng kinh ngạc hơn khi bất kỳ thứ gì trong số này hoạt động! Học (xấp xỉ) những gì đang diễn ra ở các lớp thấp hơn làm cho việc lập trình trở nên ít bí ẩn hơn và, bằng cách nào đó, kỳ diệu hơn. Và thực sự, vui hơn.

Một điều khác bạn có thể nhìn vào là hành tây nhúng. Er, ý tôi là hệ thống nhúng. Có một số nền tảng nhúng khá dễ sử dụng: Arduino và BASIC Stamp là hai ví dụ. Về cơ bản, đây là những bộ vi xử lý nhỏ với rất nhiều tính năng tích hợp. Bạn có thể coi chúng là hành tây có ít lớp hơn so với máy tính để bàn thông thường của bạn, vì vậy có thể hiểu khá kỹ về những gì đang diễn ra trong toàn hệ thống, từ phần cứng cho đến phần mềm.

Bạn không nói về mức độ phần cứng, bạn đang nói về những gì trình biên dịch thực sự làm với những gì bạn bảo nó làm.

Bạn chắc chắn cần mức độ hiểu biết này để tìm ra những gì đã sai khi nó không rõ ràng, đặc biệt là khi xử lý một tình huống dậm bộ nhớ.

Hiểu bộ nhớ chương trình! = Hiểu phần cứng

Hiểu phân cấp bộ nhớ == Hiểu phần cứng

Để trả lời câu hỏi chung chung của bạn: Nó phụ thuộc. Hiểu được phần cứng, nhưng hiểu nó sẽ không giúp ích gì trong mọi trường hợp.

Dựa trên ví dụ của bạn, bạn chỉ cần hiểu thêm về cách phân chia bộ nhớ và cách tổ chức bộ nhớ khi bạn đang chạy một chương trình. Hiểu về phần cứng sẽ không giúp bạn về vấn đề này, bởi vì bộ nhớ (như hiển thị với chương trình) thậm chí không thực sự đại diện cho phần cứng nhờ vào sự kỳ diệu của bộ nhớ ảo.

Nếu bạn tò mò về các vấn đề hiệu năng dựa trên thứ tự bạn truy cập bộ nhớ, NGAY BÂY GIỜ bạn sẽ được hưởng lợi từ việc hiểu phần cứng, thừa kế bộ nhớ, lỗi bộ nhớ cache, lỗi trang và tất cả sự tốt đẹp tuyệt vời đến từ phần cứng.

Nếu bạn làm quyết định tìm hiểu một chút về lắp ráp, có lẽ bạn nên học cái gì đó như 6502 lắp ráp trên một Commodore 64 (mô phỏng, tất nhiên), hoặc 68000 trên Amiga.

Bạn có thể biết một số ý tưởng về Commodore 64 tại đây ...

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

Cuốn sách kinh điển mọi thứ bạn cần biết là cuốn sách được mô tả ở đây ...

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

Bạn có thể tìm thấy bản quét PDF nếu bạn nhìn xung quanh.

IMO, 6502 dễ hơn Z80 và 68000 dễ hơn 8086 - các bộ hướng dẫn thông thường hơn, v.v.

Nhưng CPU chỉ là một khía cạnh của phần cứng. Ngoài ra, CPU hiện đại là một con quái vật khác biệt lớn và nó thực hiện những thứ trong suốt ngay cả từ quan điểm của trình biên dịch - chẳng hạn như trình bày một không gian địa chỉ ảo.

Một lợi thế đặc biệt của 6502 trên C64 là không chỉ CPU đơn giản mà còn có một số phần mềm rất đơn giản để hack xung quanh với phần cứng. Tôi đã từng rất vui khi chơi xung quanh với chip âm nhạc SID.

Vì vậy - nó có thể là một bài tập đáng giá nếu bạn không dành quá nhiều thời gian cho nó. Tôi đã học được trình biên dịch 6502 như ngôn ngữ thứ hai của mình khi tôi khoảng 14 tuổi, ngay sau Commodore Basic. Nhưng chủ yếu là nó có được mô hình làm việc rất đơn giản đó để bạn có thể thêm các ý tưởng phức tạp hơn vào nó với sự hiểu lầm tối thiểu.

Một số điều hữu ích bạn có thể học khi làm việc trong trình biên dịch ...

• Làm thế nào các thanh ghi CPU hoạt động.
• Làm thế nào địa chỉ bộ nhớ hoạt động, bao gồm cả chỉ định.
• Làm thế nào ngăn xếp CPU hoạt động.
• Làm thế nào logic bitwise hoạt động.
• Cách CPU điều khiển các thiết bị I / O.
• Làm thế nào gián đoạn làm việc.

Một lý do cụ thể mà tôi khuyên bạn là nên có một trực giác tốt hơn về cách các bước đơn giản vận hành hoàn toàn xác định và cơ học và hoàn toàn không có trí thông minh hoặc ý thức chung. Về cơ bản làm quen với mô hình thực thi mệnh lệnh ở dạng thuần túy và ngu dốt nhất.

Chính xác thì hữu ích như thế nào khi biết hầu hết những điều đó bây giờ, mặc dù, là một câu hỏi khó.

Một điều bạn sẽ không học được là làm thế nào để chơi tốt với một người thừa kế trí nhớ. Những máy cũ đó hầu hết có một mô hình bộ nhớ đơn giản không có lớp bộ nhớ cache và không có bộ nhớ ảo. Bạn cũng sẽ không học được nhiều về đồng thời - chúng chắc chắn là cách để xử lý vấn đề đó, nhưng điều đó chủ yếu có nghĩa là gián đoạn. Bạn không cần phải lo lắng về mutexes, vv

Đôi khi, một mô hình tinh thần về cách những thứ này từng hoạt động, hoặc cách thức trình biên dịch hoạt động, thậm chí có thể đánh lừa. Ví dụ, suy nghĩ về một con trỏ C là một địa chỉ có thể dẫn đến các vấn đề hành vi không xác định. Con trỏ AC thường được triển khai dưới dạng một số nguyên chứa địa chỉ, nhưng không có gì đảm bảo rằng điều đó hoàn toàn đúng. Ví dụ, trên một số nền tảng kỳ quái, các con trỏ khác nhau có thể trỏ vào các không gian địa chỉ khác nhau. Điều này trở nên quan trọng khi bạn muốn thực hiện số học hoặc logic bitwise với hai con trỏ.

Trừ khi bạn có một trong những nền tảng kỳ quái đó, bạn có thể không nghĩ rằng bạn quan tâm đến điều đó - nhưng trình biên dịch ngày nay có nhiều khả năng khai thác hành vi không xác định tiêu chuẩn để tối ưu hóa.

Vì vậy, một mô hình tinh thần của kiến ​​trúc hệ thống có thể hữu ích, nhưng điều quan trọng là phải viết mã cho đặc tả ngôn ngữ., Không phải là một mô hình giả thuyết mà ngôn ngữ và nền tảng của bạn có thể không tôn trọng.

Cuối cùng, rất nhiều công cụ mô hình tinh thần hữu ích xuất phát từ ý tưởng về cách trình biên dịch tạo mã - và việc tạo mã cho các ngôn ngữ hiện đại rất khác so với các trình biên dịch khá tầm thường có sẵn trước đó.

Đây là một cuốn sách yêu thích của tôi cho rằng ...

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

Cùng với các công cụ về phân tích cú pháp và AST, v.v., nó bao gồm việc tạo mã cho một loạt các mô hình ngôn ngữ - mệnh lệnh, OOP, chức năng, logic, song song và phân phối - và cũng để quản lý bộ nhớ. Nếu bạn muốn biết các cuộc gọi phương thức đa hình hoạt động như thế nào mà không bị sa lầy vào các chi tiết của tập lệnh CPU, thì một cuốn sách như thế này là bạn của bạn - và sắp có một phiên bản mới.

Hai mươi năm trước nó rất quan trọng, nhưng bây giờ không còn nhiều - có rất nhiều lớp trừu tượng hơn giữa phần mềm và phần cứng hiện đại.

Thật hữu ích khi biết những việc như cần nhiều luồng để tận dụng nhiều lõi hoặc sử dụng nhiều bộ nhớ hơn trên hệ thống là một điều tồi tệ, nhưng ngoài ra bạn không thực sự cần nó trừ khi công việc của bạn là viết những trừu tượng đó các lớp.

Phần còn lại của câu hỏi của bạn cho thấy rằng bạn có thể quan tâm đến trình biên dịch hơn phần cứng, điều này hơi khác một chút. Bạn có thể gặp phải những trường hợp quan trọng, nhưng những trường hợp này có thể là tầm thường (đệ quy vô hạn không hoạt động tốt) hoặc là trường hợp cạnh mà bạn có thể cảm thấy tốt khi giải quyết nó nhưng có thể sẽ không bao giờ gặp phải vấn đề tương tự lần nữa.

Nó giúp rất nhiều để biết và hiểu sự trừu tượng được trình bày bởi phần cứng và một chút ý tưởng chung về cách tạo ra ảo ảnh đó - nhưng cố gắng thực sự hiểu phần cứng hiện đại thực sự hoạt động như thế nào là một công việc to lớn mà bạn ' lại có khả năng chỉ nhìn thấy lợi nhuận tối thiểu.

Nếu bạn tha thứ cho một trò chơi nhỏ: điều này nhắc nhở tôi về một điều mà tôi đã lưu ý vài năm trước. Nhiều thập kỷ trước (cho đến cuối những năm 1970 hoặc lâu hơn), hầu hết mọi người nghĩ rằng máy tính chỉ thiếu một bước phép thuật - hầu như không bị ảnh hưởng bởi các định luật vật lý, có khả năng tạo ra mọi thứ có ý nghĩa thực sự, v.v. Vào thời điểm đó, tôi đã dành một khoảng thời gian hợp lý để cố gắng (chủ yếu là không thành công) để thuyết phục mọi người rằng không, họ không phải là phép thuật. Chúng thực sự là những cỗ máy khá bình thường, có số lượng hạn chế rất nhanh và đáng tin cậy, nhưng lại cực kỳ trần tục.

Ngày nay, hầu hết quan điểm của mọi người về máy tính đã thay đổi. Bây giờ chúng khá bình thường - đến mức khá nhiều người rất bình thường nắm bắt được chúng. Ví dụ, một lúc trước khi tôi đang ăn tối, tôi đã thấy / nghe một người phục vụ và nhân viên phục vụ trong giờ nghỉ của họ thảo luận về những gì cô ấy nên nhận trong máy tính mới. Những lời khuyên mà ông đã đưa ra là hoàn toàn hợp lý và thực tế.

Quan điểm của tôi về máy tính cũng đã thay đổi. Tôi đã đến Hot Chips và trước đó Diễn đàn Vi xử lý sẽ trở lại vào giữa những năm 1990 hoặc lâu hơn. Tôi có thể biết nhiều về phần cứng vi xử lý hơn ít nhất 99% lập trình viên - và biết những gì tôi làm, tôi sẽ nói điều này: chúng không còn bình thường nữa. Họ làm gần như phá vỡ các định luật vật lý. Tôi đã thực hiện rất nhiều thử nghiệm cấp độ thấp và tôi có thể nói điều này chắc chắn: vượt qua ảo ảnh do CPU tạo ra và đến mức cho thấy phần cứng thực sự hoạt động như thế nào thường cực kỳ khó khăn. Tôi ước gì có thể gửi một hình ảnh của một trong các thiết lập của chúng tôi với một máy tính bị chôn vùi dưới các loại cáp từ không ít hơn 4 phân tích logic chỉ để đo đúng một khía cạnh về cách thức hoạt động của bộ nhớ đệm trên CPU hiện đại (không đề cập đến một số chương trình thực sự khó tính để đảm bảo rằng những gì chúng tôi đo được chính xác là những gì CPU đang làm, và không có gì khác).

Các ngôn ngữ khác nhau hoạt động ở các mức độ trừu tượng khác nhau từ phần cứng. C và C ++ ở mức rất thấp. Mặt khác, các ngôn ngữ kịch bản đòi hỏi bạn phải biết ít hơn về chi tiết cơ bản.

Tuy nhiên, tôi vẫn sẽ nói rằng trong mọi trường hợp, bạn càng biết nhiều, bạn sẽ trở thành một lập trình viên giỏi hơn. Một phần của lập trình là có thể tung hứng nhiều mức độ trừu tượng cùng một lúc.

Nếu bạn đang lập trình trong C ++, bạn cần phải hiểu khá rõ về cách thức hoạt động của CPU hiện đại, ít nhất là ở mức độ trừu tượng mà trình biên dịch hoạt động. (Có những thứ đang diễn ra bên trong CPU cũng trong suốt với trình biên dịch).

Tôi muốn thêm một điểm về thiết kế chung của các ngôn ngữ cấp cao hơn như C.

Nói chung, tôi nghĩ an toàn khi nói rằng các ngôn ngữ như vậy có thể được xem là triển khai một cỗ máy trừu tượng và thực sự đó là cách mà chính Dennis Ritchie đã mô tả cách C hoạt động và cách thiết kế cụ thể của máy trừu tượng C đã biến nó thành ngôn ngữ dễ mang theo hơn. Như vậy có một số hiểu biết về kiến ​​trúc máy tính và chức năng ở cấp độ máy, có thể cực kỳ hữu ích trong việc hiểu được máy trừu tượng của ngôn ngữ.

Tính di động của các chương trình C của DMR và Hệ thống UNIX là lần đầu tiên tôi nhớ để thảo luận về mô hình máy (trừu tượng) cho C.

Tôi nghĩ rằng bài báo của DMR về lịch sử và sự phát triển của C cũng cực kỳ hữu ích trong việc cho thấy phần cứng thực sự ảnh hưởng đến thiết kế ngôn ngữ như thế nào và có lẽ cũng là một ví dụ điển hình cho thiết kế ngôn ngữ lập trình ban đầu: Sự phát triển của ngôn ngữ C