|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Programmierung > Mein erstes C Programm will nicht | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| 1 -2- 3 | [ - Beitrag schreiben - ] |
|
18.10.2005, 16:42 Uhr gni Posts: 1106 Nutzer |
Zitat:Dann fehlt dem von Dir benutzten printf ein Feature. [ Dieser Beitrag wurde von gni am 18.10.2005 um 16:43 Uhr editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
18.10.2005, 18:18 Uhr Solar Posts: 3680 Nutzer |
Mit dem Standard-printf() Parameter out-of-order ausgeben? Sorry, aber auch ich wüßte nicht wie... [ - Antworten - Zitieren - Direktlink - ] |
|
18.10.2005, 18:56 Uhr MaikG Posts: 5172 Nutzer |
>Da würde ich mich nicht weiter drüber wundern. >Probier's mal mit memset( x, 255, size ) statt einer >selbst programmierten Schleife... Nur weil C ja viel schneller als Basic sein soll. Okay, ich werd mal die Funktion suchen. [ - Antworten - Zitieren - Direktlink - ] |
|
18.10.2005, 19:25 Uhr Holger Posts: 8116 Nutzer |
Zitat:Ja, wenn wir das vorher gewußt hätten... Damit erübrigt sich auch die Diskussion, ob man printf oder Printf benutzen soll. printf liegt in der libc, formatiert also mittel ppc, Printf benutzt den 68k-code des AmigaOS... Zitat:Eben. Zitat:Wenn nicht gerade die eine Funktion die Argumente aus einem ppc-Stack in einen 68k-Stack kopieren muß... Dann ist ein manuelles Kopieren in ein array schneller, weil es mittels pointer an VPrintf ohne erneutes Kopieren übergeben werden kann, allerdings ist es dann natürlich noch schneller, einfach printf zu benutzen, dann wird mit ppc formatiert und nur ein Pointer auf const char übergeben. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
18.10.2005, 19:40 Uhr Holger Posts: 8116 Nutzer |
Zitat: Solche Schleifen sind ja keine typischen Anwendungsfälle. Aber Du kannst auch versuchen, mit 8-byte statt 4-byte Zugriffen zu arbeiten oder mal nach den Optimierungsoptionen von vbcc nachschlagen. Wobei ich keine Vorstellung habe, wo sich vbcc im Vegleich mit anderen Compiler einreiht. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
18.10.2005, 19:45 Uhr Holger Posts: 8116 Nutzer |
Zitat:Wenn die locale.library geladen wurde. Es ist ziemlich schlechter Programmierstil, von dieser Funktionalität auszugehen, wenn man die locale.library nicht selber öffnet. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
18.10.2005, 19:56 Uhr Holger Posts: 8116 Nutzer |
Zitat:Deine, offenbar: Zitat:  mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
18.10.2005, 23:10 Uhr MaikG Posts: 5172 Nutzer |
>memset( x, 255, size ) Diese Funktion finde ich in keiner Library, hab davon auch noch nie gehört... >Solche Schleifen sind ja keine typischen Anwendungsfälle. >Aber Du kannst auch versuchen, mit 8-byte statt 4-byte >Zugriffen zu arbeiten oder mal nach den >Optimierungsoptionen von vbcc nachschlagen. 8-Byte was ist das dann? Ich dachte das maximum ist Long- Gibts nicht nur Int(F) Word(FF) und Longword(FFFF)? Übrigens sind es 42 MB/s hab vergessen mal 2 zu rechnen, das Programm schreibt ja nicht nur sondern liesst auch aus. [ - Antworten - Zitieren - Direktlink - ] |
|
19.10.2005, 02:07 Uhr obw Posts: 94 Nutzer |
@MaikG: > memset( x, 255, size ) > Diese Funktion finde ich in keiner Library Kein Wunder, denn sie gehört zur Sprache C. Ist in der Standardbibliothek. > 8-Byte was ist das dann? Ich dachte das maximum ist Long > Gibts nicht nur Int(F) Word(FF) und Longword(FFFF)? Uh... nein. Der PPC 60x ist ein Prozessor mit teilweise 64bit-Strukturen. So sind 64bit-aligned Speicherzugriffe schneller. Man kann auch 128- oder 256-bit alignen, wenn man will.  Und IEEE doubles sind glaub ich schon bei 680x0 64bit-aligned. Ich bin da aber kein Experte und überhaupt ist es schon spät, also kann alles, was ich hier erzähle, auch großer Mist sein.  Und 8 bit sind ein char oder (U)BYTE, kein int. int ist die natürliche Integergröße des Systems, auf dem man übersetzt. Auf AmigaOS m680x0 sind int BTW 32 bit, also das, was du als longword bezeichnest. Die von dir verwendete Zuordnung wäre auf einem C64 korrekt, der hat eine 8 bit-CPU. (und überhaupt fehlt da immer noch die andere Hälfte eines Bytes, wie mir gerade auffällt.) > das Programm schreibt ja nicht nur sondern liesst auch aus. Daß diese Geschwindigkeiten nicht wirklich identisch sind, das ist dir aber klar, oder? OBW [ - Antworten - Zitieren - Direktlink - ] |
|
19.10.2005, 08:39 Uhr Solar Posts: 3680 Nutzer |
Zitat: Wie obw schon sagte, eine Standard-C-Funktion. Eine sehr gute Dokumentation der Standardlib gibt's online unter http://www.dinkumware.com. Ich bin eigentlich der Meinung, das man die Standard-Lib lernen sollte, bevor man sich an irgendeine OS-API macht - das System mag sich ändern, die Standard-Lib gibt's immer und überall. Zitat: C ist nicht Basic. C kennt char, short, int, long und (ab C99) long long. Wie "breit" diese Typen auf einem konkreten System sind, hängt vom System ab; "int" ist in der Regel der "native", also am schnellsten behandelte Typ. Es können mehrere dieser Typen die gleiche "Breite" bezeichnen; bei 32bit-Systemen sind das in der Regel (aber nicht immer!) "int" und "long", die beide 32bit "breit" sind. [ - Antworten - Zitieren - Direktlink - ] |
|
19.10.2005, 09:41 Uhr gni Posts: 1106 Nutzer |
Zitat:...was auf Grund des Kontextswitches wohl keinen Unterschied macht. Zitat:Dieses Problem gibt es bei WOS nicht, da H&P dessen ABI an dieser Stelle modifiziert hat, dh. Amiga/68k-like gemacht hat ;-) Und auch beim SYSV-ABI gibt es seit langem eine Amiga-Lösung: __varargs68k (MOS) bzw __linearvarargs (OS4). Diese Attribute funktionieren auch für PowerUp.Zitat:Wenn nicht gerade die eine Funktion die Argumente aus einem ppc-Stack in einen 68k-Stack kopieren muß... [ - Antworten - Zitieren - Direktlink - ] |
|
19.10.2005, 10:21 Uhr MaikG Posts: 5172 Nutzer |
>Und 8 bit sind ein char oder (U)BYTE, kein int. int ist >die natürliche Integergröße des Systems, auf dem man übersetzt. Auf AmigaOS m680x0 sind int BTW 32 bit, also das, was du als longword bezeichnest. Okay wie definiere ich dieses Variablen also das Maximale und wieviel F's passen da rein. Ich hab meistens mit Dezimalwerten gearbeitet, in MBasic ist Integer bis 3xxxx. >Daß diese Geschwindigkeiten nicht wirklich identisch sind, >das ist dir aber klar, oder? Ja, das ergebniss ist der durschnittliche Speicherdurchsatz, ohne rücksicht auf Lesen/Schreiben. >Wie obw schon sagte, eine Standard-C-Funktion. Eine >sehr gute Dokumentation der Standardlib gibt's online >unter dinkumware.com. Ich bin eigentlich der Meinung, >das man die Standard-Lib lernen sollte, bevor man >sich an irgendeine OS-API macht - das System mag sich >ändern, die Standard-Lib gibt's immer und überall. Die OS-Funktionen kenne ich ja schon von Basic her, die Standart-Lib ist also ganz was neues für mich. Ich guck mir das mal an. [ - Antworten - Zitieren - Direktlink - ] |
|
19.10.2005, 10:35 Uhr Solar Posts: 3680 Nutzer |
Zitat: Wenn Dein Compiler kein C99 kann, machst Du das mit long x; Den maximal möglichen Wert findest Du in <limits.h>: Dort werden u.a. die Präprozessor-Konstanten LONG_MAX, LONG_MIN und ULONG_MAX definiert. Unterstützt Dein Compiler C99, dann kannst Du <stdint.h> includen; dort werden u.a. die Typen intmax_t und uintmax_t definiert, die jeweils "breitesten" unterstützten Integer-Typen, sowie INTMAX_MAX, INTMAX_MIN, und UINTMAX_MAX. [ - Antworten - Zitieren - Direktlink - ] |
|
19.10.2005, 11:38 Uhr MaikG Posts: 5172 Nutzer |
Also memset geht mit (x,0xF0,size) mit FF nicht. Memset ist allerdings kein bisschen schneller als die Schleife. >0xF0F0F0F0 Wenn das FFFF entspricht sind das nur 65535 in Dec. Oder ist das wirklich F0F0F0F0? Ich wollte ja nur 1sen in den Speicher schreiben oder jedes Char auf F. [ - Antworten - Zitieren - Direktlink - ] |
|
19.10.2005, 12:23 Uhr tokai Posts: 1071 Nutzer |
@MaikG: Es gibt ram fehler bei den die bits zu 1 schalten.. und andere bei den sie zurück zu 0 schalten. mit 0xF0F0F0F0 ist die wahrscheinlichkeit etwas höher 0-Fehler abzufangen. Wenn du es aber wirklich richtig machen willst, dann musst du mit 0xFFFFFFFF und 0x00000000 und am besten auch noch mit diversen pattern wie: 0xF0F0F0F0 0x0F0F0F0F etc. testen.. und am besten nach dem Speicher füllen noch einen kleinen Delay einbauen. Manchmal schaltet so ein Bit erst nach einer kurzen Zeit zurück, wenn es fehlerhaft sein sollte. Das ganze solltest Du auch noch zwischen Forbid() und Permit() packen (damit schaltest Du das Multitasking aus und vermeidest, dass ein wildgewordenes Program das Pattern in der Zwischenzeit zerstört und somit Fehler erzeugt). Und nochwas: zum RAM-Speed messen ist ein solches Program nicht geeignet. Da musst Du schon wesentlich mehr Daten wiederholt - unter möglicher Umgehung des CPU-eigenen Caches - einfüllen um ein genaueres Testergebnis zu bekommen. regards, tokai -- http://www.christianrosentreter.com ~ MorphOS Software [ - Antworten - Zitieren - Direktlink - ] |
|
19.10.2005, 12:24 Uhr Solar Posts: 3680 Nutzer |
Zitat: ??? Zitat: Dann ist Deine einzige Chance, noch mehr rauszuholen, handgeschriebenes Assembler. Du stoppst aber schon von Eintritt in die Schleife bis zum Ausgang? Das Laden und Starten des Executables darfst Du nicht mitstoppen, ebensowenig die Zeit, die irgendwelche Ausgaben verbraten. Zitat: Wie könnte es? 0xF0F0F0F0 ist etwas anderes als 0xFFFF... Zitat: Also 0xFFFFFFFF. [ Dieser Beitrag wurde von Solar am 19.10.2005 um 12:25 Uhr editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
19.10.2005, 16:31 Uhr Gazelle Posts: 151 Nutzer |
@MaikG: > ... jedes Char auf F Ich bin mir nicht so sicher, aber es scheint, du bist mit Hex-Zahlen nicht so vertraut, deshalb eine kurze Erklärung: Ein Char (unsigned) entspricht einem Byte, also 8 Bit. Dezimal bedeutet dass von 0 bis 255 oder in Hex eben von 0x00 bis 0xFF. Ein Byte besteht also immer aus einer zweistelligen Hex-Zahl (sofern man führende Nullen mitschreibt). Eine Binäre Zahl kann man sehr leicht ins Hex übertragen: Aus den 8 Bits einfach zwei Nibble (zu 4 Bit) machen, ein Nibble entspricht dann genau einer Hex-Stelle. zB: 1. 01101010 2. 0110 1010 3. 0110 => 8*0 + 4*1 + 2*1 + 1*0 = 4+2 = 6 4. 1010 => 8*1 + 4*0 + 2*1 + 1*0 = 8+2 = 10 => A 5. 01101010 => 0x6A hth, Bernd [ - Antworten - Zitieren - Direktlink - ] |
|
19.10.2005, 17:15 Uhr MaikG Posts: 5172 Nutzer |
>Es gibt ram fehler bei den die bits zu 1 schalten.. >und andere bei den sie zurück zu 0 schalten. Ich weiss, ich hab diverse Muster ins Programm eingefügt. >mit 0xF0F0F0F0 ist die wahrscheinlichkeit etwas höher >0-Fehler abzufangen. Also hat das mit den 4er Schritten nichts zu tun und es Müsste 0xFFFFFFFF heissen richtig? >Dann ist Deine einzige Chance, noch mehr rauszuholen, >handgeschriebenes Assembler. kann memset auch mit mehr als FF umgehen? Eine echte C-Funktionen bescheibung hab ich auf der Seite nicht gefunden. >Du stoppst aber schon von Eintritt in die Schleife bis >zum Ausgang? Das Laden und Starten des Executables >darfst Du nicht mitstoppen, ebensowenig die Zeit, die >irgendwelche Ausgaben verbraten. Ich hab mittlerweile die Intuition Funktionen für das Zeitstoppen ohne Laden also. >Wie könnte es? 0xF0F0F0F0 ist etwas anderes als 0xFFFF... Mein erstes Programm sollte ja 255 überall reinschreiben was ja FFFFFFF... ist, ich dachte die Nullen sind für die 4er schritte. >Ich bin mir nicht so sicher, aber es scheint, du bist >mit Hex-Zahlen nicht so vertraut, deshalb eine kurze >Erklärung: Schon aber nicht in zusammenhang mit C. [ - Antworten - Zitieren - Direktlink - ] |
|
19.10.2005, 18:24 Uhr obw Posts: 94 Nutzer |
Zitat: Würde ich weniger nehmen. Stattdessen 0x55555555 0xAAAAAAAA 0x5 ist %0101 und 0xA %1010. Damit setzt man maximal unterschiedliche Bits. Am besten abwechselnd, um auch Fehlverhalten des Systembusses festzustellen. Zitat: Das sowieso. Der Programmierer von memtest86 wußte schon, warum er das ganze ohne OS laufen läßt.  Nicht zu vergessen Cache ausschalten, sonst benchmarkt man evtl. nur die interne CPU-Geschwindigkeit.OBW [ - Antworten - Zitieren - Direktlink - ] |
|
19.10.2005, 18:31 Uhr obw Posts: 94 Nutzer |
Zitat: Nö, er könnte mittels Duff's Device auf Cachelines alignen. Das sollte maximal schnell sein. *d&r* (Jaja, ich weiß, als Erklärung für Anfänger nicht wirklich hilfreich)  [ - Antworten - Zitieren - Direktlink - ] |
|
19.10.2005, 18:42 Uhr obw Posts: 94 Nutzer |
Zitat: Finde ich auch spontan nicht, aber hier ein wertvoller[TM] Tipp: Gerade bei sowas wie Bibliotheksfunktionen hilft es weiter, wenn man den Namen einfach in Google wirft -> voilá, massig Doku (Jetzt nicht gerade der Provider memset.com, aber der ganze Rest)[ - Antworten - Zitieren - Direktlink - ] |
|
19.10.2005, 18:48 Uhr MaikG Posts: 5172 Nutzer |
>Würde ich weniger nehmen. Stattdessen >0x55555555 >0xAAAAAAAA Wie gesagt das mit F ist jetzt der Anfangs-fall, A und 5 usw habe ich auch mit drin. >Das ganze solltest Du auch noch zwischen Forbid() >und Permit() packen (damit schaltest Du das Multitasking >aus und vermeidest, dass ein wildgewordenes Program das >Pattern in der Zwischenzeit zerstört und somit Fehler >erzeugt). Wenn ich das mache wird die Subway/Poseidon den Amiga zum absturz bringen, da der Interrupt nicht beantwortet wird. Müsste ich dann immer abschalten. [ - Antworten - Zitieren - Direktlink - ] |
|
19.10.2005, 19:55 Uhr Holger Posts: 8116 Nutzer |
Zitat: Wenn man berücksichtigen will, daß aufgrund eines Fehlers eine Speicherzelle den Inhalt einer anderen anzeigen könnte, wäre es besser, gar kein regelmäßiges Muster zu verwenden. Also eher 0xaf50f0a, 0xdeadbeaf oder ähnliches und diesen Wert in jedem Schleifendurchlauf um ein Bit oder mehr shiften (das/die rausgeschobene Bit(s) auf der anderen Seite wieder reinpacken). mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
19.10.2005, 20:02 Uhr Holger Posts: 8116 Nutzer |
Zitat:Wer ein "wildgewordenes Programm" in seinem System zu laufen hat, hat andere Probleme, als einen perfekten memtest durchzuführen. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
19.10.2005, 23:35 Uhr MaikG Posts: 5172 Nutzer |
>Also eher 0xaf50f0a, 0xdeadbeaf oder ähnliches und diesen >Wert in jedem Schleifendurchlauf um ein Bit oder mehr >shiften (das/die rausgeschobene Bit(s) auf der anderen >Seite wieder reinpacken). Shiften mit C, ich bin Anfänger! [ - Antworten - Zitieren - Direktlink - ] |
|
20.10.2005, 06:23 Uhr Solar Posts: 3680 Nutzer |
Zitat: Nein, die Funktion wurde speziell zur Befüllung von Speicher mit 0xFF entwickelt. Darum muß man das 0xFF auch als Parameter übergeben.  Falls Du mit "mehr" größere Werte meinst (0x100), nein. Der Parameter wird als unsigned char interpretiert. Zitat: http://www.dinkumware.com/manuals/reader.aspx?b=c/&h=string.html#memset PS: Wenn Du auf Dinkumware.com eine Seite "Limited Access Notice" liest, auf die Grafik mit den Pfotenabdrücken klicken. [ Dieser Beitrag wurde von Solar am 20.10.2005 um 09:08 Uhr editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
20.10.2005, 10:15 Uhr MaikG Posts: 5172 Nutzer |
>Falls Du mit "mehr" größere Werte meinst (0x100), >nein. Der Parameter wird als unsigned char interpretiert. Meinte ich z.B. FFFFFFFF, aber die Funktion wird hoffentlich so ausgelegt sein das bei einer ausreichenden größe mit Longs geschrieben wird? Ist alles noch ein wenig lahm. Ich meine 42 MB/s müsste schon der 68k bringen. Auf der Seite kam ich nun immerhin zu string.h, da steht aber kein memset drin. [ - Antworten - Zitieren - Direktlink - ] |
|
20.10.2005, 10:53 Uhr Solar Posts: 3680 Nutzer |
Zitat: Sache des Bibliothek-Schreibers, bzw. des Compiler-Schreibers da GCC für memset hartcodierten Code einsetzt (Compiler-builtin). Zitat: Na, die Augen wirst Du schon aufmachen müssen...  PS: Wenn das hier Deine ersten Gehversuche mit C sind, was schert Dich der maximale Speicherdurchsatz? Lern doch erst einmal die Sprache... [ Dieser Beitrag wurde von Solar am 20.10.2005 um 10:54 Uhr editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
20.10.2005, 12:29 Uhr MaikG Posts: 5172 Nutzer |
>Na, die Augen wirst Du schon aufmachen müssen... Ja, habs gefunden. >PS: Wenn das hier Deine ersten Gehversuche mit C sind, >was schert Dich der maximale Speicherdurchsatz? Lern >doch erst einmal die Sprache... Weil die CPPC die ich habe nicht richtig Funktioniert, nach einer weile einfach anhält. Sämtliche 68k Memtests habe ich probiert, danach scheint das Ram Okay. Nur der PPC greift ja schneller auf das Ram zu. [ - Antworten - Zitieren - Direktlink - ] |
|
20.10.2005, 13:00 Uhr Holger Posts: 8116 Nutzer |
Zitat: Linksrum: wert=(wert<<1)|(wert>>>31); Rechtsrum wert=(wert>>>1)|(wert<<31); mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
| 1 -2- 3 | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Programmierung > Mein erstes C Programm will nicht | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|