Es gab diverse Gründe, warum ich mich erst jetzt wieder einschalte: zum Einen kam ein anderes, für mich wichtigeres Projekt (keine µC-Anwendung) unangemeldet dazwischen, zum Anderen war das Rechenproblem bereits von mir gelöst worden– siehe oben. Leicht tragisch empfinde ich den Verlauf dieses Freds. Da haben wir offenkundig zuletzt prima aneinander vorbei geredet.

Mir ging es in diesem Fred darum, eine Schwäche des ,,Zweier-Komplent-Rechnens" aufzuzeigen, nicht mehr, aber ganz sicher auch nicht weniger. Etwas unglücklich widersprachst du, Volker, und schobst das auf vermeintliche Fehler in meinem Programm. Danach bemühtest du dich, das Programm so umzuschreiben, dass es ohne Fehler auflaufen konnte. Da hattest du dir ordentlich Mühe gegeben, dafür auch ein herzliches Danke. Aber mehr hätte ich mich gefreut, wenn du meine Darstellung der erkannten Schwäche anerkannt hättest. Das Programm zum sauberen Laufen zu bekommen, war mir ja selbst schon gelungen.

Dazu gibt es mindestens zwei Ansätze, die beide auf eine Vermeidungs-Taktik raus laufen. Man kann schlicht die Sprungbefehle, welche das N-Flag nutzen, vermeiden und stattdessen das C-Flag für Verzweigungen nutzen. Oder man vermeidet überhaupt eine ,,echte" Subtraktion und setzt auf einfachen Überlauf, das Abfragen des C-Flags und damit auf den ,,bit-test-und-Sprung-wenn"-Befehl, so wie du es in deinen beiden letzten Prog-Vorschlägen ausgeführt hattest. Wobei es genau genommen um andere Sprungbefehle geht, statt bra also bit-test.

Mein ganzes µC-Bemühen liegt seit einigen Tagen brach, weil anderes erledigt werden musste. In den nächsten Tagen versuche ich, weiter zu kommen.
Grüße, picass

Zitat von: picass in 21.10.2022, 17:42:46 CESTDazu gibt es mindestens zwei Ansätze, die beide auf eine Vermeidungs-Taktik raus laufen. Man kann schlicht die Sprungbefehle, welche das N-Flag nutzen, vermeiden

Man könnte auch einfach akzeptieren, wozu CARRY, /BORROW und NEGATiV Flags benutzt werden und sich nicht versuchen raus zu reden. Es gibt keine Schwäche des 2er Komplements und dein Problem  existiert schlicht nicht.

Ich werde die fruchtlose Debatte hier beenden. Es konnte aufgezeigt werden, dass in dem Problem-/Spannungsfeld von Assembler-Programmierung in der MPLAB X IDE-Umgebung (bis Vers. 5.35) logische Fehlentscheidungen und auch Rechenfehler stattfinden.

Anhand von Beispielen konnte nachgewiesen werden, dass nach Subtraktionen mal weder ein Negativ- noch ein Carry-Flag gesetzt wurde, und ebenso das Gegenteil, dass danach gleichzeitig ein N- und ein C-Flag gesetzt wurden. Beides steht für einen Fehler. Ebenfalls gab es Beispiele von Subtraktionen, in denen schlichtweg ein echter Rechenfehler auftrat.

Diese Fehlverhalten – oder wie man das auch immer benennen mag – sind System-Fehler. Die gezeigten Rechenfehler finden sich nicht nur in meinem Beispiel wieder, sondern auch in Muster-Rechenentwürfen namhafter Autoren, hier gezeigt am Beispiel im Buch ,,Mit dem PIC-Controller erfolgreich arbeiten" von Dr. Anne König und Manfred König, erschienen im Verlag Markt@Technik, Auflage 1996, Seite 398. Das exakt gleiche Programmbeispiel inclusiv des Rechenfehlers (bis auf unwesentliche Bezeichner-/Variablen-Namen Änderungen) findet sich bei SPRUT, und alles geht auch auf Beispiele von Microchip zurück.

Das sind Beweise genug. Für Lern- und Akzeptanz-Unwillige werde ich nun aus grundsätzlichen Erwägungen heraus keine Zeit mehr investieren. Mag sein, dass es nicht jedem gegeben ist, zwischen dem Problem und der Problembeseitung einen Trennstrich zu ziehen. Mir ging es in diesem Fred alleine um die  Darstellung des Problems, rsp. den Hinweis darauf.

Jeder, welcher über die programm-technischen Voraussetzungen verfügt, kann die einfachen Beispiele auf seinem Computer nach vollziehen. Damit ist für mich hier Schluss. Ich beende meine Beiträge und bin stolz auf meine Entdeckung. Der Fred erhält von mir das vom Forum zur Verfügung gestellte Merkmal: gelöst. Wer sich an dem anderen Problemfeld, der Vermeidung dieser  Rechenfehler – z.B. durch Umgehungsstrategien – engagieren möchte, darf  und sollte das in einem eigenen Fred tun und kann sicher sein, dafür auch Anerkennung zu finden.
Grüße, picass

Zitat von: picass in 24.10.2022, 17:24:36 CESTIch werde die fruchtlose Debatte hier beenden.

Gut

Zitat von: picass in 24.10.2022, 17:24:36 CESTAnhand von Beispielen konnte nachgewiesen werden...

Nö

Zitat von: picass in 24.10.2022, 17:24:36 CESTDiese Fehlverhalten – oder wie man das auch immer benennen mag – sind System-Fehler

Welche? (nein, bitte nicht antworten;-))

Zitat von: picass in 24.10.2022, 17:24:36 CESTDas sind Beweise genug.

Ich habe keinen einzigen gesehen

Zitat von: picass in 24.10.2022, 17:24:36 CESTJeder, welcher über die programm-technischen Voraussetzungen verfügt, kann die einfachen Beispiele auf seinem Computer nach vollziehen...

... und wird keinerlei Systemfehler finden

Widerspruch auf allen Ebenen wie es scheint. Ich halte mich aber an mein Wort und lege diese Angelegenheit auf Eis. Viel.... viel zu viel Zeit ist bislang dafür geopfert worden und meine anderen, wichtigen Projekte lagen da auf Eis. Die müssen aber dringend weiter geführt werden und denen wird meine Aufmerksamkeit nun gelten. Mag sein, dass diese Angelegenheit hier auch noch mal aufgegriffen wird für eine Überprüfung. Aber nun gibt's Eis. Das könnte auch zur Abkühlung evtl. angeheizter Atmosphäre dienen.
Grüße, picass

etwas off-toppic, aber mit Bezug zu einem Beitrag von mir weiter oben:

Zufällig bin ich in einem anderen Forum auf deine Anfrage bzgl. MPASM - PIC_AS gestoßen
und dadurch auf die Lösung meines Problems mit der Anzeige der Variablen im Debugger gekommen.

Die Variablen müssen dafür beim PIC-AS  als "global" deklariert sein.
Wird auch im MPLAB_XC8_PIC_Assembler_User_Guide_for_Embedded_Engineers.pdf irgendwo erwähnt

Nachfolgendes sieht nach einer veritablen Unhöflichkeit oder gar Provokation aus. Ist aber nur der Anschein:
Ich werde auch deinen gerade formulierten Hinweis nicht aufgreifen. Jedenfalls nicht jetzt. Sitze wirklich total in einer Zeitklemme drin, es sind zu viele Jobs, die ich auf einmal erledigen müsste. Und z.Z. sitzt mir auch meine Frau im Nacken, die - leider zu Recht - anmahnt, dass etliches Zugesagtes immer noch nicht erledigt wäre.

Die Gemengelage mit dem Rechenfehler möchte ich einfach noch mal komplett von vorne aufrollen, auch, weil ich natürlich darin interessiert bin, zumindest dicht an so was wie die "Wahrheit" ran zu kommen. Es gibt immerhin schon den dezenten Hinweis, dass die Funktion des Carry-Flags von mir nicht genau erfasst wurde. Aber jetzt kommen erst mal andere Projekte dran, z.B. mein Regenerations-Anzeiger, danach die Garagentor-Steuerung. Dann kommt Urlaub, dann.....
Ein offenes Wort noch: es würde mich freuen, wenn es uns gelingen würde, ein weitgehend friedliches Miteinander bewahren zu können.
Grüße, picass