Bascom Bug melden

[kritias]

Ich gehe da immer so vor:
ich schließe zeitkritische Teile mit einer Menge NOP ein und kompiliere das ganze. Das Ergebnis sehe ich mir dann im AVR-Studio in Assembler an. Durch die vielen NOPs ist die Stelle auch leicht zu finden. Den Zeitkritischen Assembler-Teil optimiere ich dann. Also das unnötige wegspeichern der Register entfernen, so wenige wie möglich Register verwenden und was einem sonst so auffällt. Dann muss ich im Falle eines Interrups nur noch die verwendeten Register sichern. (Nosave!) Dabei hat Bascom noch nie etwas einfach so geändert.Die NOPs kommen nach getaner Arbeit weg. Verzählen darf man sich halt nicht wenn man den Stack von Hand beackert. Da hab ich schon meine bösen Überraschungen erlebt. War dann aber meine Dummheit und kein Fehler von Bascom.

[Searcher]

Ich gehe da immer so vor:
.
.

Ja, so oder so ähnlich werde ich das auch in Zukunft machen. Ich war halt total überrascht, daß ein Assemblerbefehl ausgetauscht wurde. Mit gutem und richtigen Grund, da ja auf einem ATTiny25 ein SBI GIFR,PCIF nicht möglich ist. Das sollte aber bei einem Assembler Befehl nicht ohne dicke rote Warnung geschehen. Der Compiler/Assembler hat ja erkannt, daß da etwas nicht paßt und könnte eben auch eine Meldung erzeugen. Vielleicht wurde auch in höheren Versionen da schon etwas vorgesehen.

Bei LOADADR mit einem indirekt adressierten Array als Argument würde mich ein Hinweis auf das zusätzlich verwendete Register zufrieden stellen

Ich hatte bisher in nosave ISRn immer nur die Register gesichert, die ich auch selbst in der ISR verwendet habe. Trotz der möglichen Verbesserungen finde ich den einfachen Gebrauch von Assembler innerhalb von Bascom Programmen genial.

Gruß
Searcher