Forth / C - Page 1

et hop.

Pollux :
ben excuse-moi, mais rien que l'overhead de lecture des tokens est prohibitif par rapport au simple enchaînement d'instructions du C... en plus l'optimisation de ne peut pas "rentrer" dans les instructions : ce ne sont que des trucs opaques, alors qu'un compilo C va inliner la plupart de ce qui serait en Forth différentes fonctions...

---

mais sérieusement, je ne comprends pas comment on peut soutenir ce que tu dis ?
le Forth est un modèle de simplicité assez impressionnant, permet de faire certains trucs élégamment (même si il faut faire particulièrement gaffe à cause du peu de vérifications statiques du code), mais en tout cas je ne vois pas comment on peut affirmer qu'il est plus efficace ?

Hippopotamu
: ben excuse-moi, mais rien que l'overhead de lecture des tokens est prohibitif par rapport au simple enchaînement d'instructions du C...

Ben esxuse moi mais il a plus de genoux.
Le forth se compile, hein.

en plus l'optimisation de ne peut pas "rentrer" dans les instructions : ce ne sont que des trucs opaques, alors qu'un compilo C va inliner la plupart de ce qui serait en Forth différentes fonctions...

Et qu'est ce qui empêche un compilo forth de le faire?

Et qu'est ce qu'on en a à foutre, de toute façon? Ta vision absurdement ccentrique te cache la vraie nature des choses.

mais sérieusement, je ne comprends pas comment on peut soutenir ce que tu dis ?

normal, il faudrait que tu lises correctement ce que je dis.

Hippopotamu
:

Hippopotamu
: ben excuse-moi, mais rien que l'overhead de lecture des tokens est prohibitif par rapport au simple enchaînement d'instructions du C...

Ben esxuse moi mais il a plus de genoux. Le forth se compile, hein.

Sur HP aussi ? Parce que ct qd même ça la question initiale... Si c le cas je retire mes objections...

en plus l'optimisation de ne peut pas "rentrer" dans les instructions : ce ne sont que des trucs opaques, alors qu'un compilo C va inliner la plupart de ce qui serait en Forth différentes fonctions...

Et qu'est ce qui empêche un compilo forth de le faire?

idem

Et qu'est ce qu'on en a à foutre, de toute façon? Ta vision absurdement ccentrique te cache la vraie nature des choses.

mhû ? pour moi, si tu veux implémenter un MD5 ou un mode7, ben que tu sois C-centrique ou pas, ce que tu veux, c'est que ça marche efficacement, ctou...

Pollux
: Sur HP aussi ? Parce que ct qd même ça la question initiale... Si c le cas je retire mes objections...

Sur Hp, c'est pas du Forth, c'est du Rpl. On peut l'apparenter à la famille des forth, il y a quand même pas mal de différences fondamentales. Enfin bon, il est quand même théorisé dans l'article de W.Wickes publié dans "Programming Environments" (Institute for Applied Forth Research).

Toujours est il que le RPL n'est pas compilé (et pas compilable). Et bien sûr qu'est ce qu'on en a à foutre?

mhû ? pour moi, si tu veux implémenter un MD5 ou un mode7, ben que tu sois C-centrique ou pas, ce que tu veux, c'est que ça marche efficacement, ctou...

Ben oui.

Hippopotamu
:

Pollux
: Sur HP aussi ? Parce que ct qd même ça la question initiale... Si c le cas je retire mes objections...

Sur Hp, c'est pas du Forth, c'est du Rpl. On peut l'apparenter à la famille des forth, il y a quand même pas mal de différences fondamentales. Enfin bon, il est quand même théorisé dans l'article de W.Wickes publié dans "Programming Environments" (Institute for Applied Forth Research).

Toujours est il que le RPL n'est pas compilé (et pas compilable). Et bien sûr qu'est ce qu'on en a à foutre?

Que c'est moins efficace, au hasard ?

mhû ? pour moi, si tu veux implémenter un MD5 ou un mode7, ben que tu sois C-centrique ou pas, ce que tu veux, c'est que ça marche efficacement, ctou...

Ben oui.

Et ? Combien de ko/s fait un MD5 sur HP fait en RPL système ?

Pollux :
Que c'est moins efficace, au hasard ?

Moins efficace que quoi?
Le C sur saturn pue nettement plus que le RPL qui est beau grand fort et intelligent.

Et ? Combien de ko/s fait un MD5 sur HP fait en RPL système ?

Il n'y a pas de Md5 sur Hp, ça ne sert à rien.
En revanche il y a un calculateur de CRC *très* rapide.

Hippopotamu
:

Pollux :
Que c'est moins efficace, au hasard ?

Moins efficace que quoi? Le C sur saturn pue nettement plus que le RPL qui est beau grand fort et intelligent.

T'es gentil, en l'occurrence on parlait de l'ARM, pas du Saturn. Le C sur ARM roxx... (par contre le C sur Saturn suxxx, je suis bien d'accord)

Et ? Combien de ko/s fait un MD5 sur HP fait en RPL système ?

Il n'y a pas de Md5 sur Hp, ça ne sert à rien. En revanche il y a un calculateur de CRC *très* rapide.

En RPL système ?

Pollux
: T'es gentil, en l'occurrence on parlait de l'ARM, pas du Saturn. Le C sur ARM roxx... (par contre le C sur Saturn suxxx, je suis bien d'accord)

Evidemment.
Et sur Arm le Forth roxx...

C'est le micro pour sa soeur qui roxe, pas seulement le langage.

En RPL système ?

Non, un circuit hardware directement branché sur le bus, c'est-y pas beau la vie?

Voilà encore un exemple de réflexion de la part des ingénieurs Hp sur ce qu'est vraiment l'efficacité, et ce que sont les besoins de l'engin. Des ingénieurs Ti nous auraient fait un Md5 en C tout merdique.

Hippopotamu
:

Pollux
: T'es gentil, en l'occurrence on parlait de l'ARM, pas du Saturn. Le C sur ARM roxx... (par contre le C sur Saturn suxxx, je suis bien d'accord)

Evidemment.
Et sur Arm le Forth roxx...
C'est le micro pour sa soeur qui roxe, pas seulement le langage.

Mouarf.

En RPL système ?

Non, un circuit hardware directement branché sur le bus, c'est-y pas beau la vie?

Ca c'est vraiment de la solution Comme on a pas de langage de programmation efficace, on est obligé faire ce qui a besoin de vitesse en hardware ou en assembleur...

Voilà encore un exemple de réflexion de la part des ingénieurs Hp sur ce qu'est vraiment l'efficacité, et ce que sont les besoins de l'engin. Des ingénieurs Ti nous auraient fait un Md5 en C tout merdique.

Euh, tu penses pas qu'ils vont s'amuser à <no-troll> signer leur ROM </> avec un CRC 32 bits (ou 20 bits), qd même...


Donc bon, ton incapacité à me citer le moindre algo vaguement rapide en RPL sys montre bien que ce n'est pas un vrai langage de programmation : tout au plus est-ce un langage de "colle", mais dès qu'on passe aux choses sérieuses, soit on fait en ASM, soit on fait en hardware, soit on fait pas

Pollux
: Mouarf.

mézankor?

En RPL système ?

Comme on a pas de langage de programmation efficace, on est obligé faire ce qui a besoin de vitesse en hardware ou en assembleur...

Mais pourquoi il se prend le choux avec son Md5 de mes deux alors que c'est typiquement le truc complètement inutile sur une calc?
Ce polluqse est vraiment un être incompréhensible.

Euh, tu penses pas qu'ils vont s'amuser à <no-troll> signer leur ROM </> avec un CRC 32 bits (ou 20 bits), qd même...

Signer une rom? Qu'est ce que ça veut dire c't'affaire?
Mais bordel on s'en bat les couilles, quand est ce qu'il va comprendre ça?

Donc bon, ton incapacité à me citer le moindre algo vaguement rapide en RPL sys montre bien que ce n'est pas un vrai langage de programmation : tout au plus est-ce un langage de "colle", mais dès qu'on passe aux choses sérieuses, soit on fait en ASM, soit on fait en hardware, soit on fait pas

Ah ben voilà au moins une réflexion intéressante, sous des aspects trollesques.
Bien sûr, rectifions immédiatement : le rpl est bien plus qu'un langage de glu, mais il a entre autres cette fonction (c'est aussi un langage "de shell").

Mais bon, soyons sérieux deux minutes, c'est aussi le langage dans lequel est écrit par exemple le Cas (ou une foultitude d'autres applications de la rom), avec des performances meilleures que son analogue sur ti.

Et au passage, c'est précisément un langage de ce genre qui est ultrapratique sur une calc et qui manque horriblement sur ti. Parce que le basic / ligne de commande, c'est méchamment plus limité que le rpl et sa pile.

Hippopotamu
:

Pollux
: Mouarf.

mézankor?

Le C est bien plus efficace, surtout sur un truc pas trop exotique genre ARM... (sur Saturn les tailles "non-standard " auraient rendu les choses bien plus difficiles, par exemple un pointeur ou un entier ne pourrait pas faire 2.5 octets [à moins de prendre ça comme taille de base, mais alors les chaînes de caractères seraient gigantesques] )

En RPL système ?

Comme on a pas de langage de programmation efficace, on est obligé faire ce qui a besoin de vitesse en hardware ou en assembleur...

Mais pourquoi il se prend le choux avec son Md5 de mes deux alors que c'est typiquement le truc complètement inutile sur une calc?

C'est un exemple de bench simple qui donne une indication des capacités de la calc. On peut prendre des trucs plus utiles, comme :
- compression de fichiers
- algos graphiques : moteur 3d, moteur 2d, moteur mode 7
- calcul des décimales de Pi (ah non merde c inutile)
- etc...

Ce polluqse est vraiment un être incompréhensible.

Euh, tu penses pas qu'ils vont s'amuser à <no-troll> signer leur ROM </> avec un CRC 32 bits (ou 20 bits), qd même...

Signer une rom? Qu'est ce que ça veut dire c't'affaire? Mais bordel on s'en bat les couilles, quand est ce qu'il va comprendre ça?

Si vous lisez ce texte, c'est que votre navigateur ne supporte pas la balise <no-troll>. Veuillez le mettre à jour.

Donc bon, ton incapacité à me citer le moindre algo vaguement rapide en RPL sys montre bien que ce n'est pas un vrai langage de programmation : tout au plus est-ce un langage de "colle", mais dès qu'on passe aux choses sérieuses, soit on fait en ASM, soit on fait en hardware, soit on fait pas

Ah ben voilà au moins une réflexion intéressante, sous des aspects trollesques. Bien sûr, rectifions immédiatement : le rpl est bien plus qu'un langage de glu, mais il a entre autres cette fonction (c'est aussi un langage "de shell").

Mais un langage de glu, ça ne suffit pas s'il n'y a rien à coller...

Mais bon, soyons sérieux deux minutes, c'est aussi le langage dans lequel est écrit par exemple le Cas (ou une foultitude d'autres applications de la rom), avec des performances meilleures que son analogue sur ti.

En même tps je pense qu'avant que les ingénieurs de TI aient compris le principe du RPN, les HPs auront des écrans couleur 1280x1024... Vu comme ils ont du mal à programmer en C, je pense pas que le résultat aurait été meilleur en RPL. C'est avant tout une question d'algo, et ceux de TI sont probablement très inférieurs. (un algo en O(n^2) en C ne risque pas d'être meilleur qu'un algo en O(n) en RPL, c'est certain )

Bref, effectivement on peut faire des choses en RPL sys. Mais en tout cas si on fait la même chose en RPL sys et en C, la version C doit être un certain nb de fois plus rapide que son équivalent RPL... Je pense par exemple aux jeux, où les algos sont relativement simples, et où les facteurs multiplicatifs constants ne peuvent pas être ignorés.

Hippopotamu
: Et au passage, c'est précisément un langage de ce genre qui est ultrapratique sur une calc et qui manque horriblement sur ti. Parce que le basic / ligne de commande, c'est méchamment plus limité que le rpl et sa pile.

Le basic n'a pas de débugger, et ça manque... Et c'est aussi vrai que la pile doit être assez pratique pour manipuler des expressions. En revanche tu ne nieras pas que le RPN est très très casse-gueule.

Pollux
: Le C est bien plus efficace, surtout sur un truc pas trop exotique genre ARM...

Mais non, mon ami, mais non. Tu déraisonnes.

(sur Saturn les tailles "non-standard " auraient rendu les choses bien plus difficiles, par exemple un pointeur ou un entier ne pourrait pas faire 2.5 octets [à moins de prendre ça comme taille de base, mais alors les chaînes de caractères seraient gigantesques] )

Il faudrait éplucher la norme du C (#tricouic#, à mort le C!), mais je suis sûr que tu te trompes, et qu'il est possible de prendre des tailles correspondant aux registres du prc :
A = 5 quartets = int = pointeur
B = 2 quartets = caractère
W = 16 quartets = long.

Si vous lisez ce texte, c'est que votre navigateur ne supporte pas la balise <no-troll>. Veuillez le mettre à jour.

Je fais du bugware.

Mais un langage de glu, ça ne suffit pas s'il n'y a rien à coller...

Tout à fait!
Fort heureusement le Rpl n'est pas qu'un langage de glu.

En même tps je pense qu'avant que les ingénieurs de TI aient compris le principe du RPN, les HPs auront des écrans couleur 1280x1024... Vu comme ils ont du mal à programmer en C, je pense pas que le résultat aurait été meilleur en RPL. C'est avant tout une question d'algo, et ceux de TI sont probablement très inférieurs. (un algo en O(n^2) en C ne risque pas d'être meilleur qu'un algo en O(n) en RPL, c'est certain )

Mais mon cher ami, le Cas des Ti, ce n'est pas n'importe quoi, comme tu sembles le penser. C'est une mouture de Derive, si je ne m'abuse (me corriger...), c'est le boulot de Soft warehouse, et ce n'est pas sa seule implémentation. Ce n'est peut être pas le meilleur cas du monde, mais les algos sont quand même un minimum chiadés.
Le Cas hp, lui, est le produit un peu bidouillesque d'un seul programmeur. Il est certainement fort bien conçu, mais il ne faut pas croire qu'il est tellement ultimement supérieur à Derive.

Non, vraiment, le Cas est bien un exemple des bonnes possibilités du Rpl.

Bref, effectivement on peut faire des choses en RPL sys. Mais en tout cas si on fait la même chose en RPL sys et en C, la version C doit être un certain nb de fois plus rapide que son équivalent RPL...

C'est certainement vrai. (encore que là aussi il faut relativiser et comparer les performances des deux Cas.)
Mais le programme C sera aussi bien plus gros et pas du tout intégré dans le système, et au final on y aura sans doute perdu.

Je pense par exemple aux jeux, où les algos sont relativement simples, et où les facteurs multiplicatifs constants ne peuvent pas être ignorés.

crayon.
Ah, si j'avais le temps de faire ce compilateur forth....

Pollux
: Le basic n'a pas de débugger, et ça manque... Et c'est aussi vrai que la pile doit être assez pratique pour manipuler des expressions.

Tout ça n'est qu'un toute petite partie des possibilités....

En revanche tu ne nieras pas que le RPN est très très casse-gueule.

Je le nierai.

Hippopotamu
:

Pollux
: Le C est bien plus efficace, surtout sur un truc pas trop exotique genre ARM...

Mais non, mon ami, mais non. Tu déraisonnes.

erf...

(sur Saturn les tailles "non-standard " auraient rendu les choses bien plus difficiles, par exemple un pointeur ou un entier ne pourrait pas faire 2.5 octets [à moins de prendre ça comme taille de base, mais alors les chaînes de caractères seraient gigantesques] )

Il faudrait éplucher la norme du C (#tricouic#, à mort le C!), mais je suis sûr que tu te trompes, et qu'il est possible de prendre des tailles correspondant aux registres du prc :
A = 5 quartets = int = pointeur
B = 2 quartets = caractère W = 16 quartets = long.

Non, je suis sûr que j'ai raison, jeune padawan D'abord, on prend le char. Il doit impérativement pouvoir stocker 255 valeurs, donc 2 quartets minimum. Ensuite, le short. Il doit faire au moins 4 quartets, _et il doit avoir une taille multiple de celle de char_ ! (puisque sizeof(char)==1, et que sizeof(x) est un entier) Donc 4, 6 ou plus quartets, mais pour avoir 5 quartets, il faudrait un char de 5 quartets aussi.

Si vous lisez ce texte, c'est que votre navigateur ne supporte pas la balise <no-troll>. Veuillez le mettre à jour.

Je fais du bugware.

Moué, ça te réussit pas...

Mais un langage de glu, ça ne suffit pas s'il n'y a rien à coller...

Tout à fait! Fort heureusement le Rpl n'est pas qu'un langage de glu.

... mais presque...

En même tps je pense qu'avant que les ingénieurs de TI aient compris le principe du RPN, les HPs auront des écrans couleur 1280x1024... Vu comme ils ont du mal à programmer en C, je pense pas que le résultat aurait été meilleur en RPL. C'est avant tout une question d'algo, et ceux de TI sont probablement très inférieurs. (un algo en O(n^2) en C ne risque pas d'être meilleur qu'un algo en O(n) en RPL, c'est certain )

Mais mon cher ami, le Cas des Ti, ce n'est pas n'importe quoi, comme tu sembles le penser. C'est une mouture de Derive, si je ne m'abuse (me corriger...), c'est le boulot de Soft warehouse, et ce n'est pas sa seule implémentation. Ce n'est peut être pas le meilleur cas du monde, mais les algos sont quand même un minimum chiadés.
Le Cas hp, lui, est le produit un peu bidouillesque d'un seul programmeur. Il est certainement fort bien conçu, mais il ne faut pas croire qu'il est tellement ultimement supérieur à Derive.
Non, vraiment, le Cas est bien un exemple des bonnes possibilités du Rpl.

Vu la taille d'un interpréteur SysRPL et la taille d'un CAS, je pense que si Derive était ultimement bien conçu et si le SysRPL était ultime pour faire un CAS, Derive serait en SysRPL... Cherchez l'erreur
(moui, bon, semi-troll ^^)

Bref, effectivement on peut faire des choses en RPL sys. Mais en tout cas si on fait la même chose en RPL sys et en C, la version C doit être un certain nb de fois plus rapide que son équivalent RPL...

C'est certainement vrai. (encore que là aussi il faut relativiser et comparer les performances des deux Cas.) Mais le programme C sera aussi bien plus gros et pas du tout intégré dans le système, et au final on y aura sans doute perdu.

Si le Basic s'interface mal avec le C, c'est que les dév de chez TI s'y sont pris avec les pieds. J'avais pour intention de permettre d'interfacer très facilement du C avec GT-Basic, et ce n'est pas difficile.

Je pense par exemple aux jeux, où les algos sont relativement simples, et où les facteurs multiplicatifs constants ne peuvent pas être ignorés.

crayon.
Ah, si j'avais le temps de faire ce compilateur forth....

Ok, donc alors avoue tout de même que le fait que je déplore l'absence de HPGCC n'est pas infondé...

Hippopotamu
:

Pollux
: Le basic n'a pas de débugger, et ça manque... Et c'est aussi vrai que la pile doit être assez pratique pour manipuler des expressions.

Tout ça n'est qu'un toute petite partie des possibilités....

Est-ce que tu édites vraiment tes progs RPL en les manipulant sur la pile ? (chose qu'il n'est de toute façon pas possible de faire avec simplement la ROM)

En revanche tu ne nieras pas que le RPN est très très casse-gueule.

Je le nierai.

Ouin ^^ Je suis qd même convaincu qu'il faut une bonne dose d'habitude pour ne pas s'emmêler les pinceaux dans les niveaux de la pile, et j'aurais tendance à dire que c'est assez write-only : si par la suite tu veux supprimer une variable de la pile qui ne te sers plus, tous tes offsets hard-codés sur la pile ne marchent plus... Mais il y a peut-être dans les "vrais" trucs de dev en RPN (i.e. pas le truc de RPL non-sys intégré à la ROM) des moyens de mettre un label sur un certain niveau de la pile, pour que le code soit plus maintenable ?

Pollux
: erf...

Mézankor?
Bon, je me répète :
- Le C, évidemment, ce n'est que de l'assembleur déguisé de manière fourbe. Donc c'est efficace. Forcément.
- Mais d'un autre côté, je t'assure que du Forth peut aussi être *réellement* efficace. (parce qu'en fait, le forth c'est *aussi* de l'assembleur déguisé de manière fourbe. Typiquement, une instruction forth = une instruction assembleur).

Non, je suis sûr que j'ai raison, jeune padawan D'abord, on prend le char. Il doit impérativement pouvoir stocker 255 valeurs, donc 2 quartets minimum. Ensuite, le short. Il doit faire au moins 4 quartets, _et il doit avoir une taille multiple de celle de char_ ! (puisque sizeof(char)==1, et que sizeof(x) est un entier) Donc 4, 6 ou plus quartets, mais pour avoir 5 quartets, il faudrait un char de 5 quartets aussi.

sizeof ne donne qu'un majorant de la taille d'un type me semble t il, c'est important précisément quand un type n'a pas une taille multiple de unsigned char.
Le int est fait pour être adapté à la machine et la norme le laisse très libre. Il peut faire 5 quartets.

... mais presque...

... mais non ...

Vu la taille d'un interpréteur SysRPL et la taille d'un CAS, je pense que si Derive était ultimement bien conçu et si le SysRPL était ultime pour faire un CAS, Derive serait en SysRPL... Cherchez l'erreur

Il n'y a pas d'erreur, un Cas ultimement bien conçu est en RPL

Si le Basic s'interface mal avec le C, c'est que les dév de chez TI s'y sont pris avec les pieds.

C'est bien plus profond que ça.

J'avais pour intention de permettre d'interfacer très facilement du C avec GT-Basic, et ce n'est pas difficile.

C'est très bien mais je doute que tu puisses atteindre le niveau d'intégration d'une hp.

Ok, donc alors avoue tout de même que le fait que je déplore l'absence de HPGCC n'est pas infondé...

Ah non, un HPGCC n'a que très peu d'intérêt. Tu as tort d'en déplorer l'absence pour deux raisons :
- ça existe déjà.
- c'est inintéressant au possible.

En revanche on peut regretter l'absence d'un "vrai" forth compilé, en dessous du rpl, et bien interfacé avec lui.

Est-ce que tu édites vraiment tes progs RPL en les manipulant sur la pile ? (chose qu'il n'est de toute façon pas possible de faire avec simplement la ROM)

La pile, c'est *tout*.
Toutes les applications diverses et variées, genre "filer", ou gros systèmes de menus, sont peu utiles sauf dans des cas vraiment particuliers. La pile et son éditeur forment le lieu le plus pratique pour travailler.

Ouin ^^ Je suis qd même convaincu qu'il faut une bonne dose d'habitude pour ne pas s'emmêler les pinceaux dans les niveaux de la pile, et j'aurais tendance à dire que c'est assez write-only : si par la suite tu veux supprimer une variable de la pile qui ne te sers plus, tous tes offsets hard-codés sur la pile ne marchent plus...

Moui enfin le langage est quand même beaucoup plus riche que ça. Si on a 150 variables, on ne va pas les laisser sur la pile et s'amuser à gérer les n° de pile, ça serait casse burne. Le langage fournit :
- des variables locales.
- *deux* piles avec des moyens utiles de passer de l'une à l'autre. (la deuxième est la pile des adresses de retours, mais elle ne sert pas qu'à ça.)
- des variables de boucles
- sur la hp49, l'api VirtualStack, qui fait des choses de la mort qui tue (gestion d'une pile de piles, dont "la" pile n'est que le premier niveau)
- et bien des choses encore.

Le programmeur fou(c) peut s'amuser à tout faire "sèchement" sur la pile, c'est d'ailleurs une chose amusante et efficace, mais il y a bien des outils pour faire du code plus civilisé.

Hippopotamu
:

Pollux
: erf...

Mézankor?
Bon, je me répète : - Le C, évidemment, ce n'est que de l'assembleur déguisé de manière fourbe. Donc c'est efficace. Forcément.

Il faut qd même préciser que le C permet une certaine flexibilité (chgt des structures de données, des types des variables), tout en générant du code relativement optimisé.

- Mais d'un autre côté, je t'assure que du Forth peut aussi être *réellement* efficace. (parce qu'en fait, le forth c'est *aussi* de l'assembleur déguisé de manière fourbe. Typiquement, une instruction forth = une instruction assembleur).

Euh, non, il faut pas déconner. D'ailleurs une preuve que le Forth ne peut pas être aussi optimisé, c'est que "1 +" ne sera pas aussi efficace que "1+". En C, si le compilo se démerde bien, il inlinera la fonction add et fera les optimisations qu'il faut.

Non, je suis sûr que j'ai raison, jeune padawan D'abord, on prend le char. Il doit impérativement pouvoir stocker 255 valeurs, donc 2 quartets minimum. Ensuite, le short. Il doit faire au moins 4 quartets, _et il doit avoir une taille multiple de celle de char_ ! (puisque sizeof(char)==1, et que sizeof(x) est un entier) Donc 4, 6 ou plus quartets, mais pour avoir 5 quartets, il faudrait un char de 5 quartets aussi.

sizeof ne donne qu'un majorant de la taille d'un type me semble t il, c'est important précisément quand un type n'a pas une taille multiple de unsigned char. Le int est précisément fait pour être adapté à la machine et la norme le laisse très libre. Il peut faire 5 quartets.

Il peut faire 5 quartets en interne si ça lui chante, mais alors il faut qu'il y ait du padding pour arriver à un multiple de 2 quartets (par exemple 6 quartets). Donc non.

... mais presque...

... mais non ...

... mais si ...

Vu la taille d'un interpréteur SysRPL et la taille d'un CAS, je pense que si Derive était ultimement bien conçu et si le SysRPL était ultime pour faire un CAS, Derive serait en SysRPL... Cherchez l'erreur

Il n'y a pas d'erreur, un Cas ultimement bien conçu est en RPL

Il y a au moins une erreur dans les 2 hypothèses, ce qui prouve que si "un Cas ultimement bien conçu est en RPL", alors Derive n'est pas ultimement bien conçu, et donc tes critiques du C fondées sur Derive ne sont plus valables

Si le Basic s'interface mal avec le C, c'est que les dév de chez TI s'y sont pris avec les pieds.

C'est bien plus profond que ça.

J'exagère, c'est vrai que le C ne permet pas de faire de la manipulation d'expressions de manière aussi concise que le RPL (encore que, en C++ on devrait arriver à qqch de plutôt utilisable : mais ça n'existait pas au moment où Derive a été commencé)
Mais bon, en tout cas je trouve ça rigolo que dans le topic sur Caml vous soyez tt le tps en train de me dire "boaf, c'est juste un peu de sucre syntaxique, ça ne change rien", et que dans ce topic-là, ça soit exactement le contraire

J'avais pour intention de permettre d'interfacer très facilement du C avec GT-Basic, et ce n'est pas difficile.

C'est très bien mais je doute que tu puisses atteindre le niveau d'intégration d'une hp.

Oui, en fait je visais plutôt l'intégration des types "orienté programmation", pas "orienté CAS"... Mais elle aurait été bien faite

Ok, donc alors avoue tout de même que le fait que je déplore l'absence de HPGCC n'est pas infondé...

Ah non, un HPGCC n'a que très peu d'intérêt. Tu as tort d'en déplorer l'absence pour deux raisons :
- ça existe déjà. - c'est inintéressant au possible.

i.e. ? Si je veux faire un Doom sur HP et que j'ai pas envie/pas le tps d'apprendre l'asm ARM, c'est qd même le choix le plus raisonnable de le faire en C...

En revanche on peut regretter l'absence d'un "vrai" forth compilé, en dessous du rpl, et bien interfacé avec lui.

Aussi. Mais c'est orthogonal.

Est-ce que tu édites vraiment tes progs RPL en les manipulant sur la pile ? (chose qu'il n'est de toute façon pas possible de faire avec simplement la ROM)

La pile, c'est *tout*. Toutes les applications diverses et variées, genre "filer", ou gros systèmes de menus, sont globalement peu utiles sauf dans des cas vraiment particuliers. La pile et son éditeur est le lieu le plus pratique pour travailler.

Absolument, mais ma question n'était pas sur le fait qu'on puisse balancer un objet "programme" sur la pile, mais sur le fait qu'un objet "programme" n'est pas complètement opaque et qu'on peut donc le manipuler (le découper, etc...)

Ouin ^^ Je suis qd même convaincu qu'il faut une bonne dose d'habitude pour ne pas s'emmêler les pinceaux dans les niveaux de la pile, et j'aurais tendance à dire que c'est assez write-only : si par la suite tu veux supprimer une variable de la pile qui ne te sers plus, tous tes offsets hard-codés sur la pile ne marchent plus...

Moui enfin le langage est quand même beaucoup plus riche que ça. Si on a 150 variables, on ne va pas les laisser sur la pile et s'amuser à gérer les n° de pile, ça serait casse burne. Le langage fournit : - des variables locales.

Oui, j'ai fait du RPL dans ma jeunesse ^^

- *deux* piles avec des moyens utiles de passer de l'une à l'autre. (la deuxième est la pile des adresses de retours, mais elle ne sert pas qu'à ça.)

Ah ok c pas spécifique au Forth. Mais c uniquement en RPL sys ?

- des variables de boucles

yop

- sur la hp49, l'api VirtualStack, qui fait des choses de la mort qui tue (gestion d'une pile de piles, dont "la" pile n'est que le premier niveau)

ça fonctionne comment en détail ? #curieux#

- et bien des choses encore.
Le programmeur fou(c) peut s'amuser à tout faire "sèchement" sur la pile, c'est d'ailleurs une chose amusante et efficace, mais il y a bien des outils pour faire du code plus civilisé.

moui... mais mon expérience était que dès que tu commence à éclater des listes sur la pile ça devient vite le bordel... et l'absence de "structures" (au sens C) est aussi un gros manque, s'il n'y en a pas en RPL sys

Pollux
: Il faut qd même préciser que le C permet une certaine flexibilité (chgt des structures de données, des types des variables), tout en générant du code relativement optimisé.

Oui bien sûr. C'est bien l'intérêt : faire de l'assembleur sans les défauts de l'assembleur.

Euh, non, il faut pas déconner. D'ailleurs une preuve que le Forth ne peut pas être aussi optimisé, c'est que "1 +" ne sera pas aussi efficace que "1+".

Ben si.

En C, si le compilo se démerde bien, il inlinera la fonction add et fera les optimisations qu'il faut.

Idem.

Il peut faire 5 quartets en interne si ça lui chante, mais alors il faut qu'il y ait du padding pour arriver à un multiple de 2 quartets (par exemple 6 quartets). Donc non.

Donc non mais si.
Il utilisera bel et bien les bons registres du Cpu.
Et le quartet perdu donnera un avantage pour un inconvénient : le programme sera plus rapide avec des données alignées. (sur saturn les cycles sont différents en adresse paire et impaire)

... mais presque...

... mais non ...

... mais si ...

Ménon
(qu'est ce que la vertu?)

Il y a au moins une erreur dans les 2 hypothèses, ce qui prouve que si "un Cas ultimement bien conçu est en RPL", alors Derive n'est pas ultimement bien conçu, et donc tes critiques du C fondées sur Derive ne sont plus valables

Alors tu as mal lu.
Ai je dis que derive était ultimement bien conçu? Ce n'est clairement ((c)) pas le cas.

(encore que, en C++ on devrait arriver à qqch de plutôt utilisable : mais ça n'existait pas au moment où Derive a été commencé)

Eueeeerkkkk.....
(pardonner cette brusque crise de nausée)

Mais bon, en tout cas je trouve ça rigolo que dans le topic sur Caml vous soyez tt le tps en train de me dire "boaf, c'est juste un peu de sucre syntaxique, ça ne change rien", et que dans ce topic-là, ça soit exactement le contraire

Mu?
C'est pas une histoire de syntaxe....

En revanche on peut regretter l'absence d'un "vrai" forth compilé, en dessous du rpl, et bien interfacé avec lui.

Aussi. Mais c'est orthogonal.

Non, c'est plus fondamental.

Absolument, mais ma question n'était pas sur le fait qu'on puisse balancer un objet "programme" sur la pile, mais sur le fait qu'un objet "programme" n'est pas complètement opaque et qu'on peut donc le manipuler (le découper, etc...)

Un "programme" est tokénisé, et détokenisable à volonté. On peut "éclater" les programmes comme on veut (et je ne m'en prive pas, ça m'arrive souvent de faire de l'ingénierie de cette façon). Mais on se sert bien sûr plutôt de la ligne de commande

- des variables locales.

Oui, j'ai fait du RPL dans ma jeunesse ^^

Si tu n'as fait que du user RPL, alors tu ne sais *pas* la puissance et les possibilités des variables locales
(en user rpl elles sont fortement bridées pour satisfaire les impératifs de propritude. Encore que la mouture hp49 du user rpl, dans les dernières rom, donne des possibilités supérieures.)

- *deux* piles avec des moyens utiles de passer de l'une à l'autre. (la deuxième est la pile des adresses de retours, mais elle ne sert pas qu'à ça.)

Ah ok c pas spécifique au Forth. Mais c uniquement en RPL sys ?

Quand on fait du user rpl, on fait en fait du sys rpl. La pile des retours est bien là. Simplement elle est transparente, on ne sait pas qu'elle existe et on n'a pas de commande pour y accéder.

- sur la hp49, l'api VirtualStack, qui fait des choses de la mort qui tue (gestion d'une pile de piles, dont "la" pile n'est que le premier niveau)

ça fonctionne comment en détail ? #curieux#

Ben "la" pile de données du rpl est en fait le premier niveau d'une pile de piles.
On a des commandes pour faire passer la pile courante au niveau deux, et créer au niveau un une nouvelle pile vierge ou garder une copie de l'ancienne, on a des commandes diverses de meta-manipulation de piles.

Le but est de répondre à des problèmes de ce genre :

- "les applications récursives et conviviales" : imaginons que j'aille dans le menu PLOT pour tracer une courbe, et qu'au moment d'entrer l'équation, j'ai un doute et il me prend l'envie de la recalculer. J'appuie alors sur HALT, et je me retrouve sur la pile. L'application "Menu PLOT" est toujours présente, mais suspendue. Elle reprendra quand j'emploirai la commande CONT.
Bien sûr, une fois sur la pile, je peux lancer une autre application du même genre, et refaire un HALT. On peut donc avoir une infinité d'application HALTées imbriquées les unes dans les autres. Ces applications doivent conserver leurs données si possible sans laisser traîner des saletés sur la pile, puisque l'utilisateur s'en sert. La solution est que chaque application se crée sa propre pile privée en empilant l'ancienne.
(en fait ce n'est pas la vraie vraie raison, qui serait un peu difficile à expliquer, mais bon c'est l'idée)

- gérer des grosses collections d'objets sur la pile, par exemple des expressions algébriques "cassées" et étalées sur la pile. Bon je ne vais pas entrer dans les détails mais il me semble que le Cas en fait pas mal usage.

L'Api est beaucoup plus rapide et élégante que les solutions batardes consistant à encapsuler toute la pile dans une liste, ou bien dans un bloc de variables locales.

Néanmoins elle est peu utilisée pour les programmes de tous les jours, c'est surtout pour de grosses applications, notamment en rom. Ca peut quand même être un outil très puissant si on y pense.

( http://www.hpcalc.org/details.php?id=2992 )

moui... mais mon expérience était que dès que tu commence à éclater des listes sur la pile ça devient vite le bordel...

Au contraire, ça peut être très pratique si tu gères correctement les blocs (je ne sais pas si tu as fait du sys ou du user rpl ?)
Un bloc de longueur k, sur la pile, c'est un entier k avec au dessus de lui k objets. On a des commandes pour faire des meta-operations sur les blocs : metaswap, metadup, fusions, etc...

et l'absence de "structures" (au sens C) est aussi un gros manque, s'il n'y en a pas en RPL sys

c'est juste !
Mais rien ne s'y oppose dans la théorie.
J'ai moi même créé des types d'objets artificiels, et rien ne s'oppose à ce que le langage puisse créer sur le volet des structures nouvelles.... sinon que le rpl est un peu ancien et qu'il lui faudrait une petite modernisation!

Hippopotamu
:

Euh, non, il faut pas déconner. D'ailleurs une preuve que le Forth ne peut pas être aussi optimisé, c'est que "1 +" ne sera pas aussi efficace que "1+".

Ben si.

Argl, j'ai oublié de préciser "Forth interprété" (qui est bien ce dont il s'agit dans la comparaison).

En C, si le compilo se démerde bien, il inlinera la fonction add et fera les optimisations qu'il faut.

Idem.

Idem.

Il peut faire 5 quartets en interne si ça lui chante, mais alors il faut qu'il y ait du padding pour arriver à un multiple de 2 quartets (par exemple 6 quartets). Donc non.

Donc non mais si. Il utilisera bel et bien les bons registres du Cpu.

Moué, bof... En tout cas on perd toute compatibilité avec les adresses contiguës telles que stockées par la ROM.

Et le quartet perdu donnera un avantage pour un inconvénient : le programme sera plus rapide avec des données alignées. (sur saturn les cycles sont différents en adresse paire et impaire)

Il n'y a pas d'instruction "écrire en incrémentant le pointeur" ? (me souviiens plus trop...)

... mais presque...

... mais non ...

... mais si ...

Ménon (qu'est ce que la vertu?)

May Sea...
(qu'est-ce que la mer ce mois-ci?)

Il y a au moins une erreur dans les 2 hypothèses, ce qui prouve que si "un Cas ultimement bien conçu est en RPL", alors Derive n'est pas ultimement bien conçu, et donc tes critiques du C fondées sur Derive ne sont plus valables

Alors tu as mal lu. Ai je dis que derive était ultimement bien conçu? Ce n'est clairement ((c)) pas le cas.

Alors tu n'as pas lu le spoiler du message d'avant

(encore que, en C++ on devrait arriver à qqch de plutôt utilisable : mais ça n'existait pas au moment où Derive a été commencé)

Eueeeerkkkk..... (pardonner cette brusque crise de nausée)

C++ pawa

Mais bon, en tout cas je trouve ça rigolo que dans le topic sur Caml vous soyez tt le tps en train de me dire "boaf, c'est juste un peu de sucre syntaxique, ça ne change rien", et que dans ce topic-là, ça soit exactement le contraire

Mu? C'est pas une histoire de syntaxe....

Evidemment, c'est légèrement plus compliqué que ça, mais c'est l'idée... (encore que, p-ê que ça peut se faire un Forth purement en C++ )

En revanche on peut regretter l'absence d'un "vrai" forth compilé, en dessous du rpl, et bien interfacé avec lui.

Aussi. Mais c'est orthogonal.

Non, c'est plus fondamental.

C'est différent.
Bref, c'est orthogonal

Absolument, mais ma question n'était pas sur le fait qu'on puisse balancer un objet "programme" sur la pile, mais sur le fait qu'un objet "programme" n'est pas complètement opaque et qu'on peut donc le manipuler (le découper, etc...)

Un "programme" est tokénisé, et détokenisable à volonté. On peut "éclater" les programmes comme on veut (et je ne m'en prive pas, ça m'arrive souvent de faire de l'ingénierie de cette façon).

Quel est l'intérêt ? (à part que l'éditeur de texte intégré est mal foutu)

- des variables locales.

Oui, j'ai fait du RPL dans ma jeunesse ^^

Si tu n'as fait que du user RPL, alors tu ne sais *pas* la puissance et les possibilités des variables locales (en user rpl elles sont fortement bridées pour satisfaire les impératifs de propritude. Encore que la mouture hp49 du user rpl, dans les dernières rom, donne des possibilités supérieures.)

J'ai fait un soupçon de SysRPL, mais trois fois rien (j'avais juste accès à la liste des Internal, et il fallait que j'assemble moi-même )

- *deux* piles avec des moyens utiles de passer de l'une à l'autre. (la deuxième est la pile des adresses de retours, mais elle ne sert pas qu'à ça.)

Ah ok c pas spécifique au Forth. Mais c uniquement en RPL sys ?

Quand on fait du user rpl, on fait en fait du sys rpl. La pile des retours est bien là. Simplement elle est transparente, on ne sait pas qu'elle existe et on n'a pas de commande pour y accéder.

Oué oué, je me doute bien qu'elle est qd même utilisée... (structures de contrôle)

- sur la hp49, l'api VirtualStack, qui fait des choses de la mort qui tue (gestion d'une pile de piles, dont "la" pile n'est que le premier niveau)

ça fonctionne comment en détail ? #curieux#

< ... >

OK Ca a l'air pas mal

moui... mais mon expérience était que dès que tu commence à éclater des listes sur la pile ça devient vite le bordel...

Au contraire, ça peut être très pratique si tu gères correctement les blocs (je ne sais pas si tu as fait du sys ou du user rpl ?)

Plutôt du user.

Un bloc de longueur k, sur la pile, c'est un entier k avec au dessus de lui k objets. On a des commandes pour faire des meta-operations sur les blocs : metaswap, metadup, fusions, etc...

Pas en UserRPL sur 48G...

et l'absence de "structures" (au sens C) est aussi un gros manque, s'il n'y en a pas en RPL sys

c'est juste !
Mais rien ne s'y oppose dans la théorie. J'ai moi même créé des types d'objets artificiels, et rien ne s'oppose à ce que le langage puisse créer sur le volet des structures nouvelles.... sinon que le rpl est un peu ancien et qu'il lui faudrait une petite modernisation!

"à la volée" != "sur le volet"
Mais c'est encore une raison pour adopter le C, qui lui est carrément fait pour... (dans les situations où le C est adapté, évidemment)

Pollux
: Argl, j'ai oublié de préciser "Forth interprété" (qui est bien ce dont il s'agit dans la comparaison).

Ce n'est même pas interprété...

Il utilisera bel et bien les bons registres du Cpu.

Moué, bof... En tout cas on perd toute compatibilité avec les adresses contiguës telles que stockées par la ROM.

Pas sûr.

Il n'y a pas d'instruction "écrire en incrémentant le pointeur" ? (me souviiens plus trop...)

Non.

Alors tu n'as pas lu le spoiler du message d'avant

May sea.

C++ pawa

Allons bon vlà aut chose.

Evidemment, c'est légèrement plus compliqué que ça, mais c'est l'idée... (encore que, p-ê que ça peut se faire un Forth purement en C++ )

#tripastop#
Du C++ en Forth ça serait plus vraisemblable...

C'est différent.
Bref, c'est orthogonal

Tout ce qui est différent n'est pas orthogonal.

Quel est l'intérêt ?

L'intérêt est évident puisqu'on s'en sert pas mal.

(à part que l'éditeur de texte intégré est mal foutu)

L'éditeur de texte est au contraire excellemment bien foutu.

J'ai fait un soupçon de SysRPL, mais trois fois rien (j'avais juste accès à la liste des Internal, et il fallait que j'assemble moi-même )

Que du bonheur
J'espère que tu en as profité comme tout le monde pour apprendre par coeur les adresses les plus courantes!
Petit quizz :
03223 ?
03244 ?
0679B ?
02D9D ?

Un bloc de longueur k, sur la pile, c'est un entier k avec au dessus de lui k objets. On a des commandes pour faire des meta-operations sur les blocs : metaswap, metadup, fusions, etc...

Pas en UserRPL sur 48G...

Non certes. Mais le user rpl est tellement plus pauvre...
(Jean Michel Ferrard a je crois implanté ces fonctions en user rpl)

"à la volée" != "sur le volet"

/s/sur le/à la

Mais c'est encore une raison pour adopter le C, qui lui est carrément fait pour... (dans les situations où le C est adapté, évidemment)

Ce n'est pas une raison, puisque ça n'est pas utile.
Si tu savais comme on s'en passe...

Hippopotamu
:

Pollux
: Argl, j'ai oublié de préciser "Forth interprété" (qui est bien ce dont il s'agit dans la comparaison).

Ce n'est même pas interprété...

Non optimisé, si tu préfères.

Il utilisera bel et bien les bons registres du Cpu.

Moué, bof... En tout cas on perd toute compatibilité avec les adresses contiguës telles que stockées par la ROM.

Pas sûr.

Mhû ? Il faudra subdiviser la mémoire en zones où on ne peut accéder qu'aux données commençant à une adresse paire et en zones où on ne peut accéder qu'à partir d'une adresse impaire, et je ne crois pas qu'elles aient le droit de se recouvrir... (et même dans ce cas-là ce serait très lourd)

Alors tu n'as pas lu le spoiler du message d'avant

May sea.

J'avais bien compris que tu l'avais lu (tu l'as même supprimé), ça voulait dire que tu n'en avais pas tenu compte...

C++ pawa

Allons bon vlà aut chose.

Meuh si Ca poutre ^^

Evidemment, c'est légèrement plus compliqué que ça, mais c'est l'idée... (encore que, p-ê que ça peut se faire un Forth purement en C++ )

#tripastop# Du C++ en Forth ça serait plus vraisemblable...

Ouarf Je pense qu'écrire un parser C++ en Forth (bah oui, je vois difficilement comment ça pourrait être autre chose qu'un parser) n'est pas plus simple qu'un parser C++ en C++.

C'est différent.
Bref, c'est orthogonal

Tout ce qui est différent n'est pas orthogonal.

Et ?

Quel est l'intérêt ?

L'intérêt est évident puisqu'on s'en sert pas mal.

Oui mais on explication marche aussi : l'intérêt est évident parce que l'éditeur intégré est pourri, mais il le serait moins avec un bon éditeur

(à part que l'éditeur de texte intégré est mal foutu)

L'éditeur de texte est au contraire excellemment bien foutu.

Sur HP48, en tout cas, il était nul : pas de sélection (copier-coller ), pas de fonction recherche, pas de fonction remplacer, pas de moyen pour se déplacer rapidement (par exemple dans la structure du prog RPL), rame qd on défile...

J'ai fait un soupçon de SysRPL, mais trois fois rien (j'avais juste accès à la liste des Internal, et il fallait que j'assemble moi-même )

Que du bonheur
J'espère que tu en as profité comme tout le monde pour apprendre par coeur les adresses les plus courantes!
Petit quizz :
03223 ?
03244 ?
0679B ? 02D9D ?

Argl, j'ai tout oublié
Me semble que 3223 = SWAP (et encore, pas sûr) et que 15781 = aller dans le répertoire caché, mais ctou...

Un bloc de longueur k, sur la pile, c'est un entier k avec au dessus de lui k objets. On a des commandes pour faire des meta-operations sur les blocs : metaswap, metadup, fusions, etc...

Pas en UserRPL sur 48G...

Non certes. Mais le user rpl est tellement plus pauvre... (Jean Michel Ferrard a je crois implanté ces fonctions en user rpl)

"à la volée" != "sur le volet"

/s/sur le/à la

Mais c'est encore une raison pour adopter le C, qui lui est carrément fait pour... (dans les situations où le C est adapté, évidemment)

Ce n'est pas une raison, puisque ça n'est pas utile.
Si tu savais comme on s'en passe...

Ben t'es obligé de faire de l'ASM, sinon... Et je ne vois pas très bien l'intérêt de défendre férocement le Forth si c'est pour après soutenir l'ASM contre le C

Et puis tu ne nieras pas que si je veux faire une lib de calcul par exemple sur des très gros polynômes dans Z/2Z [X], ce sera bien plus efficace en C qu'en Forth

Pollux
: Non optimisé, si tu préfères.

Ca ne veut rien dire.

Tu es empli de choses qui ne veulent rien dire.

Mhû ? Il faudra subdiviser la mémoire en zones où on ne peut accéder qu'aux données commençant à une adresse paire et en zones où on ne peut accéder qu'à partir d'une adresse impaire, et je ne crois pas qu'elles aient le droit de se recouvrir... (et même dans ce cas-là ce serait très lourd)

Oui, tu as peut être raison. Vraiment de la merde, le C.

J'avais bien compris que tu l'avais lu (tu l'as même supprimé), ça voulait dire que tu n'en avais pas tenu compte...

C++ pawa

Allons bon vlà aut chose.

Meuh si Ca poutre ^^

A première vue, le C++ est un langage de merde.

A deuxième vue, cette impression est confirmée.

Ouarf Je pense qu'écrire un parser C++ en Forth (bah oui, je vois difficilement comment ça pourrait être autre chose qu'un parser) n'est pas plus simple qu'un parser C++ en C++.

De toute façon il faut être un suppôt de satan, un psychopathe dégénéré ou un raëlien pour vouloir faire une chose pareille.

Et ?

Oh !

Oui mais on explication marche aussi : l'intérêt est évident parce que l'éditeur intégré est pourri, mais il le serait moins avec un bon éditeur

L'éditeur intégré est splendiose et excellordinaire.

De même que la preuve du pudding, c'est de le manger, la preuve que c'est intéressant, c'est qu'on s'en sert.

Sur HP48, en tout cas, il était nul : pas de sélection (copier-coller ), pas de fonction recherche, pas de fonction remplacer, pas de moyen pour se déplacer rapidement (par exemple dans la structure du prog RPL), rame qd on défile...

Hp48 is Hp48.
Hp49 is Hp49.

Aujourd'hui, on appelle par le terme "hp48" une hp48 muni du metakernel.
Tu as 10 ans de retard dans ta vision des choses.

Argl, j'ai tout oublié Me semble que 3223 = SWAP (et encore, pas sûr)

Tout à fait.

et que 15781 = aller dans le répertoire caché, mais ctou...

Oui, mais le plus important, c'est #15777 qui pose sur la pile le nom vide.

Et je ne vois pas très bien l'intérêt de défendre férocement le Forth si c'est pour après soutenir l'ASM contre le C

Je vois bien que tu ne vois pas.

Je m'en désole mais je n'y peux rien.

Hippopotamu
:

Pollux
: Non optimisé, si tu préfères.

Ca ne veut rien dire.

Si. Ca veut dire que le truc écrit par l'utilisateur est exécuté verbatim, sans analyse du code dépendant de son contexte (couramment appelée "optimisation").

Tu es empli de choses qui ne veulent rien dire.

Mhû ? Il faudra subdiviser la mémoire en zones où on ne peut accéder qu'aux données commençant à une adresse paire et en zones où on ne peut accéder qu'à partir d'une adresse impaire, et je ne crois pas qu'elles aient le droit de se recouvrir... (et même dans ce cas-là ce serait très lourd)

Oui, tu as peut être raison. Vraiment de la merde, le C.

Non, c'est juste que ce n'est pas fait pour être portable sur les processeurs martiens. Tout simplement parce que la portabilité à 100% ne peut pas exister, et que même si c'était le cas le programmeur lambda aurait vite fait de faire des suppositions un peu trop hasardeuses sur la nature du processeur... Et à vrai dire, c'est parfaitement possible d'être portable à 100% : on *peut* faire du C sur Saturn. Ce sera juste moins efficace que de l'ASM ; mais c'est aussi le cas du Forth, non ? (dans un tout autre registre, évidemment)

C++ pawa

Allons bon vlà aut chose.

Meuh si Ca poutre ^^

A première vue, le C++ est un langage de merde.
A deuxième vue, cette impression est confirmée.

error: line 3: unargumented reply

Ouarf Je pense qu'écrire un parser C++ en Forth (bah oui, je vois difficilement comment ça pourrait être autre chose qu'un parser) n'est pas plus simple qu'un parser C++ en C++.

De toute façon il faut être un suppôt de satan, un psychopathe dégénéré ou un raëlien pour vouloir faire une chose pareille.

J'hésite entre les 2 premiers choix

Et ?

Oh !

Ha !

Oui mais on explication marche aussi : l'intérêt est évident parce que l'éditeur intégré est pourri, mais il le serait moins avec un bon éditeur

L'éditeur intégré est splendiose et excellordinaire.

Ah, bien alors.

De même que la preuve du pudding, c'est de le manger, la preuve que c'est intéressant, c'est qu'on s'en sert.

Dois-je te rappeler que le C, on s'en sert ? Et surtout sur des systèmes embarqués.

Sur HP48, en tout cas, il était nul : pas de sélection (copier-coller ), pas de fonction recherche, pas de fonction remplacer, pas de moyen pour se déplacer rapidement (par exemple dans la structure du prog RPL), rame qd on défile...

Hp48 is Hp48.
Hp49 is Hp49.

Aujourd'hui, on appelle par le terme "hp48" une hp48 muni du metakernel. Tu as 10 ans de retard dans ta vision des choses.

Bon, d'accord. Mais qu'est-ce que la manipulation de progs par la pile apporte qui ne peut pas être fait aussi efficacement que par l'éditeur ?

Argl, j'ai tout oublié Me semble que 3223 = SWAP (et encore, pas sûr)

Tout à fait.

et que 15781 = aller dans le répertoire caché, mais ctou...

Oui, mais le plus important, c'est #15777 qui pose sur la pile le nom vide.

Pawa

Et je ne vois pas très bien l'intérêt de défendre férocement le Forth si c'est pour après soutenir l'ASM contre le C

Je vois bien que tu ne vois pas.
Je m'en désole mais je n'y peux rien.

Bon, tu m'expliques comment tu l'écris, ton Doom 3 ?

Pollux
: Si. Ca veut dire que le truc écrit par l'utilisateur est exécuté verbatim, sans analyse du code dépendant de son contexte (couramment appelée "optimisation").

Et ben on s'en fout.

Non, c'est juste que ce n'est pas fait pour être portable sur les processeurs martiens.

De la m***e.

même si c'était le cas le programmeur lambda aurait vite fait de faire des suppositions un peu trop hasardeuses sur la nature du processeur...

Ca ce sont les habitudes du C.

error: line 3: unargumented reply

L'argument c'est l'évidence.

Dois-je te rappeler que le C, on s'en sert ? Et surtout sur des systèmes embarqués.

Hu hu. Non, le C ne sert pas *surtout* dans les systèmes embarqués.

Et dois je te rappeler que le Forth sert beaucoup dans les systèmes embarqués?
(Tiens, j'ai appris ya pas longtemps que la navette spatiale américaine est codée en forth )

Bon, d'accord. Mais qu'est-ce que la manipulation de progs par la pile apporte qui ne peut pas être fait aussi efficacement que par l'éditeur ?

Que veux tu que je te dise? Il faut juste le faire..

Bon, tu m'expliques comment tu l'écris, ton Doom 3 ?

Demande à HpFool..

Hippopotamu
:

Pollux
: Si. Ca veut dire que le truc écrit par l'utilisateur est exécuté verbatim, sans analyse du code dépendant de son contexte (couramment appelée "optimisation").

Et ben on s'en fout.

Oui, le prog est juste 5x plus lent. A part ça, rien de grave.

Non, c'est juste que ce n'est pas fait pour être portable sur les processeurs martiens.

De la m***e.

troll spotted

même si c'était le cas le programmeur lambda aurait vite fait de faire des suppositions un peu trop hasardeuses sur la nature du processeur...

Ca ce sont les habitudes du C.

troll spotted^2

error: line 3: unargumented reply

L'argument c'est l'évidence.

troll spotted^3

Dois-je te rappeler que le C, on s'en sert ? Et surtout sur des systèmes embarqués.

Hu hu. Non, le C ne sert pas *surtout* dans les systèmes embarqués.

troll spotted^4
Le C sert partout, donc oui pas seulement dans les sys embarqués. Mais parmi les sys embarqués, le C est très utilisé (surtout s'ils ont été conçus assez récemment).

Et dois je te rappeler que le Forth sert beaucoup dans les systèmes embarqués?
(Tiens, j'ai appris ya pas longtemps que la navette spatiale américaine est codée en forth )

<troll> Oué mais c parce que la moitié du code a été conçue y a 30 ans </>

Bon, d'accord. Mais qu'est-ce que la manipulation de progs par la pile apporte qui ne peut pas être fait aussi efficacement que par l'éditeur ?

Que veux tu que je te dise? Il faut juste le faire..

Moué, pas vraiment convaincant

Bon, tu m'expliques comment tu l'écris, ton Doom 3 ?

Demande à HpFool..

Pas en RPL, en tout cas.

Pollux
: Oui, le prog est juste 5x plus lent. A part ça, rien de grave.

Port nawak.

troll spotted
troll spotted^2
troll spotted^3
troll spotted^4 <troll> </>

so what?

« Dans tout troll, il y a une part de vérité. » ^(c)

En outre je suis in-forum.

(surtout s'ils ont été conçus assez récemment).

ben oui, moins ça ressemble à un système embarqué...

Moué, pas vraiment convaincant

Qu'y puis je?
Je m'addresse à un mur qui ne veut rien comprendre.

Hippopotamu
:

Pollux
: Oui, le prog est juste 5x plus lent. A part ça, rien de grave.

Port nawak.

arguments ?

troll spotted
troll spotted^2
troll spotted^3
troll spotted^4 <troll> </>

so what?

hmmmmmmmmmmm....

« Dans tout troll, il y a une part de vérité. » ^(c)

"test"

En outre je suis in-forum.

re-test

(surtout s'ils ont été conçus assez récemment).

ben oui, moins ça ressemble à un système embarqué...

ben oui, moins on s'embarrasse avec des langages ad-hoc et plus on a des langages standard, plus on peut approfondir les optimisations... Le RPL en est un excellent exemple : langage créé à partir de zéro pour l'occasion, donc efficacité relativement pitoyable, aucune optimisation inter-procédurale (ou inter-tokens, si tu préfères)...
(légèrement in-forum)

Moué, pas vraiment convaincant

Qu'y puis je? Je m'addresse à un mur qui ne veut rien comprendre.

Vraiment, on aurait pas dû continuer la discussion sur ce forum... Ca te donne trop envie de balancer des gros trolls velus

Pollux
: arguments ?

La pratique.

hmmmmmmmmmmm....

Ôhmmmmmmm

"test"

<naheulbeuk> Il dit qu'il t'emmerde </>

langage créé à partir de zéro pour l'occasion,

Pitoyablement faux.

donc efficacité relativement pitoyable,

Efficacité excellente, pourquoi à ton avis les calculatrices hp ont toujours été de meilleure qualité que leurs homologues Ti?