BASCOM und ASM

[Mega128]

Hallo zusammen!
Ich nutze z.Zt. die DEMO-Version von Bascom in Verb. mit einem ATmega16 ohne IRQ-Routinen. Für einige globale Funktionen nutze ich Bascom (LCD, CONFIGs, etc.) muß aber viele Dinge in Assembler realisieren. Mein Problem dabei: nirgendwo scheint dokumentiert welche BASCOM-Funktion nun intern welche Register belegt und welche nicht. Es ist auch schwierig, jeden BASCOM-Befehl durch den Simulator laufen zu lassen um zu sehen welche Register verwendet wurden... Dazu kommt, das der Simulator leider fehlerhaft ist: als Beispiel führt der Simulator einen BREQ-Befehl aus (verzweigt also), im µC-Register wird aber gleichzeitig Z=0 angezeigt! Bei der gemischten (zulässigen) Nutzung von BASCOM/ASM kommt es eben vor, das ich r20 nutze, dann eine BASCOM-Zeile abarbeite, und danach - bei einer weiteren Nutzung von r20 - Fehler auftreten.

Meine erste Register-Nutzungs-Untersuchung hat folgendes ergeben:
1) Definitiv BASCOM-genutzt..: R4, R5, R6, R8, R9, R23, R24.
2) BASCOM-Befehlsabhängig genutzt: R0, R10, R11, R16...R21, R25, R26, R27, R30, R31.
3) Für ASM nutzbar: R12, R13, R14, R15 sowie R19, R20, R21, R22 (R28, R29).

Meine Frage: hat jemand eine Ahnung, welche Register AUF KEINEM Fall von Bascom genutzt/verändert werden??
Ich nutze z.Zt. die unter 3) aufgelisteten Register für meine Zwecke in ASM. Dies sollte gutgehen (bei r19/r20 habe ich meine Zweifel). Jemand gleicher Meinung?

Ich möchte im jetzigen Zeitpunkt nicht auf Bascom verzichten, da ja einiges leichter von der Hand geht als bei 100% Assembler-Prog.
Dennoch bin ich recht verwirrt, das Bascom ja fast alle Register zu irgendwelchen Zeitpunkt irgenwie nutzt. Leider gibt es von MCS keine mir bekannte Liste mit den genutzten Registern.

Vielen Dank für eure Hilfe...
Mega128

[PicNick]

Schau dich da ein bißchen um, manches findet man da und in der Umgebung
https://www.roboternetz.de/wissen/in...Cr_Bascom-User

[Mega128]

Hallo PicNick,
diese Seite kannte ich schon, ist ja von Dir, nichtwahr? Ist auch gut für Einsteiger und zum Lernen/Auffrischen seiner Kenntnisse, keine Frage.

Das Problem ist aber ein anderes: Bascom nutzt intern alle möglichen Register von r0 bis r31. Dies ist sehr stark abhänging von dem jeweiligen BASCOM-Befehl welchen Du benutzt. Da ich ca. 50% Assembler nutze, kann ich natürlich nicht nach jedem BASCOM-Befehl erneut compilieren, das Ergebnis mit einem Disassembler begutachten um festzustellen welche Register nun wieder genutzt wurden. Ich muß mich ja beim Mischen von ASM/BASCOM/ASM unbedingt darauf verlassen können, das meine Register in der ASM-Nutzung nicht von Bascom verändert wurden.
Beispiel:
Ich möchte folgende BASCOM-Befehlzeile optimieren:
FOR i = 0 to 255 : LCD "Hallo PicNick" : NEXT i

Dies möchte ich mit dem Register r12 tun, also:
clr r12
hierweiter:
LCD "Hallo PicNick"
inc r12
brne hierweiter

Das Problem: ob jetzt tatsächlich 256x Dein Nick im LCD ausgegeben wird, ist unbedingt davon abhängig, ob Bascom intern bei der Umsetzung des LCD-Befehls zufälligerweise r12 nutzt od. eben nicht.
Stelle Dir einfach vor Du nutzt im obigen Beispiel I2C-Befehle statt den LCD-Befehl und statt r12 würdest Du r6 nehmen: bang! Warum? Weil in dem Fall Bascom ein error-Flag in r6 benutzt. Das ist soweit ja bekannt aus div. Literatur (z.B. Kühnel). Das habe ich bei der Einleitung des Themas ganz Oben unter Pkt. 1) aufgelistet: diese Register NIE selber in Assemblerzeilen nutzen. Klar.

Meine Frage zielt aber auf die RESTLICHEN Reg., also die in der obigen Auflistung 2) + 3). Lassen wir mal die Register-Paare X,Y,Z weg, weil Bascom diese z.T. auch nutzen wird, so bleiben Unsicherheiten bei den Reg.: r0, r1, r2, r3, r7, r10, r11, r12, r13, r14, r15, r16, r17, r18, r19, r20, r21, r22, r23, r24, r25.

Ich habe eine Anwendung mit 50% Assembler, der Quell-Code geht über 18 DinA4-Seiten. Ich habe jetzt folgendes gemacht: am Anfang des Programms habe ich die fraglichen 21 obigen Register mit den Wert AAh beschrieben. Weiterhin kann ich über ein vorhandene Tastatur div. Funktionen einleiten. Jede Funktion benutzt div. (andere) BASCOM-Befehle. Eine besondere Funktion ist diese: die Ausgabe der 21 Reg. auf dem LCD-Display. Und jetzt kommts: wenn ich mir zuerst nach Prog.-Start die Reg. ansehe steht fast überall AAh drin. Arbeite ich immer mehr Funktion ab - und zwar NUR BASCOM-Befehle - und sehe mir zwischendurch die Register-Inhalte an, dann stelle ich fest: je mehr versch. BASCOM-Befehle abgearbeitet werden, desto mehr Reg. wurden genutzt und haben einen Wert <> AAh. Also? Am Ende waren fast alle Reg. verändert. Diesen Test hatte ich gemacht BEVOR ich mit Assembler anfing, ich meine hier in dem BASCOM-Projekt (nur soviel: ich prog. seit 20 Jahren in Assembler, z.B.: 6502, 8080, Z80, 68HC11, um mal Beispiele zu nennen).

Ich prog. gern in Assembler, mache auch viel Echtzeitanwendungen. Aus Bequemlichkeit möchte ich aber auf Bascom nicht verzichten, da ja einige Arbeit abgenommen wird, gerade bei Verwendung von versch. AVRs.

Als ich vor 4 Wochen mit Bascom anfing, war mir schon bewußt, das Bascom intern alle mögliche Reg. nutzt und vergeudet. Aber welche genau? Ich war u. bin, das gebe ich offen zu, ziemlich unsicher ob der Mix ASM/BASCOM/ASM überhaupt gutgeht. BEVOR ich also in ASM losprogrammieren könnte mußte ich - soviel war klar - mir einen Überblick über die Reg. verschaffen welche ich UNEINGESCHRÄNKT benutzen kann, ohne die Angst haben zu müssen, das nach einem neuen BASCOM-Befehl ich mein ASM umschreiben muß, weil plötzlich irgendwas (bereits ausgetestetes!) abstürzt...

Deshalb der Aufwand und meine Frage eingangs zum Thema!
Weiteres Beispiel: Bascom benutzt definitiv intern die Reg. r23 + r24. Dazu gibt es in der BASCOM-Hilfe auch den Hinweis:

"The compiler will use register R23 for this. So make sure it is not used."

Und da liegt ein Teil der Verwirrung: in den von Dir gemachten Beispiel wird u.a. auch r23 und r24 verwendet. Das gibt aber Kuddelmuddel wenn im ASM-Mix zwischenzeitlich Bascom darauf zugreift...

Deshalb die Frage an die Profis: welchen Reg. kann ich denn ohne größere Sorge und ohne vorangestellte PUSH/POPs benutzen?
Oder ist der BASCOM-Compiler für diesen Mix ungeeignet?
P.S. mir würden ja 6 Register genügen: 3 oberhalb u. 3 unterhalb von r16.

Grüße,
Mega128

[Mega128]

Nochmal Nachtrag zu meinem letzten Beitrag: man könnte jetzt fragen warum ich die FOR i-Schleife umschreibe in Assembler, könnte ich doch auch in Bascom lassen... Das stimmt natürlich. Aber Bascom verschwendet viel Speicherplatz, ist nicht optimiert. Beispiel: Bascom ersetzt einen GOTO-Befehl zu einer benachbarten Programmzeile immer durch JMP (4 Byte Speicherplatz) anstatt RJMP (2 Byte) zu nutzen. Ebenso werden GOSUBs durch CALLs ersetzt, statt durch RCALL, auch wenn der Speicher garnicht >8KB hat.
Die FOR i-Schleife nutzt fast 100Byte Speicher wenn zufälligerweise i als AS WORD deklariert wurde. Deshalb Assembler.
Wenn ich jetzt konsequent die BASCOM-Befehle in Assembler umprogrammiere bleibt am Ende kaum Bascom übrig. Ja - werden jetzt einige sagen - dann kann der doch gleich Assembler nehmen. Ist von der Sache her richtig. Dennoch ist der BASCOM-ASM-Mix für mich unverzichtbar, da einem durch Bascom sehr viele globale Config-Prozeduren abgenommen werden (LCD, Timer, A/D, I2C, UART, etc.).

Somit brauche ich mich nicht mit den I/O-Registern mehr als nötig rumschlagen - und diese Grundidee finde ich halt sehr charmant.
Mega128.

[linux_80]

Hallo,
hab jetzt nicht so ganz alles durchgelesen
aber wie schauts aus wenn Du in den ASM-teilen deine verwendeten Register auf den Stack schiebst, dann gibts in der Routine keine Probleme.

Oder gehts darum, das die Daten länger halten, dann wirst Du sie ins SRAM verlegen müssen, so wie das Bascom auch macht, dazu kann man auch Bascom zuhilfe nehmen (im ASM-Teil), damit man die richtige Speicherstelle anspricht.

[Mega128]

Hallo linux,
genau das wollte ich doch vermeiden: PUSHen/POPen von Registern ist völlig sinnlos, wenn niemand diese - außer ich selbst - verändert.
Offensichtlich werden aber Register verändert und der Entwickler von Bascom kann nicht sagen (!?) welche Reg. für das angebotene und beworbene "Mixed ASM" nun zur Verfügung stehen. Zumindest habe ich dazu keine Info gefunden. Der Entwickler aber sollte das doch wissen und klar dokumentieren können -oder?

Wozu habe ich denn 32 Reg. wenn ich diese interaktiv aus (Un-)Sicherheitsgründen übers SRAM retten soll? Dann reichen doch auch 3 od. 2 Register. Das ging früher auch, ja, aber die AVR bieten nunmal 32 Reg. und da sollte ich nicht ständig (zumal OHNE IRQs) Kopien erstellen müssen. Abgesehen davon würde die RISK-Controller-Philosophie in Frage gestellt werden.

Außerdem: wo endet den diese Register-Retterei? Ab einen best. Punkt muß ich dann vielleicht Teile der I/O-Register ins SRAM verschieben? Nein.
Schlußendlich bleibt dann die Ungewißheit, ob nicht Bascom vielleicht seine Pointer über meine Register-SRAM-Kopie verlegt - die Vermutung/Möglichkeit ist ja leider nicht unbegründet, schließlich müßte ich mich darauf verlassen das Bascom alle SRAM-Pointer korrekt verwaltet. Soll ich dann die Register vielleicht sicherheitshalber in EXTERNES RAM auslagern?

Ich habe auch erlebt das Bascom - ohne Fehlermeldung - über ein SRAM-Array hinauslief und munter SRAM-Zellen (außerhalb der eindeutigen Deklaration) vollgeschrieben hat.

linux, vielen Dank für den Hinweis, in den einen od. anderen Fall habe ich das auch so gemacht (PUSH/POP). Das ist aber ein rumdoktern an den Symtomen ohne die Ursache zu ermitteln. Für professionelle Programme - vielleicht (wie bei mir) im Fahrzeug- oder Sicherheitsbereich - ist das unakzeptabel! Ein Programmierer MUß wissen was in seinen Registern vor sich geht...

Mir wäre geholfen wenn jemand ähnliche Erfahrungen hat und ein Liste der Register veröffentlicht, welche ich zuverlässig nutzen kann.
Grüße,
Mega128.

[linux_80]

Da glaube ich gibts dann einen Interessenskonflikt, Bascom ist wohl nicht gedacht um sich darin in ASM austoben zu können.
Wenn man wissen will, bzw. haben will das der Controller das macht was man will gibts wohl nur eine andere Sprache zu verwenden, die etwas druchsichtiger ist.
Der Vorteil von Bascom soll ja u.a. sein, das man sich nicht um die Register kümmern muss.

Ich persönlich würde das auch nicht nehmen wenns um Sicherheit geht [-X
auch wenns nach etwas mehr Arbeit aussieht um die diversen Features zu benutzten, es gibt ja auch viele Libs für C zB.

Zu dem Call/RCall, laut DB zB. unterstützt der Mega8 nur RCall bzw. RJmp, da kann dann Bascom eigentlich kein Call/Jmp verwenden.


PS:
Ich manche das hier alles nur Hobby-mässig da ist es dann (fast) egal wenn mein (ModellRoboter-)Auto gegen die Wand fährt weil zB. die Bremse nicht rechtzeitig angesteuert wird.

[Mega128]

Hallo linux,
da warst Du aber schon früh unterwegs.
Den Konflikt sehe ich auch, bevor ich zu Bascom kam hatte ich mich soweit es ging informiert. Assembler zu nutzen ist wichtig für mich, da ich zeitkritische Echtzeitanwendungen habe, aber auch langsame Sachen die locker in Bascom programmiert werden können. Auch kann ich "auf die Schnelle" etwas in Bascom ausprobieren und wenn alles läuft und zu langsam wird, Teile davon in ASM übersetzen. Es ist ja nicht immer der Zeitgewinn bei der Abarbeitung und der Speicherplatzgewinn.

Mega8 nutze ich z.Zt. nicht, wenn es so im DB steht dann muß sich Bascom natürlich daran halten. Bei meinen eigenen Versuchen ging es um die Frage: warum verbraucht Bascom an bestimmten Stellen soviel Speicher. Auch die Optimierungsfunktion bringt nicht viel (bei mir ca. 50 Byte Optimierung bei 4000 Byte Flash). Da bin ich drauf gekommen das JMPs & CALLs standardmäßig umgesetzt werden und leider nicht in Abhängigkeit vom (nahen) Sprungziel. Also habe ich mein Progr. selbst optimiert und alle GOSUBs durch RCALLs ersetzt und alle GOTOs (soll man ja nicht haben) durch RJMPs. Und siehe da: plötzlich hatte ich wieder 10% mehr Speicherplatz... (arbeite noch mit der DEMO, muß etwas mit Speicher geizen).

Ich sehe es bis jetzt so: Bascom bietet wahnsinnig viele Funktionen die die Arbeit schon erleichtern können (Vorteil). Dadurch wird aber auch ein Überhang an Code generiert, der nicht wirklich gebraucht wird (z.B. der JMP nach 10 Zeilen weiter), der aber gegen Not und Elend auch nicht falsch ist. Dies ist auch bei Speicherfressenden Befehlen so,
Beispiel:

LCD Voltage ; " mV "
LCD Hex(indat) ; " "
LCD Freq ; " Hz "

Diese paar Zeilen verbrauchen fast 400 Byte kostbaren Speicher. Werden die Befehle an einer anderen Stelle im Programm erneut benutzt werden wieder 400 Byte fällig. Na warum denn? Weil Bascom die Zeilen strikt nach den festen Muster übersetzt ohne bei gleichen Befehlen eine JUMP-Table einzurichten. >Also mache ich das in Assembler selber.

Natürlich, ab einen bestimmten Punkt macht dann Bascom keinen Sinn mehr. Aber ich wollte hier nicht über Bascom meckern, sondern sogar demnächst die Voll-Version ordern. Man muß die vielen Tücken nur kennen und umschiffen, dann kann Bascom insgesamt für den Anwender viel leistungsvoller werden. Dazu Suche ich hier im Board halt noch Anwender, die - Hobby od. Beruf - Bascom konsequent mit Assembler gemischt anwenden: erst dann kann der Compiler voll und effektiv genutzt werden (nur meine Meinung).

Wer natürlich kein Assembler-Progger ist, der ist mit 100% Bascom vermutlich gut bedient.
Gruß,
Mega128.

[felack]

Hallo Mega128,

Frag doch mal bei

www.mcselec.com/forum

nach. Da kannst du direkt Mark Alberts fragen, den Entwickler von BASCOM. Mir hat er auch schon weitergeholfen, obwohl ich nur mit der Demo arbeite.

felack

[PicNick]

Ich persönlich verwende Bascom in ähnlicher Art. Erstmal alles in Bascom, bis ich Licht am Horizint sehe, und dann replace ich nach und nach mehr oder weniger durch Inline-Assembler (wenn ein Gewinn zu erwarten ist).
Welche Register Bascom DEFINITIV NICHT verwendet, sieht man ja am sichersten, wenn man sich anschaut, was er bei einem Interrupt auf den Stack pusht. d.s. die Register r12, r13, r14, r15
Genauer gesagt nur dann, wenn er keine Gleitkomma-Befehle macht (steht im Help bei Interrupts)

Das hilft dir wenig, da die interessanten Register ja andere sind.