Dear visitor, welcome to Forum64.
If this is your first visit here, please read the Help. It explains in detail how this page works.
To use all features of this page, you should consider registering.
Please use the registration form, to register here or read more information about the registration process.
If you are already registered, please login here.
Zum Compilieren verwende ich momentan den Austro Speed Compiler. Jetzt hab ich aber keinerlei Ahnung, wie, und was für Optionen ich dem in den Quelltext mit übergeben kann. Davon ab frag ich mich, was der so alles mit rein pflastert, weil ein einfaches Hello World schon 19 Blocks (!) braucht. Hat irgendwer eine Dokumentation zu selbigem rum liegen, oder weiß wo man entsprechendes Material bekommt? Ich such mir hier nen Wolf! Danke schon mal im Voraus.
Der Austro hat eine Runtime, sozusagen ein Grundpaket, das immer dabei ist.
Deshalb haben Programme immer eine gewisse Grundgröße. Wenn dein BASIC programm größer wird, dann vergrößert sich das Compilat nur noch im geringen Ausmaß. Bei sehr großen Programmen kann es sogar vorkommen, dass es kleiner wird nach dem kompilieren.
Hab ihn gerade mal im Test, mal kucken, was er so hin bekommt. Aber generell, kann doch nicht sein, dass es fürn Austro keine Doku gibt? Weiß keiner sowas? Trotzdem schon mal danke für den BB.
Der Austro compiliert dir ein Basic Programm. Und das wars. Da ist nicht viel mit Optionen oder Optimierungen.
Blitz Compiler (seien wir freundlich und nennen es eine Erweiterung von Austro) erzeugt so ziemlich das selbe Compilat, hat eine etwas grössere Runtime, geht mit Basic Erweiterungen freundlicher um und hat glaube ich ein oder zwei Optionen. Bin mir da aber nicht sicher. Blitz wurde meist für BBS Software wie CBase verwendet. Wenn ein mehrteiliges Programm durchcompiliert wird kann man Runtime und Compilat auch trennen und braucht nur einmal die Runtime laden. Diese benutzt (normal) keinen selbstmodifizierenden Code, so dass nur den compilierten Teil nach $1xirgendwas laden und 'RUN' ausreicht.
Komfortabler ist allerdings wohl doch Basic Boss - da gibts auch eine Crossversion für PC von einem Forumsmenschen - einfach mal suchen ..
Also Optionen hat Basic Boss auch recht viele, aber Filesize ist ebenfalls schon recht happig. Und wie der Lord schreibt: gut dokumentiert. Würde ich empfehlen. Wenn die Filesize wirklich ein Problem wird, kann man ja immer noch auf Nachlader und/oder Crunching zurück greifen.
Wenn Sie irgendwelche Satzzeichen in meinen Postings vermissen, bedienen Sie sich, bitte:
@!#?@! (Zitat Q*bert, Arcade Version, 1982)
Hab ihn inzwischen auch schon mal probiert, die Dateigröße ist tatsächlich eher noch größer, als die vom Austro, allerdings ists schon mal ganz schön, überhaupt irgendwas einstellen zu können und flott ist er tatsächlich auch. Jetzt muss ich nur kucken, wie ich das Programm compiliert krieg, da hab ich schon so meine ersten Erfahrungen gemacht, wie mans nicht macht. ;-) Aber da wurschtel ich mich jetzt erst mal durch. Danke auf jeden Fall für den Tipp. Nachladen, hmm... Also nachdem das ganze ja auf Modul soll wird das schon wieder eine GANZ andere Hausnummer für mich, das wollt ich dann doch eher nicht. Sollte halt am Ende nicht mehr als 16 KB brauchen, weil soll ja aufn EPROM.
Für jemand der erst lang und breit Assembler lernen müsste: JA! Ehrlich, das tu ich mir jetzt nicht auch noch während der Bachelor-Arbeit an. Mal abgesehen davon, dass es mit dem Austro sogar ganz gut ging bis jetzt. Muss da einfach mal die Möglichkeiten ausloten, falls Donald es doch mal schafft, mit der 64K-Platine, würde sich das Speicherplatz-Problem vermutlich eh in Wohlgefallen auflösen.
Mal ne ganz naive Frage von jemandem der noch nie einen BASIC-Compiler (für den C64) benutzt hat - es aber vielleicht noch vor hat...
Hier wird viel über die "happige" Dateigröße geredet, aber ich nehme mal an, dass das Kompilat im Vergleich zum unkompilierten BASIC-Code in der Regel (deutlich?) kleiner ist. Ist das soweit richtig?
Leider falsch. Meiner Erfahrung nach werden Kompilate immer erstmal größer. Erst wenn man sie cruncht, sind sie vielleicht am Ende doch wieder als File kleiner als der Basic-Code, verbrauchen aber deshalb im RAM nach dem Decrunchen nicht weniger.
Wenn Sie irgendwelche Satzzeichen in meinen Postings vermissen, bedienen Sie sich, bitte:
@!#?@! (Zitat Q*bert, Arcade Version, 1982)
Nach meinen Erfahrungen ist das Kompilat noch mal ca. um Faktor 2-4 größer als das reine Basicprogramm, je nach Compiler (Petspeed ist da besonders großzügig mit der Speicherverschwendung ). Wobei ich Basic-Boss noch nicht probiert hab, vielleicht ist das ja die rühmliche Ausnahme.
"Wer Ahnung hat, soll zum Arzt gehen." (H. Schmidt)
Nein, bei BASIC-Boss ist es genauso. Rein von der Filesize ist z.B. der BASIC-Code von SOAP so 20-21 Blocks groß, nach dem Kompilieren 51-53, also Faktor 2,5 (im unteren Spektrum von Colts Schätzung 2 bis 4).
Wenn Sie irgendwelche Satzzeichen in meinen Postings vermissen, bedienen Sie sich, bitte:
@!#?@! (Zitat Q*bert, Arcade Version, 1982)
Kann ich nur bestätigen. Mein Quellcode hat bis jetzt 33 Blocks (OK, viel auskommentiert), mit dem Austro werdens 37 Blocks, der Boss verballert 44 Blocks. Kleiner wurde es damit sicher nicht. ;-)
Einen wirklich felsenfesten Faktor gibt es wohl für keinen Compiler. Vielmehr kommt es auch drauf an, welche BASIC-Befehle verstärkt kompiliert werden müssen (REM frisst im BASIC-Source evtl. viel Filesize, ist aber leicht kompiliert , bei For...Next-Schleifen oder IF-Orgien kann das schon anders aussehen) und was für Prioritäten man hat (soll es klein sein oder schnell laufen..., in letzterem Fall nutzt man ja gerade gern Compiler Optionen wie z.B. im Boss FASTIF oder FASTFOR).
Wenn Sie irgendwelche Satzzeichen in meinen Postings vermissen, bedienen Sie sich, bitte:
@!#?@! (Zitat Q*bert, Arcade Version, 1982)
Mhh ich nehm mal an das kommt dann dadurch zustande, dass der BASIC-Code vom C64 bereits quasi "komprimiert" abgespeichert wird, da ja diese Tokens verwendet werden...
Aber gut zu wissen, letztlich hat man also einen Tradeoff einzugehen, entweder man hat ne flottere/flüssigere Programmausführung, oder es lädt schneller.
Pro und Contra Compiling: Es kommt darauf an, was man will
Die Ladegeschwindigkeit ist noch nichtmal so entscheidend, man könnte ja vorher einen Loader mit Software-Speeder schalten. Dass sehr viel RAM beim Kompilieren draufgeht und irgendwo ab 202 + X Blocks pro File normalerweise Ende der Fahnenstange ist, macht schon eher Probleme. Wenn man also (nicht ganz sauber, wie oben ausgeführt) mal einen pauschalen Faktor wie 2,5 annimmt, dürfte also der Basic-Code nur etwa 80 Blocks haben, das ist bei umfangreicherer Software schneller erreicht, als mancher vielleicht denkt.
Man muss sich eben wirklich fragen bzw. testen, ob ein Compiling nennenswert Performanche/Speed bringt <-- für mich der einzige plausible Grund Compiler zu nutzen. Ein Programm, das in Basic eh schon flott läuft, wird durch Compiling nicht besser. Ein Actionspiel oder auch eine - unkompiliert - sehr lahm arbeitende Anwendung ist dagegen schon eher lohnenswert.
Wenn Sie irgendwelche Satzzeichen in meinen Postings vermissen, bedienen Sie sich, bitte:
@!#?@! (Zitat Q*bert, Arcade Version, 1982)
Falls du nicht dein Programm schon per hand "optimiert" hast, empfehle ich diesen BASIC Condenser (Option a) zu probieren. U.U. wird dein Programm ein stück kleiner und schneller. Danach kannst du den Compiler auch noch nutzen. (Mit Option b hat der Compailer nachher Probleme).
Das ist das geile, hier taucht immer wer auf, der noch was nützliches beiträgt. Habs mal eben drüber laufen lassen, hat ja "nur" 12 Blocks gespart. Allerdings kommt der Austro mit dem Kondensat nicht zu recht, der ist eben volle Kanne hängen geblieben. Aber wie zu erwarten war, das Compilat bleibt natürlich so groß. Trotzdem danke, zum Einlagern von BASIC-Code sicher ganz nützlich.
Forum64 »
Coder_unter_sich »
Programmieren »
Ehrlich, das tu ich mir jetzt nicht auch noch während der Bachelor-Arbeit an. Mal abgesehen davon, dass es mit dem Austro sogar ganz gut ging bis jetzt. Muss da einfach mal die Möglichkeiten ausloten, falls Donald es doch mal schafft, mit der 64K-Platine, würde sich das Speicherplatz-Problem vermutlich eh in Wohlgefallen auflösen. 
, bei For...Next-Schleifen oder IF-Orgien kann das schon anders aussehen) und was für Prioritäten man hat (soll es klein sein oder schnell laufen..., in letzterem Fall nutzt man ja gerade gern Compiler Optionen wie z.B. im Boss FASTIF oder FASTFOR). 
Change style
Sunday, May 19th 2013, 12:35pm
Go to the top of the page
