amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Programmierung > Gesucht: Sekundentakt [ - Suche - Neue Beiträge - Registrieren - Login - ]

1 2 -3- 4 [ - Beitrag schreiben - ]

26.06.2006, 13:53 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von gni:
Zitat:
thomas:
Korrekt muß es also so lauten:
code:
/* Die Uhr hat sich gemeldet... */
if(Signale & (1UL << TimerMP->mp_SigBit))
{
   WaitIO ((struct IORequest *) TimerIO);

   TimerIO->tr_node.io_Command = TR_GETSYSTIME;
   DoIO((struct IORequest *) TimerIO);


Und ohne Casts wäre es noch viel besser...

Würde aber reichlich Warnungen bringen ;)

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

26.06.2006, 13:57 Uhr

thomas
Posts: 7716
Nutzer
@whose:
Zitat:
Zum WaitIO(): Aus welchem Grund muß denn, wenn das timer.device das Signal gesetzt hat, nochmal extra auf Beendigung des Requests gewartet werden?

WaitIO wartet nicht, wenn der Request bereits beantwortet wurde. Aber es räumt auf und das fehlt in deinem Programm.


Zitat:
Darf man nicht davon ausgehen, daß der Request bearbeitet wurde, wenn das gewünschte Signal eintrifft?

Der Request wurde bearbeitet, aber du mußt die Antwort noch abholen.


Zitat:
Ich frage so dusslig, weil ich zum WaitIO() an dieser Stelle weder in den RKMs noch in den AutoDocs was finde...

Doch, das steht da irgendwo.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

26.06.2006, 14:24 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von thomas:
@whose:
Zitat:
Zum WaitIO(): Aus welchem Grund muß denn, wenn das timer.device das Signal gesetzt hat, nochmal extra auf Beendigung des Requests gewartet werden?

WaitIO wartet nicht, wenn der Request bereits beantwortet wurde. Aber es räumt auf und das fehlt in deinem Programm.

Zitat:
Darf man nicht davon ausgehen, daß der Request bearbeitet wurde, wenn das gewünschte Signal eintrifft?

Der Request wurde bearbeitet, aber du mußt die Antwort noch abholen.

Zitat:
Ich frage so dusslig, weil ich zum WaitIO() an dieser Stelle weder in den RKMs noch in den AutoDocs was finde...

Doch, das steht da irgendwo.


Ach, Du meinst das Räumen des MessagePorts von unterschiedlichen Replys, jetzt verstehe ich. Na, das ist hier doch aber nicht gegeben. Es kommt immer der gleiche IORequest zur Anwendung. Da wäre das Aufräumen etwas Overkill, vor allem für die, die gerade hineinschnuppern. Da sollte man besser ein Beispiel mit mehreren asynchronen Requests aufsetzen, da läßt sich das (meiner Meinung nach) viel besser zeigen, wozu die GetMsg()-Mimik überhaupt gut ist.

Das könnte man evtl. auch so machen, indem man für TR_GETSYSTIME einen eigenen Request nimmt und dann in der Wait()-Schleife TR_ADDREQUEST an erster Stelle in der Bearbeitung setzt. Da wäre dann ein WaitIO() vor dem DoIO() fällig oder auch ein GetMsg(TimerMP), um die unterscheidlichen Requests aus dem Port zu bekommen. Besonders verständlich wäre es aber wieder nicht, denke ich. Dafür ist das Programm an sich einfach zu simpel (soll heißen: Zu geradlinig im Ablauf. Das kann kaum einer nachvollziehen, warum man dann so ein "Tamtam" um die Replies macht).

Grüße

Edit: Ich habe das Beispiel nun an die Anregung angepaßt und den dussligen Fehler beim Test auf die Signale beseitigt.
--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 26.06.2006 um 16:28 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

26.06.2006, 17:53 Uhr

whose
Posts: 2156
Nutzer
@thomas:

Mal ne ganz andere Frage an den Fachmann für anfängerfreundliche Tutorials (das ist nicht ironisch gemeint):

Wie würdest Du es lösen, mehrere Requests zu verwenden, ohne die IORequest-Strukturen an sich zu kopieren? Mir kam und kommt der Ansatz, das betreffende Device für jeden IORequest einfach nochmal zu öffnen, nicht so besonders "elegant" vor. Andererseits beherrschen manche der älteren Compiler das Kopieren von Strukturen ja nicht.

Würdest Du es für gut heißen, sich in diesem Fall auf die AmigaOS-internen Strukturen (und Definitionen) zu stützen, um alle notwendigen Felder der weiteren IORequest-Strukturen "von Hand" zu initialisieren? Das wäre jetzt ad hoc die einzige Lösung, die mir dazu einfällt...

Ich habe das Beispiel inzwischen so modifiziert, daß TR_ADDREQUEST und TR_GETSYSTIME jeweils ihren eigenen IORequest benutzen und diese ordentlich bearbeitet (und aus der Message Queue "entsorgt") werden, wenn sie ausgeführt wurden. Nur die Chose mit dem mehrfachen Öffnen des timer.device schmeckt mir nicht so ganz. Da muß es doch nen eleganteren Weg geben, um auch ältere Compiler da nicht auszuschließen.

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

26.06.2006, 18:04 Uhr

thomas
Posts: 7716
Nutzer

Ich weiß nicht genau, was du meinst. Wenn du mehrere Timer brauchst, solltest du das timer.device auch mehrmals öffnen. Könnte ja sein, daß du unterschiedliche Units für unterschiedliche Genauigkeiten brauchst. Und wenn sich das erst zu einem späteren Zeitpunkt während der Programmentwicklung herausstellt, dann mußt du das ganze Programm umbauen.

Wenn du mehrere Requests nacheinander machst, reicht natürlich ein OpenDevice, dann kannst du den gleichen IORequest weiterbenutzen.

Speziell für GETSYSTIME würde ich eher die Funktion GetSystTime benutzen, die ist auch ausdrücklich als schneller dokumentiert. Oder gleich DateStamp oder CurrentTime, was man eben braucht.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

26.06.2006, 18:19 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von thomas:

Ich weiß nicht genau, was du meinst. Wenn du mehrere Timer brauchst, solltest du das timer.device auch mehrmals öffnen. Könnte ja sein, daß du unterschiedliche Units für unterschiedliche Genauigkeiten brauchst. Und wenn sich das erst zu einem späteren Zeitpunkt während der Programmentwicklung herausstellt, dann mußt du das ganze Programm umbauen.


Wenn ich mehrere Units verwende, liegt der Fall ziemlich klar. Das Problem sind Compiler, die nicht in der Lage sind, komplette Strukturen zu kopieren. Die Beispiele in den letzten RKMs benutzen implizit die Möglichkeit moderner Compiler, ganze Strukturen kopieren zu können. Wenn ein Compiler das nicht kann, muß der IORequest auf andere Art initialisiert werden, am "simpelsten", indem man das timer.device nochmal öffnet. Das kommt mir halt nur nicht so besonders elegant vor. Bei dem Uhrbeispiel stellt sich derzeit die Frage, welche anderen Wege der Initialisierung der IORequests (bei Verwendung der selben timer.device-Unit) es noch gäbe, ohne ältere Compiler von dem Beispiel auszuschließen.

Zitat:
Wenn du mehrere Requests nacheinander machst, reicht natürlich ein OpenDevice, dann kannst du den gleichen IORequest weiterbenutzen.

Das ist klar.

Zitat:
Speziell für GETSYSTIME würde ich eher die Funktion GetSystTime benutzen, die ist auch ausdrücklich als schneller dokumentiert. Oder gleich DateStamp oder CurrentTime, was man eben braucht.

Ja, das sehe ich ein. Für das Uhr-Beispiel ist es aber ganz praktisch, wenn man die Verwendung mehrerer, asynchroner Requests demonstrieren will. Ich habe das Beispiel schon darum erweitert, aber mir gefällt die Sache mit dem mehrfachen Öffnen ein und derselben Unit des timer.device halt nicht so besonders.

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

26.06.2006, 20:30 Uhr

thomas
Posts: 7716
Nutzer

Ich finde es nicht unelegant, das timer.device mehrmals zu öffnen. Wie gesagt, wenn du dich später entschließt, die Unit eines Requests zu ändern, mußt du sonst das ganze Programm umschreiben.

Für das Demonstrieren mehrerer Signale, finde ich, reicht es aus, wenn man auf den Timer, auf das Fenster und auf Ctrl-C wartet, das sind ja schon drei asynchrone Sachen.

Ich habe hier auch mal ein Beispiel für eine Uhr gebastelt: http://thomas-rapp.homepage.t-online.de/examples/uhr.c

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

26.06.2006, 20:54 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von thomas:

Ich finde es nicht unelegant, das timer.device mehrmals zu öffnen. Wie gesagt, wenn du dich später entschließt, die Unit eines Requests zu ändern, mußt du sonst das ganze Programm umschreiben.


Ok.

Zitat:
Für das Demonstrieren mehrerer Signale, finde ich, reicht es aus, wenn man auf den Timer, auf das Fenster und auf Ctrl-C wartet, das sind ja schon drei asynchrone Sachen.

Naja, das hatten wir vorher ja auch schon, immerhin wurde auch aufs Close-Gadget gewartet... das ist aber nicht das Gleiche wie asynchrone IORequests ;)

Zitat:
Ich habe hier auch mal ein Beispiel für eine Uhr gebastelt: http://thomas-rapp.homepage.t-online.de/examples/uhr.c

Gewohnte Qualität... eine Frage hab ich aber: wozu dient das Dragbar-Gadget?

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

26.06.2006, 21:09 Uhr

thomas
Posts: 7716
Nutzer

... und gleich nochmal verbessert (jetzt hat es zwei Timer, allerdings mit unterschiedlichen Units).

Zitat:
das ist aber nicht das Gleiche wie asynchrone IORequests

Wieso nicht ? Du hast eine Wait()-Anweisung, in der du auf alle Signale wartest. Wenn ein Signal erkannt wird, reagierst du entsprechend. Ob das nun ein Fenster, ein Timer, eine Soundausgabe, eine Message von einem Sub-Task oder ein Break-Signal ist, die Behandlung läuft immer gleich ab.


Zitat:
wozu dient das Dragbar-Gadget?

Ähm, als Drag-Bar... Damit kannst du das Fenster durch die Gegend ziehen, obwohl es keinen Rahmen hat (WFLG_BORDERLESS). Um zwei Uhren miteinander zu vergleichen, sollten sie möglichst nahe beieinander sein und dafür muß man mindestens eine der Uhren bewegen können ;-)

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

26.06.2006, 21:14 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von thomas:

... und gleich nochmal verbessert (jetzt hat es zwei Timer, allerdings mit unterschiedlichen Units).

Zitat:
das ist aber nicht das Gleiche wie asynchrone IORequests

Wieso nicht ? Du hast eine Wait()-Anweisung, in der du auf alle Signale wartest. Wenn ein Signal erkannt wird, reagierst du entsprechend. Ob das nun ein Fenster, ein Timer, eine Soundausgabe, eine Message von einem Sub-Task oder ein Break-Signal ist, die Behandlung läuft immer gleich ab.


Schon, aber bei verschiedenen, asynchronen IORequests mußt Du die Request-Replies selbst noch einmal unterscheiden. Sonst weißt Du ja nicht, auf welchen Timer-Event Du nun reagieren sollst. Das ist doch schon ein kleiner Unterschied zu den bekannten Signalen, finde ich. Kann jedenfalls nicht schaden, das mal zu demonstrieren :D

Zitat:
Zitat:
wozu dient das Dragbar-Gadget?

Ähm, als Drag-Bar... Damit kannst du das Fenster durch die Gegend ziehen, obwohl es keinen Rahmen hat (WFLG_BORDERLESS). Um zwei Uhren miteinander zu vergleichen, sollten sie möglichst nahe beieinander sein und dafür muß man mindestens eine der Uhren bewegen können ;-)


Ach je... gar nicht registriert, daß das ein Borderless-Window ist :glow:

Danke für den Augenöffner :)

Edit: Hehe, das war Gedankenübertragung, oder? Auf das "Nachlaufproblem", wenn die Systemzeit zurückgestellt wird, wollte ich Dich gerade aufmerksam machen ;)

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 26.06.2006 um 21:17 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

26.06.2006, 21:26 Uhr

thomas
Posts: 7716
Nutzer
Zitat:
Schon, aber bei verschiedenen, asynchronen IORequests mußt Du die Request-Replies selbst noch einmal unterscheiden. Sonst weißt Du ja nicht, auf welchen Timer-Event Du nun reagieren sollst.

Ok, das liegt wohl daran, daß du den IORequest kopierst und dann den selben Message-Port für mehrere Timer benutzt. Dann hast du natürlich das Problem, daß du beim Auftreten des Signals erstmal nachschauen mußt, welcher Request denn jetzt zurückgekommen ist. Dann kannst du auch schlecht mit WaitIO arbeiten, sondern mußt die Messages mit GetMsg abholen und kannst dann am Pointer erkennen, welcher Request es ist.

Das ist alles einfacher, wenn man das Device mehrmals mit je einem eigenen IORequest und MsgPort öffnet. Dann hat jeder Request ein eigenes Signal und man kann bereits am Signal erkennen, welcher Request es ist.

Sicher, wenn man Probleme hat, mit den 32 Signalen (oder 24, die man als User benutzen kann) auszukommen, dann muß man sparen. Aber wann kommt das schonmal vor ? Bei mir jedenfalls noch nie. Gut, ich habe noch keinen Word-Processor geschrieben, bei dem man beliebig viele Dokumenten-Fenster aufmachen kann. Aber bei sowas würde ich dann wohl auch jedem Fenster eine Sub-Task spendieren, die wieder 24 Signale zur Verfügung hat. Schon aus dem Grund, daß man, wenn mal einer abstürzt, die anderen noch sauber speichern und schließen kann.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

26.06.2006, 21:32 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von thomas:
Zitat:
Schon, aber bei verschiedenen, asynchronen IORequests mußt Du die Request-Replies selbst noch einmal unterscheiden. Sonst weißt Du ja nicht, auf welchen Timer-Event Du nun reagieren sollst.

Ok, das liegt wohl daran, daß du den IORequest kopierst und dann den selben Message-Port für mehrere Timer benutzt. Dann hast du natürlich das Problem, daß du beim Auftreten des Signals erstmal nachschauen mußt, welcher Request denn jetzt zurückgekommen ist. Dann kannst du auch schlecht mit WaitIO arbeiten, sondern mußt die Messages mit GetMsg abholen und kannst dann am Pointer erkennen, welcher Request es ist.


Genau dafür wars auch gedacht. Ich habe noch einige Frager in Erinnerung, die mit dem Teilen eines MessagePorts so ihre Problemchen hatten. Für diese Klientel wäre sowas ja ein schönes Beispiel. Ich kann ja die aktuelle Fassung des ursprünglichen Beispiels von MadDog nochmal hier reinstellen (falls Bedarf da ist).

Zitat:
Das ist alles einfacher, wenn man das Device mehrmals mit je einem eigenen IORequest und MsgPort öffnet. Dann hat jeder Request ein eigenes Signal und man kann bereits am Signal erkennen, welcher Request es ist.

Ja, auf die Art ist es ziemlich simpel ;)

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

27.06.2006, 11:46 Uhr

gni
Posts: 1106
Nutzer
Zitat:
whose:
Zitat:
gni:
Und ohne Casts wäre es noch viel besser...

Würde aber reichlich Warnungen bringen ;)
Soweit ich weis, hat timerequest einen eingebetteten IORequest. Damit kann man sich solch unsinnige Casts wie in dem Beispielprogramm sparen.

[ - Antworten - Zitieren - Direktlink - ]

27.06.2006, 11:48 Uhr

gni
Posts: 1106
Nutzer
Zitat:
whose:
Andererseits beherrschen manche der älteren Compiler das Kopieren von Strukturen ja nicht.

Was für Museumsstücke verwendest Du denn? ;-) Du kannst immer "zu Fuß" kopieren, zb. mit memcpy.

[ - Antworten - Zitieren - Direktlink - ]

27.06.2006, 12:00 Uhr

Ralf27
Posts: 2779
Nutzer
Hm, ich hatte eigentlich nur eine einfache Frage nach dem Sekundentakt gestellt und wie ich nun in diesem Thread kann, ist dies unter umständen recht kompliziert.
Bzw. finde ich auch die Diskusion unter C-Profis schon recht interesant, die sich sogar bei diesem Thema noch Hürden finden.

Und genau so geht es mir als noch mit C, leider. Ich komme zwar langsam voran (sehr langsam), aber ich bin da hin und wieder dennoch im Nahkampf mit dem Compiler. Aber das ist ja ein bekanntes Problem.

Deswegen laufen zur Zeit alle meine Projekte noch unter MaxonBasic. Und vermutlich auch noch die nächsten. ...
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

27.06.2006, 12:04 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von gni:
Zitat:
whose:
Zitat:
gni:
Und ohne Casts wäre es noch viel besser...

Würde aber reichlich Warnungen bringen ;)
Soweit ich weis, hat timerequest einen eingebetteten IORequest. Damit kann man sich solch unsinnige Casts wie in dem Beispielprogramm sparen.

Sofern man dem Compiler mitteilt, daß man die entsprechenden Warnungen nicht sehen möchte, kann man das. Wie an so vielen anderen Stellen auch. Aber ich caste lieber, statt "Kleinigkeiten" zu verwechseln und mich dann zu fragen, weshalb etwas kracht ;)

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

27.06.2006, 12:06 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von gni:
Zitat:
whose:
Andererseits beherrschen manche der älteren Compiler das Kopieren von Strukturen ja nicht.

Was für Museumsstücke verwendest Du denn? ;-) Du kannst immer "zu Fuß" kopieren, zb. mit memcpy.

Ich verwende keine Museumsstücke mehr ;) Aber es soll noch Leute geben, die mit dem Lattice/SAS5.2 arbeiten, der kanns z.B. nicht.

Danke für den Tip mit dem blanken Speicher-Kopieren... irgendwie rostet man ein, wenn man nicht hin und wieder Museumsstücke benutzt, glaube ich :D

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

27.06.2006, 12:11 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Ralf27:
Hm, ich hatte eigentlich nur eine einfache Frage nach dem Sekundentakt gestellt und wie ich nun in diesem Thread kann, ist dies unter umständen recht kompliziert.


So kompliziert ist es eigentlich gar nicht. Es gibt halt nur recht viele Möglichkeiten, das zu realisisieren und je nach Anspruch einiges zu beachten (z.B. Genauigkeit, Gleichlauf mit der Systemzeit etc.). Für Dein spezifisches Problem hat sich ja ne Lösung gefunden, das andere ist mehr theoretischer Natur ;)

Zitat:
Bzw. finde ich auch die Diskusion unter C-Profis schon recht interesant, die sich sogar bei diesem Thema noch Hürden finden.

Wie gesagt, das ist mehr eine Frage der Ansprüche. Je höher die Ansprüche, desto höher die Hürden :D

Zitat:
Und genau so geht es mir als noch mit C, leider. Ich komme zwar langsam voran (sehr langsam), aber ich bin da hin und wieder dennoch im Nahkampf mit dem Compiler. Aber das ist ja ein bekanntes Problem.

Deswegen laufen zur Zeit alle meine Projekte noch unter MaxonBasic. Und vermutlich auch noch die nächsten. ...


Eventuell wäre Cubic ne Idee... das installiert die Compiler ordentlich, man kann zwischen verschiedenen Varianten wählen und die Konfiguration ist auch verhältnismäßig simpel zu erledigen.

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

27.06.2006, 12:21 Uhr

Ralf27
Posts: 2779
Nutzer
[quote]
Original von whose:
Zitat:
Eventuell wäre Cubic ne Idee... das installiert die Compiler ordentlich, man kann zwischen verschiedenen Varianten wählen und die Konfiguration ist auch verhältnismäßig simpel zu erledigen.

Ich hab hier gerade vbcc und es geht ja auch. Aber wie so oft sind es die kleinen Probleme. Z.b. beim Mandelbrotprogram vom MadDog aus seinem C-Kurs:

zuerst lieferte der Compiler einen Fehler nach dem anderen. Dann hab ich festgestellt das beim herrauskopieren der Quellcodes von der Seite einfach andere SPACE-ASCII-Codes dann im Quellcode waren. Also statt ASCII 32(SPACE) halt ein anderer Code der auch en Space macht, aber vom Compiler nicht genommen wird.
Ok, hab ich dann geändert.

dann das zweite, zwei seiten Fehlermeldungen mit dennen ich nix anfangen konnte. Aber dank Thomas weis ich jetzt das es flieskommaprobleme gab, bzw. ich dem compiler noch die lib extra angeben mußt.

das dritte, die kommentare wollte vbcc nicht. Wie ich dann auch hier im Forum mitbekommen habe, benutzt MadDog C99-Kommandos, die aber vbcc so nicht kennt, außer man gibt das auch wieder extra an.

das vierte, wieder fehler vom compiler an einer if-stelle, die ich einfach durch herrausloeschen der gleichen (war an dieser stelle möglich) beseitigen konnte.

erst dann(!) lief es!

Und das bei einem vorgegebenen code!

Und achja, ich hab dann auch erst später erfahren das die includes von C-Compiler zu C-Compiler unterschiedlich sein können, bzw. das vbcc die extern dazugelinkt benötigt...

Also, es gibt laufend Probleme die umschifft werden möchten. Das meinte ich mit Nahkampf mit dem Compiler...
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

27.06.2006, 12:29 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Ralf27:

Also, es gibt laufend Probleme die umschifft werden möchten. Das meinte ich mit Nahkampf mit dem Compiler...


Naja, bis auf die Zeichenprobleme (Shift-Space) und Vertipper gibts die Probleme mit Cubic nicht. Das läuft "direkt aus der Kiste" und die Optionen der Compiler sind einigermaßen verständlich aufbereitet (z.B. C99-Option für vbcc). Das Gleiche gilt für die GCC-Installation.

Das Verstehen der Optionen ist allerdings ne andere Sache (verdammtes Englisch ;) )... aber da hilft Nachfragen :D

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

27.06.2006, 12:58 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Original von Ralf27:

das vierte, wieder fehler vom compiler an einer if-stelle, die ich einfach durch herrausloeschen der gleichen (war an dieser stelle möglich) beseitigen konnte.

erst dann(!) lief es!


Welches if hast Du denn rausgemacht? :dance3:
--
http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

27.06.2006, 13:12 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Original von Ralf27:
Hm, ich hatte eigentlich nur eine einfache Frage nach dem Sekundentakt gestellt und wie ich nun in diesem Thread kann, ist dies unter umständen recht kompliziert.
Bzw. finde ich auch die Diskusion unter C-Profis schon recht interesant, die sich sogar bei diesem Thema noch Hürden finden.


Das hat eigentlich nicht direkt was mit der Sprache C zu tun, sondern mit der AmigaOS API. In vielen BASIC-Dialekten gibt's viele "eingebauten Funktionen", welche die System-API Aufrufe kaschieren - dort siehst Du eben nicht, was genau passiert. Das kannst Du in BASIC genauso API-nah lösen...

Wenn Du einfach nur eine Sekunde Warten willst, reicht ein Delay(50). Für einen "zyklischen Alarm" mußt Du schon etwas tiefer in die Trickkiste greifen.


--
http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

27.06.2006, 21:05 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von Mad_Dog:
Welches if hast Du denn rausgemacht? :dance3:


code:
/* Farbwert hängt vom Parameter n ab */
        n = Berechne_n( (double)(x+x_offset)/zoom,(double)(y+y_offset)/zoom);

        if (n>=100) SetAPen(rp,Pens[0])
        else SetAPen(rp,Pens[n%64]);

        WritePixel(rp,x+xmax,y+ymax);


das else an dieser stelle macht das Problem. Bzw. Warning 54 kommt bei vbcc. Keine Ahnung wieso.

Außerdem ist da noch eine Sache:
Mir ist schon klar, wenn man das ganze im Fastram berechnen lassen würde und dann auf einmal blitten würde, wäre das ganze schneller. Allerdings wenn ich da zum vergleich jetzt z.b. Mand2000 betrachte, der braucht für eine 320*200 Mandelbrotgrafik weniger als eine Sekunde und man kann da beim zeilenweise Aufbauen zusehn! Bzw. baut er von der Mitte aus auf. Wenn man weiter rein Zoomt, dann wird es ja auch langsamer und man kann es genauer erkennen wie er aufbaut.

Vom Geschwindigkeitsunterschied würd ich mal tippen das er so groß ist wie MaxonBasic<->C, also extrem. Ich kann mir kaum vorstellen das diese WritePixel-Orgie so stark bremst.
Mich würde das ganze mal mit Zeilenweise Aufbau, bzw. Bilschirmweise Aufbau interesieren. Bzw. was das für ein Unterschied ist. Ich werd das später mal testen, wenn ich das hinbekomme mit C. :) Bzw. einfach mal die Ausgabe weg lassen. :)
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

27.06.2006, 21:10 Uhr

gni
Posts: 1106
Nutzer
Zitat:
whose:
Sofern man dem Compiler mitteilt, daß man die entsprechenden Warnungen nicht sehen möchte, kann man das.

Nix mit Warnungen unterdrücken! timerequest enthält am Anfang einen engebetteten IORequest und genau den übergibt man mittels &req->tr_node. Damit hat man ohne cast den richtigen Typ. In Amiga-Programmen wird viel zu oft mit Casts gearbeitet...
Zitat:
Danke für den Tip mit dem blanken Speicher-Kopieren... irgendwie rostet man ein, wenn man nicht hin und wieder Museumsstücke benutzt, glaube ich
Du kannst auch CopyMem aus Exec verwenden ;-)

[ - Antworten - Zitieren - Direktlink - ]

27.06.2006, 21:36 Uhr

Ralf27
Posts: 2779
Nutzer
Hab es eben mehrfach getestet, es macht kaum was aus. Der aufbau dauert fast eine Minute auf meinem 060er mit AGA. Ich vermute einfach mal das vbcc in der Standardkonfiguration auf 68000er compiliert. Macht das wirklich so viel aus? :dance3: Muß mal nachsehn wie ich da auf 060er schalt und dann mal testen...

EDIT:
Hab eben einiges getestet, aber die Option fpu=68060 hat die Zeit auf 8 Sekunden reduziert. *Das* war eben ein Geschwindigkeitsschub! So, bin gerade auf Optionen warmgelaufen, wie kann man noch mehr rausholen? Hab jetzt folgendes hinzugefügt:

-cpu=68060
-fpu=68060
-speed

Was würdet ihr noch empfehlen?

--
http://www.alternativercomputerclub.de.vu

[ Dieser Beitrag wurde von Ralf27 am 27.06.2006 um 21:54 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

27.06.2006, 22:11 Uhr

thomas
Posts: 7716
Nutzer
Zitat:
Original von Ralf27:
code:
/* Farbwert hängt vom Parameter n ab */
        n = Berechne_n( (double)(x+x_offset)/zoom,(double)(y+y_offset)/zoom);

        if (n>=100) SetAPen(rp,Pens[0])
        else SetAPen(rp,Pens[n%64]);

        WritePixel(rp,x+xmax,y+ymax);


das else an dieser stelle macht das Problem. Bzw. Warning 54 kommt bei vbcc.


Was soll die Nummer ? Warum liest du nicht den Text ? Der sollte deutlich zum Ausdruck bringen, was der Fehler ist.

Zitat:
Keine Ahnung wieso.

Da fehlt ein Semikolon.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

27.06.2006, 22:33 Uhr

Ralf27
Posts: 2779
Nutzer
@thomas:

code:
warning 54 in line 167 of "ram:Testk.c": ; expected


Ok, danke, dann ist mir auch klar was da oben steht. Dann ist das also der Fehler im Code vom Maddog. Und wenn ich das richtig verstanden habe, ist das nur eine Warnung, das ganze läuft aber dennoch.

@MadDog:

Bugreport: Hab da en Fehler gefunden. :D

--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

27.06.2006, 23:23 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von gni:
Zitat:
whose:
Sofern man dem Compiler mitteilt, daß man die entsprechenden Warnungen nicht sehen möchte, kann man das.

Nix mit Warnungen unterdrücken! timerequest enthält am Anfang einen engebetteten IORequest und genau den übergibt man mittels &req->tr_node. Damit hat man ohne cast den richtigen Typ. In Amiga-Programmen wird viel zu oft mit Casts gearbeitet...

So kann man es natürlich auch machen. Mit dem Cast geht es auch, noch dazu für beinahe jedes Device gleich, ohne jedesmal in den Strukturen schauen zu müssen, wie der eingebettete IORequest nun gerade heißt...

Zitat:
Zitat:
Danke für den Tip mit dem blanken Speicher-Kopieren... irgendwie rostet man ein, wenn man nicht hin und wieder Museumsstücke benutzt, glaube ich
Du kannst auch CopyMem aus Exec verwenden ;-)

Ja, kann ich auch. Oder von Hand jedes einzelne Byte kopieren... ich sag ja: man rostet ein, wenns zu viel Komfort gibt ;)

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

27.06.2006, 23:27 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Ralf27:
@thomas:

code:
warning 54 in line 167 of "ram:Testk.c": ; expected


Ok, danke, dann ist mir auch klar was da oben steht. Dann ist das also der Fehler im Code vom Maddog. Und wenn ich das richtig verstanden habe, ist das nur eine Warnung, das ganze läuft aber dennoch.

@MadDog:

Bugreport: Hab da en Fehler gefunden. :D


Der Fehler passiert aber schnell, wenn man mehrere Klamotten in einer Zeile unterbringt. Kleiner Tipp fürs nächste Mal: Gruppier die Zeilen so um, daß alles in einer eigenen Zeile für sich steht. Dann sieht man recht leicht, wo ein Semikolon fehlt. Auch ungleiche Klammern fallen dadurch etwas schneller auf.

Und wenn Du mal ne Warnung bekommst, deren Bedeutung sich Dir nicht erschließt (weil Englisch :D ), frag einfach mal, reißt Dir keiner den Kopf für ab, denke ich :)

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

28.06.2006, 14:33 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Original von Ralf27:

Hab eben einiges getestet, aber die Option fpu=68060 hat die Zeit auf 8 Sekunden reduziert. *Das* war eben ein Geschwindigkeitsschub! So, bin gerade auf Optionen warmgelaufen, wie kann man noch mehr rausholen? Hab jetzt folgendes hinzugefügt:

-cpu=68060
-fpu=68060
-speed

Was würdet ihr noch empfehlen?


Der Code ist bei weitem nicht optimal. Ich habe lieber Wert auf bessere Übersicht gelegt. Folgendes kannst Du noch verbessern: Die Funktion, in dem das n berechnet wird (Berechne_n) rausnehmen und den gesamten Code an die Stelle schreiben, wo diese Funktion aufgerufen wird. Das ist dann zwar schwer lesbarer Spagetticode, aber man spart sich den Funktionsaufruf. Und da diese Funktion ja ziemlich oft aufgerufen wird... Außerdem kannst Du versuchen, bestimmte Variablen mit "register" im CPU-Register zu behalten. z.B.

code:
register int x,y;


Dann ist das Fenster ein GimmeZeroZero-Fenster, was die Sache ebenfalls ausbremst. Es gibt sicher noch viele andere Möglichkeiten, das Programm zu verbessern...

Auf meinem A4000/060 mit CyberVision64/3D läufts schon sehr schnell (so 2-3 Sekunden für die Standard-Fenstergröße.

Hast Du mal probiert PPC-Code zu erzeugen - Du hast doch einen PPC, soviel ich weiß?


Und ja: Das Programm IST eine Writepixel-Orgie. Es geht sicher auch anders und schneller.

--
http://www.norman-interactive.com

[ Dieser Beitrag wurde von Mad_Dog am 28.06.2006 um 14:35 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]


1 2 -3- 4 [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > Gesucht: Sekundentakt [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
.