creer un fichier en asm - Page 4

Bon, alors on commence la rédaction de pipeline.txt ?

faudrait voir direct chez Moto, non ?

The main features of the SCM68000 include:
• Low-Power HCMOS Implementation Requires Only 15 mA at 3.3 V
• 32-Bit Performance for 16-Bit Applications—2.7 MIPS at 16 MHz
• Statically Selectable 8-Bit or 16-Bit Data Bus Operation
• 32-Bit Address Bus Directly Addresses up to 4 Gbytes of Address Space
• Static Operation Provides Almost Zero Power Consumption During Idle Periods
• Sixteen General-Purpose 32-Bit Data and Address Registers
• Fifty-Six Powerful Instruction Types That Support High-Level Programming Languages
• Fourteen Addressing Modes and Five Main Data Types Allow Compact, Efficient Code
• Seven Priority Level Interrupt Control
• Special Core Interfacing Signals
• Emulation Support Signals Including Pipeline Refill, Processor Status, and Interrupt
Pending Signals
• Both 3.3-V and 5-V Operation

The CPU32 contains a two-word instruction pipeline where instruction opcodes are
decoded. Each stage of the pipeline is initially filled under microsequencer control and
subsequently refilled by the prefetch controller as it empties.
Stage A of the instruction pipeline is a buffer. Prefetches completed on the bus before
stage B empties are temporarily stored in this buffer. Instruction words (instruction operation
words and all extension words) are decoded at stage B. Residual decoding and
execution take place in stage C.
Each pipeline stage has an associated status bit that shows whether the word in that
stage was loaded with data from a bus cycle that terminated abnormally.

hmmm... donc c'est bien un préchargement de 4 octets... (cf le test pour vti dans asm je c plus kel topic).

et si g bien compris:

A->préchargement des 2 words dans le buffer
B->décodage
C->éventuellement décodage, puis exécution

c'est ça?

sBibi : arg, tu n'as toujours pas l'air de me croire quand je dis que le nombre d'octets prechargés n'est pas constant sur TI. Tu veux peut-être une preuve en image ?

 include "OS.h"
 xdef _nostub
 xdef _ti89
 xdef _ti92plus

 lea    patch+1(pc),a0
 lea    Str(pc),a1
 move.b #$32,(a1) ;caractere "2"
 move.b #1,(a0) ;initialise
 nop
 nop
 nop ;histoire que ca perturbe pas le test
 move.b #0,(a0) ; l'instruction qu'on teste
 nop
patch:
 moveq #1,d0
 beq   DispStr
 move.b #$34,(a1) ;caractere "4"
DispStr:
 pea     (a1)
 move.l  ($c8),a0
 move.l  ST_helpMsg*4(a0),a0
 jsr     (a0)
 addq.w  #4,a7
 rts

Str dc.b "x octets prechargés",0

Tu compiles et tu lances ce programme, et ça t'indiques le nombre d'octets prechargés pour l'instruction move.b #0,(a0). Ca retoure bien 2. Et tu peux faire le meme test en remplacant le move.b #0,(a0) par clr.b (a0), et ça retournera 4.
Et tu peux faire d'autre tests qui confiremeraient que le processeur peut prechager des demi-instructions, comme je disais dans mon dernier post.

la preuve pae l'asm

ExtendeD>je n'ai pas remis en question ce que tu as dit, je constatis juste ce que le texte trouvé par Miles disait...

Il y a en tout cas un préchargement maximum de 4 octets... le fait qu'il ne précharge que deux octets pour certaines instructions a forcément une raison...
peut être que le buffer de 4 octets peut être totalement rerempli dans la partie B,alors que pour d'autres, deux octets doivent y rester, pke ça peut être par exemple nécessaire à l'exécution de l'instruction, donc seulement deux sont préchargés... j'en sais rien, ça pourrait être quelquechose comme ça...
au fait c'est quoi la taille de chacune des instructions que tu as testées?

Si je reprend celles de la page d'avant :
move.b (a0),(a1) fait précharger 2 octets, et fait 2 octets en taille.
move.b #0,(a1) fait précharger 2 octets, et fait 4 octets.
move.b #0,patch fait précharger 2 octets, et fait 8 octets.
move.w (a0),patch ne fait rien précharger, et fait 6 octets.
clr.b patch et clr.b (a0) font précharger 4 octets, et font respectivement 6 et 2 octets.

Apparement il n'y a pas de rapport avec la taille.

quel bordel

ça me donne envie de mailer motorola

ça a peut être aucun rapport, mais pour les move:

move.b -> 2 octets
move.b -> 2 octets
move.b -> 2 octets

move.w -> 0 octets

bon, et pour le clear, c'est pas la même instruction mais le même format

clr.b -> 4 octets
clr.b -> 4 octets

ça doit sans doute dépendre de comment est exécutée l'instruction...
il faudrait essayer avec sf.b patch...

Le truc bizarre, c'est que move.w (a0),(a1), par exemple, fait précharger 2 octets, alors que c'est un .w ...

...

boaf, c un bug

meuh non, ça peux pas être un bug.

je disais ça pour déconner, car c tellement curieux comme truc !