Autor Tema: Compilador para cualquier SO  (Leído 4772 veces)

Desconectado octavio

  • Novato
  • *
  • Mensajes: 39
    • Ver Perfil
Compilador para cualquier SO
« Respuesta #15 en: Marzo 11, 2007, 12:24:15 pm »
Citar
Ok, Octavio, vamos tranquilos...

Los punteros estan a 0 cuando no hacen nada, o sea, siempre compruebo que no sea 0 antes de saltar.

Con respecto al teclado, es una lastima que no lo manejes de manera directa, yo ya recopile como hacerlo con las in y out, pensaba reemplazar la interrupcion de Dex con una propia para poder usarlo, si leiste y viste el codigo del ColorForth te habras dado cuenta hasta que grado de independencia del SO es posible llegar, mi idea es desactivar las interrupciones tambien.. cuando funcione todo OK

Voy a ver si hago alguna prueba con OctaOs, aunque yo tambien estoy bastante ocupado con el laburo y las clases (empiezo a ense?ar R4 la semana que viene).

Lo del directorio no te preocupes mucho, con que funcione la interaccion alcanza por ahora. Tambien tengo planes al respecto.

Gracias por tu cooperacion, me gustaria saber si viste algo de forth y si tenes alguna duda (del forth o de mi lenguaje) no dudes en preguntar.
Hace tiempo probe el colorfoth, que es como un sistema operativo y por eso usa directamente el teclado,pero no me gusto.Tambien he leido la documentaci?n sobre el r4 y entiendo mejor lo que hace el programa,pero tengo dudas sobre si es adecuado para hacer programas grandes y sobre si es al menos tan eficiente como el C.
Bueno, yo seguire usando mi Octasm y cuando este listo el port de r4 probare a ver que tal se programa,pero lo
de usar la pila como hace forth me parece algo complicado, en asm hay algo parecido cuando se programa el coprocesador matematico que tambien usa una pila en vez de registros, y es mas dificil.

pablor

  • Visitante
Compilador para cualquier SO
« Respuesta #16 en: Marzo 11, 2007, 02:50:20 pm »
si, puede ser que sea mas dificil, yo creo que mas que dificil es diferente.
se pueden hacer programas grandes ?, pues claro, que diferencia tiene un programa grande con uno chico?..
la cantidad de lineas, nada mas..
Es tan eficiente como el C ? yo creo que si.
hay algun SO que utilice los scancodes directos ?... vi el V2OS y resulta que tambien se meten con los SHIFT y CTRL..

saludos
 

Desconectado octavio

  • Novato
  • *
  • Mensajes: 39
    • Ver Perfil
Compilador para cualquier SO
« Respuesta #17 en: Marzo 11, 2007, 06:34:52 pm »
Citar
si, puede ser que sea mas dificil, yo creo que mas que dificil es diferente.
se pueden hacer programas grandes ?, pues claro, que diferencia tiene un programa grande con uno chico?..
la cantidad de lineas, nada mas..
Es tan eficiente como el C ? yo creo que si.
hay algun SO que utilice los scancodes directos ?... vi el V2OS y resulta que tambien se meten con los SHIFT y CTRL..

saludos
No conozco ningun SO. que no traduzca el teclado ,aunque quiza windows pueda emular el acceso directo al teclado para ejecutar algunos programas del DOS.
por cierto ,?la version de windows usa el teclado directamente?
Supongo que el lenguaje no es dificil una vez que uno se acostumbra.
Me parecio que no tiene instruccion 'jmp',? es correcto?
Lo de que se tenga que definir una palabra antes de usarla ?permite recursividad?
?y por que r4 no es interactivo como el colorforth?
Al desarrolar programas grandes ,hay problemas que no suelen aparecer con programas peque?os, no me refiero a que el compilador no pueda, si no a que se hace mas dificil escribir y mantener el codigo, por ejemplo el C no es adecuado para programas grandes (aunque los haya) por tener un sistema de nombres plano, lo que obliga a usar nombres mas largos para evitar repeticiones, ademas la compilacion es algo lenta, y es algo rigido en cuanto al orden en que se escribe el codigo.
Tan eficiente como el C quiza lo sea cuando el compilador optimize bien el codigo, pero de momento no lo hace.

   

pablor

  • Visitante
Compilador para cualquier SO
« Respuesta #18 en: Marzo 11, 2007, 11:18:44 pm »
Asi es. windows guarda el scancode cuango genera un evento, lo traduce pero guarda el original, linux lo transforma en otro numero pero es posible recuperarlo..
la version interpretada toma de la libreria SDL el scancode
la version compilada lo saca del evento.

FORTH no tiene instruccion jmp, el problema original es el mismo de BASIC, la orden GOTO produce codigo espagueti, forth no necesita jmp.
permite recursividad ya que cuando estas definiendo una palabra ya la podes usar y esto produce recursividad.

R4 no es interactivo porque me falta construirle un IDE, en eso estamos, pero me parece mas importante el compilador.

El dise?o de programas en FORTH cambia bastante al de otros lenguajes, el concepto aqui es CAPA, FORTH no es ni de bajo ni de alto nivel... puede ser de cualquier nivel, cada CAPA resuelve lo que la capa superior necesita, los sistemas tienden a ser grandes cuando las capas se confunden por mal dise?o, generalmente se definen menos palabra que en C por lo que el conflicto de nombres es mucho menor, en R4 implemente un sistema de exportacion o hacer publicas ciertas palabras y otras no.. esto reduce la cantidad de palabras a usar.

En Forth y R4 la compilacion es MUY veloz..puede decirse que es en tiempo real.

Es cierto, al compilador actual le faltan optimizaciones... como se ve en el codigo generado.