On Wednesday, August 30, 2017 at 10:30:53 AM UTC-4, slawek wrote:
> On Wed, 30 Aug 2017 07:09:02 -0700 (PDT), Adam M
> <a...@m...com> wrote:
> > Skoro ten Python jest taki dobry do wszystkiego
> > i taki szybki to dlaczego nie uswiadczysz go na
> > MCU/DSP albo nawet na wiekszosci SOC
>
> Przy 1kB SRAM to raczej nie doradzałbym Pythona.
>
> Ale ludzie dziwne rzeczy robią. Np. używają Delphi do pisania dla
> MCU.

Kolega pewno mial to na mysli: https://www.mikroe.com/mikropascal/
- wbrew pozorom Pascal daje calkiem zwiezly i efektywny kod maszynowy i jesli ktos
koniecznie chce to zrobic - ale nie jest to ze tak powiem "mainstream" na MCU/DSP. W
tej chwili bardzo duza czesc oprogramowania na MCU/DSP jest pisana w Matlab/Simulink
i generowana do MISRA C na docelowy system. Ulatwia to anlize poprawnosci uzytych
algorytmow i zachowania systemu, zapewnia troche lepsza przenosnosc i generalnie
skraca czas projektu.

do góry

On Wed, 30 Aug 2017 07:42:57 -0700 (PDT), Adam M
<a...@m...com> wrote:
> Kolega pewno mial to na mysli:
> https://www.mikroe.com/mikropascal/

Bynajmniej. Zwykły Lazarus.

A Pythona da się używać z Arduino przez Firmata. Moim zdaniem jest to
bez sensu. Niemniej jednak.

do góry

On Wed, 30 Aug 2017 07:42:57 -0700 (PDT), Adam M
<a...@m...com> wrote:
> - wbrew pozorom Pascal daje calkiem zwiezly
> i efektywny kod maszynowy

Wbrew pozorom Pascal nie kompilował się od razu do kodu maszynowego,
ale do pośredniego. Trochę jak C# i Java.

do góry

On Wednesday, August 30, 2017 at 11:02:07 AM UTC-4, slawek wrote:
> On Wed, 30 Aug 2017 07:42:57 -0700 (PDT), Adam M
> <a...@m...com> wrote:
> > - wbrew pozorom Pascal daje calkiem zwiezly
> > i efektywny kod maszynowy
>
> Wbrew pozorom Pascal nie kompilował się od razu do kodu maszynowego,
> ale do pośredniego. Trochę jak C# i Java.

Chyba tylko UCSD Pascal (https://en.wikipedia.org/wiki/UCSD_Pascal) - czyżby kolega
mial doczynienia z komputerami Apple II - na nich UCSD Pascal byl bardzo popularny.
Wszytkie inne Pascale kompilowaly sie do kodu maszynowego (kompilacja i linkowanie
bibliotek). Najpopularnieszy w Polsce w latach 80tych Turbo Pascal kompilowal sie na
100% do kodu maszynowego.

do góry

Użytkownik "M.M." <m...@g...com> napisał:

> > W latach 90tych było inaczej. Kompilatory nie dość że kompilatory generowały
> > kiepski kod, to jeszcze nie umiały malutkich funkcji wstawiać inline.
> > Wszelkie próby napisać kodu przyjaznego dla kompilatora kończyły się
> >totalną sieczką z punktu programisty czytającego ten kod.
>
> ...kolejne mity...
> Bylo_dokladnie_ odwrotnie.
> To prosty zwykly kod byl przyjazniejszy dla kompilatora/optymalizatora.

> Żadne mity tylko dziesiątki albo nawet setki pomiarów czasów.
> Do czasów borlnad C++ w wersji około 5.0 - 6.0 (32bity) ja mam rację, potem Ty.

A tak. To racja. Tylko ze to jeszcze (fakt ze poznie) lata 80-te.
W 90tych bylo juz inaczej/lepiej.

> GCC i G++ był wtedy jeszcze gorszy.

Tez racja :)

> W VC++ było podobnie, dopiero gdzieś od wersji 6.0 generował akceptowalny kod.

_Dokladnie tak_ :) Przez MS C 6.0 bylo o wiele gorzej.

Ale.. ja wtedy tez uzywalem tez "innosci" typu NDP C/Zortech C i troche Watcom C
To bylo zupelnie inaczej. Llepiej - szczegolnie rodzina NDP Fortran/Pascal/C . Kod
wrecz
doskonaly, a poniewaz wspieral ona koprocesor Waitek wiec bilo toto na glowe wszytsko
inne nma PC.
Dla tego C im normalniejszy byl kod tym lepszy. Dla dosc Watcoma podobnie. Nie trzeba
bylo dbac o
sztuczki)

FYI: http://www.edm2.com/index.php/NDP_Fortran

AK

do góry

Uzupelnienie historyczne:
http://www.sai.msu.su/sal/F/1/NDP_FORTRAN.html

do góry

> Ciekawe skąd ten pomysł?!?

> Ja parę lat temu osobiście byłem na przesłuchaniu w sprawie pracy w wp.pl i tam
powiedzieli mi, że
> szukają gości do pisania w C demona rozproszonego na Linuxy do obsługi poczty. Parę
lat minęło,
> więc chyba już go skończyli... Z Onetem to nie wiem, ale jeśli chodzi o o2.pl to
połączyło się
> parę lat temu z wp.pl. Ale czy to oznacza, że teraz działa na tym co wp.pl - tego
nie wiem...

Tak, teraz dziala i w Onecie i w Wp i w setkach innych miejsc

PS:..trza umiec/sie znac..

AK

do góry

Użytkownik "M.M." <m...@g...com> napisał:

> Nigdy tego nie zauważyłem. Natomiast często widziałem, żę
>w starszych kompilatorach wystarczyło zamiast funkcji użyć
> makra i już kod był wyraźnie o parę procent szybszy.

Tak, bo one generowaly "rozbiegowki"
push bp
move pb, sp

sub sp, x
pop bp

czy to bylo potrzebne, czy nie.
(Na pewno tak robily stare/wymienione przez Ciebie wersje TC/BC++
i MS C)

> O zamianie operacji na tablicy na operacje wskaźnikach nie
> wspomnę

Tu sie mylisz.
W C juz w momencie kompilacji (a nawet w samym C - w wyrazeniach)
tablica jest zamieniana/a raczej traktowana jako wskaznik.

AK

do góry

Użytkownik "Adam M" <a...@m...com> napisał:

>No nie wiem - moze te pre procent przyspieszenia bylo potrzebne - moze nie -
[..]
> wszystko zalezy od potrzeb - czlowiek jest zawsze madrzejszy po fakcie.

I tak bylo w tym przypadku.

>
> > Na problem nad-optymalizacji C++ cierpia glownie programisci starszego pokolenia
>
>> Nieprawda, Jest dokladnie odwrotnie.
>> My starzy dobrzre wiemy ze prawdziwy handicap daje algorytm.
>> Top Wy mlodzi swiecie wierzycie w sprzet/procesor.paiec
>> My (a przynajmniej ja) starzy, rozwiazujac skomplikowana numeryke na takiej
>> Odrze1325 z 32kBslow dobrze wiedzielismy ze nie ma co liczyc na sprzet ale na
>> rozwiazanai/algorytmy/pomysly.

>Milo mi slyszec że naleze do tzw młodego pokolenia bo komputerami zajmuje się od
1982 ;-).

No coz. Wiec nie tylko pryszczaci :)

> Osobiscie nie mialem doczynienia z Odra (chociaz koledzy chwalili sobie ten system)
and pracowalem
> na MERA-300 i MERA-60 a pozniej na PDP-11, HP2000 i HP3000.

O !! Brawo. (300 nie tknalem, reszte tak).

> A co do obciazenia GHz i GB to programuje systemy czasu rzeczywistego (MCU i DSP)
na ktorych RAM
> mierzy sie KB
> (czasami 64KB RAM to wszysto)

To tyle co na calej Odrze 1325:) Calkiem spoko !

> i wiekszosc procesorow jest jedno-rdzeniowa (lub ma dodatkowe co-porocesory
wymagajace
> spcjalizowanego
> programowania w assemblerze) a predkosc mierzy sie w MHz - czasami 200MHz to juz
bardzo szybko.

Patrz moj post o Xenixie. Slowem to wcale nie tak malo :)

> Dodaktowo wymaganiem jest wysoka niezawodnosc oprogramowania - polecam poczytac
MISRA C i MISRA
> C++ standard.

Taaa. Koszmarek MISRA (zwana przez nas pieszczotliwie SZMIRA) zamiast chocby Ady.
Tak ten swiat zszedk na manowce.
PS: Ale ale ! Podobno gdzies w Aaustralli formamie dowuedli poprawnisci programi w C
(oczywiscie
Misra C:)
liczacego chyba z 1500 linii?
No pielknie! Za 1000 lat w tym tepie dorownaja mozlowosci Ady w tym temacie :))

>> Powiedz to Googlowi, Facebookowi (Tornado: https://pypi.python.org/pypi/tornado/).
> Nie wiem jak inni ale wydawalo mi sie ze Facebook uzywa wlasnego , wysoko
zoptymalizowanego PHP.

Hehe . Fakt. Wysoce zoptymalizowane PHP :) Fajnie brzmi ta legenda o PHP.

>> PS: Masz dokladnie 0-we pojecie o Pythonie. Errata. No nie., Jakies tam maasz - "z
prasy" :)
>
>Skoro ten Python jest taki dobry do wszystkiego i taki szybki to dlaczego nie
uswiadczysz go na
>MCU/DSP
> albo nawet na wiekszosci SOC (i prosze nie wyciągac mi tu Raspberry Pi - nikt
zdrowy na umysle i
> traktujacy swoich klientow powaznie nie uzyje RPi do zastosowan profesjonalnych -
dodatkowo jako
> test
> proponuje napisac program w Pythonie na RPi obslugujacy 8 do 16 portow szeregowch z
predkoscia
> transmisji 1.5MB na kazdym porcie i praktycznie ciaglym naplywem danych - a
nastepnie powtorzyc
> to cwiczenie w C++ lub C)

A co to za jakies badziewia/malenstwa ? Do czego toto w _normalnym_ programowaniu
potrezbne?
Jakas nisza anie ciekawa ani plodna. Slyszalem ze to takie nieprzyjemne ze
Hamerykanie i inni
zlecaja
toto pryszczatym w demoludach :) /no doobra, starym tez :))
PS: ..ale juz do do testowaaia tego badziewia Python jest stosowany od lat :)

Chlopie w 2005 systemy wbudowane to byly czesto w ASM (no dobram w czystym C
glownie:)
pisane w pelni autonomiczne micro-systemy operacyjne bo zaden Linux nei byl w stanie
sie zmiescic
a co dopiero dzialac. Po kilku latach nik juz nie pamietam ptawdziwego embedded:)
Za kila lat tez nikt juz nie bedzie sie martwik ze jakis Raspbery nie pociagnie.
Juz dzis Chinczycy w byle 1mm/1m zawiaraja tyle co jiedys na calej Odrze

PS: Tak, Zaczynalem na Odrze w 1976

PS: MicroPython tez sobie jest , a kiedys bedzie jeszcze bardziej :)
Normalna droga :) https://micropython.org/

Ale fakt ze czekam zeby ktos zrobil _dokladnie_ to samo z Pythonem
co V8 zrobilo z JS.
Zreszta droga wytyczona juz jest: patrz Julia
W samym Pythonie tez jest kilka bardzo dobrych rpzwiazan tego typu.
No ale ..trza sie znac.. :)

AK

do góry

Użytkownik "slawek" <f...@f...com> napisał:
> On Wed, 30 Aug 2017 07:09:02 -0700 (PDT), Adam M <a...@m...com> wrote:
>> Skoro ten Python jest taki dobry do wszystkiego
>> i taki szybki to dlaczego nie uswiadczysz go na
>> MCU/DSP albo nawet na wiekszosci SOC
>
> Przy 1kB SRAM to raczej nie doradzałbym Pythona.
>
> Ale ludzie dziwne rzeczy robią. Np. używają Delphi do pisania dla MCU.

Nawet w dosc badziewnym borlanowym C pisalo sie soft wbrywany
na malenstwa embedded.
PS: Oczywiscie bylo o wiele wiecej niz rzeczony 1kB RAM :)

AK

do góry