BASCOM und ASM

@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/ze...ag.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...

Zitat:

&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?

Zitat:

,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...

Zitat:

..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.

Code:

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