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