Debug Chr(0)

[sevny]

c'est pas grand-chose et c'est peut-être ma configuration qui est en cause mais dans un logiciel sophistiqué comme PB c'est étrange:
Debug Chr(0) <- ça plante
RUN et après ça bouge plus d'un octet !

[boddhi]

Pas de plantage sur Win10 x64 / PB 6.00 LTS x64

[SPH]

Pas de plantage sur Win10 x64 / PB 6.00 LTS x64

Même config et ça marche aussi.

[pat]

Bonjour,

Chr(0) est considéré comme la fin d'une chaîne, donc si on ajoute quelque chose après cela plante normalement.

[pat]

et il vaut mieux ne pas mettre chr(0) seul car fin de chaîne.

[pat]

Et tout dépendra du compilateur.
Cela peut ou ne peut pas fonctionner.

[falsam]

Hoooo un revenant de l'ombre. Hello Pat.

[pat]

Je m'intéresse toujours à PureBasic.
Mais j'ai également d'autres langages.
La 3D PB ne me séduit pas beaucoup parce que je n'ai pas de connaissance suffisante avec un modeleur.
Quant à Chr(0), il faut savoir, qu'en assembleur, on met en fin de chaîne un 0 pour indiquer justement que c'est la fin de la chaîne.

[Ollivier]

[...] Quant à Chr(0), il faut savoir, qu'en assembleur, on met en fin de chaîne un 0 pour indiquer justement que c'est la fin de la chaîne.

Bonjour pat,

je suis un peu étonné que tu dises ça. En Assembleur, les 2 conventions sont utilisables.

- quantité de caractères
- code de fin (et pas forcément zéro)

En fait, le "null terminal string" est une plutôt une convention née des langages évolués qui ont choisi.

avantages du code de fin :
- gain de mémoire
- longueur "infinie" des chaînes

inconvénients du code de fin :
- pas de table des longueurs de chaîne
- risque de débordement de lecture

Moi, j'aurais apprécié que a.s soit "null terminal" et A$ stocke une chaîne avec sa quantité. Ça peut sembler sale en x86-32bits et encore plus sale en x64, mais bon...

Taille d'un "A" en mémoire :

- null terminal ASCII : 2 octets
- null terminal UNICODE : 4 octets
- quantifié ASCII 8 bits quantitatifs : 2 octets
- quantifié UNICODE 8 bits quantitatifs : 3 octets
- quantifié ASCII 16 bits quantitatifs : 3 octets
- quantifié UNICODE 16 bits quantitatifs : 4 octets
- quantifié ASCII 32 bits quantitatifs : 5 octets
- quantifié UNICODE 32 bits quantitatifs : 6 octets
- quantifié ASCII 64 bits quantitatifs : 9 octets
- quantifié UNICODE 64 bits quantitatifs : 10 octets

Ben moi, perso, j'aime bien le ASCII 64 bits quantitatifs. Ça a un petit côté rétro, ça bouffe certes 9 octets pour un seul caractère, mais au moins, on y est pas pour la limitation de taille de chaîne (16 exaoctets)

[pat]

Bonjour,

En fait, je me réfère au 68000.
Avec des instructions comme dc.b "lldldldldl",0
Il fallait bien indiquer la fin de la chaîne.
Mais je ne connais pas trop l'assembleur des PC.

Donc merci pour ces précisions.

[pat]

L'instruction est ds.b "lldldldldl",0 (et non dc).

Le 68000 est un vieux processeur 16 bits et il fallait faire ainsi avec ce processeur.

[SPH]

Amiga ?

[Ollivier]

J'ai un côté admiratif pour les passionnés du 68000. Car je n'ai entendu que des éloges en comparaison 8086. Le 80286 ayant été un peu bogué, on ne reste comparer que le 68000 avec le 8086.

[pat]

Bonjour,

Je suis effectivement un nostalgique du 68000.
Un excellent processeur 16 bits.
J'avais à l'époque un Atari 520 STF.

Le 68000 a comme caractéristique, par rapport à son concurrent des PC, d'avoir un mode d'adressage très souple (et donc puissant), même si il y a moins d'instruction machine que sur les PC.

L'instruction Move (A1),(A2) est impossible sur les machines actuelles des PC, même sur les 64 bits.
Il faut passer par l'intermédiaire d'un registre pour obtenir le même résultat.

De plus, c'est un processeur extrêmement facile, intuitif, bref l'idéal pour tout programmeur.
Je regrette, et ne suis pas le seul, que les PC n'ont pas choisi ce processeur.

[Ollivier]

L'instruction Move (A1),(A2) est impossible sur les machines actuelles des PC, même sur les 64 bits.
Il faut passer par l'intermédiaire d'un registre pour obtenir le même résultat.

Ah, ce n'est pas le meilleur exemple ! Car...

Code : Tout sélectionner

! movsw

... fait l'équivalent.

De mémoire, le 68000 a moins de registres dédiés, ce qui permet une souplesse de programmation différente, donc un esprit de programmation différent.

En reprenant l'exemple de "move", movsw signifie...

Code : Tout sélectionner

MOV WORD PTR [DI],[SI] ; instruction inexistante

DI et SI étant respectivement deux registres "Destination Index" et "Source Index".
Il est impossible de choisir d'autres registres. Je pense que le 8086 se permet plus d'instructions car ses opérandes mémoire étant dédiées, il ne faut que peu de bits d'instruction pour déterminer un calcul de pointeurs, en l'occurence, 3 bits sur 16 :

Code : Tout sélectionner

[BX+SI] ; base register + source index
[BX+DI] ; base register + destination index
[BP+SI] ; base pointor + source index
[BP+DI] ; base pointor + destination index
[SI]
[DI]
[immediate 16 bits]
[BX]

La dédicace permet aussi des instructions redondantes, donc une signature logicielle, voire d'y inclure un message dans le code machine, qui est absolument indétectable à l'exécution du code machine. Cela permet aussi des instructions machine cachées, à des fins militaires.