🚀 go-pugleaf

On 09/03/2020 02:03, JDX wrote:
>> Czyli jakie unikatowe cechy rdzenia '51 lub peryferiów nie występują
>> w ByleCzym?
> No banki rejestrów

Zerknij na FIQ na ARM.

> i wydzielony stos raczej nie występują we
> współczesnym byle czym. :-D

Bo współczesne byle co właśnie nie musi mieć sprzętowego stosu. To jest 
zaleta, że nie ma.

>> Nie, to już nie jest utrzymywanie. To prosta droga do katastrofy.
> Dlaczego zaraz katastrofy? Firma ma nowy produkt na nowym, zupełnie
> innym MCU, ale stary produkt na 51 też (się) sprzedaje.

W sensie jaka nowa technologia, projektowana na nowym ASICu ma mieć 
stary kod pisany pod '51? Bo taki target jest tego wynalazku z Bytomia.

>> Problemem nie jest pieniądź.
> Ooo, na podstawie mojego doświadczenia jako klepacza kodu w tzw.
> biznesie myślę, że problemem jest przede wszystkim pieniądz. Trudno mi
> sobie wyobrazić użycie 51 w nowym projekcie, ale kto wie, może jakaś
> firma chciałaby lekko zmodyfikować sprzęt i zrobić 51 w ASICu (+ jakiś
> dodatkowy stuff) i wykorzystać istniejące oprogramowanie. Właśnie w celu
> zaoszczędzenia, najprawdopodobniej krótkoterminowego.

A czyli w sensie zrobić taki workaround? A tak, to do tego tak. Tylko że 
w takich projetkach juz nie ma C++ z definicji. Nie zapomina że to wątek 
o C++ i w tym kontekscie się tutaj wypowiadam. '51 nie ma sensu w ogóle 
poza jakimiś iditycznymi przypadkami z okolic zapchajdziury na rynku. 
Nikt tam nie będzie narzekał na kompilator a często nie będzie narzekał 
na cokolwiek bo ma tylko wsad binarny a główny programista od 20 lat 
leży pod brzozą.

Nawet Microsoft ostatnio naprawia bugi w starym office na poziomie 
asemblera bo, prawdopodobnie, zgubili kod źródłowy. SourceSafe, hehehe.

>> I potem się dziwie że na C++ w embedded przeciętny Pan Zdzisław od
>> 40 lat robiący sterowiki zegarów szkolnych reaguje alergicznie. Skoro
>> się nie da użyć w "najszybszym procesorze świata" to najlepiej nie
>> używać wcale i nigdzie.
> Na ja np. chciałbym użyć, ale nie tylko gołego C++, ale też kontenerów z
> STL-a.

Kontenery STL -> allokacje. To zaczyan mieć sens od ARM7 a i tam nikły. 
Ja nie masz MMU/wirtualną to allokowanie jest proszeniem się o kłopoty. 
Jak masz MMU to jest proszeniem się o kłopoty tylko później. C++ w 
embedded to nie powinien być kontenerowy STL chyba że ktoś naprawdę wie 
co robi.

> A w C++ nie wiadomo jak to łatwo zrobić.

Nie robić jeśli nie jest to konieczne. Każda allokacja w embedded 
oznacza potencjalne problemy w runtime.

> razie jeśli już mamy być postępowi, to nie C++ tylko Rust. :-)

A tymczasem na całym świecie brodate inzyniery po 60tce napierniczają 
kod na '51 w popsutych kopilatorach C i gołym kodzie maszynowym 
nazywając to "stabilną platformą z doskonale znanymi narzędziami". 
Jeszcze 10 lat temu jeden student mówił że był w firmie gdzie dev na '51 
robili na MSDOSie. Tylko odlatego że jeden z "Zygmuntów" nie potrafił 
używać niczego poza CP/M, o pardon, MS-DOS. Ponoć dlatego że miał tam 
wszystko pod kontrolą. Ile w tym prawdy nie wiem, ale spotykam do 
dzisiaj dinozaury które potrafią pisać aktywnie w Delphi 1 więc się 
wcale nie zdziwie jeśli to była prawda.