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.