nostub / kernel pb - Page 1

quand je compile mon prog en mode kernel tt ma'rche très bien, mais quand je le compile en nostub, j'obtient un illegal instruction ds la plus grande partie du code (j'arrive a le lancer quand mm)

on peut m'expliquer ???

attention ca vas mal finir ce topic

ça va chauffer dans les casebas...

le prog est prevu d'etre en nostub mais pour essayer j'ai essayer en mode kernel, et la ça marche par contre
mais moi je veux en nostub !

t'utilises pas de librairies au moins ?

nan aucunes, chuis pas non plus bete a ce point la

au niveau de la gestion de la mem. ?

ben la je sais pas trop, j'utilise 2 ecrans virtuels en local...

mais par contre pourquoi ça marcherait en mode kernel alors ???

Laisse le en kernel alors.

ben non je ne veux pas pasque j'ai besoin de le compresser ensuite au format ppg
je sais y a runc mais j'ai pas envie de 36 format de compression, et pis c moins pratique

> j'utilise 2 ecrans virtuels en local...

Alloue-les avec malloc plutôt.

S'ils ne servent que dans la routine, alloca est largement préférable : ça n'utilise pas de mémoire (paradoxal ) et tu es sûr que le bloc ne sera jamais déplacé (=> moins de risques de plantages).

>Thibaut: S'ils ne servent que dans la routine, alloca est largement préférable : ça n'utilise pas de mémoire (paradoxal ) et tu es sûr que le bloc ne sera jamais déplacé (=> moins de risques de plantages).

NON! alloca alloue la place sur la pile! Donc ça n'a aucun intérêt par rapport à une variable locale.
Et malloc est un alias pour HeapAllocPtr qui utilise HeapAllocHigh qui verrouille automatiquement le bloc, donc un bloc alloué avec malloc ne sera jamais déplacé par AMS.

Ca n'explique pas que ca marche en kernel.
A si. Il y aurait pas un SAVE_SCREEN a la con qui traine ?

Et oui, #define SAVE_SCREEN prend 3840 octets de pile. Soit tu sauvegardes l'écran toi-même autre part (sur le heap, donc dans un bloc alloué avec malloc), soit tu alloues tes plans avec malloc plutôt que de les mettre en local.

>> NON! alloca alloue la place sur la pile ! Donc ça n'a aucun intérêt par rapport à une variable locale.
Je sais pas si son buffer est alloué par une déclaration de tableau locale, mais dans la négative, alloca est préférable car :
1 - plus rapide (un HeapCompress ne risque pas d'arriver)
2 - limite la fragmentation de la RAM (1 bloc de moins c'est une gêne en moins pour les blocs qui se redimensionnent dans son prog)
3 - n'utilise pas de RAM
4 - limitation des risques de plantages car pas besoin de libérer le bloc "à la main", donc si son code modifie le pointeur c'est pas grave.

alloca utilise de la RAM, et justement dans la place où en a le plus besoin, dans la pile. Et si son programme plante à cause d'un débordement de la pile, utiliser alloca ne changera absolument rien au problème! Il faut utiliser malloc.

Mais non, bordel !
Il n'a pas parlé comme message d'erreur de "Stack Overflow"
Donc alloca reste le mieux, cf arguments cités précédemment.

Arrête de toujours vouloir me contredire

>obza_Fazer:
>ben la je sais pas trop, j'utilise 2 ecrans virtuels en local...
>
>mais par contre pourquoi ça marcherait en mode kernel alors ???

[...]

>PpHd:
>A si. Il y aurait pas un SAVE_SCREEN a la con qui traine ?

>Kevin Kofler:
>Et oui, #define SAVE_SCREEN prend 3840 octets de pile. Soit tu sauvegardes l'écran toi-même autre part (sur le heap, donc dans un bloc alloué avec malloc), soit tu alloues tes plans avec malloc plutôt que de les mettre en local.

Voilà pourquoi je suppose que c'est un problème de débordement de pile.

Et alloca est une fonction totalement inutile qui n'a aucun intérêt face à une simple variable locale à _main (que obza_Fazer utilise déjà, et qui n'a pas l'air de fonctionner).

ZdRUbAl est presque aussi bon que Coperfield avec le loto allemenad

C'était évident

Kevin : ben moi j'aime bien alloca. C'est pas une fonction, et puis ça permet de créer (façon de dire bien sûr) son buffer à n'importe quel endroit du code (en C les vars locales ne peuvent être déclarées qu'en début de bloc, [pub]contrairement à l'Azur[/pub]).

trop pur ! Je sais debuggue en nostub !

Que puis-je prédire de plus maintenant ?

(petite comparaison Extgraph / Genclib)

ben oui j'ai declaré mes buffer avec malloc cette fois et c tt ok, plus de pb en nostub
donc merci

Merci PpHd. (Tu viens de faire en sorte qu'il y ait un programme _nostub en plus et un programme kernel en moins. )

PpHd >> tu tombes dans la facilité ou koi ???

Laisse le en kernel alors.

Kevin Kofler > ne t'exite pas comme ça, c t clair et net que je voulais qu'il soit en nostub, donc au pir j'aurais tt reecrit la partie qui foire jusqu'a ce que ça marche

Je suis d'abord pour debugguer les programmes !