Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
Werbeanzeige
Zitat
Wann genau kann es jetzt zu Endian Problemen kommen?
Zitat
wobei bei ihm nur die mittleren beiden Bytes vertauscht waren. Ist das immer so?
C-/C++-Quelltext |
|
1 2 3 4 5 6 7 |
void WriteInt(std::ostream& out, uint32_t Int) { WriteByte(out, Int >> 0); WriteByte(out, Int >> 8); WriteByte(out, Int >> 16); WriteByte(out, Int >> 24); } |
Ich mag mich irren, aber würde der Compiler nicht an der Stelle aus Narrowing-Gefahr mal kurz rauf zu int casten? Ist ja kein Rollen, wo das 'nen Unterschied bewirken würde. Zumindest musste ich bei meiner VM an einer Stelle den Compiler dazu zwingen, val+1 mit val als uint16_t nicht hoch zu casten.Zitat
Das Ergebnis davon ist schon undefiniert und auch falsch.
C-/C++-Quelltext |
|
1 2 3 4 |
int main(int _argc, char** _argv) noexcept { asm volatile("lock cmpxchg8b %eax"); return 0; } // ::main |
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Evrey« (19.06.2014, 18:06)
Zitat von »Jack«
Ist korrekt, oder?
Zitat von »Jack«
Schlussfolgernd, kommt man also doch nicht drum rum, von Little Endian auf Big Endian zu konvertieren und andersrum, wenn es nötig ist,
oder ist was an meiner Logik verkehrt?
Zitat von »Evrey«
spezielle Maschine bezüglich der Ladezeit
Zitat von »Evrey«
Ich mag mich irren, aber würde der Compiler nicht an der Stelle aus Narrowing-Gefahr mal kurz rauf zu int casten?
Dieser Beitrag wurde bereits 6 mal editiert, zuletzt von »Spiele Programmierer« (19.06.2014, 18:18)
Ich verstehe nicht ganz, worauf du hinaus willst. Nehmen wir an, dass eine OnyxVM auf einem PowerPC Bytecode speichert. Dann wäre diese Datei im Big Endian -Format. Liest die PPC-VM jetzt diesen Bytecode ein, sind keine Byteswaps von Nöten. Jetzt lade ich die selbe Datei auf einer x86-VM, die nunmal Little Endian ist. Jetzt muss jedes Häppchen der Datei mit Byteswap geladen werden. Erstellt die x86-VM nun eine Kopie, ist diese Kopie im Little Endian -Format und kann dann wieder ohne Byteswap geladen werden.Zitat
Ein Byteswap sollte auf einem modernen Prozessor wesentlich schneller laufen als eine zusätzliche Verzweigung.
C-/C++-Quelltext |
|
1 2 3 4 |
int main(int _argc, char** _argv) noexcept { asm volatile("lock cmpxchg8b %eax"); return 0; } // ::main |
Zitat
sind keine Byteswaps von Nöten.
Nein. Wie gesagt: Ich lese die ersten vier Bytes der Datei. Ist das Prüfwort 'oxbc', wird die gesamte Datei in einem Rutsch ohne Byteswaps gelesen. Andernfalls mit. Es gibt einfach zwei verschiedene Funktionen, die den Bytecode laden. Da wird nicht Wort für Wort geprüft. Das würde doch die arme BPU töten. Und das bisschen mehr an Bytes im Code-Segment juckt mich nicht.Zitat
Allerdings muss ja bei jedem gelesenen Wert entschiedenen Werden "Byteswap oder nicht".
Ich habe noch nie Performance-Messungen mit den C++-Streams durchgeführt. Es kann sein, dass das "lahm-wie-sau" ausschließlich bei operator<< und operator>> besteht, die ziemlich knorke aber eben auch ziemlich teure Formatierungs-Arbeit leisten und read und write hingegen recht flott sind. Ich weiß es nicht. Habe eh' noch gewisse IO-Experimente vor, die dann entscheiden, welche Strategie/Lib ich wählen werde. Wahrscheinlich Marke Eigenbau, weil ich das eh' länger mal ausprobieren wollte.Zitat
Gerade die Streams von C++ sollen teilweise lahm-wie-sau implementiert sein.
C-/C++-Quelltext |
|
1 2 3 4 |
int main(int _argc, char** _argv) noexcept { asm volatile("lock cmpxchg8b %eax"); return 0; } // ::main |
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Werbeanzeige