On Mon, 31 Jan 2011 15:30:22 +0100, Michoo wrote:
>W dniu 31.01.2011 15:11, Marcin Wasilewski pisze:
>>>> pierwszy projekt dobrze jest napisać w assemblerze, bo wtedy ma się
>>>> pojęcie o rzeczach, o których dłubacz kodu w C, nigdy nie będzie miał
>>>> pojęcia.
>>> Jak na przykład?
>>
>> Np. tak:
>> a) co jest zrzucane na stos i dlaczego w takiej kolejności,
>Jakie to ma znaczenie w kodzie C?

Mozna sie zastanowic nad glebokoscia wywolan, adresowaniem parametrow
itp.


>> b) że są rejestry w obszarze I/O i w ext. I/O, a w związku z tym sporo
>> inaczej je się obsługuje, w szczególności jeśli chodzi o operacje bitowe.
>Jakie to ma znaczenie w kodzie C, poza informacją, że porty mają
>możliwość ustawiania/gaszenia atomowo jednego bitu? (Co jest w
>dokumentacji.)

Bywaja niuanse ze jedne maja, inne nie maja, a jeszce inne maja gdzie
indziej.

Albo ze np nie ma posredniego adresowania I/O.

>> c) że czasami po zapisie do rejestru warto wstawić nop, zanim zaczniemy
>> go czytać.
>O co powinien zadbać kompilator.

W zasadzie tak.

>Tak samo jak o uporządkowany zapis do rejestrów 16b.

No i tu moze byc problem, bo rejestry specjalne moga wymagac
specjalnie, a dla zwyklej pamiec rzadko jest potrzeba zawsze blokowac
przerwania - ale czasem jest.

>> d) że pewne instrukcje działają wyłącznie na dedykowanych rejestrach,
>Jakie to ma znaczenie w kodzie C?

Sprawdzic czy kompilator o tym wie :-)

>> g) że znacznie lepiej mnożyć/dzielić przez 2, 4, 8 itd., niż przez 10.
>Dlaczego? Jeżeli procesor ma układ sprzętowego mnożenia to jest to jeden
>cykl różnicy.

No, tu faktycznie moze sie kompilator wykazac pomyslowoscia i
optymalizowac na rozne sposoby - nawet lepiej niz niedouczony
programista.

>Dzielenie przez stałą sensowny kompilator zamienia na
>mnożenie.

To mozliwe tylko dla zmiennego przecinka.

>> I wiele, wiele innych rzeczy o których w tej chwili nie pamiętam.
>I wiele, wiele innych rzeczy o których programista C _nie musi_ pamiętać.

Albo musi, i nie tylko pamietac, ale wiedziec jak to jest w procku, i
jak z tego skorzystac w C. Timery, komunikacja, przerwania ..

J.

do góry

> Albo musi, i nie tylko pamietac, ale wiedziec jak to jest w procku, i
> jak z tego skorzystac w C. Timery, komunikacja, przerwania ..

i to zapewne znajdzie w tej książce... EOT

do góry

W dniu 31.01.2011 16:38, J.F. pisze:
> On Mon, 31 Jan 2011 15:30:22 +0100, Michoo wrote:
>> W dniu 31.01.2011 15:11, Marcin Wasilewski pisze:
>>>>> pierwszy projekt dobrze jest napisać w assemblerze, bo wtedy ma się
>>>>> pojęcie o rzeczach, o których dłubacz kodu w C, nigdy nie będzie miał
>>>>> pojęcia.
>>>> Jak na przykład?
>>>
>>> Np. tak:
>>> a) co jest zrzucane na stos i dlaczego w takiej kolejności,
>> Jakie to ma znaczenie w kodzie C?
>
> Mozna sie zastanowic nad glebokoscia wywolan,
W tym celu trzeba sprawdzić w dokumentacji kompilatora co ląduje na
stosie przy danej konwencji wywołań.

> adresowaniem parametrow
Jakie to ma znaczenie w kodzie C?

>>> b) że są rejestry w obszarze I/O i w ext. I/O, a w związku z tym sporo
>>> inaczej je się obsługuje, w szczególności jeśli chodzi o operacje bitowe.
>> Jakie to ma znaczenie w kodzie C, poza informacją, że porty mają
>> możliwość ustawiania/gaszenia atomowo jednego bitu? (Co jest w
>> dokumentacji.)
>
> Bywaja niuanse ze jedne maja, inne nie maja, a jeszce inne maja gdzie
> indziej.
>
> Albo ze np nie ma posredniego adresowania I/O.
Ale to wynika z dokumentacji a nie ze znajomości asm. Można napisać w
assemblerze adresujący IO pośrednio i tak samo się zastanawiać dlaczego
nie działa.


>> Tak samo jak o uporządkowany zapis do rejestrów 16b.
>
> No i tu moze byc problem, bo rejestry specjalne moga wymagac
> specjalnie, a dla zwyklej pamiec rzadko jest potrzeba zawsze blokowac
> przerwania - ale czasem jest.
To jest w dokumentacji przy opisie rejestru. To czy blokować, czy nie
jest niezależne od tego czy asm czy c.

>> Dzielenie przez stałą sensowny kompilator zamienia na
>> mnożenie.
>
> To mozliwe tylko dla zmiennego przecinka.
Hasło:
Division by invariant integers using multiplication

>
>>> I wiele, wiele innych rzeczy o których w tej chwili nie pamiętam.
>> I wiele, wiele innych rzeczy o których programista C _nie musi_ pamiętać.
>
> Albo musi, i nie tylko pamietac, ale wiedziec jak to jest w procku, i
> jak z tego skorzystac w C. Timery, komunikacja, przerwania ..
Ale ja nie twierdzę, że nie trzeba wiedzieć co się robi, tylko, że
wiedza wynikająca z programowania w ASM nie jest konieczna.

P.S.
Pisanie na początku w asm potrafi zostawić brzydkie nawyki jak
przesunięcia binarne zamiast dzielenia, czy "optymalizację" liczników w
pętlach, które nie mają praktycznego znaczenia a zaciemniają kod. Imo
optymalizować należy jeżeli są problemy z wydajnością a nie "na zapas".

--
Pozdrawiam
Michoo

do góry

On Mon, 31 Jan 2011 18:00:48 +0100, Michoo wrote:
>W dniu 31.01.2011 16:38, J.F. pisze:
>>>> a) co jest zrzucane na stos i dlaczego w takiej kolejności,
>>> Jakie to ma znaczenie w kodzie C?
>> Mozna sie zastanowic nad glebokoscia wywolan,
>W tym celu trzeba sprawdzić w dokumentacji kompilatora co ląduje na
>stosie przy danej konwencji wywołań.

I w dokumentacji procesora jaki ten stos moze byc.

>> adresowaniem parametrow
>Jakie to ma znaczenie w kodzie C?

Na przyklad okresla co jest niemozliwe czy tez bardzo pracochlonne.
Pamietasz 51 z jej pamieciami ?

>> Albo ze np nie ma posredniego adresowania I/O.
>Ale to wynika z dokumentacji a nie ze znajomości asm. Można napisać w

Jak juz znasz dokumentacje na takim poziomie to znasz i asma

>assemblerze adresujący IO pośrednio i tak samo się zastanawiać dlaczego
>nie działa.

albo nie mozna, bo nie ma takiego rozkazu. Przy czym latwiej da sie
przeczytac w opisie konkretnej instrukcji niz sie zastanawiac o co
temu glupiemu kompilatorowi chodzi przy banalnej instrukcji
out(p,v).


>>> Tak samo jak o uporządkowany zapis do rejestrów 16b.
>> No i tu moze byc problem, bo rejestry specjalne moga wymagac
>> specjalnie, a dla zwyklej pamiec rzadko jest potrzeba zawsze blokowac
>> przerwania - ale czasem jest.
>To jest w dokumentacji przy opisie rejestru. To czy blokować, czy nie
>jest niezależne od tego czy asm czy c.

C moze to kompilowac inaczej niz myslisz.

>>> Dzielenie przez stałą sensowny kompilator zamienia na
>>> mnożenie.
>> To mozliwe tylko dla zmiennego przecinka.
>Hasło:
>Division by invariant integers using multiplication

O ile pamietam wyniki nie zawsze sa calkowicie zgodne.

>P.S.
>Pisanie na początku w asm potrafi zostawić brzydkie nawyki jak
>przesunięcia binarne zamiast dzielenia,

No, polemizowalbym nieco czy to brzydki nawyk.
Za to brak w C operacji "obrotu" bitow, i to juz jest czasem problem.

>czy "optymalizację" liczników w
>pętlach, które nie mają praktycznego znaczenia a zaciemniają kod. Imo
>optymalizować należy jeżeli są problemy z wydajnością a nie "na zapas".

Od procka zalezy, bo jak sie ma 16 rejestrow po 32 bit to sie pisze
fajnie, a jak trzy po 8 to kompilator musi sie bardzo mocno wykazac, a
i programista, zeby sie nie okazalo ze zapasu nie ma :-)

J.

do góry

Użytkownik "Michoo" <m...@v...pl> napisał w wiadomości
news:ii6h1t$djb$1@news.onet.pl...

>> a) co jest zrzucane na stos i dlaczego w takiej kolejności,
> Jakie to ma znaczenie w kodzie C?

Takie, że jak się pisze w C na scalaki typu Tiny13, które mają "aż" 64
bajty RAMu to się można zdziwić, jaką sieczkę odwala (a raczej odkłada na
stos) kompilator C wchodząc w przerwanie. A zasada jest prosta zrzuca się na
stos SR i używane w przerwaniu rejestry, a nie wszystko co się da na zapas
jak robi to kompilator C.

> Chyba, że się operuje na bitach... Poza tym jest to okropny styl pisania -
> komunikację z przerwaniami zawsze lepiej objąć w ATOMIC, bo inaczej łatwo
> o prosty błąd przy późniejszych przeróbkach kodu. (A koszt zazwyczaj
> pomijalny - 2 cykle +1 cykl opóźnienia.)

Tak, szczególnie jak masz np. 1K Flash-a i 64B ramu :)
Ale wtedy co robi programista w C? Zamiast ATtiny13, ładuje się ATtiny2313 i
problem rozwiązany.

>> g) że znacznie lepiej mnożyć/dzielić przez 2, 4, 8 itd., niż przez 10.
> Dlaczego? Jeżeli procesor ma układ sprzętowego mnożenia to jest to jeden
> cykl różnicy. Dzielenie przez stałą sensowny kompilator zamienia na
> mnożenie.

Po pierwsze zajmuje 2 takty samo mnożenie, ale jego wynik ląduje w
rejestrach R0/R1, co powoduje, że tracimy nast. kilka taktów aby je stamtąd
wydobyć. A przypominam, że R0-R15 są rejestrami w pewnym stopniu
upośledzonymi i nie wszystkie instrukcje dostępu do nich działają (np. ldi).
Rolowanie zajmuje jednak mniej.

>> I wiele, wiele innych rzeczy o których w tej chwili nie pamiętam.
> I wiele, wiele innych rzeczy o których programista C _nie musi_ pamiętać.

Do momentu jak mu się program "zesra", bo stos wlezie na zmienne.

Podsumowując - pisanie w C wymaga sporo mniej czasu, jednak pewne rzeczy
dostępne w asm od ręki C ma wyjątkowo upierdliwie rozwiązane (np. dostęp do
zmiennych w pamięci FLASH). Poza tym, jak ktoś zna assembler, to sobie ze
wstawkami w newralgicznych miejscach poradzi.

do góry

On 2011-01-31 20:39, Marcin Wasilewski wrote:
> Takie, że jak się pisze w C na scalaki typu Tiny13, które mają "aż" 64
> bajty RAMu to się można zdziwić, jaką sieczkę odwala (a raczej odkłada
> na stos) kompilator C wchodząc w przerwanie.

To bug w kompilatorze jeśli wrzuca za dużo. Nikt nie twierdzi ze avr-gcc
jest doskonały bo sam wiem że *za* dużo rejestrów używa w przerwaniach.

> a nie wszystko co się da
> na zapas jak robi to kompilator C.

Kompilator C tak nie robi. Tak robi tylko *zły* kompilator C.

> Tak, szczególnie jak masz np. 1K Flash-a i 64B ramu :)
> Ale wtedy co robi programista w C? Zamiast ATtiny13, ładuje się
> ATtiny2313 i problem rozwiązany.

I ma wiele racji. Dla $0.50 oszczędności per sztuka może sie okazać że
nie ma co robić rekodzieła w kodzie asm przez 4 miesiące aż się
*zmieścisz* co do bajta tylko od razu wziąść na zapas i program napisać
w dwa wieczory.

> Po pierwsze zajmuje 2 takty samo mnożenie

Jesli kompilator nie potrafi zamienić a *= 2; na operacje shift bitów to
jest marnym kompilatorem.

>> I wiele, wiele innych rzeczy o których programista C _nie musi_ pamiętać.
> Do momentu jak mu się program "zesra", bo stos wlezie na zmienne.

Zapewne asm jest tak magiczny że to się nie ma prawa popsuć w ten
sposób, nie?

> Podsumowując - pisanie w C wymaga sporo mniej czasu, jednak pewne rzeczy
> dostępne w asm od ręki C ma wyjątkowo upierdliwie rozwiązane (np. dostęp
> do zmiennych w pamięci FLASH).

To raczej brak supportu ze strony kompilatora. C nie ma nic do tego że
są jakieś rózne pamięci, choć było by miło gdyby miał.

> Poza tym, jak ktoś zna assembler, to
> sobie ze wstawkami w newralgicznych miejscach poradzi.

Rzecz w tym że:

a) niektórzy programisci starej daty w C piszą dokładnie tak samo jak w
asm (wlacznie z uzywaniem goto). Dla nich nie ma różnicy bo i tak nie
potrafia w gruncie rzeczy wykorzystać C.

b) niektórzy uważają że wstawką może być cały program.

Wiec jest kwestią zdrowego rozsądku sensownie to podzielić. Osobiście
jestem zdania że najlepszy jest podział 100% C++ i 0% asm.

do góry

> Tak, szczególnie jak masz np. 1K Flash-a i 64B ramu :)
> Ale wtedy co robi programista w C? Zamiast ATtiny13, ładuje się ATtiny2313
> i problem rozwiązany.

Rozwój informatyki w sprzęcie i oprogramowaniu śledzę od czasów ZX spectrum,
5051, Z1, ...

Zawsze zastanawiała mnie pewna sprawa.
Jeżeli program który chodził na kompie XT (procesor intel 86 , zegar coś
około 4 MHz) uruchomimu na
komputerze nowszej generacji ( AT - Intel 286) to wynik działania programu
otrzymamy relatywnie szybciej.

Biorąc pod uwagę postęp geometryczny w rozojwu sprzętu obecne komputery
klasy PC powinny śmigać w zastraszającym tempie.

Ale co ciekawe cały przyrost mocy obliczeniowej skutecznie konsumowany jest
przez rozdmuchane oprogramowanie zarówno systemowe jak i aplikacje.
Wiadom, że kiedyś programy były toporne i robiły jedynie to co się od nich
oczekiwało.
Teraz program musi się jakoś prezentować - nie wystarczy sam wynik obliczeń.
Liczy się forma przekazu.

Ale czasami wk...wia mnie do białości sytuacja gdy np instaluję drukarkę
gdzie sterowniki do niej zamieszczone są na dwóch płytach DVD.
Choć wiem, że wystarczą góra dwa pliczki dll + inf i po sprawie.
Ale zwykłemu userowi ciągle sprzedaje się kit, że tak ma być. Że instalacja
musi trwać 2 godziny, żę musi zainstalować sobie całe to gówno, że musi
podać dane osobowe swoje, szefa i strukturę produkcji firmy oraz obowiązkowo
zamówić oryginalne materiały eksploatacyjne.

Odbiegam od tematu ...
A chciałem tyko napisać o oprogramowaniu.
Patrząc na teorię oprogramowania i twory jakie trzeba póżniej eksploatować
często się bebechy gotują.
Najczęściej jest to niestety przerost formy nad treścią.

do góry

On 2011-01-31 21:13, kk wrote:
> Bior?c pod uwage postep geometryczny w rozojwu sprzetu obecne komputery
> klasy PC powinny ?migaae w zastraszaj?cym tempie.

Złożonośc rozwiązaywanych problemów również rośnie w zastraszającym tempie.

do góry

> Złożonośc rozwiązaywanych problemów również rośnie w zastraszającym
> tempie.

Głównym problemem jest jak namówić klienta do kupna czegoś co mu zupełnie do
niczego nie będzie potrzebne.

Machina sprzęt-oprogarmowanie jest samonapędliwa ( piszę tu o PC i
programach pod windows) tak jak biurokracja.
Z jednej strony postęp w sprzęcie, z drugiej oprogramowanie które zmusza do
kupowania co raz lepszego i mocniejszego sprzętu.
Widząc to co się dzieje uważam, że twórcy oprogramowania komercyjnego nie
wiedzą co to optymalizacja.
A pewnie świadomie tworzą potworki typu pakiety office czy kolejne wersje
przeglądarek Adobe Reader które poza tym, że są coraz większe objetościowo i
wymagają coraz lepszego sprzętu to właściwie nic nowego poza formą nie
wnoszą.

do góry

On 2011-01-31 16:38, J.F. wrote:
[.....]
> Albo musi, i nie tylko pamietac, ale wiedziec jak to jest w procku, i
> jak z tego skorzystac w C. Timery, komunikacja, przerwania ..
Tzn. rzeźbiarz w assemblerze nie musi wiedzieć takich rzeczy? :-)

Każdy programista systemowy musi mieć jakieś pojęcie o sprzęcie. I to
nie tylko o CPU/MCU ale również musi wiedzieć np. jak wygląda mapa
pamięci czy też w jaki sposób są podłączone i jak się komunikują z MCU
peryferia, np. jakiś RTC na I2C. Poza tym żaden programista systemowy
rzeźbiący w C dla MCU raczej nie uniknie chociażby szczątkowego kontaktu
z assemblerem. Natomiast rzeźbiarstwo w assemblerze "dla zasady"
najzwyczajniej w świecie nie jest uzasadnione ekonomicznie.

do góry