systeme POSIX - Page 9

Haaaa oui je suis con !

q est un char

(les parenthèses m'on perdu #honte#)

Sasume :
Super utile de faire un code portable qui ne fonctionne que sur TI-89/92+

C'était ironique. Justement, c pas portable du tout et ça risque de foirer sur 95% des OS

Et puis tu ne désalloues même pas l'espace pour la chaine.

On suppose comme dans le prog original que c'est la suite du prog qui s'en occupera. Si on suppose qu'il n'y a pas de suite, alors :
(void)0;
conviendrait parfaitement

Et il me semble qu'à la fin de l'instruction, str=0x700, non ?

Non, relis. q=(char)0x700=0, et str=0 si l'alloc foire, et "blabla" si ça ne foire pas.

Oui oui, j'ai édité
Je ne comprends pas ce que ça fait, un (void)0;

Rien du tout, justement

euh (void) 357; marche tout aussi bien non ?

Oui, mais c'est plus long à écrire (flemme powa)

encore plus simple (c un peu plus long la premiere fois mais apres c tellement plus simple n'importe ou dans le code

#define V (void)42
[...]
V;
[...]

godzil :

 ((char *str = (char *) malloc((1+strlen(txt)) * sizeof(char))==NULL)?:strcpy(str,"Tout le monde a son arbre dans ce bosquet sacré où nous mènent les rêves.");

(valide en C++, limite en C ANSI (C90) normalement fonctionne(rait?) en C99, bon sa marche pas tel quel)

Carrément pas valide, ni en C++, ni en C90, ni en C99. On ne peut pas omettre l'expression entre ? et : en C/C++ standard. Cf. http://tigcc.ticalc.org/doc/gnuexts.html#SEC71. Et la déclaration en plein milieu de l'expression n'est pas valide non plus (et aucun compilateur ne comprendra en pratique).

BSS :
Sinon je serais dans la merde pour faire un OS avec le g++ sous Windows...

Tu peux très bien faire un OS avec MinGW g++.

godzil :
pas en C99 normalement

sinon considere ça comme du C++

Ce n'est pas du C++ non plus.

godzil :
en C++

j'avais vu du code (immonde) ou le gars faisait des

for(int i=0;i<xxx;i++)
{

}
c'est assé horrible en regle général comme code

Mais complètement valide en C99 et C++. La déclaration à l'intérieur d'un for n'est pas une déclaration à l'intérieur d'une expression. Et puis je ne suis pas d'accord que c'est horrible. (Je m'en sers très souvent, c'est pour ça que beaucoup de mes programmes nécessitent -std=gnu99.)

Pollux :
Encore plus efficace, mais pas portable :
char *str = (OSSetSR(0x700), strcpy(malloc(74)?:0,"Ca c'est du code portable %)")), q=OSSetSR(0);

Attention, encore le fameux ?!. Mais bon, si tu utilises OSSetSR, autant utiliser le GNU C en même temps.

Euh... ce topic était destiné à parler d'OS Posix sur caltos alors voilà:
Bon j'ai décidé de m'y mettre, c'est principalement pour ça que j'adapte le TIB à TIGCC.
L'OS en question pourrait être bien des choses.
J'ai de grosses connaissances du noyau Linux (Bon, le connaît pas par coeur hein )
mais j'aime la famille BSD. L'OS qui naîtrait aurait certainement des caractéristiques de Linux et d'autres de BSD,
genre ça pourrait être un mélange uC-Linux et PicoBSD. J'ai déjà commencé des sources ainsi.
Mais le travail est gros et bien des choses sont inutiles, les sources de Linux sont énormes, et j'envisage également
de repartir de zéro et écrire tous les appels systèmes Posix, un travail semblable à celui de Linus Torvalds au début
(mais sur TI, pas sur 386 )

on pourrait travailler ensemble
je ne connais pas tres bien le noyau linux , mais je peut etre creatif (cela dit il ne ne faut pas esperer qq chose de ma part avant 2-3 mois: il y a les concours)
je pense a un micro-noyau , en essayant de l'optimiser pour minimiser le nombre de copies de messages entre les processus

quarktop
: je pense a un micro-noyau , en essayant de l'optimiser pour minimiser le nombre de copies de messages entre les processus

Euuuuh... les copies il y en a quand les espaces d'adressage des processus sont différents. Ce n'est pas le cas sur TI (pas de MMU), tous les processus peuvent lire tous les messages sans probleme.

... et ce à moins d'émuler (ou d'ajouter en hard) une mmu périphérique

Je n'utiliserai pas de micronoyau, ce n'est pas assez efficace pour une TI. Avec un processeur de 2 mips seulement, il faut quelquechose d'optimisé pour le hardware,
alors pas de micronoyau (p-ê un exonoyau, ce qui est proche d'un micronoyau mais plus bas niveau, mais là c'est sortir des sentiers battus, je préfère suivre
Linux)
Le plan que j'ai écrit là-haut sera fait: écriture from scratch de la plupart des appels systèmes Linux en se basant sur ce qu'il font, leurs paramètres
(M'enfin comme PedRom pour l'AMS, ou Linux pour Posix quoi...)
Ce sera un système assez unique car des accès directs au matériel peuvent être faits, comme pour un exonoyau (mais c'est dû à l'absence de MMU )
et mono-utilisateur, sans réseau, donc très loin d'Unix dans son but. Je pense que j'implémenterai le noyau tout seul, en revanche il y aura besoin de
développeurs pour les programmes simples (portages de jeux etc par recompilation simple...) ou importants (shell, driver clavier pour les modes raw et cooked etc)

snow, te décrédibilise pas en nous ressortant ton trip micro/macro/exo-kernel/noyau...

(mais c'est dû à l'absence de MMU )

tu peux toujours en émuler une ou en rapporter une extérieure

Je n'ai pas la moindre envie de gérer la mémoire, un programme invalide plantera la caltos avec un reset, et puis voilà.
Je vais me décrédibiliser pour te faire plaisir:

Ce sera un système monolithique (pas de modules surtout ) à plusieurs couches, certainement 4, comme Minix ou Linux,
donc c'est quand même pas aussi bête que MS-DOS ou CP/M, qui sont totalement monolithiques, d'un seul bloc.
Ca chercherait à faire une sorte d'encapsulation des données, mais contrairement à Linux, en l'absence de MMU rien ne sera vraiment protégé.
J'aurais besoin de développeurs pour la libc par exemple, (mais on en est pas encore là)

là au moins t'as rien dit de clairement © décridibilisant

Merci.

Pour information NeXTStep qui est clairement © un systeme basé sur un micronoyaux (mach 2.x en l'occurance) a tourné pour commencer sur du 680x0, 30 il me semble) a une vitesse moyenne de 10 a 20Mhz, bref)

Un micronoyaux sur un 68000, meme sans MMU EST réalisable, et ce, sans ralentir notablement la machine, mais ça certain sont pas capable de le comprendre a priori..

et je le répète si on a pas un mmu on peut en ajouter une ou en émuler/simuler une...

en émuler/simuler une...

Moué, ça implique une recompilation de tous les progs et de grosses grosses pertes de performances (ou alors, pas de recompilation et de grosses grosses grosses grosses pertes de performances)

oui, mais c'est le prix à payer si il veut la flexibilité des noyaux l'utilisant...

Justement, j'en ai rien à foutre. Je sais bien qu'on peut faire un micronoyau sur TI. Mais soit ça va aller lentement ou tout au moins gâcher des
performances (à cause du HAL, pas trop de spécialisation des programmes pour le hardware dans un _vrai_ micronoyau),
soit ce sera bas niveau et alors c'est en fait un codemorphing.

De plus l'intérêt principal d'un micronoyau est la sécurité qu'il offre aux processus, et là sans MMU y'aura jamais de sécurité, donc ça vaut pas
le coup si on a pas de MMU ----> et on arrive au post de Pollux ./260, l'émulation de MMU + les défauts de perf des micronoyaux ça va
donner une vitesse absolument catastrophique...

C'est comme Kevin et le C++: c'est possible sur TI mais je ne le recommende pas. (Heu, faut dire aussi que contrairement à Kevin avec
le C++, je ne déteste pas les micronoyaux...)

Ce qui vaut le plus le coup, c'est un noyau monolithique à couches. Il n'y a aucune honte à ça d'ailleurs, Unix SVR4 est monolithique...

En passant, tu manques autant d'imagination, pour passer ta vie à utiliser les avatars des autres ?

Non. Déjà c'est des images prises sur Google, donc c'est pas leurs avatars, et c'est la seule image
potable d'Haku (ou de marmotte pour la dernière fois) qu'on puisse trouver.

Enfin, j'ai redimensionné l'image moi-même donc et ²

Nil :
En passant, tu manques autant d'imagination, pour passer ta vie à utiliser les avatars des autres ?

en fait vu qu'il est complètement grillé sous son identité d'origine, il se crée des icônes qu'il idolatre au point de les singer, espérant ainsi gagner du respect

retour au sujet : billy > il en est ou ton kernel ?

il me semblait que les liens vers tigen dans yN étaient moins tolérés...

heu pourquoi ca?