Compatibilité 89 - 92 + - Page 2

PpHd> tu es sûr de ta routine?
je pense que telle que tu l'as mise, elle ne marche pas.
il faut insérer une autre instruction entre le clr.b (a0) et le st...

par exemple:

Vti_PpHd:
lea vti+1(pc),a0
clr.b (a0)
nop
st.b (a0)
vti moveq #0,d0
bne.s CalcIsVti
RealCalc:
; ...
CalcIsVti:

en fait ta routine telle que tu l'as mise marche la première fois, puisque dans la source, c'est un moveq #0,d0 mais lors du deuxième appel, tous les bits sont armés et le clr.b (a0) n'a AUCUN effet...

pour que ça fonctionne correctement lors des appels suivants, il faut insérer une instruction supplémentaire.

je ne vois pas comment expliquer ça...
à moins que le pipeline du 68000 ne stocke DEUX instructions à l'avance

Justement, comme une seule instruction est stockée à l'avance, le clr.b a un effet.

désolé, mais non
ça ne marche pas, je l'ai essayé
le code de PpHd tel quel marche à son premier appel, mais dès que tu l'appeles plus d'une fois ou que tu relances simplement le programme, il détecte vti alors que c'est une vraie ti...

par contre, en rajoutant une instruction entre les deux, ça marche à chaque fois...
si le 68000 ne charge q'une instruction, expliquez moi pourquoi ça ne marche pas

je regrette, mais vous vous êtes plantés
ceci dit, j'ai testé sur ma 92+ hw2, PpHd a du le tester sur sa hw1...
peut être qu'il y a quelquechose dans le hw qui diffère et qui influence ça...
ce serait étonnant, ms bon.

Ha là là tu pars en couilles PpHd, deux erreurs en un jour

ah bah oui, peut-être bien que 2 instructions sont chargées...

c'est ce qu'on dirait
en tt cas, je vois pas comment l'expliquer autrement
dans ce cas le pipeline est un tout peti peu moins merdique que ce qu'on pensait
[edit]Edité par sBibi le 15-12-2001 à 22:32:17[/edit]

Ce sont probablement 4 octets qui sont chargés. Donc si on met et change un move.w, le processeur s'en rend compte (les données immédiates ne sont qu'après les 2 octets de l'instruction elle-même), mais si on met et change un moveq, il ne s'en rend pas compte.

À vérifier:

 lea vti+3(pc),a0 
 clr.b (a0) 
 st.b (a0) 
vti move.w #0,d0 
 bne.s CalcIsVti 
RealCalc: 
; ... 
CalcIsVti:

Si j'ai raison, ça marchera. Si j'ai tord, et que ce sont toujours 2 instructions qui sont chargées à l'avance, ça fera la même chose qu'avec moveq.

tu as raison... ça marche comme ça
donc il précharge 4 octets...
cad qu'il peut précharger une seule ou plusieurs instructions selon leur type...
hmmm...
c intéressant tout ça

au fait, on pe pas faire un truc comme ça:

 lea vti(pc),a0
 move.w #$6700,(a0) ;ou l'inverse, je c pas... 6700 - 6600 ou 6600 - 6700
 move.w #$6600,(a0)
vti bne CalcIsVti
 ;real ti
CalcIsVti

(ça marche sans doute pas, comme d'hab )
[edit]Edité par sBibi le 16-12-2001 à 02:38:01[/edit]

Déjà, tu devras mettre un bne.w explicit si tu veux faire ça (sinon A68k 2.71.F3e t'en fera un bne.s et tes codes ne sont plus bons).

ba ça marche aussi sans le .w, comme je l'ai mis... vien d'essayer...
et avec le .w ça marche ossi...
ms bon, je préfère mettre le .w quand même

euh, apparemment mon truc ça sert à rien
on dirait ke c le même nombre de cycles ke celui de PpHd, et la même taille ossi
ms bon, ça marche qd même alors...

et c'est bien ça pour l'ordre des $6700/$6600
[edit]Edité par sBibi le 16-12-2001 à 03:20:03[/edit]

>ba ça marche aussi sans le .w, comme je l'ai mis... vien d'essayer...

Alors ta version de A68k est suffisamment ancienne pour ne pas optimiser les branchements (c'est un bogue connu de la version 2.71.F2 - corrigé depuis la 2.71.F3 déjà). Si tu n'arrives toujours pas à télécharger TIGCC (ce qui n'est pas normal), la version la plus récente est aussi là. Mais je te conseille quand-même TIGCC en entier.

je viens d'arriver à le dl il y a 20 min
mais la version ke j'av était dans le pack des alternative files dispo sur le site de tigcc

Si tu avais lu le readme des Alternative Files, tu saurais que c'est une ancienne version. (Tous les fichiers là-dedans sont d'anciennes versions - il faudrait peut-être changer le nom en "Old Files", ça serait plus explicit.)
[edit]Edité par Kevin Kofler le 16-12-2001 à 03:34:50[/edit]

bah... ok, ça fé comme tu dis ac la nvelle version de a68k...
et pr le readme-> qd g vu ke ct just des noms, g fermé sans voir le piti text en bas
v dormir... bonne nuit

J'ai verifie et il faut bien une instruction supplementaire.
Or le 68k, n'a une pipeline que de lecture.
D'ou j'en deduis que Motorola a change des trucs depuis le debut.
Je peux avoir un vieux 68000 pour tester ?

je c pas... c bizarre, parce que ma méthode marche nikel à chaque fois...
bon... récapitulatons...

méthode à PpHd:

Vti_PpHd: 
  lea vti+1(pc),a0 
  clr.b (a0) 
  st.b (a0) 
vti moveq #0,d0 
  bne.s CalcIsVti 
RealCalc: 
  ; ... 
CalcIsVti:

marche au premier appel, pas aux autres

Vti_PpHd: 
  lea vti+1(pc),a0 
  clr.b (a0)
  nop 
  st.b (a0) 
vti moveq #0,d0 
  bne.s CalcIsVti 
RealCalc: 
  ; ... 
CalcIsVti:

marche tout le temps

Vti_PpHd: 
  lea vti+3(pc),a0 
  clr.b (a0) 
  st.b (a0) 
vti move.w #0,d0 
  bne.s CalcIsVti 
RealCalc: 
  ; ... 
CalcIsVti:

marche tout le temps


et mon truc:

vti_sBibi:
  lea vti(pc),a0
  move.w #$6700,(a0) ;ou l'inverse, je c pas... 6700 - 6600 ou 6600 - 6700
  move.w #$6600,(a0)
vti bne.w CalcIsVti
  ;real ti
CalcIsVti

marche tout le temps


donc je ne pense pas que ça se compte vraiment en instructions...
ce serait plutôt un truc comme l'a dit kevin...
[edit]Edité par sBibi le 21-12-2001 à 13:29:07[/edit]

Le pipeline charge un certain nombre d'octets au maximum. Il est vidé lors d'un saut.

boon, ben voila, c'est ce que pensait Kevin, ça charge 4 octets, et hop...