Làm thế nào có ngôn ngữ ảnh hưởng đến thiết kế CPU? [đóng cửa]

Chúng ta thường được thông báo rằng phần cứng không quan tâm chương trình được viết bằng ngôn ngữ nào vì nó chỉ nhìn thấy mã nhị phân được biên dịch, tuy nhiên đây không phải là toàn bộ sự thật. Ví dụ, hãy xem xét Z80 khiêm tốn; các phần mở rộng của nó cho tập lệnh 8080 bao gồm các hướng dẫn như CPIR rất hữu ích để quét các chuỗi kiểu C (chấm dứt NULL), ví dụ để thực hiện strlen(). Các nhà thiết kế phải xác định rằng việc chạy các chương trình C (trái ngược với Pascal, trong đó độ dài của chuỗi trong tiêu đề) là thứ mà thiết kế của họ có thể được sử dụng cho. Một ví dụ kinh điển khác là Máy Lisp .

Những ví dụ khác là gì? Ví dụ: hướng dẫn, số lượng và loại thanh ghi , chế độ địa chỉ, làm cho một bộ xử lý cụ thể ủng hộ các quy ước của một ngôn ngữ cụ thể? Tôi đặc biệt quan tâm đến các phiên bản của cùng một gia đình.

Các câu trả lời hiện có tập trung vào các thay đổi của ISA . Có những thay đổi phần cứng khác, quá. Chẳng hạn, C ++ thường sử dụng vtables cho các cuộc gọi ảo. Bắt đầu với Pentium M , Intel có thành phần "dự báo nhánh gián tiếp" giúp tăng tốc các cuộc gọi chức năng ảo.

Tập lệnh Intel 8086 bao gồm một biến thể "ret", thêm một giá trị vào con trỏ ngăn xếp sau khi bật địa chỉ trả về. Điều này hữu ích cho nhiều triển khai Pascal trong đó người gọi hàm sẽ đẩy các đối số lên ngăn xếp trước khi thực hiện cuộc gọi hàm và tắt chúng sau đó. Nếu một thường trình chấp nhận các tham số có giá trị bốn byte, thì nó có thể kết thúc bằng "RET 0004" để dọn sạch ngăn xếp. Không có hướng dẫn như vậy, một quy ước gọi như vậy có thể sẽ yêu cầu mã bật địa chỉ trả về vào một thanh ghi, cập nhật con trỏ ngăn xếp và sau đó nhảy đến thanh ghi đó.

Điều thú vị là hầu hết các mã (bao gồm các thói quen của hệ điều hành) trên Macintosh ban đầu đã sử dụng quy ước gọi Pascal mặc dù không có hướng dẫn thuận tiện trong 68000. Sử dụng quy ước gọi này đã lưu 2-4 byte mã tại một trang gọi thông thường, nhưng cần thêm 4 - 6 byte mã tại vị trí trả về của mọi hàm lấy tham số.

Một ví dụ là MIPS, có cả hai addvà adduđể bẫy và bỏ qua tràn tương ứng. (Ngoài ra subvà subu.) Nó cần loại hướng dẫn đầu tiên cho các ngôn ngữ như Ada (tôi nghĩ - tôi chưa bao giờ thực sự sử dụng Ada) mà xử lý tràn một cách rõ ràng và loại thứ hai cho các ngôn ngữ như C mà bỏ qua tràn.

Nếu tôi nhớ chính xác, CPU thực tế có một số mạch bổ sung trong ALU để theo dõi tràn. Nếu ngôn ngữ duy nhất mọi người quan tâm là C, thì nó sẽ không cần thứ này.

Sê-ri Burroughs 5000 được thiết kế để hỗ trợ ALGOL hiệu quả và iAPX-432 của Intel được thiết kế để thực hiện Ada một cách hiệu quả. Inmos Transputer có ngôn ngữ riêng, Occam. Tôi nghĩ rằng bộ xử lý Parallax "Propeller" được thiết kế để được lập trình bằng biến thể BASIC của riêng nó.

Đó không phải là ngôn ngữ, nhưng tập lệnh VAX-11 có một lệnh duy nhất để tải bối cảnh quy trình, được thiết kế sau khi có yêu cầu từ nhóm thiết kế VMS. Tôi không nhớ các chi tiết, nhưng ISTR đã mất rất nhiều hướng dẫn để thực hiện đến mức nó đặt giới hạn trên nghiêm trọng cho số lượng quy trình họ có thể lên lịch.

Một điều dường như không ai đề cập cho đến nay là những tiến bộ trong tối ưu hóa trình biên dịch (trong đó ngôn ngữ cơ bản không liên quan nhiều) đã chuyển sự thay đổi từ các bộ hướng dẫn CISC (phần lớn được thiết kế để mã hóa bởi con người) sang các bộ hướng dẫn RISC (phần lớn được thiết kế để được mã hóa bởi trình biên dịch.)

Gia đình Motorola 68000 đã giới thiệu một số địa chỉ tự động tăng tốc giúp sao chép dữ liệu qua cpu rất hiệu quả và nhỏ gọn.

[Ví dụ cập nhật]

đây là một số mã c ++ ảnh hưởng đến trình biên dịch 68000

while(someCondition)
    destination[destinationOffset++] = source[sourceOffset++]

được thực hiện trong trình biên dịch mã thông thường (mã giả, tôi quên các lệnh trình biên dịch 68000)

adressRegister1 = source
adressRegister2 = destination
while(someCondition) {
    move akku,(adressRegister1)
    move (adressRegister2), akku
    increment(adressRegister1, 1)
    increment(adressRegister2, 1)
}

với địa chỉ mới, nó trở thành một thứ gì đó tương tự

adressRegister1 = source
adressRegister2 = destination
while(someCondition) {
    move akku,(adressRegister1++)
    move (adressRegister2++), akku
}

chỉ có hai hướng dẫn trên mỗi vòng lặp thay vì 4.

Máy tính lớn dòng Z của IBM, là hậu duệ của IBM 360 từ những năm 1960.

Có một số hướng dẫn được đưa vào đó để đặc biệt tăng tốc các chương trình COBOL và Fortran. Ví dụ kinh điển là BXLE- "Chi nhánh trên Chỉ số Thấp hoặc Bằng", hầu hết là một forvòng lặp Fortran hoặc một COBOL được PERFORM VARYING x from 1 by 1 until x > ngói gọn trong một lệnh đơn.

Ngoài ra còn có cả một nhóm các hướng dẫn thập phân được đóng gói để hỗ trợ số học thập phân điểm cố định phổ biến trong các chương trình COBOL.

Các CPU Intel đời đầu có các tính năng sau, nhiều trong số chúng hiện đã lỗi thời ở chế độ 64 bit:

• Các hướng dẫn nn ENTER, LEAVE và RET [hướng dẫn ban đầu được nói rõ ràng những hướng dẫn được giới thiệu cho các ngôn ngữ có cấu trúc khối, ví dụ: Pascal, hỗ trợ các thủ tục lồng nhau]
• hướng dẫn tăng tốc số học BCD (AAA, AAM, v.v.); cũng hỗ trợ BCD trong x87
• Hướng dẫn JCXZ và LOOP để thực hiện các vòng lặp được tính
• INTO, để tạo bẫy trên tràn số học (ví dụ: trong Ada)
• XLAT cho tra cứu bảng
• BOUND để kiểm tra giới hạn mảng

Cờ ký hiệu, được tìm thấy trong thanh ghi trạng thái của nhiều CPU, tồn tại để dễ dàng thực hiện số học đã ký VÀ không dấu.

Tập lệnh SSE 4.1 giới thiệu các hướng dẫn xử lý chuỗi, cả được tính và không kết thúc (PCMPESTR, v.v.)

Ngoài ra, tôi có thể tưởng tượng rằng một số tính năng ở cấp hệ thống được thiết kế để hỗ trợ an toàn cho mã được biên dịch (kiểm tra giới hạn phân đoạn, cổng gọi với sao chép tham số, v.v.)

Một số bộ xử lý ARM, chủ yếu là các bộ xử lý trong thiết bị di động, bao gồm (d) phần mở rộng Jazelle, là trình thông dịch JVM phần cứng; nó giải thích trực tiếp mã byte Java. JVM nhận biết Jazelle có thể sử dụng phần cứng để tăng tốc độ thực thi và loại bỏ phần lớn JIT, nhưng dự phòng VM vẫn được đảm bảo nếu mã byte có thể được giải thích trên chip.

Bộ xử lý với đơn vị như vậy bao gồm lệnh BXJ, đặt bộ xử lý ở chế độ "Jazelle" đặc biệt hoặc nếu kích hoạt thiết bị không thành công, nó chỉ được hiểu là hướng dẫn chi nhánh thông thường. Đơn vị sử dụng lại các thanh ghi ARM để giữ trạng thái JVM.

Sự kế thừa cho công nghệ Jazelle là ThumbEE

Theo tôi biết điều này là phổ biến hơn trong quá khứ.

Có một phiên câu hỏi trong đó James Gosling nói rằng có những người đang cố gắng tạo ra phần cứng có thể xử lý tốt hơn với mã byte JVM, nhưng sau đó những người này sẽ tìm ra cách để làm điều đó với intel x86 "chung" (có thể biên dịch mã byte theo một cách thông minh nào đó).

Ông nói rằng có lợi thế trong việc sử dụng chip phổ biến chung (chẳng hạn như intel) bởi vì nó có một tập đoàn lớn ném một khoản tiền lớn vào sản phẩm.

Video đáng để xem. Anh ấy nói về điều này vào phút 19 hoặc 20.

Tôi đã thực hiện một tìm kiếm trang nhanh và dường như không ai đề cập đến CPU được phát triển đặc biệt để thực thi Forth . Các ngôn ngữ lập trình Forth được ngăn xếp dựa, nhỏ gọn, và được sử dụng trong hệ thống điều khiển.

Các iAPX Intel CPU được thiết kế đặc biệt cho các ngôn ngữ OO. Mặc dù vậy, không hoàn toàn làm việc ra.

Các iAPX 432 ( intel nâng cao kiến trúc bộ xử lý ) đã thiết kế bộ vi xử lý 32-bit đầu tiên của Intel, được giới thiệu vào năm 1981 như là một bộ ba mạch tích hợp. Nó được dự định là thiết kế chính của Intel trong những năm 1980, thực hiện nhiều tính năng quản lý bộ nhớ và đa nhiệm tiên tiến. Do đó, thiết kế được gọi là Micromainframe ...

IAPX 432 được "thiết kế để được lập trình hoàn toàn bằng các ngôn ngữ cấp cao" , với Ada là chính và nó hỗ trợ lập trình hướng đối tượng và thu gom rác trực tiếp trong phần cứng và vi mã . Hỗ trợ trực tiếp cho các cấu trúc dữ liệu khác nhau cũng nhằm mục đích cho phép các hệ điều hành hiện đại cho iAPX 432 được triển khai bằng cách sử dụng mã chương trình ít hơn nhiều so với các bộ xử lý thông thường. Các tính chất và tính năng này dẫn đến một thiết kế phần cứng và vi mã phức tạp hơn nhiều so với hầu hết các bộ xử lý của thời đại, đặc biệt là bộ vi xử lý.

Sử dụng công nghệ bán dẫn thời đó, các kỹ sư của Intel không thể dịch thiết kế thành triển khai đầu tiên rất hiệu quả. Cùng với việc thiếu tối ưu hóa trong trình biên dịch Ada sớm, điều này đã góp phần vào các hệ thống máy tính khá chậm nhưng đắt tiền, thực hiện các điểm chuẩn điển hình với tốc độ bằng khoảng 1/4 tốc độ của chip 80286 mới ở cùng tần số (đầu năm 1982).

Khoảng cách hiệu suất ban đầu với cấu hình khá thấp và dòng 8086 giá thấp này có lẽ là lý do chính khiến kế hoạch của Intel thay thế cái sau (sau này gọi là x86) bằng iAPX 432 không thành công. Mặc dù các kỹ sư đã tìm ra cách để cải thiện thiết kế thế hệ tiếp theo, kiến trúc Khả năng của iAPX 432 giờ đây đã bắt đầu được coi là một chi phí triển khai hơn là hỗ trợ đơn giản hóa.

Dự án iAPX 432 là một thất bại thương mại cho Intel ...

68000 có MOVEM phù hợp nhất để đẩy nhiều thanh ghi lên ngăn xếp trong một lệnh duy nhất, đó là điều mà nhiều ngôn ngữ mong đợi.

Nếu bạn đã thấy MOVEM (MOVE Nhiều) trước JSR (Jump SubRoutine) trong toàn bộ mã thì bạn thường biết rằng bạn đang xử lý mã tuân thủ C.

MOVEM cho phép tự động tăng thanh ghi đích cho phép mỗi lần sử dụng tiếp tục xếp chồng trên đích hoặc xóa khỏi ngăn xếp trong trường hợp tự động giảm.

http://68k.hax.com/MOVEM

Kiến trúc AVR của Atmel hoàn toàn được thiết kế từ đầu để phù hợp với lập trình trong C. Ví dụ, ghi chú ứng dụng này sẽ phát triển thêm.

IMO điều này có liên quan chặt chẽ với câu trả lời tuyệt vời của rockets4kids , với PIC16 đầu tiên được phát triển để lập trình trình biên dịch trực tiếp (tổng cộng 40 lệnh), với các gia đình sau này nhắm mục tiêu C.

Khi bộ đồng xử lý số 8087 được thiết kế, các ngôn ngữ khá phổ biến để thực hiện tất cả các phép toán dấu phẩy động bằng cách sử dụng loại có độ chính xác cao nhất và chỉ làm tròn kết quả thành độ chính xác thấp hơn khi gán nó cho biến có độ chính xác thấp hơn. Trong tiêu chuẩn C ban đầu, ví dụ, trình tự:

float a = 16777216, b = 0.125, c = -16777216;
float d = a+b+c;

sẽ thúc đẩy avà bđể double, thêm chúng, thúc đẩy cđể double, thêm nó, và sau đó lưu trữ kết quả làm tròn đến float. Mặc dù trong nhiều trường hợp, trình biên dịch tạo mã sẽ thực hiện các thao tác trực tiếp trên loại nhanh hơn float, đơn giản hơn là có một tập các thói quen dấu phẩy động chỉ hoạt động trên loại double, cùng với các thường trình để chuyển đổi thành / từ float, hơn là có các bộ thói quen riêng để xử lý các hoạt động trên floatvà double. 8087 được thiết kế xoay quanh phương pháp tiếp cận số học, thực hiện tất cả các hoạt động số học bằng cách sử dụng loại dấu phẩy động 80 bit [80 bit có thể được chọn vì:

1. Trên nhiều bộ xử lý 16 và 32 bit, hoạt động nhanh hơn với mantissa 64 bit và số mũ riêng biệt hơn là hoạt động với giá trị chia một byte giữa mantissa và lũy thừa.

2. Rất khó để thực hiện các tính toán chính xác đến độ chính xác đầy đủ của các loại số mà người ta đang sử dụng; nếu một người đang cố gắng tính toán một cái gì đó như log10 (x), thì việc tính kết quả chính xác trong vòng 100ulp của loại 80 bit sẽ dễ dàng và nhanh hơn so với tính toán một kết quả chính xác trong vòng 1ulp của 64 bit loại và làm tròn kết quả trước thành độ chính xác 64 bit sẽ mang lại giá trị 64 bit chính xác hơn giá trị sau.

Thật không may, các phiên bản tương lai của ngôn ngữ đã thay đổi ngữ nghĩa về cách các loại dấu phẩy động nên hoạt động; trong khi ngữ nghĩa 8087 sẽ rất tốt nếu các ngôn ngữ đã hỗ trợ chúng một cách nhất quán, nếu kiểu trả về các hàm F1 (), f2 (), v.v. float, nhiều tác giả trình biên dịch sẽ tự lấy nó để tạo long doublebí danh cho loại kép 64 bit thay vì loại 80 bit của trình biên dịch (và không cung cấp phương tiện nào khác để tạo biến 80 bit) và để tự ý đánh giá một cái gì đó như:

double f = f1()*f2() - f3()*f4();

theo bất kỳ cách nào sau đây:

double f = (float)(f1()*f2()) - (extended_double)f3()*f4();
double f = (extended_double)f1()*f2() - (float)(f3()*f4());
double f = (float)(f1()*f2()) - (float)(f3()*f4());
double f = (extended_double)f1()*f2() - (extended_double)f3()*f4();

Lưu ý rằng nếu f3 và f4 trả về các giá trị tương ứng là F1 và f2, thì biểu thức ban đầu sẽ trả về 0 rõ ràng, nhưng nhiều biểu thức sau có thể không. Điều này dẫn đến việc mọi người lên án "độ chính xác thêm" của 8087 mặc dù công thức cuối cùng thường vượt trội hơn so với thứ ba và - với mã sử dụng loại kép mở rộng một cách thích hợp - hiếm khi kém hơn.

Trong những năm qua, Intel đã phản ứng với xu hướng ngôn ngữ (không may IMHO) về việc buộc các kết quả trung gian phải được làm tròn theo độ chính xác của toán hạng bằng cách thiết kế bộ xử lý sau của chúng để ưu tiên hành vi đó, gây bất lợi cho việc sử dụng mã cao hơn độ chính xác trên các tính toán trung gian.