Dlaczego ludzie nie lubią low-levelu?

2

Dobry programista musi rozumieć przede wszystkim jak działa sprzęt.

Ja bym powiedział, że programista nie zrozumie jak działa sprzęt nie znając assemblera (przynajmniej w przybliżeniu). Więc znajomość assemblera jest warunkiem koniecznym ale nie wystarczającym do bycia dobrym programistą.

robienie cracków nie czyni nikogo automatycznie dobrym programistą niskopoziomowym

Jak ktoś jest dobrym Reversem Engineerem to niekoniecznie będzie dobrym programistą i vice versa. To po prostu dwie różne umiejętności.

0

@0x200x20 nie zgodzę się. Można rozumieć jak działa sprzęt bez znania assemblera (w sensie składni). Tak samo jak można rozumieć jak działa AES bez znania jego implementacji. Po prostu inny poziom abstrakcji, bardziej opisowy, ale dalej technicznie poprawny.

0
winerfresh napisał(a):

@0x200x20 nie zgodzę się. Można rozumieć jak działa sprzęt bez znania assemblera (w sensie składni). Tak samo jak można rozumieć jak działa AES bez znania jego implementacji. Po prostu inny poziom abstrakcji, bardziej opisowy, ale dalej technicznie poprawny.

Opis zasady działania komputera można przedstawić również tak:

  • Jest sobie monitor który sobie fajnie daje obraz i taka skrzynka z guzikiem

Ale z takim podejściem opisowym pseudo-technicznym jesteśmy daleko daleko od rozumienia tego co daje ASM czyli instrukcji w formie kroków.
Każda instrukcja do procesora jest pojedynczym "słowem" które do niego mówimy i nie znanie tych słów to tak naprawdę brak kompentecji z perspektywy programisty i nie umiejętność rozmowy z nim, to nie rozumienie architektury sprzętu komputerowego.

A co do tego czy ASM jest najprostszy?
Nie sądzę by osoba która nie dotknęła języka wyższego poziomu nauczyła się ASMa szybciej niż tego wysokopoziomowego, zbyt duża abstrakcja, na pewno łatwiej z wysokiego przejść do niskiego, niż zaczynać od low-levela

0

Jak nie znasz najważniejszych intrukcji assemblerowych dla danego procesora to o jakim rozmumieniu sprzętu ty mówisz. Chyba bardzo płytkim.

Pewnie tak, tylko ile tych najważniejszych instrukcji asemblerowych jest? Kilkanaście?

Nie muszę się uczyć wszystkich wariantów instrukcji mov, aby móc zrozumieć, jak są realizowane odczyty i zapisy z pamięci na poziomie sprzętowym. Wystarczy, że założę, że istnieje jakaś instrukcja do przesłania danych z pamięci do rejestru i w drugą stronę (na niektórych CPU będzie się nazywać tak samo - np. mov, a na niektórych mogą być do tego zupełnie różne np. ld, sd na MIPS - ale to są szczegóły mające małe znaczenie). Dogłębne zrozumienie tego na poziomie sprzętowym da mi zapewne znacznie większe możliwości pisania szybkich programów niż nauczenie się wszystkich pozostałych popularnych instrukcji, wraz ze wszystkimi wariantami mov i skoków warunkowych.

4

Czasami drobne subtelności w assemblerze potrafią mieć znaczenie. Jako przykład podam instrukcję xchg.
xchg reg, reg - zwykła instrukcja która swapuje wartość rejestrów
xchg reg, mem - generuje barierę pamięci, która wali bo wydajności. I nie ma tu żadnego prefixa lock, żeby się tego można była domyślić bez uprzedniej wiedzy.
Podałem realny przypadek - JIT do rubyego generował taki kod. Nie wiesz - nie będziesz w stanie zdebugować spadku wydajności.

0

A mnie przeglądając ostatnio oferty pracy tak natchnęło: jak w PL przyglądnąć się ogłoszeniom związanym z low-levelem (szeroko pojętym: C/C++/programowaniem systemowym unixów/embedded bare-metal) to jakby roboty mało raczej. Wklepałem to samo w szukajki niemieckie, angielskie, skandynawskie czy holenderskie i nagle zrobiło się tych ofert sporo (ciągle mniej niż w javie itd., ale w stosunku do Polski i tak dużo). Zresztą przecież regularnie do Szwecji zapylać będę, żeby gdb się bawić... ;) To jak to jest? Moja wypowiedź oczywiście bazuje wyłącznoe na osobistych przemyśleniach i doświadczeniach, niczym więcej, ale ciekaw jestem jak inni to postrzegają...

0
Krolik napisał(a):

Dobry programista musi rozumieć przede wszystkim jak działa sprzęt.
Znajomość assemblera nie jest równoważna ze znajomością sprzętu, tak jak umiejętność wymiany oleju w samochodzie nie jest równoważna ze znajomością procesów zachodzących w silniku.

Nie, assembler to najniższa abstrakcja. Tu nie ma nic więcej do rozumienia, sprzęt nie istnieje.
Kod teoretycznie może być nawet wykonywany przez miliony dzieci z liczydłami.

Bezpośredniego przełożenia na sprzęt nie ma już od dawna, szczególnie na x86 z jego 39 letnią historią. Kiedyś w ogóle nie było czegoś takiego jak dekoder instrukcji, instrukcje były zapisane bezpośrednio w układzie tranzystorów; teraz każdy cpu x86/amd64 ma skomplikowany dekoder który kompiluje kod w assemblerze do rzeczywistych instrukcji danego procesora. Działanie 386 na poziomie sprzętowym nie ma żadnego związku z działaniem skylake - stała jest tylko abstrakcja, doszło tylko trochę rozszerzeń. Jak za 15 lat wejdą procesory oparte np. na memrystorach rewolucja będzie totalna - abstrakcja zostanie ta sama.

Można sobie optymalizować pod konkretną architekturę, ale na tym kończy się użyteczność wiedzy sprzętowej.

2

Disclaimer: Nie czytałem wszystkich postów w dyskusji.

Dlaczego ludzie nie lubią low-levelu?

Bo ma mniejszy "cool factor" dla początkujących. Jako newbie wolisz (zazwyczaj) pochwalić się znajomym taką stroną http://damian.drygiel.com/ niż rzeczami o których większość ludzi nie ma pojęcia jak działa, albo nawet że istnieją. Dlaczego tyle newbie chce pisać gry? Bo pisanie gier ma wysoki "cool factor" wśród znajomych (wiem że gry to nie high-level, nie trzeba mnie uświadamiać). Mniej jest ludzi, którzy już od początku lubią wnikać "jak to działa" głebiej i głębiej.

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