BASCOM und ASM

[-tomas-]

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

[PicNick]

&H1F <-> 0x1F was hat mich dass schon für Zeit gekostet...

*rofl* Frag mich mal

[Mega128]

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?

[PicNick]

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

[Mega128]

@ 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

[Mega128]

Achso, den erhobenen Zeigefinger habe ich natürlich zur Kenntnis genommen...

[PicNick]

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

[oe9vfj]

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

[Mega128]

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

[-tomas-]

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