Làm thế nào một CPU được thiết kế hoàn toàn cho lập trình chức năng sẽ khác nhau?

CPU ở một mức độ nào đó được thiết kế với phần mềm mà mọi người sẽ viết cho nó, hoàn toàn hoặc rõ ràng.

Dường như với tôi rằng nếu bạn nhìn vào thiết kế của các kiến ​​trúc tập lệnh, chúng rất "bắt buộc", theo nghĩa là mỗi lệnh mã hóa một lệnh kiểu bắt buộc. Đối với tôi, dường như các kiến ​​trúc tập lệnh hiện tại đã phát triển một phần dựa trên loại mã lập trình viên tạo ra.

Nếu người ta thiết kế CPU từ đầu, biết rằng nó sẽ chỉ chạy các chương trình được viết theo kiểu lập trình chức năng, thì CPU đó sẽ được thiết kế khác với CPU hiện tại như thế nào?

Trên thực tế, nó đã được thực hiện: https://en.wikipedia.org/wiki/Lisp_machine

Một khía cạnh trong thiết kế CPU cho FP là thu gom rác. GC rất quan trọng đối với các ngôn ngữ chức năng. Việc triển khai phổ biến đòi hỏi rằng GC có thể phân biệt giữa con trỏ và dữ liệu không phải con trỏ. Thực tế, điều đó có nghĩa là lưu trữ thêm một chút dọc theo dữ liệu của bạn. Đây là lý do, ví dụ, số nguyên OCaml chỉ có 31 bit trên kiến ​​trúc 32 bit và 63 bit trên kiến ​​trúc 64 bit. Số học số nguyên sau đó liên quan đến các hoạt động dịch chuyển thêm vụng về. Các ngôn ngữ khác (hoặc các loại dữ liệu OCaml khác) có thể lãng phí toàn bộ từ máy cho bit thừa đó, do đó sử dụng 128 bit cho số nguyên 64 bit. Một CPU được thiết kế nguyên bản theo hướng GC có thể có bus dữ liệu 65 bit nhưng số học 64 bit.

Điều đó nói rằng, rất nhiều ngôn ngữ phi chức năng cũng có bộ sưu tập rác và do đó sẽ thu được lợi nhuận từ các kiến ​​trúc tương ứng.

Một điều nữa xuất hiện trong đầu là việc sử dụng bộ nhớ của FP thường phân tán hơn nhiều so với các chương trình bắt buộc. Chủ yếu là vì nó ít tự nhiên để sử dụng mảng. Do đó, các chương trình này thu lợi ít hơn từ bộ nhớ đệm liên tục của bộ nhớ. Vì vậy, CPU FP có thể sử dụng các chiến lược bộ đệm khác nhau.

Nó sẽ không thay đổi gì hoặc sẽ khai thác cài đặt song song lớn như trong Reduceron và người kế nhiệm PilGRIM ¹ với một chồng lớn.

Tuyên bố rằng ban đầu nó sẽ không thay đổi gì, nhưng vì CPU là tuần tự, nên có một quá trình dịch thuật (biên dịch) sử dụng phần cứng có sẵn để mở rộng cho hiệu quả. Sẽ có một kiến ​​trúc khác, một số hoạt động sẽ nhanh hơn, một số sẽ cần các thủ thuật hack để tăng tốc nó.

Kiến trúc tạo ra sự khác biệt sẽ yêu cầu vận hành bản đồ và danh sách để chạy nhanh hơn (không phải toàn bộ câu chuyện, nhưng nó đủ để hiển thị hiệu ứng). Không có khả năng tạo phần cứng thay đổi động để chạy danh sách, vì vậy những thứ này được lưu trữ trong bộ nhớ tiếp giáp. Chúng tôi dính vào đại diện mảng của một số hình thức. Đối với bản đồ, để chạy trong cài đặt không tuần tự - chúng tôi quay lại Reduceron. Vì vậy, hiệu quả một xử lý trung tâm cho các hướng dẫn liên tiếp và hỗ trợ xử lý song song.

Điều có thể khác nhau là khả năng tải nhiều chức năng và chạy chúng mà không bị xáo trộn khung - nhưng thêm nhiều đơn vị cho các chức năng sẽ tạo ra một mớ hỗn độn với việc truy cập bộ nhớ.

Thêm vào câu trả lời của kne, GC sẽ có ích khi chạy như bộ đồng xử lý, nó sẽ là tính năng rất gọn gàng.

1: PilGRIM được mô tả đúng trong Boeijink A., Hölundredpies PKF, Kuper J. (2011) Giới thiệu PilGRIM: Một bộ xử lý để thực hiện các ngôn ngữ chức năng lười biếng. Trong: Hage J., Morazán MT (chủ biên) Triển khai và ứng dụng các ngôn ngữ chức năng. IFL 2010. Ghi chú bài giảng Khoa học máy tính, tập 6647. Springer, Berlin, Heidelberg .

Đầu tiên là một trò đùa: vì chạy một chương trình chức năng 100% không bao giờ có thể làm bất cứ điều gì hữu ích, nó chỉ đủ để có một lệnh NOP. (Tôi mở cái này cho các cuộc chiến lửa).

Vì vậy, sẽ cần phải có một số hướng dẫn bắt buộc cho IO và hỗ trợ thông thường cho lập trình mệnh lệnh.

Nếu không, nó một phần phụ thuộc vào ngôn ngữ thực tế được sử dụng. Hai thứ trên đầu tôi là Haskell và Erlang.

Tôi tin rằng Haskell có thể được hưởng lợi từ việc hỗ trợ cho các danh sách và bản đồ. Một danh sách có thể được hỗ trợ bởi các ánh xạ bộ nhớ phần cứng cụ thể, biến danh sách được liên kết thành một tập hợp các địa chỉ liên tiếp. Phần tử đầu tiên có thể là địa chỉ n, thứ hai là địa chỉ n + 1, v.v. Để xóa phần tử đầu tiên khỏi danh sách, bạn chỉ cần thay đổi con trỏ n. Cuối cùng, khi bạn xóa con trỏ n, tất cả bộ nhớ có thể được giải phóng. Bản đồ có thể được hỗ trợ dưới dạng mảng kết hợp - nhập giá trị tìm kiếm và hệ thống bộ nhớ trả về mục. Không cần tìm kiếm lặp đi lặp lại.

Đến lượt Erlang có thể được hưởng lợi từ sự hỗ trợ của các thông điệp / quy trình và đệ quy đuôi với trạng thái đầy đủ. Tin nhắn và quy trình có thể được hỗ trợ theo nhiều cách khác nhau, một ví dụ có thể là có số lượng lõi xử lý cực lớn. Đệ quy đuôi có thể được cải thiện bởi bộ điều khiển bộ nhớ, cho phép cho phép sao chép trạng thái nhanh hơn rất nhiều, có lẽ không sao chép khối dữ liệu lớn mà thay vào đó chỉ đơn giản là sửa đổi các con trỏ hệ thống bộ nhớ.