Archiv verlassen und diese Seite im Standarddesign anzeigen : BASCOM und ASM
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
Schau dich da ein bißchen um, manches findet man da und in der Umgebung
https://www.roboternetz.de/wissen/index.php/Assembler_Einf%C3%BChrung_f%C3%BCr_Bascom-User
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
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
24.11.2006, 22:11
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.
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
25.11.2006, 00:39
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.
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.
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
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.
@Mega128
Du schreibst viel - habe aus Zeitgründen nicht alles von Dir gelesen.
Zum Thema:
Ich habe bei meinem dem Butterfly-Projekt auch fleißig ASM und BASCOM gemixt und kenne Dein Problem:
siehe https://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=23231
bzw der 81KByte BASCOM-Code:
https://www.roboternetz.de/phpBB2/download.php?id=7721
Ich empfehle ein paar Byte im Code zu opfern und das nette Feature von BASCOM zu nutzen, da BASCOM-Variablen in ASM einzubinden.
sts {Timer_Key_Event},R24
Da BASCOM außer ein paar Pointer in keinster Weise beim nächsten Befehl die Register recycelt sondern alles wieder nachlädt, hast Du keine Chance einem Register zu vertrauen. Spätestens bei der nächsten Bascom-Version fliegt Dir Dein Code um die Ohren.
Soll heißen, wenn Du ASM benutzt, lade die Register in Bascom-Variablen und zurück. Der einzig sichere Weg.
Ansonsten gibt es noch gcc...
Ein Fluch von BASCOM ist, dass er beim compilieren viele Syntaxfehler im ASM-Code nicht meldet.
&H1F <-> 0x1F was hat mich dass schon für Zeit gekostet...
&H1F <-> 0x1F was hat mich dass schon für Zeit gekostet...
*rofl* Frag mich mal :mrgreen:
Hallo!
Ja, hatte rel. viel geschrieben, wollte das Problem möglichst genau darstellen. Sorry, ist wohl ein Prob. das man selbst als Leser viele Dinge "überfliegt".
Danke erstma für die Tips hier, auslagern ins SRAM als BASCOM-Variable geht natürlich, mache ich auch, sträube mich aber schon dagegen da es der klaren Linie einer sicheren SW und Doku widerspricht.
Werde wohl mal parallel im MCS-Forum meine Frage stellen müssen.
Habe mir nochmal die Register angesehen. Einige sind absolut tabu, einige werden je nach BASCOM-Befehl verändert (natürlich OHNE Recovery). Folgende Reg. sind m.E. im ASM-Code am ehesten nutzbar: r12,r13,r14,r15,r22,r23,r28,r29. In diesem Registern stand am Programm-Ende noch die Prüfziffer drin, welche ich beim Prog.-Start reingeschrieben hatte. Also für diejenigen, die es interessiert....
gcc? Nutze ich bislang nicht. Kann der Code mit BASCOM-Code verlingt werden??? Zumindest in der BASCOM-Vollversion?
,r28,r29.
Na, da hast du glück gehabt. das ist der SoftStackpointer. EIn Sub oder eine Function, und du bist dahin.
Das wird gesetzt BEVOR du drankommst
[Zeigefinger hoch]
Männer, Software auf undokumentierte Features und Eigenschaften ohne Gewähr aufzubauen, ist extrem unprofessionell, auch wenn's mal klappt.
Zwischen $END ASM und dem nächsten $ASM gehört die komplette Maschine dem Bascom.
Wenn beim nächsten Update alle wieder anders ist, bist du zweiter.
[/Zeigefinger hoch]
@ PicNick,
hab' ich's doch geahnt...
Ich schreibe mein Assembler komplett OHNE Assembler-Block-Directive, das geht wunderbar und ist auch AUSDRÜCKLICH erlaubt! Bis auf die Ausnahme von einigen Befehlen die BASCOM als "seine" fehlinterpretieren würde. Ist auch logisch da der Compiler strikt Zeile für Zeile in wunderbaren AVR-Code übersetzt und wenn da schon schicker AVR-Code steht (ohne Directive), umso besser. Syntax-Check und Register-Plausibilitätschecks (z.B. Erkennen von fehlerhaftem ldi r12,255) läuft auch, also ein zusätzliches Zeichen für korrekte Funktion des Compilers.
Verstehe ich Dich da richtig: wenn ich KEINE SUBs und KEINE FUNCTIONs in meinem Programm verwende, dann stehen mir die r28, r29 zur Verfügung? Hintergrund: ich hatte festgestellt, das diese Register von BASCOM nicht genutzt werden, allerdings nutze ich widerum keine Sub/Function.
Weiterhin teile ich nicht ganz Deine Meinung was BASCOM und die Kontrolle über die "Maschine" angeht. Denn BASCOM ist zunächst ein PC-basiertes Übersetzungsprogramm, welches Textfiles in HEX-Code (od. Binär-Code, je nach Betrachtung) nach festem Muster übersetzt. Zum Zeitpunkt des Compilierens hat BASCOM lediglich die Kontrolle ÜBER DEINEN PC, aber nicht über einen µC. Sowie der fertige Code den PC verläßt und die "Maschine" erreicht, hat BASCOM Feierabend und damit nüscht mehr zu tun. Schließlich (oder zum Glück) ist BASCOM kein INTERPRETER. Also solltest DU eigentlich die Kontrolle über die Maschine haben und behalten! Grundlage wäre eine strikte Beschränkung von BASCOM auf interne Register. Vor 20 Jahren gab es auch leistungsfähige Compiler welche mit 3 (!) Registern ausgekommen sind. Es fällt mir ziemlich schwer zu verstehen, das BASCOM mit 32 Registern scheinbar "gerademal so hinkommt".
Ich bin auf BASCOM gestoßen da ausdrücklich ein InLine-Assembler mit angeboten wird. Dazu ist es unabdingbar wenigstens ein paar Reg. dem User zur Verfügung zu stellen, welche also Nie und Nimmer von BASCOM genutzt werden. Welchen Sinn würde die Assembler-Progr. wohl machen, wenn ich keine Reg. nutzen kann? Als BASCOM-Entwickler kann ich ungefähr abschätzen, welche Anforderungen/Bedürfnisse seitens der (mehr od. weniger prof. Anwender) besteht. Dies ist nicht zuviel verlangt. Also geben die Entwickler diese Reg. bekannt und halten sich an diese Vorgabe. Wo ist denn nun die Schwierigkeit statt 32 Reg. zu verschwenden sich auf 20 zu beschränken? Leider habe ich bislang nirgendwo einen solchen Hinweis gefunden. Natürlich kann ich um das Problem herumarbeiten. Ist aber nicht der Sinn von Software-Engeneering und entspricht überhaupt nicht der RISC-Philosophie.
Seit 20 Jahren bin ich mit einem Ing.-Büro gewerblich tätig und mache leistungsorientierte Auftragsentwicklungen, z.B. für AUDI, Deutsche Bank, Deutsche Bahn, Schering, um einige zu nennen. Ich bekomme nur mein Geld, wenn die abgelieferte Arbeit - welche auf Auftraggeberseite von einigen Dipl.-Ing's gegengeprüft und auseinandergenommen wird - zu 100% läuft. Sonst keine Kohle. Und da ich das seit 20 Jahren so mache, damit meine Taler verdiene und noch nicht Pleite bin, kann ich sagen: ich bin Profi. Sicher wird PicNick mehr Erfahrung auf AVRs haben, da ich Atmel erst seit ca. 4 Wochen programmiere. Sogesehen bin ich Anfänger, klar.
Allerdings habe ich mir mehr erhofft von diesem Compiler und es ist wohl so, das er eben nur 79,-EUR kostet und nicht 7.900,-EUR. Daher ist auch nicht mehr zu erwarten.
Ich habe gestern übrigens die Voll-Version bestellt - bin also guter Dinge. Also schau'n wir mal...
mega128
Achso, den erhobenen Zeigefinger habe ich natürlich zur Kenntnis genommen...
..Welchen Sinn würde die Assembler-Progr. wohl machen, wenn ich keine Reg. nutzen kann?
Das stimmt ja nicht. Du kannst ja alle 32 Register verwenden.
Du solltest nur
r4, r5, FRAME
r6. STATUS
r8. r9. DATA (flash)
r28. r29 SoftStack
danach wieder herstellen.
Aber die Forderung, daß eine Hochsprache definierte Register für inline assembler sozusagen reserviert, ist etwas strange.
Worauf ich mittels Zeigefinger hingewiesen habe, hat nix mit ATMEL und AVR zu tun, sondern mit Programmierung an sich.
Du kannst dein Leben lang bei Rot über die Strasse gehen, und wenn dich kein Auto oder Schupo erwischt, bist du der Gewinner und alle sind doof, die gewartet haben.
So, jetzt steck' ich den Zeigefinger weg. Rufer in der Wüste gibt's schon genug.
@Mega128
Es mag schon sein, dass es Compiler gibt, welche mit 3 CPU-Registern auskommen müssen. Der Unterschied zwischen einer CPU mit 3 oder 32 Registern wie beim AVR ist der, dass sich mit 32 Registern ein wesentlich effektiverer Code hinsichtlich Größe und Laufzeit erstellen lässt.
Es macht glaube ich auch für einen Compiler keinen Sinn, auf Kosten von Codegröße und Geschwindigkeit einige Register freizuhalten, zumal dieses Feature der freien Register nur von einem kleinen Prozentsatz der Anwender wirklich genutzt würde. Die Masse der Anwender hätte dann mit einem nicht so effektiven Code zu leben.
Dass keine Register vom Compiler freigehalten werden ist meines Erachtens keine Manko für BASCOM, sondern die Folge einer effektiven Codierung.
Zu den Register r28 und r29 (SoftstackPointer) möchte ich noch anmerken, dass dieser nicht nur in SUB und Functions benutzt wird, sondern auch in den trigonometrischen Funktionen für SINGLE und DOUBLE, wo Berechnungszwischenergebnisse auf den FRAME gespeichert werden und die Pointer zu diesen Werten im SoftStackpointer (r28,29) verwaltet werden.
OK, vermutlich sehe ich das Ganze etwas zu sehr aus der Sicht des Assembler-Programmierens. Hatte BASCOM ja gewählt wg. der Möglichkeit ASM einzubinden. Nun wird aber der ASM-Anteil bei mir immer größer, dafür ist BASCOM dann doch nicht gedacht.
Liegt vermutlich auch daran, daß ich bislang keinen Compiler benutzte, wo die Möglichkeit der (Sprachen-)Mischung besteht. Ist somit mal was Neues.
Danke für die vielen Hinweise, werde versuchen das Beste daraus zu machen...
Grüße,
mega128
Als Nachtrag hier mal eine Übersicht der Zuordnung von BASCOM internen Variablennamen zu den Registern. Dazu kommen noch die Register, die von BASCOM-ASM-Code belegt werden. Da bleibt nix mehr übrig.
Address(dec) Variable Type
0 ___BTMPR0
0 ___STRA String
4 FRAME Word
6 ___BITSIGNED Bit
6 ERR Bit
13 ___STMPA
16 ___LTMPA
16 ___ITMPA
16 ___SINGLEA Single
16 ___WTMPA
16 ___LTMPC
16 ___BTMPA
16 _A1
16 ___BITTMPA Bit
17 ___WTMPAH
17 _A2
18 ___STMPB
18 _A3
19 _A4
20 ___LTMPB
20 ___ITMPB
20 ___WTMPB
20 _B1
20 ___BTMPB
20 ___BITTMPB Bit
21 _B2
22 _B3
23 _B4
24 ___LTMPC
24 ___ITMPC
24 ___WTMPC
24 _TEMP1
24 ___BTMPC
24 ___BITTMPC Bit
25 _TEMP2
25 ___BTMP2
26 _XLXH
26 ___XL
28 SWSTACK Word
30 _ZLZH
Gut, ich muß aber auch sagen, das auch nicht die Aufgabe einer Sprache ist.
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.