> Softu, który nie da się przekompilować na nową architekturę, nie szkoda.
> Albo kiepski albo stary.

Ćwiczenie.
1. NVIDIA znana jest z tego, że sterowniki do kart daje w formie binarnego bloba, a
nie w postaci źródeł. Bo "IP protection", oczywiście. To oczywiście nie dotyczy tylko
tego producenta, to jest powszechna praktyka.
2. NVIDIA kupuje ARMa.
Pytanie do ćwiczenia: kiedy NVIDIA będzie rozdawać sterowniki do swoich kart dla
procesorów RISC-V?

No i teraz hipisi od RISC-V będą musieli jeszcze karty graficzne robić, żeby te
cudowne procesory kogokolwiek zainteresowały. I tyle było z "urywania rynku x86".

> > Z dużą dokładnością można powiedzieć, że nikt nie pisze nowego softu.
> Bo nie musi: języki wyższego poziomu zapewniły abstrakcję.

Ale ja kupuję programy już skompilowane.

> Ogólnie industry jest
> zaskoczone że "z niczego" w ciągu zaledwie kilku lat wyrosła
> konkurencja, wydawało by się z najdoskonalszym procesorom embedded.

Język C od dekad ma konkurencję w postaci doskonalszych języków, których nikt nie
używa. DOS miał konkurencję w innych systemach, których nikt nie używał. Itp. Względy
merytoryczne są drugorzędne. Albo i trzeciorzędne.

> desktopowce muszą uważać, RISC-V ma zacięcie na pokonanie ich w wersjach
> bardzo wielo rdzeniowych, do centrów obliczeniowych.

Ciekawe, co NVIDIA sądzi na ten temat. Zwłaszcza na ten temat bardzo wielo rdzeniowy.

> Jak będzie darmowy to RISC zrobi robotę. Postraszy.

I dobrze, bo presja jest dobra. Ale zobacz, jak Linux postraszył Windowsa, to masz
teraz Linuksa w Windowsie i... dalej Windows jest na każdym komputerze w biurze. A
Microsoft zarabia miliardy sprzedając przestrzeń w chmurze, w której wykorzystuje
darmowe Linuksy. Microsoft zarabia na darmowych Linuksach.
Myślę, że ze strachu NVIDIA też będzie zarabiać miliony dzięki darmowym RISC-V.

> Całośc rynku obecnie skupia się na produkcji narzędzi,

Nie szkodzi. CPU to nie jest jedyna rzecz, którą trzeba kupić. Zwykle kupuje się
więcej różnych rzeczy. I wtedy kupuje się u takiego producenta, który da ogólnie
dobrą cenę za ogólną lojalność. Np. jak kupujesz cały silikon u Texasa, to pewnie
lepiej (w pieniądzach) kupić u Texasa też CPU. I wtedy to Texas decyduje, jakie CPU
sprzeda. I jeszcze narzędzia dorzuci.
W projektach przemysłowych liczy się Total Cost of Ownership, a nie to, kto ma o
centa taniej jedną część, która nie pasuje do całej reszty.

> Jesli team od software jest zdrowy psychicznie to każe
> sie że całą ta migracja zakończy się poprzez zmianę kompilatora w
> makefile i puszczenia testów.

Nie. Bo ten jak najbardziej zdrowy psychicznie team wziął też od Texasa ich system
operacyjny (TI-RTOS). No i run-time, z "proprietarnymi" bibliotekami do peryferiów.
To, że Twoje kilka linijek kodu na wierzchu tego wszystkiego jest "przenośne", bo
napisałeś je sobie w "języku wysokiego poziomu", który "zapewnia abstrakcje", to jest
złudzenie optyczne.

> Przed chwilą nie był. Demonizujesz. Apple doskonale sobie poradziło z
> przejściem z x86 na ARM,

Apple to już ćwiczył, więc ma wprawę - wcześniej przechodzili z PowerPC na x86. Ale
wbrew temu co sądzisz o snobach oglądających pornole, akurat te prawdziwe snoby
kupują te komputery raczej po to:

https://new.steinberg.net/cubase/

albo po to:

https://www.apple.com/final-cut-pro/

itp., jest tego oczywiście więcej.
I o ile widzę oczami wyobraźni jak ci producenci portują swoje produkty na nowe
procki Apple'a, to entuzjazmu na portowanie na RISC-V się nie spodziewam. I nie, nie
chodzi tylko o "przekompilowanie i puszczenie testów". Te produkty mają za sobą całe
ekosystemy pluginów, od tzw. "firm trzecich". Pierdyliony pluginów. I weź teraz
przekonaj ich twórców, że mają zrobić osobne wersje na RISC-V, bo jacyś hipisi chcą
robić "rewolucję".

> Całośc RISC-V opiera się o dominacje w
> embedded

Dominację w embedded mają producenci silikonu, tacy jak przykładowy Texas. Bo to u
nich się robi zakupy a nie na GitHubie. I to od nich zależy, czy RISC-V zrobi
rewolucję, czy nie zrobi.

--
Maciej Sobczak * http://www.inspirel.com

do góry

On 05/01/2021 21:06, Maciej Sobczak wrote:
> Ćwiczenie.
> 1. NVIDIA znana jest z tego, że sterowniki do kart daje w formie binarnego bloba, a
nie w postaci źródeł. Bo "IP protection", oczywiście. To oczywiście nie dotyczy tylko
tego producenta, to jest powszechna praktyka.
> 2. NVIDIA kupuje ARMa.
> Pytanie do ćwiczenia: kiedy NVIDIA będzie rozdawać sterowniki do swoich kart dla
procesorów RISC-V?

To pytanie zadaj wobec R-PI który będzie miał złacze PCI-E i da się do
niego wsadzić kartę NVidi. Są sterowniki NVidi pod linuxa, na arm?
Ojejkujejku! Nie będzie cyberpunka na r-pi?

> No i teraz hipisi od RISC-V będą musieli jeszcze karty graficzne robić, żeby te
cudowne procesory kogokolwiek zainteresowały. I tyle było z "urywania rynku x86".

Dokładnie to samo masz z armem.

Rynek x86 to nie tylko gry. Dekoder x265 i blitter do pasjasa w gpu
załatwia 80% potrzeb biur. Brak GPU załatwia 100% potrzeb wirtualizacji
ukrytych giełd narkotyków, w torze.

>> Bo nie musi: języki wyższego poziomu zapewniły abstrakcję.
> Ale ja kupuję programy już skompilowane.

Bo taki masz system dystrybucji w zabawkowym systemie operacyjnym. Są
inne, np Android ma w połowie skompilowane. Jeszcze inne mają kod
źródłowy. W zasadzie mało kto ma skompilowane, licząc tak możliwie szeroko.

>> Ogólnie industry jest
>> zaskoczone że "z niczego" w ciągu zaledwie kilku lat wyrosła
>> konkurencja, wydawało by się z najdoskonalszym procesorom embedded.
> Język C od dekad ma konkurencję w postaci doskonalszych języków, których nikt nie
używa.

Przeginasz. Język C ma konkurencje w postaci C++ której używa sie
powszechnie, również w embedded (acz tam problemem jest raczej białko
niż technologia). Starasz się zniknąć zmianę na rynku, ale ona tam jest,
od dziesięcioleci. jest wiele języków używanych powszechnie w róznych
niszach.

> DOS miał konkurencję w innych systemach, których nikt nie używał.

Przeginasz. W USA Maki były znacznie bardziej powszechne niż piedołowaty
DOS, w wielu zastosowaniach. To że u nas ich nie było, było oczywiste. U
nas musiało być tanio, bo dewizy.

>> desktopowce muszą uważać, RISC-V ma zacięcie na pokonanie ich w wersjach
>> bardzo wielo rdzeniowych, do centrów obliczeniowych.
> Ciekawe, co NVIDIA sądzi na ten temat. Zwłaszcza na ten temat bardzo wielo
rdzeniowy.

Dokładnie co teraz: nie istnieje sens robienia klastra obliczeniowego na
GPU do zastosowań ogólnych ponieważ GPU mają bardzo wiele wad i nie są
"duża iloscią rdzeni", jak wielu sądzi. Czasem są przydatne, a czasem
komplenie nieużyteczne. Beda miały swoją niszę, mają ją z resztą już w
tej chwili.

>> Jak będzie darmowy to RISC zrobi robotę. Postraszy.
> I dobrze, bo presja jest dobra. Ale zobacz, jak Linux postraszył Windowsa

Nie przypominam sobie. Linux w '99 miał gry z akceleracją 3D?

>, to masz teraz Linuksa w Windowsie i... dalej Windows jest na każdym komputerze w
biurze.

Bo są gry 3D i pasjans.

> Myślę, że ze strachu NVIDIA też będzie zarabiać miliony dzięki darmowym RISC-V.

NVidia ma obecnie na głowie AMD który stuknął ją znowu w łeb. Jesli
kogoś się boją, to raczej konkurencji w 3D a nie konkurencji w
klastrach, które są raczej kwesią hałasu medialnego.

>> Całośc rynku obecnie skupia się na produkcji narzędzi,
> Nie szkodzi. CPU to nie jest jedyna rzecz, którą trzeba kupić.

Pozostałe sie nie zmieniają.

> Zwykle kupuje się więcej różnych rzeczy. I wtedy kupuje się u takiego producenta,
który da ogólnie dobrą cenę za ogólną lojalność.

Fajnie, ale ciezko znaleźc producenta który oferuje *wszystko*. Naprawdę
cieżko. Ten ma symualtor i cpu, tamten weryfikację formalną, ale ma inne
cpu, ten ma debugger do ARMów, ale nie ma symulatora itd itp.

Może to zabrzmi śmiesznie, ale wiele bardzo drogich projektów w EDA
powstaje poprzez sklejenie wielu niespójnych narzędzi gumą do żucia i
duża ilością perla.

> W projektach przemysłowych liczy się Total Cost of Ownership, a nie to, kto ma o
centa taniej jedną część, która nie pasuje do całej reszty.

O ile to Total jest naprawdę Total. Możesię okazać że to kilka luźnuch
narzędzi, jak to obecnie jest powszechne.

>> Jesli team od software jest zdrowy psychicznie to każe
>> sie że całą ta migracja zakończy się poprzez zmianę kompilatora w
>> makefile i puszczenia testów.
> Nie. Bo ten jak najbardziej zdrowy psychicznie team wziął też od Texasa ich system
operacyjny (TI-RTOS). No i run-time, z "proprietarnymi" bibliotekami do peryferiów.

Innymi słowy wziął vendor-lockin? Przecież pisałem, ze zdrowy psychicznie.

Dodam też, że komunikacja z takimi biblitekami musi być napisana przez
abstrakcję, którą można łatwo podmienić. Nie została napisana przez
abstrakcję? Mówiłam przeciez że zdrowych...

> To, że Twoje kilka linijek kodu na wierzchu tego wszystkiego jest "przenośne", bo
napisałeś je sobie w "języku wysokiego poziomu", który "zapewnia abstrakcje", to jest
złudzenie optyczne.

Albo praktyka na codzień. Zależy gdzie siedzisz.

>> Przed chwilą nie był. Demonizujesz. Apple doskonale sobie poradziło z
>> przejściem z x86 na ARM,
> Apple to już ćwiczył, więc ma wprawę - wcześniej przechodzili z PowerPC na x86. Ale
wbrew temu co sądzisz o snobach oglądających pornole

Tak wygląda rynek laptopów: snoby oglądające pornole. Szczególnie Apple,
ich kompytery migrują w kierunku kompletnie bezuzytecznych do
profesjonalnej pracy (złacza, klawiatura, znikanie fukncji itd itp).
Niech sobie wsadzają Z80 jesli chcą. Obawiam się że nikogo to nie
interesuje.

> https://www.apple.com/final-cut-pro/

A co kupują jak chcą odpalić ModelSima?

> itp., jest tego oczywiście więcej.

Wiadomo. Zapomniałeś dorzucić klasyka profesjonalizmu, czyli Autocada.
Który w porównaniu z wieloma naprawde profesjonalnymi apliakcjami
wygląda znacząco mniej imponująco.

> I o ile widzę oczami wyobraźni jak ci producenci portują swoje produkty na nowe
procki Apple'a, to entuzjazmu na portowanie na RISC-V się nie spodziewam.

I on nigdy nie nastapi. To był argument teoretyczny: twierdzenie że
zmiana architektury procesora jest problemem, jest idityczne. Nie jest.
Ba, doświadczasz tego na codzień: kompilacja kodu na x86 i x86-64, dwie
komplenie różne ISA, nie stanowi *żadnego* problemu, poza kiepskim
kodem. API OS jest takie samo.

Gdyby, teoretycznie, Apple przeszedł na RISC-V, API systemu było by
takie samo.

Wystarczy zmienić kompilator w makefile.

No i oczywiście zapominam o vendor-lockin, ale przecież nie rozmawiamy o
chorych apliakcjach.

> I nie, nie chodzi tylko o "przekompilowanie i puszczenie testów". Te produkty mają
za sobą całe ekosystemy pluginów, od tzw. "firm trzecich".

Vendor-lockin. Jeśli programiści mieli choć cień mózgu, to dawno się od
tego odgrodzili abstrakcją. "Firmy trzecie" same sie zgłoszą, jeśli są
coś warte, aby ich pluginy zastosować.

> Pierdyliony pluginów.

Skoro wybrali model pracy z okolic "niech kompilują te kolesie w
Indiach, ojej, właśnie umarli" to dlaczego uważasz że to jest sensowny
argument?

Sporo software ma pluginy pisane w pythone, tclu itd. I co teraz? Ten
argument świadczy o tym że łatwo przejść, twój że ciężko, prawda po środku.

> I weź teraz przekonaj ich twórców, że mają zrobić osobne wersje na RISC-V, bo jacyś
hipisi chcą robić "rewolucję".

Rynek ich przekona. Dokładnie tak, jak w tym momencie, kiedy to piszę,
rynek przekonuje aby te wszystkie pluginy do photoshopa przekompilować
na gwałt na ARMa, bo snoby znowu kupiły zabawki.

>> Całośc RISC-V opiera się o dominacje w
>> embedded
> Dominację w embedded mają producenci silikonu, tacy jak przykładowy Texas.

Myślę że wyjąłeś sobie 1 mały detal z embedded i nazywać go
najważniejszym, olewając inne detale.

> Bo to u nich się robi zakupy a nie na GitHubie.

No i widzisz, nie pojmujesz. Własnie zakupy robi się "na githubie" tylko
że ceny są w milionach dolarów i nazywa się to ipcores/weryfikacja.
Raczej nie dostaniesz cennika. To nie dla nas. I to jest embedded. To
czy krzem zrobią w SMC czy Samsungu, nikogo nie obchodzi, poza księgowymi.

do góry

W dniu 04.01.2021 o 20:35, heby pisze:

> Intel zrobił 8086 w taki sposób aby dało się *automatycznie* translować
> oprogramowanie z 8080. I dokładnie w taki sposób zapełniono biblitekę
> niczego. Czyli wsadzić nowy procesor i zapełnić go gównianymi programami
> wyjętymi wprost z 8-bit na gównianą platformę sprzętową 8/16-bit+segmenty.

No proszę, ktoś wypuszcza produkt wstecznie zgodny z dotychczasowymi
rzeczami, zły i niedobry...

> To wynik zbiegów okoliczności, kilku oszustw i może szczypty ignorancji.
> IBM jak robił pierwszego peceta nie miał pojęcia jaki system go będzie
> napędzał i zwrócili się do firmy która  miała doświadczenia w pisaniu
> BASICa na C64. Wyszło jak widać, z resztą nawet nie dali rady go
> napisać, tylko "znaleźli" w dziwnych i niewyjaśnionych okolicznościach.

Czyli potwierdzasz moją wersję - decyzja IBM była SPRZĘTOWA.

>
> Ciekawe że DOS praktycznie się nie rozwijał. Wersja 6.22 wygląda na
> lekko odpicowaną wersję DOS 1.0. Nic tam specjalnie przez te lata nie
> poprawiono, dodano itd itp. Ani śladu nowoczesnych technologii, kerneli
> preemptive, wielozadaniowości, wielodostępu, wirtualizacji. Niebywałe.
> Co oni tam robili przez te wszystkie lata? DoubleSpace?

Nic. W kwestii rozwoju Windows czy Office też długo nie robiono nic.
Dopiero konkurencja zmuszała do rozwoju. I nagle, kiedy Linux zaczął
działać konkurencyjnie stabilniej, Windows też się poprawił.

> Dokładnie taka sama powstała by gdyby inny procesor wsadzono w PC, w
> dobrej cenie i otwarto platformę. Można dyskutować czy taki był wtedy na
> rynku.

Więc poproszę o konkrety - co powinien był zrobić IBM albo ktoś inny,
aby uniknąć tej wielkiej porażki? Ale konkrety, nie "coś innego". Z
uwzględnieniem ówczesnych cen, potrzeb użytkowników i ich mentalności.

L.

do góry

On 06/01/2021 10:58, Luke wrote:
>> Intel zrobił 8086 w taki sposób aby dało się *automatycznie*
>> translować oprogramowanie z 8080. I dokładnie w taki sposób zapełniono
>> biblitekę niczego. Czyli wsadzić nowy procesor i zapełnić go
>> gównianymi programami wyjętymi wprost z 8-bit na gównianą platformę
>> sprzętową 8/16-bit+segmenty.
> No proszę, ktoś wypuszcza produkt wstecznie zgodny z dotychczasowymi
> rzeczami, zły i niedobry...

On nie był kompatybilny na poziomie binariów tylko na poziomie kodu w
asm trzymał jako taką możliwosc translacji.

To nie jest nic złego, ale jednocześnie cały procesor był obudowany tą
koncepcją. I to wygenerowało sytuację jaką mieliśmy w latach 90. Męcząc
się w ciansych, 16 bit segmentach, jak procesory 8-bit. To nie jest
"rewolucja" tylko "wstecznictwo".

> Czyli potwierdzasz moją wersję - decyzja IBM była SPRZĘTOWA.

To nie była decyzja. Wzieli co było i zrobili na kolanie byle co.
Decyzja to by była gdyby rozpatrywali różne koncepcja hardware, systemów
operacyjnych, rozszerzeń, planowali, badali.

Tymczasme wzieli dziadowski procesor, nie mają pojęcia o systemie
operacyjnym jak na nim będzie i wyciągając druty z CPU nazywając to
"magistralą", zmuszając ludzi do ręcznego przydzielania IO i przerwań.
Taki "komputer poskładany na kolanie przez studenta".

>> Niebywałe. Co oni tam robili przez te wszystkie lata? DoubleSpace?
> Nic.

Nic? Czekaj, czyli potwierdzasz tezę o zapaści?

> W kwestii rozwoju Windows czy Office też długo nie robiono nic.

Ależ robiono, jednak to dopiero *potem* było widać że cośtam dziubali z
Windowsem 1.0 który był wyraźnie gorszy nawet od GUI Amigi i Atari ST
mimo zupełnie innych zasobów gotówki. Team od MS-DOSa musiał być chyba
często na wakacjach, bo nic tam się nie działo.

>> Dokładnie taka sama powstała by gdyby inny procesor wsadzono w PC, w
>> dobrej cenie i otwarto platformę. Można dyskutować czy taki był wtedy
>> na rynku.
> Więc poproszę o konkrety - co powinien był zrobić IBM

Aby powiedzieć "zapoczątkował rewolucję" należało by porozmawiać o
udziale przypadku w tym całym biznesie.

Bo dla mnie rewolucje zapoczątkował 100x bardziej Apple, dostarczając
GUIowy system operacyjny, zamiast filesystemu z promptem godnego lat 70.

> aby uniknąć tej wielkiej porażki? Ale konkrety, nie "coś innego". Z
> uwzględnieniem ówczesnych cen, potrzeb użytkowników i ich mentalności.

Nie rozumiesz czego się czepiam.

Czepiam się piprzenia o wielkim zapoczątkowaniu rewolucji, itd itp. Nie,
nic z tego gównianego MS-DOSa i x86 nie zostało do dzisiaj gdziekolwiek,
poza żałosnym CMD windowsa, a cała ta rewolucja zapoczątkowana przez IBM
była powodem męk piekielnych przez całe lata 90 z których ledwo udało
się wybrnąć. Rewolucja nastapiła nie DZIEKI IBM tylko MIMO IBM i całej
reszcie wielkiej trójki.

do góry

> > Pytanie do ćwiczenia: kiedy NVIDIA będzie rozdawać sterowniki do swoich kart dla
procesorów RISC-V?
> To pytanie zadaj wobec R-PI który będzie miał złacze PCI-E i da się do
> niego wsadzić kartę NVidi. Są sterowniki NVidi pod linuxa, na arm?

Nie wiem, czy są. Ale wiem, że NVIDIA kupiła ARMa. Za 40B$. To było raptem 4 miesiące
temu, mogłeś przeoczyć w kwarantannie
(https://nvidianews.nvidia.com/news/nvidia-to-acquir
e-arm-for-40-billion-creating-worlds-premier-computi
ng-company-for-the-age-of-ai).
40B$ to jest wystarczająco dużo powodu, żeby spodziewać się sterowników do GPU dla
ARMa i jednocześnie nie spodziewać się ich do RISC-V.
Szansą dla RISC-V jest fakt, że niektórzy boją się dominacji NVIDII, bo nie traktują
jej jako neutralnego gracza. Ale tam za duży hajs jest na stole, żeby to się łatwo
zmieniło.

> > Nie. Bo ten jak najbardziej zdrowy psychicznie team wziął też od Texasa ich
system operacyjny (TI-RTOS). No i run-time, z "proprietarnymi" bibliotekami do
peryferiów.
> Innymi słowy wziął vendor-lockin? Przecież pisałem, ze zdrowy psychicznie.

Oczywiście. To są bardzo racjonalne decyzje. A firma, która lepi swój system z kilku
niepasujących do siebie vendor-lockinów, wcale nie jest przez to bardziej racjonalna.
Do tego potrzebuje więcej taśmy klejącej i ma gorszy support. Sam pisałeś o "bardzo
drogich projektach EDA" - one są drogie, bo? Wszystko darmowe i otwarte a projekty
bardzo drogie. Ciekawe, nie?

> Dodam też, że komunikacja z takimi biblitekami musi być napisana przez
> abstrakcję, którą można łatwo podmienić. Nie została napisana przez
> abstrakcję? Mówiłam przeciez że zdrowych...

Ależ oczywiście, że przez abstrakcję. Przecież TI-RTOS ma interfejs POSIX. To bardzo
dobra i sprawdzona abstrakcja (dlatego bardzo racjonalne było to wziąć). Szkoda
tylko, że inne RTOSy tej abstrakcji nie mają i nie da się przenieść takiego
"przenośnego" projektu na inne klocki, z innym RTOSem. Albo z innym stosem TCP. Itd.
Pacz pan, przenośny program, a nie da się przenieść. Same abstrakcje, wszystko
otwarte, a projekty dalej drogie. Ciekawe, nie?

> Tak wygląda rynek laptopów: snoby oglądające pornole. Szczególnie Apple,
> ich kompytery migrują w kierunku kompletnie bezuzytecznych do
> profesjonalnej pracy

Klikasz w złym miejscu. https://www.apple.com/pl/mac-pro/specs/
Jak dla mnie, ma wystarczająco dużo złącz.

> A co kupują jak chcą odpalić ModelSima?

Windowsa. I nie ma w tym żadnego konfliktu, bo to nie są ci sami profesjonaliści.

> Wystarczy zmienić kompilator w makefile.

Ale tego makefile też nie mam.
Problemem nie jest Twój czy mój kod. Problemem jest ten cudzy kod.

> Sporo software ma pluginy pisane w pythone, tclu itd. I co teraz?

Nie zrozumiałeś. Pluginy do obróbki dźwięku albo obrazu (albo video) nie są pisane w
Pythonie.

> > Dominację w embedded mają producenci silikonu, tacy jak przykładowy Texas.
> Myślę że wyjąłeś sobie 1 mały detal z embedded i nazywać go
> najważniejszym, olewając inne detale.

A jakie są inne detale? Bo rozmawiamy o zmianie CPU, tak?
Bo ja dorzucam jeszcze konieczność zmiany karty graficznej, która mi nie zadziała z
RISC-V, bo NVIDIA ma 40B$ powodów, żeby nie zadziałała. To już drugi detal.

--
Maciej Sobczak * http://www.inspirel.com

do góry

On 06/01/2021 17:02, Maciej Sobczak wrote:
> Nie wiem, czy są. Ale wiem, że NVIDIA kupiła ARMa.

I nagle zmieniła politykę czy tylko wyciska dalej co się da z licencji?

To że ktoś jest właścicielem nie zawsze powoduje jakiekolwiek widoczne
efekty działania. Co najwyżej AMD szybciej wembeduje RISC-V w swoje SoC.

> 40B$ to jest wystarczająco dużo powodu, żeby spodziewać się sterowników do GPU dla
ARMa i jednocześnie nie spodziewać się ich do RISC-V.

Ależ zobaczymy. Nie można też wykluczyć że nvidia ma interes w NIE
dawaniu rdzeni ARMa konkurencji.

>>> Nie. Bo ten jak najbardziej zdrowy psychicznie team wziął też od Texasa ich
system operacyjny (TI-RTOS). No i run-time, z "proprietarnymi" bibliotekami do
peryferiów.
>> Innymi słowy wziął vendor-lockin? Przecież pisałem, ze zdrowy psychicznie.
> Oczywiście. To są bardzo racjonalne decyzje. A firma, która lepi swój system z
kilku niepasujących do siebie vendor-lockinów>, wcale nie jest przez to bardziej
racjonalna. Do tego potrzebuje więcej taśmy klejącej i ma gorszy support. Sam pisałeś
o "bardzo drogich projektach EDA" - one są drogie, bo?

Bo potrzebują drogich specjalistów, bardzo drogich ipcores, bardzo
bardzo drogich narzędzi i skrajnie drogiego prototypowania.

> Wszystko darmowe

W EDA *NIC* nie jest darmowe. Nawej najgorsze g..no jest płatne
niebotyczne pieniądze, niewspółmierne do tego co potrafi.

> i otwarte a projekty bardzo drogie. Ciekawe, nie?

Nie, nic takiego nie istnieje jak "otwarte projekty darmowe" dotyczące
rynku embedded. Ja nie mówie o miganiu diodą z RISC. Ja mówie o grubych
graczach którzy projektują choćby dla lotnictwa czy medycyny. Tam nie ma
nic za friko. NIC.

>> Dodam też, że komunikacja z takimi biblitekami musi być napisana przez
>> abstrakcję, którą można łatwo podmienić. Nie została napisana przez
>> abstrakcję? Mówiłam przeciez że zdrowych...
> Ależ oczywiście, że przez abstrakcję. Przecież TI-RTOS ma interfejs POSIX. To
bardzo dobra

POSIX nie jest "bardzo dobrą abstrakcją" bo sam jest bardzo niedobry z
punktu widzenia embedded. To nie do tego.

> Szkoda tylko, że inne RTOSy tej abstrakcji nie mają

I nic dziwnego, używanie POSIXa w embedded jest komplenie bez sensu w
większosci zastosowań. FreeRTOS składa się z wątków, schedulera, jakiś
mutexów i tyle.

POSIXa też się zawija w abstrakcję w swoim kodzie. Chcesz mieć pełno
pthread_mutex czy może Foo::Mutex? I co jest większym vendor-lockin?

> i nie da się przenieść takiego "przenośnego" projektu na inne klocki

Bo jest bardzo źle napisany.

> , z innym RTOSem. Albo z innym stosem TCP.

Bo jest bardzo, bardzo źle napisany.

Abstrakcji nie szukasz w 3-rd party. Abstrakcję robisz u siebie. Własnie
po to aby od detali posix-nie posix nie uzależniać się w swoim kodzie,
poza adapterami do konkretnego OSu.

W razie zmiany OSu, zmieniasz adapter.

> Itd. Pacz pan, przenośny program, a nie da się przenieść.

Nie jest przenośny. Jest vendor-lockin. Tutaj vendorem jest POSIX,
przeciekajacy do kodu.

> Same abstrakcje

Jeśli w kodzie logiki swojego programu używasz bezpośrednio POSIXa to
nie jest to abstrakcja, tylko IMPLEMENTACJA pod konkretny OS. Chcesz
zmienic na inny OS nie będacy posixem, jesteś w d..pie.

>, wszystko otwarte, a projekty dalej drogie. Ciekawe, nie?

Nie, najzwyczajneij gówniany kod. Możliwe że z założenia, nie każdy musi
od razu być uniwersalny.

>> Tak wygląda rynek laptopów: snoby oglądające pornole. Szczególnie Apple,
>> ich kompytery migrują w kierunku kompletnie bezuzytecznych do
>> profesjonalnej pracy
> Klikasz w złym miejscu. https://www.apple.com/pl/mac-pro/specs/
> Jak dla mnie, ma wystarczająco dużo złącz.

I nagle przestają działać. Kojarzysz "mała aferę" z DisplayLink?
Rechotrałem godzinami czytają komentarze profesjonalistów od
dicking-around siedzącymi przed swoimi jabłkami płacząc że im się popsuło.

>> A co kupują jak chcą odpalić ModelSima?
> Windowsa.

Linuxa.

> I nie ma w tym żadnego konfliktu, bo to nie są ci sami profesjonaliści.

Aha. Ale jakoś słyszę ciągle że AutoCAD i Photoshop są powodem bycia
profesjonalnym.

>> Wystarczy zmienić kompilator w makefile.
> Ale tego makefile też nie mam.

No to zmienic kompialtor w *foo*.

> Problemem nie jest Twój czy mój kod. Problemem jest ten cudzy kod.

Jesteś od niego oddzielony abstrakcją. *ZAWSZE* oddziela się 3-rd party
abstrakcją. Można tego nie robić z róznej przyczyny, ale wtedy to jest
*dziadowski* kod.

Oczywiście nie muszę przecież przypomniać że oddzielanie się abstrakcją
od wszystkeigo pomaga róznież w testowaniu. No ale skoro kod dziadowski,
to może i testowania nie ma.

>> Sporo software ma pluginy pisane w pythone, tclu itd. I co teraz?
> Nie zrozumiałeś. Pluginy do obróbki dźwięku albo obrazu (albo video) nie są pisane
w Pythonie.

Nie są, a Mac przeskoczył na ARMa i reszta 3rd-party zrobiła to chwile
potem. Wniosek: to nijaki argument. Zmienili tylko kompilator w makefile
lub poprawili jakieś bugi i poszło.

>>> Dominację w embedded mają producenci silikonu, tacy jak przykładowy Texas.
>> Myślę że wyjąłeś sobie 1 mały detal z embedded i nazywać go
>> najważniejszym, olewając inne detale.
> A jakie są inne detale? Bo rozmawiamy o zmianie CPU, tak?

Rozmawiamy o embedded i zmienach embedded cpu. To nie jest *osobny*
scalak, tylko zazwyczaj coś wciśnięte do jakiegoś ASICa zrobionego jako
SoC, z masą skomplikowanych peryferiów w jednym kawałku krzemu.

> Bo ja dorzucam jeszcze konieczność zmiany karty graficznej, która mi nie zadziała z
RISC-V, bo NVIDIA ma 40B$ powodów, żeby nie zadziałała. To już drugi detal.

Ale karty nvidia nie są na rynku embedded, a na rynku desktopów nie ma
to znaczenia, pornole czy photoshop pójdą na czymkolwiek. To że 5%
desktopów ma karty nvidi jest naprawdę mało istotne nad zastanawianiem
się o przydatność RISC-V na desktopy.

do góry

środa, 6 stycznia 2021 o 14:28:23 UTC+1 heby napisał(a):
> On 06/01/2021 10:58, Luke wrote:
>
> Czepiam się piprzenia o wielkim zapoczątkowaniu rewolucji, itd itp. Nie,
> nic z tego gównianego MS-DOSa i x86 nie zostało do dzisiaj gdziekolwiek,
> poza żałosnym CMD windowsa, a cała ta rewolucja zapoczątkowana przez IBM
> była powodem męk piekielnych przez całe lata 90 z których ledwo udało
> się wybrnąć. Rewolucja nastapiła nie DZIEKI IBM tylko MIMO IBM i całej
> reszcie wielkiej trójki.

dos i wczesny windows to byla tragedia, ale win95 zmienil sytuacje bo to bylo cos
z tego roznego systemowego shitu do dzis sie nie udalo w pelni wyjsc...moim zdaniem
potrzebny jest lepszy wyzszy poziom systemu plikow tak by pliki mozna bylo
katalogowac na
'skrosne' sposob oraz potrzebny jest jakis system zapewniania integralnosci plikow
zwiazanych w paczkach (obie idee mojego pomyslu choc pewnie niektorzy inni tez o tym
mysla) potrzebne sa tez takie rzeczy jak np w menadzeze zadan widok ile dany proces
czyta bajtow z dysku lub z sieci z dokladnoscią do bajtu - bo user ma prawo do takich
informacji, potrzeban jest tez wzmozona stara dobra komponentowosc i moznosc wymiany
komponentu na inny wg uznania bo dzis to drastycznie slabo dziala

do góry

środa, 6 stycznia 2021 o 17:32:48 UTC+1 fir napisał(a):
> środa, 6 stycznia 2021 o 14:28:23 UTC+1 heby napisał(a):
> > On 06/01/2021 10:58, Luke wrote:
> >
> > Czepiam się piprzenia o wielkim zapoczątkowaniu rewolucji, itd itp. Nie,
> > nic z tego gównianego MS-DOSa i x86 nie zostało do dzisiaj gdziekolwiek,
> > poza żałosnym CMD windowsa, a cała ta rewolucja zapoczątkowana przez IBM
> > była powodem męk piekielnych przez całe lata 90 z których ledwo udało
> > się wybrnąć. Rewolucja nastapiła nie DZIEKI IBM tylko MIMO IBM i całej
> > reszcie wielkiej trójki.
> dos i wczesny windows to byla tragedia, ale win95 zmienil sytuacje bo to bylo cos
> z tego roznego systemowego shitu do dzis sie nie udalo w pelni wyjsc...moim zdaniem

> potrzebny jest lepszy wyzszy poziom systemu plikow tak by pliki mozna bylo
katalogowac na
> 'skrosne' sposob oraz potrzebny jest jakis system zapewniania integralnosci plikow
zwiazanych w paczkach (obie idee mojego pomyslu choc pewnie niektorzy inni tez o tym
mysla) potrzebne sa tez takie rzeczy jak np w menadzeze zadan widok ile dany proces
czyta bajtow z dysku lub z sieci z dokladnoscią do bajtu - bo user ma prawo do takich
informacji, potrzeban jest tez wzmozona stara dobra komponentowosc i moznosc wymiany
komponentu na inny wg uznania bo dzis to drastycznie slabo dziala

mozna by ew zastanowic sie czemu ten system komponentowy na wspolczesnych windach
niezbyt dziala.. nie wydaje sie to specjalnie trudne do zrobienia tak by bylo
powszechne i ladnie dzialalo - mozna uzyc dllki spelniajacej pewne warunki jako
komponentu (tj jako bazy na taki komponent) i raczej powino dzialac
trzebe tez oczywiscie dac miejsca i konwencje do podmienianie, przelaczania lub
dolaczania takich komponentow
jest tez kwestia ze oczywiscie kawalek proramu moze wpasc w nieskonczona petlle lub
scrashowac ale z reguly ta zasada zeby pisac programy tak by dzialaly poprawnie
dziala , dwa ze winda mam wrazenie ciul lepiej moglaby zarzadzac tymi kraszami i
zwlaszcza wpadaniem programow w loopy 0 dzis jak napisze sie apke ktora mieli loop
bez oddawania kontroli w petli eventow to potrafi to zablokowac system na minute nim
to da sie skillowac imo winda powinna raczej jakos mocniej wywlaszczac takie progamy
by az tak nie gniotly systemu

dobre miejsce na dobry komponent w systemie to imo super ciekawa rzecz by byla ale
dzis te pluginy (bo nawet nie komponenty) to nieprzyjemna babranina...winda powinan
opracowac dobry system dolaczania komponentow na poziomie systemu

do góry

W dniu 04.01.2021 o 20:35, heby pisze:
> On 04/01/2021 19:02, Luke wrote:
>> Decyzja IBM była decyzją sprzętową. Dotyczyła produkcji podzespołów,
>> nie miała nic wspólnego z DOS-em i ewentualną dominacją.
>
> Intel zrobił 8086 w taki sposób aby dało się *automatycznie* translować
> oprogramowanie z 8080.

Był jeszcze 8088
Oprócz DOSa zaczeli robić Windows 16 bit. Śmieszne takie.

do góry

W dniu 06.01.2021 o 14:28, heby pisze:
/..../
> Tymczasme wzieli dziadowski procesor, nie mają pojęcia o systemie
> operacyjnym jak na nim będzie i wyciągając druty z CPU nazywając to
> "magistralą", zmuszając ludzi do ręcznego przydzielania IO i przerwań.
> Taki "komputer poskładany na kolanie przez studenta".
>
Jaki procesor był niedziadoski?

>>> Niebywałe. Co oni tam robili przez te wszystkie lata? DoubleSpace?
>> Nic.
>
> Nic? Czekaj, czyli potwierdzasz tezę o zapaści?
>
>> W kwestii rozwoju Windows czy Office też długo nie robiono nic.
>
> Ależ robiono, jednak to dopiero *potem* było widać że cośtam dziubali z
> Windowsem 1.0 który był wyraźnie gorszy nawet od GUI Amigi i Atari ST
> mimo zupełnie innych zasobów gotówki. Team od MS-DOSa musiał być chyba
> często na wakacjach, bo nic tam się nie działo.

Obsługa szerokiego wachlarza sprzętu.
>

do góry