HP 49G+ - Page 5

Hippohmu
:

Ouin, il y a qd même des bouts qui ne sont pas sous LGPL

Le fichier distribué par Bernard Parisse contient la partie de la Rom autre que le Cas, sous forme binaire, et qui n'est pas encore libre. (nécessaire pour recompiler la rom!)

Oui, je sais. Mais il n'empêche qu'on n'a pas le droit de redistribuer le reste de la ROM, ça fait un peu tâche

En tout cas ce qui serait cool ce serait de faire un compilateur RPL système portable

Un compilateur c'est facile (c'est plutôt un tokenisateur, d'ailleurs)
Le gros morceau, c'est l'interpréteur, c'est à dire la rom Hp dans son ensemble J'ai déjà réfléchi au problème (pour la diox), et il me semble qu'implémenter un Rpl sur une autre architecture est tout à fait faisable et même facile. C'est juste long. Bien sûr, on n'a pas besoin de reprogrammer le Mo de la rom Hp, en quelques ko on a déjà un système potable. J'avais programmé un mini-RPL sur VTI, ça marchait tout à fait bien!

Le compilateur et l'interpréteur, c'est facile (juste appeler toutes les fonctions les unes à la suite des autres). Le pb étant de boucher les trous formés par les fonctions Saturn / les fonctions propriétaires...

LizDog :
et qui va s'amuser a porter le cas en GPL en natif ARM ?

Là n'est pas la question (ou alors il s'agit juste de recoder les routines critiques : multiplication d'entiers longs, par exemple). L'intérêt est de continuer le développement du Cas.
[cite]

Pollux :
Ou en C portable, ce serait encore mieux

B. Parisse a fait un logiciel de calcul formel libre pour PC, pour répondre à cette question. (xcas. Je ne sais plus si c'est du C ou du C++)

Kevin Kofler
:Tu veux mon aide pour un HPGCC?

Comme l'environnement Hp n'est pas à la base orienté C (niveau allocation et libération de la mémoire), ça va nécessiter beaucoup de réflexions préliminaires avant même d'y penser.

Mais à long terme, oui, c'est tentant! (mais je ne peux pas me lancer là dedans d'ici la fin de l'année scolaire, et je suppose que d'autres personnes plus compétentes vont s'y mettre)
[cite]

Pollux :
./111> Clair, ça n'a carrément pas fait pour être portable (cf adresses absolues, etc...) Mais avec un peu de chance ça doit être possible de réutiliser le squelette des routines d'intégration/résolution...

Ah la la, la magie Hp avec les routines importantes qui sont à la même adresse depuis des décennies, et qu'on apprend même par coeur tellement on aime les adresses absolues
03223 SWAP
03244 DROP
03188 DUP
0000F interruptions
0679B SAVPTR
02D9D DOCOL
0312B SEMI
etc.....

Kevin Kofler :
Et y a-t'il un moyen de faire tourner un émulateur Saturn sous PedroM pour faire tourner le CAS LGPL?

Un émulateur ne me paraît pas très raisonnable (le résultat serait sans doute une extrême lenteur), en revanche une implémentation du Rpl est possible sur 68k. Mais je suppose que le degré de précision à atteindre pour cette réimplémentation doit rendre le projet très rébarbatif. Sans compter les innombrables adaptations qu'il faudrait faire au Cas.

Pollux :
./112> Euh compiler le code RPL sys en code natif, ça m'a pas l'air trivial, par contre...

Ca n'est pas possible! Le Rpl est tokenisé, il n'est pas possible de le compiler efficacement en natif. (Cependant, le Rpl système est par certains côtés d'assez bas niveau et a de bonnes performances - moins que le C, bien sûr)

Kevin Kofler
: Ce n'est que le code de Bernard Parisse qui est sous LGPL (c'est quand-même fort qu'il ait réussi à convaincre HP de lui permettre ça), pas le CAS entier.

C'était dans le contrat de départ. Je crois qu'il n'a jamais fait partie de Hp, ce n'est qu'un associé et son logiciel lui appartient.

Et puis le reste de la Rom finira sans doute par échouer à Jean Yves Avenard et Cyrille de Brébisson, qui le distribueront librement.

Pollux :
Oui, je sais. Mais il n'empêche qu'on n'a pas le droit de redistribuer le reste de la ROM, ça fait un peu tâche

C'est ça ou pas de recompilation possible...
On a besoin des autres morceaux, fussent ils des binaires, pour refaire une Rom

Le compilateur , c'est facile

Oui

et l'interpréteur, c'est facile (juste appeler toutes les fonctions les unes à la suite des autres).

Non!
Ou en tout cas, si c'est facile, ce n'est sans doute pas comme tu le penses.
L'interprétation du Rpl est faite de façon subtile pour être à la fois puissante et efficace.
Je ne vais pas rentrer dans les détails, mais par exemple il n'y a *pas* de programme interpréteur. Comme l'a si bien dit Jean Michel Ferrard, "Le Rpl est un langage tokenisé qui s'auto-interprète".

Le pb étant de boucher les trous formés par les fonctions Saturn / les fonctions propriétaires...

moué...
Je ne sais pas si ça représente tellement de chose... :/

Ca n'est pas possible! Le Rpl est tokenisé, il n'est pas possible de le compiler efficacement en natif. (Cependant, le Rpl système est par certains côtés d'assez bas niveau et a de bonnes performances - moins que le C, bien sûr)

Si, complètement :

<sysrpl> DUP [0x12345] + [0x23456] 0x34567 </sysrpl>

=>

<a68k>
jsr 0x12345 [DUP]
jsr 0x23456 [+]
jsr 0x34567
</>

=>

<a68k>
move.l (a6),-(a6)

move.l (a6)+,a0
move.l (a6)+,a1
bsr do_add
move.l a0,-(a6)

jsr 0x34567
</>

=>

<a68k>
move.l (a6)+,a0
move.l a0,a1
bsr do_add
bsr internal_version_of_34567_using_a0
</>

Mais :
- jusqu'où faut-il réaliser un compromis performance/taille ?
- pour éliminer au maximum les push/pop sur la pile, il faut analyser le graphe des appels de fonctions, voir si la profondeur est constante, regarder le nb d'arguments, etc...

Hippohmu :
Je ne vais pas rentrer dans les détails, mais par exemple il n'y a *pas* de programme interpréteur. Comme l'a si bien dit Jean Michel Ferrard, "Le Rpl est un langage tokenisé qui s'auto-interprète".

Marrant ça me fait penser a un autre language qui na strictement rien a voir : le PostScript

[cite]Pollux :

Ca n'est pas possible! Le Rpl est tokenisé, il n'est pas possible de le compiler efficacement en natif. (Cependant, le Rpl système est par certains côtés d'assez bas niveau et a de bonnes performances - moins que le C, bien sûr)

Si, complètement :

[pre]<a68k> move.l (a6)+,a0 move.l a0,a1 bsr do_add bsr internal_version_of_34567_using_a0 </>[pre] Mais : - jusqu'où faut-il réaliser un compromis performance/taille ? - pour éliminer au maximum les push/pop sur la pile, il faut analyser le graphe des appels de fonctions, voir si la profondeur est constante, regarder le nb d'arguments, etc...[/cite] Tu as l'air bien partit, mais sort GTC s'il te plait avan, merci :D

Hippohmu
:

et l'interpréteur, c'est facile (juste appeler toutes les fonctions les unes à la suite des autres).

Non!
Ou en tout cas, si c'est facile, ce n'est sans doute pas comme tu le penses.
L'interprétation du Rpl est faite de façon subtile pour être à la fois puissante et efficace. Je ne vais pas rentrer dans les détails, mais par exemple il n'y a *pas* de programme interpréteur. Comme l'a si bien dit Jean Michel Ferrard, "Le Rpl est un langage tokenisé qui s'auto-interprète".

Justement, c'est ce que je dis : il n'y a *pas* d'interpréteur. (juste une boucle qui transforme les adresses en "jsr adresse") D'où la trivialité de l'interpréteur, tout le problème étant de convertir _toutes_ les fonctions, y compris les propriétaires.

LizDog
:

Pollux
:

Ca n'est pas possible! Le Rpl est tokenisé, il n'est pas possible de le compiler efficacement en natif. (Cependant, le Rpl système est par certains côtés d'assez bas niveau et a de bonnes performances - moins que le C, bien sûr)

Si, complètement :

<a68k>
move.l (a6)+,a0
move.l a0,a1
bsr do_add
bsr internal_version_of_34567_using_a0
</>

Mais :
- jusqu'où faut-il réaliser un compromis performance/taille ? - pour éliminer au maximum les push/pop sur la pile, il faut analyser le graphe des appels de fonctions, voir si la profondeur est constante, regarder le nb d'arguments, etc...

Tu as l'air bien partit, mais sort GTC s'il te plait avan, merci

Je ne pense pas sortir un truc comme ça, à moins qu'il se forme une team vraiment motivée...

Pollux :
Mais :
- jusqu'où faut-il réaliser un compromis performance/taille ? - pour éliminer au maximum les push/pop sur la pile, il faut analyser le graphe des appels de fonctions, voir si la profondeur est constante, regarder le nb d'arguments, etc...

Ton code ne va pas.
D'abord, il n'apporte rien en performance par rapport à la version tokenisée, et il fait perdre énormément en taille (alors que dans le cahier des charges originel du Rpl, on voulait un langage *compact*).

Mais surtout, ça ne peut pas être considéré comme du vrai Rpl parce que les objets ne sont pas sautables (SKIPables). (Ze principe fondamental du Rpl)

Par exemple, la séquence
"* SKIP DUP + 2 -" doit exécuter la même chose que "* + 2 -".
Avec ta méthode, tu ne peux pas implémenter une instruction SKIP correcte, qui marche dans tous les contextes.

La compilation du Rpl est amha indécidable, sauf si on a recours à une solution triviale qui ne fait que "mimer" la tokenisation.

Justement, c'est ce que je dis : il n'y a *pas* d'interpréteur. (juste une boucle qui transforme les adresses en "jsr adresse") D'où la trivialité de l'interpréteur, tout le problème étant de convertir _toutes_ les fonctions, y compris les propriétaires.

Non.
car ici tu fais tomber ZE other grand principe du Rpl, qui est que dans le programme, un objet peut être inclus de façon directe (son contenu est là) ou de façon indirecte (seul une adresse pointant vers l'objet est là), et qu'à tous les niveaux du langage, cette distinction est transparente (en particulier, SKIP traite les deux cas indifféremment).

_Bool skip_next_instruction=FALSE;
...
void add(void) {
if (skip_next_instruction) {skip_next_instruction=FALSE;return;}
...
}
...

Hippohmu
:

Pollux :
Mais :
- jusqu'où faut-il réaliser un compromis performance/taille ? - pour éliminer au maximum les push/pop sur la pile, il faut analyser le graphe des appels de fonctions, voir si la profondeur est constante, regarder le nb d'arguments, etc...

Ton code ne va pas.
D'abord, il n'apporte rien en performance par rapport à la version tokenisée, et il fait perdre énormément en taille (alors que dans le cahier des charges originel du Rpl, on voulait un langage *compact*).

Mais surtout, ça ne peut pas être considéré comme du vrai Rpl parce que les objets ne sont pas sautables (SKIPables). (Ze principe fondamental du Rpl)

Par exemple, la séquence
"* SKIP DUP + 2 -" doit exécuter la même chose que "* + 2 -". Avec ta méthode, tu ne peux pas implémenter une instruction SKIP correcte, qui marche dans tous les contextes.

On peut analyser statiquement si on a besoin ou non de SKIP, et si on en a besoin (en dehors du cas des boucles, qu'on peut traiter de manière efficace) on peut laisser du RPL système normal...

La compilation du Rpl est amha indécidable, sauf si on a recours à une solution triviale qui ne fait que "mimer" la tokenisation.

Bah non, il y a plein de cas (fonctions feuilles, notamment) où on peut largement améliorer les choses.

Justement, c'est ce que je dis : il n'y a *pas* d'interpréteur. (juste une boucle qui transforme les adresses en "jsr adresse") D'où la trivialité de l'interpréteur, tout le problème étant de convertir _toutes_ les fonctions, y compris les propriétaires.

Non.
car ici tu fais tomber ZE other grand principe du Rpl, qui est que dans le programme, un objet peut être inclus de façon directe (son contenu est là) ou de façon indirecte (seul une adresse pointant vers l'objet est là), et qu'à tous les niveaux du langage, cette distinction est transparente (en particulier, SKIP traite les deux cas indifféremment).

Comment ça, SKIP traite les deux cas indifférement ? A mon avis, SKIP => { instr=*ptr++, ptr+=inclusion_directe(instr)?*ptr:0 }, non?
Et ça se résoud statiquement aussi, comme plus haut.

Kevin>

Je te signale que ce truc est inlinable comme tout le reste, c'est même partiellement inlinable (inlining seulement du test du skip), et optimisable en rien du tout si le compilateur détermine qu'il n'y a pas de skip possible à cet endroit (ou s'il y a toujours un skip).

Oui, si tu décides de mettre le if (skip) en dehors de la fonction, alors c'est équivalent à ma solution (ptr += machin). Dans le cas contraire, tu es obligé de recopier toute la fonction... (s'il y a des regs à sauvegarder, c'est impossible)

Pollux
: On peut analyser statiquement si on a besoin ou non de SKIP, et si on en a besoin (en dehors du cas des boucles, qu'on peut traiter de manière efficace) on peut laisser du RPL système normal...

Hé non, on ne peut *pas* supposer qu'on n'aura pas besoin de Skipper! (Et soit dit en passant, dans la pratique, en rpl, ça skippe tout le temps. Toutes les structures sont faites sur cette base).

Par exemple, ta séquence DUP + 2 * est à l'intérieur d'un programme :
:: DUP + 2 * ;

Ce programme peut très bien être pris en argument par un autre programme, qui voudra le "casser" (commande INNERCOMP) comme une liste, ce qui donnera comme résultat sur la pile :
DUP
+
2
*
4

Pour celà, il faut s'assurer que les différents objets (DUP, +, 2, *) soient skippables.

Bah non, il y a plein de cas (fonctions feuilles, notamment) où on peut largement améliorer les choses.

Ben oui, c'est ce que je dis, on ne peut faire que des "améliorations" triviales (qui en fait n'améliorent rien du tout, car 1-l'interprétation est efficace 2-On perd énormément en taille 3-on a besoin de rajouter des données pour entrer et sortir du code machine)

Comment ça, SKIP traite les deux cas indifférement ?

Imaginons que tu aies dans ton programme une chaîne de caractère "Abscdwp".
Imaginons que tu aies également, en ROM (ou ailleurs que ton programme, en tout cas), une chaîne de caractère "Abscdwp", à l'adresse XXXX.

Alors les deux séquences .... "Abscdwp" .... et .... Pointeur_XXXX .... sont à tous points de vue strictement équivalentes, y compris si la chaîne se fait skipper.

A mon avis, SKIP => { instr=*ptr++, ptr+=inclusion_directe(instr)?*ptr:0 }, non?

Ya de l'idée, mais c'est plus compliqué que ça. (c)

Un Objet rpl peut avoir une structure récursive qui oblige à parcourir et examiner l'objet pour déterminer sa longueur. (par exemple des listes emboîtées).

Et ça se résoud statiquement aussi, comme plus haut.

Non...

Sachant que de toute façon, chaque programme est isomorphe à une liste, et en tant que tel, décomposable en ses éléments primitifs, et que d'autre part tout ensemble d'objets peut être réuni en un programme, la lutte est vaine... On n'échappe pas à la tokenisation.

Mais il ne faut pas en avoir peur
Tel que c'est implémenté, c'est efficace. Et il y a d'autres méthodes pour accélérer : mon prototype de Rpl-68k était amha sensiblement plus efficace que l'original, j'avais trouvé le moyen de profiter correctement du processeur.

Pollux
: Oui, si tu décides de mettre le if (skip) en dehors de la fonction, alors c'est équivalent à ma solution (ptr += machin). Dans le cas contraire, tu es obligé de recopier toute la fonction... (s'il y a des regs à sauvegarder, c'est impossible)

Sauf que ma solution marche que la fonction soit inline ou non, ce qui fait que ça fonctionne aussi pour les appels indirects.
Je pense qu'il est beaucoup plus malin de compiler SysRPL->C (voire d'utiliser un frontend GCC, mais bon courage ) que SysRPL->ASM.

Kevin Kofler :
_Bool skip_next_instruction=FALSE;
...
void add(void) {
if (skip_next_instruction) {skip_next_instruction=FALSE;return;}
...
}
...

Assembleur indispensable pour implémenter un Rpl, je le crains...

Et ton code est légèrement pas efficace, je le crains aussi

D'autre part une instruction n'est pas sautée *au moment où elle doit être exécutée*.

Par exemple, pour déterminer la longueur d'une liste, on saute ses éléments les uns après les autres jusqu'à la fin, mais ils ne sont pas exécutés.







De toute façon, si vous voulez comprendre, il faut vous ôter de l'esprit l'optimisation "à la C".

xcas est en C++, et est tres lourd au niveau memoire et ressources necessaires.