ARM có gì tuyệt vời?

Trong một bình luận cho câu trả lời này, Kortuk hỏi lợi thế của ARM là gì . Lần đầu tiên tôi đã thêm một số đối số trong câu trả lời của mình, nhưng tôi nghĩ rằng câu hỏi đủ thú vị để tự nó là một câu hỏi, để có nhiều câu trả lời hơn.

Hiệu suất là một lợi thế. Là bộ xử lý 32 bit, nó vượt trội hơn (gần như) tất cả các bộ điều khiển 8 bit DMIPS-khôn ngoan. Cốt lõi cũng đã trải qua nhiều thế hệ, đọc tối ưu hóa.
Những tối ưu hóa này không chỉ thể hiện ở số hiệu suất, mà cả mức tiêu thụ năng lượng . Lõi gần đây nhất đã tăng gấp đôi tỷ lệ DMIPS / mW so với thế hệ trước (xem thêm câu trả lời này ).
ARM có sẵn từ rất nhiều nhà sản xuất , nhiều hơn bất kỳ bộ vi điều khiển nào khác và mỗi phiên bản có một số phiên bản để lựa chọn, với các kết hợp khác nhau của các thiết bị ngoại vi và bộ nhớ trên chip và gói. Trường hợp điển hình: NXP cung cấp không dưới 35 bộ điều khiển với Ethernet trên chip .
ARM làkhông tốn kém ; ARM có lẽ là bộ điều khiển 32 bit đầu tiên phá vỡ rào cản USD 1.

Sự kết hợp giữa hiệu suất , cung cấp rộng rãi và chi phí thấp khiến bạn không thể bỏ qua ARM:

Trong năm 2005, khoảng 98 phần trăm của tất cả các điện thoại di động sử dụng ít nhất một lõi do ARM thiết kế trên bo mạch chủ của họ, theo nghiên cứu từ công ty phân tích Linley Group. ( nguồn )

$^2$

Một điểm chưa được đề cập: Năm 1908, một anh chàng tên là ông PL Robertson đã phát minh ra một đầu vít và trình điều khiển cải tiến mới . Ông muốn trở thành người duy nhất sản xuất ốc vít và trình điều khiển theo thiết kế của mình. Nhiều thập kỷ sau, một người khác tên ông Henry F. Phillips đã đưa ra một thiết kế thay thế . Không giống như ông Robertson, ông Phillips quan tâm đến việc cấp phép thiết kế của mình hơn là sản xuất ốc vít và trình điều khiển.

Tương tự như vậy, vào những năm 1970, Sony đã đưa ra một công nghệ có tên Betamax ; JVC đã đưa ra một cái gọi là VHS. Sony đã quan tâm đến việc sản xuất các VCR; JVC đã quan tâm hơn đến việc cấp phép.

Dường như có một mô hình ở đây. (Lưu ý: Trong một thời gian, Intel đã cấp phép cho công nghệ 80x86 của mình , nhưng trong nhiều thập kỷ, họ đã tập trung nhiều hơn vào việc phát triển các công nghệ để sử dụng nội bộ.)

1. Cùng một phần cứng / phần mềm để phát triển cho ARM của tất cả các nhà cung cấp. Bạn mua JLINK / ULINK và một số IDE Keil một lần và có thể sử dụng nó để phát triển, mô phỏng và gỡ lỗi gần như bất kỳ ARM nào trên một hành tinh.

2. Không cần học kiến ​​trúc mới khi chuyển sang nhà cung cấp chip mới => nhà cung cấp ít khóa hơn => cạnh tranh nhiều hơn => giá thấp hơn

3. Trong các quy trình công nghệ hiện đại (0,18um trở xuống) Lõi ARM rất nhỏ, việc hy sinh nó cho lõi 8 bit sẽ không tiết kiệm được bất kỳ phần nào có thể nhìn thấy của giá. Do đó, lý do của kiến ​​trúc tiêu chuẩn hiệu suất cao nhưng giá rẻ.

4. Hiệu suất - chỉ với ARM, bạn có thể có đồng hồ đơn 32 * 32-> 32 nhân và hỗ trợ phần cứng cho 32 * 32-> 64 và phân chia cho các thiết bị phụ 1 (ví dụ: STM32 cấp thấp hơn)

5. ARM không quá tham lam và không thu phí vô lý đối với giấy phép, vì vậy các nhà sản xuất có thể sản xuất kính hiển vi giá rẻ.

Tôi đang tập trung vào bộ xử lý ARM tầm trung vì những lý do sau:

1. Hỗ trợ Linux đầy đủ

   Điều này có nghĩa là trình điều khiển thiết bị gần như miễn phí. Tôi đã thực hiện đủ mã máy chủ và thiết bị USB, tôi không muốn làm điều đó nữa. Tôi cũng không quá phấn khích khi cố gắng thêm TCP / IP vào một nền tảng bộ xử lý ngẫu nhiên (mặc dù LwIP / uIP không tệ lắm). Tôi thậm chí chưa bao giờ thử làm Wi-Fi, một ngăn xếp Bluetooth thực sự, webcam, v.v. Sử dụng Linux có nghĩa là một loạt các thiết bị rất rộng trở nên dễ nói chuyện hơn nhiều.

   Tôi cũng thực sự ngạc nhiên về cách viết trình điều khiển thiết bị Linux hợp lý và dễ dàng. Sau khi thực hiện một số trình điều khiển thiết bị Windows, Linux là một giấc mơ. (Công bằng mà nói, khung trình điều khiển Windows đã cải thiện rất nhiều kể từ khi tôi làm việc đó.)

   Nền tảng phần mềm cũng tuyệt vời. Tôi nhận được mã hóa SSL, hệ thống tệp, quản lý từ xa, cập nhật ứng dụng dễ dàng (sao chép tệp thay vì bộ tải khởi động phức tạp), v.v ... Ồ, và rất nhiều tiện ích hiện có nếu bạn cần thực hiện.

   Nó cũng miễn phí bản quyền và dễ dàng uốn cong theo ý muốn của bạn hơn là nói một nền tảng WinCE nguồn đóng . (Không phải tôi thực sự là một người theo chủ nghĩa lý tưởng nguồn mở ... tất cả đều là lý do rất thực tế đối với tôi.)

   Tôi đang nói về lõi ARM với các MMU thực tế , vì vậy đây là dành cho các chip từ trung cấp đến cao cấp (mặc dù bạn có thể sử dụng μClinux tôi cho là).

2. Sự tiêu thụ năng lượng

   Điều này về cơ bản là sự lặp lại ý kiến ​​của người khác, nhưng nó là một yếu tố lớn đối với tôi. Nền tảng ARM 454 MHz hiện tại của tôi thu được 1/2 watt, 1 watt ở CPU tối đa. Bạn thậm chí không thể đến gần với x86.

Đó là khá nhiều lý do của tôi. Tôi không thấy phương trình thay đổi bất cứ lúc nào sớm.

ARM đã trải qua một quá trình:

1. Kiến trúc hướng dẫn 32 bit, có mã lớn hơn nhiều kiến ​​trúc khác, nhưng có thể được giải mã nhanh chóng và có thể thực hiện nhiều thao tác với ít lệnh hơn so với kiến ​​trúc cạnh tranh
2. Một kiến ​​trúc định dạng hướng dẫn kép, có thể chuyển đổi giữa tập lệnh ARM đẹp và mạnh mẽ (nhưng không may hơi phình to) và tập lệnh "Thumb" 16 bit ít mạnh mẽ hơn (nhưng nhỏ gọn hơn). Mỗi lệnh Thumb đều có một lệnh ARM tương ứng, giảm thiểu phần nào nhu cầu cho các lập trình viên học hai bộ hướng dẫn.
3. Kiến trúc Thumb2, đã thêm các hướng dẫn hai từ vào tập lệnh Thumb, mang lại phần lớn là win-win: mã ARM thông thường sẽ chứa hỗn hợp các hướng dẫn chỉ có trong ARM và các hướng dẫn có sẵn trong Thumb nhưng dù sao cũng phải được biểu diễn dưới dạng 32 bit; trong Thumb2, mã như vậy nhận được lợi ích không gian khi thay thế một số hướng dẫn 32 bit bằng 16 bit.
4. Một kiến ​​trúc chỉ có ngón tay cái, hạn chế hơn tôi quan tâm, nhưng nhỏ hơn và rẻ hơn bất kỳ kiến ​​trúc nào khác.

Kiến trúc ARM cho phép một số thao tác khá phức tạp được thực hiện rất nhanh - nhanh hơn nhiều so với bất kỳ con chip nào khác. Ví dụ: (sử dụng ARM7-TDMI):

  ldrh r0, [r10, # ADDR_BUS_OFS]; Đọc bus địa chỉ hệ thống đích (13 bit)
  ldrb r1, [r9, r0, lsr # 8]; Sử dụng các bit trên để tìm địa chỉ trong bảng xử lý
  thêm pc, r9, r1 lsl # 2; Đi đến xử lý thích hợp

Mỗi trình xử lý được lưu trữ dưới dạng một byte, cung cấp 1/4 dịch chuyển địa chỉ từ đầu bảng. Hiệu quả ròng là một khi nội dung của bus địa chỉ đã được tìm nạp, chỉ cần sáu chu kỳ (hai hướng dẫn) để chuyển đến một trình xử lý dựa trên năm bit trên của truy xuất, sử dụng bảng nhảy 32 byte.

Mã THUMB tương ứng sẽ giống như:

; Giả sử chúng tôi không cần r6 / r7 cho bất cứ điều gì khác, họ được chỉ định lại từ r9 / r10
  ldrh r0, [r7, # ADDR_BUS_OFS]
  di r1, r0
  lsr r1, r1, # 8; THUMB yêu cầu nguồn và đích phải giống nhau
  ldrb r1, [r6, r1]
  lsl r1, r1, # 1; Có thể sử dụng shift-left-hai, nếu địa chỉ đích được căn chỉnh toàn từ
  thêm pc, r1

Điều đó tốt từ quan điểm mật độ mã, cho rằng các hướng dẫn chỉ lớn bằng một nửa so với bản gốc, nhưng sẽ mất chín chu kỳ sau khi tìm nạp chứ không phải sáu. Trong một ứng dụng mà xe buýt đang được theo dõi sẽ chạy ở tốc độ của chính nó cho dù ARM có quản lý được hay không, các lệnh ARM nhanh hơn là một điểm cộng lớn.

Ngẫu nhiên, Thumb2 tương thích nhị phân với Thumb, tạo điều kiện cho việc sử dụng các công cụ trước đó, nhưng có nghĩa là có một số điều mà nó không thể làm tốt như ARM gốc. Ví dụ, trong ARM, người ta có thể "xoay" một bitmap 8x8 được giữ trong bốn thanh ghi bằng cách sử dụng khoảng 3 lệnh trên hai bit:

  Mov r0, r4, lsl # 25; Đặt bit trên cùng của LSB vào C và bit tiếp theo vào N
  orrcs r6, # 0x00000001
  orrmi r6, # 0x00000100

Trong Thumb2, cần phải thêm các hướng dẫn có điều kiện rõ ràng:

  Mov r0, r4, lsl # 25; Đặt bit trên cùng của LSB vào C và bit tiếp theo vào N
  itcs
  orrcs r6, # 0x00000001
  itmi
  orrmi r6, # 0x00000100

Giảm 33% hiệu quả về thời gian và không gian so với ARM; đó có lẽ là một ví dụ tồi tệ nhất về mã Thumb kém hiệu quả hơn ARM và thậm chí điều đó không thực sự khủng khiếp.

Một nhược điểm nhỏ khác của Thumb2 so với ARM: trong mã ARM, tất cả các hướng dẫn bắt đầu ở ranh giới toàn từ, tạo điều kiện cho phân tích tĩnh. Trong Thumb2, các hướng dẫn có thể tùy ý bắt đầu ở các ranh giới nửa từ và sắp xếp các ranh giới toàn từ. Phân tích tĩnh do đó có thể khó khăn hơn nhiều.

Một chút là lịch sử, Acorn muốn có CPU tùy chỉnh (ví dụ: có bộ điều khiển bộ nhớ tích hợp, v.v.) cho một máy tính mới vào những năm 1980 (8 bit 6502 đã giới hạn những gì họ có thể làm). Họ đã nói chuyện với Intel, nhưng Intel sẽ không cấp phép CPU cho họ.

Vì vậy, Acorn đã thiết kế CPU RISC rất đơn giản, nhưng vì họ không phải là nhà sản xuất CPU nên họ sẵn sàng cấp phép cho bất kỳ ai (và cần tất cả số tiền nhanh chóng họ có thể nhận được!). (Tôi tin rằng CPU hoạt động lần đầu tiên, một phần vì nó quá đơn giản và cũng là nhà thiết kế đã tạo ra rất nhiều CPU nghiên cứu khi còn ở Đại học Cambridge.)

Qua nhiều năm, thiết kế CPU trở nên dễ dàng và dễ dàng hơn trong thiết kế chip của khách hàng.

Nhà sản xuất chip cảm thấy cấp phép an toàn từ Acorn vì họ không phải là đối thủ cạnh tranh. Ngoài ra, không ai nghĩ rằng họ sẽ đến thành phố quê hương của đối thủ cạnh tranh để lấy giấy phép, vì Acorn đang ở Cambridge (người thật!) . (Có phải cơ hội của một thực tế là tìm kiếm chuyến đi tới Cambridge để đến thăm Acorn ảnh hưởng đến việc rút ngắn danh sách các lựa chọn tại bất kỳ điểm nào.)

Rất nhiều thiết kế bao gồm CPU Acorn Risc Machine dành cho hệ thống nhúng là việc sử dụng năng lượng rất quan trọng. Các công cụ phát triển tốt và rẻ cũng được tạo ra cho CPU Acorn Risc Machine.

Vì vậy, khi điện thoại di động bắt đầu cần chip tùy chỉnh với CPU nhúng, Acorn được đổi tên thành ARM và phần còn lại là lịch sử. (Có lẽ cũng có một chút rằng các CPU khác hầu hết được kiểm soát bởi Hoa Kỳ, nhưng điện thoại di động trước tiên trở nên bình thường ở Châu Âu)

(Có ai trong số này nhắc bạn về Microsoft và Dos với một nhóm nhỏ chưa biết từ IBM không?)

Thực tế rằng ARM là một trong những CPU tốt nhất vào thời điểm đó (và vẫn còn) cho rất nhiều nhiệm vụ cũng có ích - nhưng chỉ cần có thiết kế CPU "tốt nhất" là không đủ.

Vấn đề kỹ thuật sang một bên, có rất nhiều lý do phi kỹ thuật cho ARM. Nhưng câu trả lời nhanh là đây: Không phải Intel (hoặc x86).

Nếu bạn nhìn vào nơi mà các đô la R & D của CPU đang được đầu tư ngay bây giờ thì chúng rơi vào hai phe cơ bản: ARM và Intel. (Tôi đang bỏ qua các MCU nhỏ và tôi đang kết hợp AMD với Intel.) Có rất ít tiền vào PowerPC, MIPS, SPARC và các CPU lớn khác. ARM và Intel là những người duy nhất vẫn đứng vững.

Với Intel và CPU x86 khác, bạn sẽ nhận được một lượng lớn hành lý kế thừa. Ví dụ, bạn cần một chipset, BIOS và những thứ khác. Ngay cả khi CPU là siêu năng lượng hiệu quả, những thiết bị khác có xu hướng đè nặng hệ thống của bạn và làm cho nó lớn hơn, ngốn nhiều năng lượng hơn và đắt tiền hơn. Chỉ cần phát triển PCB với CPU Intel là một vấn đề lớn, và sau đó bạn phải đàm phán với nhà cung cấp BIOS, v.v. Để làm cho vấn đề tồi tệ hơn, nhiều nhà cung cấp cho chipset, BIOS, chip video, v.v. để làm kinh doanh với những người nhỏ bé sẽ không bán được dưới một triệu đơn vị mỗi năm.

Với ARM, bạn không có hành lý đó. Có rất nhiều nguồn chip từ những thứ thuộc dòng vi điều khiển cho đến những con quái vật đa lõi. Bạn không cần phải đối phó với việc cấp phép cho BIOS (điều này giống như đi đến một nhân viên bán xe đã qua sử dụng). Và các nhà sản xuất và nhà cung cấp thường tốt với bạn.

So sánh ARM7 / ARM9 với MIPS IV và có rất ít lợi thế ngoài vấn đề cấp phép đã được đề cập rõ. Các phần bên trong của tập lệnh MIPS và bus nội bộ làm cho nó vượt trội (hiệu suất trên mỗi chi phí) đối với một số loại thiết kế nhất định; đó là lý do tại sao nhiều bộ định tuyến Wi-Fi sử dụng lõi MIPS thay vì lõi ARM.

Do lõi ARM được áp dụng chủ yếu cho các thiết bị cầm tay, ASIC đã thêm nhiều tính năng kiểm soát năng lượng trong khi MIPS tập trung nhiều hơn vào hiệu suất trên mỗi chu kỳ thay vì công suất thấp hơn. Lợi ích của RISC so với Intel x86 là một cuộc thảo luận khác.

Không có lợi thế thực sự. DSP đính kèm và các bộ điều khiển khác, như GSM là thứ khiến chúng trở nên phổ biến.