www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Test BASCOM - ASM


Autor: Uwe (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ein Test zwischen BASCOM(Demo) und ASM (Studio4)

Ich erspare mir jeden Kommentar.

MFG Uwe

Autor: emil (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hm, heisst das, dass bascomavr die aufgabe am besten gelöst hat 
(betrachtend die file-grösse)? bitte um verzeihung für die dumme frage, 
bin nämlich neu, ein Kommentar würde mich doch erleuchten... :)

Autor: daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi
Ich kapier net ganz was das zeigen soll??
Die Dateigröße dieser Dateien spielt doch überhaupt keine Rolle!!!  Die 
Studio 4 Datei ist so groß da einfach die komplette ".inc" kopiert 
wurde.

Autor: Dieter Brüggemann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich halte den Vergleich auch für wenig aussagekräftig.

Bei kleinen Prgrammen ist der Codeüberhang bei Bascom und auch bei GCC 
viel größer, als wenn man es direkt in Assembler macht. Code Grösse ist 
aber auch nicht alles.

In Bascom komme ich am schnellsten zu Ergebnissen, die ich dann in GCC 
übertrage, weil ich da noch mehr Möglichkeiten habe. Mit Assembler 
möchte ich heute keine grösseren Sachen mehr machen und werde es auch 
nicht.

Ich halte Bacom gerade für Einsteiger gar nicht schlecht, da man schnell 
ein Erfolgserlebniss bekommt. Umsteigen kann man dann immer noch, wenn 
es dann sein muß oder man es möchte.

Man sollte aber schon bei jeder Sprache wissen, was der Chip wie, wann 
und wieso tut.

Das soll aber auf keinen Fall heißen , daß ich Assembler hasse. Die 
Sprache hat auch Ihren Reiz und macht viel Spaß. Man muß halt, wie bei 
jedem Porgramm, viele Kommentare schreiben, damit man nach 2 Wochen noch 
weiß, was die Zeile macht und wieso.

MFG
Dieter

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!
Die Dateigrösse ist nicht wichtig, die Codegrösse und das wie ist das 
entscheidende.(Man beobachte die letzte Zeile der *.lst Dateien)

@Dieter
<Code Grösse ist aber auch nicht alles.

Deswegen halte ich mich da ja auch zurück.

Gruss Uwe

Autor: Sascha Weitkunat (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du glaubst doch nicht wirklich dass Bascom in der lage ist "bessere" 
Programme hervorzubringen als solche die in puren Assembler programmiert 
worden? Ja zum Himmel, in welche Märchensprache soll Bascom denn bitte 
übersetzen? Assembler ist nunmal die letzte direktive, wenn man es 
kann/will sind somit die schärfsten Espressoprogramme (klein, schwarz, 
stark) hinzubekommen, ein Hochsprachencompiler ist dort nur eine weitere 
Stufe um es uns einfacher zu machen, allerdings nicht dem Prozessor.

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja, wenn du ein geistiges Genie bist, dann wirst du in asm immer besser 
sein als jeder Compiler. Das nächste Problem: hast du ewig Zeit, ein 
Programm zu optimieren? Kannst du in einem Assemblerprogramm (sogar 
deinem eigenen, geschweige in dem Code eines anderen) nach einem Jahr 
noch zusätzliche Funktionen unterbringen? In einem hochoptimierten Code 
ist das so gut wie aussichtslos. Selten genug kommt es auf das letzte 
Byte und den letzten gesparten Taktzyklus an, und wenn doch, liegt es an 
mangelhafter Vor/Grobplanung.
Machen wir uns doch nichts vor, 90% aller AVR-Anwendungen verbringen 
jede Menge Zeit mit Nichtstun, das einsparen von ein paar Takten ist 
meist kein Argument.
Und wenn das Programm komplexer wird, hast du alle Hände voll zu tun, 
alle Variablen im Griff zu halten, die Parameterübergabe zu 
organisieren, Funktionen einzubinden oder gar selbst in asm zu 
schreiben. Der Test/Fehlerbeseitigung eines solchen Programmes nimmt 
wesentlich mehr Zeit in Anspruch als das Schreiben selbst. Und wenn du 
einen Fehler ausbügelst, kann es durchaus sein, daß du dir einen anderen 
gleich wieder mit einbaust. Außerdem soll man die 
Optimierungsmöglichkeiten moderner Compiler nicht unterschätzen, man hat 
sogar die Wahl, in welche Richtung optimiert werden soll. Schnellere 
Laufzeit -> mehr Code und umgekehrt, das ist nun einmal so. Was tust du 
mit einem asm-Programm in dieser Richtung?
Lass mal gut sein, wenn deine Programme sich darauf beschränken, 
Schalter abzufragen und dementsprechend LEDs an-und auszuschalten, gebe 
ich dir Recht, da brauchts keinen Compiler.

Autor: Sascha Weitkunat (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Natürlich weiss ich die Vorteile eines Compilers zu schätzen, aber 
nichts desto trotz ginge es meist wohl besser, kürzer und schneller. 
Aber das ist ja garnicht der springende Punkt in diesem Thread, es geht 
um die Tatsache dass der Glaube besteht dass das Ergebnis eines 
Compilers (Bascom) viel besser sei als die Variante in reinem Assembler. 
Und hättest du dir Uwes Dateianhang einmal zu Gemüte geführt, Herr crazy 
hore, dann hättest du gemerkt dass es um reines "Tasten abfragen und 
LEDs schalten" geht. Bei einem komplexen Programm währe der 1:1 
Vergleich zur Assembler-Variante auch nicht mehr nachvollziehbar, also 
der gesamte Vergleich unnützt.

Autor: Sascha Weitkunat (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bitte den unpässlichen Fehler zu entschuldigen, wohlwissend was der 
Verhaspler bedeutet... Sorry

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wenn schon "Herr", dann bitte auch "Sie", soviel Zeit muss sein :-)
Ansonsten sind wir uns wohl einig.

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!
Was meint ihr eigentlich warum ich mich jeglicher Wertung enthalten 
habe? Eben weil es viele gibt die Bascom nutzen und die damit gut 
zurechtkommen, sollen sie ja auch. Für mich war es nur mal von Interesse 
zu wissen wie gross denn ein solcher Code wird und das muss man doch 
nicht für sich behalten, zumal man immer wider liest das die 
verschiedenen Compiler ja so fantastisch kurzen Code erzeugen. Ich war 
jedenfalls über die Verschwendung an Code erschüttert.Ihr müsst eben 
auch mal hinschauen. Leider gibt es eben immer Leute,die nur auf dem 
Thema "ASM, Sinn oder Unsinn" rumhacken. Schade!
Gruss Uwe

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und genau das ist der Punkt: solange das compilierte Programm in den 
Programmspeicher passt, ist es doch völlig wurscht, wie groß der Code 
ist, das ist kein Nachteil, die Vorteile bleiben aber erhalten.
Außerdem ist es so, je komplexer ein Programm ist, desto mehr 
Optimierungsspielraum ergibt sich für den Compiler, da können 
Programmteile mehrfach genutzt werden, die du als Assemblerprogrammierer 
gar nicht mehr siehst und froh bist, daß das Programm überhaupt läuft.
Ich verstehe dein Problem nicht, sorry.
Ansonsten kommt es entscheidend auf den Compiler selbst an.
Ich arbeite mit CodeVision und habe relativ regen Kontakt mit Pavel 
Haiduk, wenn ich Zeit und Lust habe, durchforste ich das erzeugte 
asm-File, wenn ich Verbesserungsmöglichkeiten sehe, schreibe ich ihm 
das, und schwups, gibts eine neue Version. Davon lebt der Compilerbau, 
niemandem ist es möglich, den perfekten Compiler "auf der grünen Wiese" 
zu schreiben, das ist ein Entwicklungsprozess.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.