On 2011-01-31 22:34, Marcin Wasilewski wrote:
>>> 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?
> Ale jak piszesz w asm to z pewnością wiesz co to stos, tym bardziej, że
> sam musisz go sobie ustawić na RAMEND (lub tam gdzie ci wygodnie), bo
> nikt tego za Ciebie nie zrobi.

Podobnie jak pisanie w asm znakomicie rozwija umiejętnośc tworzenia
nastepnej implementacji fdiv która jak pierdyliard innych pisanych przez
całe stada assemblerowców jest spieprzona.

Jakość kodu nie wynika z pisania wszystkiego po swojemu a już na pewno
nie z pisania wszystkiego na nowo za każdym razem.

> Tak samo jak mogę sobie wpisać pod jakiś
> adres w RAM-ie (gdzie planowany jest koniec stosu) jakąś wartość i nawet
> podczas wykonywania programu sprawdzać, czy stos tego nie zamazał.

Zupełnie jak w C.

Oczywiście poza tym, że dzięki możliwości kompilacji kodu w C i
testowania go w środowisku PC można zdobyc tą i mase innych ważnych
informacji których nie sposób uzyskać mając do czynienia z kodem
natywnym na uC. O takich drobnostkach jak unit testy nie wspominam, bo
przecież assemblerowcy bez wątpienia mają jakieś własne, lepsze
rozwiązania zagadnień jakości i testowania kodu produkcyjnego, prawda?

> a jak nawet słyszał ten ktoś magiczną nazwę "stos", to ma
> mgliste pojęcie jak działa.

W każdym języku programowania można spotkać ignorantów, ludzi z
doświadczeniem w Basicu/Delphi czy zwykłych idiotów. Co z tego?

do góry

W dniu 2011-01-31 13:25 Piotr Gałka napisał(a):

>> Po drugie C (avr-gcc) udostępnia ładne makro po którym od razu widać,
>> że w tym miejscu zachodzi synchronizacja:
>> ATOMIC_BLOCK(ATOMIC_FORCEON)
>> {
>> flags |= 0b00001001;
>> }
[...]
> Tak z czystej ciekawości:
> Czy takie makro patrzy co jest w jego wnętrzu i albo blokuje przerwania,
> albo nie (jeśli wnętrze z natury jest operacją atomową) ?

Nie, nie "patrzy". Blokuje przerwania na początku a na końcu odblokowuje
(w tej postaci ATOMIC_FORCEON). Jest też bardziej pożyteczna wersja,
która przywraca stan przerwań sprzed zablokowania - można takie kawałki
bez stresu używać wtedy w przerwaniach.

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

do góry

Użytkownik "Adam Dybkowski" <a...@4...pl> napisał w wiadomości
news:iiab1p$7in$1@news.onet.pl...
>
> Nie, nie "patrzy". Blokuje przerwania na początku a na końcu odblokowuje
> (w tej postaci ATOMIC_FORCEON). Jest też bardziej pożyteczna wersja, która
> przywraca stan przerwań sprzed zablokowania - można takie kawałki bez
> stresu używać wtedy w przerwaniach.
>
Wiem, że nic nie wiem, no i tego nie rozumiem.
Przecież jeśli zablokuje przerwania to stan się w czasie gdy są zablokowane
nie zmieni więc co tu przywracać.
Czego nie chwytam ?
P.G.

do góry

W dniu 2011-02-02 09:24, Piotr Gałka pisze:
>
> Użytkownik "Adam Dybkowski" <a...@4...pl> napisał w wiadomości
> news:iiab1p$7in$1@news.onet.pl...
>>
>> Nie, nie "patrzy". Blokuje przerwania na początku a na końcu
>> odblokowuje (w tej postaci ATOMIC_FORCEON). Jest też bardziej
>> pożyteczna wersja, która przywraca stan przerwań sprzed zablokowania -
>> można takie kawałki bez stresu używać wtedy w przerwaniach.
>>
> Wiem, że nic nie wiem, no i tego nie rozumiem.
> Przecież jeśli zablokuje przerwania to stan się w czasie gdy są
> zablokowane nie zmieni więc co tu przywracać.
> Czego nie chwytam ?

Wychodzisz z błędnego założenia, że ten fragment kodu zaczyna się zawsze
przy włączonych przerwaniach, więc po zakończeniu blokady możesz je
znowu włączyć (zamiast przywrócić stan poprzedni).

do góry

Dnia 01-02-2011 o 22:13:57 4CX250 <t...@p...onet.pl> napisał(a):

>
> Użytkownik "janusz_kk1" <j...@o...pl> napisał w wiadomości
> news:op.vp8ouirl1cvm6g@jk-laptop...
>
>> Ale asm to nie kompilator tylko translator który zapis mnemoniczny
>> przekłada na kod,
>
> Wiesz co, nie wiedziałem... Nawet nie wiedziałem że w 1991 roku w
> paskalu napisałem sobie translator na 8085 :)
A robił on coś więcej? bo jak nie to był tylko translatorem.
Poczytaj jak jest zbudowany GCC, IMHO on ma trzy moduły,analizator składni
i prekompilator,
właściwy kompilator z optymalizacją i moduł translacji na kod maszynowy z
linkierem.
Trzeci moduł jest dostosowany do listy rozkazów procka dzięki czemu GCC
jest uniwersalne
i kompiluje od 51 po pic-a. To Tak w dużym skrócie.

--
Pozdr
JanuszK

do góry

On Wed, 02 Feb 2011 11:07:06 +0100, janusz_kk1 wrote:
>> Wiesz co, nie wiedziałem... Nawet nie wiedziałem że w 1991 roku w
>> paskalu napisałem sobie translator na 8085 :)
>A robił on coś więcej? bo jak nie to był tylko translatorem.
>Poczytaj jak jest zbudowany GCC, IMHO on ma trzy moduły,analizator składni
>i prekompilator,
>właściwy kompilator z optymalizacją i moduł translacji na kod maszynowy z
>linkierem.
>Trzeci moduł jest dostosowany do listy rozkazów procka dzięki czemu GCC
>jest uniwersalne i kompiluje od 51 po pic-a. To Tak w dużym skrócie.

Architekture musisz uwzglednic juz na etapie kompilacji.
I optymalizacji tez.

J.

do góry

Użytkownik "janusz_kk1" <j...@o...pl> napisał w wiadomości
news:op.vp9s140z1cvm6g@jk-laptop...

>A robił on coś więcej? bo jak nie to był tylko translatorem.
>Poczytaj jak jest zbudowany GCC, IMHO on ma trzy moduły,analizator składni
>i prekompilator,
>właściwy kompilator z optymalizacją i moduł translacji na kod maszynowy z
>linkierem.
>Trzeci moduł jest dostosowany do listy rozkazów procka dzięki czemu GCC
>jest uniwersalne
>i kompiluje od 51 po pic-a. To Tak w dużym skrócie.

Uśmieszków moich nie dostrzegłeś :)
Chodziło mi tylko o to że gcc nie ma szans obliczyć głębokości stosu jeżeli
będziemy zmieniali wartośc wskaźnika SP programowo. Tak ironizowałem tylko.

Marek

do góry

Użytkownik "J.F." <j...@p...onet.pl> napisał w wiadomości
news:t3dik6lu6hjn6doh73rcl94j8vs48eol8l@4ax.com...
> Architekture musisz uwzglednic juz na etapie kompilacji.
> I optymalizacji tez.


I tego nie da się nijak programowo załatwić choćby nie wiadomo jaki był
uniwersalny ten gcc.

Wystarczy też małe potknięcie programisty np. włączenie fuse bitu
kompatybilności 103 w atmega 128 i żaden gcc nie wykryje błędu. Okaże się że
pamięć za krótka i stos mamy na zmiennych i dodatkowo nie ma fiuczerów które
sa tylko w 128 a które chce nasz program wykorzystać.


Marek

do góry

On Wed, 2 Feb 2011 12:22:00 +0100, 4CX250 wrote:
>Użytkownik "J.F." <j...@p...onet.pl> napisał w wiadomości
>> Architekture musisz uwzglednic juz na etapie kompilacji.
>> I optymalizacji tez.
>
>I tego nie da się nijak programowo załatwić choćby nie wiadomo jaki był
>uniwersalny ten gcc.

Java i .Net jakby to obchodza.

>Wystarczy też małe potknięcie programisty np. włączenie fuse bitu
>kompatybilności 103 w atmega 128 i żaden gcc nie wykryje błędu. Okaże się że
>pamięć za krótka i stos mamy na zmiennych i dodatkowo nie ma fiuczerów które
>sa tylko w 128 a które chce nasz program wykorzystać.

Mozna sie upierac ze C powinien to sobie ustawiac sam :-)

J.

do góry

W dniu 02.02.2011 11:07, janusz_kk1 pisze:
> Trzeci moduł jest dostosowany do listy rozkazów procka dzięki czemu GCC
> jest uniwersalne
> i kompiluje od 51 po pic-a.
Pudło. Ich budowa jest tak 'inna', że na te architektury nie ma portu gcc.

Dzięki temu mogłem poznać rozkosze używania SDCC - np operuje się na
liczbach zmiennoprzecinkowych, kod się kompiluje. Dopiero po
sformatowaniu go przez printf i wyświetleniu na LCD widać napis
informujący o braku jednostki zmiennoprzecinkowej. ;)

--
Pozdrawiam
Michoo

do góry