Compilateur oncalc - Page 3

Ca marche peut être sur PedRom mais je suis sur ams (en term S g pas le choix)
Et diam + /, j'avais déja essayé....
Donc side est inutilisable pour la compilation.......

Quant à CC,
La seule URL ou je le trouve, c'est celle donnée au début de ce topic et c'est la version _nostub ppg. Alors si quelqu'un sait où se trouve la version nostub...

Je ne sais pas ou est passé la version kernel, mais su que les sources sont fournies, tu dois pouvoir le recompiler sans trop de dificultés

Bon bah y a tjrs ce prob de "!" qui est vraiment tres con (excusez moi mais programmer une capacité sans la rendre accessible, c'est pas super neuronal...) Y a pas moyen que vous corrigiez ce bug ? ca doit pas être trop difficile...
Puis quant au niveaux de gris. C'est clair que le texte en lui même doit rester noir mais on peut immaginer un surlignage en niveaux de gris...

c'est pas con le surlignage mais je sais pas si ca va etre bien plus lisible, exemple : un unique petit caractere sur 89 (font 0) en gris foncé, j'ai du mal a croire que ce sera plus lisible ke ce meme caractere en gris foncé tout-court...

Bon bah y a tjrs ce prob de "!" qui est vraiment tres con (excusez moi mais programmer une capacité sans la rendre accessible, c'est pas super neuronal...)

Tu preferes quel caractere ?

Et alors ?

Au fait, Kevin me dit que c'est pas bien de troller dans son dos

Ben c'est là que je veux en venir. Pour les fuites mémoires,
il existe des outils de developpement pour, le resource tracking ralentit le système pour faire attention aux mauvais programmeurs.

, ou alors tu ne sais pas comment fonctionne un os moderne (post-1990). Le noyau garde de toutes façons la trace de toutes les pages allouées, ne serait-ce que pour pouvoir les swapper, gérer la mémoire partagées, les mappings dans les espaces d'adressage du processus, sans compter que le heap n'est pas le seul espace mappé, y'a aussi la pile, le code, le segment de données..... Bref dans tous les cas il garde la liste des pages allouées, et ce à un coût négligeable.
A partir de là, quand le processus se finit, il libère toutes les pages d'un bloc et hop terminé. De toutes façons il est obligé de le faire, pour récupérer l'espace alloué pour la pile du programme, et pour les données statiques.

Sur les os modernes, il est même *recommandé* de ne pas perdre du temps à libérer les ressources lorsque le programme quitte, simplement parce que là où le programme va devoir faire 15000 free(), l'os aura juste à changer 10 pointeurs dans une liste. (sans compter que free() ne rend pas réellement les ressources au système d'exploitation, donc ça sert encore plus à rien).

spectras
: Sur les os modernes, il est même *recommandé* de ne pas perdre du temps à libérer les ressources lorsque le programme quitte, simplement parce que là où le programme va devoir faire 15000 free(), l'os aura juste à changer 10 pointeurs dans une liste. (sans compter que free() ne rend pas réellement les ressources au système d'exploitation, donc ça sert encore plus à rien).

Bien d'accord.
Mais l'OS qui nous concerne sur les TI-68k (AMS évidemment, qui équipe ~100% des calculatrices) ne fait pas ça. Soit on utilise un ajout au système plutôt lourd (le "kernel" - nom mal choisi, mais on ne va pas polémiquer là-dessus - je n'utilise plus qu'"AMS native" pour me référer au mode de programmation natif - et majoritaire - du système, ça n'est pas pour rien), soit on attend que les programmes fonctionnent convenablement.
Avec la place que prend le kernel, en archive comme en RAM, il est difficile d'imaginer que le kernel puisse sur ce point-là faire gagner de la place, par rapport à des allocations/désallocations standard, quand bien même ce dernier boulot peut parfois être mal fait (vingt blocs séparés là où 1 suffit - cf PepZip, Ice Hockey 68k avant que je fasse remarquer aux auteurs que c'était mal).

PpHd : je préfere le caractère ":" . Et pendant ke t'y es, j'ai un autre prob avec Side : quand on le lance depuis un prog en basic, on ne peut le lancer qu'une fois parcequ'apres, on a une erreure "ce n'est pas un nom de programme ou de fonction". Y a moyen d'aranger ca ?

'*' te conviendrait pas mieux ? C'est plus intuitif je trouve.
Sinon pour le probleme basic, je vais voir.

./73 >

Le matos des OS récents est prévu pour la gestion des pages. Mais sur une TI un resource tracking est sale.
(^^ troll trop voyant... je mets un spoiler ?)

A l'aide :
La version de CC compressée décone trop lors de sa décompression.
Si quelqu'un dispose de la version non compressée, il faudrait vraiment qu'il me la mail...

Tu peux essayer de la recompiler en kernel ou non, avec ou sans ppg, ca devrait pas être très difficile, même si ca ne m'étonnerais pas que KK ait rajouté des truc qui compliquent le passage en kernel.

- qui compliquent
+ qui empêchent

J'espère u'il avait une bonne raison de faire ça!
C'est quoi exectement le problème? Car si c'est de mon niveau, je vais me faire un plaisir de corriger ça!

Tiens, depuis quand le fait de compresser un programme fait qu'il y a des problèmes ?
(En plus clair, je pencherais pour que le problème soit dans CC).

En encore plus clair, je ne sais pas utiliser tigcc (je débute en C)...
Donc si qqun pouvait me dire OU SE TROUVE LA VERSION NORMALE DE CC !!!!

refuser d'utiliser tigcc parceque tu débutes en C, je ne pense pas que ce soit une bonne idée

Si tu débute TIGCC sera bien plus facile a appréhender que CC.
En effet CC est un compilateur K&R qui est la plus ancienne version du C. La syntaxe est quelque peu différente de ce que tu risque de trouver sur la pluspart des indications généralement faites en C ISO(C89). Et il n'y a pas de controle des paramètres, on peut donc très facilement provoquer des bugs pas forcément evidents a détecter.

mon prob c'est que je peut pas programmer autre part que sur ma calc

ah ok là c'est une bonne raison

non, tu m'a envoyé GrayTools et Side

Nouvelle version de side par mes soins: http://www.medicis.polytechnique.fr/~pphd/preos/
J'ai un peu ameliore le systeme de compilation / execution.

question: est ce qu'il est possible de faire de la compilation séparée avec tigcc en kernel?
Car il n'a envoyé une serie d'erreur impressionante au linkage quand j'ai voulu compiler CC en kernel