Library für Bascom erstellen

[Rage_Empire]

Hallo,
hat hier irgendwer schonmal eine eigene Lib für Bascom erstellt? Ich finde, was die externe Libs angeht, ist die Bascom-Hilfe weniger ausführlich.
Ich weiß, daß die Library nur unter Asm unterstützt wird. Kann Basom aus einem Basiccode so ein ASM- File erstellen?
Wie gebe ich die Variablen an die Library weiter, welche verwendet werden?
Kann ich Routinen von einer Lib direkt als Befehl aufrufen?
Sind Routinen von Librarys mit Macros vergleichbar?

Ich Frage, da ich ein Bascomcode habe, den ich gerne in eine Lib verwandeln will. Soll zum Schluß ungefähr so funktionieren, wie die I2C- Library. Aber ich weiß nicht, was ich hierfür beachten muß.

[PicNick]

Die beste Erläuterung, (die ich bis jetzt gefunden habe) steht in der Library Mylib.lib selbst. Du kannst das Zeugs mit dem Notepad aufmachen.
Bascom macht afaik keine .asm dateien aus seinen Sourcen.

[Rage_Empire]

Hm, bissl unlogisch finde ich, daß die Libs ur ASM sein dürfen, obwohl Bascom mit einer Art von Basic interpretiert. Irgendwiehabe ih das Gefühl, daß die Funktion mit Libs nur für Erweiterungen von MCS selbst (die natürlich auch etwas Kosten) gedacht ist.

Wenn ich ein Source von Bascom einfügen will, muß ich es dann wohl erst compilieren und danach disassemblieren und Anpassen. Sehr Bedienerfreundlich.....weil: Könnte ich ASM so gut, bräuchte ich wohl weniger den Bascom-Compiler, und somit auch die Umgebung von Bascom nicht.

@PicNick: Hast du schon mal ne eigene Lib geschrieben und verwendet?

[oe9vfj]

Hallo Rag_Empire,

In der Hilfe ist unter "Mixing ASM and BASIC" einiges zu finden.

Es ist ( derzeit ) mit BASCOM-AVR nicht möglich, BASIC-Code in entsprechenden ASM-Code zu übersetzen. Daher ist also selber in ASM programmieren nötig.

Für die Variablenbehandlung gibt es mehrere Möglichkeiten:

Eine Variable kann mit z.B.

lds r24, {Variablenname}

in ein Register geladen werden. Analog dazu natürlich abspeichern mit

sts {Variablenname}, r24.

Hier kann auch mit Offset gearbeitet werden z.B.: {Variablenname+1}

Während dieses Verfahren für Byte-Variablen gut geeignet ist, ist für Variablen mit mehreren Bytes (Word, Integer, Long, String) die Verwendung eines Variablenpointers besser geeignet.

Loadadr X, Variablenname

Loadadr ist eine Hilfs-Befehl, welcher es ermöglicht mit Variablenpointer in BASCOM-AVR zu arbeiten.
Ist die Variable z.B. auf der Adresse &H123 wird dieser Befehl beim Kompilieren in

ldi xl, &H23
ldi xh, &H01

übersetzt.

Hat man die Adresse einer Variablen in einem der X oder Z Pointer-Register, kann dann mit folgender Sequenz eine Long-Variable in die Register r20-r23 geladen werden:

ld r20, X+
ld r21, X+
ld r22, X+
ld r23, X+

Abspeichern geht analog dazu.

Damit selbst erstellte Lib-Routinen aus dem BASIC aufgerufen werden können, müssen diese wie SUB oder FUNCTION in BASIC deklariert werden und die Library mit $LIB "MyLib.lib" gelinkt werden. "MyLib" steht für den Namen der selbst erstellten LIB.

Die Adressen der übergebenen Parameter, sowie die Adresse eines Rückgabewertes bei einer FUNCTION werden auf dem Y-Pointer (Soft-Stack) gespeichert.

Makros sind nicht mit LIBs vergleichbar. Lib-Routinen sind mit eingebundene Routinen, welche bei Bedarf angesprungen/aufgerufen werden, während Makros direkt beim Makro-Aufruf in den Code eingefügt werden. Eine LIB-Routine wird nur einmal eingebunden, während ein Makro bei jedem Aufruf in den Code eingefügt wird.

Man könnte z.B. die Hilfsfunktion Loadadr als ein Makro bezeichnen.

Grundsätzlich wäre aber zu überlegen, ob ein Portieren eines BASCOM-AVR Programmteiles in eine Library notwendig ist. Es lassen sich mit Librarys Code-Größe als auch Ausführungsgeschwindigkeit optimieren. Falls weder Code-Größe noch die Geschwindigkeit ein Problem sind, können diese Funktionalitäten in BASIC-Code in SUB od FUNCTION verpackt werden und dann von jedem Programmpunkt aufgerufen und verwendet werden. Siehe dazu DECLARE SUB und DECLARE FUNCTION in der Hilfe

[PicNick]

Es ist irgendwo eine Philosophiefrage. Bascom läßt ja zu, daß du an einer beliebigen Stelle "include" sagst und deine Routinen (in Sourceform) einbindest. Außer, daß du sie dadurch natürlich auch jedesmal frisch übersetzt, ist das ja soweit ok und hilft, Programm-Monster-Megalithen zu vermeiden und sich auf diese Weise "Libraries" zu machen.
Wenn du dir die compilierten "*.LIBS" ansiehst, wirst du sehen, daß die Schweinebacke in Wirklichkeit ja nur den Code übersetzt, der keine Absoluten Sprung- oder Datenadressen verwendet. Den rest läßt er ja wie er ist und übersetzt ihn dann mit seiner normalen "inline-assembler" Methode.
So richtige Object-files, wie man sie sonst (vom PC) kennt, sind das ja nicht. Das wär nämlich auch komplizierter, Bascom würde dann auch einen "Linker" brauchen, den er sich so erspart.
Ich selbst:
Da ich die Problemstellung ja auch kenne, bin ich am Überlegen, ein entsprechendes Tool (PC) zu schreiben, daß zum Bascom-Library Erstellen geeignet ist. Da ich doch schon seit einigen Wochen in dem Beruf arbeitet, trau' ich mir das auch zu, wenn es nur nicht so ein grausliches Gefummel wäre. Angeblich will ja jeder Programmierer einmal in seinem Leben eine Betriebs-System und einmal einen Compiler schreiben. Ich weiß nicht, ich hab das Gefühl überhaupt nicht.

[Rage_Empire]

@oe9vfj:
Danke für die ausführliche Antwort. Das mit der Variablenbehandlung habe ich jetzt verstanden. Ja, es geht bei mir um die Größe und um das Handling, deswegen will ich die Lib schreiben.

Was meinst du aber mit

Es ist ( derzeit ) mit BASCOM-AVR nicht möglich, BASIC-Code in entsprechenden ASM-Code zu übersetzen

wird es irgendwann möglich sein? Wäre für mich dann einiges leichter. Weil sonst muß ich mir echt die Mühe machen, Compilieren und Disassemblieren, Anpassen.......
Viel Arbeit und Nerven kostet das dann wieder!

@PicNick:
Ja, richtiger Begriff: Gefummel!!!! Aber so ein Tool, wie du Angesprochen hast, wäre viel ersparniss an Nerven und Zeit........ würde ich sogar kaufen, wenn es dies gäbe!

[PicNick]

Jetzt, wo gerade keiner zuhört, kann ich es ja sagen:
Mein Traum wäre eine Methode, wo man Bascom-, GCC und Assembler- Module untereinander kreuz und quer linken könnte, damit man je nach Problem die Vorteile der einzelnen Sprachen nutzen kann. Aber wie schon gesagt: das stinkt ganz furchtbar nach Arbeit.

[PicNick]

Falls es wen interessiert oder hilft:
Ich hab' in unserere Wiki ein paar Bascom - Interna dargestellt
https://www.roboternetz.de/wiki/pmwi...ain.Bascomcall

[Rage_Empire]

Du meinst so ne Art Allround- Oberfläche? Das wäre echt der Hammer! Aber das gibt es nicht und somit haben wir halt gräusliches Gefummel, was uns alle Nerven und Zeit kostet. Tja, die Welt wäre so einfach, wenn die Welt so einfach wäre.

Und ich finde es immernoch unlogisch von MCS, daß die Libs nur ASM sein dürfen, obwohl Bascom selbst mit einer Abart von Basic interpretiert.

PS: Aber erst als dus erwähnt hast ist mir aufgefallen, das Bascom gar kein Linker benutzt, was mich hätte von Anfang an wundern müssen.

[oe9vfj]

Mark Alberts (der Autor vom BASCOM-AVR) hat wenn ich mich recht erinnere in einer seiner Antworten in der Mailingliste www.grote.net/bascom dies als ein mögliches zukünftiges Feature bezeichnet.
Um in ASM wirklich effektiv arbeiten zu können, sind meines Erachtens schon fundierte AVR-ASM Kenntnisse notwendig.
Da der von BASCOM-AVR erstellte Code schon sehr kompakt ist, lässt sich nur in einem Punkt noch merkbar etwas optimieren:
BASCOM-AVR holt für jeden Befehl die benötigten Parameter/Variablen aus dem SRAM und speichert zum Abschluss des Befehles die Ergebnisse wieder ins SRAM zurück. So ist jeder BASCOM-AVR Befehl quasi unabhängig vom vorhergehenden bzw. nachfolgendem. Sofern aber in einer Befehlssequenz die gleichen Variablen immer wieder verwendet werden, könnten diese in einem gewissen Code-Bereich in den CPU-Registern gehalten werden, wodurch man sich das Abspeichern und neu Laden ersparen würde. Dazu muss aber unter Umständen einiges an ASM-Code umgeschrieben werden, da nicht unbedingt eine Routine mit einer Variablen in den gleichen Registern beginnt, wie eine andere Routine mit der Variablen endet. Weiters muss überlegt werden, welche CPU-Register werden für die Ausführung einer bestimmten Aufgabe benötigt, welche können für die Zwischenspeicherung von Variablen freigehalten werden.
Ein ASM-Listing wäre hier natürlich schon eine gewisse Hilfestellung, aber ist auch einiges an weiterer Arbeit im ASM-Coding notwendig, um wirklich gegenüber dem BASIC-Code noch weiter zu optimieren.


Wenn Du vielleicht etwas konkreter ausführen könntest, was Du vorhast, wäre vielleicht eine zielführendere Hilfe möglich.