Hội vẫn còn liên quan? [đóng cửa]


18

Có sự khác biệt lớn giữa ngôn ngữ lắp ráp và ngôn ngữ cấp cao hơn khi nói đến mã hóa và / hoặc quản lý dự án không? Rõ ràng phải mất nhiều câu lệnh trong ngôn ngữ lắp ráp để thực hiện một thao tác cụ thể hơn so với hầu hết các ngôn ngữ khác, nhưng có những khác biệt ảnh hưởng đến cách một dự án cần (hoặc nên) được chạy dựa trên ngôn ngữ lắp ráp nhắm mục tiêu (cụ thể là ngôn ngữ lắp ráp x86 / x64) ?

Trong phạm vi có sự khác biệt giữa ngôn ngữ lắp ráp và các ngôn ngữ khác, có vẻ hợp lý để đoán rằng ít nhất một số trong số này là lợi thế cho các ngôn ngữ khác. Bất cứ ai cũng có thể chỉ ra những nhược điểm cụ thể của ngôn ngữ lắp ráp và cách để giảm thiểu những nhược điểm đó?

Một ví dụ cụ thể sẽ là nhân viên sẵn sàng. Có ai gặp khó khăn trong việc tìm kiếm các lập trình viên ngôn ngữ lắp ráp có kinh nghiệm, và nếu vậy, những bước nào có thể được thực hiện để giảm thiểu vấn đề này?


Tại sao mọi người sẽ viết một dự án hoàn chỉnh chỉ bằng ngôn ngữ lắp ráp ngày hôm nay? Hay bạn đang hỏi về một môi trường ngôn ngữ hỗn hợp, đó là cách lắp ráp thường được sử dụng ngày nay?
Martin Vilcans

6
Lưu ý rằng có các lĩnh vực non-[PC|web|enterprise]lập trình, trong đó hội chiếm ưu thế hoặc rất phổ biến. Tôi đang nói về bộ điều khiển vi mô, tự động hóa công nghiệp hoặc robot. Chắc chắn, có những ngôn ngữ cấp cao trong các lĩnh vực này, nhưng bạn thấy hội rất nhiều.
Mchl

1
@Mchl: Không phải các dự án này được thực hiện bằng C (hoặc thậm chí là C ++) và có thể là lắp ráp? Tôi đã đoán rằng việc sử dụng lắp ráp độc quyền là rất hiếm.
Martin Vilcans

1
Trên thực tế trong tự động hóa công nghiệp, bạn có thể gặp cả một nhánh ngôn ngữ đơn giản là không tồn tại bên ngoài lĩnh vực đó. Một phần trong số đó đến từ sự khác biệt về phần cứng (kiến trúc Harvard trái ngược với kiến ​​trúc von Neumann mà chúng ta đã quá quen thuộc). cũng như từ lịch sử làm cho các bộ điều khiển này có thể truy cập được cho các thợ điện, những người đã từng làm việc với các công tắc và rơle. Đó là cách LD ( en.wikipedia.org/wiki/Ladder_logic ) ra đời, đây thực sự là một cách giải thích đồ họa của lắp ráp. Xem bài viết được liên kết để biết thêm một số ngôn ngữ được sử dụng trong tự động hóa.
Mchl

2
Tôi đã có một trình cài đặt nhỏ mà tôi hỗ trợ bây giờ đang lắp ráp. Thật dễ dàng để viết theo cụm (với Windows API) như mọi thứ khác, vậy tại sao không? Tôi cũng đã có một giao diện swiper thẻ tín dụng được viết bằng cách lắp ráp. Bắt đầu với các ngôn ngữ cấp cao, nhưng có quá nhiều khó khăn để nó hoạt động đến mức tôi viết lại trong phần lắp ráp để kiểm soát tốt hơn tất cả các bit đang chảy ...
Brian Knoblauch

Câu trả lời:


25

Có - nhưng không thường xuyên.

Ở một khía cạnh nào đó, lắp ráp thực sự chỉ là một proxy cho ngôn ngữ máy, vì vậy tất nhiên bạn có thể làm bất cứ điều gì trong lắp ráp mà bạn có thể với ngôn ngữ cấp cao hơn.

Điều ngược lại không phải luôn luôn như vậy. Ví dụ, một vài năm trước, tôi đã làm việc trên một CPU ARM có một số opcode thú vị để thay đổi trạng thái đồ họa chỉ có thể được sử dụng từ chế độ kernel. Chúng sẽ không có tương đương trực tiếp trong ngôn ngữ cấp cao hơn và tôi chắc chắn rằng chức năng trong trình điều khiển hạt nhân Linux để thay đổi các trạng thái đó bao gồm một số hội đồng.

Trên các bộ vi xử lý từ những năm 80 và đầu những năm 90, nếu bạn có một số mã bạn cần để chạy rất nhanh, bạn thường viết nó trong lắp ráp, bởi vì một người có kỹ năng có thể dễ dàng viết lắp ráp được tối ưu hóa hơn hầu hết C trình biên dịch có thể tạo ra. Một số chương trình Mac đầu tiên được viết hoàn toàn bằng cách lắp ráp và chúng nhanh chóng đáng kinh ngạc cho thời đại. Ngay cả khi không viết toàn bộ chương trình trong lắp ráp, tôi chắc chắn đã chia sẻ tối ưu hóa các vòng lặp bên trong trong C thông qua lắp ráp nhúng.

Nhưng mọi thứ bắt đầu thay đổi vào giữa những năm 1990. CPU bắt đầu bao gồm các tính năng như đường ống và dự đoán nhánh, vì vậy thứ tự lệnh hiệu quả nhất không phải lúc nào cũng rõ ràng đối với con người. Tệ hơn thế, thứ tự hiệu quả nhất khác nhau giữa các CPU trong cùng một gia đình; chẳng hạn, trình biên dịch PowerPC thường cung cấp các công tắc đích cho sê-ri G3, G4 và G5. Mã đối tượng tương tự sẽ chạy trên tất cả chúng, nhưng nó sẽ chạy trên một trong những chuỗi đó hiệu quả hơn.

Kể từ đó, việc đặt hàng lệnh ngày càng phức tạp hơn, đặc biệt là trên các CPU phức tạp hơn về mặt kiến ​​trúc như x86, PowerPC và SPARC. . . Các trình biên dịch hiện đại chính có thể thực hiện công việc tối ưu hóa mã trên các CPU đó tốt hơn nhiều so với khả năng hợp lý của con người.

Tôi đã không tìm thấy một lý do tốt để viết lắp ráp trong ít nhất 15 năm. Tôi nghĩ vào năm 2011, việc sử dụng chính để lắp ráp sẽ là:

  • Để đọc các lần tháo gỡ khi gỡ lỗi, điều mà tôi thỉnh thoảng làm ngay cả ngày hôm nay.
  • Xử lý các tính năng CPU không chuẩn, như chế độ đồ họa thú vị đó.
  • Trình biên dịch viết - nó cung cấp một định dạng trung gian, có thể đọc được để dịch các ngôn ngữ cấp cao hơn sang.

1
Và ngay cả lý do số 3 của bạn cũng bắt đầu biến mất với các trình biên dịch nhắm mục tiêu khung trình biên dịch cấp cao như LLVM, nanojit hoặc libjit hoặc một cái gì đó như JVM, CIL, Parrot, Rubinius hoặc Neko bytecode.
Jörg W Mittag

Đôi khi vẫn cần phải thực hiện một chút SSE2 trong công việc đồ họa / video. Mặc dù điểm chuẩn so với TBB / OMP đầu tiên!
Martin Beckett

@Martin: OMP trực giao với SSE2. (giả sử thực hành bố trí dữ liệu tốt)
rwong

@rwong - nhưng quá trình vẫn còn, 1, phát hiện ra nó quá chậm. 2, hy vọng OMP / TBB tăng tốc đủ. 3, dùng để viết tay phiên bản SSE2! (theo thứ tự đau)
Martin Beckett

2
Ví dụ, toàn bộ Tàu lượn siêu tốc được viết theo cụm (trừ đồ họa được thực hiện trong c) và mạnh mẽ đáng kinh ngạc theo thời gian. Hàng trăm AI riêng lẻ hoạt động độc lập, gần như liền mạch, khi hầu hết các trò chơi có một vài sprite 16x16 pixel thực hiện các chuyển động được xác định trước. Tôi luôn thích sử dụng nó để thể hiện sức mạnh của lắp ráp.
Ampt

19

Hãy thử lập trình một vi điều khiển cho một "nhúng nhỏ" - điều khiển từ xa báo động ô tô, màn hình pin điện thoại, bộ điều khiển bàn phím, bộ điều chỉnh tốc độ quạt, mà không cần sử dụng lắp ráp.

Trong khi biên giới di chuyển, luôn có chỗ để lắp ráp.

15 năm trước, đồng hồ đo tốc độ xe đạp của bạn là cơ khí, lò vi sóng ở mạch tương tự, điều khiển TV là mạch kỹ thuật số, bộ chỉnh Sat TV được viết bằng cách lắp ráp, phần sụn điện thoại bằng C và một applet máy tính bằng Java.

7 năm trước, một lò vi sóng là trong mạch kỹ thuật số, một điều khiển TV được viết bằng cách lắp ráp, hộp set-top TV được viết bằng C, điện thoại của bạn chạy UI dựa trên Java.

Ngày nay, máy đo tốc độ xe đạp thuộc mạch kỹ thuật số, lò vi sóng được lắp ráp phần sụn, điều khiển từ xa có chương trình cơ sở trong C, hộp giải mã TV chạy Java, điện thoại của bạn có Linux.

Bạn muốn đặt cược trong 7 năm tới? Khi nhiều công nghệ có được các ngôn ngữ điều khiển tiên tiến hơn, lắp ráp sẽ có được cơ sở mới và nó sẽ tiếp tục có được chúng. Nhìn vào những gì được thực hiện ngày hôm nay với các mạch cơ hoặc tương tự. Bạn có thể đặt cược lắp ráp ở đó trong một vài năm. Công tắc đèn của bạn? Vòi nước của bạn? Ấm đun nước của bạn? Bàn chải đánh răng của bạn?

Sẽ luôn có một thiết bị mới, thiết bị, đồ chơi, vật dụng thông thường được lập trình lắp ráp.


3
câu trả lời tốt. Có bao nhiêu người thà trả gấp đôi số tiền cho một thứ mà pin kéo dài một nửa chỉ vì java hoặc thứ gì đó được sử dụng làm nền tảng phát triển? Nhìn vào groupon và tất cả những cách khác mọi người tìm cách tiết kiệm tiền, nhìn vào tài nguyên tiết kiệm phong trào xanh. Tại sao chi phí và tăng sức mạnh cho tất cả các sản phẩm nhúng chỉ để tránh lắp ráp?
old_timer

1
Bạn đã quên thêm rằng bây giờ máy tính chạy Javascript (Chromebook). Đối với tôi sự tiến bộ đó là khá buồn nhưng là sự thật.
Hawken

Kể từ năm 2017, CIA xâm nhập vào TV của bạn chạy Linux, tín hiệu từ Java chạy trên chìa khóa xe hơi có thể bị giả mạo, bất kỳ ai cũng có thể kết nối qua phần mềm WIFI với C ++ của máy ảnh dương vật giả , bàn chải đánh răng đã khai thác từ xa vào năm 2013, nhưng may mắn vẫn có tai nghe khử tiếng ồn được tạo ra trong công việc lắp ráp. Mặc dù lắp ráp mất vị trí như bộ điều khiển cấp cao nhất của bất cứ thứ gì , thay vào đó chuyển sang các thành phần phụ. Rèm cửa sổ của bạn đã chạy Java, nhưng bảng điều khiển Java nói chuyện với rèm điều khiển động cơ chạy với lắp ráp.
SF.

8

Tôi dựa trên cơ sở này chủ yếu là các bộ lắp ráp mà tôi đã sử dụng - chủ yếu là MASM, NASM và (ở mức độ thấp hơn) TASM. Một số phiên bản sau của TASM có (có?) Một số tính năng để hỗ trợ OO, nhưng tôi chưa sử dụng chúng nhiều và tôi không cố gắng nhận xét về chúng.

Thứ nhất: hầu hết các ngôn ngữ đã chuyển sang một cấu trúc ít nhất giống như cây. Cho dù hướng đối tượng, hoặc dựa trên đối tượng, hoặc chính xác là gì, có khá nhiều định nghĩa về mối quan hệ giữa các phần khác nhau của hệ thống. Cũng có khá nhiều thứ để "bảo vệ" một phần của hệ thống khỏi sự "can thiệp" vô tình nhưng các phần khác (mặc dù sự bảo vệ thường có thể được bỏ qua nếu bạn muốn). Ngược lại, ngôn ngữ lắp ráp tương đối "phẳng" - hầu hết các mối quan hệ giữa mã (và dữ liệu) trong các phần khác nhau của hệ thống được thiết lập chủ yếu bằng tài liệu và ở một quy ước đặt tên ở mức độ thấp hơn.

Kết quả của điều này là thường dễ dàng hơn nhiều để ghép mã chặt chẽ hơn nhiều so với lý tưởng. Các yêu cầu thúc đẩy sự lựa chọn ngôn ngữ lắp ráp bắt đầu (hiệu suất cao hơn, kích thước nhỏ hơn, v.v.) thường cũng thưởng cho điều này - bằng cách bỏ qua các giao diện được phê duyệt và như vậy bạn thường có thể nhận được mã nhỏ hơn và nhanh hơn (mặc dù không thường xuyên tốt hơn trong bất kỳ chiều nào). Bản thân ngôn ngữ và công cụ làm ít hơn nhiều để hạn chế những gì bạn làm (tốt hay xấu), điều này đặt ra gánh nặng lớn hơn nhiều cho các nhà quản lý để ngăn chặn các vấn đề. Tôi sẽ không nói nó khác biệt về mặt chất lượng, nhưng về mặt định lượng - nghĩa là, quản lý phải làm việc để ngăn chặn các vấn đề, nhưng trong trường hợp ngôn ngữ lắp ráp, nó thường có nhiều hướng dẫn (và thường chặt chẽ hơn) về những gì đang hoặc không phải là ' t chấp nhận được.

Giảm thiểu điều này phần lớn là vấn đề hướng dẫn cẩn thận hơn, hướng dẫn nhiều hơn từ nhân viên có kinh nghiệm hơn và quy ước đặt tên cụ thể hơn, được thi hành cẩn thận.

Nhân sự là một vấn đề. Tuy nhiên, những vấn đề tôi gặp phải không phải là vấn đề mà tôi mong đợi. Tìm những anh chàng có một chút tính cách "jock jock", người rất vui khi nhảy vào mã ngôn ngữ lắp ráp khá dễ dàng. Hầu hết đã làm một công việc khá hợp lý, mặc dù gần như thiếu kinh nghiệm trước đó trong việc sử dụng ngôn ngữ lắp ráp.

Khó khăn tôi gặp phải là tìm kiếm thêm nhân sự cấp cao - những người có thể giữ dự án dưới ít nhất một số khả năng kiểm soát và không hoàn toàn quen với các ngôn ngữ sẽ cung cấp (và chủ yếu thực thi) các hướng dẫn cần thiết để giữ mã hợp lý duy trì và dễ hiểu

Nhìn lại, tôi có thể đã / gây ra một số vấn đề lớn nhất trong khía cạnh đó. Tôi có thể thấy hai nguồn vấn đề từ phía tôi. Thứ nhất, tính đến thời điểm dự án Tôi đang nghĩ đến việc, tôi đã được mã hóa chủ yếu bằng các ngôn ngữ cấp cao cho khá trong một, và sử dụng lắp ráp ngôn ngữ chỉnhư một phương sách cuối cùng Như vậy, khi tôi đã sử dụng nó, gần như mọi thủ thuật có thể để đạt được hiệu suất không chỉ là trò chơi công bằng, mà còn được mong đợi. Thứ hai, trở lại khi tôi đã làm việc trên một số hệ thống được viết hoàn toàn (hoặc chủ yếu) bằng ngôn ngữ lắp ráp, nó nằm dưới một số nhà quản lý dự án khá sắt. Lúc đó tôi còn khá trẻ, và khá thẳng thắn phẫn nộ với cách họ điều hành mọi thứ, nên có xu hướng làm ngược lại. Nhìn lại, những gì họ đang làm thực sự rất quan trọng và không được thực hiện chỉ vì chúng đã cũ và không linh hoạt (điều mà tôi khá chắc chắn là cách tôi nhìn thấy mọi thứ vào thời điểm đó).


Tôi có những kỷ niệm đẹp về các nhà lắp ráp TASM và Orca / M =)
Patrick Hughes

0

theo ý kiến ​​của tôi, lắp ráp như một nền tảng phát triển có thể không phù hợp để sử dụng hàng ngày. Lý do chính cho ý kiến ​​này có thể là do lượng năng lượng tính toán được loại bỏ khỏi một quy trình nhất định So với lượng thời gian phát triển cần thiết để tối ưu hóa cùng một quy trình nhất định thường không có giá trị thời gian và năng lượng (có một thuật ngữ cụ thể cho việc này .. nghe có vẻ như người đàn ông / giờ hoặc một cái gì đó .. xin vui lòng chỉnh sửa nếu bạn biết tôi nói gì ..) có những trường hợp ngoại lệ rõ ràng được đề cập ở trên nhưng theo như lập trình chính thống thì việc lắp ráp không được sử dụng thường xuyên.

điều này đang được nói .. sự lắp ráp vẫn còn phù hợp ngày nay khi học lập trình trong bối cảnh nghiên cứu công nghệ phần mềm, nó dạy cho một ngôn ngữ lập trình cấp thấp trông như thế nào và cảm thấy như thế nào. Tôi sẽ tiếp tục và đưa ra ví dụ về những gì chúng ta sử dụng trong lớp những ngày này. chúng tôi sử dụng lắp ráp pep / 8 được phát triển bởi Stanley Warford (Đại học Pepperdine Hoa Kỳ) và phần mềm nguồn mở của nó được đưa ra ở đây . Chủ yếu được sử dụng vì nó ảo hóa cpu và hiển thị nội dung bộ nhớ trong khi chuyển qua mã trong khi nó đang chạy (khá hữu ích cho việc học, gỡ lỗi).

Vì vậy, tùy thuộc vào lắp ráp sử dụng của bạn có thể có hoặc không có liên quan theo ý kiến ​​của tôi.


0

Tôi nghĩ bạn đang hỏi "xe tải có còn phù hợp nếu chúng ta có xe không?". Ý tôi là, lắp ráp có phạm vi ứng dụng rất rộng nhưng không rộng bằng lập trình cấp cao, giống như cách có ít xe tải hơn ô tô.

Trong các trường như tối ưu hóa thuật toán, bạn có thể sử dụng các thanh ghi bộ xử lý trực tiếp để cải thiện thuật toán xử lý hình ảnh / video.

Trong các lĩnh vực như mật mã, bạn có thể sử dụng nó theo cùng một cách.

Trong các bộ xử lý mới có kiến ​​trúc mới (hãy nhớ khi bộ vi xử lý tế bào được phát hành), chắc chắn họ phải viết bộ tải khởi động và lắp ráp (và với bộ xử lý cũ, nhưng bộ xử lý được sử dụng trong thời gian dài có nền tảng rất ổn định và khó cải thiện nó).

Và nhiều ví dụ khác có thể được đưa ra, vì vậy nó phụ thuộc vào lĩnh vực mà công ty bạn tập trung, nếu công ty của bạn dành riêng cho phát triển web / di động, rất có thể bạn không cần nó, nhưng nếu công ty của bạn tập trung vào vi điều khiển, hệ thống nhúng, vv là rất có thể bạn cần nó.

Và sự sẵn có của nhân viên, điều này phụ thuộc vào, tôi đoán rằng nếu bạn hỏi trong Intel, Qualcomm, ... họ phải có một danh sách lập trình viên lắp ráp lớn (giống như nếu bạn hỏi tại nơi làm việc của bạn "có bao nhiêu tài xế xe tải ở đây?" nghĩ không nhiều, nhưng điều đó không có nghĩa là không có ở những nơi khác. Điều gì xảy ra nếu bạn hỏi "có bao nhiêu người lái xe quanh đây?").


-3

Nếu bạn thực sự muốn biết tại sao học lắp ráp là đặt cược tốt nhất. Đây là những lý do.

  1. Không cần phải học lắp ráp, nếu bạn định lập trình trên visual basic và MS.
  2. Không cần phải học lắp ráp, nếu bạn không tạo ra các tiện ích vi điều khiển nghiêm trọng.
  3. Không cần phải học lắp ráp, nếu bạn có một bộ nhớ bất động sản theo ý của bạn trong khi làm việc với vi điều khiển (thần giúp bạn trong khi giao tiếp bộ nhớ với vi điều khiển)
  4. Không cần phải học lắp ráp, nếu bạn không muốn thần như quyền lực đối với bộ vi điều khiển / bộ vi xử lý của bạn.
  5. Không biết lắp ráp cũng giống như biết tảng băng trôi. Bạn có thể thấy 25% những gì của bạn và khả năng siêu nhỏ của bạn và 75% bạn sẽ không bao giờ biết hoặc hiểu
  6. Hãy thử chạy hệ điều hành Kolibris hoàn toàn bằng văn bản !!! Bạn đã thấy một hệ điều hành khởi động chưa đầy 5 giây và ứng dụng bắt đầu chạy chỉ sau 1 giây nhấp chuột.
  7. Trình biên dịch hiện đại có các hàm mục đích chung trong phần phụ trợ và do đó mã cuối cùng được tạo sẽ nặng hơn so với hội.

Hội giống như Natasha Romanoff của Avengers. Đó là một sự quyến rũ và ma thuật. Đầu tiên, nó sẽ cắn bạn nhưng tin tôi đi bạn sẽ không bao giờ quên mùi vị.


1
điều này dường như không cung cấp bất cứ điều gì đáng kể qua các điểm được thực hiện và giải thích trong 5 câu trả lời trước
gnat
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.