[php]Little versus Big Endian problems

[0528973]

Hallo allemaal,

Het probleem dat ik heb, is in de nabije toekomst wordt er bij ons een Mac OS/X G5 web/mysql/ed server neergezet. Extern blijven we echter met linux machines werken op een i386 architectuur. En dan gaan we het little en big endian probleem misschien wel krijgen, aangzien de G5 Big Endian(of Bi-Endian) is en de i386 Little Endian. Ik probeer nu uit te zoeken wat voor lange termijn effecten dat gaat hebben, misschien kunnen sommige mensen me hier wat tips geven om naar te zoeken?

Het verschil tussen Little en Big Endian is mij bekend, echter heb ik geen inzicht in wat voor problemen dit kan gaan geven, wanneer de test/interne server Big Endian is en de externe productie server Little Endian is. Er worden websites met php en mysql gehost op de externe machine, tevens wordt er gebruik gemaakt van xls2csv en xapian. Ik ben nu nog aan het rondzoeken en me aan het inlezen in de mogelijke problemen, bijvoorbeeld het generen van images op de interne server, die niet direct gebruikt kunnen worden op de externe server, vanwege het byteorder verschil. Zouden er nog meer van dit soort problemen kunnen zijn? Alle software die extern gedraaid wordt(php, mysql, apache ed zijn allemaal beschikbaar onder OS/X).

[chem]

Dat maakt allemaal geen zak uit hoor.

Je kan al die apps gewoon onder OS X compilen en onder je x86 procs - ik doe het zelf en heb er geen enkel probleem mee.

[0528973]

Het maakt geen zak uit zeg je, goh ik probeer nu juist argumenten te verzamelen waarom het wel of niet uitmaakt. Ik weet ook dat de software onder beide systemen te compilen en te installeren valt. Ik vraag me bijv. echter af of een bit-shifts en binaire vergelijkingen hierdoor op PHP niveau niet beinvloed worden. Voor zover ik nu heb kunnen zien, maakt het niet uit, maar ik kan echter niet alles testen en weet niet genoeg over een onderwerp als dit om een keiharde conclusie neer te leggen, daarom wil ik het zo graag goed uitzoeken

Een heel simpel argument om niet over te gaan is, een systeem testen op systeem A en het dan draaien op systeem B, waar bij beide systemen dus de onderliggende architectuur verschilt kan betekenen dat bepaalde operaties niet hetzelfde resultaat hebben. Het zou me tenminste niet verbazen als dit het geval. Dus onderbouw even waarom het geen zak uitmaakt aub.

[chem]

Nee dat wordt allemaal afgevangen door de compilers. Als je niet op dergelijke nivo aan het programmeren bent (bv php, java, etc.) dan heb je daar allemaal niets mee te maken.

Zelfs als je wel op dat nivo bezig bent (c, c++ oid) dan NOG zal het lastig zijn om er tegenaan te lopen denk ik (te weinig ervaring in die talen).

[lordgandalf]

zie

http://www.noveltheory.com/techpapers/endian.asp

over het verschil tussen de twee mijn inziens maakt het dus kwa progs niks uit het over hoe je geheugen beheerd wordt en dat wordt als het goed is niet gedaan door je programma

[JeRa]

In C/C++ heb je wel degelijk te maken met little en big endian verschillen (zie de headerfiles van ScummVM maar eens voor alle macros). Ik vermoed echter dat MySQL en PHP hun systeem zó hebben dat het ongeacht het systeem waarop het draait altijd in één bepaald endianess doorstuurt.

[CyBeR]

Het enige waar je mogelijk tegenaanloopt is als je bitwise loopt te kutten in multibyte waarden. In sommige gevallen komen de bytes dan verkeerd om tegenelkaar te staan. Maar als je netjes progt heb je daar zelden last van. Sowieso is Big-Endian The Only Way

Overigens meen ik dat de G5 niet meer Bi-Endian is, tot en met de G4 waren PowerPC's dat wel. Ik meen ook dat er daarom veel meer moeite zit in het overzetten van VirtualPC naar de G5.

[JeRa]

CyBeR schreef op maandag 31 januari 2005 @ 20:31:
Sowieso is Big-Endian The Only Way

Waarom?

[CyBeR]

Omdat mensen ook op die manier bits beschrijven, alles over netwerken big-endian gestuurd wordt en ik 't gewend ben. D'r zijn ook mensen die little-endian logischer vinden.

[JeRa]

CyBeR schreef op maandag 31 januari 2005 @ 20:47:
Omdat mensen ook op die manier bits beschrijven, alles over netwerken big-endian gestuurd wordt en ik 't gewend ben. D'r zijn ook mensen die little-endian logischer vinden.

Ik beschrijf op die manier bits, dat over netwerken wist ik niet, maar qua programmeren lijkt me little-endian de meest logische keuze (uitleg daarover staat in die link hierboven, je kunt getallen met meer bits uitlezen zonder dat de waarde verandert). Waarom hebben ze nou niet gewoon 'n standaard afgesproken

[CyBeR]

JeRa schreef op maandag 31 januari 2005 @ 20:51:
[...]

Ik beschrijf op die manier bits, dat over netwerken wist ik niet, maar qua programmeren lijkt me little-endian de meest logische keuze (uitleg daarover staat in die link hierboven, je kunt getallen met meer bits uitlezen zonder dat de waarde verandert). Waarom hebben ze nou niet gewoon 'n standaard afgesproken

Volgens mij (weet 'k niet heel zeker moet ik bekennen) wa big-endianness standaard voor Intel bedacht 't andersom te doen Pin me d'r alleen niet op vast.

[ Voor 4% gewijzigd door CyBeR op 31-01-2005 20:58 ]

[kvdveer]

Ik heb weinig bij te dragen aan deze discussie. (ik heb 'm al gevoerd met de TS), maar ik wil jullie het volgende stukje tekst niet onthouden:

In Gulliver's travels the Lilliputians liked to break their eggs on the small end and the Blefuscudians on the big end. They fought wars over this. There is a computer analogy. Should numbers be stored most or least significant byte first? This is sometimes referred to as byte sex.

Those in the big-endian camp (most significant byte stored first) include the Java VM virtual computer, the Java binary file format, the IBM 360 and follow-on mainframes such as the 390, and the Motorola 68K and most mainframes. The Power PC is endian-agnostic.

Blefuscudians (big-endians) assert this is the way God intended integers to be stored, most important part first. At an assembler level fields of mixed positive integers and text can be sorted as if it were one big text field key. Real programmers read hex dumps, and big-endian is a lot easier to comprehend.

In the little-endian camp (least significant byte first) are the Intel 8080, 8086, 80286, Pentium and follow ons and the MOS 6502 popularised by the Apple ][.

Lilliputians (little-endians) assert that putting the low order part first is more natural because when you do arithmetic manually, you start at the least significant part and work toward the most significant part. This ordering makes writing multi-precision arithmetic easier since you work up not down. It made implementing 8-bit microprocessors easier. At the assembler level (not in Java) it also lets you cheat and pass addresses of a 32-bit positive ints to a routine expecting only a 16-bit parameter and still have it work. Real programmers read hex dumps, and little-endian is more of a stimulating challenge.

[Verwijderd]

CyBeR, volgens mij kon je best 's gelijk hebben.
Voor zover ik weet was Intel's 8080 de eerste 8-bits processor met een 'pseudo 16-bits' accumulator (2 8-bits registers, AL en AH), en vanaf dat moment was little-endian een feit. De 16-bits instructies kwamen vrijwel overeen met hun 8-bits broertjes, alleen werd er nog een extra byte in het geheugen benaderd: de high byte.

Of Intel hiermee de eerste was weet ik niet, maar op z'n minst wel de belangrijkste (CP/M, Wang, een hoop dedicated tekstverwerkers, etc. en later de home computers -Sinclair, MSX, noem maar op-).

[_JGC_]

Enige waar ik problemen in zie is als je van bijvoorbeeld MySQL de database files zo overkopieert van je linux machine naar je OS X machine, je zult dan moeten dumpen en importeren omdat het dataformaat door architectuurverschillen veranderd *kan* zijn.

[CyBeR]

_JGC_ schreef op dinsdag 01 februari 2005 @ 12:27:
Enige waar ik problemen in zie is als je van bijvoorbeeld MySQL de database files zo overkopieert van je linux machine naar je OS X machine, je zult dan moeten dumpen en importeren omdat het dataformaat door architectuurverschillen veranderd *kan* zijn.

Nope, die kun je gewoon heen en weer kopieren zover ik heb ervaren.