Haces obviamente tokens en las cadenas de texto para desmenuzar el código.
Apilas variables los símbolos.
Y con análisis léxico y sintáctico armas el código en código máquina.
Veo que conoces a fondo esa parte.
Había pensado en algo similar, es decir usar un procesador de texto, y que analice cadenas.
Y lo más importante, saber reconocer, cuándo se abre una llave y a cuál complementa cuándo se cierra. Y si hay funciones anidadas, saber identificarlas.
Si hoy volskwagen decidiera volver a fabricar el escarabajo, no dudes que habría uno que otro lunático en comprar ese coche tan definitivamente comparado con los de hoy.
Si decidieras vender tu kit yo sería un loco en comprarlo.
Si hoy volskwagen decidiera volver a fabricar el escarabajo, no dudes que habría uno que otro lunático en comprar ese coche tan definitivamente comparado con los de hoy.
Si decidieras vender tu kit yo sería un loco en comprarlo.
Veo que conoces a fondo esa parte.
Había pensado en algo similar, es decir usar un procesador de texto, y que analice cadenas.
Y lo más importante, saber reconocer, cuándo se abre una llave y a cuál complementa cuándo se cierra. Y si hay
Es que no es difícil
Digamos nuestro hipotético compilador vemos.
If ( a >> b )
Hacemos token
If
(
a
>>
b
)
Dónde todo el token encontramos un (
Que se abre lo apilamos y hacemos una sentencia que recuerde que hay un ( abierto.
Si encontramos cualquier cosa fuera de la sintaxis marcamos un error.
Pero dentro del (
Si encontramos una formula a + b eso ya sabemos hacerlo en código maquina.
Esperamos encontrar el )
Para afirmar que se escribió correctamente el código.
Y así para todo.
Es tedioso pero si se puede
Lo más fácil de implementar es sumas restas, igualdad. Puerto de 8 bits etc.
Al parecer parece una buena alternativa.
Una persona que ha visto éste proyecto se ofreció a hacer el compilador, sólo me dijo "pasame el set de instrucciones y algo vamos a armar"
Es increíble que personas aún hoy en día se motivan a ésta área.
Es que no es difícil
Digamos nuestro hipotético compilador vemos.
If ( a >> b )
Hacemos token
If
(
a
>>
b
)
Dónde todo el token encontramos un (
Que se abre lo apilamos y hacemos una sentencia que recuerde que hay un ( abierto.
Si encontramos cualquier cosa fuera de la sintaxis marcamos un error.
Pero dentro del (
Si encontramos una formula a + b eso ya sabemos hacerlo en código maquina.
Esperamos encontrar el )
Para afirmar que se escribió correctamente el código.
Y así para todo.
Es tedioso pero si se puede
Lo más fácil de implementar es sumas restas, igualdad. Puerto de 8 bits etc.
Mensaje automáticamente combinado:
Si lo he visto me gustaría tenerlo pero sería mejor uno hecho en el foro
Dada tu reiteración te ganaste una posición.
Lo que voy a hacer es subir un esquema de la arquitectura en 4bits, con funciones matemáticas básicas. Y con la posibilidad de manejar un puerto, ya sea de 4 u 8 bits.
Básicamente se trata de la arquitectura que armé para el sistema de 8 y 32bits.
Dónde todo el token encontramos un (
Que se abre lo apilamos y hacemos una sentencia que recuerde que hay un ( abierto.
Si encontramos cualquier cosa fuera de la sintaxis marcamos un error.
Exactamente! e incluso añadir la posibilidad de múltiples operadores en la misma sentencia.
Una vez comentaste que habías armado un sistema a base del procesador Zilog, una pena que hayas perdido ese trabajo, pero si puedes retomarlo, sería un gusto verlo funcionar.
Vaya Gudino al ver las lineas de su lenguaje assembler ya me perdi pues no se parece mucho al assembler que acostumbramos como de los microprocesadores clasicos como 6502, 8085 o del z80 jeje, esta parte de como crear un lenguaje compilador se pone interesante tambien para mi proyecto que tenia en mente tomar la sintaxis del lenguaje del arduino IDE y con alguna aplicacion convertirlo a lenguaje maquina para el z80 jeje
Respecto a lo de comercializarlo no sería para ganar dinero sino para compartir conocimientos mas bien.
No sería el primer PC de ese estilo que ha salido en los últimos años.
El problema con hacer un compilador para ese target es que primero necesitás un sistema operativo donde ejecutarlo, lo cual es toda una historia adicional para ese hardware, a menos que uses un cross-compiler....y esos ya están disponibles hace mucho tiempo y me parece que no tiene sentido gastarse en hacer uno nuevo (aunque si es por diversión, todo vale).
Por supuesto que si el hardware es compatible con una PC entonces podés usar algo como el FreeDOS....pero también ya trae todo resuelto
Así Dr., pero se puede hacer lo sig.
Escribir el código en .txt, luego con un procesador de texto creado para tal fin, compilar la sintaxis y generar un archivo .HEX compatible al hardware dónde correrá.
Mensaje automáticamente combinado:
Explicando un poco la mecánica del programa del sistema PDC32 sería así:
Supongamos que queremos sumar 2 números y enviarlos al puerto paralelo.
La sintaxis sería:
A12 0xF //Indica que los datos son asignados por el programa que está corriendo.
A1 0x00 // Reservamos el registro de Carry IN del sumador de la ALU.
A9 0x01 // Cargamos en el registro A el valor 1.
A14 0x02 // Cargamos en el registro B el valor 2.
A12 13// Vuelca el resultado del sumador en el BUS.
B7 - // El dato se transfirió del BUS al registro del puerto paralelo.
A12 0xF
A5 0x00 // El programa vuelve a la línea 0 y se repite el bucle.
Mensaje automáticamente combinado:
Cómo se puede ver una instrucción se forma siempre por una letra seguida de un número.
El byte de instrucción tiene un formato así:
DCBAXXXX, entonces por ejem si deseamos elegir la instrucción A12, entonces la posición que ocupa la letra A se coloca en 0, el resto permanece en 1 siempre!
Luego los 4bits de menor peso forman el número.
Quedaría así:
A12 es igual a 11101111.
Internamente los bits A, B, C y D, están conectados a multiplexores tipo 74LS138.
Y los datos a las líneas de dirección. A partir de ahí las salidas de cada multiplexor, ataca el CK o bien el Enable del registro al que está conectado.
Ya algo de luz se asoma con su explicacion de la codificacion pero aun asi algunas dudas asomarme como por ejemplo el acceso al bus de datos del sistema , si la CPU es de 32 bits este accede directamente a la memoria externa RAM y ROM a un bus de datos del ancho de 32 bits (4 bytes) o el acceso al bus de datos es como el 8088 que internamente maneja un bus de 16 bits pero al exterior el bus es de 8 bits y requiere completar la instruccion de 16 bits en dos ciclos maquina?
El byte de instrucción tiene un formato así:
DCBAXXXX, entonces por ejem si deseamos elegir la instrucción A12, entonces la posición que ocupa la letra A se coloca en 0, el resto permanece en 1 siempre!
Luego los 4bits de menor peso forman el número.
Quedaría así:
A12 es igual a 11101111.
la instruccion A12 seria una A de seleccion acompa;ado del 12 en decimal o hexadecimal? pero al transcribirlo al formato binario de la instruccion deberia quedar en alguna de estas formas?binario como
como seria esta instruccion desmenuzada en binario?
Gudino creo que tendra que publicarnos su tabla de OP jeje
esa es una parte que no me quedaba del todo claro con los procesadores de buses de instrucciones y datos anchos , por ejemplo si en el juego de instrucciones de un determinado microprocesador de 32 bits tuviera instrucciones implicitas de solo un byte de ancho quiere decir que este capturaria de un solo golpe 4 instrucciones de la memoria que tendria que ejecutar en secuencia una tras otra mientras otra etapa sigue capturando en su memoria cache mas instrucciones pero llegando a que justo entre las proximos 4 bytes el ultimo codigo fuera parte de una instruccion de 16 bits tendria que esperar a la proxima captura de los 4 bytes siguientes para completar con este primer byte su instruccion de 16 bits pendiente y recien poder ejecutar esa, ya me maree jeje
Bueno, ampliando un poco más es así:
El firmware está cargado en 1byte para instrucción y 16 bits de datos( Ésto lo definí así porque trabajar con 32bits de firmware requiere usar 5 memorias en paralelo.)
Volviendo, entonces se necesita de la instrucción A10, que lo que hace es cargar en el Word alto, los otros 16 bits para completar los 32 bits si es que hay que llevar datos al BUS. Pero ésto sólo es necesario cuándo hay que inyectar un dato del firmware al BUS, ya que el resto trabaja con la cantidad de bits que necesita, por ejem. La RAM, ALU, etc. Poseen 32 bits. El TIMER del sistema y el controlador de Keyboard son de 24bits.
La tarjeta VGA requiere 20bits para direccionar la RAM de vídeo y 8bits para datos.
En resumen, cada tarjeta se conecta al BUS, con la cantidad de bits que necesita para funcionar, además de las señales de control, que le dicen, éste dato entra y éste otro dato sale.
Me corrijo del mensaje anterior, sucede que cuándo volví a releerlo NO se podía editar.
La instrucción A12 equivale a 11101100 en binario y así netamente se carga en el firmware.
Sí a eso le acompañamos el argumento 15.
Quedaría en total:
A12 15 igual a 11101100 00000000 00001111.
Se pueden observar tres bytes, ya que el firmware utiliza tres memorias EEPROMs en paralelo, cómo mencioné anteriormente.
La instrucción A12 13 en binario equivale a:
11101100 00000000 1101.
Gracias por tu interés!!!
Gudino esta instruccion aun me tiene medio confusio, con la parte del programa que habia puesto habia supuesto que el codigo de operacion es un byte y lo que le sigue seria un dato pero en esa linea nos da a entender que el 13 no es un dato sino tambien parte de la instruccion que le indica al procesador a poner el resultado en el bus?
y en el caso de querer cargar un valor inmediato de 32 bits en el registro acumulador cual seria el codigo de esa accion?
Hola Amigo, A12 es una instrucción de direccionamiento.
El argumento valor 13 es un dato que le dice adónde direccionar.
Vale aclarar que A12 13, NO es una acción de operación.
Respondiendo a cómo cargar un dato en el acumulador, hacemos así.
1ro. Hay que indicar de dónde vienen los datos. En éste caso los provee el programa qué está corriendo, entonces sería:
A12 15
Luego ejecutamos A10 XX, en dónde XX es el valor alto en formato 16bits(Word) del valor a cargar en el acumulador.
Luego se ejecuta la instrucción A9 XX, en dónde XX lleva los 16bits bajos al acumulador.
Es decir, se requieren 3 ciclos de máquina para llevar un dato al acumulador.
A partir de allí quedan cargados los 32bits en el registro acumulador.
Aclarando un poco más respecto a la instrucción A12, lo que hace es conectar el BUS con un único destino.
De esa forma se evita colisión con cualquier otro dispositivo que tenga algún dato para entregar al BUS.
Buenas gente, aquí les comparto otro adelanto más al proyecto PDC32, se trata del módulo controlador de memorias seriales. Para poder utilizar cómo almacenamiento extraíble(simil Pendrive).
Realmente ésta etapa del proyecto, ha estado lleno de complicaciones de lo más insólito que puede ocurrírseles.
Empezando por ejem. que las memorias que conseguí (24C08 y 24LC512) ambas estaban dañadas. Eso lo descubrí, luego de "renegar" un buen tiempo, ya que uno se espera que el circuito es el culpable... La primer memoria, entregaba cualquier dato, es cómo si las direcciones de memoria internamente estuvieran cortocircuitadas. Y la segunda memoria directamente NO entregaba ninguna confirmación, luego de enviarle los comandos.
En fin, hubo que esperar hasta que llegaran más memorias, y probarlas fuera de la placa de forma manual, por si había algún inconveniente con el circuito.
Desde ya, muchas gracias.
A partir de aquí, estaría en condiciones de comenzar con la programación del sistema.
Pero hay un detalle, y aquí es dónde Uds. se transforman en protagonistas!
Resulta que el sistema NO tiene reloj, más precisamente reloj calendario.
Entonces el dilema sería. Utilizamos un reloj afín, cómo el DS1307 o similar?
Aunque va en contra de la ideología de utilizar sólo discretos!
Ahora bien, diseñar un reloj con lógica, aparece el problema de la autonomía.(Alimentar un puñado de circuitos 30 o 40 CMOS con pilas, sería un presupuesto mantener todo eso funcionando por períodos largos) y además voluminoso.
Recurrir a algo intermedio?
por ejem. utilizar un PIC a baja velocidad?
Alguna otra alternativa?
Escucho opiniones! Toda idea aunque parezca absurda puede resultar la más genial!
Yo conozco lo que es pelear con tecnologías antediluvianas, pero en virtud de lo que he analizado de PCs viejas (muy viejas) YO usaría un chip como el RTC de Dallas (con la pila "on-board" jajaja) y no me complicaría la vida. Sigue siendo algo arcaico pero te reduce el hardware en forma significativa.
sdcc.sourceforge.net
