Azrael

Ben oui, c'est ce qu'on appelle un depassement de capacite, et ca a toujours existe

J'ai remodifie l'URL, elle fonctionne Mais faut pas non plus etre trop hors sujet, car la on part dans la racine carree et pas la 3D.

Je suppose que personne ici n'a acces au PDF a cette adresse : ICI Edit : J'ai modifie le message sinon RaZ allait me tuer pour avoir demoli la mise en page... Edit Edit : ben non, serait-ce un bug pour des url trop longues ? Edit Edit Edit : modifiee one more time

GT, RaZ s'en fout, il a son jeu deja tout pret : Grand Tourismo Nan, si tu veux des graph j'ai des artistes en herbe prets a t'en faire tout plein, les amies de ma copine sont en plein pouponage, donc des dessins tu en auras de tres jolis Ton gazon tu le veux bleu ou bien marron ?

Merci, c'est vrai qu'elle est courte. Apres quelques recherches, il y en a pas mal sur l'Atari Forum.

Merci CTS ! En 3D, dans le calcul de la matrice de changement de base tu n'as jamais eu de division negative ? En fait il se peut que le determinant a calculer soit toujours positif.

Tu as un truc a nous montrer RaZ ?

CTS, au lieu de faire un trois MMULT il n'est pas plus judicieux de faire trois (IMULTN, IMACN, IMACN et RESMAC) ? En oubliant bien sur les translations. Je vois aussi que tu as un calcul de racine carree, tu utilises quelle sorte de routine ? Pour ma part je fais une table de precalcul.

CTS, toi qui a fait de la 3D, tu n'as pas fait de division signee ?

Autre chose : si c'est bien ce que je pense, SHARQ est arithmetique (c'est pas nouveau, c'est dans la doc), mais SHLQ l'est aussi pour les memes raisons que mon post precedent. Tout ceci est a verifier bien entendu.

C'est la meme explication que SCPCD : ex sur 8bits : non signé : 00000110 = 6 shl 1 -> 00001100 = 12 signé : 11111101 = -3 shl 1 -> 11111010 = -6 Je rajouterai qu'un SHA vers la droite te complete avec des bits 1 a gauche, comme ca ton nombre reste negatif. Avec ton exemple : 10111101 avec un decalage a gauche le chiffre passe au positif, ok, mais je dirais aussi que tu a un depassement de capacite, avec 32 bits faut quand meme le faire.

Et faire un SHA tout simplement ça fonctionne pas ? De toute maniere le decalage a gauche est arithmetique a cause du complement a zero, mais le decalage droit a besoin d'etre arithmetique, d'ou la nuance dans le descriptif de l'instruction. Ceci dit je peux me tromper.

Yep, enfin c'est pas la dernière, il y a le pipelining a considerer donc la position des instructions a changer.

Bon... RAZ !!!! tu arretes Grand Tourismo et tu vas faire des dessins !!!

Je veux pas trop jouer mon chieur, mais d'après ta propre traduction IMULT est une multiplication signee alors que MULT n'est pas signee, donc le pied serait quand meme d'avoir un IDIV et pas un DIVS. Ceci dit on a un petit probleme avec la routine precedente. La multiplication prend des registres de 16 bits alors que la division en prend de 32 bit. Bref, quand on evalue le bit de signe c'est avec des registres de 16 bits. Il faudrait faire un decalage de chaque registre a multiplier pour avoir le bit de signe au bon endroit... ou bien le bit de signe est toujours en position 32 meme pour des entiers codes sur 16 bits ? Si la reponse a derniere question est vrai, alors la routine doit marcher... En fait je crois que ca marche, sinon c'est un enfer a coder... J'ai rien dit, vous pouvez aller mater la tele tranquille... moi je retourne me coucher.

Certainement, mais il n'y a que la pratique qui permet d'optimiser le code.

ok, merci de le préciser quelle equipe !! mais je n'ai pas les instructions gpu/dsp sous la main, d'ailleurs je ne sais pas comment fonctionne la puce (nombre de registres de données et d'adresse, instructions possibles avec des constantes...) un "idiv" ca serait le pied !

Ben si, ca s'appelle de la desinformation, pratique habituelle en temps de guerre pour tromper l'ennemi !

Au fait, le dernier bit (celui de signe) est toujours mis a zero dans le resultat de la division ?

Enfin le plus pratique c'est quand meme d'ecrire une macro qui fait ca, tant pit pour les cycles perdus, a moins d'etre dans une boucle assez courte auquel cas la macro est remplacee par ce code.

enfin bon, faire une multiplication pour une division... c'est quand meme un comble !!! il n'y a vraiment pas de division signee ???? c'est une puce prehistorique, c'est pas possible !!! Il n'y a pas une histoire de cache et d'instruction qu'il faut entrelacer pour que ca aille plus vite ?

encore plus court, mais peut etre pas plus rapide : movei #$80000000,r20 move r1,r3 mul r2,r3 ; on fait une petite mul pour recuperer signe de r1*r2 and r20,r3 ; on récup juste le bit de signe de r3 dans r3 abs r1 ; Absolution de r1 !! abs r2 ; Absolution de r2 !! div r1,r2 ; on divise r2 par r1 or r3,r2 ; on rajoute le signe...

PAs de division signee ???? j'hallucine ! Ca a l'air correct Ce qui casse toute la vitesse c'est les tests pour l'instant je ne vois pas le moyen de les virer... a moins que...

Ouais, ben je suis incapable de te dire a quoi correspondent tous les parametres, pas envie de me replonger dans du code non commente qui date d'il y a 10 ans ou j'avais un niveau math prepubere.

Bah, euh, oui et non, j'ai pas non plus envie de réinventer le fil a couper le beurre, donc si la theorie est la je suis preneur aussi Creer un moteur 3D gerant les faces cachees par exemple c'est pas de refus.