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


Das Forum zur C-Control-1
Welche C-Control-Varianten existieren?
Übersicht - Suchen - Neueste 50 Beiträge - Neuer Beitrag - Login - Registrieren
INFO - FAQ - CC2-Forum - CCPro-Forum 

 Re: C-Control am Ende? Kategorie: Verschiedenes (von Stefan Tappertzhofen, Homepage - 27.10.2005 16:41)
 Als Antwort auf Re: C-Control am Ende? von Dietmar - 27.10.2005 11:54
Stefan Tappertzhofen nutzt:  CC1-M-Unit V1.2/2.0, Micro
Hallo,

> gut das Du das ansprichst, ins Nirvana kommt man nämlich nur bei der "neuen" C-Control, da diese Rechen- und GOSUB-Stack vereint und Stacküberläufe, bzw. Stackfehler nicht detektieren kann. Wie es besser gemacht werden kann, zeigt die OM.

Wenn das so besser ist, warum habe ich dann auf meinem PC das gleiche Stacksystem wie auf der neuen M Unit? Hier landet die Rücksprungadresse auch im Stack. Als erfahrener Entwickler kann man sich sowas sogar zu nutze machen und superschnelle und effiziente dynamische Sprung-Rechen-Auswertungen machen, wie man sie z.B. bei großen API Anwendungen in Assembler macht.

> Es würde mich außerdem interessieren, ob Du das von Dir angegebene CCBASIC-Beispiel überhaupt jemals getestet hast. Du vergleichst nämlich Äpfel mit Birnen.

Ich vergleiche den Unterschied zwischen Funktionen und Parametern und der Variante mit AD und DA durch GoSubs. Das hat nix mit Äpfeln und Birnen zu tun, sondern mit einem heute nicht üblichen und irreführenden Programmsyntax von CCBasic.

> Den Rechenstack für die Übergabe von Parametern zu verwenden (wie es nebenbei in vielen Compilaten der Fall ist) magst Du als nicht sonderlich sinnvoll ansehen, es bietet aber den entscheidenden Vorteil, daß dieses Verfahren mit weniger Tokencode zu realisieren ist, also zu kleineren Programmen führt.

Ja genau zwei Byte pro Funktion zum Speichern in die Rücksprungvariable. Jetzt werden Erbsen gezählt. Genau so muss man das aber auch bei Freescale Assembler und auf dem PC machen. Du widersprichst Dich offenbar. Zunächst hieß es die Methode von PUSH und POP würde den Anwender näher an Assembler bringen. Wenn der aber in Assembler wegen Parametern und Rückgabewerten plötzlich nicht mehr dort hin zurückspringt, wo er losgesprungen ist, wird der sich herzlich bedanken. Das verwirrt doch und hat nichts mit Näherbringung an Assembler zu tun.

> Dein Beispiel zu Basic++ erzeugt mit Deinem Compiler 40 Byte Tokencode und belegt 12 Byte User-RAM. (Mit "Option CC1.1" sind es 32 Byte Code

Die 12 Byte RAM braucht man nur für Strings und kann diese ggf. abschalten. Es sind dann also auf der alten M Unit genau so viele Ramspeicherstellen in Gebrauch wie in CCBasic. Die 32 Byte Code ergeben sich u.a. aus einem 3 Byte Sprung am Anfang des Programms, um zum Hauptprogramm zu springen und 2 ENDs am Ende des Programms hinzu kommt noch ein von mit in das Beispiel eingebauten unnützen END Befehl.

Gruß,

Stefan

Meine Homepage: http://www.fdos.de

 Antwort schreiben

Bisherige Antworten:

Re: C-Control am Ende? (von Dietmar - 27.10.2005 22:17)