MIPS neden shamt ve funct / opcode'u ayırdı?


15

MIPS tasarımcılarının neden kaymaya adanmış 5 bit içereceğini ve ayrı opcode ve fonksiyon bitlerine sahip olacağı konusunda kafam karıştı.

MIPS çok RISC olduğundan, sadece birkaç talimatta kaymanın yapılacağını varsayıyorum, bu yüzden bu 5 bit hemen yerleştirilebilecekleri zamanları boşa harcıyor gibi görünüyor. Op kodlarının ve fonksiyonunun R ve I tipi komutları ayırt etmek için ayrı olduğunu varsayıyorum, ancak bu op kodu 1 bit genişleterek yapılabilir. Bu R tipi talimatların her ikisiyle de 22 bit uzunluğunda olabilir. I tipi ve J tipi talimatlar hemen ve adreslerini korumak istiyorsa bu işe yaramaz, ancak her ikisi de gereksiz görünür.

Yanıtlar:


10

Burada birkaç farklı değiş tokuş var.

İlk olarak, talimatların sabit genişlikte (32 bit) olmasını istiyoruz. Bu, talimatların önbellek bloğu ve sayfa hizalaması olmasını sağlar; bu da önbellek ve sayfa varlığını ve izin kontrollerini basitleştirir.

İkinci olarak, çeşitli talimat alanlarının ( opcode/ source regs/ immediates) sabit genişlik ve sabit konum olmasını istiyoruz. Bu, kod çözme işlemlerini daha hızlı / daha az mantık yapar ve boru hattının erken aşamalarında gereklidir. ( destinationBoru hattının sonuna kadar kayıt gerekli değildir, bu yüzden farklı yerlerde Rve Italimatlarda olabilir.) functionALU'nun işlevini kontrol etmesi gerektiğinden alanın konumu ve genişliği biraz daha az önemlidir, ancak bu üçüncü boru hattı aşamasında, bu yüzden gerekirse çalışmak için biraz zamanınız var.

IJJ228228Italimatları derleyici / linker yazarları için de iyidir. (Yakın alanın sadece 12 bit olduğu SPARC'da, load-high20 bit hızlı bir şekilde özel bir talimat sınıfı eklemek zorunda kaldılar .)

26=64JRI

Ama bu Rtalimatlarla birlikte kıpır kıpır bir oda bırakıyor . 6 bitlik opcodeun yanı sıra, kayıt spesifikasyonu için sadece 15 ek bite ihtiyaç duyarlar, bu da uzatılmış opcode ve / veya vardiya miktarı için 11 bit bırakır.

functionAlanı, Rtalimat için genişletilmiş bir opcode olarak düşünmelisiniz . Sadece bir tane var Rtalimat işlemkodu ama 64 farklı vardır functionso Rtalimat gerçekleştirebilir.

Tamam. 60 farklı Italimatımız ve 64 farklı Rtalimatımız var, öyleyse hemen vardiya talimatlarını nereye koymalıyız?

Sadece daha az Italimat değil, I talimatlarla yapmak istediğimiz çok daha fazla şey var . Tüm şube talimatlarının talimat olması gerektiğini hatırlayın, Içünkü göreceli (acil) bir ofsete sahiptirler. Ayrıca tüm yükleme ve depolama talimatları IMIPS biçimindedir. Ve son olarak bir Italimat olmak için yük-üst-acil talimatına ihtiyacımız var . Sadece bu da değil, Rtalimatlarda hala 5 ek kullanılmayan bit var (bu mimaride bir vardiya-anında derhal için ihtiyacımız olan şey), bu da vardiya-derhal özel (garip) Rtalimatlara dönüşme için daha fazla teşvik veriyor. .

Bu kararların birçoğu bilimden daha fazla sanattır, ancak ayırt edilebilen temel bir mantık vardır. Anahtar hedeftir değil mümkün olduğu kadar küçük talimatların sayısını yapmak için, bir hale getirmektir yüksek performanslıboru hattı tek bir yongaya sığar (böylece MIPS ve Sun gibi küçük şirketler 1980'lerde IBM ve DEC ile rekabet edebilirler). (David Patterson tarafından icat edilen RISC adı biraz talihsiz. Sevimli olduğu için yakalandı, çünkü "indirgenmiş talimatlar" MIPS ve SPARC mimarilerinin gerçekte ne yapmaya çalıştığının doğru bir açıklaması değil.) getirme, sayfalama ve kod çözmeyi daha basit ve daha hızlı hale getirmek için sabit genişlikte (ve daha iyi I-önbellek davranışı elde edebilmeniz için nispeten küçük) talimatlar. Talimatın erken kodunun çözülmesi gereken kısımlarını (opcode, iki kaynak yazmacı ve işaret genişletilmiş hemen) sabit bir genişlikte ve sabit bir konumda olmalıdır. Hemen olabildiğince uzun olmasını istersiniz ve diğer tüm kısıtlamalar göz önüne alındığında, sığacak kadar farklı talimatlar istersiniz.


Bilgilendirici yanıtınız için, özellikle mimari tasarımcıların hedefleri ile ilgili bölümünüz için teşekkür ederiz. MIPS'yi MOS 6502 ile karşılaştırmak ilginç buluyorum, çünkü doğru anlarsam 6502'de hiç sahte olmadı (hala talimat formatlarını anlamaya çalışıyorum).
qwr

1
6502 birinci nesil bir mikroişlemci tasarımıydı (CISC öncesi), boru hattını öngörmesine rağmen, bir sonraki talimatı yüklerken aynı zamanda geri yazma kaydı yapabilmesi için. 6502, çoğu 8 bit mikroda olduğu gibi bayt opcodlarına sahipti. Dikkate alınacak bir diğer mimari, Berkeley RISC belgelerini okuyan ve MOS fabrikasını ziyaret eden ve "hey, bunu yapabiliriz" e karar veren bir dizi üst düzey elektronik mühendisleri tarafından tasarlanan ARM.
Takma ad

Acaba "aşağıdaki talimatı yürütmeyin, ancak bu talimat için kaynak işlenen olarak getirilen 32 bit kullanın" anlamına gelen bir sahte bit modeli olsaydı ne olurdu merak ediyorum? Alternatif olarak veya ek olarak, basit kesintisiz talimat çiftlerine adanmış adil bir opcode alanı yığınına sahip olmanın pratik olup olmadığını merak ediyorum - biraz Thumb gibi bir kavram, ancak 32 bit talimatlarla serbestçe dağıtılabilir ve doğrudan bir kelimenin ikinci talimatına atlamak?
supercat

5

MIPS I talimat formatlarını anlamak için, MIPS boru hattını anlamanız ve 1985 dolaylarında CPU uygulama teknolojisini de düşünmeniz gerekir. Şemaya bakarsanız (birini tanıyorsunuz), kayıt dosyası okumasının Kimlik aşaması, IF'den hemen sonra.

R tipi bir yönerge amacıyla, kimlik aşamasının aşağıdaki görevleri gerçekleştirmesi gerekir:

  1. Aslında o belirleyin olan bir R-tipi talimat.
  2. Öyleyse, kayıt dosyasına kayıtlardan değer yüklemesini söyleyin.

Bu tartışmanın amacı için düşünmeniz gereken ilk iş budur. Eğer kayıtlardan herhangi bir değere ihtiyacınız varsa bile çözmek için yapmanız gereken bir çok kod çözme işi varsa, bu kayıt okumalarına başlamadan önce gecikmeyi artırır. Ayrıca kimlik aşamasının karmaşıklığını da artırır. Tüm R tipi talimatlar için tek bir opcode ayırarak karmaşıklığı minimumda tutarsınız.

Beş biti sadece vites değiştirmeye ayırmanız biraz garip görünüyor. Birkaç olası açıklama düşünebilirim. Birincisi, yönlendirmeyi basitleştirmesidir (bu beş bit DAİMA doğrudan kayıt dosyasına beslenir, bu beş bit DAİMA kovan değiştiriciye beslenir, bu altı bit DAİMA hangi işlevi gerçekleştireceğini belirlemek için ALU'ya yönlendirilir).

Gelecekte birleştirilmiş sağa sola kaydırma ve ekleme talimatları eklemeyi düşünüyor olabilirler. Bu muhtemelen şu şekildedir:

$d = $s + ($t << shamt)

2s+1s

Bugün, muhtemelen daha karmaşık bir kod çözme aşamasına sahip olmak hakkında iki kez düşünmeyiz, çünkü özellikle kayıt dosyası erişimleri daha sonra tipik bir süperskalar CPU'nun boru hattında gerçekleşme eğilimindedir. Birçok modern CPU , L1 önbelleğine bir talimat eklendiğinde bazı kaba komut kod çözme de yapar . I-cache satırlarını ekstra bilgileri saklamak için birkaç bit daha geniş yaparsınız (Moore Yasası sayesinde, harcanacak çok sayıda transistör vardır), "uygun" komut kod çözme işlemini daha basit ve daha hızlı hale getirmek için.

Muhtemelen opcode alanını olabildiğince küçük tutmak istemelerinin bir nedeni, J-tipi talimatları haksız yere cezalandırmamasıdır. Muhtemelen bildiğiniz gibi, J tipi talimatlar sözde doğrudan adresleme kullanır. Evde oynayan herkesin yararına, kısaca açıklayacağım.

J tipi komutun adres alanı 26 bittir. Talimatlar her zaman 4 bayt hizalı olduğundan, en az önemli iki biti saklamanız gerekmez, bu da 28 bit adrese etkili bir şekilde sahip olduğunuz anlamına gelir. Ancak, MIPS I'deki adres alanı 32 bittir. Böylece atlama yerinin ilk dört biti program sayacından alınır.

Bu, PC konumunun en önemli dört bitinin farklı olduğu bir yere doğrudan atlayamayacağınız anlamına gelir. Bunun yerine bir çizik yazmacından daha pahalı bir üç komutlu atlama yapmanız gerekir:

lui $r,target >> 16
    ori $r,$r,target & 0xFFFF
    jr $r

Bugün çok kötü değil, ama 1985'te çok fazla saat döngüsü.

Adres alanından biraz çalmak, doğrudan atlamanın etkili aralığını daha da azaltacaktır. Bunun ödemek için çok yüksek bir fiyat olabileceğini görebilirsiniz.


daha sonra ARM'de görülen tipte "kombine shift-left-and-add talimatları"?
Damian Yerrick
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.