Autor Thema: Software gesucht Korg DSM-1 und  (Gelesen 1368 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

Offline Chocco

  • Benutzer
  • Beiträge: 146
  • May the force be with you
Re: C-Entwicklung auf dem Atari
« Antwort #20 am: Mi 01.07.2020, 22:28:51 »
ich bin kein Programmierer und weiß deshalb nicht weshalb der so wenig Erwähnung findet wenn mal nach einen C-Compiler gesucht wird.

Vermutlich weil der (gelinde gesagt) eine sehr bescheidene Oberfläche hat. Ausserdem ist sowohl der Compiler als auch die mitgelieferte Bibliothek ziemlich buggy. Wenn man nicht gerade für die FireBee entwickeln will, ist man mit Pure-C deutlich besser bedient.

Einziges Problem: Pure-C ist (im Gegensatz zu AHCC) eigentlich immer noch nicht frei erhältlich.

Pure-C ist unter TOS/GEM tatsächlich unschlagbar. Welche "schlankere" Version des GCC könnte man denn als Basis nehmen, um sie mit einer Pure-C ähnlichen IDE aufzumöbeln? Da ich immer mit Pure-C gearbeitet habe, hat sich mir diese Frage bisher nie gestellt.
Atari TT030 mit CrazyDots
Milan 040 (S3)
Apple MBP

Offline gh-baden

  • Benutzer
  • Beiträge: 1.435
Re: C-Entwicklung auf dem Atari
« Antwort #21 am: Do 02.07.2020, 15:24:33 »
Pure-C ist unter TOS/GEM tatsächlich unschlagbar. Welche "schlankere" Version des GCC könnte man denn als Basis nehmen, um sie mit einer Pure-C ähnlichen IDE aufzumöbeln? Da ich immer mit Pure-C gearbeitet habe, hat sich mir diese Frage bisher nie gestellt.

Schlank heißt hier: uralt. GCC 2.5 oder 2.6 müßte die letzte für SingleTOS gewesen sein, aus meiner Erinnerung. Ich habe nie generierten Code gegenübergestellt, aber die Libraries von GCC 2.x waren viel dicker auftragend als alles rund um PureC, so dass viel schlankere Programme herauskamen.

PureC gewinnt in der 68k-Codegenerierung deutlich gegenüber Sozobon (die Basis von AHCC) und Lattice. Anderes habe ich selbst nie angeguckt, aber Zeitschriftentests zufolge hat PureC auch bspw LaserC, Megamax C ziemlich in den Boden gestampft.

Nichtsdestotrotz ist PureC inzwischen auch steinalt¹, Compileroptimierungen haben heute ein völlig neues Niveau gegenüber damals erreicht. Ich weiß nicht, wieviel davon im heutigen gcc generisch erreicht wird, und wieviel Plattform-unabhängig, wäre sicher einen Blick wert -  und dank Crosscompiler von Thorsten und anderen ja leicht zu kriegen.

1: Schon eher simplere mathematische Optimierungen werden von PureC nicht immer erkannt und vorgenommen, das klappt schon bei manchen Kombinationen von Multiplikationen nicht, woraus man billige Additionen machen könnte.
Wider dem Signaturspam!

Online Thorsten Otto

  • Benutzer
  • Beiträge: 868
Re: C-Entwicklung auf dem Atari
« Antwort #22 am: Do 02.07.2020, 17:00:41 »
Schlank heißt hier: uralt. GCC 2.5 oder 2.6 müßte die letzte für SingleTOS gewesen sein, aus meiner Erinnerung.

2.95 gab es auch noch. Wurde am Anfang wohl auch noch für Mint verwendet. Allerdings ist man dann auch an alte Libraries gebunden, neuere kriegt damit ohne ziemlichen Aufwand nicht mehr übersetzt.

Zitat
Anderes habe ich selbst nie angeguckt,

Ich hab schon öfter mal Pure-C mit gcc verglichen. Hängt immer sehr vom Anwendungszweck ab, mal hat der eine die Nase vorn, mal der andere. Pure-C ist denke ich vor allem bei 68k durch die Register-Übergabe der Parameter im Vorteil, das spart einiges an Code und Speicher-Zugriffen.

Zitat
Zeitschriftentests zufolge hat PureC auch bspw LaserC, Megamax C ziemlich in den Boden gestampft.

Naja das ist auch kein Wunder, die genannten waren auch nicht viel besser in der Codegenerierung als Alcyon. Nicht mal automatische Register-Zuweisung haben sie hinbekommen, das musste man alles selber explizit angeben.

Zitat
und wieviel Plattform-unabhängig,
Ich würde schätzen mindestens 90% davon ist plattform (und sogar Sprachen)- unabhängig. Der plattform-abhängige Teil macht eigentlich nur noch peephole-Optimierungen (bestimmte Befehlsfolgen durch andere ersetzen).

Zitat
das klappt schon bei manchen Kombinationen von Multiplikationen nicht, woraus man billige Additionen machen könnte.
Das hängt in den meisten Fällen vom Compiler-Schalter -G (Size-Optimierung) ab. Gesetzt wird dann normalerweise muls/mulu genommen, wenn nicht, und einer der Operatoren konstant ist, eine Folge von Additionen. Könnte auch noch von anderen Bedingugne abhängen (z.B. wieviel Bits in der Konstante gesetzt sind; ausserdem wird dafür ein temporäres Register benötigt), aber grundsätzlich beherrscht Pure-C diese Optimierung.

Haupt-Problem bei Pure-C ist eigentlich nicht die Code-Optimierung, sondern die Tatsache daß er nur 16bit ints kennt. Das macht es schwer bis fast unmöglich, heutige Programme damit zu benutzen.