Tại sao x86 lại xấu? Tại sao nó bị coi là kém hơn khi so sánh với những người khác? [đóng cửa]

Gần đây tôi đã đọc một số kho lưu trữ SO và gặp các câu lệnh chống lại kiến ​​trúc x86.

• Tại sao chúng ta cần kiến ​​trúc CPU khác nhau cho máy chủ & mini / máy tính lớn và lõi hỗn hợp? nói
  " Kiến trúc PC là một mớ hỗn độn, bất kỳ nhà phát triển hệ điều hành nào cũng sẽ nói với bạn điều đó. "

• Học Hợp ngữ có đáng để nỗ lực không? (đã lưu trữ ) nói rằng
  " Hãy nhận ra rằng kiến ​​trúc x86 rất kinh khủng "

• Có cách nào dễ dàng để học trình hợp ngữ x86 không? nói
  " Hầu hết các trường đại học dạy lắp ráp trên một cái gì đó như MIPS vì nó dễ hiểu hơn nhiều, lắp ráp x86 thực sự xấu xí "

và nhiều bình luận khác như

• "So với hầu hết các kiến ​​trúc, X86 khá tệ."

• " Đó chắc chắn là sự khôn ngoan thông thường mà X86 kém hơn MIPS, SPARC và PowerPC "

• " x86 là xấu "

Tôi đã thử tìm kiếm nhưng không tìm thấy bất kỳ lý do nào. Tôi thấy x86 không tệ có lẽ vì đây là kiến ​​trúc duy nhất tôi quen thuộc.

Ai đó có thể vui lòng cho tôi lý do để xem xét x86 xấu / xấu / kém hơn so với những người khác.

Một số lý do có thể cho nó:

1. x86 là ISA tương đối cũ (tiền thân của nó là những năm 8086)
2. x86 đã phát triển đáng kể nhiều lần, nhưng cần phải có phần cứng để duy trì khả năng tương thích ngược với các tệp nhị phân cũ. Ví dụ, phần cứng x86 hiện đại vẫn hỗ trợ chạy mã 16 bit nguyên bản. Ngoài ra, tồn tại một số mô hình định địa chỉ bộ nhớ để cho phép mã cũ hơn hoạt động với nhau trên cùng một bộ xử lý, chẳng hạn như chế độ thực, chế độ được bảo vệ, chế độ 8086 ảo và chế độ dài (amd64). Điều này có thể gây nhầm lẫn cho một số người.
3. x86 là một máy CISC. Trong một thời gian dài, điều này có nghĩa là nó chậm hơn so với các máy RISC như MIPS hoặc ARM, bởi vì các lệnh có sự phụ thuộc lẫn nhau về dữ liệu và cờ làm cho hầu hết các dạng song song mức lệnh khó thực hiện. Các triển khai hiện đại chuyển các hướng dẫn x86 thành các hướng dẫn giống RISC được gọi là " micro-ops " dưới vỏ bọc để làm cho các loại tối ưu hóa này trở nên thực tế để triển khai trong phần cứng.
4. Ở một số khía cạnh, x86 không thua kém, nó chỉ khác. Ví dụ: đầu vào / đầu ra được xử lý dưới dạng ánh xạ bộ nhớ trên đại đa số các kiến ​​trúc, nhưng không phải trên x86. (NB: Các máy x86 hiện đại thường có một số dạng hỗ trợ DMA và giao tiếp với phần cứng khác thông qua ánh xạ bộ nhớ; nhưng ISA vẫn có các lệnh I / O như INvà OUT)
5. ISA x86 có rất ít thanh ghi kiến ​​trúc, điều này có thể buộc các chương trình quay vòng qua bộ nhớ thường xuyên hơn mức cần thiết. Các hướng dẫn bổ sung cần thiết để thực hiện việc này lấy tài nguyên thực thi có thể được chi cho công việc hữu ích, mặc dù chuyển tiếp cửa hàng hiệu quảgiữ độ trễ thấp. Các triển khai hiện đại với việc đổi tên thanh ghi thành một tệp thanh ghi vật lý lớn có thể giữ nhiều lệnh trong quá trình hoạt động, nhưng việc thiếu thanh ghi kiến ​​trúc vẫn là một điểm yếu đáng kể của x86 32-bit. Sự gia tăng của x86-64 từ 8 lên 16 số nguyên và thanh ghi vectơ là một trong những yếu tố lớn nhất khiến mã 64bit nhanh hơn 32-bit (cùng với lệnh gọi thanh ghi ABI hiệu quả hơn), chứ không phải tăng chiều rộng của mỗi thanh ghi. Việc tăng thêm từ 16 đến 32 thanh ghi số nguyên sẽ giúp một số, nhưng không nhiều. (Tuy nhiên, AVX512 tăng lên 32 thanh ghi vectơ vì mã dấu phẩy động có độ trễ cao hơn và thường cần nhiều hằng số hơn.) ( Xem nhận xét )

6. Mã lắp ráp x86 phức tạp vì x86 là một kiến ​​trúc phức tạp với nhiều tính năng. Danh sách hướng dẫn cho một máy MIPS điển hình nằm gọn trên một tờ giấy có kích thước bằng chữ cái. Danh sách tương đương cho x86 lấp đầy một số trang và các hướng dẫn chỉ làm được nhiều hơn, vì vậy bạn thường cần giải thích nhiều hơn về những gì họ làm hơn là một danh sách có thể cung cấp. Ví dụ: MOVSBlệnh cần một khối mã C tương đối lớn để mô tả những gì nó làm:

   if (DF==0) 
     *(byte*)DI++ = *(byte*)SI++; 
   else 
     *(byte*)DI-- = *(byte*)SI--;
   

   Đó là một lệnh duy nhất thực hiện một tải, một lưu trữ và hai lệnh cộng hoặc trừ (được điều khiển bởi đầu vào cờ), mỗi lệnh sẽ là các lệnh riêng biệt trên máy RISC.

   Mặc dù sự đơn giản của MIPS (và các kiến ​​trúc tương tự) không nhất thiết khiến chúng trở nên vượt trội, nhưng để dạy phần giới thiệu về lớp hợp ngữ, bạn nên bắt đầu với một ISA đơn giản hơn . Một số lớp hợp ngữ dạy một tập con cực kỳ đơn giản của x86 được gọi là y86 , được đơn giản hóa đến mức không hữu ích cho việc sử dụng thực tế (ví dụ: không có lệnh shift) hoặc một số chỉ dạy các lệnh x86 cơ bản.

7. X86 sử dụng các mã opcodes có độ dài thay đổi, làm tăng thêm độ phức tạp của phần cứng đối với việc phân tích cú pháp các lệnh. Trong kỷ nguyên hiện đại, chi phí này ngày càng trở nên nhỏ bé khi CPU ngày càng bị giới hạn bởi băng thông bộ nhớ hơn là tính toán thô, nhưng nhiều bài báo và quan điểm "dựa trên x86" đến từ thời đại mà chi phí này tương đối lớn hơn nhiều.
   Cập nhật 2016: Anandtech đã đăng một cuộc thảo luận về kích thước opcode dưới x64 và AArch64 .

CHỈNH SỬA: Đây không phải là một bash x86! buổi tiệc. Tôi không có lựa chọn nào khác ngoài việc thực hiện một số đánh giá dựa trên cách diễn đạt câu hỏi. Nhưng ngoại trừ (1), tất cả những điều này đã được thực hiện vì những lý do chính đáng (xem phần bình luận). Các nhà thiết kế của Intel không hề ngu ngốc - họ muốn đạt được một số điều với kiến ​​trúc của mình và đây là một số khoản thuế họ phải trả để biến những điều đó thành hiện thực.

Cú hích chính chống lại x86 trong tâm trí tôi là nguồn gốc CISC của nó - tập lệnh chứa rất nhiều phụ thuộc lẫn nhau. Những sự phụ thuộc lẫn nhau này gây khó khăn khi thực hiện những việc như sắp xếp lại thứ tự lệnh trên chip, bởi vì các tạo tác và ngữ nghĩa của những sự phụ thuộc lẫn nhau đó phải được bảo toàn cho mỗi lệnh.

Ví dụ, hầu hết các lệnh cộng và trừ số nguyên x86 đều sửa đổi thanh ghi cờ. Sau khi thực hiện một phép cộng hoặc phép trừ, thao tác tiếp theo thường là xem các thanh ghi cờ để kiểm tra lỗi tràn, bit dấu, v.v. Nếu có một phép cộng khác sau đó, rất khó để biết liệu có an toàn để bắt đầu thực hiện phép cộng thứ hai hay không. trước khi kết quả của lần bổ sung đầu tiên được biết.

Trên kiến ​​trúc RISC, lệnh add sẽ chỉ định các toán hạng đầu vào và (các) thanh ghi đầu ra, và mọi thứ về hoạt động sẽ diễn ra chỉ khi sử dụng các thanh ghi đó. Điều này làm cho việc tách các thao tác bổ sung gần nhau dễ dàng hơn nhiều vì không có thanh ghi cờ nào buộc mọi thứ phải xếp hàng và thực thi một tệp duy nhất.

Chip DEC Alpha AXP, một thiết kế RISC theo phong cách MIPS, khá khó khăn trong các hướng dẫn có sẵn, nhưng tập lệnh được thiết kế để tránh các phụ thuộc thanh ghi ngầm giữa các lệnh. Không có thanh ghi ngăn xếp do phần cứng xác định. Không có thanh ghi cờ do phần cứng xác định. Ngay cả con trỏ hướng dẫn cũng đã được OS định nghĩa - nếu bạn muốn quay lại người gọi, bạn phải tìm cách người gọi sẽ cho bạn biết địa chỉ nào để quay lại. Điều này thường được xác định bởi quy ước gọi hệ điều hành. Tuy nhiên, trên x86, nó được xác định bởi phần cứng chip.

Dù sao, qua 3 hoặc 4 thế hệ thiết kế chip Alpha AXP, phần cứng đã từ chỗ thực thi tập lệnh spartan theo nghĩa đen với 32 thanh ghi int và 32 thanh ghi float thành một công cụ thực thi không theo thứ tự khổng lồ với 80 thanh ghi bên trong, đổi tên thanh ghi, chuyển tiếp kết quả (trong đó kết quả của một lệnh trước được chuyển tiếp đến một lệnh sau phụ thuộc vào giá trị) và tất cả các loại công cụ tăng hiệu suất hoang dã và điên rồ. Và với tất cả những tiếng chuông và tiếng còi đó, chip AXP vẫn nhỏ hơn đáng kể so với chip Pentium tương đương vào thời điểm đó, và AXP nhanh hơn rất nhiều.

Bạn không thấy những thứ tăng hiệu suất bùng nổ đó trong cây họ x86 phần lớn là do độ phức tạp của tập lệnh x86 khiến nhiều loại tối ưu hóa thực thi trở nên đắt đỏ nếu không muốn nói là không thể. Thiên tài của Intel là đã từ bỏ việc triển khai tập lệnh x86 trong phần cứng nữa - tất cả các chip x86 hiện đại thực sự là lõi RISC ở một mức độ nhất định sẽ diễn giải các lệnh x86, dịch chúng thành vi mã bên trong bảo toàn tất cả ngữ nghĩa của x86 gốc. nhưng cho phép một chút RISC không theo thứ tự và các tối ưu hóa khác trên vi mã.

Tôi đã viết rất nhiều trình biên dịch x86 và hoàn toàn có thể đánh giá cao sự tiện lợi của gốc CISC của nó. Nhưng tôi không hoàn toàn đánh giá được x86 phức tạp như thế nào cho đến khi tôi dành một chút thời gian để viết trình hợp dịch Alpha AXP. Tôi đã bị thu hút bởi sự đơn giản và đồng nhất của AXP. Sự khác biệt là rất lớn và sâu sắc.

Kiến trúc x86 bắt nguồn từ thiết kế của bộ vi xử lý 8008 và họ hàng. Các CPU này được thiết kế trong thời kỳ bộ nhớ chậm và nếu bạn có thể làm điều đó trên CPU chết, nó thường nhanh hơn rất nhiều . Tuy nhiên, không gian chết của CPU cũng rất đắt. Hai lý do này là lý do tại sao chỉ có một số ít thanh ghi có xu hướng có các mục đích đặc biệt và một tập lệnh phức tạp với đủ loại lỗi và hạn chế.

Các bộ vi xử lý khác từ cùng thời đại (ví dụ như dòng 6502) cũng có những hạn chế và khó khăn tương tự. Điều thú vị là cả dòng 8008 và dòng 6502 đều được dùng làm bộ điều khiển nhúng. Thậm chí vào thời điểm đó, các bộ điều khiển nhúng được cho là sẽ được lập trình trong trình hợp dịch và theo nhiều cách được phục vụ cho người lập trình hợp ngữ hơn là người viết trình biên dịch. (Hãy nhìn vào chip VAX để biết điều gì sẽ xảy ra khi bạn phục vụ cho việc viết trình biên dịch.) Các nhà thiết kế không mong đợi chúng trở thành nền tảng máy tính có mục đích chung; đó là những thứ giống như những người tiền nhiệm của POWER archicture dành cho. Tất nhiên, cuộc cách mạng Máy tính gia đình đã thay đổi điều đó.

Tôi có một số khía cạnh bổ sung ở đây:

Hãy xem xét hoạt động "a = b / c" x86 sẽ thực hiện điều này như

  mov eax,b
  xor edx,edx
  div dword ptr c
  mov a,eax

Như một phần thưởng bổ sung của lệnh div edx sẽ chứa phần còn lại.

Một bộ xử lý RISC sẽ yêu cầu đầu tiên tải địa chỉ của b và c, tải b và c từ bộ nhớ đến các thanh ghi, thực hiện phép chia và tải địa chỉ của a rồi lưu trữ kết quả. Cú pháp Dst, src:

  mov r5,addr b
  mov r5,[r5]
  mov r6,addr c
  mov r6,[r6]
  div r7,r5,r6
  mov r5,addr a
  mov [r5],r7

Ở đây thường sẽ không có phần còn lại.

Nếu bất kỳ biến nào được tải qua con trỏ thì cả hai chuỗi có thể dài hơn mặc dù điều này ít xảy ra hơn đối với RISC vì nó có thể có một hoặc nhiều con trỏ đã được tải trong một thanh ghi khác. x86 có ít thanh ghi hơn nên khả năng con trỏ nằm trong một trong số chúng là nhỏ hơn.

Ưu và nhược điểm:

Các lệnh RISC có thể được trộn với mã xung quanh để cải thiện việc lập lịch lệnh, điều này ít xảy ra với x86 mà thay vào đó, x86 thực hiện điều này (nhiều hoặc ít tùy thuộc vào trình tự) bên trong chính CPU. Chuỗi RISC ở trên thường sẽ dài 28 byte (7 lệnh có độ rộng 32 bit / 4 byte mỗi lệnh) trên kiến ​​trúc 32 bit. Điều này sẽ khiến bộ nhớ ngoài chip hoạt động nhiều hơn khi tìm nạp các hướng dẫn (bảy lần tìm nạp). Chuỗi x86 dày đặc hơn chứa ít lệnh hơn và mặc dù độ rộng của chúng khác nhau, có thể bạn cũng đang xem trung bình 4 byte / lệnh ở đó. Ngay cả khi bạn có bộ nhớ đệm hướng dẫn để tăng tốc bảy lần tìm nạp này có nghĩa là bạn sẽ có ba lần thiếu hụt ở nơi khác để bù đắp so với x86.

Kiến trúc x86 với ít thanh ghi hơn để lưu / khôi phục có nghĩa là nó có thể sẽ thực hiện chuyển mạch luồng và xử lý ngắt nhanh hơn RISC. Nhiều thanh ghi hơn để lưu và khôi phục đòi hỏi nhiều không gian ngăn xếp RAM tạm thời hơn để thực hiện ngắt và nhiều không gian ngăn xếp cố định hơn để lưu trữ trạng thái luồng. Những khía cạnh này sẽ làm cho x86 trở thành ứng cử viên tốt hơn để chạy RTOS thuần túy.

Trên một lưu ý cá nhân hơn, tôi thấy việc viết RISC assembly khó hơn x86. Tôi giải quyết vấn đề này bằng cách viết quy trình RISC trong C, biên dịch và sửa đổi mã đã tạo. Điều này hiệu quả hơn từ quan điểm sản xuất mã và có lẽ kém hiệu quả hơn từ quan điểm thực thi. Tất cả 32 đăng ký để theo dõi. Với x86 thì ngược lại: 6-8 thanh ghi có tên "thật" làm cho vấn đề dễ quản lý hơn và tạo thêm niềm tin rằng mã được tạo ra sẽ hoạt động như mong đợi.

Xấu xí? Đó là trong mắt của người xử lý. Tôi thích "khác biệt".

Tôi nghĩ câu hỏi này có một giả định sai. Nó chủ yếu chỉ là những học giả bị ám ảnh bởi RISC gọi x86 là xấu xí. Trên thực tế, ISA x86 có thể thực hiện trong một hoạt động lệnh đơn lẻ sẽ cần đến 5-6 lệnh trên RISC ISA. Người hâm mộ RISC có thể phản đối rằng các CPU x86 hiện đại phá vỡ các lệnh "phức tạp" này thành các microops; Tuy nhiên:

1. Trong nhiều trường hợp, điều đó chỉ đúng một phần hoặc hoàn toàn không đúng. Các hướng dẫn "phức tạp" hữu ích nhất trong x86 là những thứ như mov %eax, 0x1c(%esp,%edi,4)chế độ định địa chỉ, và chúng không được chia nhỏ.
2. Điều thường quan trọng hơn trên các máy hiện đại không phải là số chu kỳ được sử dụng (vì hầu hết các tác vụ không bị ràng buộc bởi cpu) mà là tác động của bộ đệm lệnh của mã. 5-6 lệnh kích thước cố định (thường là 32bit) sẽ ảnh hưởng đến bộ nhớ cache nhiều hơn một lệnh phức tạp hiếm khi nhiều hơn 5 byte.

x86 thực sự hấp thụ tất cả các khía cạnh tốt của RISC khoảng 10-15 năm trước, và những phẩm chất còn lại của RISC (thực sự là định nghĩa - tập lệnh tối thiểu) là có hại và không mong muốn.

Ngoài chi phí và độ phức tạp của việc sản xuất CPU và yêu cầu năng lượng của chúng, x86 là ISA tốt nhất . Bất kỳ ai nói với bạn theo cách khác đều đang để cho hệ tư tưởng hoặc chương trình nghị sự cản trở lý luận của họ.

Mặt khác, nếu bạn đang nhắm mục tiêu các thiết bị nhúng mà chi phí của CPU được tính, hoặc các thiết bị nhúng / di động nơi tiêu thụ năng lượng là mối quan tâm hàng đầu, ARM hoặc MIPS có thể có ý nghĩa hơn. Hãy nhớ rằng mặc dù bạn vẫn phải xử lý thêm ram và kích thước nhị phân cần thiết để xử lý mã dễ dàng lớn hơn 3-4 lần và bạn sẽ không thể đạt được gần hiệu suất. Điều này có quan trọng hay không phụ thuộc rất nhiều vào những gì bạn sẽ chạy trên nó.

ngôn ngữ trình hợp dịch x86 không quá tệ. Đó là khi bạn truy cập vào mã máy, nó bắt đầu trở nên thực sự xấu xí. Mã hóa lệnh, chế độ định địa chỉ, v.v. phức tạp hơn nhiều so với mã hóa đối với hầu hết các CPU RISC. Và có thêm nhiều điều thú vị được tích hợp cho các mục đích tương thích ngược - thứ chỉ phát huy tác dụng khi bộ xử lý ở một trạng thái nhất định.

Ví dụ, trong các chế độ 16-bit, việc định địa chỉ có vẻ rất kỳ lạ; có một chế độ địa chỉ cho [BX+SI], nhưng không có một cho [AX+BX]. Những thứ như vậy có xu hướng phức tạp hóa việc sử dụng sổ đăng ký, vì bạn cần đảm bảo giá trị của mình trong một sổ đăng ký mà bạn có thể sử dụng khi cần.

(May mắn thay, chế độ 32-bit tốt hơn nhiều (mặc dù bản thân nó vẫn hơi kỳ lạ - ví dụ như phân đoạn) và mã x86 16-bit phần lớn không còn liên quan nữa ngoài bộ tải khởi động và một số môi trường nhúng.)

Ngoài ra còn có những thứ còn sót lại từ những ngày xa xưa, khi Intel đang cố gắng biến x86 trở thành bộ xử lý tối ưu. Các hướng dẫn dài một vài byte đã thực hiện các tác vụ mà không ai thực sự làm được nữa, vì chúng thực sự quá chậm hoặc phức tạp. ENTER vàHướng dẫn LOOP , đối với hai ví dụ - lưu ý rằng mã khung ngăn xếp C giống như "push ebp; mov ebp, esp" và không phải "enter" đối với hầu hết các trình biên dịch.

Tôi không phải là một chuyên gia, nhưng có vẻ như nhiều tính năng khiến mọi người không thích nó có thể là lý do nó hoạt động tốt. Vài năm trước, có các thanh ghi (thay vì một ngăn xếp), các khung thanh ghi, v.v. được coi là những giải pháp tốt để làm cho kiến ​​trúc có vẻ đơn giản hơn đối với con người. Tuy nhiên, hiện nay, điều quan trọng là hiệu suất bộ nhớ cache và các từ có độ dài thay đổi của x86 cho phép nó lưu trữ nhiều lệnh hơn trong bộ nhớ cache. "Giải mã hướng dẫn", mà tôi tin rằng các đối thủ đã chỉ ra từng chiếm một nửa chip, gần như không còn nhiều như vậy nữa.

Tôi nghĩ tính song song là một trong những yếu tố quan trọng nhất hiện nay - ít nhất là đối với các thuật toán đã chạy đủ nhanh để có thể sử dụng được. Việc thể hiện tính song song cao trong phần mềm cho phép phần cứng giảm bớt (hoặc thường ẩn hoàn toàn) độ trễ bộ nhớ. Tất nhiên, tương lai kiến ​​trúc vươn xa hơn có lẽ là trong một lĩnh vực như điện toán lượng tử.

Tôi đã nghe từ nVidia rằng một trong những sai lầm của Intel là họ giữ các định dạng nhị phân gần với phần cứng. CUDA's PTX thực hiện một số tính toán sử dụng thanh ghi nhanh (tô màu đồ thị), vì vậy nVidia có thể sử dụng máy đăng ký thay vì máy ngăn xếp, nhưng vẫn có đường dẫn nâng cấp không phá vỡ tất cả phần mềm cũ.

Bên cạnh những lý do mà mọi người đã đề cập:

• x86-16 có một sơ đồ đánh địa chỉ bộ nhớ khá lạ cho phép một vị trí bộ nhớ duy nhất được đánh địa chỉ theo 4096 cách khác nhau, RAM giới hạn ở 1 MB và buộc các lập trình viên phải xử lý hai kích thước con trỏ khác nhau. May mắn thay, việc chuyển sang 32-bit đã làm cho tính năng này trở nên không cần thiết, nhưng các chip x86 vẫn mang trong mình các thanh ghi phân đoạn.
• Trong khi không phải là một lỗi của x86 cho mỗi gia nhập , x86 ước gọi không được tiêu chuẩn hóa như MIPS là (chủ yếu là vì MS-DOS không đi kèm với bất kỳ trình biên dịch), để lại cho chúng ta sự lộn xộn của __cdecl, __stdcall, __fastcallvv

Tôi nghĩ rằng bạn sẽ đi đến một phần của câu trả lời nếu bạn cố gắng viết một trình biên dịch nhắm mục tiêu x86 hoặc nếu bạn viết một trình giả lập máy x86 hoặc thậm chí nếu bạn cố gắng triển khai ISA trong một thiết kế phần cứng.

Mặc dù tôi hiểu "x86 là xấu xí!" tranh luận, tôi vẫn nghĩ nó vui hơn việc viết assembly x86 hơn MIPS (ví dụ) - cái sau chỉ đơn giản là tẻ nhạt. Nó luôn luôn tốt cho các trình biên dịch hơn là cho con người. Tôi không chắc một con chip có thể thù địch hơn với người viết trình biên dịch nếu nó cố gắng ...

Phần xấu nhất đối với tôi là cách thức hoạt động của phân đoạn (chế độ thực) - rằng bất kỳ địa chỉ vật lý nào cũng có 4096 phân đoạn: bí danh offset. Lần cuối cùng bạn cần điều đó là khi nào? Mọi thứ sẽ đơn giản hơn rất nhiều nếu phần phân đoạn là các bit bậc cao hơn của địa chỉ 32 bit.

1. x86 có một bộ thanh ghi đa năng rất, rất hạn chế

2. nó thúc đẩy một phong cách phát triển rất kém hiệu quả ở cấp độ thấp nhất (địa ngục CISC) thay vì một phương pháp luận tải / lưu trữ hiệu quả

3. Intel đã đưa ra quyết định kinh hoàng khi giới thiệu mô hình phân đoạn / bù đắp - bộ nhớ hoàn toàn ngu ngốc để duy trì khả năng tương thích với công nghệ lỗi thời (tại thời điểm này!)

4. Vào thời điểm mà tất cả mọi người đều sử dụng 32 bit, x86 đã kìm hãm thế giới PC chính thống bằng một con số 16 bit ít ỏi (hầu hết trong số họ - 8088 - thậm chí chỉ có đường dẫn dữ liệu ngoài 8 bit, thậm chí còn đáng sợ hơn!)

Đối với tôi (và tôi là một cựu chiến binh DOS đã từng chứng kiến ​​mọi thế hệ PC từ góc độ nhà phát triển!) Thì điểm 3 là tệ nhất.

Hãy tưởng tượng tình huống sau đây mà chúng ta đã có vào đầu những năm 90 (chính thống!):

a) Hệ điều hành có những hạn chế điên cuồng vì những lý do cũ (640kB RAM dễ truy cập) - DOS

b) Một phần mở rộng của hệ điều hành (Windows) có thể làm được nhiều hơn về RAM, nhưng bị hạn chế khi nói đến những thứ như trò chơi, v.v. và không phải là thứ ổn định nhất trên Trái đất (may mắn là điều này đã thay đổi sau đó, nhưng tôi Tôi đang nói về đầu những năm 90 ở đây)

c) Hầu hết phần mềm vẫn là DOS và chúng tôi phải tạo đĩa khởi động thường xuyên cho phần mềm đặc biệt, bởi vì có EMM386.exe này mà một số chương trình thích, một số chương trình khác lại ghét (đặc biệt là các game thủ - và tôi là một game thủ AVID vào thời điểm này - biết gì không? tôi đang nói về đây)

d) Chúng tôi bị giới hạn ở MCGA 320x200x8 bit (ok, có nhiều hơn một chút với các thủ thuật đặc biệt, 360x480x8 là có thể, nhưng chỉ khi không có hỗ trợ thư viện thời gian chạy), mọi thứ khác lộn xộn và kinh khủng ("VESA" - lol)

e) Nhưng về phần cứng, chúng tôi có máy 32 bit với khá nhiều megabyte RAM và card VGA hỗ trợ lên đến 1024x768

Lý do của tình trạng tồi tệ này?

Một quyết định thiết kế đơn giản của Intel. Mức độ tương thích của máy (KHÔNG phải mức nhị phân!) Với thứ gì đó đã chết, tôi nghĩ đó là 8085. Các vấn đề khác, dường như không liên quan (chế độ đồ họa, v.v.) có liên quan vì lý do kỹ thuật và vì phạm vi rất hẹp kiến trúc tâm trí mà nền tảng x86 mang theo.

Ngày nay, tình hình đã khác, nhưng hãy hỏi bất kỳ nhà phát triển trình hợp ngữ nào hoặc những người xây dựng chương trình phụ trợ trình biên dịch cho x86. Số lượng đăng ký mục đích chung thấp đến mức điên cuồng không gì khác ngoài một kẻ giết người hiệu suất khủng khiếp.