Robotrontechnik-Forum

Registrieren || Einloggen || Hilfe/FAQ || Suche || Mitglieder || Home || Statistik || Kalender || Admins Willkommen Gast! RSS

Robotrontechnik-Forum » Technische Diskussionen » P8000 lcc... » Themenansicht

Autor Thread - Seiten: -1-
000
10.07.2009, 21:37 Uhr
holm

Avatar von holm

Gibts bei dem Ding einen Trick für Floatingpoint?


cc -o h h.c -lm
#228 ./h
Pi: 3.141593
#229 lcc -o h h.c -lm
#230 ./h
Pi: 0.000000
#231 cat h.c
#include <stdio.h>
#include <math.h>
main()
{
float pi;
pi=4*atan(1);
printf("Pi: %f\n",pi);
}
#232

oder ist der übersetzte Compiler defekt?
Gruß,

Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
001
10.07.2009, 22:01 Uhr
Olli

Avatar von Olli

Scheint in der Tat etwas mit der libmath im argen zu sein


Quellcode:
#12 cc h.c -lm
#13 ./a.out
Pi: 3.141593
#14 lcc h.c -lm
lcc: Command not found.
#15 source /.cshrc
#16 !14
lcc h.c -lm
#17 ./a.out
Pi: 0.000000
#18

Habe noch ne andere Llibm.a von nem aelteren lcc - evtl funzt die - ansonsten muesste man sich mal die Implementierung von atan() anschauen? Waren ja schon einige Fehler im Code die ich schon gefunden habe....

EDIT: alte Llibm.a aendert auch nichts an dem Verhalten.
--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000

Dieser Beitrag wurde am 10.07.2009 um 22:08 Uhr von Olli editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
002
10.07.2009, 22:07 Uhr
holm

Avatar von holm

...grmbl....grmpg..:-(


Gruß,

Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
003
10.07.2009, 22:09 Uhr
Olli

Avatar von Olli

Naja, was meinst du wie schoen es ist Fehler im Compiler oder einer lib zu suchen - ich such mal - bis meine Freundin bruellt ich soll endlich ins Bett kommen
--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
004
10.07.2009, 22:53 Uhr
Olli

Avatar von Olli

So - Fehler gefunden.
Irgendwie scheint er nicht int nach double casten zu wollen oder zu koennen. Wenn man Ihm etwas unter die Arme greift geht es. Achja - und float mag er auch nicht - ist ja nicht umsonst als double atan(double) deklariert

#include <stdio.h>
#include <math.h>
main()
{
double pi;
pi=4*atan((double)1);
printf("Pi: %f\n",pi);
}


#104 !-2
lcc h.c -lm ; ./a.out
Pi: 3.141593

Aber frag mich jetzt nicht, wiso er nicht autom. castet... naja - erstmal ins Bett wandern fuer heute.
--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000

Dieser Beitrag wurde am 10.07.2009 um 22:54 Uhr von Olli editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
005
11.07.2009, 09:06 Uhr
holm

Avatar von holm

Hmm, mit dem Compiler wird das Programmieren etwas kompliziert, der ist noch sehr jung...



Quellcode:
#include <stdio.h>
#include <math.h>

main()
{

double pi;
int i;

pi=4*atan(1.0);
printf("pi=%f\n",pi);

for(i=0;i<360;i++)
        printf("Grad: %3d, Sinus: %f\n",
                i,sin(((double)i * pi) / (double) 180.0));
}


und dann ..


Quellcode:
...
Grad: 329, Sinus: -0.515038
Grad: 330, Sinus: cvtdl: integer overflow: Result too large
-0.500000
Grad: 331, Sinus: -0.484810
Grad: 332, Sinus: -0.469472
...

Das Selbe bei 210 Grad, auch -0.5 als Ergebnis.

Welcher Integer läuft hier über?


Mal ganz abgesehen davon:

#57 /bin/time ./holm >sinlist
1.76u 33.40s 0:35 100%
#58 lcc -O -o lholm holm.c -lm
#59 /bin/time ./lholm >lsinlist
cvtdl: integer overflow: Result too large
cvtdl: integer overflow: Result too large
107.70u 0.50s 1:50 98%
#60

(das Erste ist mit dem Systemcompiler übersetzt)

Gruß,

Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Dieser Beitrag wurde am 11.07.2009 um 09:14 Uhr von holm editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
006
11.07.2009, 09:24 Uhr
Olli

Avatar von Olli

Ja - der vom lcc erzeugte code ist nicht wirklich schnell - aber er erzeugt auch immer segmentierten code (also als Pedant zu dem scc - nicht cc ) Und sein Sprachumfang ist halt groesser - und er hat auch nicht so Limitierungen wie "#define ABCDE - dort darf ABCDE unr 32 Zeichen lang sein" - sowas in der Art existiert naemlich beim Systemcompiler - und du wunderst dich dann nur wiso er bei

#define FOOBARP8000EAWROBOTRONWASWEISICH1 1
#define FOOBARP8000EAWROBOTRONWASWEISICH2 2

beim 2. ein "redefinition" warning kommt

Wenn du die Sourcen zum Systemcompiler hast nehme ich die auch gerne.....
--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
007
11.07.2009, 09:32 Uhr
holm

Avatar von holm

Hmm, das mit dem Redefining ist ein Präprozessor Problem, da sollte sich eigentlich ein Anderer anflanschen lassen...


#67 /bin/time ./sholm >ssinlist
1.66u 38.3s 0:40 99%
(scc)

Gruß,

Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Dieser Beitrag wurde am 11.07.2009 um 09:35 Uhr von holm editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
008
11.07.2009, 09:38 Uhr
Olli

Avatar von Olli

Jo - der Systemcompiler ist grundsaetzlich schneller.... Die von beiden Compiliern (scc, lcc) erzeugten ASM Listings unterscheiden sich auch nahezu grundsaetzlich...

Ich hatte mal mit dem Gedanken gespielt, einen aktuellen PCC zu nehmen und dem Z8001 Support einzuhauchen basierend auf den LCC Quellen (was ja auch nichts anderes als der Ur-PCC ist) - aber - das stellt sich fuer mich als zu kompliziert da - dafuer reichte dann mein Durchblick auch wieder nicht aus
--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000

Dieser Beitrag wurde am 11.07.2009 um 09:40 Uhr von Olli editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
Seiten: -1-     [ Technische Diskussionen ]  



Robotrontechnik-Forum

powered by ThWboard 3 Beta 2.84-php5
© by Paul Baecher & Felix Gonschorek