Procesor za -10 złotych. :)

A -- to samoróbek.

Pozdrawiam, Piotr

Nie brodacze od 8051 którym 40 lat przeleciało za oknem. Wbrew pozorom w lotnictwie poziom pewności co czym i jak developujesz/testujesz wynika z procedur. Nie ze średniowiecznych poglądów Henia, co zatrzymał się w NortonCommanderze i Keilu. Te procedury, to często coś podlegające audytom.

Mówisz o kontroli wersji? A i owszem:

1) można zgrywać na pendrive 2) można zgrywać na NAS 3) można wysyłać mailem

Tylko że od kilkudziesięciu lat doskonale wiemy że to wszystko g... Natomiast jest ciągle duża grupa ludzi, którzy najzwyczajniej nie pojmują zalet (nie rozumiejąc ich) i wymyślają kwadratowe koła. Często to postawy czysto ideologiczne (myślmy zawsze tak robili/w poprzedniej firmie tak robiliśmy/ja jestem najmądrzejszy i tak wymyśliłem/not invented here).

I o ile w przypadku małego skansenu z kilkoma Heńkami to nie dziwi, to jak mówie że tutaj jest cała branża EDA która najzwyczajneij ignoruje zdobycze informatyki na poziomie inżynieri (o)programowania, a wyjątki są raczej glitchami. I nie, nie mają powodów, poza tradycją/ignorancją/"nikt tak nie robi". To problem czysto białkowy, EDA ma ogromną bezwładność na pojmowanie zmian organizacji pracy, zupełnie przeciwnie jak zwykli programiści. Mozliwe że to wynika z faktu że programistó w EDA jak na lekarstwo, choć robią głównie programowanie.

Piotr Wyderski wrote on 28.04.2021 17:10:

Te 20 lat to akurat z ich własnych materiałów porównujących fram i mram.

No i kto jest pryszczatym nastolatkiem - programisci, czy audytorzy? :-)

A potem mozna przeczytac taki tytul

Hm, moze i audytorzy sa pryszczatymi nastolatkami, skoro

Albo

Przy czym wydaje mi sie, ze czytalem z rok temu o podobnym bledzie w Boeingu ... albo mamy dwa, albo mi sie firmy pomylily.

A, pamiec mi jeszcze dziala

"Boeing 787s need to be turned off and on again every 51 days to prevent 'potentially catastrophic failure' "

Bo tam w srodku jest procesor z 1996 :-)

J.

Nikt, oni wszyscy mają garnitury i krawaty, więc są profesjonalni. Natomaist wszyscy uzywają w jakimś stopniu oprogramowania pisanego przez pryszczatych nastolatków.

To może być arument przeciwny archaicznym metodom dev jak i pokazujące co przesadna nowoczesność może popsuć.

Audytorzy nie ogarniają dużego kodu, będą się skupiać na metodyce pracy a nie na tym że przeżytnik ma niepodpięty reset. Kod nie jest pokryty testami w 100%, a jeśli nawet jest w znacznej częsci pokryty, to nie wiadomo kto testuje te testy itd... Budowanie zauwania kończącego się pieczątką jest skomplikowane i nie zawsze zgodne w tym co nam się wydaje o kontroli jakości.

Ogólnie pisanie dużego oprogramowania robi się korzystajac z różnych technik zwiększania jakosci. Ale przypadku EDA i HDL jest odwrotnie: duże firmy zatrzymały się na etapie kopiowania plików na dyskietkę.

Może zobrazuje to w taki sposób: znaczna część dostępnych symulatorów korzysta z czegoś co nazywa się "systemem biblitecznym".

Działa to tak że jakiś kod w HDL jest "kompilowany" i umieszczany w "bibliotece" i już można z niego korzystać.

Po kilku iteracjach możesz zauwazyć, że nikt nie kontroluje co w biblitece się znajduje, w szczególnosci mogą znajdować się tam skompilowane kawałki z plików źrodłowych które już nie istnieją lub zmieniły zawartość, napisane kawałki o tych samych nazwach, framgmenty od inncyh userów których możemy nie chcieć.

Dlaczego tak jest? Pewnie dlatego, że kilku brodatych Heńków lat temu 30 nie zuważyło, że istnieje make. I wymyślili kwadratrowe koło. Rozlazło się to po producentach symulatorów i obecnie jest standardem przemysłowym. Generującym niebotyczne ilości workaroundów. I Twój samolot też lata weryfikowany na tym g...

Nikt w EDA nie chce make. I zaznaczam: nie mają śladu argumentu. A wlaściwie mają: nie da się zrobić w obecnym systemie biblitecznym.

A ja zaryzykuje nastepujące: wolałbym wsiąść w samolot z lat 90 niż w cokowliek nowoczesnego, z powodu overengineering. Dotyczy to wszystkiego, od elektroniki do machaniki. Ale najbardzoej elektroniki co do której proces devu znam i czasami trzęsą mi się kolana na myśl ilu Heńków majstrowało przy samolocie w którym siedzę i jak skrajnie popsutych narzędzi, ale certyfikowanych, używali, jak wygląda proces dev przeciętnej firmy w EDA i dlaczego uże układy, które sterują tym samolotem, weryfikuje się randomizacją a nie formalnie...

rzutnik ;) Widać weekend blisko i destylaty w myśli.

Zdajesz sobie sprawę, że jeśli to nie jest tylko Twoja subiektywna ocena to za jakiś czas powiedzenie przypisywane Einsteinowi o kijach i kamieniach w 3 Wojnie Światowej jest całkiem realną wizją i to niekoniecznie jakiegoś konfliktu zbrojnego ale przyszłych narzędzi życia codziennego?

Moje subiektywne i g... warte oceny nie mają *aż* takiego wpływu na losy świata.

Ale tu nie o wpływ przecież chodzi ale na zwrócenie uwagi na pewien jednak obiektywnie występujący trend. Trudno zaklinać rzeczywistość, że nie występuje.

o garniakach nie mowie, ale ... jesli zatrudnieni od lat, to profesjonalni.

Akurat mialem na mysli to, ze oni uzywaja starego komputera. Moze nie 8051, ale starocia. I wymaga starych informatykow :-)

Zastapienie moze nie byc takie latwe, jesli to jakis odporniejszy procesor, mozna gdzies wyczytac ze "formally verified", i jeszcze sprawdzony przez 25 lat ... chcesz cos nowoczesnego wstawic?

Albo ... Boeing wynajal zewnetrzna firme, co to niby ma doswiadczenie, ale zatrudnia tanich nastolatkow :-)

Brodate Henki mogly sie akurat na make wychowac. Pozniejsze pokolenie nie zna ..

I tu sie zgadzamy.

J.

Paradygmat Szumowskiego się kłania....

Mamy całkiem sensowne procesory współczesne do cieżkich zadań, których programowanie jest "normalne" i nie ma problemu ze znalezieniem programistów.

Do 8051 cieżko znaleźc programistę który ogarnie go i jednoczesnie ma pojęcie o jakości, procedurach, współczesnych technikach pisania z naciskiem na jakość. To są biegunowo odległe grupy.

Ale do LEONa nie powinno być kłopotu. Niczym się to nie różni od innych CPU na których obecnie jedziemy w normalnym programowaniu. Za chwile wszędzie będzie wciskany RISC-V, któy też jest zupełnie normalny. Nawet w FPGA go będą wciskać.

Na końcu zawsze są hindusi.

Taka uwaga: nie abym tak uważał, ale mam wrażenie że na stare lata będę tak uważał: to nie programiści decydują o jakości, tylko procedury i testowanie. Z tego wynika pewna higiena pisania kodu, oczywiscie, ale to czy zatrudnisz studenta czy profesjonalistę powinno wpływać na czas i koszta, ale na jakość, raczej nie. Utopijnie: jakość software powinna być determinowana przez kontrolę jakości a czas pisania przez poziom programisty.

Brodate Zygumnty, programiści, tak.

Hanryki od rysowania bramek, nie. Oni dalej je rysują, tylko w kodzie. Niewiele się zmieniło. Mają bardzo podobne narzędzia, tylko robiąto odrobinę inaczej (i nadal jest pełno Heńków którzy rysują sieci bramek z translacją do kodu)

Warto wspomnieć że SystemVerilog wprowadził jakiś czas temu programowanie obiektowe. I nie w celu syntezy, tylko testowania. Była niewyobrażalna gównoburza że ktoś Heńkom bezczelnie kazał nagle nauczyć się czegoś nowego. W efekcie powstało pełno narzędzi które chowają to obiektowe coś pod interfejsem graficznym gdzie można sobie wyklikać to i owo. I oczywiscie można sobie źle wyklikac, trudno klikac jak się nie ma pojęcia, w co sie klika. Efekt: no i co z tego że powstało zaawansowane narzędzie, skoro sprowadzono je do gryzaka dla niemowlaka.

Odwrotnie, współczesne pokolenie zna doskonale. Nawet jeśli nie make, to koncepcje za nim stojące. Korzysta z tego bardzo dużo języków. Tylko że to mowa o programistach. W EDA też jest programowanie, ale robione przez elektroników. I tutaj jest podstawowy problem. Elektronicy od rysowania bramek nagle muszą ogarniać problemy typowego programisty. I ogarniają na swój sposób.

Ale rozumiesz, że może też chodzić o formalne dowodzenie poprawności algorytmów.

I przeniesienie kilku milionów linii kodu z 2 czy tam 9 słabszych ale zestandaryzowanych komputerów na jeden super-duper ale bliżej nikomu nie znany może oznaczać grube miesiące jeśli nie lata i dziesiątki albo setki milionów w brzęczącej monecie, które trzeba poświęcić na retesty, certyfikacje, etc.

I z całym szacunkiem, ale programiści Ci tego nie zrobią bo się po prostu na tym nie znają.

A już czuć gorący oddech konkurencji na karku ;-)

Piotrek

Ale czy sa odporne na szeroki zakres temperatur, na promieniowanie kosmiczne itp?

I czy mozna w jakis sposob zbadac, czy nie maja bledow ?

Ale tu pewnie tez jest normalne - w C. Ewentualnie w Ada. Plus system operacyjny i biblioteki, a te i tak specyficzne.

8051 ma 8KB pamieci programu, no - 64 czasem, to jeden programista ogarnia :-)

IMO - programisci tez. Ale czy zatrudniasz programistow w roznym wieku, czy starsi jakos tam dbaja o "ład korporacyjny" w pisaniu programow, uczą mlodszych jak to sie robi, czy zatrudniasz z doskoku i to najtanszych ...

Aczkolwiek ... w PLD byl problem, ze przerzutnik latch na bramkach wychodzi a na rownaniach nie bardo ... Verilog/VHDL ... mam nadzieje, ze nie ma juz tego problemu.

Hm. Make owszem, sie przydaje, ale wymaga narzedzi "command line". A tu piekne programy zwykly to robic z menu.

Aczkolwiek niedawno widzialem ladne oprogramowanie, mozna sobie narysowac maszyne w CAD, podlaczyc wirtualne PLC, zaprogramowac to PLC, i zobaczyc jak bedzie dzialalo. Tylko cos mi sie widzi, ze make tam nie ma :-)

J.

I dlaczego LEON czy RISC-V miały być do tego gorszy niż Heńkowy 8051?

Nie przesadzajmy. Tych milionów lini kodu *NIKT* nie zweryfikował formalnie. Tam jest weryfikacja przez zasiedzenie. Jesteśmy w czarnej d... jeśli chodzi o weryfikację dużych systemów, niby rozwijamy się, tworzymy nowe metodyki, ale powiedz to Heńkowi, co gita na oczy nie widział.

Zależy jacy programiści. Po tych w lotnictwie, spodziewam się że potrafią formalnie dowodzić przynajmniej kilkuset linijkowców dbających o bezpieczeństwo. Których pewnie nie ma, za to są wciśnięte właśnie kilkumilionowe potworki do sterowania autopilotem i sterowaniem klimą w jednym.

Tak.

Tak.

Na 8051 nie ma "C". jest jakaś proteza ogarniająca dziwaczne tryby adresowania i udajaca że z C ma coś wspólnego podobną składnią. Skrajnie utrudnia to testowanie kodu i praktycznie przekreśla przenośność.

Jak by taka zależności RAM<->ogarnianie była prawdziwa...

Na końcu jest kontrola jakości. Jesli jest zrobiona na odpiernicz się albo wcale, to programiści mają wypływ na jakość.

Ciekawostka: przykładowo syntezer Xilinxa nie obsługuje command line. Trzeba mu dostarczyć plik który interpretuje. Na dzień dobry wybija to zęby pisząc makefile.

I można syntezować "z menu" ale ma się to nijak to koncepcji "single click build" która jest uznawana za jeden z poważnych punktów kontroli tworzenia oprogramowania. Eleiminacji błedów białkowych.

Bo make nie służy do robienia prototypów. Przypuszczalnie Photoshp też nie ma wsparcia dla make.

Hm ...

OK, ale w Boeingu jest jakis lepszy procesor, to moze i C jest normalne.

A moze tez harwardzki, i kod z 51 sie przydaje :-)

Latwiej zapanowac nad malym programem.

Owszem, ale potem przychodzi deadline, kontrola mowi "tego nie mozemy wypuscic" a szef mowi "musimy" :-)

Poza tym jak programista sie skupi na kontroli, to moze tak napisac program, ze testy przejdzie ...

IMO - i tak jest niezle, ze przewiduje taki plik,

A potem masz zadanie "redakcja nie chce png tylko jpg. Jak przerobic setke zdjec z png na jpg" :-)

J.

W US jest ciekawiej, bo certyfikat dostajesz an konkretne urządzenie wykonane z konkretnych elementów. Potem się okazuje, że producent opornika wycofał go z produkcji i zastąpił czymś innym -- i kosztowną certyfikację zaczynasz od początku. Dlatego podstawą podstaw jest wylistowanie w BOM kilku alternatywnych modeli przed rozpoczęciem certyfikacji. Z zatwierdzonych alternatyw wolno Ci wybierać. :-)

Pozdrawiam, Piotr

Nie wiem. Wiem jednak, że jest tam za dużo procesorów kontrolujących lot. Taka jest tendencja we wszystkim.

Kod z '51 nigdzie się nie przydaje, poza Bytomiem i zegarem szkolnym. Może jeszcze jakiś modemach GSM, ale tam napisano go w średniowieczu i jest konsekrowany.

Nie wydaje mi się, 64kB to 64 tysiące mozliwości spieprzenia czegoś. Weryfikacja formalna kodu nie będzie zastanawiać się ile masz pamięci RAM, bardziej ile masz stanów osiągalnych bez synchronizacji itd.

Takie rzeczy nie mogą miec miejsca, jeśli mówimy o poważnym sofcie od którego zależy moje życie.

I dostaniesz dobry program, jesli testy są dobre.

Jeśli testy są złe, wiele z nich można przejśc return 4;

Od testów zależy najwiecej.

W sensie że dziadostwo jest tylko o gram mniej dzadowskie ;) Widzę że cieszysz się z małych rzeczy ;)

I tutaj wchodzi make, cały na biało, razem z kilkoma innymi toolami w konsoli. Kończą, zanim Heniek odpali photoshopa i znajdzie w menu funkcje konwersji. Ale Heniek będzie potem gadał wszystkim że on robi to

*prościej*, bo co łatwiejszego niż klikanie.

Innymi słowy prototyp sobie robisz w czymbądź. Produkcję ... nie, produkcję potrafimy optymalizować narzędziami które pozoronie wydają się być trudne w użyciu, jak syntezą z makefile, której nie da się zrobić, bo Heńki. Błędne koło.