Hola!
He mezclado la respuesta a un par de mensajes... iré quoteando las
frases.
Perdonadme todos por el tono de mis mensajes, pero es que ya estoy harto
de
ver en la scene del MSX a gente que se cree que lo sabe todo.
[>]
A lo mejor los demás estamos hartos de apariciones "deslumbrantes" y
"estelares" de usuarios de PC, que intentan igualar ambas plataformas, que
intentan trasladar lo intrasladable a este otro mundo....
Porque, se quiera o no, el MSX no es un ordenador, en la definición que
dan los libros... se parece, pero no lo es.
Y, dado que no sigue las "arquitecturas" más modernas, habrá que ver sus
posibilidades y limitaciones.
Por otra parte, hacer afirmaciones como
> - El software de UNIX se compila de forma transparente entre
plataformas,
> gracias a un compilador C standard (egcs/gcc).
es faltar a la verdad de una forma bastante burda... me tiro todo el día
programando sobre Solaris, System V y Linux, y todas las cabeceras llevan
'tropecientas' condiciones, preguntando por etiquetas de compilación para
cada kernel... claro!! así si es estandar y portable...
Decir que todos los 'kernel' de Unix son iguales y que se "compila de
forma transparente", es como decir que todos los coches llevan los mismos
modelos de tornillos... ve con un BMW a la Seat, y le pides recambios....
Y con todos mis respetos a la gente que está desarrollando UZIX, con el
mayor de mis respetos insisto.... pero tienen que estar montando "un pan con
dos ostias"....
Si lo único que llegamos a imaginar para el desarrollo es lo mismo que
ya está para el resto.... ¡¡es que aquí no pintamos nada!!! Pues se nos
habrá secado la imaginación, y para ser realista yo no tengo un MSX....
Habrá que ser "estándar" en lo único que haya que ser estándar (en los
protocolos y formatos de ficheros, principalmente)... en el resto, se podrá
ser o no.
E insisto: el C no es el estádar... es el C++. Y alguno dirá: "... hay
que saber C para C++". Sí; pero lo que se reutilizan son clases e
interfaces, no punteros....
Por algo será que todos y cada uno de los kernels de los
sistemas operativos que ves por ahí están escritos en C
[>]
Sí... pero un usuario no escribe kernels....
Y, por eso, los usuarios de Unix dejan de utilizar C, y pasar a otros
lenguajes (Tcl, Perl, GTK,...)
Repito: ¿para qué reinventar la rueda? Si quieres un lenguaje rápido,
fácil
de usar, potente e interpretado, usa Perl.
[>]
¡¡También digo yo eso!!
La rueda en MSX se llama "BASIC"... ;-DD
El acceso a los periféricos es una característica del sistema operativo,
no
del lenguaje.
[>]
El lenguaje tendrá que poseer las instrucciones apropiadas para manejar
la E/S, ya sea a alto o a bajo nivel....
En C, toda la entrada/salida se maneja como ficheros, ya sean "cooked" o
"raw"... y eso es simplificar demasiado el modelo para todos los tipos de
máquinas. Por eso luego se tienen que estar "inventando" librerías que
complementan el kernel, y permiten hacer otra serie de accesos a los
dispositivos que no son "secuenciales"...
La multitarea depende del sistema operativo, no del lenguaje. Tú estás
hablando de threads
[>]
El lenguaje deberá poseer las instrucciones para invocar las llamadas al
sistema que permitan la generación de nuevos procesos...
Si no es así, pues quitamos el fork(), y a ver cómo creamos otro proceso
para hacer multitarea...
¿Ni siquiera si haces accesos ilegales a bajo nivel a los dispositivos del
sistema? Esto también depende del sistema operativo.
[>]
Un lenguaje interpretado no permite "accesos ilegales"...
Si hay un trozo en otro lenguaje (ASM, C), ese trozo depende del otro
lenguaje, no del interpretado....
La gestión de memoria depende del sistema operativo.
[>]
Idem de arriba...
malloc(), calloc(), free(),....
Un punto interesante: ¿puede el lenguaje "resolver" lo que el hardware y
el SO estropean? Me refiero a "visión" de la memoria...
No me enrollo mucho más... no merece la pena.
Llamaremos al Sr. Tanenbaum (si te escucharan los alumnos de aquí, de la
Técnica de Informática y de la Técnica de Teleco de Madrid el nombre de ese
pibe, y ponerlo como ejemplo... la que se podría formar), y le diremos que
haga un SO estilo UNIX sin un microprocesador que implemente modo protegido,
sin un hardware que implemente espacio virtual de direccionamiento... y por
supuesto, que implemente un servidor X-Window sobre un VDP, que apenas se
sostiene haciendo SCREEN 8....
El problema que veo en estos momentos con el MSX es que los cuatro gatos
que
saben assembler se pasan el día hablando de cosas de las que no tienen ni
idea, en vez de ponerse a aprender cosas nuevas. Son considerados gurús y
todo el mundo toman lo que dicen como palabras divinas. Y todos siguen
ignorando el mundo que les rodea.
[>]
Nos aplicaremos todos el cuento...
Pero tanto los que no ven la realidad de la calle, como los que no
conocen el MSX....
Saludos.
José María.
