Czy assembler umiera?

0

Ponoć istnieją już mikrokontrolery które można natywnie programować w Node.js, czy to oznacza że assembler umiera?

0

W Krakowie i w Warszawie są firmy antywirusowe gdzie korzystają z assemblera. Zastosowanie assemblera jest różne, nie patrz na język poprzez zawężoną perspektywę, np. tylko mikrokontrolery

0

Nie umrze bo jest pierwotnym językiem, nie da się go usunąć, ani zabić.

Assembler jest po prostu interfacem processora do komunikacji z nim, assembler == opcode.

Inne języki mogą generować opcody, bo czemu nie, oby tylko błędów bezpieczeństwa nie popełniały, bo i tak generują jak to mówią natywny kod, czyli noda tam nie ma.
Zwykle i tak wszystkie libki tego noda w C naklepali do tej natywnej obslugi processora.

1

uC już od lat rzadko pisze się w asm. Głównie jest to C albo Bascom. Z drugiej strony istnieją uC które implementują nawet Jave, ale każde mają swoje zastosowanie. Do tej pory jeśli chodzi o uC to używa się do nowych konstrukcji uC Intela 8051 bo się sprawdza. Jakoś kiedyś wymyślony młotek, przez lata został nieco zmodyfikowany (gumy na rączce, na głowie wycięcie do wyciągania gwoździ, czy blokowanie trzonka w utworze), niemniej, to nadal młotek i nadal się sprawdza. Tak samo jest z innymi maszynami, jak np. uC, ba, tak samo z językami i kodem programów - to też jakiegoś rodzaju maszyny. Kupa kodu który kryje się w naszych komputerach i różnych rozwiązaniach jest pewnie starsze od Ciebie. Nie skupiaj się na języku, a na tym, żeby być dobrym projektantem i programistą. Język to rzecz wtórna.

0
Zimny Pomidor napisał(a):

Nie umrze bo jest pierwotnym językiem, nie da się go usunąć, ani zabić.

Assembler jest po prostu interfacem processora do komunikacji z nim, assembler == opcode.

Inne języki mogą generować opcody, bo czemu nie, oby tylko błędów bezpieczeństwa nie popełniały, bo i tak generują jak to mówią natywny kod, czyli noda tam nie ma.
Zwykle i tak wszystkie libki tego noda w C naklepali do tej natywnej obslugi processora.

Nie do końca to prawda. Asm to nie do końca same opcode ubrane w mnemoniki. Jeśli tak by było to nie istniały by różne dialekty assemblera dla tej samej rodziny procesorów. Dodatkowo istnieje ekstrakod, który implementuje różne lukry i ciekawe instrukcje, które nie mają fizycznych odzwierciedleń, tylko np. skupiają większą ilość i kombinacje opcode.

Co do procesorów - nie ważne na co jest tłumaczony dany język, i implementacja etc. ważne, że można pisać w danym języku. Równie dobrze można powiedzieć, że w x86 się już nie pisze, bo to i tak Intel wewnętrznie tłumaczy na jakieś RISCowe jądro.

0
Zimny Pomidor napisał(a):

Nie do końca to prawda. Asm to nie do końca same opcode ubrane w mnemoniki. Jeśli tak by było to nie istniały by różne dialekty assemblera dla tej samej rodziny procesorów. Dodatkowo istnieje ekstrakod, który implementuje różne lukry i ciekawe instrukcje, które nie mają fizycznych odzwierciedleń, tylko np. skupiają większą ilość i kombinacje opcode.

Co do procesorów - nie ważne na co jest tłumaczony dany język, i implementacja etc. ważne, że można pisać w danym języku. Równie dobrze można powiedzieć, że w x86 się już nie pisze, bo to i tak Intel wewnętrznie tłumaczy na jakieś RISCowe jądro.

Właśnie, że nie ma różnicy, to tylko sposób interpretacji.
Weź sobie dowolny skrawek kodu i zdisassembluj na dowolny dialekt przez co zobaczysz, że to tylko kosmetyczne różnice.

A to, że są jeszcze makra i inne pierdy itp., które nie mają odzwierciedlenia tylko są przebudowywane na kod.
I one są tylko dodatkiem skryptowym.

0

Asembler może się dobrze trzymać w świecie uC, gdzie krytyczne jest zużycie prądu (super długo działające urządzenia). Przeciętny kompilator C nie wygeneruje najbardziej oszczędnego kodu. Poza tym sterowniki i systemy operacyjne.

0

Jeśli chodzi o niskie zużycie prądu i zmniejszenie ilości cykli to robi się też soft dla uC w Tiny C oraz Small C. Co do systemów operacyjnych - w asm robi się mniejszą część w zasadzie (nie licze egzotyki jak system kolegi z forum). Niemniej zgodzę się z tym, że ASM nigdy nie umrze.

2
Nieposkromiony Młot napisał(a):

Ponoć istnieją już mikrokontrolery które można natywnie programować w Node.js, czy to oznacza że assembler umiera?

Assembler umrze na pewno - wraz z ostatnim programistą (co na pewno kiedyś nastąpi).
Na pewno zmniejszy się jego zapotrzebowanie wraz z odrywaniem się programistów od sprzętu (JVM, .NET, js, Python).
W takich językach wystarczy zejść jeden poziom niżej (np. do poziomu https://pl.wikipedia.org/wiki/Kod_bajtowy_Javy).
Z tym że jest jeszcze parę miejsc gdzie takie języki nie są używane.

Przykładowo - cały web jest opanowany przez PHP + JavaScript.
PHP: napisany w C - źródło
V8: napisane w C++ - źródło

Wiadomo (lub nie) że do programowania w C/C++ przydaje się znajomość assemblera.
W związku z tym:
a) do migania ledem nie potrzebne już ASM
b) do pisania języka migającego ledem przydaje się lub jest niezbędny ASM

0
vpiotr napisał(a):
Nieposkromiony Młot napisał(a):

Ponoć istnieją już mikrokontrolery które można natywnie programować w Node.js, czy to oznacza że assembler umiera?

Assembler umrze na pewno - wraz z ostatnim programistą (co na pewno kiedyś nastąpi).

co jeśli to programista Javy/C#?

1

Jak już wspomniano, assembler zginie dopiero wtedy gdy nie będzie już CPU, ale jego udział w rynku naturalnie maleje.Ostatnio dowiedziałem, że nawet firmware kodują w C++. Jednak assembler jest na pewno potrzebny wszędzie tam gdzie musimy pracować kodem maszynowym (np. reverse engineering, bezpieczeństwo). Poza tym, to że systemy operacyjne, firmware, kompilatory, itp programuje się w językach wysokiego poziomu nie znaczy wcale, że w rozwijaniu ich niepotrzebna jest znajomość assemblera, jest potrzebna.

Poza tym warto się nauczyć assemblera, żeby lepiej pisać w C/C++, bo wtedy autentycznie wiesz co piszesz, co się z tym wiąże i jak to działa. Znając assemblera znacznie lepiej rozumiesz działanie komputera, a myślę że wielu programistom bardzo tego brakuje, żeby ROZUMIEĆ jaką przewagę (i za jaką cenę) daje ci C nad assemblerem, C++ nad C i tak dalej z Javą, językami skryptowymi i innymi. Tak naprawdę nie wyobrażam sobie dobrego programisty, który nie ma choćby podstaw w tym zakresie, choćby po to żeby zrozumieć, że całe programowanie sprowadza się do operacji read() i write() w takim ogólnym sensie.

No i wreszcie zawsze będzie choćby mała grupka zapaleńców, którzy po prostu lubią assemblera, rajcuje ich ta wolność, którą zabiera im KAŻDY język programowania, który wprowadza abstrakcję. Będą fanaci demosceny, reverse-engineeringu, wydajności, bezpieczeństwa itp. Sam w zasadzie jestem jednym z nich. Nie wyobrażam sobie pisać dużych ilości kodu w assemblerze, bo zwyczajnie nie idzie się połapać, dlatego jeśl już generuję go automatycznie. Jednak lubię wolność ograniczoną tylko procesorem i systemem operacyjnym. I myślę, że nawet (a może zwłaszcza) jeśli programuję w Javie czy innym języku na VM takie doświadczenie jest bardzo przydatne.

1

Nie umiera, ale cały czas się rozwija, świadczy o tym ilość nowych zestawów instrukcji dodawanych do kolejnych generacji procesorów, ja się zatrzymałem gdzieś na SSE2 jeśli chodzi o x86 (ARM dla każdego programującego w x86 będzie na pewno również fascynującą odmianą), bo poziom skomplikowania i ilość instrukcji jest nie do przyswojenia bez dokumentacji obok. Według bloga:

https://fgiesen.wordpress.com/2016/08/25/how-many-x86-instructions-are-there/

w 2016 było 1503 instrukcji x86. Nie sposób tego wykuć na blachę, bo to już nie są proste skoki czy mov-y.

Jeśli chodzi o pisanie programów w assemblerze to dawno nie widziałem niczego ciekawego, lata świetności assembler dla x86 przeżywał w latach 90, co można zawdzięczać przyjaznej składni kompilatora MASM i dzięki czemu można powiedzieć, że kompilatory jak NASM czy FASM nigdy nie osiągnęły takiej popularności. Warto znać choćby podstawy assemblera, bo pozwala to zrozumieć niektóre aspekty programowania wysokopoziomowego, a w takich dziedzinach jak tu ludzie wyżej wspominali - czyli reversing jest po prostu wymagana jego znajomość.

1 użytkowników online, w tym zalogowanych: 0, gości: 1