C Compiler für 6502

Es gibt 16 Antworten in diesem Thema, welches 3.254 mal aufgerufen wurde. Der letzte Beitrag (13. Oktober 2009 um 18:51) ist von peiselulli.

  • Auf der Bitte melde dich an, um diesen Link zu sehen. Seite sind ja viele C-Compiler für den 6502 gelistet. Aber neben dem bewährten CC65 gibt es nicht sehr viele Alternativen an freien/kostenlosen Compiler:

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.


    Vielleicht wäre auch Forth eine Alternative zu C. Es gibt zwei oder drei Forth Compiler für den 6502.


    Entwickelt jemand mit einem der Tools oder hat jemand Erfahrung damit?

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Entwickelt jemand mit einem der Tools oder hat jemand Erfahrung damit?


    Aztech kennt nur K&R-C, kein ANSI.

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • quetzalcoatl ist kein c-compiler, sondern irgendwas das eine c-ähnliche sprache halbwechs kompiliert :) ich finde nur als spielzeug zu gebrauchen....

    aztec-c ist mal, vor 20 jahren oder so, ein echt guter crosscompiler gewesen.... mitlerweile aber sowas von obsolet :) cc65 ist in jeder hinsicht besser.

    den lcc port da kannte ich aber nicht (auf er verlinkten webseite gibts btw auch noch den alten GCC port für 65c02) ... LEIDER kein source dabei, sonst würde ich mir das glatt mal anschauen und mit cc65 vergleichen. (vermutlich hat auch hier cc65 die nase vorn, aber man weiss ja nie)

  • den lcc port da kannte ich aber nicht (auf er verlinkten webseite gibts btw auch noch den alten GCC port für 65c02) ... LEIDER kein source dabei, sonst würde ich mir das glatt mal anschauen und mit cc65 vergleichen. (vermutlich hat auch hier cc65 die nase vorn, aber man weiss ja nie)

    Wenn man googelt nach dem LCC65 findet man schon ein paar Meinungen zu dem Teil. Sinngemäß zusammengefasst: frontend super, backend scheisse


    Den Source könnte man sich recht leicht bilden. Der normale LCC ist im Source Verfügbar, das Backend gibt "nur" Assemblercode aus. Es gibt beim LCC ja nur eine begrenzte Anzahl an Pseudo Operationen. Die kann man sich einmal vom Binary erstellen lassen, danach kann man zuordnen wie welche Pseudooperation umgesetzt wird.

    Aber wenn man den Meinungen in den diversen Diskussionen glauben kann, ist das Backend derart schlecht dass offenbar nicht mal minimale optimierung gemacht wird.

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Zitat

    Den Source könnte man sich recht leicht bilden. Der normale LCC ist im Source Verfügbar, das Backend gibt "nur" Assemblercode aus. Es gibt beim LCC ja nur eine begrenzte Anzahl an Pseudo Operationen. Die kann man sich einmal vom Binary erstellen lassen, danach kann man zuordnen wie welche Pseudooperation umgesetzt wird.

    ich glaube du unterschätzt die arbeit die auch das bischen noch macht :) ich hab mir vor einiger zeit mal den lcc port von jolze für den 65816 angeschaut und wollte den auf 6502 zurückbauen, habs aber dann irgendwann drangegeben.... darum würde ich doch gerne mal in ein mehr oder weniger funktionierendes backend sehen (und eventuell ein wenig verbessern).

    Zitat

    Aber wenn man den Meinungen in den diversen Diskussionen glauben kann, ist das Backend derart schlecht dass offenbar nicht mal minimale optimierung gemacht wird.


    das stimmt wohl, die meissten lcc backends rotzen einfach den code raus.... was aber nicht sooooo das problem ist, denn viele optimierungen lassen sich auch nachträglich mit einem anderen program machen. mich würde in erster linie halt interessieren in wie weit dieser compiler dann standard-konform und bugfrei ist, und falls sich herausstellt das er in den punkten mit cc65 mithalten kann könnte man sich noch immer gedanken um weiteres machen :)

    mmmh. und ich hab jetzt auch bischen rumgesucht und finde aber nichtmal ne email adresse wo man mal wegen dem source anfragen könnte... schade

  • darum würde ich doch gerne mal in ein mehr oder weniger funktionierendes backend sehen (und eventuell ein wenig verbessern

    Ich bin überzeugt den Source würde man evt. bekommen. Es gibt da eine Seite bei Oric die geradezu aufruft sich an Implementierungen und Verbesserungen zu beteiligen, da wird auch der Compiler, real Zahlen , libs etc. angedeutet. Ich poste den Link wenn ich ihn wieder finde ...


    Edit: Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • die hab ich auch schon gefunden... aber ne email adresse sehe ich da auch keine :) scheint auch nur ne deutsche version der französischen oric seiten zu sein, da steht genau das gleiche. mmmh. ich probiers mal mit dem kontaktformular, vielleicht meldet sich ja einer :)

    edit: nicht die englischen sondern die französischen meinte ich natürlich :)

    Einmal editiert, zuletzt von sauhund (22. September 2009 um 17:57)

  • Ich hab mir jetzt das Buch zum LCC (A Retargetable C Compiler: Design and Implementation) bestellt. Inzwischen ist es da.


    Möglicherweise versuche ich mich mal an einem 6502 Backend, so zum Spass. Ich bin noch nicht eins mit mir, ob ein 6502 Backend oder ein P-Code Backend + Interpreter für einen 8 Bitter mehr Sinn macht. Das beste wäre natürlich, wenn man jederzeit "umschalten" könnte. Mit einer Bitte melde dich an, um diesen Link zu sehen. Anweisung oder gleich Modulweise.

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Bitte melde dich an, um diesen Link zu sehen.

    da gibts zumindest den lcc port als source, die variante da spuckt eine art 32 bit pseudo assembler aus, der dann mittels macros nach 6502 übersetzt wird

  • Cool, danke für den Link. Das muss ich mir demnächst mal genauer ansehen.

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Reine Neugier: Was genau ist eigentlich Dein Ziel? Nur mal so rumspielen oder was erreichen?

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

  • Reine Neugier: Was genau ist eigentlich Dein Ziel? Nur mal so rumspielen oder was erreichen?


    Compiler haben mich immer schon fasziniert, vor allem C Compiler. Ich habe ja programmieren nicht von der Pike auf gelernt wie einige hier, und habe deshalb auch nie mit yacc und lex spielen dürfen wochenlang.

    Ne im Ernst, es gibt ja bereits einen guten C Compiler für 6502 und auch für fast alles andere. Wird wohl ne Spielerei bleiben.


    Mich hat nur fasziniert dass ID Soft für Quake eine eigene VM geschrieben hat. Und zwar lange bevor VM's so richtig in Mode kamen! Und die VM basiert zu 100% auf den LCC!!

    Mein Lieblingscompiler ist Pelles C. Auch der basiert auf dem LCC-32.


    Am CC65 stört mich eigentlich nur die Code Größe. Aber das lässt sich bei einem 8 Bitter nicht ändern wenn man native compiliert. Deshalb wünsche ich mir eine P-Code Lösung für Programmteile die nicht zeitkritisch sind (User Interface).

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Mich hat nur fasziniert dass ID Soft für Quake eine eigene VM geschrieben hat. Und zwar lange bevor VM's so richtig in Mode kamen!


    Na ja, kommt darauf an was man als "in Mode kamen" bezeichnen will. UCSD-Pascal, die Z-Machine (Infocom), AS/400 und Java sind nur ein paar ältere Beispiele die mir gerade einfallen. Hexen hatte auch schon ein Skriptsystem mit C-ähnlicher Syntax, aber ich kann mich gerade nicht daran erinnern ob das vorcompiliert wurde.

    Zitat

    Am CC65 stört mich eigentlich nur die Code Größe. Aber das lässt sich bei einem 8 Bitter nicht ändern wenn man native compiliert.


    Man arbeitet daran. :wink:

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Diese Faszination kenne ich :)

    Zum Thema Größe: Man arbeitete daran und man arbeitet weiter daran. Beispiel, zugegebenermaßen *äußerst* sinnfreier Test-Code, aber aus dem echten Leben:

    Mit Quelltext als Kommentar:

    Das wäre vor zwei Jahren noch doppelt so groß. Man beachte z.B., dass dem Compiler bewusst ist, dass X hinter L0022 schon 0 ist. Sonst hätte er hier auch wieder die Y-Indizierung benutzt. Falls sich jemand über die Sache mit dem X-Register wundert: AX ist ein "virtuelles" 16-Bit register.

    Edit: Aber manchmal spuckt er auch noch ziemliche Katastrophen aus. Das hat jemand neulich gefunden:

    Code
    bcc bla
        clc
    bla:

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.


  • Am CC65 stört mich eigentlich nur die Code Größe. Aber das lässt sich bei einem 8 Bitter nicht ändern wenn man native compiliert. Deshalb wünsche ich mir eine P-Code Lösung für Programmteile die nicht zeitkritisch sind (User Interface).

    Das ist sicher ein "Problem" des cc65. Ich verzichte auf die stdio library und nutze conio + eine selbstgebaute "cgets" routine - das spart tatsächlich ein paar Byte. Der microQuestMaker ist ein Beispiel für diesen Weg, da habe ich in der aktuellen Version z.B. beim "Mazegen" (Levelgenerator) 9 Blocks auf der Diskette durch diesen Weg gespart.

    Was den cc65 aber trotz seiner Schwächen sehr stark macht, ist die Vielzahl an unterstützten Systemen und das dieses Projekt nach wie vor aktiv betreut wird.

    -
    Commodore 64 is a way of life!

    Internet: Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. und im Bitte melde dich an, um diesen Link zu sehen.
    CSDB: Bitte melde dich an, um diesen Link zu sehen.
    GitLab: Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.

  • Na ja, kommt darauf an was man als "in Mode kamen" bezeichnen will. UCSD-Pascal, die Z-Machine (Infocom), AS/400 und Java sind nur ein paar ältere Beispiele die mir gerade einfallen.

    tlr hatte mal vor einiger Zeit vom Kopierschutz von Bitte melde dich an, um diesen Link zu sehen. (1984) erzählt, der hat wohl intern 32bittigen Bytecode interpretiert. Wieso auch nicht, ist ja gut geeignet, das Durchleuchten davon zu erschweren.

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.