Noyau 64 bits : appel aux béta-testeurs.

Là, NArdo26, tu as raison. Mais pour moi, il s'agirait là de compatibilité descendante ! Et elle ne peut guère être garantie. Les programmes fats avant, tournant en version 32 bits, tourneront en nouvelle version 64 bits - c'est ça, la compatibilité ascendante. A moins que tu aies conçu un programme explicitement de sorte à utiliser la limitations à 32 bits dans les calculs ou opérations binaires (avec des rotations, par exemple) ou la limitation à 4 octets par mot. Mais même les opérations FILEBIN_xxx se dérouleront normalement, telles qu'elles sont conçues.

Je te renvois sur la définition (ici)
Quand aux opérations FILEBIN_XXX, elles travaillent sur l'octet, donc pas de soucis...

Non, là où cela risque poser problème c'est sur des calculs mathématiques plus complexes qui nécessitent des nombres supérieur à 32 bits...
Dans ce cas, le programme ne tournera pas correctement sur une version 32.

Sauf bien sur si Jack limite toutes les variables Panoramic en 32 bits...(auquel cas, la question ne se pose plus...)

Evidemment, un programme qui utilise la capacité de 64 bits pour les calculs, ne pourra plus tourner sur un système 32 bits. Mais là, c'est justement la compatibilité descendante - toute nouvelle fonction n'est pas garantie de marcher que les anciennes configurations. Mais la compatibilité ascendante reste assurée: tout programme existant (utilisant forcément le mode 32 bits) tournera tel quel en mode 64 bits.

Supposons que mon programme (version actuelle donc 32 bits) soit ainsi codé

Code:

DIM MinInt%,MaxInt%
Maxint% = 2147483647 : MinInt% = 0-MaxInt%-1
print "Entier signé sur 32 bits : ";MinInt%;" ---> ";MaxInt%

Si, dans la future version (64 bits), la déclaration des entiers se fera de la même façon (DIM A%), mon programme (ci-dessus) devra tourner sans problème même si les entiers signés seront codés sur 64 bits.
La seule différence est que l’on peut étendre la plage des entiers de -9223372036854775808 à +2233720368547755807.
Dans ce cas, mon programme reste compatible avec la version 64 bits puisque : qui peut le plus peut le moins.

On peut aussi imaginer une autre déclaration des entiers sur 64 bits ( en plus de DIM a% comme ceci ( ou toute autre syntaxe)

Code:

DIM A%  :  ‘  entier signé codé sur 32 bits
DIM B%% :  ‘  entier signé codé sur 64 bits

Ainsi la compatibilité ascendante sera garantie.

heu...et vous faites quoi des réels

qui actuellement sont déclarés par leur simple nom de variable

dim A

C'est le dernier jour, donc je peux faire le malin:

Citation :

dim A

Dim Ahlala! (que les temps sont durs!

Certains langages disposent de plusieurs types d’entiers (INTEGER, SHORTINT, LONGINT, BYTE, WORD) ou autres syntaxes.
Je pense que ceci est pour la raison que le programmeur puisse choisir lui-même son type pour mieux maitriser l’exécution de son programme.
En effet, tous ces types d’entiers nécessitent un espace de stockage mémoire sur 1, 2, 4 octets ou plus.
Selon, sa configuration matérielle, le programmeur peut faire son choix.
Une autre raison : la vitesse d’exécution d’une opération.
Les opérations sur 16 bits sont plus rapides que celles sur 32 bits, lesquelles sont aussi plus rapides que celles sur 64 bits.

Je pense qu’en ne modifiant pas la syntaxe actuelle pour la déclaration des variables, à savoir :
DIM A% pour les entiers
DIM X pour les flottants
nos programmes (écrits en 32 bits) tourneront sans problème sur la version en 64 bits : la réciproque n’est pas vraie !

WAIT AND SEE !

Suis-je en train de faire le malin comme Cosmos70? .

BONNE ANNEE 2013 (MMXIII)

Je le vois aussi comme ça, Papydall.

Et des déclarations comme % pour des entiers 32 bits et %% pour des entiers 64 bits, cela me semble scabreux. Et comment alors définir des flottants 32 bits et 64 bits ?

Pour moi, la simplicité doit primer, et cela signifie ne rien changer à la syntaxe, et de façon interne, traiter en mode 64 bits tout en 64 bits, et traiter en mode 32 bits tout en 32 bits. Implicitement, sans autre précision dans le langage.

C'est surtout dans le sens 64 bits -> 32 bits que le problème se posera...
Certains calculs seront réalisables en 64bits et pas en 32...
Mais bon, cela représente 0.001% des cas d'utilisation des entiers avec les programmes que nous faisons actuellement...
Par exemple dans le cas de génération de fichiers binaires où l'on doit stocker des valeurs négatives...

Là, tu touches un point délicat. Mais pour le cas de valeurs (entières ou flottantes) stockées dans un fichier binaire, il ne peut y être question de portabilité ascendante ou descendante. Car, par définition, un fichier binaire est une suite d'octets binaires de 8 bits, dont l'interprétation de la structure interne est à la charge du programme.

C'est comme le cas des fichier BMP ou GIF, si on essaie de les lire en Panoramic. Il faut connaître la structure, se faire des sous_programmes ou procédures de service pour se positionner et pour lire ou écrire des parties relevantes de données etc.

Dès l'instant que tu fais cela avec un fichier binaire contenant des valeurs entières ou flottantes, tu sais si elles ont été érites en format 32 bits ou 64 bits, parce que c'est toi qui as créé le fichier. Il t'appartient alors d'écrire les routines de positionnement, d'écriture et de lecture pour traiter un cas ou l'autre, dans un environnement ou l'autre. Pour les valeurs entières, c'est simple: on passe de 32 bits à 64 bits en dupliquant le bit 31 sur les 32 bits 32 à 63. Et pour passer de 64 bits à 32, on prend simplement les bits de 0 à 31. Cela respecte le signe et marche dans tous les cas. C'est plus compliqué pour les flottants, mais le principe est le même.

Pour 32 bits vers 64 bits, c'est une simple extension, aucune perte d'information. Pour 64 bits vers 32 bits, on a fatalement une perte d'information, dès l'instant que les bits supérieurs sont réellement utilisés. Mais ça, c'est inévitable. Et c'est surtout la raison pourquoi, de par la conception du mode Windows natif 64 bits, aucun programme 64 bits ne peut utiliser une DLL de 32 bits et inversement. Les adresses étant codées sur 32 (EDIT: correction suite à la remarque de Papydall) ou 64 bits selon les cas, elles indiquent un espace virtuel totalement différent. Et tronquer une telle adresse de 64 à 32 bits, ou l'étendre de 32 à 64 bits conduit immédiatement à une violation de mémoire.

Conclusion: les fichiers binaires ayant uns structure "propriétaire" inconnue de Panoramic, seul le "propriétaire", donc le programmeur, peut écrire les routines d'interface. Et aucun effort de Jack sur la portabilité ne pourra y changer quoi que ce soit. Dommage, mais c'est comme ça.

Salut Klaus.
Dans ton dernier post, paragraphe 4, avant dernière ligne, tu as inversé les chiffres 3 et 2 (une faute de frappe qui pourrait nuire à ma compréhension quand je relirai ce message dans un siècle !)

Alors, veuille bien corriger :
étant codées sur 23 ou 64 bits
en
étant codées sur 32 ou 64 bits

NB : ça m’arrive de faire l’intéressant, alors je le fais !
Tu ne m'en veux pas, n'est-ce pas?

@ Papydall,

Dans un siècle tu n'auras plus de problèmes de relecture
vu que l'on ne parlera plus de 32 ou 64 bits mais plutôt entre 320 et 640 bits

Dans tous les cas, les entiers sont apparemment déclarés en 32 bits

Code:

DIM i%
DIM j%
i%=4294967290
FOR j%=0 TO 10
  PRINT i%+j%;" ";HEX$(i%+j%)
NEXT j%
PRINT
PRINT hex$(ADR(i%))

et donc la fonction ADR renvoie une valeur codée sur 32 bits...

Euh... tu as une version de Panoramic en 64 bits ? La version Beta qsue Jack avait publiée au début de ce fil de discussion, a été retiré et était en réalité une version 32 bits ! Je l'ai garder et l'utilise régulièrement sous XP 32 bits car elle a des nouveautés qui manquaient avant, mais ce n'est pas une version 32 bits ! Normal donc si ton code montre un codage interne sur 32 bits. Et à moins que j'aie manqué un truc, la version 64 bits n'est pas encore en ligne. Corrige-moi si je me trompe.

Et tu peux essayer avec l'utilitaire gratuit WhichMachine disponible ici. Il teste un EXE ou une DLL pour déterminer si c'est fait pour 32 ou 64 bits. Très facile et très rapide. Comme ça, tu sauras.

y a t il un moyen de compiler un source avec la version retiré de jack ?

Klaus a écrit:

Euh... tu as une version de Panoramic en 64 bits ? ...

Oui voir page 4 (tout en bas), jack a mis une version de l'executable en 64 bits

Désolé, Nardo26. C'est une version 32 bits ! Elle tourne sous mon EX PRO 32 nits. Et l'utilitaire indiqué ci-dessus le confirme. Ce n'est pas une version 64 bits !

EDIT

Autant pour moi ! Je me suis trompé de fichier, et ce que tu indiques, est bien une version pour 64 bits !
Désolé pour cette erreur !

Mais avec cette version, un entier DOIT pouvoir contenir un handle:

Code:

dim h%
h% = handle(0)

Et le handle est TOUJOURS codé sur 64 bits. alors, si h% n'est que de 32 bits, Panoramic 64 bits a des soucis à se faire !

Klaus, le bout de code que j'ai mis précédemment me donne exactement le même résultat, que ce soit en 32 ou 64 bits...

Spoiler:

Que hex$(ADR(i%)) ne donne pas plus de chiffres, ce n'est pas significatif: la fonction hex$ ne donne pas les zéros à gauche. Mais les additions: si le résultat est identique en 64 bits, c'est qu'il y a vraiment un problème. Dans ce cas, il faudrait que Jack jette un coup d'oeil.

Je confirme: j'obtiens exactement le même résultat...

Alors, Jack, explique-nous s'il te plaît: comment sont représentés entiers Panoramic (et accessoirement les flottants) dans la version 64 bits ? Toujours limités à 32 bits ?

Je pense que Jack a compilé son interpréteur en 64 bits (le noyau lui-meme) mais que fondamentalement le langage Panoramic (vu coté utilisateur) est toujours limité en 32...

Si c'est vraiment le cas, cela ne marchera pas. Impossible d'utiliser les handle ni adr().

@Jack:
Pourrais-tu s'il te plaît nous donner une information sur la façon dont seront codés les entiers et flottants dans la version 64 bits de Panoramic ? Si je fais DIM i%,f est-ce que i% et g sont bien en 64 bits ou restent-ils en 32 bits ? J"ai besoin de cette précision pour le portage de mes DLLs en 64 bits, pour être prêt pour le jour J... Merci d'avance.