Mi CPU teórica...

[jotego]

Las ventajas de hacerlo en Verilog, si lo que buscar es aprender, son (entre otras muchas):

-Los ciclos de reloj tienen sentido real
-Puedes entender las relaciones entre cada parte del procesador
-Entiendes qué sentido tienen los registros de cada tipo (puntero, PC, acumulador...) y por qué se suelen separar
-Entiendes lo que implica que el direccionamiento en una instrucción sea directo, indexado, indirecto, etc.
-Cuando lo implementas en una FPGA puedes ver la relación entre el código y los MHz alcanzados en silicio

Algunas desventajas:

-Verilog no es un lenguaje de programación. Está permitido usar operaciones de "alto" nivel, como la suma de enteros, pero el resultado en FPGA puede ser decepcionante
-Depurar código verilog, usando un simulador, es muy diferente de depurar un programa informático
-Sacar una imagen de la simulación es más complicado en Verilog que en un lenguaje de programación

Si lo que quieres es aprender, escribir en Verilog un procesador compatible con alguno de los más viejos, es un ejercicio fantástico. Mejor que diseñar tú el lenguaje porque te beneficias de todo el código que ya existe para ese procesador y porque puedes ver la lógica que hay detrás de un diseño comercial completo.

[Hark0]

Las ventajas de hacerlo en Verilog, si lo que buscar es aprender, son (entre otras muchas):

-Los ciclos de reloj tienen sentido real
-Puedes entender las relaciones entre cada parte del procesador
-Entiendes qué sentido tienen los registros de cada tipo (puntero, PC, acumulador...) y por qué se suelen separar
-Entiendes lo que implica que el direccionamiento en una instrucción sea directo, indexado, indirecto, etc.
-Cuando lo implementas en una FPGA puedes ver la relación entre el código y los MHz alcanzados en silicio

Algunas desventajas:

-Verilog no es un lenguaje de programación. Está permitido usar operaciones de "alto" nivel, como la suma de enteros, pero el resultado en FPGA puede ser decepcionante
-Depurar código verilog, usando un simulador, es muy diferente de depurar un programa informático
-Sacar una imagen de la simulación es más complicado en Verilog que en un lenguaje de programación

Si lo que quieres es aprender, escribir en Verilog un procesador compatible con alguno de los más viejos, es un ejercicio fantástico. Mejor que diseñar tú el lenguaje porque te beneficias de todo el código que ya existe para ese procesador y porque puedes ver la lógica que hay detrás de un diseño comercial completo.

Entiendo... he descargado la ISO y la estoy quemando ahora mismo... por temas de tiempo (siempre igual) no podré probarlo hasta esta noche -con suerte- o mañana...

Miraré primero la info que hay en el enlace que has colgado... ya que está en castellano...

Me da un poco de yuyu esto que dices de: Verilog no es un lenguaje de programación... etc etc pero bueno, habrá que echarle un ojo...

Gracias!

(cada día estoy más contento de que cierto usuario de este foro me recomendara ZDP )

[mentalthink]

Hombre yo no lo veo una tonteria y más usando lo que uso cada dia, de hecho como dice Jepalza y era algo que cuando empezé con GLbasic no entendia, quedandome que el Basic del CPC, y siempre que todo el mundo dice que el Basic es una mierda, pensaba que estás cosas tan complejas no se podían hacer.

Supongo que ha día de hoy como todo va a una velocidad endiablada pues no es un gran problema.

Sobre python yo lo poco que lo toco me encanta y más aún cuando se ha convertido en un Standard del 3D, como dice Jotego es un lenguaje extremadamente útil, y que se hace todo aunque creo que es más rápido a la hora de funcionar GLbasic (lo desconozco, pero según mis datos es un 3% menos que C++ puro y duro).

Sobre el Verilog, pues supongo que es como todo en está vida hecharle tiempo y ganas... a mi la FP ya se me quedó lejos y aprender algo especifico para circuitos, pues de momento no lo veo...

Por cierto gracias por ese link que has comentado, según he entendido es una Release con todo para hacer proyectos electrónicos, al igual que hay el Ubuntu Studio que es para hace Audio?¿, según he entendido...

Dale caña a eso Hark0, que aunque no entiendo ni papa del código, debe ser la mar de chulo ver un micro hay metido, lo chulo es que luego funcionará en las tropecientas cosas que compila GLBasic.

[jepalza]

Tengo GLBasic tambien (no de pago), y he probado una docena de Basic hasta que me quedé con el FB hace tiempo, y todo lo que desarrollo en Basic , lo hago con FB (He usado el VB para un cliente, por que me pidió una cosa cuyas librerías solo iban en VB, pero es un caso entre una docena).

EL emulador de A500 estoy emperrado en hacerlo (y cuando empiezo algo, puede que no lo acabe, pero queda presentable al menos). Tengo parte del núcleo del 68000, pero es gigantesco y voy lento. Espero en una o dos semanas poner algún avance en el foro, y si funciona el 68000, lo siguiente, el A500, y luego un ST, todo en Basic).

[Hark0]

Como ya se ha dicho en este foro... no seré yo el que venga a reinventar la rueda... eso sí, quiero saber cuanto más mejor... y si puedo diseñarme una máquina teórica que funcione, etc, nunca se sabe si acabaré construyendola de verdad, a fin de cuentas... ahí está la gracia... ya sabemos que está casi todo inventado... pero ¿y la satisfacción personal?

@jepalza, no he probado FB... pero lo miraré a ver qué tal...

@mentalthink, gracias!

[mcleod_ideafix]

Mis alumnos del Grado de Ingeniería Electrónica hacen precisamente como práctica de programación en C un simulador de una CPU virtual. Es una máquina RISC muy simple, pero que les sirve para aprehender muchos conceptos, como por ejemplo, que las operaciones aritméticas más usuales (suma, resta, comparación, incrementar, decrementar, negar) se pueden hacer sólamente sumando, o bien cómo funciona el tema de la decodificación de instrucciones (uso un esquema que se parece bastante a cómo se hace después en Verilog)

Parte del material del curso está publicado aquí:
http://www.atc.us.es/asignaturas/inf/in ... rgas_etron

A partir de la sección "Boletines de prácticas de programación" está la documentación y utilidades relacionadas con el Simulador.

El lunes tienen precisamente el control de esta práctica...

[mentalthink]

Gracias por la info... que has puesto McLeod.

[Manualeitor]

Está interesantísimo el hilo...

Yo he programado mucho en BASIC, mayormente QuickBASIC en su versión comercial. Pero mi lenguaje por excelencia y el que siempre defenderé a capa y espada es el C. No C++, ni el C de Microsoft, ni Borland C. Sino ANSI C. El C normalizado.

He colaborado en algún videojuego para PC hace muchos años, y de siempre he aportado mi código en C puro, o ANSI C.

Las ventajas son muy notables: Si se usa este C consigues programas multiplataforma, en el sentido de que pueden compilarse tal cual en cualquier entorno y funcionarán perfectamente sin hacer retoques o, cuando menos, muy pocos.

Además puedes programar a muy alto nivel, a muy bajo nivel, a un nivel intermedio o ir alternando. Puedes programar a objetos y a eventos, puedes emplear casi cualquier biblioteca (que no librería, eso es una mala traducción del concepto), introducir sentencias directamente en ensamblador, etc.

Es difícil de aprender (sobre todo el tema punteros, a mí personalmente fue lo que más me costó), pero como es un lenguaje estructurado es muy inteligible (si está bien escrito). Así que resulta poco traumático pasar a él a partir de un lenguaje como BASIC.

También podría añadir que los S.O. tradicionalmente se han programado en C.

Pero en fin, en mi opinión me parece fabuloso este proyecto de CPU en GlBasic, el usar un lenguaje tan sencillo hace que sea muy fácil ir siguiendo el código y viendo lo que hace. En su forma definitiva, se podría portar a otro lenguaje más potente. Pero para aprender, maravilloso. Y seguro que funciona.

Mi mayor enhorabuena y admiración para el autor. ¡Mucho ánimo y p'alante, macho!

¡Abrazos!

Manu

[jepalza]

Pero mi lenguaje por excelencia y el que siempre defenderé a capa y espada es el C. No C++, ni el C de Microsoft, ni Borland C. Sino ANSI C. El C normalizado.

Yo tambien uso el C para cosas que lo necesitan, pero no es el que uso a diarío, ese sería el FreeBasic. En C he programado el emulador de Spectrum 16k del STM32 ARM o mis viejos emuladores de la saga "Mr.Do!", por que el C++ me queda grande. De todos modos, hoy día es difícil distinguir al programar en C si es C++ o C puro. Como los compiladores se lo comen todo, si por accidente mezclas algo de C++ ni te vas a enterar (siempre que los "includes" estén ahí). Por ejemplo, el COUT o el CIN los suelo usar a veces para depurar de modo rápido, pero cuando ya funciona, lo acabo sustituyendo por PRINTF.

[Manualeitor]

Es cierto... Pero puntualizando algo: Los compiladores de C++ de hoy en día se lo comen todo... salvo excepciones.

Un compilador de C puro no se come las sentencias de C++ o yo estoy muy equivocado... Cierto es que uso GCC para todo, pero en fin... C++ se considera una extensión de ANSI C.

Mi motivo para usar C es el poder compilar mi código en cualquier plataforma. He trabajado para IBM y en esa empresa no sabes bien quien va a compilar tu código y en qué máquina, si en un PC o en un Series i5 (AS/400)...

Ejemplo:

http://en.wikipedia.org/wiki/IBM_System_i

Por cierto, sobre eso corre Linux... Estoy a la caza y captura de uno de esos que van a jubilar en una empresa de la zona. Como conozco al gerente, tengo casi todos los números para quedármelo. A ver donde lo meto...

¡Abrazos!

Manu