Endianess des pc actuels versus époque du 286 jusqu'au pentium

bidouillage de vieux jeux sous dosbox

a marqué ce sujet comme résolu.
Auteur du sujet

Salut, l' endianess des pc actuels a t il le même endianess qu’à l' époque du 286 / 386 / 486 / pentium ? il parait qu’on est en petit boutiste actuellement, mais depuis quand ? pour les smartphones ? le raspbery ? les macbooks ?

pourquoi avoir inventé le petit boutiste qui semble contre intuitif ?

que se passe t il si on fait communiquer sur un réseau un vieux pc et un pc actuel : email, ftp , http … ?

Édité par buffalo974

+0 -0

Cette réponse a aidé l’auteur du sujet

il parait qu’on est en petit boutiste actuellement, mais depuis quand ? pour les smartphones ? le raspbery ? les macbooks ?

Le grand boutisme est utilisé de manière général dans les communications réseaux et pour certaines architectures comme le PowerPC qui n’est plus utilisé dans des PC.

que se passe t il si on fait communiquer sur un réseau un vieux pc et un pc actuel : email, ftp , http … ?

Le réseau est en grand boutisme depuis le début par convention, donc il n’y a pas de problèmes de compatibilité à ce niveau. Tous les ordinateurs font la conversion nécessaire.

Amateur de Logiciel Libre et de la distribution GNU/Linux Fedora. #JeSuisArius

+1 -0

Cette réponse a aidé l’auteur du sujet

Salut.

Du côté de l’embarqué, l’architecture MIPS que tu retrouves dans la plupart des routeurs peut être soit big-endian soit little-endian, personnellement j’ai vu pas mal de MIPS big-endian dans la nature.

ARM peut être les deux, la large majorité des devices (dont les téléphones) est en little-endian, mais j’ai vu du hardware en ARM big-endian aussi (décodeur TV).

x86 (donc « 286 / 386 / 486 / pentium ») c’est seulement little-endian. De plus, les instructions peuvent être de nombreuses tailles différentes (c’est un jeu d’instructions CISC - Complex Instruction Set Computing), contrairement aux jeux d’instructions RISC (R = Reduced) cités ci-dessus où globalement, toutes les instructions feront 4 octets et l’ordre de leurs octets sera différents en fonction de l’endianness.

PowerPC (utilisé sur les vieux Mac et pas mal de consoles) est big-endian de base, j’ai lu qu’il y avait possibilité de switcher l’endianness mais je suis pas spécialiste.

Les protocoles réseaux sont en large majorité big-endian, par convention, de même que pas mal de formats de fichiers, ce qui implique de faire pas mal de conversions au niveau du code.

Parmi FTP, HTTP et SMTP que tu as cité, aucun n’est un protocole binaire donc aucun n’a besoin d’encoder des nombres binaires, en principe. Les couches plus basses répandues (TCP/IP…) sont toutes en big-endian, un PC en little-endian fera la conversion de toutes façons.

L’intérêt du little-endian est la simplicité au niveau électronique, comme ça a été évoqué.

Bonne soirée,

+2 -0

Bonjour,

Ayant quel que (petites) compétences hardware, je suis un peu surpris par l’affirmation de wikipédia:

À priori, il y avait un intérêt à cette architecture dans les tout premiers CPU, parce que le petit-boutisme simplifie certains circuits. Cf https://en.wikipedia.org/wiki/Endianness si tu lis l’anglais.

SpaceFox

Pour moi, c’est kif-kif-bouricot!

A mon avis, la justification est plus simple: Dans les années 1980, il y avait 2 familles de processeurs 16 bits: Intel (8080) et Motorola (6800). quand on fait un processeur 8 bits, il n’y a pas de problème. Mais quand on fait un processeur 16 bits, il faut choisir l’ordre de lecture des octets : L’un avait choisi le little Indian, l’autre le big Indian : pourquoi ? Le hasard ? Ou une volonté de ne pas être compatible entre eux ?

Suite à quoi, l’un a été choisi pour bâtir les PC (les XT ! C’est vieux) et l’autre à été utilisé dans l’embarqué et les MAC.

L’histoire de l’explosion de l’utilisation du PC à fait la suite … pour garder la compatibilité des soft, les PC (puis les téléphones, …) sont restés en "Petit indiens". Si c’était les MAC qui avaient supplanté les PC, les processeurs serait "Grand Indiens".

Pour moi, il n’y a aucun intérêt à travaillé en little indiant, le big Indian est plus intuitif pour la lecture mémoire, quand on fait de l’assembleur ou langage machine, … où de l’électronique. Mais "C’est historique !"

Bien cordialement.

Édité par Dedeun

+0 -0
Auteur du sujet

L’histoire de l’explosion de l’utilisation du PC à fait la suite …. Mais "C’est historique !"

Source:Dedeun

@Dedeun l’Histoire a sûrement joué également, ça me fait pensé à la malheureuse convention du sens électrique / électrons. Si t’as un lien sympa au passage sur le hardware qui pourrait m’être utile : je suis dans le trip pythonistas qui regarde rust et nasm, et les émulateurs chip8.


je me mets un pense-bête qui sera aussi peut-être utile à d’autres plus tard:

>>> hexnum = 0xdeadbeef

>>> hexnum.to_bytes(4, 'little')
b'\xef\xbe\xad\xde'

>>> hexnum.to_bytes(4, 'big')
b'\xde\xad\xbe\xef'

In Python 3, the default encoding is "utf-8", so you can directly use:

>>>b'hello'.decode()
'hello'

which is equivalent to

b'hello'.decode(encoding="utf-8")
>>> int.from_bytes(b'\x00\x10', byteorder='big')
16

>>> int.from_bytes(b'\x00\x10', byteorder='little')
4096

>>> int.from_bytes(b'\xfc\x00', byteorder='big', signed=True)
-1024

>>> int.from_bytes(b'\xfc\x00', byteorder='big', signed=False)
64512

>>> int.from_bytes([255, 0, 0], byteorder='big')
16711680

module bitstring très sympa pour manipuler:

>>> fromhex = BitArray('0x01ffc9')
>>> frombin = BitArray('0b01')
>>> fromoct = BitArray('0o7550')
>>> fromint = BitArray('int:32=10')
>>> fromfloat = BitArray('float:64=0.2')
>>> acopy = BitArray(fromoct)
>>> fromlist = BitArray([1, 0, 0])
>>> f = open('somefile', 'rb')
>>> fromfile = BitArray(f)
>>> zeroed = BitArray(1000)
>>> frombytes = BitArray(bytearray(b'xyz'))

Édité par buffalo974

+0 -0

Bonsoir,

Il y a des sources à ce sujet dans la Wikipédia en anglais.

SpaceFox

en effet:

The Datapoint 2200 uses simple bit-serial logic with little-endian to facilitate carry propagation.

wikipedia

et

CTC released the Datapoint 2200 using about 100 TTL components (SSI/MSI chips) instead of a microprocessor, …

wikipedia

Si j’ai bien compris, ce terminal avait de la mémoire série (1 bits à la fois) et pas de processeur (uniquement des circuits TTL). Aussi quand il devait faire une addition/soustraction/… la lecture des donnés "LSB first" optimisait le calcul. (Bien! Il fallait y pensé! astucieux !) et donc "LSB First" est devenu "little indian", et Intel sur le 8008 à repris le même ordre pour sa mémoire. Donc la justification d’une meilleur performance, c’est avant la création du CPU, avant 1970. Merci pour cette remarque SpaceFox, j’ai appris quelque chose.

Il me semble donc que je puisse confirmer que dans un processeur, même les premiers 8 bits, Même les 16, 32, 64 et … , Little ou big Indian ça n’a pas d’impacte performance. Le choix est historique !

Si t’as un lien sympa au passage sur le hardware qui pourrait m’être utile : je suis dans le trip pythonistas qui regarde rust et nasm, et les émulateurs chip8.

buffalo974

Euh ! (comme j’ai expliqué, je suis un vieux !) Je n’ai aucune idée de ce qu’est "pythonistas", pas beaucoup plus sur "rust", rien du tout sur "nasm", …

Un jour que je posé une question, "Mad scientist" m’avait trouvé ce lien. J’espère que c’est ce que tu cherches comme info.

Cordialement.

Édité par Dedeun

+0 -0
Auteur du sujet

merci Dedeun

pythonista : adepte de python

rust : langage récent aussi rapide mais plus sûr que c++ pour la gestion de la mémoire, en vogue !

nasm : Netwide Assembler est un assembleur pour l’architecture x86, utilisant la syntaxe Intel. Il peut être utilisé pour produire à la fois des programmes 16 bits et 32 bits ; depuis la version 2 de NASM il est possible de produire aussi des programmes 64 bits. Libre et cross-plateforme.

Édité par buffalo974

+0 -0

A mon avis, la justification est plus simple: Dans les années 1980, il y avait 2 familles de processeurs 16 bits: Intel (8080) et Motorola (6800). quand on fait un processeur 8 bits, il n’y a pas de problème. Mais quand on fait un processeur 16 bits, il faut choisir l’ordre de lecture des octets : L’un avait choisi le little Indian, l’autre le big Indian : pourquoi ? Le hasard ? Ou une volonté de ne pas être compatible entre eux ?

Suite à quoi, l’un a été choisi pour bâtir les PC (les XT ! C’est vieux) et l’autre à été utilisé dans l’embarqué et les MAC.

L’histoire de l’explosion de l’utilisation du PC à fait la suite … pour garder la compatibilité des soft, les PC (puis les téléphones, …) sont restés en "Petit indiens". Si c’était les MAC qui avaient supplanté les PC, les processeurs serait "Grand Indiens".

Pour moi, il n’y a aucun intérêt à travaillé en little indiant, le big Indian est plus intuitif pour la lecture mémoire, quand on fait de l’assembleur ou langage machine, … où de l’électronique. Mais "C’est historique !"

Bien cordialement.

Je suis d’accord sur que la raison est tout simplement que le x86 c’est implanté , juste que un peu faux de dire si c’était Mac , y’avait plein de micro ordinateur qui utilisait du motorola (entre autre Atari St et Amiga) mais aucun micro n’a gagné contre le PC. Bref je voulais juste dire que l’informatique des années 80–90 était assez heterogene !

D’ailleurs le PC a failli prendre un proco motorola (c’était sérieusement envisagé) mais le manque de logiciels pour ce proco (en 1981) a fait balancer le choix sur le x86

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte