RTV forum PL | NewsGroups PL

Rynek pracy STM32

NOWY TEMAT

elektroda NewsGroups Forum Index - Elektronika Polska - Rynek pracy STM32

Goto page Previous  1, 2, 3 ... 21, 22, 23, 24  Next

Janusz
Guest

Thu Jul 21, 2022 2:27 pm   



W dniu 2022-07-21 o 15:34, heby pisze:
Quote:
On 21/07/2022 14:59, Janusz wrote:
Rzecz w tym, że nie masz pojęcia o czym mówisz.
Widziałem te twoje wypociny, daruj sobie.

I co, nie działają?
Nie wiem, nie mam takiej potrzeby ich używania.

Jak już coś pisze to piszę prosty kod zrozumiały dla mnie.


--
Janusz

Piotr Gałka
Guest

Thu Jul 21, 2022 2:29 pm   



W dniu 2022-07-21 o 16:25, Janusz pisze:

Quote:
Bo to co robi kompilator na avr to jest proteza, skoro nie da się kodu
modyfikować podczas wykonania to robimy kody na każdy argument, osobne.

Prawie na pewno się mylisz. Funkcje wirtualne nigdy nie są realizowane
poprzez modyfikowanie kodu w RAMie.

Quote:
Więc niby masz narzędzie ale de fakto to samo miałeś wcześniej pisząc
sobie sam
funkcje. Narzędzie jedynie 'ukrywa' przed tobą typ argumentu, wołasz raz
a kompilator sam dobiera ścieszkę. W '86 nie trzeba takich protez robić
bo kod może być zmieniany podczas wykonania programu.

Z tego co pamiętam (Stroustrup pisał jak jego funkcje wirtualne mają być
implementowane) to nie jest do tego wykorzystywane modyfikowanie kodu
podczas pracy programu.
P.G.

Janusz
Guest

Thu Jul 21, 2022 2:33 pm   



W dniu 2022-07-21 o 15:21, heby pisze:
Quote:
On 21/07/2022 15:06, Janusz wrote:
Szablony tak, ale polimorfizm dynamiczny już nie, tzn pójdzie bo
będzie de fakto statyczny czyli stałe procedury wygenerowane na każdą
okoliczność wsadzone w rom.

To *jest* polimorfizm dynamiczny, kiedy kod *jest* wygenerowany przez
kompialtor ,a całośc procesu sterowania nim odbywa sie przez indirect call.
Przecież statyczny jest tak samo wywoływany, nie tu tkwi różnica, ale

brnij dalej.

Quote:

Myslisz to z "kodem dynamicznym" albo "kodem samomodyfikującym" który
nie ma z tym nic wspólnego.
Polimorfizm dynamiczny na dużych maszynach był tak osiągany, czy teraz

to nie wiem bo dawno w kod nie zaglądałem, pewnie ze względów
bezpieczeństwa już tak nie robią
tym bardziej że wielkość pamięci przestałą być krytyczna.


--
Janusz

Janusz
Guest

Thu Jul 21, 2022 2:40 pm   



W dniu 2022-07-21 o 15:34, heby pisze:
Quote:
... po czym miesiąc szuka kodu, w którym pomylił flagę.
To chyba o sobie piszesz Smile bo ja już trochę programów napisałem i nie

miałem takiego problemu. Może dlatego że zamiast szablonów to używam
struktur np bitowych gdzie mam wszystko jasno opisane, ale wiem szablony
sa lepsze :)

--
Janusz

heby
Guest

Thu Jul 21, 2022 2:41 pm   



On 21/07/2022 16:25, Piotr Gałka wrote:
Quote:
Chciałem móc przekazać GUID jako parametr konstruktora - chyba mi się
nie udało.

Czy GUIDy są zmienne? Pisałeś o statycznych.

To miejsce na tempaltes, jesli są statyczne.

Quote:
Tak na prawdę to nie wiem co chciałem i na czym poległem (za dawno było).
Pamiętam jedynie, że wniosek był - tylko tak to mi działa.
Wiedząc jak robię czasem inne klasy to zapewne:
- chciałem mieć klasę bazową, która ma GUID jako parametr konstruktora.

class KlasaBazowa {
public:
KlasaBazowa( GUID const& _guid ) : m_guid( _guid );
[...]
private:
GUI const& m_guid;
};

Quote:
- ona ma funkcję FindDevs która korzysta z tego guid z konstruktora.

Więc w tej funkcji masz m_gui który jest typu GUID i o wartości jaką
przekazano do konstruktora klasy bazowej.

Quote:
- konstruktor klasy pochodnej woła konstruktor klasy bazowej wpisując
tam znany już w tym miejscu swój guid.

static GUI konkretnyGUID = { };

class KlasaKonkretna : public KlasaBazowa {
public:
KlasaKonkretna() : KlasaBazowa( konkretnyGUID ) { [...] };

[...]
};

Zaznaczam, że to nie jest optymalne. Tracisz 4 bajty na pole m_guid.

Poprawnie było by to zrobione za pomocą szablonów i techniki mixin.
Klasa bazowa nie musiała by wtedy trzymać GUIDa, ale mogła by z niego
korzystać dzięki specjalizacji szablonem.

Quote:
- klasa pochodna ma dostępną funkcję FindDevs klasy bazowej i ona umie
użyć tego guid wpisanego w jej konstruktorze.

Tak jak powyżej.

Quote:
To chyba jest to, co mi się nie udało i w każdej klasie pochodnej mam
jej własną statyczną FindDevs.

Hmmm... całośc tego wydaje mi się niejasna, co w zasadzie było problemem.

Niewątpliwie ten kod przydałby się w wersji invitro aby móc coś wiecej
dysputować.

Quote:
Taki kod: Foo = 1<<BAR;
Od lat 90-tych widuję te foo i bar i nigdy nie wiem co o tym sądzić.

To metasłowa. Może być GORZAŁKA i ZAGRYCHA.

Quote:
Skąd się to wzięło i jak o tym mysleć.

Nijak. Programiści musza czasami pokazać składnię czegoś w oderwaniu od
konkretów. Używa się też "spam", "Alice" i kilku innych.

https://en.wikipedia.org/wiki/Foobar

Quote:
A zjada 0 Flasha. Tak naprawdę, to "kod templaetowy" wykonuje się na
etapie kompilacji, jako metajęzyk.
Na razie o ile wiem to według brata przykład USB na załatwienie prostej
rzeczy zabiera 10x za dużo miejsca i nie zostaje miejsca na naszą
aplikację, a chcemy się zmieścić w 1/2 flasha z powodu upgrade'ów.

Gcc ma flagę -Os? Symbole debugowe wyłaczone w docelowej binarce?

Raczej nie dam wiary, że jest tak źle. Prosty kod usb UARTa na STM32
zajmował jakies kilobajty. Ba, w małym AVR potrafili to zmieścić, z
softwareową emulacją.

heby
Guest

Thu Jul 21, 2022 2:43 pm   



On 21/07/2022 16:33, Janusz wrote:
Quote:
Myslisz to z "kodem dynamicznym" albo "kodem samomodyfikującym" który
nie ma z tym nic wspólnego.
Polimorfizm dynamiczny na dużych maszynach

Jakich? Odrach?

Quote:
to nie wiem

No właśnie.

Kod polimorfizmu dynamicznego nie wymaga samomodyfikującego kodu, jesli
tylko masz indirect jump/call. W AVR masz. Finito.

heby
Guest

Thu Jul 21, 2022 2:46 pm   



On 21/07/2022 16:25, Janusz wrote:
Quote:
Kluczowe słówko: 'bo'.
Kwestia nie wykonywania z RAMu była użyta tylko jako wytłumaczenie
dlaczego do głównej tezy, że program wygenerowany z templates nie
pójdzie w avr.
Bo to co robi kompilator na avr to jest proteza, skoro nie da się kodu
modyfikować podczas wykonania to robimy kody na każdy argument, osobne.

Nie masz pojęcia co piszesz. Kompilatory praktycznie nigdy nie produkują
kodu samomodyfikującego, od dziesiątek lat. Nie ma znaczenia, czy na AVR
czy RISCV. To jest bezużyteczna technika.

Quote:
Więc niby masz narzędzie ale de fakto to samo miałeś wcześniej pisząc
sobie sam
funkcje. Narzędzie jedynie 'ukrywa' przed tobą typ argumentu, wołasz raz
a kompilator sam dobiera ścieszkę. W '86 nie trzeba takich protez robić
bo kod może być zmieniany podczas wykonania programu.

Nikt tego nie robi, poza trampolinami. Od dziesiątek lat nie piszemy
kodu samomodyfikującego bo to jest najzwyczajniej niepotrzebne i
utrudnia działanie potoków w CPU mocno je spowalniając.

heby
Guest

Thu Jul 21, 2022 2:48 pm   



On 21/07/2022 16:27, Janusz wrote:
Quote:
On 21/07/2022 14:59, Janusz wrote:
Rzecz w tym, że nie masz pojęcia o czym mówisz.
Widziałem te twoje wypociny, daruj sobie.
I co, nie działają?
Nie wiem

Napisałeś kilkarazy, że nie działają, bo Harvard.

Quote:
Jak już coś pisze to piszę prosty kod zrozumiały dla mnie.

Tego nie dało się napisać prościej, aby wykazać ideę i działanie na AVR.
Złośliwe - dodajmy, bo miało nie działać.

Janusz
Guest

Thu Jul 21, 2022 3:37 pm   



W dniu 2022-07-21 o 16:43, heby pisze:
Quote:
On 21/07/2022 16:33, Janusz wrote:
Myslisz to z "kodem dynamicznym" albo "kodem samomodyfikującym" który
nie ma z tym nic wspólnego.
Polimorfizm dynamiczny na dużych maszynach

Jakich? Odrach?
PC-tach.

to nie wiem

No właśnie.

Kod polimorfizmu dynamicznego nie wymaga samomodyfikującego kodu, jesli
tylko masz indirect jump/call. W AVR masz. Finito.
Tylko wtedy niczym sie nie różni od statycznego.


--
Janusz

Janusz
Guest

Thu Jul 21, 2022 3:42 pm   



W dniu 2022-07-21 o 16:46, heby pisze:
Quote:
On 21/07/2022 16:25, Janusz wrote:
Kluczowe słówko: 'bo'.
Kwestia nie wykonywania z RAMu była użyta tylko jako wytłumaczenie
dlaczego do głównej tezy, że program wygenerowany z templates nie
pójdzie w avr.
Bo to co robi kompilator na avr to jest proteza, skoro nie da się kodu
modyfikować podczas wykonania to robimy kody na każdy argument, osobne.

Nie masz pojęcia co piszesz.
Szkoda słów.


Kompilatory praktycznie nigdy nie produkują
Quote:
kodu samomodyfikującego, od dziesiątek lat. Nie ma znaczenia, czy na AVR
czy RISCV. To jest bezużyteczna technika.

Więc niby masz narzędzie ale de fakto to samo miałeś wcześniej pisząc
sobie sam
funkcje. Narzędzie jedynie 'ukrywa' przed tobą typ argumentu, wołasz
raz a kompilator sam dobiera ścieszkę. W '86 nie trzeba takich protez
robić bo kod może być zmieniany podczas wykonania programu.

Nikt tego nie robi, poza trampolinami. Od dziesiątek lat nie piszemy
kodu samomodyfikującego bo to jest najzwyczajniej niepotrzebne i
utrudnia działanie potoków w CPU mocno je spowalniając.
A wiesz że pierwsze pc-ty nie miały potoków? nawet 486 i pentiumy nie miały,

więc o czym piszesz, mało wiesz a sadzisz się jak kura na grzędzie. To
że później ich ni ma to już napisałem, więc sobie daruj, ale informatyka
czy programowanie nie zaczeło sie jak Ty zacząłeś pisać.


--
Janusz

heby
Guest

Thu Jul 21, 2022 3:49 pm   



On 21/07/2022 17:37, Janusz wrote:
Quote:
Kod polimorfizmu dynamicznego nie wymaga samomodyfikującego kodu,
jesli tylko masz indirect jump/call. W AVR masz. Finito.
Tylko wtedy niczym sie nie różni od statycznego.

Czyli potwierdzasz, że nie pojmujesz w czym rzecz.

https://www.modernescpp.com/index.php/dynamic-and-static-polymorphism

Dynamiczny polimorfizm bazuje na wołaniu metod wirtualnych.

Statyczny bazuje na zamrożeniu tych wywołań na etapie kompilacji, przez
co metody wirtualne przestają być potrzebne.

Tak z grubsza.

heby
Guest

Thu Jul 21, 2022 3:58 pm   



On 21/07/2022 17:42, Janusz wrote:
Quote:
funkcje. Narzędzie jedynie 'ukrywa' przed tobą typ argumentu, wołasz
raz a kompilator sam dobiera ścieszkę. W '86 nie trzeba takich protez
robić bo kod może być zmieniany podczas wykonania programu.
Nikt tego nie robi, poza trampolinami. Od dziesiątek lat nie piszemy
kodu samomodyfikującego bo to jest najzwyczajniej niepotrzebne i
utrudnia działanie potoków w CPU mocno je spowalniając.
A wiesz że pierwsze pc-ty nie miały potoków?

To było dziesiątki lat temu. Dlatego od dziesiatek lat nie stosujemy
kodu samomodykującego.

Quote:
nawet 486 i pentiumy nie
miały,

486 miał potok, podobnie jak Pentium.

https://pl.wikipedia.org/wiki/Intel_80486

Quote:
więc o czym piszesz, mało wiesz

Na razie wychodzisz na ignoranta. Jestes pewny, że widziałes kiedyś na
oczy komputer? Współczesny? Taki po Odrze?

Quote:
informatyka
czy programowanie nie zaczeło sie jak Ty zacząłeś pisać.

Chcesz mi powiedzieć, że całe to bredzenie o Harvardzie i
samoodyfikującym się kodzie, to tylko dlatego, że jesteś kustoszem w muzeum?

To teraz jasne.

FYI: mamy już 2022. W mikrokontrolerach mamy C++. Mamy potoki w
pierdołach wielkości główki zapałki, do migania diodą. Świat się
rozwinął od czasu jak odpalałeś ostatni czas Odrę.

J.F
Guest

Thu Jul 21, 2022 4:15 pm   



On Thu, 21 Jul 2022 16:46:46 +0200, heby wrote:
Quote:
On 21/07/2022 16:25, Janusz wrote:
Kluczowe słówko: 'bo'.
Kwestia nie wykonywania z RAMu była użyta tylko jako wytłumaczenie
dlaczego do głównej tezy, że program wygenerowany z templates nie
pójdzie w avr.
Bo to co robi kompilator na avr to jest proteza, skoro nie da się kodu
modyfikować podczas wykonania to robimy kody na każdy argument, osobne.

Nie masz pojęcia co piszesz. Kompilatory praktycznie nigdy nie produkują
kodu samomodyfikującego, od dziesiątek lat. Nie ma znaczenia, czy na AVR
czy RISCV. To jest bezużyteczna technika.

Jedyne co mi przychodzi na mysl, to jakies switch/case, gdzie mozna
obliczyc adres skoku, a procesor nie ma stosownego rozkazu.
No chyba, ze wrzucic adres na stos i zrobic RET.

A - i jeszcze 8080, gdzie nie bylo rozkazu IN/OUT z adresem w
rejestrze. Tylko na stale umieszczony w kodzie, a mamy np
8 portow szeregowych do obsluzenia.

Quote:
Więc niby masz narzędzie ale de fakto to samo miałeś wcześniej pisząc
sobie sam
funkcje. Narzędzie jedynie 'ukrywa' przed tobą typ argumentu, wołasz raz
a kompilator sam dobiera ścieszkę. W '86 nie trzeba takich protez robić
bo kod może być zmieniany podczas wykonania programu.

Nikt tego nie robi, poza trampolinami. Od dziesiątek lat nie piszemy
kodu samomodyfikującego bo to jest najzwyczajniej niepotrzebne i
utrudnia działanie potoków w CPU mocno je spowalniając.

Plus wielozadaniowosc i przełaczanie zadan, przerwania, protekcja itp
..

J.

heby
Guest

Thu Jul 21, 2022 7:00 pm   



On 21/07/2022 20:36, Dawid Rutkowski wrote:
Quote:
Ja też nie rozumiem sensu szablonów.

Pozwalają podejmować decyzje na etapie kompialcji. Ta niewielka cecha
czyni z nich poteżne narzędzie, użyteczne w wielu sytuacjach. W embedded
też. Być może tam w szczególności - niektóre konstrukcje pozwalają na
absurdalnie dokładne optymalizacje kodu wynikowego.

Quote:
Jak tylko zobaczyłem, uznałem, że to to samo co define'y - a nieszczęsny zapis z <> odrzucił estetycznie.

Nie to samo. Główna rónica, jak już chcesz porównać, to ścisła kontrola
typów, których w #define nie ma. #define to taki regexp/sed wbudowany w
język, z masą problemów.

Quote:
I przez to nie da się zrobić bibliotek closed-source.

Da się.

Quote:
Polepszyło się coś od 2001?

W sensie templates? Cały nowoczesny C++ to głównie szablony. Robiące
rzeczy o kłopotliwej w wyjasnieniu, przeciętnemu kilkaczowi w C, rzeczy.
To mocno inny język.

Quote:
Tylko nie mieszajmy w to idei open-source i free software.

Szablony nie musza być open-source, aczkolwiek ich uzytecznośc wtedy nie
jest tak wielka.

Możesz mieć Foo< Bar > gdzieś w .hpp i biblitekę .a. Bez znajomości Foo
i Bar.

Ogólnie interfejsy biblitek bardziej korzystają z szablonów (np.
boost::optional< Foo >, std::shared_ptr< Bar >, itd) niż mają interfejs
szablonowy. Skoro są closed source to raczej nie ba się korzystać z
mozliwosci szablonów, bo one, aby były optymalnie wykorzystane, muszą
widzieć kod, aby go zoptymalizować. Co nie znaczy że nie korzysta się z
szablonów w closed-source. Jako narzędzie a nie cel.

Janusz
Guest

Thu Jul 21, 2022 7:18 pm   



W dniu 2022-07-21 o 17:49, heby pisze:
Quote:
On 21/07/2022 17:37, Janusz wrote:
Kod polimorfizmu dynamicznego nie wymaga samomodyfikującego kodu,
jesli tylko masz indirect jump/call. W AVR masz. Finito.
Tylko wtedy niczym sie nie różni od statycznego.

Czyli potwierdzasz, że nie pojmujesz w czym rzecz.
Oczywiście że wiem. To ty się puszysz jak kogut w kurniku.

https://www.modernescpp.com/index.php/dynamic-and-static-polymorphism

Dynamiczny polimorfizm bazuje na wołaniu metod wirtualnych.
czyli calami wywołuje funkcje z rom, tylko wpierw musi wybadać typ

zmiennej żeby wybadać gdzie skoczyć.
Quote:

Statyczny bazuje na zamrożeniu tych wywołań na etapie kompilacji, przez
co metody wirtualne przestają być potrzebne.
Czyli te same cale co wyżej tylko na stałe przypisane do wywołania bo

kompilator wie jaki jest typ zmiennej i nic nie musi badać.
Quote:

Tak z grubsza.
I tak z grubsza jest guano bo pakowane są wszystkie funkcje w zalezności

od typu, czyli to samo co robi dotychczasowy amator pisząc osobne
funkcje na kazdy typ zmiennej np: na wysyłanie znaku czy liczby. Jedyna
zaleta że w wywołaniu ładnie wygląda po to jedna funkcja np: lcd.print()
Jak widać postęp niewielki a kruszysz kopie jakby nie wiadomo co to było.

--
Janusz

Goto page Previous  1, 2, 3 ... 21, 22, 23, 24  Next

elektroda NewsGroups Forum Index - Elektronika Polska - Rynek pracy STM32

NOWY TEMAT

Regulamin - Zasady uzytkowania Polityka prywatnosci Kontakt RTV map News map