PureBoard

Seh ich auch so...
Die meisten C++ Kompiler sind hier schon sehr stark und per Hand bist du
sicherlich nicht schneller...

Aber bei PB denk ich das da schon noch ein paar schwachstellen sind...

Ich denke, PB ist durchwachsen.
Es gibt Dinge, die sehr gut sind, aber auch Dinge, die "nur" gut sind...

Faster Len: http://www.purebasic.fr/english/viewtop ... faster+len
Zero Memory: http://www.purebasic.fr/english/viewtop ... faster+len
ReverseString(): http://www.purebasic.fr/english/viewtop ... faster+len
n*n faster than n^2: http://www.purebasic.fr/english/viewtop ... faster+len

bis auf das letzte Beispiel alles Dinge, wo man mit ASM nachbessern kann. Und darum dachte ich, könnte ich mich eventuell auch mal an ASM wagen.

Und darum dachte ich, könnte ich mich eventuell auch mal an ASM wagen.

Es ist sicher nie ein Fehler, sich damit ein bißchen auszukennen. Es kann einem auch für die "normale" Programmierung wiederum behilflich sein, und manchmal macht's auch einfach nur Spaß, damit ein bißchen rumzufrickeln

Früher kam man an Maschinensprache/Assembler garnicht vorbei
wenn man etwas einigermassen schnell machen wollte, da die meist
interpretierten Hochsprachen (z.B. C64-BASIC) erheblich langsamer
waren - oftmals um den Faktor 200 und mehr.
Oder es waren noch keine Hochsprachen verfügbar.

Heute kann man in allen möglichen Sprachen programmieren und es
wird automatisch in Maschinensprache übersetzt und meist auch gut
bis sehr gut optimiert.

Es ist ja der Sinn von Compilern einem Arbeit abzunehmen, sonst würden
wir alle noch immer alles in ASM machen.
Irgendwo haben Hochsprachen also scheinbar Vorteile bei der Programmierung.

Wer wissen möchte was im Hintergrund passiert und wie alles auf unterer
Ebene funktioniert, der kann sich ja gern mal mit ASM beschäftigen.
Dann wird auch klar warum es beim aufsplitten von manchen Sachen
zu besseren Ergebnissen kommen kann, da moderne Prozessoren
die Instruktionen schrittweise in einer Pipeline dekodieren und dann
oftmals mehrere Befehle in einem Taktzyklus abgearbeitet werden
können, wenn sie nicht voneinander abhängig sind und auf das Ergebniss
des vorherigen Befehls warten müssen.
So kann man allein durch die Anordnung der Befehle bessere Ergebnisse
bekommen. Moderne optimierende Compiler können auch das beachten
und wählen dann zwischen zig Möglichkeiten und Anordnungen aus, um den
perfomantesten Code zu erzeugen. Entsprechend dauert dann das Kompilieren
auch länger, was nicht jeder (hier) gerne hat.

Es ist sicherlich sinnvoll das jeder für sich einen Kompromiss findet.
Von "alles in ASM" bis hin zu "nur Hochsprachen" kann alles dabei sein,
inklusive Zwischenstufen/Mix, wenn gewünscht. Je nach eigenen Prioritäten
und eigenem Wissen muß das jeder selbst entscheiden.

Cool! Heißen Dank für die Info!!

Mit Assembler kann man auch einfach Dinge sehr direkt machen, die in PB nur durch Umwege und dementsprechend unperformant machbar sind.

Wenn man Assembler programmiert, gibts z.b. im Prinzip keine festgelegten Datentypen. Du kannst mit der gleichen Variable eine signt und unsignt Operation durchführen. Oder nur mit dem unteren Byte oder Word eines Longs arbeiten ohne das erst rausrechnen zu müssen.

Letztens hatte ich das Problem das ich den Speicher nach einer Bytefolge durchsuchen wollte. Habs in Assembler gelöst, weils da viel einfacher war als mit PB, da viel direkter. Waren nur ein paar Instruktionen.

Geil.
Scheint sich also doch zu lohnen. Allerdings irritieren mich als Anfänger die ganzen Register.
Dann gibt es anscheinend Befehle/Befehlssätze, die nicht auf allen CPUs laufen, sprich SSE, SSE2, MMX und sowas.
Und als ob das nicht schon genug ist, gibt es auch noch verschiedene Assembler(typen), ich meine damit Nasm und Fasm. PB ist mit eine der letzten Versionen ja von Fasm auf Nasm (oder andersrum) umgestiegen.
Und das sind erst meine Anfangsprobleme, ganz nzu schweigen von Fragen, die bei intensiverer Beschäftigung auftreten...

AND51 hat geschrieben: Dann gibt es anscheinend Befehle/Befehlssätze, die nicht auf allen CPUs laufen, sprich SSE, SSE2, MMX und sowas.

Die würd ich erstmal ausser acht lassen. Damit lässt sich zwar richtig Performance rauskitzeln wie man hier im Board auch abundzu sehen darf. Aber das ist eher für Fortgeschrittene, also erstmal würde ich nur 386 kompatiblen Befehlssatz empfehlen.

AND51 hat geschrieben: Und als ob das nicht schon genug ist, gibt es auch noch verschiedene Assembler(typen), ich meine damit Nasm und Fasm. PB ist mit eine der letzten Versionen ja von Fasm auf Nasm (oder andersrum) umgestiegen.

Naja Assembler ist die native Sprache der CPU. Die Assemblersprache wird also von der CPU bestimmt, in deinem Fall warscheinlich nur x86. Die Assembler-Programme, die den Code assemblieren unterscheiden sich meist nur gering in der Syntax und in den Assembler-Direktiven. Da hilft die Doku des jeweiligen Assemblers weiter.

Hm also PB 4.20 nutzt immernoch FASM oder gibts schon ne neuere Version?

AND51 hat geschrieben: Und das sind erst meine Anfangsprobleme, ganz nzu schweigen von Fragen, die bei intensiverer Beschäftigung auftreten...

Naja, ja. Assembler lernen ist heutzutage nicht ganz so leicht. Das liegt nicht an Assembler selbst, sondern daran das es irgendwie keine vernünftigen Bücher für Anfänger gibt.

Gelernt (ich bin immernoch ASM-Noob ^^) hab ich es mit diesem Buch. Es ist nicht perfekt aber der Preis ist super. Das Problem ist das hier wie bei allen anderen Anfänger-Büchern auch, die ich gefunden habe, sich mit uraltem 16Bit Mist aufgehalten wird, den man nun wirklich nicht mehr braucht. Da sind Beispiele für MASM drinnen, die die aktuelle MASM-Version garnichtmehr so assembliert und Fehlermeldungen auswirft. Und das schon beim ersten "Hello World".
Wie dem auch sei, man muss da etwas autodidaktisch vorgehen. Zieh dir das aus dem Buch raus was du für wichtig hälst und du wirst einiges lernen.

Dieses Buch ist Gold wert. Eine sehr schöne und detailierte x86 Assembler-Referenz. Das von mir meistgenutzte Assemblerbuch.

Fragen gibts eigentlich garnicht so viele bei ASM. Weil es garnicht so viele Instruktionen gibt die man oft braucht. Wenn man erstmal das Grundkonzept begriffen hat und sowieso schon programmieren kann, gibts eigentlich keine großartig schwierig zu beantwortenden Fragen. Da das ganze sehr simpel ist. Man muss halt erstmal vom Hochsprachendenken weg.

>> Hm also PB 4.20 nutzt immernoch FASM oder gibts schon ne neuere Version?
PB hat bis 3.40 NASM genutzt!

Thorium: Nen Speicherbereich nach ner Bytefolge durchsuchen geht doch eigentlich ganz einfach mit ner Schleife und dann wahlweise PeekB() oder CompareMemory()...