A komu to potrzebne - czyli zapotrzebowanie na programistów C++

Po co dwie osobne instrukcje, które robią dokładnie to samo?

Nie robią tego samego, opkody 31 i 33 się różnią kolejnością argumentów – xor [rax + rdi * 8 + 40], esi i xor esi, [rax + rdi * 8 + 40] kodowane są tak samo (OP 74 F8 28), z tą tylko różnicą, że to pierwsze używa opkodu 31, a drugie 33.

To, że xor eax, eax da się zapisać na dwa sposoby to tylko efekt uboczny tego, że kodowanie instrukcji na x86 jest dość regularne i można tak dobrać tak wartości ModR/M, by zapisać tą samą kombinację rejestrów przy użyciu różnych opkodów. Większość RISCów wypada pod tym względem tak samo, bo dzięki trójargumentowym instrukcjom każdą przemienną operację można zapisać na kilka sposobów.

Zrobienie responsywnej aplikacji okienkowej w C# załatwisz ucząc się trochę WPFa czy Windows Forms i async/await i gotowe. W C++ będziesz musiał nauczyć się C++a a potem wybrać odpowiednią bibliotekę, która i tak będzie wyglądać brzydko a potem nauczyć się obsługi wielowątkowości. Responsywną stronę internetową zrobisz w JS z CSSem po kilku tutorialach a w C++ nawet nie myślę co trzeba by było zrobić.

W skrócie, pisanie w C# nie wymaga nauki, a efekty to cud miód i palce lizać. Za to C++ musisz się nauczyć, wielowątkowości musisz się nauczyć, a potem to i tak brzydko wygląda. I te porównanie do JS+CSS, aż nie wiadomo gdzie tu zacząć..

Czyli redundancja rośnie i to jest między innymi to, o czym piszę. Po co dwie osobne instrukcje, które robią dokładnie to samo? Po co instrukcje liczące SHA?

Czyli twoim zdaniem posiadanie operacji dodawania i odejmowania to redundancja, skoro wszystko można załatwić odejmowaniem..? Te wszystkie rozszerzenia to tylko marketing, bo przecież to nic nie wniosło do możliwych do przeprowadzenia operacji! Trochę nie trafiasz w sens.

Nie robią tego samego

W przypadku "33 c0" i "31 c0" to jest to samo. Później następuje jednak optymalizacja i "c0" jest podmieniane na "cośtam", co może prowadzić do błędu. Z poziomu C++ takich różnic zwykle nie da się zobaczyć. Chodzi o to, że podczas przechodzenia przez kolejne fazy translacji występują "szczególne przypadki" i jeden kompilator zapisuje to jako "33 c0", a drugi jako "31 c0". Później następują optymalizacje, które w jednym kodzie działają prawidłowo, a w drugim "nagle przestają działać". Aby nie powtarzać tego samego dwa razy, następuje podmiana niektórych kodów operacji. Chodzi o takie sztuczki, jak w temacie [FASM] Skok między dwie instrukcje, o których zapomniałem podczas pierwszej próby rozwiązania problemu.

Większość RISCów wypada pod tym względem tak samo, bo dzięki trójargumentowym instrukcjom każdą przemienną operację można zapisać na kilka sposobów.

1. Nie ma rzeczy idealnych, problem jest dość ogólny i dotyczy wszelkich języków, procesorów i stosowanych narzędzi.
2. Jak już wcześniej wspomniałem, RISC to nie był dobry przykład. Pierwotnie słowo "reduced" mogło rzeczywiście oznaczać, że tych instrukcji było niewiele, ale pod wpływem różnych zjawisk (między innymi tych, które opisałem nieco wcześniej) to wszystko się rozrosło i mamy to, co mamy.
3. Opisywane przeze mnie przypadki stanowią niewielką część tego, z czym się stykam na co dzień. To są "patologiczne" sytuacje, które były, są i będą. Ważne jest to, aby za pomocą dostępnych narzędzi móc takie rzeczy zauważać i względnie łatwo poprawiać.
4. Niektórych zmian nie można wprowadzać ze względu na szeroko rozumianą "zgodność wsteczną", więc pewnych problemów nie można rozwiązać przez doinstalowanie jakiejś aktualizacji, bo to, co działało wczoraj, może przestać działać dziś lub jutro.
5. W przypadku problemów sprzętowych zmiana oprogramowania nie wystarcza (zwłaszcza, gdy mamy "na sztywno" zainstalowany kod działający w trybie "tylko do odczytu"). Na razie nie mamy "magicznego pudełka", do którego można włożyć układ scalony z wadą fabryczną i po chwili wyjąć sprawnie działający egzemplarz.

Czyli twoim zdaniem posiadanie operacji dodawania i odejmowania to redundancja, skoro wszystko można załatwić odejmowaniem..?

Nie. Po prostu uważam, że nie należy pakować zwykłego dodawania do tego samego worka, co SHA. Myślę, że za jakiś czas ten podział się wykrystalizuje, bo na razie wszyscy rozbudowują wszystko bez żadnych ograniczeń, co czasami sprawia problemy. Były procesory typu CISC i ludzie narzekali, że instrukcje są zbyt złożone. Powstały rozwiązania typu RISC i stało się dokładnie to samo. C++ sprawiał problemy, więc wymyślono Javę. Później Java przestała być taka szybka i prosta, powstały kolejne języki. I tak w kółko. Każdy mechanizm ma "stan nasycenia", gdy użycie tego samego narzędzia do osiągnięcia kolejnego celu już się nie sprawdza i powstaje coś nowego. Wtedy następuje "wytrącenie się" z tego wielkiego "kombajnu" elementów potrzebnych do realizacji zaplanowanego projektu. Zgaduję, że jak powstanie zbyt wiele tych "nowych, wspaniałych narzędzi do zrobienia X, bo obecne są już niewygodne", to zacznie się tworzyć "kod bazowy", który pozwoli na ogarnięcie tego całego "chaosu". Kiedyś nie było podziału na back-end i front-end, teraz jest. Może za jakiś czas powstanie podział na poszczególne etapy przetwarzania kodu, który będzie dość podobny we wszystkich przypadkach, aby to sensownie uogólniać. Z maszyną Turinga lub czymś w tym rodzaju na samym dole i z językami naturalnymi na górze.

@up, Bielan
No właśnie, słodzicie Javie i C# ale czy faktycznie jest to tak proste? Za mną (niedługo) już rok nauki w c++ i faktycznie nie wydaje mi się, żebym za wiele umiał jeśli chodzi o tworzenie jakiś porządnych aplikacji okienkowych / gier , czy więc java i c# są takie wspaniałe i proste, a tylko c++ toporny?

słodzicie Javie i C#

"Święte wojny" były, są i będą. Zawsze znajdziesz takich, którzy powiedzą, że język X jest najlepszy. W tym przypadku fakt, że rynek wymaga tych języków, jest jednak dość mocnym argumentem. Chyba, że programowanie traktujesz jako hobby, ale to już inna sytuacja.

czy faktycznie jest to tak proste

Zależy, co chcesz zrobić. Napisanie systemu operacyjnego w Javie, który będzie działał pod x86 nie jest proste, co pokazują chociażby próby na [OSDev] Java For Starters.

Za mną (niedługo) już rok nauki w c++ i faktycznie nie wydaje mi się, żebym za wiele umiał

Jeśli chodzi o C++, to nie ma osób, które dobrze znają ten język. Są ci, którzy znają go w stopniu podstawowym oraz ci, którym wydaje się, że go znają dobrze. Później dowiadują się o fazach translacji, optymalizacjach, wyjątkach i nagle piękny obraz "łatwego pisania w C++" legnie w gruzach.

jeśli chodzi o tworzenie jakiś porządnych aplikacji okienkowych / gier , czy więc java i c# są takie wspaniałe i proste, a tylko c++ toporny?

Wszystko ma swoje wady i zalety. Używanie Garbage Collectora może zapobiec wyciekom pamięci, a z drugiej strony może sprawić, że pamięć nigdy nie zostanie zwolniona (da się napisać kod tak, aby prawidłowo działający GC nigdy nie zwalniał pamięci, ewentualnie może wystąpić szamotanie). Mamy nawet artykuł o przesiadce z C++ do Javy.

Bez przesady, to nie tak że tylko cpp jest i nic innego dobrego szybkiego. Rust jest szybki, może nawet szybszy. Trochę bardziej trzeba napracować się przy zarządzaniu pamięcią, no ale fajny system pakietów ma.

Rust jest szybki, może nawet szybszy.

Ta... bo nowy język będzie generował natywny kod lepszy niż 30 lat rozwoju kompilatorów C i C++ (o ile w ogóle Rust jest natywny). Z opisów na stronie gównej Rusta wynika, że 'nie można uzyskać segmentation fault'. Z tego wynika, że wszędzie jest kontrolowane wyjście poza zakres pamięci. Oznacza to, że nigdy to nie będzie szybsze niż C i C++, bo kontrola też kosztuje.

Poza tym... to nie szybkość finalnego produktu decyduje o wyborze języka jak to już zostało tu napisane, tylko minimalny czas dostarczenia produktu w danym języku.

C# i Java bez porównania są szybsze jeżeli chodzi o czas wytworzenia aplikacji w porównaniu do C++. Mając do dyspozycji przeciętnego dewelopera C++ i przeciętnego dewelopera C# to ten deweloper C# zrobi działający prototyp w kilka tygodni, a ten przeciętny deweloper C++ po kilku tygodniach będzie miał rozgrzebany plac zabaw i nie będzie wiedział w które miejsce łopatkę włożyć.

W przypadku "33 c0" i "31 c0" to jest to samo. Później następuje jednak optymalizacja i "c0" jest podmieniane na "cośtam", co może prowadzić do błędu.

Czyli optymalizator stwierdza, że użyje innych rejestrów i podmianę zrobi po wygenerowaniu kodu? Ok..