Problemy z C++ (GNU ARM)

May 15, 2008 26 Replies

Nie powinien, chyba ze warningiem.

Warunek kontynuacji jest prosty - i<30.25, oczywiscie ((float)i)<30.25, czy nawet ((double) i)) <30.25d

I dokladnie tak ma dzialac jak zapisane :-)

J.

ach to C - w Pascalu musi byæ ca³kowity :)

AK

Bo u Witha petla to petla, a w C to tylko skomasowany sposob zapisu while .. :-)

J.

In the darkest hour on Thu, 15 May 2008 21:57:44 +0200, Sebastian Bialy snipped-for-privacy@poczta.onet.pl> screamed:

Ja najmilej wspominam 6502.

O też miło wspominam 6502 [Atari rulez :]. Tylko ilośc rejetrów w tym wynalazku niebezpiecznie zbliżała się do 0. Stąd pewno pomysły "strona zerowa" itd. Potem po latach podobny potwór koncepcyjny straszył mnie z x86. Co gorsza straszy do dzisiaj, tylko teraz odpicowany dla niepoznaki.

Konop przemówił ludzkim głosem:

^^^^ Brakuje d_time na liście parametrów wyjściowych - gcc domyślnie uznaje, że parametry wejściowe wstawek asemblerowych nie są niszczone. Jak wstawisz po sobie dwa opóźnienia to się możesz zdziwić :-) Warto także dodać do funkcji __attribute__((always_inline)), inaczej przy wyłączonej optymalizacji funkcja może nie być inline'owana.

Taka wstawka powinna pomóc: asm volatile(".error \"Opoznienie nie jest stale\"");

W artykule snipped-for-privacy@4ax.com J.F napisal(a):

Można rzutować:

#define us(t) ((int)(30.25*(t)+0.5)) ^ zaokrąglenie

AFAIR nawet jeśli w wyrażeniu stałym jest rzutowanie, kompilator ma prawo (ale nie obowiązek) obliczyć jego wartość i wstawić do kodu wynikowego pojedyczą stałą.

avr-gcc (20070525) przelicza podczas kompilacji us(10) na stałą 303.

BTW warto dać dodatkowe nawiasy wokół parametru; przydadzą się, jeśli użyjemy us z wyrażeniem:

us(1+time)

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required