Das Forum zur C-Control-1

Achtung! Für dieses Forum muß unbedingt Javascript (Active Scripting) im Browser aktiviert werden.
Hingegen kann und sollte Java aus Sicherheitsgründen immer deaktiviert bleiben.

Das Open-Control-Projekt - Die Alternative zur C-Control-I

Übersicht - Suchen - Neueste 50 Beiträge - Neuer Beitrag - Login - Registrieren
INFO - FAQ - CC2-Forum - CCPro-Forum

Was ist die Politik von Conrad (oder "was den offiziellen Compiler betrifft") Kategorie: Verschiedenes (von Patrick, Homepage - 13.12.2004 20:09)

Hallo Dietmar,
ich fand das, was du gesagt hast, ganz interessant und freue mich, dass du es angesprochen hast.
Ich zitiere dich mal an dieser Stelle, denn Peter's Thread ist schon etwas Ã¼berladen mit Themen,
die nichts mit seiner Frage zu tun haben - ich hoffe mal das ist in Ordnung so ;-)

Es ist doch einem selbst Ã¼berlassen, welchen Compiler man verwenden will.
Auch wenn man als erfahrener CCBASIC Programmierer zunÃ¤chst nicht die Vorteile von
BASIC++ oder mBasic sieht, es ist ein gewaltiger Unterschied, Programme werden durchaus
schneller und Ã¼bersichtlicher, es hilft auch Fehler zu vermeiden. "Go To Statement Considered Harmful", Dijkstra, das war vor 40 Jahren, seitdem benutzt man keine GoTos mehr. Welches CCBASIC
Programm wÃ¼rde aber ohne ein Goto auskommen????

Und eigentlich sollte sich doch Conrad freuen, wenn rund um die C-Control reichlich Software entsteht.
"Eigentlich", weil es ganz so scheint, als wÃ¼rde Conrad mBasic absichtlich ignorieren.
Ich bin vor einiger Zeit (vergeblich wie sich herausstellen sollte) an Conrad herangetreten
und habe mBasic und einige Ideen zur Verbesserung der C-Control vorgestellt:

1. Der Compiler soll die C-Control Typen (M-Unit, PCB, Station,...) sowie die Versionen
als auch das Versionsdatum selbst unterscheiden kÃ¶nnen, damit der Anwender nicht Befehle
kompiliert, die eine bestimmte C-Control gar nicht kennt. AuÃŸerdem kÃ¶nnte einige Befehle automatisch
nachgebildet werden (das macht z.B. mBasic mit NAND fÃ¼r die Micro/PCB).
Weiterhin kÃ¶nnten so Bugs automatisch behoben werden (das macht mBasic z.B. bei DOW fÃ¼r V1.1).
Das kann man nur dann konsequent fÃ¼r alle Typen und alle Versionen realisieren,
wenn man entsprechende Informationen darÃ¼ber hat oder bekommt!

2. Die erweiterten Funktionen Ã¼ber zusÃ¤tzliche Tokens ansprechen nicht Ã¼ber "PRINT" Umleitung.
Das verbraucht weniger Speicherplatz. Die Print Umleitung existiert nur, da man den alten Compiler
weiterverwenden musste

3. Assembler in speziell gekennzeichneten Assembler BlÃ¶cken. Die Assembler Befehle kÃ¶nnen nur
auf die BASIC Variablen oder Register zugreifen. Dann kann der Anwender Assembler programmieren,
aber nicht das Betriebssystem auslesen, und alle wÃ¤ren glÃ¼cklich.

4. Mit ganz einfachen zusÃ¤tzlichen Tokens kann kompiliertes BASIC enorm beschleunigt werden.

5. mBasic ist fÃ¼r jeden gegen kostenlose Registrierung uneingeschrÃ¤nkt nutzbar, das bleibt auch so.

So, und das war Conrad's Antwort zu meinen VorschlÃ¤gen:

""

(Das ist Ã¼brigens ein leerer String, denn Strings gibt es auch inzwischen in mBasic)

EnttÃ¤uschend, aber dabei hÃ¤tte doch irgendetwas dem groÃŸen Conrad dazu einfallen mÃ¼ssen.
Ich erwarte keine Anerkennung, aber wenigstens ein "Nein". (Vielleicht scheut sich ja jemand vor der
Mehr-Arbeit, die ich da ins Haus trage)
Aber wer kennt Conrad's Sturheit besser als seine Kunden -
Und zum GlÃ¼ck waren die mBasic Anwender (derzeit 112 registriert) ja auch kontaktfreudiger!
Die vielen Mails, Lob und die zahlreiche Ideen waren da schon weitaus mehr motivierend :-)
Ich freue mich auch Ã¼ber Hilfe, so kann ich bald "mit tatkrÃ¤ftiger UnterstÃ¼tzung" neue Befehle
fÃ¼r das C-Control Modem einbauen, und der eine oder andere hat schon angekÃ¼ndigt sein Projekt als
Beispiel beizusteuern. Ich warte auch noch auf die versprochene Displaysteuerung fÃ¼r alle C-Controls!
Gerne hÃ¤tte ich auch einen speziellen Emulator oder Simulator fÃ¼r die V2.0 geliefert, aber Conrad
ist daran nicht interessiert, und ohne Infomaterial geht es eben einfach nicht...
Ãœber den Interpreter und das Betriebssystem der anderen Versionen weiÃŸ niemand etwas so genau,
wenn man sich aber auf Conrad's "abwÃ¤rtskompatibel" verlassen darf, sollte mBasic auf allen
C-Controls problemlos laufen.
Da auch zukÃ¼nftig nicht mit UnterstÃ¼tzung von Conrad zu rechnen ist, mBasic aber noch nicht alle
MÃ¶glichkeiten des Machbaren voll ausschÃ¶pft, soll es auch auch kompatibel zu den Atmel AVR Mikrocontrollern gemacht werden (da mÃ¼sste auch noch ein neuer Assembler her).
WÃ¼rde mich Ã¼ber Meinungen freuen, die altbekannte BASIC++ Lobby hat sich ja schon
geÃ¤uÃŸert (und ich nehme das als Kritik auch sehr ernst)
Viele GrÃ¼ÃŸe,
Patrick

Also ganz zum Schluss noch der Link zum INoffiziellen C-Control Compiler :-)

Ich kann wirklich nicht verstehen, wieso BASIC++ von Conrad als offizielle Programmiersprache auserkoren worden ist. (CC)BASIC++ enthÃ¤lt weder einen Emulator, noch einen Simulator noch ist die MÃ¶glichkeit vorgesehen, in Assembler zu programmieren!

Das ganze Projekt wirkt nicht nur dadurch extrem unseriÃ¶s. Ich habe die Entwicklung von "BASIC++" mitverfolgt und dabei etliche Versionen ausprobiert. Die ersten zum Download angebotenen Versionen waren derart buglastig, daÃŸ es kaum in Worte zu fassen ist. Und auch jetzt stolpert man immer noch Ã¼ber Bugs. Wenn zum Beispiel in der IDE 'Ã–ffnen' ausgewÃ¤hlt wird, erscheint ein Requester, der abfragt, ob der Quellcode gespeichert werden soll, obwohl Ã¼berhaupt nichts programmiert oder an der Datei verÃ¤ndert worden ist! Ich denke, daran wird deutlich, wie ein Programmtest vor der VerÃ¶ffentlichung durchgefÃ¼hrt wird. Das erinnert in fataler Weise an die Politik von Conrad Electronic bei der EinfÃ¼hrung der neuen C-Control-Varianten.

Und schlieÃŸlich stolpert man dann auch noch Ã¼ber Rechtschreibfehler in der "Entwickler Referenz", die den LesefluÃŸ extrem hemmen. Siehe "Beispiel Code", "Syntax Definitionen", "Mikrocontroller Entwicklung", "Compiler Version", usw. Hochtrabend ist die Rede von der neuen Version des "bewÃ¤hrten" BASIC++-Compilers. Seltsam nur, daÃŸ bis jetzt erst Version 1.0.0 erschienen ist?

Das folgende Zitat stammt aus dem Manual, steht aber auch auf der Support-Side zur "Next Generation", und enthÃ¤lt eine wissentlich falsche Aussage:

Der Ausspruch "BASIC ist langsam" stammt aus der Zeit, als BASIC auf dem Computer als Quelltext gespeichert war und der gesamte Text bei der AusfÃ¼hrung erst gelesen und interpretiert werden musste.

Dem unbefangenen Laien vermittelt sich der Eindruck, BASIC++ wÃ¤re dadurch im Vergleich zu anderen BASIC-Dialekten besonders leistungsfÃ¤hig. Richtig ist hingegen, daÃŸ sÃ¤mtliche BASIC-Interpreter nicht Quellcode, sondern BASIC-Token ausfÃ¼hren. Der Quellcode wird bereits vor der ProgrammausfÃ¼hrung in diese Token konvertiert. Diese Konvertierung bezeichnet Conrad Electronic als Kompilierung, was weder ganz falsch, noch ganz richtig ist. Und der Ausspruch "BASIC ist langsam" stammt aus der Zeit, als es nur diese BASIC-Token-Interpreter gab. Hingegen Ã¼bersetzt ein echter Compiler einen Quellcode nach Maschinensprache - wobei auch das noch kein QualitÃ¤tsbeweis ist, da es auch etliche Compiler gibt, die uneffektiven Code erzeugen. DarÃ¼ber wurde aber schon an anderer Stelle in diesem Forum diskutiert.

Die Programmiersprache MBASIC wirkt durch den Emulator und die MÃ¶glichkeit, in 6805-Assembler zu programmieren deutlich leistungsfÃ¤higer als BASIC++. Hat jemand von Euch MBASIC mal auf Herz und Nieren getestet? Die Registrierung ist bekanntlich kostenlos und geht sehr schnell!

GruÃŸ, Dietmar

Meine Homepage: http://home.tiscali.de/mbasic

Antwort schreiben

Bisherige Antworten: