Hallo Besucher, der Thread wurde 6,7k mal aufgerufen und enthält 39 Antworten

letzter Beitrag von Qualitäter am

c++ zu c

    Zitat

    Und vor allem, was auch immer in dem File drinsteht, es ist alles nur kein C-Code, schaut teilweise sogar wie x86 Assembler aus.


    das ist "b code", sprich das was llvm als zwischencode benutzt, das hat in der tat mehr mit assembler als mit C gemein.


    man sollte das aber mit iic nach C übersetzen können (anleitung lesen UND verstehen soll angeblich manchmal hilfreich sein :=D)

    Das ist leider immer noch kein C, und immer noch versetzt mit x86 Assembler.


    So schaut ANSI C-Code aus (und nichts anderes kann CC65):


    #include <stdio.h>
    #include <stdlib.h>


    main()
    {
    printf("Hello, World!");
    }


    Und nicht


    %tmp.0 = load double* %Klassenanzahl ; <double> [#uses=1]
    %dec = sub double %tmp.0, 1.000000e+00 ; <double> [#uses=2]
    store double %dec, double* %Klassenanzahl
    %tmp.3 = load double* %hoechst ; <double> [#uses=1]
    %tmp.4 = div double %dec, %tmp.3 ; <double> [#uses=1]
    %tmp.1.i = mul double %tmp.4, 1.000000e+02 ; <double> [#uses=2]


    Sorry, no chance.

    :bussi:


    Es klappt ! :@1@:


    Was habe ich gemacht?


    0. NACH EINIGEN FEHLVERSUCHEN NEU INSTALLIERT


    1. llvm Version 1.7 das neuste Frontend als Binärpaket runtergeladen und ./fixheaders
    ausgeführt. Mit PATH=$PATH:/prg/llvm ..... am Ende der /etc/profile die binären Dateien, die vorkommen gepathed und neu gestartet!


    2. den llvm-nicht-Testversion-source runtergeladen und mit configure und make all nur installiert - das Zeugs meckert zwar, aber dann doch vollständig. Die Binis ins Path-Verzeichnis!


    3. Mit einer kleinen ,,Textoberfläche'' test.cpp die TAB.h eingebunden und mit llvm-g++ es zu einer .bc gemacht und dann weiter mit llc -f -march=c (also doch zwei Optionen!) zur .c, die SEXY-c aussieht und diesmal auch ist!


    4. Gegenprobe mit cc kompeliert und läuft.


    Tipp: cout macht das C-Programm nicht falsch, aber kompliziert und unsexy.


    Es klappt! :@1@:


    Nun werde ich wieder alle Programmteile einbinden, die ich aus Testzwecken raustat, oder besser: Nur die, die ich dem C64er zutraue....


    :freude

    Kommt jemand auf die Idee etwas Code reinzutun, jedenfalls soviel, wie man braucht, dann das:


    :aerger:
    too many local variables



    Also ein anderes Problem ist, das bei minimalem Aufwand


    Progrämmchen


    42K großes Programm rauskommt und


    man noch mit Hand die von cc65 schon geleistete malloc.h rausschmeißen muß, weil da zwischen vielen Betriebsystemen unterschieden wird, aber c64 ist offensichtlich nicht so bekannt, wie atari, sun oder apple.

    das war eigentlich zu erwarten das das nicht funktioniert mit dem wandeln von c++ :=P


    aber welchen c++ compiler für den c64 meinst du?


    cc65 hat aber eine option die alle lokalen variablen zu statischen globalen variablen macht, damit kannst du das problem etwas umschiffen - vorausgesetzt der code muss nicht reentrant sein, was ich bei gewandeltem c++ dann schon wieder bewzeifel :=P

    -relocation-model=static (also noch von llc)
    Aber da scheint der Compiler zwischendurch einfach Variablen ,,zu vergessen''.


    Das Progrämmchen zeigt, daß Hochzählen und Runterzählen im Konstruktor und Detruktor nicht unter 43 k zu haben sind.


    Und in Contiki habe ich 14 k noch für jeweils eine Programmstufe.


    UND NUR UM C++-Code zu benutzen?


    Viel wichtiger:


    1. Wann kann ich Dateien ,,hochsenden''`?


    2. Da scheint es irgendein Problem mit der Statusleitung schon beim Runterladen zu geben?


    3. Habe ich mit dem Final Replay 96k Speicher, also mehr? *wunder*

    Verdammt, dann können wir Java und .NET vergessen... ;)


    Sorry, konnt ich mir nicht verkneifen... aber die geeignetste Programmiersprache für den Brotkasten (sowie praktisch alle 8-bitter) bleibt nunmal Assembler, und evtl. so sachen wie Forth etc. Und natürlich speziell angepaßte C-Compiler wie CC65, wobie ich mir einen speziellen C++ Compiler schon vorstellen *könnte*, aber die 6502-Architektur ist ja schon mit C ziemlich "gestretcht". Alles andere führt zu zuviel Overhead als daß man in 64K mehr als "Hello World" zustandebringt.

    Zitat

    Nun, ich denke daß aufgrund der Vererbung und dem ganzen anderen Schnickschnack der Overhead größer sein dürfte als bei reinen C-Programmen.


    ja sicher, es kommt natürlich auf die features an die man benutzt :) wenn man c++ hauptsächlich wegen der klassen und "schöneren" syntax benutzt gibts da keinen grossartigen unterschied.


    Zitat

    Und ob C-64-Programme jemals so groß werden daß sich der OO-Krempel lohnt ist ohnehin die Frage, ich denke mal eher nicht.


    das würde ich so nicht sagen...für einige aufgaben ist OO schon hilfreich, mir würde da spontan eine adventureengine mit manipulierbaren objekten einfallen, sowas ist in c++ wesentlich angenehmer zu implementieren.

    c++ würde sich dann lohnen, beherrsche der C64er das Nachladen.


    Und das kann c++ besser als c, man kann ganze Klassen wegspeichern und das auch als Hintergrundklasse.


    UND DAS IST DER PUNKT!


    Mit viel Aufwand ist mein Listengenerator von mir geschrieben worden, um ggf. automatisch Klassen wegzuspeichern, schön nummeriert.


    Nie benutzt, weil XP und Linux selber das mit dem Speicher regeln.


    Und der Overhead von 43k, davon sind bestimmt 30k tatsächlicher, da bleibt nicht viel mehr übrig um mit großem Aufwand eine Nachladeroutine zu schreiben, bei der sind die 60k sofort erreicht.




    Denkbar wäre eine Swaproutine in C für C++ auf Contiki.
    Aber ihr helft mir offensichtlich nicht einmal bei dem FTP-Upload.

    wow, dynamisches linken *träum*


    Nur doof, wenn man dann tftp benutzen muß! :hammer:
    :hammer:
    Unter Linux benutze ich .so Dateien.
    Kann ich so etwas auch machen, oder heißen die dann .drv?
    :hammer:
    Nachladen ja und nein.
    Contiki stellt Dir eben nicht den :hammer: freien Diskettenplatz als Speicher zur Verfügung!


    Und Programme sind in ihrer größe beschränkt auf den freien ,,physikalischen Speicher''!


    :hammer:

    Zitat

    Unter Linux benutze ich .so Dateien. Kann ich so etwas auch machen, oder heißen die dann .drv?


    wie die dann heissen ist doch völlig wurst oder nich? so ziemlich alle files im contiki system werden dynamisch gelinkt.


    Zitat

    Nachladen ja und nein. Contiki stellt Dir eben nicht den freien Diskettenplatz als Speicher zur Verfügung! Und Programme sind in ihrer größe beschränkt auf den freien ,,physikalischen Speicher''!


    ehrm ja, das geht aber ohne hardwareunterstützung, sprich mmu, kaum anders. das musst du als programmierer schon selber managen.

    HSuH Listengenerator V16.5 - Version ,,Master''


    http://www.occultusactus.de/Master/01.JPG


    Das kennt wohl noch jeder von Euch, so sieht mein Rechner aus, nachdem Windoof hochfährt, alle C64er Programme oben, ich hoffe ihr probiert mein kleines Cpp-Programm aus.


    http://www.occultusactus.de/Master/02.JPG


    Die neuste Flashfassung, fast so wie ohne schön.


    http://www.occultusactus.de/Master/03.JPG


    Mein Startbild (abgewandelt vom Hallo world Programm) aber natürlich nicht ohne Intelligenz, gleichzeitig lädt der Deutsche Zeichensatz hoch (eine Abwandlung von Plasma.c)



    Diese Datei habe ich einfach im Editor vor dem Zusammenfassen der .d64 erstellt und wird trotz Ascii mit Umlauten korrekt dargestellt. (das waren so 10 Stunden Arbeit)



    Ach ja, ich arbeite mit äquivalenten Klassen aus der Objektorientierung (*Finger wund* da c++ llvm-umgewandelt zu viel Overhead 30k)


    So, wer mag mir nun endlich beim Hochladen ohne WARPCOPY helfen, eigenständig, wie es anständig ist?