X86 neden çirkin? Neden diğerlerine kıyasla daha aşağı kabul ediliyor? [kapalı]

Son zamanlarda bazı SO arşivlerini okudum ve x86 mimarisine karşı ifadelerle karşılaştım.

• Sunucu ve mini / ana bilgisayar ve karma çekirdek için neden farklı CPU mimarisine ihtiyacımız var? diyor
  " PC mimarisi bir karmaşa, herhangi bir işletim sistemi geliştiricisi size bunu söyler. "

• Assembly Dili öğrenmek çabaya değer mi? ( Arşivlenmiş ) diyor
  " x86 mimarisi iyi korkunç farkında olduklarını da "

• X86 assembler'ı öğrenmenin kolay bir yolu var mı? diyor
  " bunu anlamak çok daha basittir çünkü çoğu kolej MIPS gibi bir şey üzerinde montaj öğretmek, 86 derleme gerçekten çirkin "

ve gibi daha birçok yorum

• "Çoğu mimariyle karşılaştırıldığında, X86 oldukça kötü."

• " X86'nın MIPS, SPARC ve PowerPC'den daha düşük olduğu kesinlikle geleneksel görüştür "

• " x86 çirkin "

Aramayı denedim ama herhangi bir neden bulamadım. Muhtemelen x86'yı kötü bulmuyorum çünkü aşina olduğum tek mimari bu.

Birisi bana x86'yı diğerlerine kıyasla çirkin / kötü / aşağı olarak düşünmem için nedenler verebilir mi?

Bunun birkaç olası nedeni:

1. x86 nispeten eski ISA (kendi atalarıdır sonuçta 8086s idi)
2. x86, birkaç kez önemli ölçüde gelişmiştir, ancak eski ikili dosyalar ile geriye dönük uyumluluğu korumak için donanım gereklidir. Örneğin, modern x86 donanımı hala yerel olarak 16 bit kod çalıştırma desteği içerir. Ek olarak, gerçek mod, korumalı mod, sanal 8086 modu ve (amd64) uzun mod gibi eski kodun aynı işlemci üzerinde birlikte çalışmasına izin vermek için birkaç bellek adresleme modeli mevcuttur. Bu bazıları için kafa karıştırıcı olabilir.
3. x86 bir CISC makinesidir. Uzun bir süre için bu, MIPS veya ARM gibi RISC makinelerinden daha yavaş olduğu anlamına geliyordu, çünkü talimatlarda veri karşılıklı bağımlılığı ve komut düzeyi paralelliğinin çoğu biçiminin uygulanmasını zorlaştıran işaretler var. Modern uygulamalar, bu tür optimizasyonların donanımda uygulanmasını pratik hale getirmek için x86 talimatlarını kapakların altındaki " mikro işlem " adı verilen RISC benzeri talimatlara çevirir .
4. Bazı açılardan x86 daha aşağı değil, sadece farklı. Örneğin, girdi / çıktı, mimarilerin büyük çoğunluğunda bellek eşlemesi olarak işlenir, ancak x86'da değil. (Not: Modern x86 makineleri tipik olarak bir tür DMA desteğine sahiptir ve bellek eşleme yoluyla diğer donanımlarla iletişim kurar; ancak ISA'da hala INve gibi G / Ç talimatları vardır OUT)
5. X86 ISA'da çok az sayıda mimari kayıt vardır ve bu da programları, aksi takdirde gerekenden daha sık bellek içinde dönmeye zorlayabilir. Bunu yapmak için ihtiyaç duyulan ekstra talimatlar, verimli mağaza yönlendirme olmasına rağmen, faydalı işler için harcanabilecek yürütme kaynaklarını alır.gecikmeyi düşük tutar. Kayıt defteri büyük bir fiziksel kayıt dosyası üzerine yeniden adlandırma ile modern uygulamalar birçok talimatı çalışır durumda tutabilir, ancak mimari kayıtların eksikliği hala 32 bit x86 için önemli bir zayıflıktı. x86-64'ün 8'den 16 tamsayıya ve vektör yazmaçlarına artışı, 64 bit koddaki en büyük faktörlerden biridir, her bir yazmacın artan genişliği değil, 32-bit'ten daha hızlıdır (daha verimli kayıt arama ABI ile birlikte). 16'dan 32 tamsayı kaydına bir artış daha fazla yardımcı olabilir, ancak bu kadar değil. (AVX512, 32 vektör yazmacına yükselir, çünkü kayan noktalı kod daha yüksek gecikmeye sahiptir ve genellikle daha fazla sabit gerektirir.) (Açıklamaya bakın )

6. x86 derleme kodu karmaşıktır çünkü x86 birçok özelliğe sahip karmaşık bir mimaridir. Tipik bir MIPS makinesi için bir talimat listesi, tek bir harf boyutlu kağıt parçasına sığar. X86 için eşdeğer listeleme birkaç sayfayı doldurur ve talimatlar daha fazlasını yapar, bu nedenle genellikle ne yaptıklarına dair bir listenin sağlayabileceğinden daha büyük bir açıklamaya ihtiyacınız olur. Örneğin, MOVSBtalimatın ne yaptığını açıklamak için nispeten büyük bir C kodu bloğuna ihtiyacı vardır:

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

   Bu, her biri bir RISC makinesinde ayrı talimatlar olan bir yükleme, bir depolama ve iki toplama veya çıkarma (bir işaret girişi tarafından kontrol edilir) yapan tek bir talimattır.

   MIPS (ve benzer mimariler) basitliği onları üstün kılmazken, assembler sınıfına giriş öğretmek için daha basit bir ISA ile başlamak mantıklıdır . Bazı montaj sınıfları , gerçek kullanım için kullanışlı olmama noktasının ötesinde basitleştirilen y86 adında ultra basitleştirilmiş bir x86 alt kümesini öğretir (örneğin, kaydırma talimatları yok) veya bazıları yalnızca temel x86 komutlarını öğretir.

7. X86, talimatların ayrıştırılmasına göre donanım karmaşıklığı ekleyen değişken uzunluklu işlem kodları kullanır. Modern çağda bu maliyet, CPU'lar ham hesaplamaya göre bellek bant genişliğiyle gittikçe daha fazla sınırlı hale geldikçe, giderek azalmaktadır, ancak birçok "x86 dayatma" makalesi ve davranışı, bu maliyetin nispeten çok daha yüksek olduğu bir çağdan gelmektedir.
   2016 Güncellemesi: Anandtech, x64 ve AArch64 altındaki işlem kodu boyutlarıyla ilgili bir tartışma yayınladı .

DÜZENLEME: Bunun x86'ya vurulması gerekmiyor ! Parti. Sorunun söylendiği şekilde düşünüldüğünde, biraz dayak atmaktan başka seçeneğim yoktu. Ancak (1) dışında, tüm bunlar iyi nedenlerle yapıldı (yorumlara bakınız). Intel tasarımcıları aptal değil - mimarileriyle bazı şeyler başarmak istediler ve bunlar, bunları gerçeğe dönüştürmek için ödemeleri gereken vergilerden bazıları.

Aklımda x86'ya karşı ana darbe CISC kökenleri - komut seti birçok örtük karşılıklı bağımlılık içeriyor. Bu karşılıklı bağımlılıklar, çip üzerinde talimatın yeniden sıralanması gibi şeyler yapmayı zorlaştırır, çünkü bu karşılıklı bağımlılıkların yapıları ve anlambilimlerinin her bir talimat için korunması gerekir.

Örneğin, x86 tamsayı toplama ve çıkarma komutlarının çoğu bayrak kaydını değiştirir. Bir toplama veya çıkarma gerçekleştirdikten sonra, sonraki işlem genellikle taşma, işaret biti, vb. İçin işaretler kaydına bakmaktır. Bundan sonra başka bir ekleme varsa, 2. eklemeyi çalıştırmaya başlamanın güvenli olup olmadığını söylemek çok zordur. 1. ekin sonucu bilinmeden önce.

Bir RISC mimarisinde, add komutu, giriş işlenenlerini ve çıkış yazmaçlarını belirtir ve işlemle ilgili her şey yalnızca bu yazmaçlar kullanılarak gerçekleşir. Bu, birbirine yakın olan ekleme işlemlerinin ayrıştırılmasını çok daha kolay hale getirir çünkü her şeyi sıraya koyup tek bir dosyayı yürütmeye zorlayan hiçbir çiçeklenme bayrak kaydı yoktur.

MIPS tarzı bir RISC tasarımı olan DEC Alpha AXP yongası, mevcut talimatlarda acı verici bir şekilde spartan idi, ancak talimat seti, talimatlar arası örtük yazmaç bağımlılıklarından kaçınmak için tasarlandı. Donanım tanımlı yığın kaydı yoktu. Donanım tanımlı bayrak kaydı yoktu. Yönerge işaretçisi bile işletim sistemi tanımlıydı - arayan kişiye geri dönmek istiyorsanız, arayanın size hangi adrese döneceğinizi nasıl bildireceğini hesaplamanız gerekiyordu. Bu genellikle işletim sistemi çağrı kuralı tarafından tanımlanmıştır. X86'da ise yonga donanımı tarafından tanımlanıyor.

Her neyse, 3 veya 4 nesilden fazla Alpha AXP yonga tasarımı, donanım, 32 int yazmaç ve 32 değişken yazmaçlı spartan komut setinin gerçek bir uygulaması olmaktan, 80 dahili yazmaç, yazmaç yeniden adlandırma, büyük ölçüde sıra dışı yürütme motoruna dönüştü sonuç iletme (önceki bir talimatın sonucunun değere bağlı olan sonraki bir talimata yönlendirildiği) ve her türlü çılgın ve çılgın performans artırıcı. Ve tüm bu çanlar ve ıslıklarla, AXP yonga kalıbı hala o zamanın karşılaştırılabilir Pentium yonga kalıbından önemli ölçüde daha küçüktü ve AXP çok daha hızlıydı.

X86 soy ağacındaki şeyleri artıran bu tür performans patlamalarını görmezsiniz, çünkü x86 komut setinin karmaşıklığı birçok tür yürütme optimizasyonunu imkansız olmasa da çok pahalı hale getirir. Intel'in dehası, artık donanımda x86 komut setini uygulamaktan vazgeçmek oldu - tüm modern x86 yongaları, aslında x86 komutlarını belirli bir dereceye kadar yorumlayan ve bunları orijinal x86'nın tüm anlamlarını koruyan dahili mikrokoda dönüştüren RISC çekirdekleridir. talimat, ancak bu RISC'nin biraz çalışmasına ve mikrokod üzerinden diğer optimizasyonlara izin verir.

Çok sayıda x86 assembler yazdım ve CISC köklerinin rahatlığını tam olarak takdir edebiliyorum. Ancak Alpha AXP assembler'ı yazmak için biraz zaman harcayana kadar x86'nın ne kadar karmaşık olduğunu tam olarak anlamadım. AXP'nin sadeliği ve tekdüzeliği beni şaşkına çevirdi. Farklılıklar çok büyük ve derin.

X86 mimarisi 8008 mikroişlemci ve akrabalarının tasarımına dayanmaktadır. Bu CPU'lar belleğin yavaş olduğu bir zamanda tasarlandı ve bunu CPU kalıbı üzerinde yapabilseydiniz, genellikle çok daha hızlıydı. Bununla birlikte, CPU kalıp alanı da pahalıydı. Bu iki neden, neden özel amaçlara sahip olma eğiliminde olan az sayıda yazmaç ve her türden aldatma ve sınırlama içeren karmaşık bir talimat seti olmasıdır.

Aynı döneme ait diğer işlemciler de (örneğin, 6502 ailesi) benzer sınırlamalara ve tuhaflıklara sahiptir. İlginç bir şekilde, hem 8008 serisi hem de 6502 serisi gömülü kontrolörler olarak tasarlandı. O zamanlar bile, gömülü kontrolörlerin assembler'da programlanması ve birçok yönden derleyici yazıcıdan ziyade assembly programcısına hitap etmesi bekleniyordu. (Derleyici yazısına hitap ettiğinizde neler olduğunu görmek için VAX çipine bakın.) Tasarımcılar bunların genel amaçlı bilgisayar platformları olmasını beklemiyorlardı; POWER mimarisinin öncülleri gibi şeyler bunun içindi. Ev Bilgisayarı devrimi bunu değiştirdi elbette.

Burada birkaç ek yönüm var:

"A = b / c" x86 işleminin bunu şu şekilde uygulayacağını düşünün:

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

Div talimatının ek bir bonusu olarak edx kalanı içerecektir.

Bir RISC işlemcisi önce b ve c adreslerinin yüklenmesini, bellekten b ve c'nin kayıtlara yüklenmesini, bölme işleminin yapılmasını ve a adresinin yüklenmesini ve ardından sonucun depolanmasını gerektirir. Dst, src sözdizimi:

  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

Burada genellikle bir kalıntı olmayacak.

Herhangi bir değişken işaretçiler aracılığıyla yüklenecekse, her iki sekans da uzayabilir, ancak bu RISC için daha az olasıdır çünkü başka bir kayıtta bir veya daha fazla işaretçi zaten yüklü olabilir. x86'da daha az kayıt vardır, bu nedenle işaretçinin bunlardan birinde olma olasılığı daha düşüktür.

Lehte ve aleyhte olanlar:

RISC komutları, komut zamanlamasını iyileştirmek için çevreleyen kodla karıştırılabilir, bu, bunun yerine CPU'nun içinde bu işi yapan (sıraya bağlı olarak az çok iyi) x86 ile daha az olasıdır. Yukarıdaki RISC dizisi, 32 bit mimaride tipik olarak 28 bayt uzunluğunda (her biri 32 bit / 4 bayt genişliğinde 7 komut) olacaktır. Bu, talimatı getirirken yonga dışı belleğin daha fazla çalışmasına neden olur (yedi getirme). Daha yoğun olan x86 dizisi daha az komut içerir ve genişlikleri değişse de, muhtemelen orada da ortalama 4 bayt / talimata bakıyorsunuzdur. Bu yedi getirmeyi hızlandırmak için talimat önbellekleriniz olsa bile, x86'ya kıyasla telafi etmek için başka bir yerde üç tane açığınız olacağı anlamına gelir.

Kaydedilecek / geri yüklenecek daha az kayıt içeren x86 mimarisi, muhtemelen iş parçacığı anahtarları yapacağı ve kesintileri RISC'den daha hızlı işleyeceği anlamına gelir. Kaydetmek ve geri yüklemek için daha fazla kayıt, kesintiler için daha fazla geçici RAM yığın alanı ve iş parçacığı durumlarını depolamak için daha kalıcı yığın alanı gerektirir. Bu özellikler, x86'yı saf RTOS çalıştırmak için daha iyi bir aday haline getirmelidir.

Daha kişisel bir not olarak, RISC derlemesini yazmayı x86'ya göre daha zor buluyorum. Bunu, RISC rutinini C'de yazarak, üretilen kodu derleyerek ve değiştirerek çözüyorum. Bu, kod üretimi açısından daha verimlidir ve yürütme açısından muhtemelen daha az verimlidir. İzlenecek tüm bu 32 kayıt. X86 ile durum tam tersidir: "gerçek" adlara sahip 6-8 kayıt, sorunu daha yönetilebilir hale getirir ve üretilen kodun beklendiği gibi çalışacağına dair daha fazla güven verir.

Çirkin? Bu, bakanın gözündedir. "Farklı" yı tercih ederim.

Bu sorunun yanlış bir varsayımı olduğunu düşünüyorum. X86'ya çirkin diyenler sadece RISC takıntılı akademisyenlerdir. Gerçekte, x86 ISA, RISC ISA'larda 5-6 komut alan tek bir komut işleminde gerçekleştirebilir. RISC hayranları, modern x86 CPU'ların bu "karmaşık" talimatları mikrooplara böldüğüne karşı çıkabilir; ancak:

1. Çoğu durumda bu sadece kısmen doğrudur veya hiç doğru değildir. X86'daki en yararlı "karmaşık" talimatlar, mov %eax, 0x1c(%esp,%edi,4)örneğin adresleme modları gibi şeylerdir ve bunlar bozulmaz.
2. Modern makinelerde genellikle daha önemli olan, harcanan döngü sayısı değil (çünkü çoğu görev cpu'ya bağlı değildir), kodun talimat önbelleği etkisidir. 5-6 sabit boyutlu (genellikle 32bit) talimatlar, önbelleği, nadiren 5 bayttan fazla olan birden fazla karmaşık talimatı etkiler.

x86, yaklaşık 10-15 yıl önce RISC'nin tüm iyi yönlerini gerçekten özümsedi ve RISC'nin kalan nitelikleri (aslında tanımlayıcı olan - minimum komut seti) zararlı ve istenmeyen.

CPU üretiminin maliyeti ve karmaşıklığı ve enerji gereksinimleri bir yana, x86 en iyi ISA'dır . Size aksini söyleyen biri, ideolojinin veya gündemin akıl yürütmelerinin önüne geçmesine izin veriyor.

Öte yandan, CPU'nun maliyetinin önemli olduğu gömülü cihazları veya enerji tüketiminin önemli olduğu gömülü / mobil cihazları hedefliyorsanız, ARM veya MIPS muhtemelen daha mantıklıdır. Yine de, kolayca 3-4 kat daha büyük olan kodu işlemek için gereken ekstra ram ve ikili boyutla uğraşmanız gerekecek ve performansa yaklaşamayacağınızı unutmayın. Bunun önemli olup olmadığı, üzerinde ne çalıştıracağınıza bağlıdır.

x86 assembler dili o kadar da kötü değil. Makine koduna ulaştığınızda gerçekten çirkinleşmeye başlar. Komut kodlamaları, adresleme modları, vb. Çoğu RISC CPU'larından çok daha karmaşıktır. Ve geriye dönük uyumluluk amacıyla yerleşik ekstra eğlence var - yalnızca işlemci belirli bir durumda olduğunda devreye giren şeyler.

Örneğin 16 bitlik modlarda adresleme düpedüz tuhaf görünebilir; için bir adresleme modu var [BX+SI], ancak biri için değil [AX+BX]. Bunun gibi şeyler, ihtiyaç duyduğunuz şekilde kullanabileceğiniz bir kayıt defterinde değerinizin olmasını sağlamanız gerektiğinden, kayıt kullanımını karmaşıklaştırma eğilimindedir.

(Neyse ki, 32 bit modu çok daha mantıklıdır (yine de bazen kendisi biraz tuhaftır - örneğin bölümleme) ve 16 bit x86 kodu artık önyükleme yükleyicileri ve bazı gömülü ortamlar dışında büyük ölçüde önemsizdir.)

Intel'in x86'yı en iyi işlemci yapmaya çalıştığı eski günlerden kalanlar da var. Aslında hiç kimsenin yapmadığı görevleri yerine getiren birkaç bayt uzunluğundaki talimatlar, çünkü açıkçası çok yavaş ya da karmaşıktılar. ENTER ve LOOP talimatları , iki örnek için - C yığını çerçeve kodunun çoğu derleyici için "push ebp; mov ebp, esp" gibidir ve "enter" değildir.

Uzman değilim, ancak insanların hoşlanmamasının birçok özelliği iyi performans göstermesinin nedenleri olabilir. Birkaç yıl önce, yazmaçlara (yığın yerine), kayıt çerçevelerine vb. Sahip olmak, mimarinin insanlara daha basit görünmesini sağlamak için güzel çözümler olarak görülüyordu. Ancak günümüzde önemli olan önbellek performansı ve x86'nın değişken uzunluklu sözcükleri önbellekte daha fazla talimat depolamasına izin veriyor. Rakiplerin bir zamanlar çipin yarısını aldığına inandığım "talimat çözme" artık pek de öyle değil.

Paralelliğin günümüzde en önemli faktörlerden biri olduğunu düşünüyorum - en azından zaten kullanılabilecek kadar hızlı çalışan algoritmalar için. Yazılımda yüksek paralellik ifade etmek, donanımın bellek gecikmelerini amorti etmesine (veya genellikle tamamen gizlemesine) izin verir. Elbette, daha uzağa ulaşan mimari gelecek muhtemelen kuantum hesaplama gibi bir şeyde.

NVidia'dan Intel'in hatalarından birinin ikili formatları donanıma yakın tutmaları olduğunu duydum. CUDA'nın PTX'i bazı hızlı kayıt kullanım hesaplamaları (grafik renklendirme) yapar, böylece nVidia yığın makinesi yerine bir kayıt makinesi kullanabilir, ancak yine de tüm eski yazılımları bozmayan bir yükseltme yoluna sahiptir.

İnsanların daha önce bahsettiği nedenlerin yanı sıra:

• x86-16, tek bir bellek konumunun 4096 farklı yolla adreslenmesine, RAM'i 1 MB ile sınırlandırmasına ve programcıları iki farklı boyutta işaretçi ile uğraşmaya zorlayan oldukça garip bir bellek adresleme şemasına sahipti . Neyse ki, 32-bite geçiş bu özelliği gereksiz hale getirdi, ancak x86 yongaları hala segment kayıtlarının temelini taşıyor.
• Süre değil bir arıza x86 kendiliğinden x86 arama kuralları (MS-DOS herhangi derleyiciler ile gelmedi çünkü çoğunlukla) karmaşa ile bize bırakarak oldu MIPS gibi standardize edilmemiştir __cdecl, __stdcall, __fastcallvb

X86'yı hedefleyen bir derleyici yazmaya çalışırsanız veya bir x86 makine öykünücüsü yazarsanız veya ISA'yı bir donanım tasarımında uygulamaya çalışsanız bile, cevabın bir kısmını alacağınızı düşünüyorum.

"X86 çirkin!" argümanlar, hala x86 derlemesini yazmanın MIPS'ten daha eğlenceli olduğunu düşünüyorum (örneğin) - ikincisi sadece sıkıcı. İnsanlardan çok derleyiciler için her zaman iyi olması amaçlanmıştır. Bir çipin, denerse derleyici yazarlara karşı daha düşmanca davranacağından emin değilim ...

Benim için en çirkin kısım, (gerçek mod) segmentasyonun çalışma şeklidir - herhangi bir fiziksel adresin 4096 segmenti vardır: ofset takma adları. Buna en son ne zaman ihtiyacın vardı? Segment parçası 32 bitlik bir adresin kesinlikle daha yüksek sıralı bitleri olsaydı işler çok daha kolay olurdu.

1. x86, çok, çok sınırlı bir genel amaçlı kayıt kümesine sahiptir

2. Etkili bir yükleme / depolama metodolojisi yerine en düşük seviyede (CISC cehennemi) çok verimsiz bir geliştirme tarzını teşvik eder

3. Intel, düpedüz aptal segmenti / ofseti - modası geçmiş teknolojiyle (şu anda zaten!) Uyumlu kalmak için bellek adresleme modelini tanıtmak için korkunç bir karar verdi.

4. Herkesin 32 bit gittiği bir zamanda, x86, yetersiz 16 bit (çoğu - 8088 - sadece 8 bit harici veri yollarıyla bile, ki bu daha da korkutucu!) Ana PC dünyasını geride tuttu!

Benim için (ve her nesil bilgisayarı geliştiricilerin bakış açısından gören bir DOS tecrübesiyim!) 3. nokta en kötüsüydü.

90'ların başlarında yaşadığımız şu durumu düşünün (ana akım!):

a) Eski nedenlerden dolayı çılgın sınırlamalara sahip bir işletim sistemi (640kB kolay erişilebilir RAM) - DOS

b) RAM açısından daha fazlasını yapabilen, ancak oyun vb. şeyler söz konusu olduğunda sınırlı olan ve dünyadaki en kararlı şey olmayan bir işletim sistemi uzantısı (Windows) (neyse ki bu daha sonra değişti, ama ben Burada 90'ların başlarından bahsediyorum)

c) Çoğu yazılım hala DOS'tu ve özel yazılımlar için sık sık önyükleme diskleri oluşturmak zorunda kaldık, çünkü bazı programların sevdiği, diğerlerinin nefret ettiği bu EMM386.exe vardı (özellikle oyuncular - ve ben o sırada bir AVID oyuncusuydum - ne olduğunu biliyorum buradan bahsediyorum)

d) MCGA 320x200x8 bit ile sınırlıydık (tamam, özel numaralarla biraz daha fazlası vardı, 360x480x8 mümkündü, ancak yalnızca çalışma zamanı kitaplığı desteği olmadan), diğer her şey dağınık ve korkunçtu ("VESA" - lol)

e) Ancak donanım açısından, birkaç megabayt RAM ve 1024x768'e kadar destekli VGA kartlara sahip 32 bit makinelerimiz vardı.

Bu kötü durumun nedeni nedir?

Intel'den basit bir tasarım kararı. Makine talimat seviyesi (ikili seviye DEĞİL!) Zaten ölmekte olan bir şeye uyumluluk, 8085 olduğunu düşünüyorum. Görünüşte alakasız olan diğer problemler (grafik modları, vb.) Teknik nedenlerle ve çok dar x86 platformunun getirdiği fikirli mimari.

Bugün durum farklı, ancak herhangi bir derleyici geliştiricisine veya x86 için derleyici arka uçları oluşturan kişilere sorun. Genel amaçlı kayıtların inanılmaz derecede az olması, korkunç bir performans katilinden başka bir şey değildir.