c++ zu c


  • Qualitäter
  • 3877 Aufrufe 39 Antworten

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • 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)
  • Danke für Deine nette Antwort. :)
    Deine zweite kam zwischendrinnen.

    Ich versuche an die llc zu kommen...

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Qualitäter ()

  • 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.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von kufi ()

  • Mist, schon wieder eine Antwort dazwischen.

    Ja, danke.

    Ich versuche es mit llc .

    :bia

    Also bei genauem hingucken ,,ret'' statt ,,return'', da hätte ich selbst drauf kommen können....

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Qualitäter ()

  • Mein erstes C aus C++ Programm, das meine TAB.h einbindet und benutzt.

    :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

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Qualitäter ()

  • Aber bloß keine Klassen mit Code drinnen!

    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.

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von Qualitäter ()

  • 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*

    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von Qualitäter ()

  • Alles versucht. Es hat sich herausgestellt, daß der Luxus in C++ zu programmieren mit llvm 43k Speicher kostet, ein Luxus, den sich kein seriöser C64er Programmierer leisten kann.
  • 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.

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von kufi ()

  • ein richtiger c++ kompiler (einer der c++ direkt in assembler übersetzt) sollte schon zu vergleichbaren ergebnissen wie cc65 führen..... aber mit C als zwischenstufe kommt immer so aufgeblähtes zeug raus, darum war c++ ja lange zeit so verpönt.
  • 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.

    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.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Qualitäter ()

  • junge junge du saugst dir manchmal dinge aus der nase, kaum zu fassen. der c64 kann also nicht nachladen! interessant, ist mir noch garnicht aufgefallen :=)

    contiki beherrscht übrigens dynamisches linken, davon mal abgesehen.
  • 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:

    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von Qualitäter ()

  • 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.

    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.
  • So, ich nehme jetzt meine Tabletten.

    Die werden mir ja gegen Realitätsverlust und Konzentrationsmangel und Wahn und so was alles verschrieben. :bmotz:

    Ja, ich finde keinen T-FTP client, den soll es geben?

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Qualitäter ()

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

    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.

    occultusactus.de/Master/02.JPG

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

    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)

    [Blockierte Grafik: http://www.occultusactus.de/Master/04.JPG]

    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)

    [Blockierte Grafik: http://www.occultusactus.de/Master/05.JPG]

    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?

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Qualitäter ()