Karoshi MSX Community

Hola a todos!

Aunque no participo mucho en los debates, si me conecto y husmeo en estos lugares de placer extremo. El chismorreo de temas Msxeros.
Bueno, pues vuelvo a saludar a viejos conocidos como el Archivero, Robsy, Saphire, Xenon... espero k alguien se acuerde de mi.

En fin... al tema...
estoy diseñando el PYasMsx

que no es mas que un traductor de Python que convierte el texto a lenguage de AsMsx de Robsy.

Tengo el programa aun muy verde, pero ya se pueden ver cosillas.

Aquí tengo un ejemplo de como se programaria:

#-------------------------------
#pyasm example, only testing v01
#-------------------------------
   
def screen0():
   inline
      ld hl,32
      call &H45
   
def multiplicar(a,b):
   return a*b
   
def sumar(n,m):
   return n+m

def main():   
   inline
      org &Hc000
   screen0()
   nombre=3
   bx=555
   ax=64

   if ax==bx:
      ax+=1
   
   if bx>5:
      bx-=2
      ax-=1
   
   nombre2=multiplicar(ax,bx)
   print sumar(ax,nombre)
   
   for i in range(10):
      print sumar(i,ax)

Sigo...

El tema es que me gustaria que participarais en este proyecto, 100% Open Source, aunque la ayuda sea mínima... correccion de bugs, aportación de ideas,etc.
Pido a Konamito que publique un espacito para albergar el proyecto.

Dentro de poco... tendréis mas noticias mías.

Por cierto Konamito, tienes la pàgina caida??

Buenas, Sr. msxnake, cuanto tiempo sin verle por aquí! Nos alegramos todos de tenerte de vuelta, y que sepas que no perdemos la esperanza de ver el JACK EXPLORING II terminado en breve :)

En cuanto a lo que propones, suena interesante, aunque la realidad es que nunca he hecho nada en Python, así que no voy a poder ser de mucha ayuda. Por la parte del asMSX espero que sí. Y espero que el pobre asMSX aguante la caña que le des :P

Seguiremos a la escucha ;)

Saludos, MSXnake, ¿para cuándo ese Jack Exploring II?  :D

Ese Jordi!, bienvenido de nuevo a estos lares!! ;) ;) ;) ;) . Yo también voy a preguntar por el Jack Exploring II, ya que me quedé muy preocupado con el pobre oso...  :D :D

Lo dicho, welcome back!  ;)

Volviendo al tema que nos ocupa, a ver si lo pillo, ¿se trata entonces de un "compilador" de Python a ensamblador Z80?, lo digo porque el ejemplo me confunde un poco, es evidente que no pretende ser un programa real...
Si se trata de un compilador, ¿hasta donde has pensado llegar?, no es un proyecto en absoluto sencillo; de hecho este tema se ha comentado varias veces y seguro que a más de uno le hace tilín tu proyecto y te echa una mano.
Yo por mi parte, aunque no conozco demasiado Python (¿no podrías haber escogido Perl? ;D) si que me gustaría ayudarte a probar cosillas.

¡Ánimo con el trabajito! :D

Hola. Me alegra ver este tipo de apariciones en el foro :-) (a veces uno se siente solito  :'()  ;D

Veamos, el compilador de Python lo estas haciendo desde 0 .. o estás usando algo ya existente?
Te metes en un mundo realmente cojonudo, en serio :-)
El compilador este lo pretendes hacer para poder compilar en MSX o en PC? Si es en PC lo estás montando en C/C++ o en Python?
Si es en PC .. realmente te recomiendo te pilles el SDCC y te olvides, salvo que realmente te haga mucha ilusión. Yo es que al final desistí al ver que con el SDCC me apañaba a las mil maravillas, encima con el PeepHole optimizator se pueden hacer una de guarreridas impresionantes.
Tengo varios proyectos de compiladores de C y cosas similares para generar ASM para MSX pero ya te digo .. al final .. me planteé dejarlo estar ya que el SDCC cumple mis expectativas.
Otra cosa sería que el compilador fuera para MSX o sea .. que se pudiera compilar como hacer el MSX-C de ASCII.
En ese caso, yo te ayudo en el proyecto lo que haga falta.

Jo Nerlaska, si cada vez q escribietas "SDCC" te dieran un euro estarias forrado  :D

La verdad es q es un proyecto sumamente dificil, y yo de python "0".

De todas formas todo lo q sea una ayudita para programar para msx bienvenido sea ..

Cuando tengas algo hecho te puedo ayudar con el testeo.

Un saludete

Eso, eso, Nerlaska. Deja de hacer proselitismo del SDCC!  :D

Vale que aquí siempre hemos sido profetas del MSX1 y del ensamblador, pero es que Karoshi es así. :p

Pues eso, que si Jordi quiere hacer Python, déjale que siga adelante con Python. No he visto dónde puede encajar en el trámite Python -> asMSX el SDCC  ??? Jajajaja! Pero es bueno tener alternativas, y el MONSTER HUNTER creo que ha sido la mejor tarjeta de presentación del SDCC. (aunque a mi no me convencerás, los vejetes somos tozudos)  :(

 A los que preguntan por el Jack Exploring 2...
 La tarea sigue, pero he empezado el proyecto de 0, porque al final creí que un juego no tenía nada k ver con el otro.
 Jack Exploring era eso ... Jack Exploring... un teleñeco volador que esquivaba fantasmas y peligros y ... a la vez recogía tesoros ... pantalla a pantalla.
 El Jack 2 se había convertido en un plataformas más ... reflexionando... no quiero eso
 Jack 2 tiene k ser la saga del primero, el mismo modo de juego pero con gráficos impresionantes, movimiento suave, caída con gravedad y cambios de direccion
con inercia. Pero tiempo al tiempo.

 el Pyasmsx es un cros-compiler para pc que produce codigo para ensamblador... concretamente el de robsy, el porqué de mi elección:
     No conocía python de nada pero eso que buscas por internet y das con Java y das con C++, no me acababan de gustar. Encontre documentación de Python
y me encanta el lenguaje. Es casi como el pseudocodigo. Cuando programo pienso casi en Python, además es muy visual. Y menos propenso a cometer errores que en C.
  Es un poco jodido... pero pronto tendré una Beta para vosotros.

 Me tengo que largar, al curro.
Dios.

Desde luego como sois :-)

En fin .. pues nada tío. Adelante con tu PyAsMSX ... otro lenguaje más para hacer trastadas!

Yo sigo con mi SDCC que le estoy sacando provecho. Ya tengo un sistema para generar aplicaciones SYMBOS usando SDCC como compilador .. mola mola.

SDCC al Poder!!! jejejeje

 El PyasMsx está integramente programado en Python (Cual sino) ;D

 Reflexionando mas sobre el tema de mi elección...

 Me hago llamar Msxnake---- o sea ---- m S x N A K E ---- O SEA ----  snake  ----( serpiente del msx)

 Python --- NO es sinó el lenguage de la pitón

piton == Serpiente == Snake

No podía fallar.

Bromas aparte , hay alguien que conoce el metodo para hospedar un proyecto en Souceforge.com???
Se busca rinconcito Web para el proyecto, please... :'( :'( :'( :'(

Hombre msxnake!! Cuánto tiempo!!! Me alegra verte de nuevo por aquí :)

Cuenta conmigo para lo que necesites, ya sabes que a mí todo el tema de compiladores me encanta. Te envío un privado para que puedas contactar conmigo por correo y así ir más rápido :)

Un saludo!!
--
Sph.

Aquí habrá un blog para que vayais viendo las evoluciones.

 http://pyasmsx.blogspot.com/

He llegado a las 500 lineas de código.

Viendo la complejidad de Python... creo que voy a hacer un Pseudo-Python-Msxero.

Muy interesante, quizas debiera ir yo haciendo lo mismo.

Si que lo está; pena que mi nivel de Python no me permita seguir el hilo del desarrollo de msxnake...  :(

 Bueno, Jltursan, comentarte que puedes contribuir despejando mis dudas en pseudocódigo.
 Ahora mismo tengo un dilema...

 el tema tiene que ver con la  recursividad:
 si yo creo una funcion, ejemplo:

 def sumar(a,b):
    codigo

 programa principal


 en principio mi compilador lo que realiza es una busqueda de todas las funciones definidas en el programa y guarda sus nombres. Pero se salta el paso de entrar en
cada función y traducir a assembler su contenido, lo veo totalmente ilogico, pues en el futuro pienso crear una biblioteca Msxera de gran tamaño, y claro no estaré compilando algo innecesario no?
 Pues tenemos:

 1ero - 1 trazado al programa para guardar nombres de funciones definidas  en todo el programa y librerias y variables utilizadas sólo en la zona global
 2o ---- 1 trazado que empieza a traducir todo lo que se encuentra el la zona global, o sea del ejemplo anterior lo que es el programa principal

si el programa ppal no llama a la funcion suma(a,b)... esta nunca se traducirá
por el contrario si se llama a suma... mi programa tiene que llamar otra vez a la función traducir para traducir el interior del bloque que contiene suma... si, a su vez:

def get_sumando(x):
   input(a)

def suma(a,b):
   get_sumando(a)
   get_sumando(b)
   return a+b

la función de suma llama a otra función de mi librería................ pues otra vez a llamar a la función de traducción de bloque,
y así hasta que se resuelve todo el embrollo...........pero tendré que utilizar un detector de recursividad porque si la funcion get_sumando(x) en su interior contubiera codigo que vuelve a llamar a la función suma(a,b) mi compilador entraría en un bucle indefinido y .......... cuelgue.

La verdad es que no se muy bien como deben funcionar los compiladores en este aspecto, si hay alguien que conozca el tema que me eche un cable.  :-\
    l

Caray :o

Bueno, comprendo que la situación que planteas es la lógica y bastante frecuente en intérpretes o compiladores; pero creo que no llega a darse el caso de que entres en un bucle infinito demasiadas veces. Si te entendido bien, la recursividad aparece cuando te encuentras con estas construcciones:

suma(suma(suma(a+b),c),d)

Entiendo que la forma más razonable de tratar esto es mediante niveles de pila en los que secuencialmente vas tratando los operandos de dentro a fuera (¿conoces la notación polaca inversa o el forth?), "simplificando" o resolviendo la expresión paso a paso. Las expresiones pueden ser todo lo complicadas que quieras; pero siempre limitadas por la memoria de la que dispongas, los bucles infinitos no deberían poderse dar o por lo menos no se como tal como lo veo (y si te he entendido bien ;))
En general, lo que si te puedo comentar es que en funciones recursivas siempre tiene que existir una condición que indique que se abandona la recursión, en ese momento se retorna de todas las invocaciones, nivel a nivel. Un bucle infinito representa un error en la lógica de la función.

De todas formas el que conoce mejor los temas de intérpretes y compiladores es Sapphire, seguro que el tiene algo que opinar acerca de como se parsean (¿existe ya este término en el DRAE? :)) comunmente las expresiones en un lenguaje y de que posibles fenómenos pueden aparecer; creo que la recursividad es de los más comunes (incluyendo en el lenguaje humano).

He leido el post un poco por encima, ya que a estas horas o se esta lucido o se esta atontado.

Por como yo se como funciona un compilador que no un interprete (basic):

La funcion que se define o crea se define o crea una sola vez y se almacena en una parte de memoria, si quieres hacerlo puedes incluso tener el codigo ya compilado en una libreria.

 Luego en el cuerpo del programa no hay que compilar de nuevo ese codigo solo hacer como decia jl, poner en la pila los parametros y se llama a la direccion donde se ha colocado la funcion.

Diagamos que los pasos serian:

1- Ver que hay que compilar y que no.

2- Compilar todas las funciones necesarias.

3- Compilar el programa principal.

No genera ningun problema una recursividad.

Otra cosa seria hacerlo como lo hace Pascal, guarda los aprametros de manera fija en una zona de memoria, esto invalida por completo toda recursividad.

Eso no es recursividad. La recursividad aparece cuando en el propio código de la función se hace una llamada explícita a la misma función (pero con unos argumentos que deben decrecer estrictamente en un preorden bien fundado inducido sobre el conjunto del tipo de los datos de entrada a la función... errr... que me salgo del tiesto).

Por ejemplo:


Por otro lado, es necesario que guardes, en las definiciones de funciones, todos los datos necesarios: número de parámetros y tipo de los mismos. ¿Qué tipos de datos estás considerando?

Un saludo
--
Sph.

Bueno, me refería a que si alguien malintencionadamente o por error teclea un programa de la forma:

def suma(a,b):
   return suma(a,b)

no tendría método para hallar el error de programación.

En cuanto a...


Me parece bastante interesante. Pero ya se sale de mi filosofía de trabajo. Lo estudiaré.

Y tú Saphire que opinas de esto?

Eso deberia detectartelo en la primera pasada, no puedes llamar a una funcion que aun no ha sido definida.

Error funcion desconocida.

Es que eso no es un error de compilación. La función está bien definida, pero en tiempo de ejecución llenaría completamente la pila de retorno. Es como si tecleas en BASIC:



Totalmente de acuerdo, así es como funcionan los compiladores.

Claro, tal como lo veo yo, no es un problema del compilador, si no que la solución se tiene que aportar dentro del código de suma (suponiendo que fuera una función recursiva). Como mucho el compilador podría avisar que se desbordará la pila si se usa así...no se, a ver que opinan los que entienden...

No pides tú na... pfufff... Para que un compilador pudiera decir eso, tendría que trabajar con asertos de lógica de primer orden que indicasen, en cada punto del código, las propiedades que se están cumpliendo. Después, debería operar con dichos asertos (para lo cual necesita pasar a una lógica superior, que ya sabemos que aunque correctas no son completas) para comprobar si hay un problema o no ante determinado código.

Vamos, si alguien lo consigue que me llame, que publicaríamos un artículo de investigación que revolucionaría el mundo.

Saludos
--
Sph.

Hombreee; pero no que diera la información de forma certera sino que simplemente avisara a título informativo de que ahí existe riesgo. Cada vez que se invocara una función dentro de si misma; pues "warning" al canto, luego el programador ya decidiría si hay problema o no...

Bueno, eso sí se puede hacer, sería un "Warning! recursive function detected!"

..Y ya sería mucho. En C (y supongo que en prácticamente cualquier lenguaje) vas dao si esperas que el compilador te avise de esas cosas ::)

El SDCC no se queja de nada, ni un triste warning.

El Compilador de Microsoft .. el del Visual Studio si que te lo indica :)
O sea .. mira si en todos los path de una funcion existe llamada a la misma funcion. En ese caso ... Warning.
Y lo que el SDCC no te avise .. no lo tengo tan claro .. juraría que he llegado a ver algún Warning sobre eso .. pero no estoy seguro.

Es que lo he probado y ni mu.

  Estoy de lleno en el tema del compilador/traductor, despues de meditarlo con la almuada voy a crear instrucciones igualitas al Basic...
  SCREEN
  LOCATE
  COLOR
 el porqué:
 senzillo de responder

si creará una función de tipo:
 def Screen(n1,n2):
     codigo a generar

cada vez que se llamara a la rutina se cuela un call screen, con lo cual se entorpece la rapidez de ejecución, unas sentencias transparentes debidamente cogidas de
la bios y parecidas al Basic seran muy útiles.

 Tenia esto un poco parado debido a mis vacaciones en Egipto.
 9 dias a 46 grados, un verdadero horno.
 Tras visitar Abu Simbel, Piramides, vijecito en camello, ver el tesoro de Tut ank amhon me han entrado ganas de programar otro Abu Simbel Profanation.  :D :D

Nada pues ya que te lo has pasado bien, a que esperas a programar ese Abu simbel jijijijjji

A mi me bastaría con JACK EXPLORING: EGYPTIAN ADVENTURES.  ;D

¡Oye, que buena idea!. Así el personaje de Jack Exploring empezaría a parecerse a una especie de Indiana Jones  :D