Jump to content

le GPU


Orion_

Recommended Posts

  • Replies 58
  • Created
  • Last Reply

Top Posters In This Topic

SCPCD :


- il ne faut pas oublié que le GPU/DSP execute toujours l'instruction qui suit un jump/jr donc dans ce cas, je ne sais plus trop comment il gere les flags pour le saut.





Ce code fonctionnera correctement, car le jr récupere les flags de l'instruction précédente quitte a generer des waits states, j'en ai fais plusieurs fois l'essais et seulement après ca, les flags seront modifié par ton addq. Car le test est la première opérande et est décodé avant tout.



J'ai des code comme cela dans un paquet de routine, je crois meme dans la routine de décompactage.





GT
Link to comment
Share on other sites

Orion_ :


soit un blitter qui est capable de faire des operations d'addition et saturation par octets :/





SCPCD a raison, c'est surement jouable regarde dans les registres du blitter pour faire du Gouraud, la Sat est hardware dans ce cas, peut ètre qu'en mettant les bonnes valeurs dans le registre d'incrément...



A essayer ;)



GT A pas encore essayé le Gouraud :D
Link to comment
Share on other sites

  • 1 month later...

Salut,

 

A tous ceux qui étaient présents hier soir sur la discussion du GPU,

oubliez l'hypothèse de bug qu'on a soulevé, c'est pas du tout ça!!

Pardon GPU, je ne douterais plus jamais de toi <_<

 

Le problème était que je lisais un mot long à une adresse non alignée

sur 32 bits (mais sur 16 bits)... du coup, en rajoutant un nop, ça corrigeait

ce problème!

 

Cette macro peut être utile dans MadMac:

 

.macro align32nop

.if (*-\1)%4 == 0

.print "Adding padding nop"

nop

.endif

.endm

 

et c'est bizarre, l'* n'a pas l'air d'être l'adresse du nop

mais l'adresse du nop +/- 2

ce qui explique le == 0

 

Seb

 

 

et c'est bizarre, l'* n'a pas l'air d'être l'adresse du nop

mais l'adresse du nop +/- 2

ce qui explique le == 0

 

non, en fait, c'est juste madmac qui est pourri et qui ignore superbement

le == 0

donc la condition est vrai si (*-\1)%4 est non nul

c'est à dire = 2 si on suppose que * et \1 sont toujours pairs!

 

Seb

 

la bonne macro est donc

 

.macro align32nop

.if (*-\1)%4

.print "Adding padding nop"

.print (*-\1)%4

nop

.endif

.endm

Link to comment
Share on other sites

A tous ceux qui étaient présents hier soir sur la discussion du GPU,

oubliez l'hypothèse de bug qu'on a soulevé, c'est pas du tout ça!!

Pardon GPU, je ne douterais plus jamais de toi <_<

 

Le problème était que je lisais un mot long à une adresse non alignée

sur 32 bits (mais sur 16 bits)... du coup, en rajoutant un nop, ça corrigeait

ce problème!

Ben voila :)

tout s'arrange :)

 

Cette macro peut être utile dans MadMac:

:o Le FOU des MACROS :lol:

Link to comment
Share on other sites

  • 2 weeks later...

J'avais dit que je ne dirai plus de mal du GPU mais là!!

 

j'ai litéralement ce bout de code au milieu d'une routine au GPU (devinez laquelle!)

 

...

moveq #RANDGEN_J,r4

load (r14+r4),r5

...

 

maintenant, si je remplace donc ces deux lignes par:

 

...

load (r14+RANDGEN_J),r5

...

 

alors là, tout foire! :blink: (enfin, ça ne se comporte mais alors plus du tout de la même façon)

si quelqu'un a une explication, je prends!

 

Seb

Link to comment
Share on other sites

A première vue, ton code est tout a fait juste, MadMac aurait peut ètre du mal a assembler le 'load (r14+n),rn' et le 'load (r14+rn),rn' doit fonctionner, tu as essayé de déssassembler ton code pour voir ce que MadMac a gribouillé ?

 

 

GT Curieux ;)

Link to comment
Share on other sites

A première vue, ton code est tout a fait juste, MadMac aurait peut ètre du mal a assembler le 'load (r14+n),rn' et le 'load (r14+rn),rn' doit fonctionner, tu as essayé de déssassembler ton code pour voir ce que MadMac a gribouillé ?

GT Curieux ;)

 

oui, ça avait l'air d'être bon de ce coté là

 

j'ai aussi oublié de dire que Project Tempest émule mal

la Jaguar (on le savait!) puisque ces deux codes sont

équivalents sous PT!

 

Seb

Link to comment
Share on other sites

j'ai aussi oublié de dire que Project Tempest émule mal

la Jaguar (on le savait!) puisque ces deux codes sont

équivalents sous PT!

 

Seb

 

Super :huh: D'ou l'imcompatibilité avec certains codes, assemble a la main (dc.w $xxxx) (Heuresement que c'est un Risc) ;)

 

GT Artisanal dans mon code :blink:

Link to comment
Share on other sites

Super :huh: D'ou l'imcompatibilité avec certains codes, assemble a la main (dc.w $xxxx) (Heuresement que c'est un Risc) ;)

 

GT Artisanal dans mon code :blink:

 

non, je pense que tu m'as mal compris

je disais juste que pour PT, ma transformation

de code est valide (comme je m'y attend quoi :D )

 

Seb

Link to comment
Share on other sites

non, je pense que tu m'as mal compris

 

Pour changer :lol:

 

je disais juste que pour PT, ma transformation

de code est valide (comme je m'y attend quoi :D )

 

Seb

 

Pour moi aussi B)

 

GT D'accord

Link to comment
Share on other sites

Seb,

 

C'est pas juste parceque le load (RN+n),RN prend le 'n' comme un index de LONG ?

 

Me suis déjà fait avoir...

 

oui, c'est ce qu'il y a écrit dans la doc

moi je comprends donc que si j'ai un tableau de longs mots (tableau aligné évidemment)

et que r14 pointe au début

je peux accéder au i-ème élément avec (r14+i)

 

mais est-ce que ça ne serait pas plutôt (r14+4*i) ?

 

Seb

Link to comment
Share on other sites

oui, c'est ce qu'il y a écrit dans la doc

moi je comprends donc que si j'ai un tableau de longs mots (tableau aligné évidemment)

et que r14 pointe au début

je peux accéder au i-ème élément avec (r14+i)

 

mais est-ce que ça ne serait pas plutôt (r14+4*i) ?

 

Seb

 

Le "load (r14+rn),r5" est différent de "load (r14+n),r5"

dans le premier cas :

le load lit la valeur a l'adresse r14+rn, dans le second cas, le load lit ce qui est a l'adresse r14+4*n.

Car n est un offset en long word et non en byte.

Si tu reprends l'idée de l'adressage de tableau, tes cases de tableau étant en long word tu accedes a la seconde valeur en allant a l'adresse X+4*1.

 

 

C'est ecrit dans la doc :

"The offset is in long words, not in bytes, therefore a divide by four should be used on any label arithmetic to give the offset."

;)

Link to comment
Share on other sites

Le "load (r14+rn),r5" est différent de "load (r14+n),r5"

dans le premier cas :

le load lit la valeur a l'adresse r14+rn, dans le second cas, le load lit ce qui est a l'adresse r14+4*n.

Car n est un offset en long word et non en byte.

Si tu reprends l'idée de l'adressage de tableau, tes cases de tableau étant en long word tu accedes a la seconde valeur en allant a l'adresse X+4*1.

C'est ecrit dans la doc :

"The offset is in long words, not in bytes, therefore a divide by four should be used on any label arithmetic to give the offset."

;)

 

d'accord

donc c'est le load (r14+rn) que j'avais mal interprété

merci je comprends mieux alors

(mais c'est quand même un peu bizarre cette histoire, je ne comprends alors pas pourquoi ça se comporte comme je veux avec les load (r14+rn) alors que je divisais par 4 les valeurs dans rn)

 

Seb

 

PS: de toute façon, j'ai changé mon fusil d'épaule et réécrit le code autrement du coup!

Link to comment
Share on other sites

Alors autre question en rapport

(puisque mes index en registre amenaient à cette situation)

 

Que fait la Jag en cas d'accès non alignés :

1- en mémoire interne

2- en mémoire externe

??

 

Pour Project Tempest 0.95

les accès mémoire non alignés

1-en mémoire interne : plantent PT

2-en mémoire externe : font quelque chose (ne plantent pas toujours en tout cas)

 

Pour la 0.5, les deux font quelque chose (ne plantent pas).

 

Seb

Link to comment
Share on other sites

Alors autre question en rapport

(puisque mes index en registre amenaient à cette situation)

 

Que fait la Jag en cas d'accès non alignés :

1- en mémoire interne

2- en mémoire externe

Alors j'ai pas vraiment trouvé, faut que je cherche d'avantage mais je pense ceci :

1- en interne (ca j'en suis sur), il y a alignement de l'adresse sur le longword en dessous et lit/ecrit le longword en entier.

2- en externe, je pense que le même principe est apliqué mais j'en suis pas sur du tout, faudrais tester.

Soit c'est ce que ca fait, soit ca fait un peu n'imp.

Link to comment
Share on other sites

d'accord donc c'est le load (r14+rn) que j'avais mal interprété

 

En fait, c'est la phrase "Otherwise like instructions 43 and 44" qui m'a fait extrapoler un peu :whistling:

 

Seb

Link to comment
Share on other sites

  • 1 month later...

ce week-end, j'ai un peu joué au GPU (les interruptions en particulier), et j'ai eu l'impression que le code PC relatif en interruption, ça lui plaisait pas trop... est-ce que vous avez déjà fait cette expérience?

 

[english]

 

this week-end, I played a bit with the GPU (and interrupts) and I had the impression that it did not like PC relative code in interrupt... does someone else has also made this experiment?

 

Seb

Link to comment
Share on other sites

ce week-end, j'ai un peu joué au GPU (les interruptions en particulier), et j'ai eu l'impression que le code PC relatif en interruption, ça lui plaisait pas trop... est-ce que vous avez déjà fait cette expérience?

 

[english]

 

this week-end, I played a bit with the GPU (and interrupts) and I had the impression that it did not like PC relative code in interrupt... does someone else has also made this experiment?

 

Seb

:huh:

Je vois pas trop pourquoi ca ne fonctionnerais pas :huh:

Si tu as respecté les regles sur les interruptions, je ne vois pas ce qui pourrait ne pas fonctionner :unsure:

a moins que tu fais des trucs louches dans ton code :D

 

[english]

If you respecte all laws for the GPU interrupts, I don't understand why this don't work :unsure:

unless you made strange things in your code :D

Link to comment
Share on other sites

:huh:

Je vois pas trop pourquoi ca ne fonctionnerais pas :huh:

Si tu as respecté les regles sur les interruptions, je ne vois pas ce qui pourrait ne pas fonctionner :unsure:

a moins que tu fais des trucs louches dans ton code :D

 

[english]

If you respecte all laws for the GPU interrupts, I don't understand why this don't work :unsure:

unless you made strange things in your code :D

 

 

oui, moi non plus, je ne comprends pas vraiment

j'ai switché pour du code absolu et ça a marché...

(mon code PC relatif marchait avant que je le mette en interruption)

 

[english]

 

yes, me neither

I changed for absolute code and it worked so I concluded that something was wrong with PC relative code and interrupts

(my PC relative code worked before I put it in interrupt)

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...