On 2012-04-30 23:35, John Smith wrote:
>>> Kolega też chyba nie widzi różnicy w sygnałach na końcówkach uP i uC.
>> Przy odpowiednio duzej szybkości uC właśnie nie widać żadnej rożnicy.
> Zrobienie *dokładnej* emulacji sprzętowo-programowej Z80 na ARM-ie,
> wydaje się być mocno nieopłacalne.

Ładowanie się w Z80 wydaje się mocno bez sensu. Dlatego ciągnę ten
absurd, skoro i watek absurdalny u podstaw :)

> Emulacja sprawniej by się mogła udać
> na FPGA. Tylko po co?

Po co robić ethernet na Z80 :) Chyba nawet gotowe rozwiązanie sprzetowe
nie jest wystarczającym argumentem żeby reanimować trupy. *Wszystko* na
rynku jest lepsze od Z80 pod dowolnym względem.

do góry

W dniu 2012-04-30 23:35, John Smith pisze:
> W dniu 2012-04-30 21:53, Sebastian Biały pisze:
>> On 2012-04-29 23:48, John Smith wrote:
>>> Kolega też chyba nie widzi różnicy w sygnałach na końcówkach uP i uC.
>>
>> Przy odpowiednio duzej szybkości uC właśnie nie widać żadnej rożnicy.
>
> Zrobienie *dokładnej* emulacji sprzętowo-programowej Z80 na ARM-ie,
> wydaje się być mocno nieopłacalne. Emulacja sprawniej by się mogła udać
> na FPGA. Tylko po co?
Nie ma sensu emulować Z80 w pełni. W tym przypadku autor chce i tak
pisania nowego softu na Z80 (w asemblerze). Więc softu nie ma, a skoro
nie ma i trzeba go stworzyć, to łatwiej go stworzyć wprost na ARMa, z
wbudowanym w ten soft tcp/ip i całym ethernetem jaki się wymyśli, a nie
tworzyć soft na zabytek, w zabytkowym asmeblrze, i jeszcze modzić jak tu
do ethernetu to podłączyć, i robić soft na interfejs z80<>eth.
Jeśli chodziło mi o emulacje, to o zewnętrzne udawanie Z80 przy pomocy
lini i/o ARMa, tak by dostawać się do istniejącego hardware (czyli
realnie tylko i/o w przestrzeni adresowej Z80, bo ram i rom jego jest
nam niepotrzebny)


--
| Bartłomiej Kuźniewski
| s...@d...org GG:23319 tel +48 696455098 http://drut.org/
| http://www.allegro.pl/show_user_auctions.php?uid=338
173

do góry

Dnia 30-04-2012 o 23:38:13 Sebastian Biały <h...@p...onet.pl>
napisał(a):

> On 2012-04-30 23:19, Andrzej Ekiert wrote:
>>>>> Jak zgodność tego produktu z dowolnym standardem C++?
>>>> Dość trudno mówić o zgodności z C++, skoro Microchip ma tylko
>>>> kompilatory C.
>>> No właśnie. Bida aż piszczy.
>> Tylko w przypadku PIC32 kompilator C++ miałby trochę sensu.
>
> Ma sens na AVR. Dlaczego na PIC nie miałby? Bo sprzetowy stos? Zonk ...

Ma? Na 8-bitowe AVRy też?

Wydaje mi się, że pisanie w C++ na mały mikrokontroler sprowadzałoby się
do ciągłego uważania, żeby przypadkiem nie użyć zbyt zaawansowanych
funkcji języka. Tu coś podziedziczysz, tam dodasz parę trywialnych metod,
bo enkapsulacja obiektu będzie wtedy lepsza (ale kompilator włoży funkcje,
zamiast odwołać się bezpośrednio do pamięci), gdzieś tam zrzutujesz
wskaźnik i nawet nie zauważysz, że użyłeś identyfikacji typu run-time, i
po chwili używasz 2 razy więcej Flasha lub RAMu, niż użyłbyś w C.

Jak już koniecznie programować obiektowo, to od C++ wolałbym język ADA -
przynajmniej wtedy otworzyłby się rynek safety-critical.

BTW, sprzętowy stos dotyczy tylko 8-bitowych PICów. I do C++ ma się nijak.

ae

do góry

On 2012-05-01 00:00, Andrzej Ekiert wrote:
>> Ma sens na AVR. Dlaczego na PIC nie miałby? Bo sprzetowy stos? Zonk ...
> Ma? Na 8-bitowe AVRy też?

Here we go again ... Reszta grupy niech zamknie oczy.

Ależ oczywiście że ma sens na 8 bit.

> Tu coś podziedziczysz

[cut crap]

Kto tu mówi o pisaniu obiektowym?

> run-time, i po chwili używasz 2 razy więcej Flasha lub RAMu, niż użyłbyś
> w C.

Urban legend. Najczęsciej rozpowiadane przez ludzi którzy nie rozumieją
C++, nie pisali bądź doczytali że coś tam gdzieś tam komuśtam zjadło
więcej flasha. A potem okazało się że to był pierwszy eksperyment z C++
w życiu jakiegoś nerda od pisania w asm.

> Jak już koniecznie programować obiektowo

Kto mówi o pisaniu obiektowym?

>, to od C++ wolałbym język ADA -
> przynajmniej wtedy otworzyłby się rynek safety-critical.

Tak, ada już pokazała że jest cafe-critical-full-wypas że ojej.

http://en.wikipedia.org/wiki/Ariane_5_Flight_501

do góry

Dnia 01-05-2012 o 00:10:53 Sebastian Biały <h...@p...onet.pl>
napisał(a):

>
>> Tu coś podziedziczysz
>
> [cut crap]
>
> Kto tu mówi o pisaniu obiektowym?
>

Bardzo dziękuję za nazwanie mojej wypowiedzi "gównem". Normalnie,
potrzebowałem tego.

Poza tym wyciąłeś tam zdanie: "Wydaje mi się, że pisanie w C++ na mały
mikrokontroler sprowadzałoby się do ciągłego uważania, żeby przypadkiem
nie użyć zbyt zaawansowanych funkcji języka." Jeśli wytniesz pisanie
obiektowe, to robisz dokładnie to, co napisałem - sprowadzasz C++ do
proceduralnego C.

>> run-time, i po chwili używasz 2 razy więcej Flasha lub RAMu, niż użyłbyś
>> w C.
>
> Urban legend. Najczęsciej rozpowiadane przez ludzi którzy nie rozumieją
> C++, nie pisali bądź doczytali że coś tam gdzieś tam komuśtam zjadło
> więcej flasha. A potem okazało się że to był pierwszy eksperyment z C++
> w życiu jakiegoś nerda od pisania w asm.

Jeśli koniecznie musi być ad personam, to tak się składa, że zawodowo
programuję w C, C++ i asm. Od ponad 10 lat. Ale wolałbym trzymać się
argumentów merytorycznych, a nie uzasadniać że mam rację, bo mam większego
eksperta. Dałem konkretne przykłady rzeczy, na które trzeba uważać
programując w C++, bo brak uwagi będzie skutkować wygenerowaniem
niepotrzebnego kodu. A ty mi się do nich nie odnosisz, wycinasz i
próbujesz sugerować doborem cytatu, że uważam że w C++ kod zawsze musi być
większy.

> Tak, ada już pokazała że jest cafe-critical-full-wypas że ojej.
>
> http://en.wikipedia.org/wiki/Ariane_5_Flight_501

Ada to de facto standard w safety-critical, więc posiadanie kompilatora
otworzyłoby mi (jako sprzedającemu procesory) nowy rynek. I tyle. A kod,
który zawiera błędy, można napisać w każdym języku. W Adzie podobno
trudniej (podobno, bo tu jestem tylko na poziomie "hello world").

ae

do góry

On 2012-05-01 10:21, Andrzej Ekiert wrote:
>> [cut crap]
>> Kto tu mówi o pisaniu obiektowym?
> Bardzo dziękuję za nazwanie mojej wypowiedzi "gównem". Normalnie,
> potrzebowałem tego.

crap to beznadzieja. Jesli zaczynasz atakowanie C++ na uC od dyskusji o
obiektowości to jest to beznadziejne.

> Jeśli wytniesz pisanie
> obiektowe, to robisz dokładnie to, co napisałem - sprowadzasz C++ do
> proceduralnego C.

Nie. C++ to znacznie więcej niż obiektowość. *Właśnie* w uC te inne niż
obiektowość rzeczy są przydatne. Takie jak destruktory, silne typy,
traits i ogólnie szablony w metaprogramowaniu. I nie, te szablony nie
muszą generować *ANI* grama kodu. Dostajesz darmowe ciastko. Microchip
jednak slusznie zauwazył, że środowisko klepaczy w C nijak nie pojmuje
ze jest to smaczne ciastko i jest darmowe. Więc go nie daje i lemmingi C
nie widzą różnicy dalej klepiąc kiepskie makra.

> Dałem konkretne przykłady rzeczy, na które trzeba
> uważać programując w C++, bo brak uwagi będzie skutkować wygenerowaniem
> niepotrzebnego kodu.

Daleś przykład obiektów. To nagorszy pustak jaki mogłeś mieć w tej dyskusji.

> A ty mi się do nich nie odnosisz, wycinasz i
> próbujesz sugerować doborem cytatu, że uważam że w C++ kod zawsze musi
> być większy.

Uważam że taki jest urban legend. Twoje wypowiedzi tylko to potwierdzają.

> W Adzie podobno
> trudniej (podobno, bo tu jestem tylko na poziomie "hello world").

Całe szczeście że na 8-bit nikt nie pisuje w Adzie.

do góry

Dnia 01-05-2012 o 15:01:17 Sebastian Biały <h...@p...onet.pl>
napisał(a):

> crap to beznadzieja.

To by raczej było "hopelessness". A wulgaryzm pozostaje wulgaryzmem.
Odniesiony do czyjejś wypowiedzi, jest... mało elegancki.

> Jesli zaczynasz atakowanie C++ na uC od dyskusji o obiektowości to jest
> to beznadziejne.

No cóż - główna cecha różnicująca języki, o których mowa. Faktycznie, nie
ma czego wspominać.

> Nie. C++ to znacznie więcej niż obiektowość. *Właśnie* w uC te inne niż
> obiektowość rzeczy są przydatne. Takie jak destruktory, silne typy,
> traits i ogólnie szablony w metaprogramowaniu.

Szablony to się właśnie przydają przy dużych programach, gdzie jest
potrzeba wykonywania tych samych operacji na różnych typach danych. Przy
programowaniu na mikrokontrolery? - może czasem się mogłyby przydać, ale
na pewno nie *właśnie* tam.

Destruktory to cecha obiektowa, której zalety wychodzą szczególnie w
przypadku typów polimorficznych, ale sam twierdzisz, że prawdziwie
obiektowo, to nie chcesz pisać. Przy "zwykłych" typach, nie wnoszą jakiejś
jakościowej różnicy, za to przez swoje "samoczynne" uruchamianie się
stanowią niezłą okazję do implementacji subtelnych bugów, szczególnie u
niezbyt doświadczonych programistów (a piszemy o mikrokontrolerach, które
w praktyce, szczególnie w mniejszych firmach, najczęściej programują
elektronicy).

Silna typizacja, to kwestia gustu i konwencji, poza tym oba języki mają to
na podobnym poziomie - tu i tu jest "static typing", tylko w C łatwiej to
obejść bokiem, za to w C++ trzeba zrozumieć 4 różne operatory rzutowania
wskaźników, a konwersje "kompatybilnych" typów i tak zachodzą
automatycznie i gryzą tak samo jak w C. A jeśli chodzi o traits, to w C++
to nie cecha języka, a jedynie idiom, poza tym chyba żartujesz podając to
jako coś ponadmarginalnie przydatnego przy programowaniu mikrokontrolerów
8-bit.

> środowisko klepaczy w C [...] i lemmingi C nie widzą różnicy dalej
> klepiąc kiepskie makra.

Po co epitety? Dowartościowujesz się obrażając programistów C?

>> próbujesz sugerować doborem cytatu, że uważam że w C++ kod zawsze musi
>> być większy.
>
> Uważam że taki jest urban legend. Twoje wypowiedzi tylko to potwierdzają.

Bardzo dziwną logikę stosujesz, skoro z moich wypowiedzi ma wynikać
istnienie jakichś legend.

Na moje stwierdzenie, że aby nie generować nadmiaru kodu, język trzeba by
okroić przez samoograniczenie programisty, gwałtownie protestujesz, po
czym stwierdzasz, że okroisz go z całego programowania obiektowego. No
weź...

>> W Adzie podobno
>> trudniej (podobno, bo tu jestem tylko na poziomie "hello world").
>
> Całe szczeście że na 8-bit nikt nie pisuje w Adzie.

Bardzo ciekawe. Akurat na twoje ulubione AVRy jest kompilator - powstał
pewnie tylko dla zabawy. Poza tym, tego twojego nagłego czepienia się Ady
nie rozumiem już zupełnie. To dlatego, że ja o niej napisałem, to już
musisz być koniecznie przeciw?

ae

do góry

On 2012-05-01 23:35, Andrzej Ekiert wrote:
> Szablony to się właśnie przydają przy dużych programach, gdzie jest
> potrzeba wykonywania tych samych operacji na różnych typach danych.

Nie. Podstawowym zastosowaniem szablonów w małej skali beda traitsy i
metaprogramowanie. Nijak nie ma tu mowy o powielaniu kodu w sensie
std::vector< T >. To zupełnie inne zastosowanie niż to o którym piszesz.
Ja rozumiem to jako podejście w stylu boost::mpl.

> Destruktory to cecha obiektowa, której zalety wychodzą szczególnie w
> przypadku typów polimorficznych

Destruktory to cecha która nie wymaga podejścia obiektowego do
programowania. Najprościej:

struct CriticalSection {
CriticalSection{ cli(); }
~CriticalSection{ sei(); }
};

To żadne programowanie obiektowe. A destruktor przydatny.

> za to przez swoje "samoczynne" uruchamianie
> się stanowią niezłą okazję do implementacji subtelnych bugów,
> szczególnie u niezbyt doświadczonych programistów

Odwrotnie: dzieki swojemu samoczynnemu dzialaniu *ochraniają* przed
wieloma subtelnymi bugami w stylu "a mi się tu zapomniało zdjąć flagę
przerwania".

> podając to jako coś ponadmarginalnie przydatnego przy programowaniu
> mikrokontrolerów 8-bit.

Mi się przydaje. Przyznaje, idę pod prąd.

>> środowisko klepaczy w C [...] i lemmingi C nie widzą różnicy dalej
>> klepiąc kiepskie makra.

> Po co epitety? Dowartościowujesz się obrażając programistów C?

Ja juz nie musze się dowartościowywać od czasu kiedy usłyszałem od
pewnego programisty uC że najlepszy kompilator to jakieś barachło pod
DOSa w którym wszelakie optymalizacje należy i tak robić ręcznie w asm.
Dziwnym trafem najczęsciej wlasnie takie teksty słyszę od tzw lemmingów.
Ludzi którzy nie mają ochoty na zmiany, a na pewno nie w lepszym
kierunku. Microchip doskonale wyczuł sytuacje dostarczając technologie
wprost z lat 80. Malo tego, jest cała masa ludzi którzy preparują
pseudo-merytoryczne argumenty dlaczego C jest lepsze niz C++ bo przeciez
MC nie jest głupi.

A MC nie jest głupi, ale tylko marketoidalnie...

Moje marzenie to PIC w sensie peryferiów i AVR w sensie rdzenia. Ale sie
nie doczekalem bo przyszły ARMy i pozamiatały.

> Na moje stwierdzenie, że aby nie generować nadmiaru kodu, język trzeba
> by okroić przez samoograniczenie programisty, gwałtownie protestujesz,
> po czym stwierdzasz, że okroisz go z całego programowania obiektowego.

Bo po co mi programownie obiektowe na 8-bit z 1k pamięci? C++ dostarcza
masę innych narzędzi, obiekty to najmniej ważny element w uC.

> Bardzo ciekawe. Akurat na twoje ulubione AVRy jest kompilator - powstał
> pewnie tylko dla zabawy. Poza tym, tego twojego nagłego czepienia się
> Ady nie rozumiem już zupełnie. To dlatego, że ja o niej napisałem, to
> już musisz być koniecznie przeciw?

Nie muszę. Ada to zacny język, choć obrośnięty legendą jakości która jak
widać musi walczyć z faktami. Ale stawianie go obok C++ w kontekscie tej
rozmowy uważam za niepoważne. *Nikt* nie pisze w Ada poza szumem
statystycznym. Nie zmuszajmy MC żeby pisał kompilator Ady dla 0.01%
programistow uC. Ale C++ mógłby. Wystarczylo sportować gcc. No chyba, że
architektura PICów nie da się wmontować w backed gcc. Co za pech ...,
znaczy design ...

do góry

W dniu 2012-05-02 01:28, Sebastian Biały pisze:

> Moje marzenie to PIC w sensie peryferiów i AVR w sensie rdzenia.

To chyba raczej koszmar. Peryferia w PIC to sprytny księgowy projektuje.
Jeden port ma podciąganie, inny nie; porty potrafią się różnić
obciążalnością. Kanały ADC można włączać tylko zakresami (np.15..7 a nie
pojedynczo). Najbardziej podoba mi się ADC w PICach z ethernetem. Jak
się przekroczy napięcie zasilania na wejściu ADC to zaczyna płynąć prąd
nie do linii Vcc, tylko do kanału aktualnie mierzonego :-). Jakiś
humorysta to projektował.

do góry

Dnia 02-05-2012 o 01:28:30 Sebastian Biały <h...@p...onet.pl>
napisał(a):

> Ja rozumiem to jako podejście w stylu boost::mpl.
>

Ładne. Ale szczerze mówiąc to nie bardzo widzę, jaki problem to rozwiązuje
w przypadku programowania naszego 8-bitowca z 1kB kodu.

> Destruktory to cecha która nie wymaga podejścia obiektowego do
> programowania. Najprościej:
>
> struct CriticalSection {
> CriticalSection{ cli(); }
> ~CriticalSection{ sei(); }
> };

Sprytne i fajnie pokazuje, jak działa destruktor. Ale ja bym po prostu
napisał:

cli();
... kod krytyczny
sei();

Lepiej widać w jednym miejscu co się dzieje, bez szukania definicji klasy
CriticalSection, bez zastanawiania się gdzie jej obiekt wychodzi z
zasięgu, no i bez ryzyka, że osoba, która nie jest autorem kodu nie
zauważy, że wsród paru zmiennych lokalnych jest jakiś dziwny pozornie
nieużywany obiekt.

> Odwrotnie: dzieki swojemu samoczynnemu dzialaniu *ochraniają* przed
> wieloma subtelnymi bugami w stylu "a mi się tu zapomniało zdjąć flagę
> przerwania".

Ja tam wolę widzieć przebieg programu, a nie musieć ciągle pamiętać, że
między ostatnią instrukcją funkcji, a '}' uruchomi się jeszcze seria
niewidzialnych funkcji. Zresztą, akurat w mojej praktyce programowania
małych uC potrzeba nietrywialnej destrukcji "obiektu" zachodzi bardzo
rzadko.

>> podając to jako coś ponadmarginalnie przydatnego przy programowaniu
>> mikrokontrolerów 8-bit.
>
> Mi się przydaje. Przyznaje, idę pod prąd.

Skoro ci się przydaje i masz nawyk ciągłego stosowania takich konstrukcji,
to rozumiem że koniecznie chcesz mieć C++.

> Moje marzenie to PIC w sensie peryferiów i AVR w sensie rdzenia. Ale sie
> nie doczekalem bo przyszły ARMy i pozamiatały.

Architektura 16-bit Microchipa (PIC24, dsPIC33) to właśnie coś takiego.
Bardzo elegancko zaprojektowana, przyjemnie się z tym pracuje - moim
zdaniem dużo ładniejsza niż MIPS, którego użyli w PIC32, oraz niż ARM.

> Nie zmuszajmy MC żeby pisał kompilator Ady dla 0.01% programistow uC.
> Ale C++ mógłby. Wystarczylo sportować gcc.

Nie zmusimy ich do niczego, bo tam kalkulacja jest prosta: zrobienie
kompilatora kosztuje tyle, a zyskamy na tym tyle. Jeśli nierówność zaczyna
wychodzić zdecydowanie na korzyść, to robią.

> No chyba, że architektura PICów nie da się wmontować w backed gcc.

gcc zostało przeniesione na architektury 16 i 32 bit. Jeśli chodzi o te 32
bit (rdzeń MIPS) to spodziewam się, że prędzej czy później kompilator C++
się pojawi. Do 16-bit też pewnie mogliby to w miarę tanio zrobić - mi
zupełnie jednak na tym nie zależy.

ae

do góry