Nuevo proyecto CoCo "C" CoCo/Dragon/CP400

Avatar de Usuario
luiscoco
Mensajes: 2328
Registrado: 15 May 2011 04:23
Ubicación: Caracas, Venezuela
Agradecido : 30 veces
Agradecimiento recibido: 44 veces
Contactar:

Nuevo proyecto CoCo "C" CoCo/Dragon/CP400

Mensajepor luiscoco » 16 Ago 2017 18:30

Abro este hilo con la aportación de parte de Pser de un c para 6809 windows
viewtopic.php?f=18&t=200033266&start=16#p200085096
acabo de encontrar esto en Sourceforge
https://sourceforge.net/projects/cmoc-win32/
Es una 'adaptación' del compilador de C para 6809 de Pierre Sarrazin para entornos Window$
Tal vez pueda dar alguna idea ...
saludos
pere


Un detalle, no tiene LONG
The most significant difference between CMOC and a complete C compiler is the absence of longs and of the const keyword.


Ya empezamos, necesita:
It requires the LWTOOLS assembler (lwasm), by William Astle.


Algo bueno trae un IDE, Para empezar está muy bien

Un C en las Rom de la coco seria otra cosa muy buena

Imagen
Imagen

Avatar de Usuario
luiscoco
Mensajes: 2328
Registrado: 15 May 2011 04:23
Ubicación: Caracas, Venezuela
Agradecido : 30 veces
Agradecimiento recibido: 44 veces
Contactar:

Re: Nuevo proyecto CoCo "C" CoCo/Dragon/DP400

Mensajepor luiscoco » 16 Ago 2017 18:54

Funciona muy bien
Compilador C Coco.jpg
Compilador C Coco.jpg (74 KiB) Visto 195 veces

Avatar de Usuario
pser1
Mensajes: 2013
Registrado: 08 Dic 2012 18:34
Agradecido : 198 veces
Agradecimiento recibido: 181 veces

Re: Nuevo proyecto CoCo "C" CoCo/Dragon/CP400

Mensajepor pser1 » 16 Ago 2017 19:01

luiscoco escribió:Funciona muy bien
Compilador C Coco.png
Compilador C Coco.jpg
No se ven como imágenes, sino como descargas, ¿porque sera?

Me parece que el motivo es que don demasiado grandes, pantalla completa a resoluciones actuales
no los puede mostrar 'abiertos'. Si los editas con cualquier programa de dibujo (irfanView, Paint) y reduces
la definición verás como los muestra 'abiertos'
saludos
pere

Avatar de Usuario
luiscoco
Mensajes: 2328
Registrado: 15 May 2011 04:23
Ubicación: Caracas, Venezuela
Agradecido : 30 veces
Agradecimiento recibido: 44 veces
Contactar:

Re: Nuevo proyecto CoCo "C" CoCo/Dragon/DP400

Mensajepor luiscoco » 16 Ago 2017 19:07

Ok gracias
y con respecto a esto
pser1 escribió:Ya se va pareciendo a un lenguaje orientado a clases ... Solo hace falta que cambiemos main por el nombre de la clase!
Entiendo que aquí no habrá parámetros, ¿Verdad? porque si hay que pasarlos junto con el nombre
de la función lo haríamos con paréntesis habitualmente, pero entonces hay que 'inventar' un símbolo
para inicio y final de función.
Pero si NO vas a utilizar el editor en un CoCo/Dragon real sinó que trabajaremos en un PC/Mac/Linux,
podríamos aceptar la llave {} como se hace en otros lenguajes ... pero no sé si se quiere que se pueda
utilizar en un 6809
saludos
pere

Ciertamente desde PC es mucho más cómodo, aunque tenía la idea de hacer algo que les quedara a las máquinas, no se si es ilusión, pero por ahora esto que has encontrado me parece magnífico.

Ciertamente la función principal (MAIN o el nombre de la clase) en coco no tendría parámetros ya que el DOS no los acepta, como podrías correr un BIN con parámetros, pero ya veremos.

Por ahora voy a revisar las librerías que trae este proyecto que encontraste

Avatar de Usuario
luiscoco
Mensajes: 2328
Registrado: 15 May 2011 04:23
Ubicación: Caracas, Venezuela
Agradecido : 30 veces
Agradecimiento recibido: 44 veces
Contactar:

Re: Nuevo proyecto CoCo "C" CoCo/Dragon/DP400

Mensajepor luiscoco » 16 Ago 2017 19:10

pser1 escribió:Me parece que el motivo es que don demasiado grandes, pantalla completa a resoluciones actuales
no los puede mostrar 'abiertos'. Si los editas con cualquier programa de dibujo (irfanView, Paint) y reduces
la definición verás como los muestra 'abiertos'
saludos
pere

Listo era exactamente eso, gracias

jltursan
Mensajes: 1876
Registrado: 20 Sep 2011 13:59
Agradecido : 47 veces
Agradecimiento recibido: 141 veces

Re: Nuevo proyecto CoCo "C" CoCo/Dragon/DP400

Mensajepor jltursan » 16 Ago 2017 19:18

Yo también estoy de acuerdo con pser1 acerca de que este es el camino a seguir. El C no es complicado, el resultado es compilado y si las librerías son las adecuadas, los resultados pueden ser muy buenos. Como ya digo, con unas buenas librerías, con un API que abstraiga en lo posible el hardware, la ventaja del C supondría el poder generar con relativa sencillez conversiones del mismo programa a las diferentes máquinas simplemente enlazando las librerías correspondientes.

A ver si le echo un vistazo que también me intriga que librerías lleva :-)

Avatar de Usuario
luiscoco
Mensajes: 2328
Registrado: 15 May 2011 04:23
Ubicación: Caracas, Venezuela
Agradecido : 30 veces
Agradecimiento recibido: 44 veces
Contactar:

Re: Nuevo proyecto CoCo "C" CoCo/Dragon/DP400

Mensajepor luiscoco » 16 Ago 2017 19:24

Este programa está avanzadisimo, prácticamente se puede hacer un juego ya en C para coco
Esto es la reostia, jajaja, Pser ponte en contacto con el Frances Pierre Sarrazin, que le ayudamos a hacer librerias, según nos diga, y avisale a Simon, a ver si quiere ayudar.

Y como dice jltursan
jltursan escribió:Yo también estoy de acuerdo con pser1 acerca de que este es el camino a seguir. El C no es complicado, el resultado es compilado y si las librerías son las adecuadas, los resultados pueden ser muy buenos. Como ya digo, con unas buenas librerías, con un API que abstraiga en lo posible el hardware, la ventaja del C supondría el poder generar con relativa sencillez conversiones del mismo programa a las diferentes máquinas simplemente enlazando las librerías correspondientes.

A ver si le echo un vistazo que también me intriga que librerías lleva :-)

Se puede usar para otros equipos, juasss

Avatar de Usuario
pser1
Mensajes: 2013
Registrado: 08 Dic 2012 18:34
Agradecido : 198 veces
Agradecimiento recibido: 181 veces

Re: Nuevo proyecto CoCo "C" CoCo/Dragon/CP400

Mensajepor pser1 » 16 Ago 2017 19:34

luiscoco escribió:Este programa está avanzadisimo, prácticamente se puede hacer un juego ya en C para coco
Esto es la reostia, jajaja, Pser ponte en contacto con el Frances Pierre Sarrazin, que le ayudamos a hacer librerias, según nos diga, y avisale a Simon, a ver si quiere ayudar.

Y como dice jltursan
jltursan escribió:Yo también estoy de acuerdo con pser1 acerca de que este es el camino a seguir. El C no es complicado, el resultado es compilado y si las librerías son las adecuadas, los resultados pueden ser muy buenos. Como ya digo, con unas buenas librerías, con un API que abstraiga en lo posible el hardware, la ventaja del C supondría el poder generar con relativa sencillez conversiones del mismo programa a las diferentes máquinas simplemente enlazando las librerías correspondientes.

A ver si le echo un vistazo que también me intriga que librerías lleva :-)

Se puede usar para otros equipos, juasss

Hola Luis,
no te embales!
Pierre Sarrazin es miembro de la lista maltedmedia de la que si recuerdo bien ... tu eres miembro también todavía, ¿Verdad?
El tema es que el es un fan de Linux y *no* ha hecho versión alguna para WIndows.
Lo que se puede ver accediendo a su página web es si ha llevado a cabo actualizaciones. Quizás nos saldría mas a cuenta tratar de
contactar con la persona que ha hecho el port a Window$.
Respecto a Simon Jonassen, estará encantado de revisar/optimizar código hecho en ensamblador 6809, así que no creo que le 'vaya'
mucho el tema de C. Un punto que hay que verificar es que esta versión de C permita el uso de assembler on line, es decir que
podamos 'meter' funciones en ensamblador puro y duro para aquellas cosas que van a requerir hiper-velocidad
saludos
pere

Avatar de Usuario
luiscoco
Mensajes: 2328
Registrado: 15 May 2011 04:23
Ubicación: Caracas, Venezuela
Agradecido : 30 veces
Agradecimiento recibido: 44 veces
Contactar:

Re: Nuevo proyecto CoCo "C" CoCo/Dragon/DP400

Mensajepor luiscoco » 16 Ago 2017 19:41

pser1 escribió: Un punto que hay que verificar es que esta versión de C permita el uso de assembler on line, es decir que
podamos 'meter' funciones en ensamblador puro y duro para aquellas cosas que van a requerir hiper-velocidad
saludos
pere


Si lo tiene

Código: Seleccionar todo

Inline assembly

Inline assembly text can be specified by surrouding it with asm { and }. In the text, one can refer to C variables (global, local and parameters) as well as functions. Labels can be used for branch instructions, but a label must either be unique to the whole program or comply with what lwasm considers a "local" label. Prefixing a global label with the name of the current C function is a good way to help prevent clashes. A label must appear at the very beginning of the line, without spaces or tabs in front of it.

One way of using lwasm local labels is to prefix the label name with the @ character. Such a label will be local to the current block, which will begin at the previous blank line (or start of the asm block) and end at the next blank line (or end of the asm block). Refer to the LWASM manual about its symbols for details on using local labels.

The following example fills array out with n copies of character ch, then returns the address that follows the region written to:

#include <cmoc.h>

char *f(char *out, char ch, unsigned char n)
{
    char *end;
    asm
    {
        ldx     out         /* comments must be C style */
        lda     ch          // or C++ style
        ldb     n
f_loop:
        sta     ,x+
        decb
        bne     f_loop
        stx     end
    }
    return end;
}

int main()
{
    char a[10];
    a[9] = '\0';
    char *p = f(a, 'X', (unsigned char) sizeof(a) - 1);
    printf("a='%s', %p, %p\n", a, a, p);
    return 0;
}

Avatar de Usuario
pser1
Mensajes: 2013
Registrado: 08 Dic 2012 18:34
Agradecido : 198 veces
Agradecimiento recibido: 181 veces

Re: Nuevo proyecto CoCo "C" CoCo/Dragon/CP400

Mensajepor pser1 » 16 Ago 2017 19:47

luiscoco escribió:
pser1 escribió: Un punto que hay que verificar es que esta versión de C permita el uso de assembler on line, es decir que
podamos 'meter' funciones en ensamblador puro y duro para aquellas cosas que van a requerir hiper-velocidad
saludos
pere

Si lo tiene

Maravilloso!
Con esto podemos tener lo mejor de los dos mundos ...
Facilidad de programación para las cosas que no requieren velocidad y ensamblador puro
para gráficos y otras hierbas
Empieza a ser tentador -thumbup
saludos
pere

Avatar de Usuario
luiscoco
Mensajes: 2328
Registrado: 15 May 2011 04:23
Ubicación: Caracas, Venezuela
Agradecido : 30 veces
Agradecimiento recibido: 44 veces
Contactar:

Re: Nuevo proyecto CoCo "C" CoCo/Dragon/DP400

Mensajepor luiscoco » 16 Ago 2017 19:55

Unsupported features

* Floating-point arithmetic (no float or double types). No se si entendi bien, tiene la aritmética pero no tiene los tipos?, pero es por restricción del C que usa o de la librería, no explica mucho
* 32-bit arithmetic (no long type). Type char is 8 bits and short and int are 16 bits. Pasa lo mismo aca
* The const keyword. Nada grave.
* Separate compilation (i.e., compiling several source files to several object files that get linked together). Nada grabe
* Bit fields. Haría un poquito de falta
* Type-safe function pointers. (The address of a function has type void * and the return type of a call through a pointer is assumed to be int.) Defectillo reparable?
* Typedefs local to a function (global typedefs are supported). No es necesario.
* Structs local to a function (global structs are supported). No es necesario
* Indirection of a pointer to a struct used as an r-value (e.g., *ptr alone). The l-value case is supported, e.g., (*ptr).field. No es importante
* Passing a struct by value to a function. Por valor?, sería ineficiente, no hace falta.
* Comma expressions (e.g., x = 1, y = 2, z = 3;). Un poco menos práctico.
* register, extern, static, volatile. The register keyword is accepted but ignored. Ya se mejorará, sobre todo para el ASS in Line
* K&R function definitions, i.e., f() int a; { ... } Un tipo de definir funciones?
* A continue statement in a switch() body. Sería bueno atacar esto
* Implementing Duff's device in a switch(). No entendi.
* Function-local function prototypes. All prototypes must be declared at global scope. Suficiente
* Zero-element arrays. Innecesario

Avatar de Usuario
pser1
Mensajes: 2013
Registrado: 08 Dic 2012 18:34
Agradecido : 198 veces
Agradecimiento recibido: 181 veces

Re: Nuevo proyecto CoCo "C" CoCo/Dragon/CP400

Mensajepor pser1 » 16 Ago 2017 20:18

luiscoco escribió:Unsupported features

* Floating-point arithmetic (no float or double types). No se si entendi bien, tiene la aritmética pero no tiene los tipos?, pero es por restricción del C que usa o de la librería, no explica mucho
* 32-bit arithmetic (no long type). Type char is 8 bits and short and int are 16 bits. Pasa lo mismo aca
* The const keyword. Nada grave.
* Separate compilation (i.e., compiling several source files to several object files that get linked together). Nada grabe
* Bit fields. Haría un poquito de falta
* Type-safe function pointers. (The address of a function has type void * and the return type of a call through a pointer is assumed to be int.) Defectillo reparable?
* Typedefs local to a function (global typedefs are supported). No es necesario.
* Structs local to a function (global structs are supported). No es necesario
* Indirection of a pointer to a struct used as an r-value (e.g., *ptr alone). The l-value case is supported, e.g., (*ptr).field. No es importante
* Passing a struct by value to a function. Por valor?, sería ineficiente, no hace falta.
* Comma expressions (e.g., x = 1, y = 2, z = 3;). Un poco menos práctico.
* register, extern, static, volatile. The register keyword is accepted but ignored. Ya se mejorará, sobre todo para el ASS in Line
* K&R function definitions, i.e., f() int a; { ... } Un tipo de definir funciones?
* A continue statement in a switch() body. Sería bueno atacar esto
* Implementing Duff's device in a switch(). No entendi.
* Function-local function prototypes. All prototypes must be declared at global scope. Suficiente
* Zero-element arrays. Innecesario

Acabo de instalarlo y hacer la prueba mas elemental. Perfecto! Buscaré como 'convencerle' para arrancar XRoar para Dragón o para CoCo2
ya que se empeña en VCC para CoCo3 (efecto grupo maltedmedia)
- Habrá que ver si realmente necesitamos tipos float. Hasta ahora los criticábamos por ocupar una burrada (5 bytes) y ser de difícil manejo.
Yo tengo el contenido de una EPROM de Motorola pensada para el 6809 que lleveba un montón de código para operaciones en coma flotante
y además en código PIC. LA ROM se llamaba MC6839 y contiene 8kb!!!
Si miráis los rotadores de imágenes 3D de Simon Jonassen, solamente utilizan enteros de +127 a - 128 y eso que se trabaja con senos y cosenos!
- El tema bit fields o bitmaps habria que ver si lo necesitamos y en su caso se crea la clase con las operaciones que se definan en ensamblador
puro y duro, independiente de la máquina (mínimo de registros)
- ¿Que defectillo hay en que los punteros a función sean void y que retornen un entero? Es el tipo estandar que estábamos persiguiendo, ¿no?
De todas maneras ya sabemos que una función puede modificar una variable global que puede ser de dos bytes y usarla como resultado
- K&R definitions significa que se adhiere a la definición de funciones establecida por los creadores del lenguaje C: Kernighan and Ritchie
- El rollo de Duff's device no lo traduzco, esta es su definición en wikipedia (inglesa)
In the C programming language, Duff's device is a way of manually implementing loop unrolling by interleaving two syntactic
constructs of C: the do-while loop and a switch statement.
Ver ejemplo en:
https://en.wikipedia.org/wiki/Duff%27s_device
En fin, veamos si hay mas ideas al respecto ...
saludos
pere

Avatar de Usuario
luiscoco
Mensajes: 2328
Registrado: 15 May 2011 04:23
Ubicación: Caracas, Venezuela
Agradecido : 30 veces
Agradecimiento recibido: 44 veces
Contactar:

Re: Nuevo proyecto CoCo "C" CoCo/Dragon/DP400

Mensajepor luiscoco » 16 Ago 2017 20:40

pser1 escribió:- El rollo de Duff's device no lo traduzco, esta es su definición en wikipedia (inglesa)
In the C programming language, Duff's device is a way of manually implementing loop unrolling by interleaving two syntactic
constructs of C: the do-while loop and a switch statement.
Ver ejemplo en:
https://en.wikipedia.org/wiki/Duff%27s_device

Bueno eso ya lo sabemos todos, que a veces en lugar de dar vueltas en un loop es más rápido instrucciones repetidas, para eficiencias llamamos a Simon que seguro nos hace una indexada con registro indice que deja todo a la mitad de tiempo y ciclos, jeje

Avatar de Usuario
pser1
Mensajes: 2013
Registrado: 08 Dic 2012 18:34
Agradecido : 198 veces
Agradecimiento recibido: 181 veces

Re: Nuevo proyecto CoCo "C" CoCo/Dragon/CP400

Mensajepor pser1 » 16 Ago 2017 21:52

luiscoco escribió:
pser1 escribió:- El rollo de Duff's device no lo traduzco, esta es su definición en wikipedia (inglesa)
In the C programming language, Duff's device is a way of manually implementing loop unrolling by interleaving two syntactic
constructs of C: the do-while loop and a switch statement.
Ver ejemplo en:
https://en.wikipedia.org/wiki/Duff%27s_device

Bueno eso ya lo sabemos todos, que a veces en lugar de dar vueltas en un loop es más rápido instrucciones repetidas, para eficiencias llamamos a Simon que seguro nos hace una indexada con registro indice que deja todo a la mitad de tiempo y ciclos, jeje

Ya, pero el truco que se inventó este señor es *genial*. Si has utilizado alguna vez este tipo de 'desdoblamiento' para acelerar rutinas,
te pasa a menudo que tienes que copiar digamos 165 bytes, entonces si haces un bucle de 8 bytes cada vez y lo repites 20 veces obtienes 160
y te quedan 5 por hacer, o sea MENOS que un bucle completo.
Manualmente, contamos cuantos van a ser necesarios en el último paso y la primera vez entramos saltándonos la diferencia, en este caso me
saltaría 8-5 = 3 y por supuesto el contador de bucle = 21 para hacer los 20 completos mas el incompleto.
Esto nos obliga a calcular cada vez y por tanto no estandariza nada.
El método de Duff implica tener un switch dentro del bucle FOR-NEXT. Montándolo adecuadamente, en la última iteración, el solito va a
elegir entrar por el sitio que hace 'solamente' el resto, en mi caso 5
Y encima el sistema sirve para cualquier cantidad de bytes! repito Genial!!
saludos
pere

Avatar de Usuario
pser1
Mensajes: 2013
Registrado: 08 Dic 2012 18:34
Agradecido : 198 veces
Agradecimiento recibido: 181 veces

Re: Nuevo proyecto CoCo "C" CoCo/Dragon/CP400

Mensajepor pser1 » 16 Ago 2017 22:05

Hola,
de momento he estado trasteando con el entorno de edición de CMOC y no he encontrado forma alguna
de evitar que arranque el emulador VCC (para CoCo3) y en su lugar arranque XRoar (para CoCo1-2, CP400 y Dragon32-64-200)
Si alguno lo descubre o sabe como hacerlo, se agradecerá nos explique el procedimiento a seguir -drinks
muchas gracias
pere

Avatar de Usuario
pser1
Mensajes: 2013
Registrado: 08 Dic 2012 18:34
Agradecido : 198 veces
Agradecimiento recibido: 181 veces

Re: Nuevo proyecto CoCo "C" CoCo/Dragon/CP400

Mensajepor pser1 » 16 Ago 2017 22:34

pues ... he osado enviarle un correo a Pierre Sarrazin con estas preguntillas:
- ¿Podríamos hacer que tras la compilación arranque XRoar en lugar de VCC?
- ¿Podríamos obtener ficheros de salida binarios para Dragón? además de para CoCo
- ¿Cuando hagas una actualización, publicarás una versión para Windows también?

Siento no haber tenido mas imaginación, estas eran mis mayores dudas, pues tal como está ahora la versión actual
no ayuda demasiado ... a los Dragoneros
saludos
pere


Volver a “Tandy CoCo”

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 1 invitado