Meclis hala ilgili mi? [kapalı]


18

Projelerin kodlanması ve / veya yönetilmesi söz konusu olduğunda, montaj dili ile üst düzey diller arasında büyük farklılıklar var mı? Açıkçası, montaj dilinde belirli bir işlemi gerçekleştirmek için diğer birçok dilde olduğundan daha fazla ifade gerekir, ancak bir projenin montaj dilini (özellikle x86 / x64 montaj dili) hedefleme temelinde nasıl çalışması gerektiğini (veya nasıl olması gerektiğini) etkileyen farklılıklar vardır. ?

Montaj dili ve diğer diller arasında farklılıklar olduğu sürece, bunların en azından bir kısmının diğer diller için avantajlar olduğunu tahmin etmek makul görünmektedir. Herkes montaj dilinin belirli dezavantajlarına ve bu dezavantajları azaltmanın yollarına dikkat çekebilir mi?

Bunun spesifik bir örneği personel mevcudiyeti olabilir. Herhangi biri deneyimli derleme dili programcılarını bulmakta zorluk çekti ve eğer öyleyse, bu sorunu azaltmak için hangi adımlar atılabilir?


Neden herkes bugün sadece montaj dilinde eksiksiz bir proje yazsın ki? Yoksa karışık dilde bir ortam mı soruyorsunuz, günümüzde montaj genellikle bu şekilde mi kullanılıyor?
Martin Vilcans

6
non-[PC|web|enterprise]Assembly'nin baskın veya çok popüler olduğu programlama alanları olduğunu unutmayın . Mikrodenetleyiciler, endüstriyel otomasyon veya robotikten bahsediyorum. Elbette, bu alanlarda da üst düzey diller var, ama Meclis'i çok görüyorsunuz.
Mchl

1
@Mchl: Bu projeler C (hatta C ++) ve muhtemelen derlemede yapılmıyor mu? Sadece montajı kullanmanın çok nadir olduğunu tahmin ederdim.
Martin Vilcans

1
Aslında endüstriyel otomasyonda, bu alanın dışında var olmayan bir çok dille tanışabilirsiniz. Bunun bir kısmı donanımdaki farklılıklardan geliyor (alıştığımız von Neumann mimarisinin aksine Harvard mimarisi). ve bu kontrolörlerin anahtarlar ve rölelerle çalışmaya alışkın olan elektrikçiler için erişilebilir hale getirilmesi tarihinden itibaren. LD ( en.wikipedia.org/wiki/Ladder_logic ) işte böyle ortaya çıkıyor, aslında montajın grafiksel bir yorumu. Otomasyonda kullanılan bazı diller için bağlantılı makaleye bakın.
Mchl

2
Desteklediğim küçük bir yükleyicim var şimdi montajda. Montajda (Windows API ile) başka bir şey gibi yazmak kolaydı, neden olmasın? Ayrıca mecliste yazılmış bir kredi kartı swiper arayüzü var. Üst düzey dilde başladı, ancak akan tüm bitlerin daha iyi kontrolünü sağlamak için mecliste yeniden yazdığım çok fazla zorluk çekti ...
Brian Knoblauch

Yanıtlar:


25

Evet - ama sık değil.

Bir anlamda, montaj gerçekten sadece makine dili için bir vekildir, bu yüzden elbette montajda daha üst düzey bir dille yapabileceğiniz her şeyi yapabilirsiniz.

Tersi her zaman böyle değildir. Örneğin, birkaç yıl önce, sadece çekirdek modundan kullanılabilen grafik durumlarını değiştirmek için bazı korkak opcodesleri olan bir ARM CPU üzerinde çalıştım. Daha yüksek bir dilde doğrudan bir eşdeğeri yoktur ve eminim Linux çekirdek sürücüsündeki bu durumları değiştirme işlevinin bazı montajları da içeriyordu.

80'lerde ve 90'ların ortalarında bulunan mikroişlemcilerde, gerçekten hızlı bir şekilde çalıştırmanız gereken bir kodunuz varsa, genellikle montajda yazarsınız, çünkü yetenekli bir insan çoğu C'den daha optimize edilmiş montaj yazabilir derleyiciler üretebilir. Bazı erken Mac programları tamamen montajda yazılmıştır ve çağ için şaşırtıcı derecede hızlıydı. Tüm programı montajda yazmadan bile, kesinlikle gömülü montaj yoluyla C'deki iç halkaları optimize etme payımı yaptım.

Ancak 1990'ların ortalarında işler değişmeye başladı. CPU'lar boru hattı ve dal tahmini gibi özellikler eklemeye başladı, bu nedenle en etkili talimat sırası bir insan için her zaman açık değildi. Daha da kötüsü, en verimli sıralama aynı ailedeki CPU'lar arasında değişiyordu; örneğin, PowerPC derleyicileri genellikle G3, G4 ve G5 serisi için hedef anahtarlar sundu. Aynı nesne kodu hepsinde çalışır, ancak bu serilerden birinde daha verimli çalışır.

O zamandan beri, özellikle x86, PowerPC ve SPARC gibi mimari açıdan daha karmaşık CPU'larda, talimat sıralaması giderek daha karmaşık hale geldi. (ARM'nin bu şekilde oldukça basit olduğuna inanıyorum.) Eklenen büyük bir faktör kod boyutudur - daha fazla CPU döngüsü kullanan ancak CPU önbelleğinde kalabilen kod genellikle daha az CPU döngüsü kullanan koddan çok daha hızlı çalışır, ancak yavaş bellek getirmelerini tetikler . Büyük modern derleyiciler, bu CPU'larda kodları optimize etmek için bir insanın makul bir şekilde yapabileceğinden çok daha iyi bir iş yapabilir.

En az 15 yıl içinde meclis yazmak için iyi bir neden bulamadım. Bence 2011'de montajın ana kullanım alanları:

  • Hata ayıklama sırasında sökme dökümlerini okumak için, bazen bugün bile yaparım.
  • Bu korkak grafik modu gibi standart olmayan CPU özellikleriyle başa çıkmak.
  • Derleyici yazımı - üst düzey dilleri çevirmek için insan tarafından okunabilir bir ara biçim sağlar.

1
Ve neden # 3 bile LLVM, nanojit veya libjit gibi yüksek seviyeli bir derleyici çerçevesini veya JVM, CIL, Parrot, Rubinius veya Neko bayt kodu gibi bir şeyi hedefleyen derleyicilerle kaybolmaya başlıyor.
Jörg W Mittag

Grafik / video çalışmalarında biraz SSE2 yapmak hala gereklidir. Her ne kadar önce TBB / OMP ile kıyaslandığında!
Martin Beckett

@Martin: OMP, SSE2 ile dikeydir. (iyi veri düzeni uygulamaları varsayarak)
rwong

@rwong - ama süreç hala 1, çok yavaş olduğunu keşfet. 2, umut OMP / TBB yeterince hızlandırır. 3, SSE2 sürümünü yazma el çare! (acı sırasına göre)
Martin Beckett

2
Örnek olarak, Roller Coaster Tycoon'un tamamı montajda yazılmıştır (eksi c'de yapılan grafikler) ve zamanı geldiğinde inanılmaz derecede güçlüydü. Çoğu oyun, önceden tanımlanmış hareketler yapan birkaç 16x16 piksel sprite sahip olduğunda, bağımsız olarak, neredeyse sorunsuz bir şekilde hareket eden yüzlerce AI. Bunu her zaman montajın gücünü göstermek için kullanmayı seviyorum.
Ampt

19

"Küçük gömülü" bir mikrodenetleyici programlamayı deneyin - bir araba alarmı uzaktan kumandası, bir telefon pil monitörü, bir klavye denetleyicisi, fan hızı regülatörü, montaj kullanmadan.

Sınır hareket ederken, her zaman montaj için yer vardır.

15 yıl önce bisiklet kilometre sayacınız mekanikti, bir mikrodalga fırın analog devrede, TV uzaktan kumandası dijital devrede, Sat TV tuneri montajda yazıldı, telefon yazılımı C'de ve bilgisayar uygulaması Java'daydı.

7 yıl önce dijital devrede bir mikrodalga fırın vardı, montajda bir TV uzaktan kumandası, C'de TV set üstü kutusu yazıldı, telefonunuz Java tabanlı UI çalıştırdı.

Günümüzde, bir bisiklet kilometre sayacı dijital devrede, bir mikrodalga fırın montajda ürün yazılımı alır, bir TV uzaktan kumandası C'de ürün yazılımı içerir, TV set üstü kutusu Java çalışır, telefonunuz Linux'tur.

Önümüzdeki 7 yıla bahis oynamak ister misiniz? Daha fazla teknoloji daha gelişmiş kontrol dilleri aldıkça, montaj yeni bir temel kazanır ve onları almaya devam edecektir. Bugün mekanik veya analog devrelerle neler yapıldığına bakın. Birkaç yıl içinde orada meclis bahsi oynayabilirsiniz. Işık anahtarınız? Su musluğun mu? Su ısıtıcısı? Diş fırçanız?

Montajda programlanacak her zaman yeni bir cihaz, cihaz, oyuncak, ortak kullanım ömrü öğesi olacaktır.


3
iyi cevap. Kaç kişi, java veya geliştirme platformu olarak bir şey kullanıldığından, pillerin yarıya kadar sürdüğü bir şey için iki kat daha fazla ödeme yapmayı tercih eder? Groupon ve millet para kazanmak için bakmak diğer yolları, yeşil hareket tasarrufu kaynakları bakın. Montajı önlemek için neden tüm gömülü ürünlerin maliyetini artırın ve güç verin?
old_timer

1
Artık bilgisayarların Javascript (Chromebooks) çalıştırdığını eklemeyi unuttunuz. Bana göre ilerleme oldukça üzücü ama gerçek.
Hawken

2017 itibariyle, CIA Linux çalıştıran TV'nize giriyor, Java'nın araba anahtarlarında çalışan sinyalleri taklit edilebilir, herkes WIFI üzerinden yapay penis kamerasının C ++ ürün yazılımına bağlanabilir , bir diş fırçası 2013'te uzaktan istismar etti, ancak neyse ki hala kulaklık montaj çalışmasında gürültü önleme yaratıldı. Montaj her şeyin üst seviye kontrolörü olarak konumunu kaybetse de , bunun yerine alt bileşenlere geçiyor. Pencere panjurlarınızda zaten Java çalışıyor, ancak Java kontrol panosu montajla çalışan motor kontrolörü ile konuşuyor.
SF.

8

Bunu öncelikle kullandığım montajcılara dayandırıyorum - öncelikle MASM, NASM ve (daha az ölçüde) TASM. TASM'nin sonraki sürümlerinden bazıları, OO'yu desteklemek için bazı özelliklere sahipti (var mı?), Ancak onları çok fazla kullanmadım ve bunlar hakkında yorum yapmaya çalışmıyorum.

Birincisi: çoğu dil en azından biraz ağaç benzeri bir yapıya doğru ilerledi. Nesne yönelimli veya nesne tabanlı veya tam olarak ne olursa olsun, bir sistemin farklı bölümleri arasındaki ilişkiler hakkında biraz tanımlanmış. Ayrıca, bir sistemin bir parçasını kazara "karışmaya" ama diğer parçalara karşı "korumak" için biraz da vardır (eğer isterseniz koruma genellikle atlanabilir olsa da). Aksine, montaj dili nispeten "düzdür" - sistemin farklı bölümlerindeki kod (ve veriler) arasındaki ilişkilerin çoğu öncelikle belgelerle ve daha az ölçüde adlandırma kurallarıyla belirlenir.

Bunun sonucu, kodu ideal olandan çok daha sıkı bir şekilde birleştirmenin genellikle çok daha kolay olmasıdır. Başlangıç ​​için montaj dili seçimini başlatan gereksinimler (daha yüksek performans, daha küçük boyut, vb.) Çoğu zaman bunu da ödüllendirir - onaylanmış arayüzleri atlayarak ve genellikle daha küçük ve daha hızlı kodlar alabilirsiniz (genellikle çok fazla olmasa da) herhangi bir boyutta daha iyi). Dil ve araçların kendisi, yaptığınız işi (iyi veya kötü) kısıtlamak için çok daha az şey yapar, bu da sorunları önlemek için yöneticilere çok daha fazla yük getirir. Niteliksel olarak farklı olduğunu söyleyemem, ancak niceliksel olarak - yönetim, sorunları her iki şekilde önlemek için çalışmak zorundadır, ancak montaj dili söz konusu olduğunda, genellikle ne olup olmadığı hakkında daha fazla (ve genellikle daha sıkı) yönergeler alır ' t kabul edilebilir.

Bu durumun hafifletilmesi büyük ölçüde daha dikkatli yönergeler, daha deneyimli personelden daha fazla rehberlik ve daha spesifik, dikkatle uygulanan adlandırma sözleşmeleri meselesidir.

Çalışanlar bir problemdir. Ancak karşılaştığım sorunlar, öncelikle beklediğim gibi değil. Meclis dil koduna atlamaktan mutluluk duyan biraz "savaşçı jock" kişiliğine sahip çocuklar bulmak oldukça kolaydı. Çoğu, montaj dilini kullanma konusunda neredeyse tamamen deneyimsiz olmasına rağmen oldukça makul bir iş çıkardı.

Karşılaştığım zorluk, daha üst düzey personel bulmaktı - projeyi en azından bir miktar kontrol altında tutabilen ve kodu makul bir şekilde tutmak için gerekli yönergeleri sağlayacak (ve büyük ölçüde uygulayan) dillere tamamen alışmamış insanlar bakımı ve anlaşılırlığı.

Geriye dönüp baktığımda, bu açıdan en büyük sorunlardan bazılarına neden olmuş olabilirim. Benim tarafımda iki sorun kaynağı görebiliyorum. İlk olarak, düşündüğüm proje boyunca, bir süredir öncelikle daha üst düzey dillerde kod yazıyordum ve sadece montaj dilini kullanıyordumSon çare olarak. Bu nedenle, onu kullandığımda, performans kazanmak için mümkün olan her numara sadece adil bir oyun değil, beklenen bir şeydi. İkincisi, tamamen (veya öncelikle) montaj dilinde yazılmış bazı sistemlerde çalıştığımda, oldukça demir yumruklu proje yöneticileri altındaydı. O zamanlar nispeten gençtim ve açıkçası şeyleri yürütme şekline kızdım, bu yüzden tam tersini yapma eğilimindeydi. Geriye dönüp bakıldığında, yaptıkları gerçekten önemliydi ve sadece eski ve esnek olmadıkları için yapılmadı (ki, o zaman işleri nasıl gördüğümden eminim).


TASM ve Orca / M meclislerinin =)
Patrick Hughes

0

benim görüşüme göre bir geliştirme platformu olarak montaj günlük kullanım için uygun olmayabilir. bu görüşün temel nedeni, belirli bir işlemden çıkarılan hesaplama gücü miktarının, aynı verilen işlemi optimize etmek için gereken geliştirme süresinin miktarına genellikle zaman ve enerjiye değmemesidir (bunun için belirli bir terim vardır) .. adam / saat ya da bir şey gibi geliyor .. ne konuştuğumu biliyorsanız lütfen düzenleyin ..) yukarıda belirtilen bariz istisnalar vardır ama anaakım programlama gittiği sürece montaj sık kullanılmaz.

Bu, montaj, yazılım mühendisliği çalışmaları bağlamında programlamayı öğrenirken günümüzde hala geçerlidir, düşük seviyeli bir programlama dilinin neye benzediğini ve nasıl davrandığını öğretir. devam edip bugünlerde sınıfta kullandığımızın örneğini vereceğim. Stanley Warford (Pepperdine University USA) tarafından geliştirilen pep / 8 montajını ve burada verilen açık kaynaklı yazılımını kullanıyoruz . esas olarak cpu sanallaştırdığı ve çalışırken kodun üzerinden geçerken bellek içeriğini gösterdiği için kullanılır (öğrenme, hata ayıklama için oldukça yararlıdır).

Bu yüzden kullanım meclinize bağlı olarak bence uygun olabilir veya olmayabilir.


0

Bence "arabalarımız varsa kamyonlar hala alakalı mı?" Yani, montaj çok geniş bir uygulama yelpazesine sahiptir, ancak yüksek seviyeli programlama kadar geniş değildir, aynı şekilde arabalardan çok daha az kamyon vardır.

Algoritma optimizasyonu gibi alanlarda, görüntüleri / video işleme algoritmalarını iyileştirmek için doğrudan işlemci kayıtlarını kullanabilirsiniz.

Kriptografi gibi alanlarda da aynı şekilde kullanabilirsiniz.

Yeni mimarileri olan yeni işlemcilerde (Hücre mikroişlemcisinin ne zaman piyasaya sürüldüğünü hatırlayın), emin olun ki montajda önyükleme yükleyicileri vb. o).

Ve daha birçok örnek verilebilir, bu nedenle şirketinizin odaklandığı alana bağlıdır, eğer şirketiniz web / mobil geliştirmeye adanmışsa, buna muhtemelen ihtiyacınız yoktur, ancak şirketiniz mikrodenetleyicilere odaklanmışsa, gömülü sistemler, vb. ihtiyacınız olabilir.

Ve personel kullanılabilirliği, bağlıdır, sanırım Intel, Qualcomm, sorarsanız ... büyük bir montaj programcı listesi olması gerekir (işyerinizde "burada kaç kamyon şoförü var?" fazla düşünmeyin, ama başka yerlerde olmadığı anlamına gelmez. "Burada kaç araba sürücüsü var?" diye sorarsanız ne olur?


-3

Eğer gerçekten öğrenme montajı neden en iyi bahis olduğunu bilmek istiyorsanız. İşte nedenleri.

  1. Visual basic ve bu MS şeyler üzerinde programlama yapacaksanız montaj öğrenmeye gerek yok.
  2. Ciddi mikrodenetleyici aygıtları yapmak zorunda kalmazsanız montaj öğrenmeye gerek yoktur.
  3. Mikrodenetleyici üzerinde çalışırken emrinizde bir bellek mülkünüz varsa montaj öğrenmeye gerek yoktur (tanrı hafızayı mikrodenetleyici ile arayüzlerken size yardımcı olur)
  4. Mikrodenetleyici / mikroişlemci üzerinde tanrı gibi güç istemiyorsanız montaj öğrenmeye gerek yoktur.
  5. Montajı bilmemek buzdağını bilmek gibidir. Sizinkinin ve mikros yeteneğinizin% 25'ini ve asla bilemeyeceğiniz veya anlamayacağınız% 75'ini görebilirsiniz
  6. Tamamen Mecliste yazılmış Kolibris OS çalıştırmayı deneyin !!! 5 saniyeden daha kısa sürede başlatılan bir işletim sistemi gördünüz ve uygulama 1 saniye içinde fare tıklaması ile çalışmaya başlıyor.
  7. Modern derleyicilerin arka uçta genel amaçlı işlevleri vardır ve bu nedenle üretilen nihai kod Meclis ile karşılaştırıldığında ağır olacaktır.

Meclis, Avengers'ın Natasha Romanoff'u gibi. Bu bir çekicilik ve sihir. İlk olarak, seni ısıracak ama bana güven tadı asla unutmayacaksın.


1
Bu, önceki 5
cevapta
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.