Limite de la ram - Page 1

Salut, je voulais juste savoir combien de la ram peut-on utiliser en asm.
En effet, j'ai créé qqs tableaux et il me met error out of memory, donc je suppose qu'on a pas accès aux ~180000 octets de la ram

PS: pas mal ce nouveau forum

si tu fais de l'allocation non dynamique de mem, tu peux utiliser au maximum, les 16ko que font le stack.
(je dis bien au maximum, vu qu'une partie du stack est utilisée par d'autres trucs)

Si tu fais de l'allocation dynamique de mem (ROM_CALL HeapAlloPtr et HeapAlloc, je crois) tu peux en utiliser bcp plus...

en fait je crée beaucoup de tableau en bss, du style
ds.b x

arf... OK.
Donc, c comme si tu utilisais HeapAlloc ou HeapAllocPtr : c ce que le Kernel fait pour les BSS, je crois...
Vérifie que la taille de tes tableaux n'est pas supérieure à la taille de la RAM !

oui, mais même !
il en faut aussi pour le prog que tu execute, et pour le kernel et pour les libs !
ça en laisse déjà beaucoup moins !

La taille du BSS doit etre inferieure a 64 Ko

C'est une des raisons pour laquelle il vaut mieux d'allouer sa mémoire proprement (avec les fonctions Heap*). Il suffit dans ce cas d'allouer plusieurs blocs.

oui, c pas très clair de toute façon, il vaut mieux le mettre soit même avec un Heap*, ça je suis 100% d'accord

Non, c mieux , et plus simple de faire une section BSS si la taille est connue.
En plus, si ca plante sous Unios, la memoire est quand meme liberee !
Et franchement, vous arrivez rapidement a 64 Ko ?

C'est vrai que c'est quand même plus simple de gérer la mémoire avec des labels.

Mais utiliser des labels pour accéder aux variables est inefficace. Surtout qu'on ne peut pas utiliser le mode PC-relatif pour les variables en BSS. Le mode d'adressage x(an) (voire (an)+) est beaucoup plus rapide et plus petit.

qd vous dites 64 ko pour les BSS, c'est pour la totalite ????
sinon, je les dépasse donc c'est pour cela

En fait, je voudrait 2 tableau en .b de 327xx (je sais plus bien)
Comment puis-je faire pour les libérer si les bss ne marche pas
dès que j'essaye des rom/ram call, ca passe pas (j'utilise doorsos.h et ca merde)
[edit]Edité par gugusg le 26-10-2001 à 15:52:59[/edit]

2 tableaux de 32Ko (32768 ?)
Ok, la faut faire deux appels a tios::HeapAlloc (et bien 2, pas un !)

ou je peut avoir de la doc sur les fonctions du tios???
merci d'avance.
au fait, pquoi les bss sont limités
c ptet con comme question mais ca me l'apprendra au moin

La meilleur doc sur les Rom_CALLs que tu puisses trouver est celle de TIGCC.

On ne peut allouer plus de 64ko de BSS car le kernel réserve la mémoire en une fois (pas de HeapAlloc à chaque ds.t). Ceci pour au moins 2 raisons évidentes :
- rapidité
- limitation de la fragmentation de la RAM (cause de "out of memory" alors qu'il en reste plein)

Enfin bon il y a toujours 64ko de table que l'on peut utilise et que tout le monde semble oublier!

j'ai regardé la doc de tigcc sur heapalloc, et c'est pas marqué comment s'en servir??
je fait:
jsr tios::heaphalloc(32768)
mais où va l'adresse????

Mais la doc te le dit justement !
Une documentation de librairie montre toujours le prototype des fonctions qu'elle contient. Celui de HeapAlloc est : short HeapAlloc(unsigned long Taille);

Taille ; ou move.l Var,-(a7) si la taille est dans une variable jsr tios::HeapAlloc addq.l #4,a7Cela signifie que tu dois empiler la taille de ton bloc sur 4 octets avant de sauter vers la fonction : pea
Dans d0.w tu retrouve alors le handle de ton bloc, ou 0 si l'allocation a échouée.

[edit]Edité par Thibaut le 28-10-2001 à 10:49:14[/edit]

y'a marqué cela dans la doc ???
ca ressemblait pas trop à de l'aasembleur et plus à du C !!
enfin, merci thibaut, je vais regarder cela
mais c'est vrai que la doc n'est pas de ce qu'il y a de plus clair !!

>> y'a marqué cela dans la doc ???
Ce n'est pas écrit explicitement, mais l'info est bien donnée...
>> ca ressemblait pas trop à de l'asembleur et plus à du C !!
... par le prototype de la fonction !


Je t'explique comment lire un prototype du point de vu d'un programmeur ASM :

short : le résultat sera retourné dans d0 (dans a0 pour les fonctions qui retournent un pointeur). De plus short est un type de donné qui prend 2 octets => on peut donc préciser la taille de la valeur rendue : d0.w

HeapAlloc : ben ça c'est le nom de la fonction. Il faudra donc faire 'jsr HeapAlloc'

unsigned long Taille : le paramètre dont la fonction a besoin. unsigned signifie que la taille est un nombre toujours positif. Mais en ASM ça a peu d'importance. long est la taille du paramètre : 4 octets.

Les paramètres sont à passer du dernier au premier !!!

Voilà avec ça tu peux maintenant utiliser toutes les fonctions du TIOS sans aide de notre part, vu qu'elles sont pour la plupart dans la doc de TIGCC

bon bah je vais regarder cela, mais c'est vrai que c'est plus implicite qu'autre chose leur doc

j'ai 2 problème (désolé )
- comment faire pour avoir l'adresse du handle (j'ai pas trouvé de fonction qui le fait)
- coment compiler (avec doorsos.h, il reconnait pas les fonction tios::xxx, et avec tios.h, il ne reconnait pas le xdef _ti89, donc petit problème )

Il y a certaines choses de base que tu ne sais pas je pense

Un xdef ça sert à l'assembleur (A68k) pour le forcer à référencer un label dans la tables de symboles du fichier objet qu'il crée.

el n'est défini nulle part, il y a erreur. Il te suffit tout simplement de le faire toi même, par exempe après _main :_main: _ti89:Mais si le lab
Si tu compiles avec doorsos.h alors remplace tous les tios:: par doorsos:: !

Obtenir l'adresse d'un bloc à partire de son handle se fait par la fonction HeapDeref, son prototype est : void *HeapDeref(short Handle)
L'étoile indique que la fonction retourne un pointeur (c'est bien là son rôle ), donc le résultat se trouve dans a0.

ok!!
mais l'histoire du _ti89 après _main, je ne l'avais jamais vu. en fait, avec doorsos.h, ca marchais nickel
(je savais que avec le xdef _main, fallais le _main, qu'avec le xdef _comment, fallais un _comment, mais je pensais que le xdef _ti89 servait au compilateur pour savoir à quelle calculette il avait affaire (pour créer le .89z au lieu du .9xy))
merci pour cette précision, et pour le reste.
(le coup de l'étoile pour le pointeur je savais, mais je trouvais pas la fonction, y'en a des milliers on dirait )

2 heures que je cherche un bug que je ne trouve pas

le xdef _ti89 sert au linker à savoir quel type de fichier créer : 89z ou 9xz.

On aurait pu choisir une autre méthode pour "communiquer" avec le linker : la ligne de commande.

tjrs pas trouvé mon bug

avant de me tirer un balle, je vous donne la source pour voir si vous voyez mieux que moi où ca foire :
----------------------------------------------------------------------
[edit]Edité par gugusg le 29-10-2001 à 09:53:14[/edit]

Edite ton post et refait un copier-coller de ta source entre [ pre ] et [ /pre ], là c'est trop illisible.