HP 49G+ - Page 4

Nan, parce que l'émulation prendrait en puissance. Et les CAS sont optimisés pour une architecture précise.

et puis ça serait interessant à coder non ?

>Et les CAS sont optimisés pour une architecture précise.

Oui, mais un serait émulé, et l'autre non... si l'émulé est plus rapide que le non émulé, ça serait pas cool (mais ça métonnerai quand même, vu que pour que VTI soit à 100 % sans autre appli en arrière plan et de façon stable, il faut un P300 environ)

VTI ne doit pas être très optimisé... En plus l'ARM a plein de registres

Par contre ça pose un (gros) pb au niveau de l'écran, mais il devrait suffire de changer la taille des SCR_RECT/WIN_RECT et à la limite de reprogrammer l'écran home.

./93>

Rectification : Et les CAS sont précise.

C'est vrai qu'elle est belle

En plus, je suis ému, ils utilisent le successeur du processeur qui avait été choisi pour l'O²...

Espèrons qu'elle finira pas comme l'O²

Pauvre O², jamais sortie déjà dépassée

Miles
: En plus, je suis ému, ils utilisent le successeur du processeur qui avait été choisi pour l'O²...

Ah, vous ne vouliez pas prendre un 68040?

Pourquoi forcément un 680x0 ? Le 68040 est certainement bridé par la contrainte de backwards-compatibility...

la série 68k avait été envisagée au début, effectivement.

bah actuellement je regarde du coté des arms 9 pour l'O² mais j'attends des réponses parcque si j'ai pas moyen d'en obtenir à l'unité ça sert à rien de faire le circuit...

Ah ? tu la continues encore ?
T'en es où ?

j'en suis à : j'attends des réponses parcque si j'ai pas moyen d'en obtenir à l'unité ça sert à rien de faire le circuit...


y'a HPSB qu'est encore sur le coup, tristram, xorxar et yBr qui passent de temps à autre...

Ca y est, on sait programmer en ARM natif sur Hp49G+ :
http://groups.google.fr/groups?hl=fr&lr=&ie=UTF-8&frame=right&th=dcd37a66835709a6&seekm=4e41df23.0402191617.18470f41%40posting.google.com#link3

Il y a en fait une commande spéciale de l'émulateur permettant d'exécuter du code Arm proprement et de revenir à l'émulation Saturn.

Un programme tout bête de tracé de l'ensemble de Mandelbrot a été diffusé, sa vitesse est hallucinante



Autre évènement d'importance, le CAS de la hp49 vient de passer en LGPL. Les sources sont distribuées de manière à pouvoir recompiler facilement une Rom avec les modifications voulues.


C'est beau la vie!

Hippohmu :
C'est beau la vie!

Ahlala

(parfois)

Hippohmu :
Ca y est, on sait programmer en ARM natif sur Hp49G+ :
http://groups.google.fr/groups?hl=fr&lr=&ie=UTF-8&frame=right&th=dcd37a66835709a6&seekm=4e41df23.0402191617.18470f41%40posting.google.com#link3

Il y a en fait une commande spéciale de l'émulateur permettant d'exécuter du code Arm proprement et de revenir à l'émulation Saturn.

Un programme tout bête de tracé de l'ensemble de Mandelbrot a été diffusé, sa vitesse est hallucinante

Huhu, vous avez plus qu'à abandonner Diox

Autre évènement d'importance, le CAS de la hp49 vient de passer en LGPL. Les sources sont distribuées de manière à pouvoir recompiler facilement une Rom avec les modifications voulues.

Ouin, il y a qd même des bouts qui ne sont pas sous LGPL
En tout cas ce qui serait cool ce serait de faire un compilateur RPL système portable (j'ai l'impression qu'une bonne partie du CAS est en RPL système sans assembleur).

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

Ou en C portable, ce serait encore mieux

bref c en gpl ^^ mais sa sert a rien

Tu veux mon aide pour un HPGCC?

./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...

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

./112> Euh compiler le code RPL sys en code natif, ça m'a pas l'air trivial, par contre... (lié à l'organisation en pile et au fait qu'il y a tout plein de hacks gores liés à la profondeur de la pile qui peut varier n'importe [et qu'il n'y a pas dans le bytecode Java, même s'il utilise une pile aussi] ).

Kevin> je ne sais pas trop ce qu'il en est vis-à-vis de la redistribution, donc je ne pense pas qu'on puisse tout réutiliser (pas fous, HP )

Pollux :
./112> Euh compiler le code RPL sys en code natif, ça m'a pas l'air trivial, par contre... (lié à l'organisation en pile et au fait qu'il y a tout plein de hacks gores liés à la profondeur de la pile qui peut varier n'importe [et qu'il n'y a pas dans le bytecode Java, même s'il utilise une pile aussi] ).

Je propose de faire une toolchain C->ARM basée sur GCC, comme le fait TIGCC pour C->68k. Un frontend RPL système ne fait pas partie de ma suggestion...

Ah, OK.

Pollux :
Huhu, vous avez plus qu'à abandonner Diox

!slap Pollux
• Hippopotame slaps Pollux around a bit with a large trout !

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!)

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!

(j'ai l'impression qu'une bonne partie du CAS est en RPL système sans assembleur).

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.