Küçük Endian kazandı?

34

Yakın zamanda Büyük ve Küçük Endian savaşları hakkında bir şeyler öğretirken, bir öğrenci bunun çözülüp çözülmediğini sordu ve bilmediğimi fark ettim. Wikipedia makalesine bakıldığında , en popüler işletim sistemi / mimarlık çiftlerinin Little Endian kullandığı, ancak İnternet Protokolünün, paket başlıklarında sayısal değerleri aktarmak için Big Endian belirttiği anlaşılıyor. Bu mevcut durumun iyi bir özeti olur mu? Geçerli ağ kartları veya CPU'lar bayt sırasını değiştirmek için donanım desteği sağlıyor mu?

— Ellen Spertus
kaynak

25

Mesele kesildiği kadar kazanılmadığını savunuyorum. Temel olarak mobil pazarın tamamını oluşturan ARM iki kişiliktir (oh, sapkınlık!). Temel olarak x86'nın masaüstü pazarını "kazandığı" anlamına geldiğini düşünüyorum, küçük endian'ın kazandığını söyleyebilirim, ancak genel kod derinliği (sığ) ve bugünün uygulamalarının çoğunun soyutlanması (çok) verildiğini düşünüyorum. öyleydi. Computer Architecture dersimdeki endian neslinin gerçekten ortaya çıktığını hatırlamıyorum.

Pek çok geliştiricinin dolandırıcılık veya neden önemli olduğunun farkında bile olmadığından şüpheleniyorum. Çünkü engin için (ve demek istediğim engin onların günlük çalışma ortamına tamamen alakasız çoğunluğu). Bu, 30 yıl önce, herkesin bir ekrandaki metin dosyalarını süslü ve dramatik şekillerde manipüle etmenin aksine metale daha yakın bir şekilde kodlanmasıydı.

Genel şüphem, Nesne Yönelimli Programlamanın, iyi bir OO sistemindeki erişim ve soyutlama katmanları kullanıcıdan uygulama detaylarını gizlediğinden, endianlığı önemsemenin başlangıcı olduğu yönünde. Uygulama endianness içerdiğinden, insanlar buna açık bir faktör olmamasına alışmışlardır.

Zeyilname: zxcdw taşınabilirliğin kaygı verici olduğunu belirtti. Ancak, son 20 yıldaki intikamla neyin ortaya çıktı? Sanal makinelere dayalı programlama dilleri. Sanal makine öncülüğünün önemli olabileceğinden emin olun, ancak bir dil için temelde sorun olmadığı noktaya çok tutarlı bir şekilde yapılabilir. Sadece VM uygulayıcılarının taşınabilirlik açısından endianness hakkında endişelenmeleri bile gerekecekti.

— Dünya Mühendisi
kaynak

2

Örneğin, herhangi bir taşınabilir kod biçimi yazarken, önemli olan birçok önemli alan vardır . Infact, muhtemelen önemli olmadığı bir platforma bağlı olan taşınabilir olmayan kodları yazarken olur .

— zxcdw

Bizi doğrudan dışarıdaki sanal makine dillerinin ordusuna götüren @zxcdw ... Bunu düşünmemiştim.

— Dünya Mühendisi

Zeyilname tamamen doğru değildir (ve @zxcdw ile aynı fikirdeyim): endianness yalnızca çok baytlı tamsayılar ve bayt akışları arasında çeviri yaparken önemlidir ve dolaylı olarak yapıldığında ve platformlar arasında farklılık gösterdiğinde sorun olur. Çoğu modern dil (VM tabanlı olsun ya da olmasın), nadiren (opak bir veri türü olarak tamsayılarla) yapmanıza olanak sağlayarak taşınabilirliği elde eder ve daha sonra platformdan bağımsız olarak veya programcı tarafından açıkça seçilmiş bir ennisiteye sahiptir.

— Michael Borgwardt

2

@MichaelBorgwardt ARM arium.com/pdf/Endianness.pdf yapıyor

— Dünya Mühendisi

2

@zxcdw - assembler'da bile, her zaman endian sırasını bilmenize gerek yoktur. Örneğin sabitlerin her seferinde bir bayt belirtilmesi gerekmez. Durum, C'deki belirli bir seri hale getirme stiline biraz benziyor - x & 0xFFendian sırasına bakılmaksızın (baytlarınızın her birinin 8 biti olduğunu varsayarak) her zaman en az önemlisi baytı verir, çünkü ilgilendiğiniz bitleri değerleriyle belirlediğinizden, bellekteki göreceli konumları değil.

— Steve314

4

Endians, yalnızca ikili veri sistemlerini aktarırken gerçekten önemlidir.

İşlemci hızının (ve çok daha düşük depolama maliyetinin) artmasıyla, ikili veri arayüzleri daha nadir hale gelir, bu nedenle bunları uygulama katmanında farketmezsiniz. Bir metin aktarma formatı (XML / JSON) kullanıyorsunuz ya da çeviriyi sizin için halleden veri katmanı soyutlamasını kullanıyorsunuz (yani bir çeviri olduğunu bile farketmiyorsunuz).

Ancak, ikili veri katmanına kod yazarken, bunu fark edersiniz ve bu çok önemlidir. Örneğin VERITAS'ta çalıştığımda (şimdi Symantec), 25 farklı donanım platformu üzerine kurulmuş bir yazılım geliştiriyordum (sadece büyük / küçük endian türleri değil).

— Martin York
kaynak

Öğrencilerim ayrıca cep telefonları için geliştirdiler ve bulut bilişim kullandılar, böylece dünyanın PC ve Mac olmadığını biliyorlar.

— Ellen Spertus,

@Loki - Makinenin sonunu bilmeden seri hale getirmek ve seri hale getirmek mümkündür. Yalnızca / streams / dosyalarındaki verilerin bayt sıralamasını bilmeniz yeterlidir. Örneğin, (char) (x & 0xFF)C'de, yalnızca bir baytın 8 bit olduğunu varsayarsak, endian sorunlarından bağımsız olarak en az anlamlı bayt verir. Yazılımın çalışacağı makineleri bilmeden ikili dosya formatları tasarladım - temel olarak donanıma bakmadan dosya formatı için bir endian siparişi seçtim.

— Steve314

@ espertus: Elbette mümkün.

— Martin York

1

@ Steve314: Tabii ki yapabilirsin. "İkili Veri Katmanı" üzerinde çalışırken, verilerinizi serileştirmek istediğiniz herhangi bir düzeni tasarlayabilirsiniz ve taşınabilir olan düzenleri tasarlamak zor değildir. Her ne kadar kişisel olarak 60'lı yıllardan beri yapılmış ve iyi test edilmiş bir tekerleği yeniden icat etmeye zahmet etmem. H2nl ve ailesine bak . Bu işlev ailesi, platformunuz için en uygun şeyleri yapmanın taşınabilir (standart) bir yolunu sağlar.

— Martin York

4

Hayır, kimse kazanmadı. Tür olarak, baytlarımızı kaydetme sırasını, yazdığımız yönü ve kullandığımız sokağın kenarını standartlaştırmada başarısız olduk.

Sonuç olarak, bir ağ üzerinden veya bir dosyada iki farklı sistem arasında veri aktarmak isteyen herhangi biri, veri boşaltma kodunun makul bir başlangıç sürümünün ortamlarında doğru olma ihtimalinin ancak% 50'sinin şansına sahip olma şansına sahiptir. , müşterilerinde çalışma şansı% 50'dir.

Bununla başa çıkabilmek için "htonl" gibi isimlerle platforma özgü fonksiyonları araştırmanız gerekir, açıkçası 70'lere "arpa / inet.h" gibi isimlerle çıkıyor, çünkü durum o zamandan beri düzelmedi ve muhtemelen asla .

— Andrew Wagner
kaynak

10

standartlaştığımız ortaya çıktı - bir tamsayıyı temsil etmek için 4 bayt göndermek yerine, özel başlık metni, açılı ayraçlar, anahtar kelimeler ve bu 4 baytın bir ASCII temsili ile biçimlendirilmiş bir metin bloğu gönderiyoruz. Daha sonra alıcı son, tamsayı metnini almak için biçimlendirmeyi ayrıştırır ve tekrar 4 bayta dönüştürür. Buna ilerleme denir, :-) söylendi

— gbjbaanb

$ yetenek arama xml | wc -l 677

— Andrew Wagner

1

Hala bir fikir birliği yok:

Büyük bilgisayar sistemlerinin büyük çoğunluğu (sunucu / masaüstü / dizüstü bilgisayar) şu anda küçük endian mimarileri kullanıyor
Küçük bilgisayarların çoğunluğu (tabletler / telefonlar) son teknolojiden bağımsız bir işlemci mimarisi kullanır, ancak küçük endian düzenini kullanan işletim sistemleri kullanır

Yani donanım düzeyinde, LE çok daha yaygındır. Fakat:

Bilgisayarlar arası iletişimin çoğu, büyük-endian sırasını belirleyen protokoller kullanılarak gerçekleştirilir
Dünyadaki yazılımların çok büyük bir kısmı, veriler harici depolamaya yazıldığında varsayılan olarak büyük endian siparişine ayarlanan sanal bir platformda çalışmaktadır.

Her iki emir de öngörülebilir gelecek için bizimle birlikte olacak.

— Jules
kaynak

En büyük sistemlerin çoğunluğu (yani, "büyük demir") tipik olarak büyük-endian'dır. Yani, sözde mini veya anabilgisayar sistemleri (çoğumuz umursamadığımız arka uç işlemlerinin büyük bir kısmını oluşturur).

@jdv Ancak en büyük bilgisayar sistemleri çoğu küçük endian x86-64 makineleri ve orada performans sorunları var.

— user877329

Kimsenin, mimarlığın mimarlık tasarımcıları için kolaylıktan başka bir şey olmadığı konusunda güçlü bir iddiada bulunabileceğini sanmıyorum (ne yapmak isterlerse yapsın). O antik yorumu yaptığım zaman, büyük demir BE idi. Ancak bu BE olduğu için değil, mimari böyle olduğu için değil.