[Windows Vista] Carta abierta a Microsoft. Limitaciones en windows Vista (32 bits)

27/06/2006 - 19:25 por JM Tella Llop [MVP Windows] | Informe spam
(borrador - la version oficial se publicará en varios idiomas al objeto de
presionar a los Jefes de Producto para que se replanteen el alcance de
Windows Vista y prime una apuesta por la tecnologia y no por una teorica
compatibilidad con dudosos dispositivos).


Carta abierta a Microsoft. Limitaciones en windows Vista (32 bits)


Sorprendentemente me he encontrado que en la ultima beta liberada (5456.5)
del mes de Junio, posterior a la beta 2 oficial, Microsoft ha limitado la
memoria disponible por Windows Vista siendo esta siempre inferior a los 4 GB
y en algunos casos unicamente estan disponible 2 GB de memoria. Hasta el
momento, y en la ultima beta oficial (beta 2) liberada al publico, Vista
podia "ver" toda la memoria hasta los 4 GB. En la beta 1 no existia
limitacion, se usaba el modo PAE completo y se podia usar perfectamente mas
de 4 GB, en mi caso particular 8 GB.

Recordemos un poco el pasado y la cantidad de memoria disponible para los
sistemas operativos.

RECORDANDO
-

Siempre y cuando el chipset de una placa madre soporte la reasignacion de
los recursos a los dispositivos PCI, es posible en 32 bits el usar 64 GB de
memoria si el procesador soporta PAE (todas las CPUs de Intel y todos los
modelos actuales de procesador AMD). Esto es debido a la utilizacion del
modo PAE el cual puede usar 4 bits de uno de los registros de control para
ampliar a 36 bits el bus de direcciones. (fisicamente en los Pentium y
compatibles ya existen 64 lineas de direcciones).

NOTA: La reasignacion por parte del chipset y cuales lo soportan o no puede
verse en el siguiente articulo:
http://www.multingles.net/docs/jmt/4gbmem.htm

En el pasado, Microsoft permitia:

* Sistemas operativos de escritorio: hasta 4 GB de memoria. Si además se
activaba el modo PAE en el boot.ini, era posible usar los 4 GB completos ya
que el sistema operativo, bajo las premisas anteriores del tipo de chipset y
procesador, reasignaba el hardware por encima de los 4 GB.

* Sistemas operativos servidores: hasta 64 GB de memoria con las premisas
anteriores y el limite de memoria estaba en funcion del tipo de Server
adquirido (Data Center podia usar mas memoria que la version Enterprise y
esta mas que la version Server Standar)

Dentro de los sistemas operativos de escritorio, tanto W2000 Profesional
como XP y XP-SP1 podian sin problemas usar los 4 GB completos siempre y
cuando se pusiese el modificador /PAE en el archivo boot.ini

El modo PAE tiene implicaciones:

1) El acceso a memoria es ligeramente mas lento al existir a nivel de nucleo
tres niveles de indireccion en vez de dos. Realmente es inapreciable.

2) Todos los drivers de dispositivos deben estar bien codificiados, ya que
es necesario que los apuntadores a memoria tengan presente que pueden
existir direcciones por encima de los 4 GB (es decir se deben usar
apuntadores de 64 bits). Esto es lo normal ya que figura en la
especificacion de construccion de drivers, y cualquier driver certificado lo
cumple. Tambien es verdad, que muchos driver de terceros fabricantes tienen
una escasa calidad y en estos casos puede que esten mal codificados sin
cumplir las especificaciones anteriores y por tanto fallar al sistema
operativo en el modo PAE.


PRIMERAS LIMITACIONES EN XP-SP2
-

Al ser necesario el modo PAE en XP-SP2 debido a que Microsoft decidió
implementar la proteccion de ejecucion de tareas en las areas de datos (Data
Execution Prevention) tambien se encontró en una disyuntiva: si permitia el
modo PAE completo existia el peligro de que los drivers mal diseñados
hiciesen fallar al sistema operativo. Por otra parte, el PAE era necesario
para la proteccion de tareas.

Ante esta disyuntiva Microsoft decidió poner un modo PAE limitado. Es decir,
PAE activado, pero con las tablas de desciptores a memoria internas del
sistema operativo de 32 bits. Con esto limitaba el acceso a memoria ya que
al no reasignarse las direcciones por encima de 4 GB debian usarse
direcciones reales por debajo de los 4 GB para el uso de dispositivos
hardware. Esto implicaba que con SP2, aunque tuviesemos 4 GB de memoria, la
memoria real disponible al sistema operativo siempre era menor. Dependiendo
del hardware, podian ser 3,5 GB, 3 GB, 2,5 GB. En general era mayor o igual
a 2 GB pero nunca los 4 GB que hubiesemos adquirido.

En ese momento, y a pesar que como betatester protesté en su dia por esta
limitacion, la respuesta de Microsoft fun un simple "by design" sin mas
explicaciones.

Incluso en aquel momento esta decision pudiera ser logica: se debe primar la
estabilidad, a pesar de la mala calidad de drivers de terceros, a la memoria
en uso, maxime cuando los recursos consumidos por XP-SP2 eran de unos 256 MB
y un sistema, en aquel entonces, con cantidad de memoria de 1 GB o superior
era raro y a precios realmente prohibitivos.


ACTUALIDAD - Windows Vista

En la actualidad el precio de memoria es irrisorio, es normal equipos
incluso portatiles con 2 GB de memoria de serie. Igualmente los sistemas
operativos como Vista, y con el aero activado, consumen nada mas instalarse
cerca de 1 GB de memoria. Tenemos además pendiente por parte de Microsoft la
implantacion del nuevo File System (WinFs) el cual se apoyará en un nucleo
de SQL-Server. En ese momento, será necesario cerca de los 2 GB simplemente
para que nuestro sistema "empiece a andar". Esto unido al bajo precio de la
memoria hace casi imprescindible el poder usar sin limitaciones los 4 GB.

Recordemos ademas que las actuales tarjetas graficas (por ejemplo las
actuales 7950 de nVidia), ya usan 1 GB de memoria. Si no hay reasignacion de
memoria a los dispositivos, esta cantidad de memoria será disminuida de la
memoria real accesible por debajo de los 4 GB. Realmente se disminuye mucho
mas ya el propio hardware de la placa base ya necesita direcciones de
memoria, y la especificacion PCI además, asigna una granularidad o marcos de
memoria por debajo de los 4 GB a cada slot PCI.

Hasta la beta 1 de Vista, Microsoft no habia impuesto limitaciones a la
cantidad de memoria. Se podia usar con Vista e 32 bits 8 GB de memoria sin
problemas. En la versiones intermedias entre beta1 y beta2, Microsoft
decidiío limitar la cantidad de memoria a 4 GB. Esto puede ser comprensible
debido a la politica comercial comentada en los primeros parrafos y dejar
por encima de los 4 GB para las versiones de 64 bits o las versiones
servidoras (LongHorn) de 32 bits.

La sorpresa aparece en la primera build posterior a la beta 2. (la 5456.5).
Aparece una limitacion: lo mismo que en XP+SP2 el modo PAE está restringido
y no hay reasignacion del hardware por encima de los 4 GB. En mi caso
particular, en una maquina con 8 GB, solo se puede usar 2,5 GB. Esta
cantidad se quedará escasa en cuanto salga el WinFs, o bien si queremos usar
programas devoradores de memoria como es la clasica multimedia debido a que
el sistema operativo ya usa 1 GB nada mas instalarse.

No sirve en este caso la posible disculpa de pasarse a 64 bits. Vista de 64
bits obliga a que todos los drivers sean de 64 -escaso en el mercado- pero
lo mas grave es que obliga a que sean certificados. El tema es tan crudo que
es imposible por ejemplo, instalar Vista 64 en una simple y actual
controladora SATA (en modo SATA - no Legacy) ya que los drivers no son
certificados. Permitirá la instalacion, pero en el primer boot, no arrancará
informando que hay un driver de boot que no tiene el corrrespondiente hash
de nucleo registrado.


¿QUE DEBE PRIMAR?

¿que debe primar en este caso en Microsoft?. ¿la compatibilidad de drivers
dudosos -y cada vez mas escasos- o bien apostar por la tecnologia y dejar
disponibles los 4 GB?

Creo, honestamente, que Microsoft se ha equivocado al no realizar una
apuesta por la Tecnologia de la que tanto presume en este nuevo Sistema
operativo.

Recordemos que existe un serio competidor en sistema de escritorio: Linux. Y
esta es dejar abierta una posibilidad a su crecimiento. Una posibilidad
real.



Jose Manuel Tella Llop
MVP - Windows
jmtella@XXXcompuserve.com (quitar XXX)
http://www.multingles.net/jmt.htm
news://jmtella.com

Este mensaje se proporciona "como está" sin garantías de ninguna clase, y no
otorga ningún derecho.

This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.

Preguntas similare

Leer las respuestas

#41 RFOG
29/06/2006 - 18:44 | Informe spam

"Felix Gomez" wrote in message
news:


Pues no sé, pero sigo pensando que se trata de malas ideas... Cualquier
cosa que se puede hacer en ensamblador se puede hacer exactamente igual
en C.




Pero todo programa en C es del orden de 3 veces mas lento que en
ensamblador.




Eso que te lo crees tu. Esa es una de las grandes falacias que los forofos
del ensamblador se encargan de difundir. Una rutina bien hecha en C es tan
rápida -o más (el compilador, pese a ser tonto, siempre lo tiene todo en
cuenta)- que realizada en ensamblador. Y eso en PC, en otras arquitecturas
existen compiladores "agresivos" que sacan ciclos máquina de donde no te
imaginas. Te puedo comentar que el Keil para x51 y los de Metrowerks para
Motorola son enormemente eficientes. Como ejemplo, hace tiempo sustitiuí un
programa realizado en ensamblador con el Keil y, aparte de ocupar mucho
menos y tener más opciones, iba sensiblemente más rápido.
Respuesta Responder a este mensaje
#42 RFOG
29/06/2006 - 18:50 | Informe spam
"Felix Gomez" wrote in message
news:
Nada es viejo mientras cumpla con su cometido. ¿Hay algo que no se pueda
hacer con la x86-64 que se pueda hacer con otras? No, pues entonces.




Damos vueltas sobre lo mismo, ¿eh? A ver, eso no quiere decir que dichos
micros no cumplan sus objetivos, ni de lejos (esa fue una de mis primeras
premisas en mi primera respuesta), sino que la arquitectura es *vieja* y
difícil de implementar en un core, y que en el paso de 32 a 64 bits hubiera
sido el momento de hacer borrón y cuenta nueva.

No hablamos de si va bien o mal, sino de que es tan vieja y tan parcheada
que casi es un aborto. Ahora las cosas se hacen de otra forma. Mira los
nuevos micros ATMEL, o los PIC.

¿Los tornillos y destornilladores se puende hacer de otra forma? Si ¿Pero,
para que?




No confundamos. Los tornillos y destornilladores han sido así desde siempre,
porque han cumplido con su cometido desde el principio... aunque hay
evoluciones más modernas y totalmente incompatibles: Una impresora HP no
tiene apenas tornillos, todo va con inserciones. O los remaches. O los
cierres estilo mosquetón. ¿Ves como el tornillo ha evolucionado, perdiendo
la compatibilidad hacia atrás?





"RFOG" escribió en el mensaje
news:
"Felix Gomez" wrote in message
news:%
Pues mis deseos son diferentes:
Que para programar compiladores solo tengas que aprender una
arquitectura.
En telecomunicaciones que es una materia mas antigua que la informatica
hay estandares para todo y no hay nada propiedad de nadie.
La informatica tiene que tender a eso mismo y dejarse de ideas felices.

Y gracias que vamos encaminados a ello.
¿Tu que opinas?




Je je. Le has dado la vuelta a la tortilla.

A ver, de acuerdo respecto a los estándares, pero ten en cuenta que los
estándares también han de evolucionar, y la arquitectura x86 es vieja,
muy vieja, y debería evolucionar.



"RFOG" escribió en el mensaje
news:
"Felix Gomez" wrote in message
news:%
Y otra pregunta:
¿Que es lo que no te gusta de la x86-64?




Exactamente eso, que es x86-64, o sea, una arquitectura obsoleta
extendida y estirada hasta la saciedad. La necesidad de compatilibidad
con x86 (16 bits), la necesidad de compatibilidad con x32 (32 bits), el
modelo segmentado, la mierda de la conmutación modo real/protegido, un
juego de instrucciones bastante abstruso y difícil, un pipeline de
demasiadas etapas, con una lógica de predicción de salto etc
completamente absurda e innecesaria, la existencia de cuatro anillos
que nadie usa en lugar de dos, las 16 interrupciones y sus niveles
completamente objsoletos y las que se me escapan.

Yo personalmente cambiaría todo eso del core del micro por un
procesador SIMD vectorial, una alu que trabajara con números decimales
en lugar de binarios, etc, pero esto son opiniones y preferencias mías.


No me vale lo de los drivers por que siempre que se produce un cambio
en la maxima memoria direccionable, NECESARIAMENTE hay que reescribir
los drivers para que puedan acceder a toda la memoria.





Lo de arriba.



"RFOG" escribió en el mensaje
news:
"Felix Gomez" wrote in message
news:
>
Los cambios solo serían necesarios a nivel de drivers y de sistema
operativo. Todo eso que comentas lo abstrae el sistema operativo, y
si alguna aplicación se mete a ello, sencillamente: está mal hecho,
para eso tienen un SO.




Todo compilador de C permite codigo embebido en ensanblador.



¿Y? ¿Tiene algo que ver? ¿Cuántos de tus programas para PC tienen
ensamblador embebido? ¿Piensas que eres más listo que el compilador?


¿Te piensas que el cambio de un sistema operativo a otro no
requiere rehacer la mayoría de los drivers?



Compara la adaptacion de un driver de IA-32 a x86-64 con la de IA-32
a IA-64.
O la de IA-32 a la de MAC.




A ver una cosa. Estás confundiendo el tocino con la velocidad. Esos
cambios ya se han producido sin problemas. Hay fabricantes que hacen
drivers para MAC, linux, w9x, solaris, etc. Sería un nuevo driver. Y
si no que en lugar de vender hardware que vendan lechugas.

¿Por que si es tan facil como dices no hay dispositivos que valgan
para mas de una arquitectura y si los hay para la x86-64 y la IA32?


¿TU sabías que las aplicaciones de sistema se
hacen en C/C++/VB y que el único cambio sería el
compilador/intérprete.?


Si
¿Tu sabes la cantidad de compiladores que hay en el mercado, al
menos uno por arquitectura?



Si

¿Tu sabes que para cambiar un compilador sólo hay que modificar el
back-end?



No, prueba a migrar una aplicacion de C de MS a C de Borland. Y
tambien prueba de C de MS a C de Linux.
Y para colmo de C de MS a C de MAC. Y ya no te cuento si te metes
con ventanas la migracion resulta complicadisima.




Otra vez churras con merinas. Hablas de convertir entre plataformas.
Coge una aplicación Win32 bien hecha y pásala a win64. Coge una
aplicación linux 2.4 y pásala a linux 2.6. Lo mismo con MAC. Sólo es
necesario recompilar. Otra cosa es el hatajo de programadores
inútiles que hay por el mundo que no tienen ni idea de programar.

Pues cambiando la arquitectura del procesador, el sistema operativo y
el back-end del compilador correspondiente, pasar de un hipotético
win64 x64 a un win64 nueva_arq sólo debería requerir una
recompilación.

Tu me hablas de convertir entre sistemas operativos diferentes, no
arquitecturas... Hubo una época en el que windows nt funcionaba bajo
varias arquitecturas... con un mismo código fuente sólo había que
recompilar para el micro adecuado.



Pues eso.




Visita mi blog: http://rfog.blogsome.com
Libros, ciencia ficcion y programacion
>>>>>>>>>> La ansiedad es un arroyito de temor que corre por la mente. Si se
le alimenta puede convertirse en un torrente que arrastrara todos
nuestros pensamientos.




































Respuesta Responder a este mensaje
#43 Felix Gomez
29/06/2006 - 18:54 | Informe spam
Ahh y soy SemiP, da gusto hablar con personas sin prejuicios ni
cabezonerias.

Ves como si que se puede hablar conmigo sin insultar.

Saludos.

"RFOG" escribió en el mensaje
news:
"Felix Gomez" wrote in message
news:%
Pues mis deseos son diferentes:
Que para programar compiladores solo tengas que aprender una
arquitectura.
En telecomunicaciones que es una materia mas antigua que la informatica
hay estandares para todo y no hay nada propiedad de nadie.
La informatica tiene que tender a eso mismo y dejarse de ideas felices.

Y gracias que vamos encaminados a ello.
¿Tu que opinas?




Je je. Le has dado la vuelta a la tortilla.

A ver, de acuerdo respecto a los estándares, pero ten en cuenta que los
estándares también han de evolucionar, y la arquitectura x86 es vieja, muy
vieja, y debería evolucionar.



"RFOG" escribió en el mensaje
news:
"Felix Gomez" wrote in message
news:%
Y otra pregunta:
¿Que es lo que no te gusta de la x86-64?




Exactamente eso, que es x86-64, o sea, una arquitectura obsoleta
extendida y estirada hasta la saciedad. La necesidad de compatilibidad
con x86 (16 bits), la necesidad de compatibilidad con x32 (32 bits), el
modelo segmentado, la mierda de la conmutación modo real/protegido, un
juego de instrucciones bastante abstruso y difícil, un pipeline de
demasiadas etapas, con una lógica de predicción de salto etc
completamente absurda e innecesaria, la existencia de cuatro anillos que
nadie usa en lugar de dos, las 16 interrupciones y sus niveles
completamente objsoletos y las que se me escapan.

Yo personalmente cambiaría todo eso del core del micro por un procesador
SIMD vectorial, una alu que trabajara con números decimales en lugar de
binarios, etc, pero esto son opiniones y preferencias mías.


No me vale lo de los drivers por que siempre que se produce un cambio
en la maxima memoria direccionable, NECESARIAMENTE hay que reescribir
los drivers para que puedan acceder a toda la memoria.





Lo de arriba.



"RFOG" escribió en el mensaje
news:
"Felix Gomez" wrote in message
news:
>
Los cambios solo serían necesarios a nivel de drivers y de sistema
operativo. Todo eso que comentas lo abstrae el sistema operativo, y
si alguna aplicación se mete a ello, sencillamente: está mal hecho,
para eso tienen un SO.




Todo compilador de C permite codigo embebido en ensanblador.



¿Y? ¿Tiene algo que ver? ¿Cuántos de tus programas para PC tienen
ensamblador embebido? ¿Piensas que eres más listo que el compilador?


¿Te piensas que el cambio de un sistema operativo a otro no requiere
rehacer la mayoría de los drivers?



Compara la adaptacion de un driver de IA-32 a x86-64 con la de IA-32
a IA-64.
O la de IA-32 a la de MAC.




A ver una cosa. Estás confundiendo el tocino con la velocidad. Esos
cambios ya se han producido sin problemas. Hay fabricantes que hacen
drivers para MAC, linux, w9x, solaris, etc. Sería un nuevo driver. Y
si no que en lugar de vender hardware que vendan lechugas.

¿Por que si es tan facil como dices no hay dispositivos que valgan
para mas de una arquitectura y si los hay para la x86-64 y la IA32?


¿TU sabías que las aplicaciones de sistema se
hacen en C/C++/VB y que el único cambio sería el
compilador/intérprete.?


Si
¿Tu sabes la cantidad de compiladores que hay en el mercado, al
menos uno por arquitectura?



Si

¿Tu sabes que para cambiar un compilador sólo hay que modificar el
back-end?



No, prueba a migrar una aplicacion de C de MS a C de Borland. Y
tambien prueba de C de MS a C de Linux.
Y para colmo de C de MS a C de MAC. Y ya no te cuento si te metes con
ventanas la migracion resulta complicadisima.




Otra vez churras con merinas. Hablas de convertir entre plataformas.
Coge una aplicación Win32 bien hecha y pásala a win64. Coge una
aplicación linux 2.4 y pásala a linux 2.6. Lo mismo con MAC. Sólo es
necesario recompilar. Otra cosa es el hatajo de programadores inútiles
que hay por el mundo que no tienen ni idea de programar.

Pues cambiando la arquitectura del procesador, el sistema operativo y
el back-end del compilador correspondiente, pasar de un hipotético
win64 x64 a un win64 nueva_arq sólo debería requerir una
recompilación.

Tu me hablas de convertir entre sistemas operativos diferentes, no
arquitecturas... Hubo una época en el que windows nt funcionaba bajo
varias arquitecturas... con un mismo código fuente sólo había que
recompilar para el micro adecuado.



Pues eso.




Visita mi blog: http://rfog.blogsome.com
Libros, ciencia ficcion y programacion
>>>>>>>>> La ansiedad es un arroyito de temor que corre por la mente. Si se
le alimenta puede convertirse en un torrente que arrastrara todos
nuestros pensamientos.
































Respuesta Responder a este mensaje
#44 Felix Gomez
29/06/2006 - 18:58 | Informe spam
Y un buen progarmador en ensamblador puede mejorarla.

Saludos.


"RFOG" escribió en el mensaje
news:

"Felix Gomez" wrote in message
news:


Pues no sé, pero sigo pensando que se trata de malas ideas... Cualquier
cosa que se puede hacer en ensamblador se puede hacer exactamente igual
en C.




Pero todo programa en C es del orden de 3 veces mas lento que en
ensamblador.




Eso que te lo crees tu. Esa es una de las grandes falacias que los forofos
del ensamblador se encargan de difundir. Una rutina bien hecha en C es tan
rápida -o más (el compilador, pese a ser tonto, siempre lo tiene todo en
cuenta)- que realizada en ensamblador. Y eso en PC, en otras arquitecturas
existen compiladores "agresivos" que sacan ciclos máquina de donde no te
imaginas. Te puedo comentar que el Keil para x51 y los de Metrowerks para
Motorola son enormemente eficientes. Como ejemplo, hace tiempo sustitiuí
un programa realizado en ensamblador con el Keil y, aparte de ocupar mucho
menos y tener más opciones, iba sensiblemente más rápido.
Respuesta Responder a este mensaje
#45 Felix Gomez
29/06/2006 - 19:06 | Informe spam
Cuando hay millones de lineas de codigo escritas exclusivamente para la x86.
Diles ahora que las tienen que cambiar totalmente. Que no les sirven. Te
pegan un tiro.

Saludos


"RFOG" escribió en el mensaje
news:
"Felix Gomez" wrote in message
news:
Nada es viejo mientras cumpla con su cometido. ¿Hay algo que no se pueda
hacer con la x86-64 que se pueda hacer con otras? No, pues entonces.




Damos vueltas sobre lo mismo, ¿eh? A ver, eso no quiere decir que dichos
micros no cumplan sus objetivos, ni de lejos (esa fue una de mis primeras
premisas en mi primera respuesta), sino que la arquitectura es *vieja* y
difícil de implementar en un core, y que en el paso de 32 a 64 bits
hubiera sido el momento de hacer borrón y cuenta nueva.

No hablamos de si va bien o mal, sino de que es tan vieja y tan parcheada
que casi es un aborto. Ahora las cosas se hacen de otra forma. Mira los
nuevos micros ATMEL, o los PIC.

¿Los tornillos y destornilladores se puende hacer de otra forma? Si
¿Pero, para que?




No confundamos. Los tornillos y destornilladores han sido así desde
siempre, porque han cumplido con su cometido desde el principio... aunque
hay evoluciones más modernas y totalmente incompatibles: Una impresora HP
no tiene apenas tornillos, todo va con inserciones. O los remaches. O los
cierres estilo mosquetón. ¿Ves como el tornillo ha evolucionado, perdiendo
la compatibilidad hacia atrás?





"RFOG" escribió en el mensaje
news:
"Felix Gomez" wrote in message
news:%
Pues mis deseos son diferentes:
Que para programar compiladores solo tengas que aprender una
arquitectura.
En telecomunicaciones que es una materia mas antigua que la informatica
hay estandares para todo y no hay nada propiedad de nadie.
La informatica tiene que tender a eso mismo y dejarse de ideas felices.

Y gracias que vamos encaminados a ello.
¿Tu que opinas?




Je je. Le has dado la vuelta a la tortilla.

A ver, de acuerdo respecto a los estándares, pero ten en cuenta que los
estándares también han de evolucionar, y la arquitectura x86 es vieja,
muy vieja, y debería evolucionar.



"RFOG" escribió en el mensaje
news:
"Felix Gomez" wrote in message
news:%
Y otra pregunta:
¿Que es lo que no te gusta de la x86-64?




Exactamente eso, que es x86-64, o sea, una arquitectura obsoleta
extendida y estirada hasta la saciedad. La necesidad de compatilibidad
con x86 (16 bits), la necesidad de compatibilidad con x32 (32 bits),
el modelo segmentado, la mierda de la conmutación modo real/protegido,
un juego de instrucciones bastante abstruso y difícil, un pipeline de
demasiadas etapas, con una lógica de predicción de salto etc
completamente absurda e innecesaria, la existencia de cuatro anillos
que nadie usa en lugar de dos, las 16 interrupciones y sus niveles
completamente objsoletos y las que se me escapan.

Yo personalmente cambiaría todo eso del core del micro por un
procesador SIMD vectorial, una alu que trabajara con números decimales
en lugar de binarios, etc, pero esto son opiniones y preferencias
mías.


No me vale lo de los drivers por que siempre que se produce un cambio
en la maxima memoria direccionable, NECESARIAMENTE hay que reescribir
los drivers para que puedan acceder a toda la memoria.





Lo de arriba.



"RFOG" escribió en el mensaje
news:
"Felix Gomez" wrote in message
news:
>
Los cambios solo serían necesarios a nivel de drivers y de sistema
operativo. Todo eso que comentas lo abstrae el sistema operativo,
y si alguna aplicación se mete a ello, sencillamente: está mal
hecho, para eso tienen un SO.




Todo compilador de C permite codigo embebido en ensanblador.



¿Y? ¿Tiene algo que ver? ¿Cuántos de tus programas para PC tienen
ensamblador embebido? ¿Piensas que eres más listo que el compilador?


¿Te piensas que el cambio de un sistema operativo a otro no
requiere rehacer la mayoría de los drivers?



Compara la adaptacion de un driver de IA-32 a x86-64 con la de
IA-32 a IA-64.
O la de IA-32 a la de MAC.




A ver una cosa. Estás confundiendo el tocino con la velocidad. Esos
cambios ya se han producido sin problemas. Hay fabricantes que hacen
drivers para MAC, linux, w9x, solaris, etc. Sería un nuevo driver. Y
si no que en lugar de vender hardware que vendan lechugas.

¿Por que si es tan facil como dices no hay dispositivos que valgan
para mas de una arquitectura y si los hay para la x86-64 y la IA32?


¿TU sabías que las aplicaciones de sistema se
hacen en C/C++/VB y que el único cambio sería el
compilador/intérprete.?


Si
¿Tu sabes la cantidad de compiladores que hay en el mercado, al
menos uno por arquitectura?



Si

¿Tu sabes que para cambiar un compilador sólo hay que modificar el
back-end?



No, prueba a migrar una aplicacion de C de MS a C de Borland. Y
tambien prueba de C de MS a C de Linux.
Y para colmo de C de MS a C de MAC. Y ya no te cuento si te metes
con ventanas la migracion resulta complicadisima.




Otra vez churras con merinas. Hablas de convertir entre plataformas.
Coge una aplicación Win32 bien hecha y pásala a win64. Coge una
aplicación linux 2.4 y pásala a linux 2.6. Lo mismo con MAC. Sólo es
necesario recompilar. Otra cosa es el hatajo de programadores
inútiles que hay por el mundo que no tienen ni idea de programar.

Pues cambiando la arquitectura del procesador, el sistema operativo
y el back-end del compilador correspondiente, pasar de un hipotético
win64 x64 a un win64 nueva_arq sólo debería requerir una
recompilación.

Tu me hablas de convertir entre sistemas operativos diferentes, no
arquitecturas... Hubo una época en el que windows nt funcionaba bajo
varias arquitecturas... con un mismo código fuente sólo había que
recompilar para el micro adecuado.



Pues eso.




Visita mi blog: http://rfog.blogsome.com
Libros, ciencia ficcion y programacion
>>>>>>>>>>> La ansiedad es un arroyito de temor que corre por la mente. Si
se le alimenta puede convertirse en un torrente que arrastrara
todos nuestros pensamientos.








































Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida