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.
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)
Have something to add? Share your thoughts — no account required.
Ask the community — no account required