Hallo linux,
da warst Du aber schon früh unterwegs.
Den Konflikt sehe ich auch, bevor ich zu Bascom kam hatte ich mich soweit es ging informiert. Assembler zu nutzen ist wichtig für mich, da ich zeitkritische Echtzeitanwendungen habe, aber auch langsame Sachen die locker in Bascom programmiert werden können. Auch kann ich "auf die Schnelle" etwas in Bascom ausprobieren und wenn alles läuft und zu langsam wird, Teile davon in ASM übersetzen. Es ist ja nicht immer der Zeitgewinn bei der Abarbeitung und der Speicherplatzgewinn.

Mega8 nutze ich z.Zt. nicht, wenn es so im DB steht dann muß sich Bascom natürlich daran halten. Bei meinen eigenen Versuchen ging es um die Frage: warum verbraucht Bascom an bestimmten Stellen soviel Speicher. Auch die Optimierungsfunktion bringt nicht viel (bei mir ca. 50 Byte Optimierung bei 4000 Byte Flash). Da bin ich drauf gekommen das JMPs & CALLs standardmäßig umgesetzt werden und leider nicht in Abhängigkeit vom (nahen) Sprungziel. Also habe ich mein Progr. selbst optimiert und alle GOSUBs durch RCALLs ersetzt und alle GOTOs (soll man ja nicht haben) durch RJMPs. Und siehe da: plötzlich hatte ich wieder 10% mehr Speicherplatz... (arbeite noch mit der DEMO, muß etwas mit Speicher geizen).

Ich sehe es bis jetzt so: Bascom bietet wahnsinnig viele Funktionen die die Arbeit schon erleichtern können (Vorteil). Dadurch wird aber auch ein Überhang an Code generiert, der nicht wirklich gebraucht wird (z.B. der JMP nach 10 Zeilen weiter), der aber gegen Not und Elend auch nicht falsch ist. Dies ist auch bei Speicherfressenden Befehlen so,
Beispiel:

LCD Voltage ; " mV "
LCD Hex(indat) ; " "
LCD Freq ; " Hz "

Diese paar Zeilen verbrauchen fast 400 Byte kostbaren Speicher. Werden die Befehle an einer anderen Stelle im Programm erneut benutzt werden wieder 400 Byte fällig. Na warum denn? Weil Bascom die Zeilen strikt nach den festen Muster übersetzt ohne bei gleichen Befehlen eine JUMP-Table einzurichten. >Also mache ich das in Assembler selber.

Natürlich, ab einen bestimmten Punkt macht dann Bascom keinen Sinn mehr. Aber ich wollte hier nicht über Bascom meckern, sondern sogar demnächst die Voll-Version ordern. Man muß die vielen Tücken nur kennen und umschiffen, dann kann Bascom insgesamt für den Anwender viel leistungsvoller werden. Dazu Suche ich hier im Board halt noch Anwender, die - Hobby od. Beruf - Bascom konsequent mit Assembler gemischt anwenden: erst dann kann der Compiler voll und effektiv genutzt werden (nur meine Meinung).

Wer natürlich kein Assembler-Progger ist, der ist mit 100% Bascom vermutlich gut bedient.
Gruß,
Mega128.