Page 1 sur 2
Debug Chr(0)
Publié : ven. 24/févr./2023 2:26
par 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 !

Re: Debug Chr(0)
Publié : ven. 24/févr./2023 4:52
par boddhi
Pas de plantage sur Win10 x64 / PB 6.00 LTS x64

Re: Debug Chr(0)
Publié : ven. 24/févr./2023 6:27
par SPH
boddhi a écrit : ven. 24/févr./2023 4:52
Pas de plantage sur Win10 x64 / PB 6.00 LTS x64
Même config et ça marche aussi.

Re: Debug Chr(0)
Publié : sam. 25/févr./2023 13:55
par 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.
Re: Debug Chr(0)
Publié : sam. 25/févr./2023 13:58
par pat
et il vaut mieux ne pas mettre chr(0) seul car fin de chaîne.
Re: Debug Chr(0)
Publié : sam. 25/févr./2023 14:00
par pat
Et tout dépendra du compilateur.
Cela peut ou ne peut pas fonctionner.
Re: Debug Chr(0)
Publié : sam. 25/févr./2023 15:05
par falsam
Hoooo un revenant de l'ombre. Hello Pat.
Re: Debug Chr(0)
Publié : mer. 03/mai/2023 14:35
par 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.
Re: Debug Chr(0)
Publié : mer. 03/mai/2023 15:38
par Ollivier
pat a écrit : mer. 03/mai/2023 14:35
[...] 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)
Re: Debug Chr(0)
Publié : jeu. 04/mai/2023 14:01
par 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.
Re: Debug Chr(0)
Publié : ven. 05/mai/2023 14:17
par 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.
Re: Debug Chr(0)
Publié : ven. 05/mai/2023 15:51
par SPH
Amiga ?
Re: Debug Chr(0)
Publié : ven. 05/mai/2023 16:05
par 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.
Re: Debug Chr(0)
Publié : mar. 16/mai/2023 14:55
par 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.
Re: Debug Chr(0)
Publié : jeu. 25/mai/2023 19:04
par Ollivier
Pat a écrit :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...
... 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...
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.