Tại sao các chương trình không được viết trong hội thường xuyên hơn? [đóng cửa]

Dường như đó là một ý kiến ​​chính thống rằng lập trình lắp ráp mất nhiều thời gian hơn và khó lập trình hơn một ngôn ngữ cấp cao hơn như C. Do đó, có vẻ như được khuyến nghị hoặc giả định rằng tốt hơn là viết bằng ngôn ngữ cấp cao hơn vì những lý do này và vì lý do tính di động tốt hơn.

Gần đây tôi đã viết trong hội thảo x86 và tôi nhận ra rằng có lẽ những lý do này không thực sự đúng, ngoại trừ tính di động. Có lẽ nó là một vấn đề quen thuộc và biết cách viết lắp ráp tốt. Tôi cũng nhận thấy rằng lập trình trong lắp ráp khá khác so với lập trình trong HLL. Có lẽ một lập trình viên lắp ráp giỏi và có kinh nghiệm có thể viết chương trình dễ dàng và nhanh chóng như một lập trình viên C có kinh nghiệm viết bằng C.

Có lẽ đó là do lập trình lắp ráp khá khác so với HLL, và do đó đòi hỏi phải có suy nghĩ, phương pháp và cách thức khác nhau, điều này khiến cho việc lập trình trở nên lạ lẫm, và do đó đặt tên xấu cho việc viết chương trình.

Nếu tính di động không phải là một vấn đề, thì thực sự, C sẽ có gì với một trình biên dịch tốt như NASM?

Chỉnh sửa: Chỉ để chỉ ra. Khi bạn đang viết lắp ráp, bạn không phải viết chỉ bằng mã lệnh. Bạn có thể sử dụng các macro và quy trình và các quy ước của riêng bạn để tạo ra các bản tóm tắt khác nhau để làm cho các chương trình trở nên mô đun hơn, dễ bảo trì hơn và dễ đọc hơn. Đây là nơi quen thuộc với cách viết lắp ráp tốt đi vào.

ASM có mức độ dễ đọc và không thực sự duy trì được so với các ngôn ngữ cấp cao hơn.

Ngoài ra, có rất ít nhà phát triển ASM hơn so với các ngôn ngữ phổ biến khác, chẳng hạn như C.

Hơn nữa, nếu bạn sử dụng ngôn ngữ cấp cao hơn và các hướng dẫn ASM mới có sẵn (ví dụ SSE), bạn chỉ cần cập nhật trình biên dịch và mã cũ của bạn có thể dễ dàng sử dụng các hướng dẫn mới.

Nếu CPU tiếp theo có số lượng thanh ghi nhiều gấp đôi thì sao?

Câu chuyện ngược lại của câu hỏi này là: Trình biên dịch cung cấp chức năng gì?

Tôi nghi ngờ bạn có thể / muốn / nên tối ưu hóa ASM của mình tốt hơn gcc -O3có thể.

Hell®, tôi là một trình biên dịch.

Tôi chỉ quét hàng ngàn dòng mã trong khi bạn đang đọc câu này. Tôi đã duyệt qua hàng triệu khả năng tối ưu hóa một dòng của bạn bằng cách sử dụng hàng trăm kỹ thuật tối ưu hóa khác nhau dựa trên một lượng lớn nghiên cứu học thuật mà bạn sẽ mất nhiều năm để đạt được. Tôi sẽ không cảm thấy xấu hổ, thậm chí không một chút khó khăn nào, khi tôi chuyển đổi một vòng lặp ba dòng thành hàng ngàn hướng dẫn chỉ để làm cho nó nhanh hơn. Tôi không có gì phải xấu hổ khi đi đến thời gian tối ưu hóa tuyệt vời hoặc làm những thủ đoạn bẩn thỉu nhất. Và nếu bạn không muốn tôi, có thể trong một hoặc hai ngày, tôi sẽ cư xử và làm theo cách bạn muốn. Tôi có thể chuyển đổi các phương thức tôi đang sử dụng bất cứ khi nào bạn muốn, thậm chí không thay đổi một dòng mã của bạn. Tôi thậm chí có thể cho bạn thấy mã của bạn trông như thế nào trong lắp ráp, trên các kiến ​​trúc bộ xử lý khác nhau và các hệ điều hành khác nhau và trong các quy ước lắp ráp khác nhau nếu bạn muốn. Vâng, tất cả chỉ trong vài giây. Bởi vì, bạn biết đấy, tôi có thể; và bạn biết đấy, bạn không thể.

PS, nhân tiện, bạn không sử dụng một nửa mã bạn đã viết. Tôi đã làm cho bạn một lợi ích và ném nó đi.

Tôi đã viết các khối lắp ráp cho các chip 6502, Z80, 6809 và 8086. Tôi đã ngừng làm như vậy ngay khi trình biên dịch C có sẵn cho các nền tảng mà tôi đang xử lý, và ngay lập tức trở nên hiệu quả hơn ít nhất gấp 10 lần. Hầu hết các lập trình viên giỏi sử dụng các công cụ họ sử dụng vì lý do hợp lý.

Tôi thích lập trình bằng ngôn ngữ hợp ngữ, nhưng cần nhiều mã hơn để làm điều tương tự như trong một trình độ cao cấp và có mối tương quan trực tiếp giữa các dòng mã và lỗi. (Điều này đã được giải thích từ nhiều thập kỷ trước trong Tháng huyền thoại .)

Có thể nghĩ C là 'lắp ráp cấp cao', nhưng hãy vượt lên trên một vài bước và bạn đang ở một thế giới khác. Trong C # bạn không nghĩ hai lần về việc viết này:

foreach (string s in listOfStrings) { /* do stuff */ }

Đây sẽ là hàng chục, có thể hàng trăm dòng mã được lắp ráp, mỗi lập trình viên thực hiện nó sẽ có một cách tiếp cận khác nhau và người tiếp theo sẽ phải tìm ra nó. Vì vậy, nếu bạn tin (như nhiều người) rằng các chương trình được viết chủ yếu cho người khác đọc, thì phần lắp ráp ít đọc hơn HLL thông thường.

Chỉnh sửa: Tôi đã tích lũy một thư viện mã cá nhân được sử dụng cho các tác vụ thông thường và macro để triển khai các cấu trúc điều khiển giống như C. Nhưng tôi đã thành công vào những năm 90, khi GUI trở thành chuẩn mực. Quá nhiều thời gian đã được dành cho những thứ thường lệ.

Nhiệm vụ cuối cùng tôi có trong đó ASM rất cần thiết là vài năm trước, viết mã để chống lại phần mềm độc hại. Không có giao diện người dùng, vì vậy đó là tất cả các phần thú vị mà không có sự phình to.

Ngoài các câu trả lời của người khác về khả năng đọc, khả năng bảo trì, mã ngắn hơn và do đó ít lỗi hơn và dễ dàng hơn nhiều, tôi sẽ thêm một lý do:

tốc độ chương trình.

Có, trong quá trình lắp ráp, bạn có thể điều chỉnh mã của mình để sử dụng mọi chu kỳ cuối cùng và làm cho nó nhanh nhất có thể. Tuy nhiên ai có thời gian? Nếu bạn viết một chương trình C không hoàn toàn ngu ngốc, trình biên dịch sẽ thực hiện tốt công việc tối ưu hóa cho bạn. Có thể thực hiện ít nhất 95% các tối ưu hóa bạn thực hiện bằng tay, mà không phải lo lắng về việc theo dõi bất kỳ điều gì trong số đó. Chắc chắn có một loại quy tắc 90/10 ở đây, trong đó 5% tối ưu hóa cuối cùng sẽ chiếm 95% thời gian của bạn. Vậy tại sao phải bận tâm?

Nếu một chương trình sản xuất trung bình có 100k dòng mã và mỗi dòng có khoảng 8-12 hướng dẫn trình biên dịch, đó sẽ là 1 triệu hướng dẫn trình biên dịch.

Ngay cả khi bạn có thể viết tất cả những thứ này bằng tay với tốc độ khá (hãy nhớ, mã của bạn phải viết gấp 8 lần), điều gì xảy ra nếu bạn muốn thay đổi một số chức năng? Hiểu điều gì đó bạn đã viết vài tuần trước trong số 1 triệu hướng dẫn đó là một cơn ác mộng! Không có mô-đun, không có lớp, không có thiết kế hướng đối tượng, không có khung, không có gì. Và số lượng mã tìm kiếm tương tự bạn phải viết cho ngay cả những điều đơn giản nhất là khó khăn nhất.

Ngoài ra, bạn không thể tối ưu hóa mã của mình cũng như ngôn ngữ cấp cao. Ví dụ, trong đó C thực hiện số lượng tối ưu hóa điên rồ vì bạn mô tả ý định của bạn, không chỉ mã của bạn, trong trình biên dịch mã bạn chỉ viết mã, trình biên dịch không thể thực hiện bất kỳ tối ưu hóa đáng chú ý nào trên mã của bạn. Những gì bạn viết là những gì bạn nhận được và tin tưởng tôi, bạn không thể tối ưu hóa đáng tin cậy 1 triệu hướng dẫn mà bạn vá và vá khi bạn viết nó.

Vâng, tôi đã viết rất nhiều bài "ngày xưa", và tôi có thể đảm bảo với bạn rằng tôi làm việc hiệu quả hơn nhiều khi tôi viết chương trình bằng ngôn ngữ cấp cao.

Một mức độ hợp lý của năng lực trình biên dịch là một kỹ năng hữu ích, đặc biệt là nếu bạn làm việc ở bất kỳ mức độ hệ thống hoặc lập trình nhúng nào, không nhiều vì bạn phải viết trình biên dịch mã đó nhiều, nhưng vì đôi khi điều quan trọng là phải hiểu cái hộp thực sự đang làm gì . Nếu bạn không có hiểu biết ở mức độ thấp về các khái niệm và vấn đề của trình biên dịch chương trình, điều này có thể rất khó khăn.

Tuy nhiên, vì thực sự viết nhiều mã trong trình biên dịch chương trình, có một số lý do nó không được thực hiện nhiều.

• Đơn giản là không có (hầu hết) nhu cầu. Ngoại trừ một cái gì đó như khởi tạo hệ thống rất sớm và có lẽ một vài đoạn trình biên dịch ẩn trong các hàm hoặc macro C, tất cả các mã cấp độ rất thấp có thể đã được viết bằng trình biên dịch mã có thể được viết bằng C hoặc C ++ mà không gặp khó khăn gì.

• Mã trong các ngôn ngữ cấp cao hơn (thậm chí C và C ++) ngưng tụ chức năng thành các dòng ít hơn rất nhiều, và có nghiên cứu đáng kể cho thấy số lượng lỗi tương quan với số dòng mã nguồn. Tức là, cùng một vấn đề, được giải quyết trong trình biên dịch chương trình và trình biên dịch, sẽ có nhiều lỗi hơn trong trình biên dịch chương trình đơn giản vì nó dài hơn. Lập luận tương tự thúc đẩy việc chuyển sang các ngôn ngữ cấp cao hơn như Perl, Python, v.v.

• Viết bằng trình biên dịch, bạn phải giải quyết mọi khía cạnh của vấn đề, từ cách bố trí bộ nhớ chi tiết, lựa chọn hướng dẫn, lựa chọn thuật toán, quản lý ngăn xếp, v.v. Các ngôn ngữ cấp cao hơn sẽ loại bỏ bạn điều khoản của LỘC.

Về cơ bản, tất cả những điều trên có liên quan đến mức độ trừu tượng có sẵn cho bạn trong trình biên dịch so với C hoặc một số ngôn ngữ khác. Trình biên dịch buộc bạn phải thực hiện tất cả các bản tóm tắt của riêng mình và để duy trì chúng thông qua kỷ luật tự giác của riêng bạn, trong đó bất kỳ ngôn ngữ cấp trung nào như C, và đặc biệt là các ngôn ngữ cấp cao hơn, cũng cung cấp cho bạn các bản tóm tắt ngoài hộp, cũng như khả năng tạo ra cái mới tương đối dễ dàng.

Là một nhà phát triển dành phần lớn thời gian của mình trong thế giới lập trình nhúng, tôi sẽ lập luận rằng lắp ráp khác xa với một ngôn ngữ đã chết / lỗi thời. Có một mức độ mã hóa gần với kim loại nhất định (ví dụ, trong trình điều khiển) đôi khi không thể được thể hiện chính xác hoặc hiệu quả bằng ngôn ngữ cấp cao hơn. Chúng tôi viết gần như tất cả các thói quen giao diện phần cứng của chúng tôi trong trình biên dịch chương trình.

Điều đó đang được nói, mã lắp ráp này được gói sao cho nó có thể được gọi từ mã C và được coi như một thư viện. Chúng tôi không viết toàn bộ chương trình trong hội đồng vì nhiều lý do. Đầu tiên và quan trọng nhất là tính di động; cơ sở mã của chúng tôi được sử dụng trên một số sản phẩm sử dụng các kiến ​​trúc khác nhau và chúng tôi muốn tối đa hóa số lượng mã có thể được chia sẻ giữa chúng. Thứ hai là sự quen thuộc của nhà phát triển. Nói một cách đơn giản, các trường không dạy lắp ráp như trước đây và các nhà phát triển của chúng tôi làm việc hiệu quả hơn bằng C so với lắp ráp. Ngoài ra, chúng tôi có rất nhiều "tính năng bổ sung" (những thứ như thư viện, trình gỡ lỗi, công cụ phân tích tĩnh, v.v.) có sẵn cho mã C của chúng tôi không có sẵn cho mã ngôn ngữ lắp ráp. Ngay cả khi chúng tôi muốn viết một chương trình lắp ráp thuần túy, chúng tôi sẽ không thể bởi vì một số thư viện phần cứng quan trọng chỉ có sẵn dưới dạng C libs. Theo một nghĩa nào đó, đó là vấn đề gà / trứng. Mọi người bị đẩy ra khỏi lắp ráp vì không có nhiều thư viện và các công cụ phát triển / gỡ lỗi có sẵn cho nó, nhưng lib / công cụ không tồn tại vì không đủ người sử dụng lắp ráp để đảm bảo nỗ lực tạo ra chúng.

Cuối cùng, có một thời gian và một nơi dành cho bất kỳ ngôn ngữ nào. Mọi người sử dụng những gì họ quen thuộc và năng suất nhất. Có lẽ sẽ luôn có một vị trí trong tiết mục của lập trình viên để lắp ráp, nhưng hầu hết các lập trình viên sẽ thấy rằng họ có thể viết mã bằng ngôn ngữ cấp cao hơn, gần như hiệu quả trong thời gian ngắn hơn.

Khi bạn đang viết lắp ráp, bạn không phải viết chỉ bằng mã lệnh. Bạn có thể sử dụng các macro và quy trình và các quy ước của riêng bạn để tạo ra các bản tóm tắt khác nhau để làm cho các chương trình trở nên mô đun hơn, dễ bảo trì hơn và dễ đọc hơn.

Vì vậy, về cơ bản, bạn đang nói rằng, với việc sử dụng thành thạo trình biên dịch phức tạp, bạn có thể làm cho mã ASM của mình ngày càng gần với C (hoặc dù sao là một ngôn ngữ cấp thấp khác của phát minh của riêng bạn), cho đến cuối cùng bạn chỉ là năng suất như một lập trình viên C.

Điều đó có trả lời câu hỏi của bạn không? ;-)

Tôi không nói điều này một cách ngớ ngẩn: Tôi đã lập trình bằng cách sử dụng chính xác một trình biên dịch và hệ thống như vậy. Thậm chí tốt hơn, trình biên dịch có thể nhắm mục tiêu một bộ xử lý ảo và một trình dịch riêng biệt đã biên dịch đầu ra của trình biên dịch cho một nền tảng đích. Nhiều như đã xảy ra với IF của LLVM, nhưng ở dạng sơ khai của nó trước khoảng 10 năm. Vì vậy, có tính di động, cộng với khả năng viết các thói quen cho một kẻ lừa đảo mục tiêu cụ thể, nơi cần thiết cho hiệu quả.

Viết bằng cách sử dụng trình biên dịch đó có năng suất tương đương với C và so với GCC-3 (khoảng thời gian tôi tham gia), trình biên dịch / dịch thuật tạo ra mã nhanh và thường nhỏ hơn. Kích thước thực sự quan trọng, và công ty có ít lập trình viên và sẵn sàng dạy cho những người mới thuê một ngôn ngữ mới trước khi họ có thể làm bất cứ điều gì hữu ích. Và chúng tôi đã có một bản sao lưu rằng những người không biết trình biên dịch chương trình (ví dụ như khách hàng) có thể viết C và biên dịch nó cho cùng một bộ xử lý ảo, sử dụng cùng một quy ước gọi, v.v. để nó giao tiếp gọn gàng. Vì vậy, nó cảm thấy như một chiến thắng bên lề.

Đó là với nhiều năm làm việc trong túi phát triển công nghệ lắp ráp, thư viện, v.v. Phải thừa nhận rằng phần lớn trong số đó đã biến nó thành di động, nếu nó chỉ nhắm mục tiêu vào một kiến ​​trúc thì trình biên dịch múa toàn hát sẽ dễ dàng hơn nhiều.

Tóm lại: bạn có thể không thích C, nhưng điều đó không có nghĩa là nỗ lực sử dụng C lớn hơn nỗ lực tìm ra thứ gì đó tốt hơn.

Hội không di động giữa các bộ vi xử lý khác nhau.

Lý do tương tự chúng ta không đi vệ sinh bên ngoài nữa, hoặc tại sao chúng ta không nói tiếng Latin hoặc Aramaic.

Công nghệ xuất hiện và làm cho mọi thứ dễ dàng hơn và dễ tiếp cận hơn.

EDIT - để chấm dứt mọi người xúc phạm, tôi đã xóa một số từ nhất định.

Tại sao? Đơn giản.

So sánh điều này:

        for (var i = 1; i <= 100; i++)
        {
            if (i % 3 == 0)
                Console.Write("Fizz");
            if (i % 5 == 0)
                Console.Write("Buzz");
            if (i % 3 != 0 && i % 5 != 0)
                Console.Write(i);
            Console.WriteLine();
        }

với

.locals init (
    [0] int32 i)
L_0000: ldc.i4.1 
L_0001: stloc.0 
L_0002: br.s L_003b
L_0004: ldloc.0 
L_0005: ldc.i4.3 
L_0006: rem 
L_0007: brtrue.s L_0013
L_0009: ldstr "Fizz"
L_000e: call void [mscorlib]System.Console::Write(string)
L_0013: ldloc.0 
L_0014: ldc.i4.5 
L_0015: rem 
L_0016: brtrue.s L_0022
L_0018: ldstr "Buzz"
L_001d: call void [mscorlib]System.Console::Write(string)
L_0022: ldloc.0 
L_0023: ldc.i4.3 
L_0024: rem 
L_0025: brfalse.s L_0032
L_0027: ldloc.0 
L_0028: ldc.i4.5 
L_0029: rem 
L_002a: brfalse.s L_0032
L_002c: ldloc.0 
L_002d: call void [mscorlib]System.Console::Write(int32)
L_0032: call void [mscorlib]System.Console::WriteLine()
L_0037: ldloc.0 
L_0038: ldc.i4.1 
L_0039: add 
L_003a: stloc.0 
L_003b: ldloc.0 
L_003c: ldc.i4.s 100
L_003e: ble.s L_0004
L_0040: ret 

Chúng giống hệt nhau về tính năng. Cái thứ hai thậm chí không phải là trình biên dịch mà là .NET IL (Ngôn ngữ trung gian, tương tự như mã byte của Java). Trình biên dịch thứ hai biến IL thành mã gốc (nghĩa là gần như trình biên dịch mã), làm cho nó thậm chí còn khó hiểu hơn.

Tôi đoán ASM trên x86 (_64) có ý nghĩa trong trường hợp bạn đạt được nhiều bằng cách sử dụng các hướng dẫn khó để trình biên dịch tối ưu hóa. Ví dụ x264 sử dụng rất nhiều mã hóa cho mã hóa của nó và tốc độ tăng là rất lớn.

Tôi chắc chắn có nhiều lý do, nhưng hai lý do nhanh chóng tôi có thể nghĩ đến là

1. Mã hội chắc chắn là khó đọc hơn (tôi cũng rất tích cực để viết)
2. Khi bạn có một nhóm lớn các nhà phát triển làm việc trên một sản phẩm, sẽ rất hữu ích khi mã của bạn được chia thành các khối logic và được bảo vệ bởi các giao diện.

Một trong những khám phá ban đầu (bạn sẽ tìm thấy nó trong Tháng huyền thoại của Brooks , từ kinh nghiệm trong những năm 1960) là mọi người ít nhiều làm việc hiệu quả bằng một ngôn ngữ khác, trong các dòng mã được gỡ lỗi mỗi ngày. Điều này rõ ràng là không đúng sự thật và có thể bị phá vỡ khi bị đẩy đi quá xa, nhưng nó thường đúng với các ngôn ngữ cấp cao của thời Brooks.

Do đó, cách nhanh nhất để có năng suất là sử dụng các ngôn ngữ trong đó một dòng mã riêng lẻ đã làm nhiều hơn và thực sự điều này hoạt động, ít nhất là đối với các ngôn ngữ phức tạp như FORTRAN và COBOL hoặc đưa ra một ví dụ hiện đại hơn C.

Tính di động luôn là một vấn đề - nếu không phải bây giờ, ít nhất là cuối cùng. Ngành công nghiệp lập trình dành hàng tỷ đô la mỗi năm để chuyển phần mềm cũ, tại thời điểm nó được viết, "rõ ràng" không có vấn đề gì về tính di động.

Có một vòng luẩn quẩn khi lắp ráp trở nên ít phổ biến hơn: khi các ngôn ngữ cấp cao hơn trưởng thành, các bộ hướng dẫn ngôn ngữ lắp ráp được xây dựng ít hơn để thuận tiện cho lập trình viên và nhiều hơn cho sự thuận tiện của trình biên dịch.

Vì vậy, bây giờ, thực tế, có thể rất khó để đưa ra quyết định đúng đắn, giả sử, đăng ký nào bạn nên sử dụng hoặc hướng dẫn nào hiệu quả hơn một chút. Trình biên dịch có thể sử dụng phương pháp phỏng đoán để tìm ra sự đánh đổi nào có khả năng có mức chi trả tốt nhất. Có lẽ chúng ta có thể suy nghĩ thông qua các vấn đề nhỏ hơn và tìm ra các tối ưu hóa cục bộ có thể đánh bại các trình biên dịch khá phức tạp hiện nay của chúng ta, nhưng tỷ lệ là trong trường hợp trung bình, một trình biên dịch tốt sẽ làm tốt hơn trong lần thử đầu tiên so với một lập trình viên giỏi có thể sẽ làm được. Cuối cùng, giống như John Henry, chúng tôi có thể đánh bại cỗ máy, nhưng chúng tôi có thể tự thiêu mình một cách nghiêm túc khi đến đó.

Vấn đề của chúng tôi bây giờ cũng khá khác nhau. Vào năm 1986, tôi đã cố gắng tìm ra cách tăng tốc một chút khỏi các chương trình nhỏ liên quan đến việc đưa vài trăm pixel lên màn hình; Tôi muốn hoạt hình để ít giật hơn. Một trường hợp công bằng cho ngôn ngữ lắp ráp. Bây giờ tôi đang cố gắng tìm ra cách thể hiện sự trừu tượng xung quanh ngôn ngữ hợp đồng và chính sách phục vụ cho các khoản thế chấp, và tôi muốn đọc một cái gì đó gần với ngôn ngữ mà những người kinh doanh nói. Không giống như các macro LISP, các macro hội không thực thi nhiều quy tắc, do đó, mặc dù bạn có thể có được thứ gì đó hợp lý gần với DSL trong một trình biên dịch tốt, nó sẽ dễ bị các loại quirks giành được ' Tôi gây ra sự cố cho tôi nếu tôi viết cùng một mã trong Ruby, Boo, Lisp, C # hoặc thậm chí F #.

Tuy nhiên, nếu vấn đề của bạn dễ dàng diễn đạt bằng ngôn ngữ lắp ráp hiệu quả, sẽ mang lại nhiều sức mạnh hơn cho bạn.

Ditto hầu hết những gì người khác đã nói.

Vào thời xa xưa trước khi C được phát minh, khi các ngôn ngữ cấp cao duy nhất là những thứ như COBOL và FORTRAN, có rất nhiều thứ không thể làm được mà không cần dùng đến trình biên dịch. Đó là cách duy nhất để có được sự linh hoạt hoàn toàn, có thể truy cập tất cả các thiết bị, v.v. Nhưng sau đó, C đã được phát minh, và hầu như mọi thứ có thể lắp ráp đều có thể có trong C. Tôi đã viết rất ít lắp ráp sau đó.

Điều đó nói rằng, tôi nghĩ rằng nó là một bài tập rất hữu ích cho các lập trình viên mới học viết bằng trình biên dịch. Không phải vì họ thực sự sẽ sử dụng nó nhiều, mà bởi vì sau đó bạn hiểu những gì đang thực sự xảy ra bên trong máy tính. Tôi đã thấy rất nhiều lỗi lập trình và mã không hiệu quả từ các lập trình viên, những người rõ ràng không biết chuyện gì đang thực sự xảy ra với các bit và byte và các thanh ghi.

Tôi đã lập trình lắp ráp được khoảng một tháng. Tôi thường viết một đoạn mã bằng C và sau đó biên dịch nó thành tập hợp để hỗ trợ tôi. Có lẽ tôi không sử dụng toàn bộ sức mạnh tối ưu hóa của trình biên dịch C nhưng có vẻ như nguồn C asm của tôi bao gồm các hoạt động không cần thiết. Vì vậy, tôi bắt đầu thấy rằng cuộc nói chuyện về một trình biên dịch C tốt vượt trội hơn một bộ mã hóa lắp ráp tốt không phải lúc nào cũng đúng.

Dù sao, chương trình lắp ráp của tôi rất nhanh. Và tôi càng sử dụng lắp ráp thì tôi càng mất ít thời gian để viết ra mã của mình vì nó thực sự không khó lắm. Ngoài ra nhận xét về lắp ráp có mức độ dễ đọc là không đúng. Nếu bạn gắn nhãn chương trình của mình một cách chính xác và đưa ra nhận xét khi cần thêm chi tiết, bạn nên thiết lập tất cả. Trong thực tế, theo cách lắp ráp thì rõ ràng hơn đối với người lập trình bởi vì họ đang nhìn thấy những gì đang xảy ra ở cấp độ của bộ xử lý. Tôi không biết về các lập trình viên khác nhưng đối với tôi, tôi thích biết những gì đang xảy ra, hơn là những thứ nằm trong một hộp đen.

Như đã nói, lợi thế thực sự của trình biên dịch là trình biên dịch có thể hiểu các mẫu và mối quan hệ và sau đó tự động mã hóa chúng ở các vị trí thích hợp trong nguồn. Một ví dụ phổ biến là các hàm ảo trong C ++, yêu cầu trình biên dịch tối ưu hóa các con trỏ hàm. Tuy nhiên, một trình biên dịch bị giới hạn để làm những gì mà trình tạo của trình biên dịch cho phép trình biên dịch thực hiện. Điều này dẫn đến việc các lập trình viên đôi khi phải dùng đến việc làm những điều kỳ quái với mã của họ, thêm thời gian mã hóa, khi họ có thể đã được thực hiện một cách tầm thường với lắp ráp.

Cá nhân tôi nghĩ rằng thị trường hỗ trợ rất nhiều ngôn ngữ cấp cao. Nếu ngôn ngữ lắp ráp là ngôn ngữ duy nhất tồn tại ngày nay thì họ sẽ ít hơn 70% người lập trình và ai biết thế giới của chúng ta sẽ ở đâu, có lẽ là vào những năm 90. Ngôn ngữ cấp cao hơn thu hút nhiều người hơn. Điều này cho phép nguồn cung lập trình viên cao hơn để xây dựng cơ sở hạ tầng cần thiết cho thế giới của chúng ta. Các quốc gia đang phát triển như Trung Quốc và Ấn Độ được hưởng lợi rất nhiều từ các ngôn ngữ như Java. Các quốc gia này sẽ nhanh chóng phát triển cơ sở hạ tầng CNTT và mọi người sẽ kết nối với nhau nhiều hơn. Vì vậy, quan điểm của tôi là các ngôn ngữ cấp cao phổ biến không phải vì chúng tạo ra mã vượt trội mà vì chúng giúp đáp ứng nhu cầu trên thị trường thế giới.

Tôi đang học lắp ráp trong comp org ngay bây giờ, và mặc dù nó rất thú vị, nhưng nó cũng rất không hiệu quả để viết. Bạn phải giữ nhiều chi tiết trong đầu để mọi thứ hoạt động, và nó cũng chậm hơn để viết những điều tương tự . Ví dụ, một dòng 6 vòng lặp đơn giản trong C ++ có thể bằng 18 dòng hoặc nhiều hơn lắp ráp.

Cá nhân, rất nhiều niềm vui khi học cách mọi thứ hoạt động ở cấp độ phần cứng và nó mang lại cho tôi sự đánh giá cao hơn về cách thức hoạt động của máy tính.

Những gì C có trên một trình biên dịch macro tốt là ngôn ngữ C. Kiểm tra kiểu. Cấu trúc vòng lặp. Quản lý ngăn xếp tự động. (Gần) quản lý biến tự động. Kỹ thuật bộ nhớ động trong lắp ráp là một nỗi đau lớn ở mông. Làm một danh sách được liên kết đúng cách chỉ là đáng sợ so với C hoặc tốt hơn là liệt kê foo.insert (). Và gỡ lỗi - tốt, không có cuộc thi nào về việc dễ gỡ lỗi hơn. HLLs thắng tay xuống đó.

Tôi đã mã hóa gần một nửa sự nghiệp của mình trong trình biên dịch chương trình, điều này giúp tôi dễ dàng suy nghĩ về người hỗ trợ. nó giúp tôi xem trình biên dịch C đang làm gì một lần nữa giúp tôi viết mã mà trình biên dịch C có thể xử lý một cách hiệu quả. Một thói quen được suy nghĩ kỹ lưỡng được viết bằng C có thể được viết để xuất ra chính xác những gì bạn muốn trong trình biên dịch với một công việc nhỏ - và nó có thể mang theo được! Tôi đã phải viết lại một vài thói quen cũ hơn trở lại C vì lý do đa nền tảng và không có gì thú vị.

Không, tôi sẽ gắn bó với C và đối phó với hiệu suất chậm đôi khi so với thời gian năng suất tôi đạt được với HLL.

Tôi chỉ có thể trả lời tại sao cá nhân tôi không viết chương trình lắp ráp thường xuyên hơn và lý do chính là nó tẻ nhạt hơn để làm. Ngoài ra, tôi nghĩ rằng sẽ dễ dàng nhận được những điều sai trái một cách tinh tế mà không nhận thấy ngay lập tức. Ví dụ, bạn có thể thay đổi cách bạn sử dụng một đăng ký trong một thói quen nhưng quên thay đổi điều này ở một nơi. Nó sẽ lắp ráp tốt và bạn có thể không nhận thấy cho đến sau này.

Điều đó nói rằng, tôi nghĩ rằng vẫn còn sử dụng hợp lệ để lắp ráp. Chẳng hạn, tôi có một số thói quen lắp ráp được tối ưu hóa khá tốt để xử lý lượng lớn dữ liệu, sử dụng SIMD và theo cách tiếp cận "mỗi bit là thiêng liêng" [quote V.Stob]. (Nhưng lưu ý rằng việc triển khai lắp ráp ngây thơ thường tệ hơn rất nhiều so với những gì trình biên dịch sẽ tạo ra cho bạn.)

C là một trình biên dịch vĩ mô! Và nó là thứ tốt nhất!

Nó có thể thực hiện gần như mọi thứ lắp ráp, nó có thể di động và trong hầu hết các trường hợp hiếm hoi mà nó không thể làm gì đó mà bạn vẫn có thể sử dụng mã lắp ráp nhúng. Điều này chỉ để lại một phần nhỏ các chương trình mà bạn thực sự cần phải viết trong lắp ráp và không có gì ngoài lắp ráp.

Và sự trừu tượng ở cấp độ cao hơn và tính di động khiến cho hầu hết mọi người viết phần mềm hệ thống trong C. đáng giá hơn và mặc dù bây giờ bạn có thể không cần tính di động nếu bạn đầu tư nhiều thời gian và tiền bạc vào việc viết một số chương trình mà bạn có thể không muốn giới hạn bản thân trong những gì bạn sẽ có thể sử dụng nó trong tương lai.

Mọi người dường như quên mất rằng cũng có hướng khác.

Tại sao bạn viết bằng Trình biên dịch ở vị trí đầu tiên? Tại sao không viết chương trình bằng một ngôn ngữ thực sự cấp thấp?

Thay vì

mov eax, 0x123
add eax, 0x456
push eax
call printInt

bạn cũng có thể viết

B823010000
0556040000
50 
FF15.....

Điều đó có rất nhiều lợi thế, bạn biết kích thước chính xác của chương trình của mình, bạn có thể sử dụng lại giá trị của các hướng dẫn làm đầu vào cho các hướng dẫn khác và bạn thậm chí không cần một trình biên dịch để viết nó, bạn có thể sử dụng bất kỳ trình soạn thảo văn bản nào ...

Và lý do bạn vẫn thích Trình biên dịch về điều này, là lý do người khác thích C ...

Bởi vì nó luôn như vậy: thời gian trôi qua và những điều tốt đẹp cũng qua đi :(

Nhưng khi bạn viết mã asm, cảm giác hoàn toàn khác so với khi bạn viết mã lang cấp cao, mặc dù bạn biết nó kém năng suất hơn nhiều. Giống như bạn là một họa sĩ: bạn có thể tự do vẽ bất cứ thứ gì bạn thích theo cách bạn muốn mà hoàn toàn không bị hạn chế (tốt, chỉ bằng các tính năng của CPU) ... Đó là lý do tại sao tôi thích nó. Thật đáng tiếc ngôn ngữ này biến mất. Nhưng trong khi ai đó vẫn còn nhớ nó và mã hóa nó, nó sẽ không bao giờ chết!

$$$

Một công ty thuê một nhà phát triển để giúp biến mã thành $$$. Nhanh hơn mà hữu ích mã có thể được sản xuất, nhanh hơn các công ty có thể chuyển mã vào $$$.

Các ngôn ngữ cấp cao hơn thường tốt hơn trong việc tạo ra khối lượng mã hữu ích lớn hơn. Điều này không có nghĩa là lắp ráp không có vị trí của nó, vì có những lúc và những nơi không có gì khác sẽ làm.

Lợi thế của HLL thậm chí còn lớn hơn khi bạn so sánh lắp ráp với ngôn ngữ cấp cao hơn C, ví dụ Java hoặc Python hoặc Ruby. Chẳng hạn, các ngôn ngữ này có bộ sưu tập rác: không cần phải lo lắng khi nào giải phóng một đoạn bộ nhớ và không bị rò rỉ bộ nhớ hoặc lỗi do giải phóng quá sớm.

Như những người khác đã đề cập trước đây, lý do cho bất kỳ công cụ nào tồn tại là nó có thể hoạt động hiệu quả như thế nào. Vì các HLL có thể hoàn thành các công việc giống như nhiều dòng mã asm, tôi đoán rằng việc lắp ráp sẽ bị thay thế bởi các ngôn ngữ khác. Và đối với vấn đề gần với phần cứng - có lắp ráp nội tuyến trong C và các biến thể khác theo ngôn ngữ. Tiến sĩ Paul Carter nói trong ngôn ngữ hội PC

"... hiểu rõ hơn về cách máy tính thực sự hoạt động ở mức thấp hơn so với ngôn ngữ lập trình như Pascal. Bằng cách hiểu sâu hơn về cách máy tính hoạt động, người đọc thường có thể phát triển phần mềm hiệu quả hơn trong các ngôn ngữ cấp cao hơn như C và C ++. Học lập trình bằng ngôn ngữ lắp ráp là một cách tuyệt vời để đạt được mục tiêu này. "

Chúng tôi đã giới thiệu về lắp ráp trong các khóa học đại học của tôi. Nó sẽ giúp xóa các khái niệm. Tuy nhiên tôi nghi ngờ bất kỳ ai trong chúng ta sẽ viết 90% mã trong hội đồng. Làm thế nào có liên quan là kiến ​​thức lắp ráp chuyên sâu ngày nay?

Lướt qua những câu trả lời này, tôi cá là 9/10 người trả lời chưa bao giờ làm việc với lắp ráp.

Đây là một câu hỏi lâu đời xuất hiện thường xuyên và bạn nhận được câu trả lời giống nhau, chủ yếu là sai. Nếu không có tính di động, tôi vẫn sẽ tự mình lắp ráp mọi thứ. Thậm chí sau đó, tôi viết mã bằng C gần giống như tôi đã lắp ráp.