BlitzMax Extended

Gehe zu Seite 1, 2  Weiter

Worklogs BlitzMax Extended Kommentare

Linker of Lame

Mittwoch, 24. Oktober 2012 um 23:29 Uhr von ProfJake

Hi kog,

genau das gleiche Problem hatte Lobby auch und ich hab bis jetzt ehrlich gesagt eher in die Röhre als durchgesehen. Es ist ja offensichtlich ein Linkerproblem und damit doof zu lösen für mich als Mac-Typie.

Im vorliegenden Fall ist es der GCC, der eine Schleife optimiert und dafür dieses Modulozeugs einsetzt. Natürlich sind Optimierungen super, aber wenn MinGW sie nicht unterstützt ist das eine ganz andere Geschichte.

Hier wurde das Problem schonmal diskutiert – probier es mal aus. ABER: Diese Linkeroptionen sind eigentlich schon gesetzt. Von daher bin ich mir nicht sicher, ob das heute noch viel hilft (v1.49).

Ich habe bei der neuesten Version mal den Optimierungslevel auf Standard (O2) gelassen. Vielleicht reicht das schon.

Ansonsten den neusten MinGW besorgen und die hier vorgeschlagene Lösung ausprobieren.


ProfJake

Fehler beim Compilieren

Mittwoch, 24. Oktober 2012 um 18:18 Uhr von kog

Guten Tag,

Ich wollte es gerade ausprobieren, habe den Inhalt aus dem Archiv in einen neuen Ordner namens brl.blitz getan, Kompliert keine probleme mit bmk.


Jedoch wenn ich den Test starten will im Archiv, kommt folgende Fehlermeldung:
Code: [AUSKLAPPEN]

D:/BlitzMax/lib/libmingwex.a(pformat.o):pformat.c:(.text+0x355): undefined reference to `__umoddi3'
D:/BlitzMax/lib/libmingwex.a(pformat.o):pformat.c:(.text+0x377): undefined reference to `__udivdi3'

makedocs kaputt machen...

Sonntag, 7. Oktober 2012 um 19:46 Uhr von blackgecko

Getestet auf Fedora 17:
Kompiliert ohne Probleme. Beim Durchlaufen steigt zwischendurch der RAM-Verbrauch ziemlich stark an, was beim Original nicht so ist. Aber es läuft komplett durch.
Hoffe das hilft weiter.

Geschwindigkeit

Donnerstag, 19. Juli 2012 um 00:04 Uhr von ProfJake

Nochmal klarer auf den Punkt gebracht:

BlitzMaxExtended ist im Durchschnitt etwas schneller als das Original, mindestens aber genauso schnell.

Mittwoch, 18. Juli 2012 um 19:15 Uhr von ProfJake

@Nova:

Wenn du die neuen Features benutzt statt BlitzMax-Implementationen, werden deine Programme schneller sein als vorher – versprochen. (z.B isLower/isUpper kriegst du mit BlitzMax nicht ohne weiters so schnell hin)
Ansonsten werde ich beim erreichen der BETA, wenn alles an Features soweit drin und funktionsfähig ist, nochmal speziell auf Geschwindigkeit optimieren.

(Vielleicht sogar beim kompilieren einstellbar: schnell oder klein)


@Lobby:

Habe den Link mal gegen den zu einer neuen Version ausgetauscht.
Könnte sein, dass einfach nur die Zeile, die "windows.h" inkludiert an der falschen Position stand.

Mittwoch, 18. Juli 2012 um 18:41 Uhr von Nova

Sind diese Geschwindkeitsvorteile allgemein gehalten (sind also bei fast jedem Projekt präsent) oder muss man für diese wirklich bestimmte Funktionen nutzen?

Auf jeden Fall sehr schön, dass auch solche Dinge noch Verbesserungen (wenn auch keine offizielle) erfahren. Finde ich auf jeden Fall gut. Smile

Sinn und Zweck

Mittwoch, 18. Juli 2012 um 18:18 Uhr von ProfJake

@Nova:

Ja, man kann dann einfach das originale brl.blitz Modul ersetzen.
Ja, es soll ein aufgeräumterer Quellcode mit ausführlicherer Dokumentation werden.
Ja, es sind neue Funktionen mit eingebaut worden. (Mehr für die C/C++-API, aber auch für BlitzMax ist viel dabei.)

Es lohnt sich denke ich für alle, die "extended" Version zu nutzen. Schon allein, weil an der originalen nur wenig gemacht wird.
Außerdem gibt es viele neue Funktionen und alte Funktionen, die schneller und sicherer geworden sind.


@Lobby:

Das sieht ja nicht gerade gut aus, werde mir das mal anschauen. Auch wenn natürlich ein 8 Jahre alter Kompiler nicht so dufte ist.
Sieht das bei der ganzen Windows-Fraktion so aus, dass man den alten GCC verwenden muss?

Mittwoch, 18. Juli 2012 um 17:42 Uhr von Nova

Kann mir jemand eine kurze Erklärung geben, was das ganze überhaupt soll? Sind das alles nur "Aufräumaktionen" an grundlegenden Sachen von BlitzMax oder soll es auch noch speziellere Verbesserungen geben? Wird man einfach die Original-Version ersetzen können, neu compilieren und alles ist gut?
Ich bin nicht so ganz auf der Höhe, was hier so alles passiert. Ein paar einfache Worte für die "niedere Programmiererschicht" der "Fenster-und-Sanduhr-Fraktion" wäre daher wirklich nett! ;D

Mittwoch, 18. Juli 2012 um 14:16 Uhr von Lobby

Wenn ich dann einmal als Teil der Fenster-und-Sanduhr-Fraktion etwas zu deinem Projekt sagen darf: es funktioniert nicht.
Um genauer zu sein, kommt beim Versuch das ganze zu kompilieren die folgende Ausgabe: http://pastebin.com/CtzDeX1L
Ich habe einfach deinen blitz.mod-Ordner den bisherigen überschreiben lassen. Mein gcc hat die Version 3.4.5 von 2004, weil ich mit neueren Versionen Probleme beim Kompilieren von anderen Modulen hatte.

Fixes

Sonntag, 8. Juli 2012 um 18:22 Uhr von ProfJake

Danke für die Rückmeldungen.

1. Thunder:
Das Fehlen der Funktionen liegt höchstwahrscheinlich daran, dass BB_OS_LINUX nicht definiert wurde.
Ich habe bisher nur auf "__linux__" getestet, da "__linux" veraltet ist.

FIX: Test auf beide vordefinierten Kompilerkonstanten

2. ich
Der Fehler kam nur im experimentellen Modus vor, das habe ich wohl übersehen.

FIX: Kein spezieller "experimenteller" Code mehr in bbStringSplit. Läuft jetzt in allen Modi.


Das Update ist im Worklog verlinkt.

Gehe zu Seite 1, 2  Weiter


Kommentar schreiben

Titel:
Text: