BTFSC : Bit Test File, Skip if Clear
hat nichts mit dem Carry Bit zu tun, sonder Testet ob das Bit gelöscht ist. Du könntest aber auch schreiben BC bzw BNC (Adresse) wie Du schon gemerkt hast.

Deine 100 Fehlermeldungen sind seltsam.
WRDH kenne ich nicht

den Rest kenne ich wohl, allerdings vom C18 Compiler womit ich noch arbeite
MOVF f,d,a
MULWF f,a
MOVFF fs,fd
hast Du diese in Befehle in Klammer geschrieben? Versuche es mal mit Großschreibung ohne Klammer

ansonsten solltest Du das mal in C probieren. Allerdings mußt Du dann mit float Datentype arbeiten. Siehe IEEE 754 Format. Bei meinem C18 Compiler findest Du das unter /microchip/mplabc18/v3.47/src/traditional/math/divFP.asm

Zitat von: pic18 am 13.05.2022, 15:18:57 CESTSTATUS,CY entspricht STATUS,C
SKPNC entspricht BTFSC STATUS,C

Den Passus für "STATUS,CY hatte ich auch schon rausgefunden, ebenso wie den Ersatz für SKPNC. Bei Letzterem gibt es wohl zu bemerken, dass "BTFSC STATUS,C" ein ungewöhnlicher Ausdruck, weil doppel-gemoppelt ist. Während einer Subtraction wird ja das Carry-Bit von STATUS auf jeden Fall gesetzt oder eben nicht. Es reicht demnach, einen einfachen Sprungbefehl wie BC oder BNC einzusetzen.
Ist aber eine rein akademische Debatte, denn nichts davon nützt. Habe alle Versionen ausprobiert - es bleibt dabei: 120 dividiert durch 20 gibt 3 !

Wenn ich schon mal mecker, dann gründlich!   Von deinem neuen Beispiel habe ich zur Vorsicht und zum Einüben - bevor ich sowas Komplexes wie eine Division einer 32-bit-Zahl durch eine 16-bit-Zahl probiere - zunächst die voran gestellte Multiplikation 16 mal 16 bit ausprobiert.
Nach mehr als einer halben Stunde Arbeit und dem Versuch, auch diesem alten Speech - kenntlich an den equ-Anweisungen - auf die aktuelleren Sprünge zu helfen, ist nur dieses erreicht: siehe angehängte Fehlerdatei. Da läuft schon beim Umändern nichts zusammen, geschweige denn, ob und wie das Prog evtl. funktionieren könnte.

Ich schmeiße jetzt mal die Brocken hin, gehe in den Garten und lasse mein Ungemach am Unkraut aus.

Tut mir leid, pic18 ! Du hast dich sehr bemüht, mir zu helfen. Du bist echt ein lieber Kerl..... alleine, die Karre ist zu festgefahren und was vielleicht - vielleicht vor 30 Jahren mal funktionierte, ist ohne Wundertaten heute nicht mehr brauchbar. Und heutzutage arbeitet wohl kaum noch jemand mit Assembler.... und hat mit den Niederungen von Grundrechenarten zu Fuß nix mehr am Hut.
Ab zum Unkrautjäten, picass

Moment, der Anhang kommt noch, vielleicht...

ich habe hier noch etwas gefunden
https://www.elepal.fi/antennit/pic/muldiv18.html

frag Google
https://www.google.de/books/edition/Das_gro%C3%9Fe_PIC_Micro_Handbuch/HOJ2DwAAQBAJ?hl=de&gbpv=1&dq=BCF+STATUS,CY&pg=PA141&printsec=frontcover

Seite 141 - 142
STATUS,CY entspricht STATUS,C
SKPNC entspricht BTFSC STATUS,C

Ganz herzlichen Dank für eure Anregungen. Habe die auch alle angeschaut, und nach zahlreichem Stirnerunzeln mich zwecks eines ersten Versuches einer Division für ein scheinbar gut dokumentiertes Beispiel in/aus einem Buch des Markt&Technik Verlages aus dem Jahr 1996 entschlossen, die Autoren: Dr. Anne König plus ihr Mann.

120 dividiert durch 20 ergibt 3 !!!!! Nach Wahl auch schon mal 7.
Beim Versuch der Übersetzung des Speeches für PIC16F8X-Typen in Assembler für den PIC18F14K22 hängt es anscheinend an zwei Ausdrücken, die zumindest ich nicht einsortieren kann:
1) - BCF STATUS,CY     Das damalige Register STATUS kennt aber kein "CY" und im Prog ist auch keine solche Variable definiert.
2) - SKPNC    watt is dat??? im damaligen Befehlssatz gab es sowas nicht. Soll vielleicht heißen skip if not carry?!
Warum verwendet Frau Dr. einen nicht einsetzbaren Befehl?!!!
3) Der Programmaufbau ist schon seltsam. Da wird nicht etwa subtrahiert, sondern zunächst der Nenner nach links rotiert, also jedesmal vom Wert her verdoppelt, was dann das Ergebnis von 3 erklärt, und danach wird der Zähler nach rechts rotiert. Bei Aufstoppen mit Breakpoint wird als Ergebnis 7 ausgespuckt.

Warum muss mir das immer passieren?: Blut, Schweiß und Tränen und ein irrer Zeitaufwand. Kann nicht mal jemand eine Routine geschrieben haben, in welcher 14550 geteilt durch 100 auch funktioniert? Das Zahlenbeispiel ist eines, welches demnächst gebraucht wird.
Muss wohl doch das Rad wieder neu erfinden. Weiß nicht, wie lange ich diesen Aufwand noch erbringen will.
Grüße, picass

http://www.schulheft-ottakring.eu/vane/Schule/Literatur/PIC/Gooligum/Intro%20to%20PIC%20Programming%20gooligum%20Base%20A/PIC_Base_A_11.pdf

kann man sich auch mal anschauen

http://ww1.microchip.com/downloads/en/DeviceDoc/39500a.pdf
16*16 Bit Multiplizierer. S 124..

Hier warst du schon ?

http://www.piclist.com/techref/microchip/math/index.htm

http://goumas-info.de/page10.html

In einem Projekt soll fleißig gerechnet werden. Ein PIC18F14K22 hat ja erbaulicherweise einen 8-bit-Multiplizierer in Hardware, also als Befehlssatz. Aber der ganze "Rest" muss irgendwie händisch im Programm ausgeführt werden. Nun muss ja nicht jedes Rad immer wieder neu erfunden werden.
Gesucht sind also fertige Routinen für Standard-Rechnungen wie 16-bit Multipl., Subtraktion und vor allem Division - is klar: in Assembler bitte sehr. Vermutlich gibt es sowas als Bibliotheken.
Gefunden habe ich was in einem stonealten Datenbuch von 1994. Aber - mit Verlaub - so recht kann ich mit denen nichts anfangen. Da sind eng und kleinst gedruckt auf 4 Seiten Programmschnipsel abgelegt in einer Assemblersprache, die längst nicht mehr brauchbar ist. Würde ich das in tagelanger Arbeit versuchen, erst abzutippen und dann in aktuellen Speach umzusetzen, reicht ein einziger Fehler/Irrtum, um alles ad absurdum zu führen.
Bei Sprut habe ich da auch keine Aufstellung gefunden. Kann mir jemand einen Hinweis auf solche Mathe-Routinen geben?
Grüße, picass

Komme gerade aus der Garage, und weil ich nicht möchte, dass der Staatsschutz hier unnötig rum schnüffelt, vermeide ich ein Wort der Steigerung für den Sieg über die Technik, sondern sage stattdessen: es ist geschafft: die Torsteuerung funktioniert. Rauf- u. Runterziehen und zuverlässiges "Einparken" an den Endpositionen und auch zwischendurch Aufstoppen, Kehrtwende, etc.... alles klappt. Zwischendurch pennt der PIC immer ein, das soll so sein.
Na gut, niemals ist so'n Programm ganz fertig. Im Moment braucht es manchmal zwei Tastendrücke, um eine Funktion auszulösen. Komischerweise aber nur in der realen Welt, in der Garage. Ein PIC mit demselben Programm in meiner Simulationsanlage macht das nicht. Grübel...., motz und nix verstehen.
Aber lass ma, das wird schon auch noch.

Das Ziel ist erreicht, auch die Elektronenquelle - das Solarmodul - lädt den Auto-Akku gerade wieder auf: pünktlich zum Zieleinlauf scheint die Sonne. Sowieso, als auch auf mein Projekt. Da gibts demnächst sicher noch was zu sagen, aber erst mal isses gut.

pic18P :Danke für das Angebot der Begutachtung des Programms. Wenn alles fertig scheint, stelle ich das wahrscheinlich hier ein. Falls du vorher schon neugierig sein solltest, vermelde das.
Grüße, picass