Estructura de procesador

Yo intentare ayudarte con lo poco ke se...
pues bien, se supone k los diferentes tipos de procesadores tienen una forma de "procesar"(valga la redundancia) las ordenes ke le llegan, pues bien , de la forma k tiene cada uno de procesar esas ordenes surgen los diferentes tipos de Micros, Sparc, PPC (ke no es otra cosa k PowerPC... los Mac) i386 (y sus evoluciones i586, i686...)

k yo sepa, salvo en el caso de los micros ix86 k son compatibles con los anteriores , es decir, k puedes rular codigo hecho para un i386 en un i686... son incompatibles entre si, con lo cual un programa hecho para Sparc, de ninguna forma se puede usar en un PPC o un i686 ni viceversa... a no ser k sea tocando el codigo fuente (como ocurre en las distros de Linux, por ejemplo)

Sobre las estructuras usadas en los Micros mas comunes (AMD, Intel, incluso Cyrix o Winchip )
estan basados (segun la generacion) en evoluciones del i386... de la siguiente forma (mas o menos... no estoy muy seguro)
i585=Pentium y sus ekivalentes en AMD
i686=Pentium 2 y sus ekivalentes
...
y asi sigue...

Espero haberte ayudado un poco en el tema, no se mucho sobre esto, pero he tratado de ayudarte en lo poco k sabia ...

Un saludo

Jejeje!

Pos muchísimas gracias!

No quería saber más que eso... era sólo para enterarme más o menos, sin complicarme la vida, porque ya me tocará estudiarlo algún día... ,-).

Muchas gracias por todo.

Salu2!

P.D: Ya me he bajado la peli de Akira... tan bien está?

Vamos a ver,

Hay varias familias de procesadores, PowerPC, alpha, SPARC, ix86...., y dentro de estas familias hay procesadores que son "compatibles" entre si.

¿Que quiero decir con compatibles?, que en un i586 puedes ejecutar codigo de un i386, ya que un i586 "extiende" un i386. Si compilas algo en un i386 FIJO que te va a funcionar en un i586, pero puede que no se de el caso contrario, mas que nada porque si al compilar haces uso de alguna instruccion en ensamblador que tenga el i586 pero no el i386 vas a tener problemas

ix86 son compatibles entre si siempre que se haga "de menor a mayor", pero lo que ya es IMPOSIBLE es que compiles algo en un alpha y te rule en un ix86, ya que el juego de instrucciones de ambos procesadores son TOTALMENTE diferentes. (no son ni compatibles ni de la misma familia ni nada)

En el caso de intel y amd, la 'i' de los 'i'x86 es de INTEL, pero los procesadores de AMD son compatibles con intel. Son distintos micros, de distinta compañia, pero de la misma familia.


Bueno, espero que te haya quedado mas claro


Saludos!

Aprovecho ya que se está hablando de procesadores y de Linux al mismo tiempo, que lo que se está comentando es una de las razones por las que se han creado distribuciones como Gentoo. Compilar todos los programas en tu máquina lleva tiempo, pero tienes tu recompensa si lo haces específicamente para tu procesador, por eso va todo mucho más rápido.

Yo por ejemplo tengo un P3 a 933, lo que significa que puedo ejecutar código i686, e instrucciones extendidas MMX y SSE. Alguien que tenga un Athlon XP, pues tiene un i686+MMX+SSE+3DNOW.

Las mejoras a la hora de calcular y manejar datos dentro del procesador, además de las ampliaciones que se hacen al código x86 y los conjuntos de instrucciones extendidas hacen que los procesadores sean más eficientes a la hora de manejar ciertos datos, de tal manera que el aumento de potencia no venga dado sólo por los Mhz, el número de transistores o la velocidad de los buses y memoria.

Es por eso que hay algunas distros que pecan en ese aspecto, como Debian. ¿De qué me sirve tener todos los paquetes compilados para i386? Para qué tengo un 686, y las instrucciones mmx y sse? Pues para usarlas en todos los casos posibles. Por qué hay distros que usan todavía gcc 2.96, sabiendo que gcc 3.2.1 funciona perfectamente y genera código mucho más rápido y eficaz (sin contar optimizaciones específicas)?

Y que conste que nunca he probado Debian, y seguramente es el colmo de la organización y la calidad, pero ahí pecan bastante. Es por eso por lo que opté por Gentoo, al final, para que todo me vaya lo más rápido posible.

No es por salirme del tema y empezar una discusión sobre distro1 vs distro2, pero ya que se ha preguntado sobre las diferentes arquitecturas x86 y de otras cpu's, aprovecho para remarcar la importancia que tiene, ya que se disfruta de soft libre, de compilarte las cosas para tu máquina, y no para las de hace 10 años.

salu2

Escrito originalmente por Briareos_H
Es por eso que hay algunas distros que pecan en ese aspecto, como Debian. ¿De qué me sirve tener todos los paquetes compilados para i386? Para qué tengo un 686, y las instrucciones mmx y sse? Pues para usarlas en todos los casos posibles. Por qué hay distros que usan todavía gcc 2.96, sabiendo que gcc 3.2.1 funciona perfectamente y genera código mucho más rápido y eficaz (sin contar optimizaciones específicas)?

Y que conste que nunca he probado Debian, y seguramente es el colmo de la organización y la calidad, pero ahí pecan bastante. Es por eso por lo que opté por Gentoo, al final, para que todo me vaya lo más rápido posible.

No es por salirme del tema y empezar una discusión sobre distro1 vs distro2, pero ya que se ha preguntado sobre las diferentes arquitecturas x86 y de otras cpu's, aprovecho para remarcar la importancia que tiene, ya que se disfruta de soft libre, de compilarte las cosas para tu máquina, y no para las de hace 10 años.

salu2

Briareos_H diste en el clavo, no eres ningun tonto amigo.

De todas formas lo de debian NO ES UN PECADO... esta hecho aproposito y es una de sus caracteristicas esenciales "corre hasta en una patata".

POR ESO siempre el viejo sergiox dice: cada distribucion tiene un fin especifico... no tiene sentido hoy en dia instalarte una debian en tu pc multimedia cuando hay distro especializadas para eso (lease mandrake) en donde todos los paquetes estan compilados para 686 (es criticada por eso) y te autodecta el hard y tiene urpmi. bah! casi nada.

Yo uso debian en mi pc secundaria y he hecho una prueba para que vean la diferencia entre un paquete debian para 386 (las Vorbis Tools), y las vorbis tools compiladas por mi para mi micro. (un celeron 400).

Codifique el mismo wav primero con el binario 686 y luego con el 386 que viene con la debian.

Adjunto PNG

Como ven... es increible, hay una diferencia de +1 minuto!!! Encima el kernel de mi debian esta recompilado para 686 y varias de las librerias las recompile para 686 (las libao por ejemplo)... asi que si estuviera la debian original los resultados podrían haber sido incluso mas IMPRESIONANTES.


salu2

PD: veo que el foro crece dia a dia, cada vez vamos tocando temas mas interesantes.

Escrito originalmente por InDeeD
P.D: Ya me he bajado la peli de Akira... tan bien está?

Pues aunke la tenga de Avatar, y mi nombre sea este... te dire k no soy un fanatico de la serie (en manga) ni de la peli, yo la tengo bajada tambien, y me gusta mucho, aunke no es tampoco como para considerarla una obra maestra del Manga eso si, vale la pena

Escrito originalmente por sergiox



De todas formas lo de debian NO ES UN PECADO... esta hecho aproposito y es una de sus caracteristicas esenciales "corre hasta en una patata".

Sí, la verdad es que podría funcionar en cualquier cosa, y no me extraña que sea estable a rabiar, entre la optimización nula y que tardan la tira en actualizar el software, no me extraña que sea duro como una roca.

Y es que es cierto que Gentoo es más inestable que Debian, al menos sobre el papel, pero prefiero perder un 2% de estabilidad pero que los programas al menos vayan decentes. Pq macho, entre las X 4.2 y KDE 3, menudo par

Pero también es muy cierto lo que comentas, cada distro vale para lo que vale. De todas maneras es muy remarcable que una gran cantidad de gente que ahora usa Gentoo viene de Debian. No se dónde leí que un 60% venían de la Debian, pero bueno, hay que tomárselo como una cifra "orientativa" . Yo vengo de usar Mandrake 8.1, y francamente, no vuelvo a usarlo ni p'atrás. Por cierto sergiox, la mdk no está compilada para i586? Diría que sí, pq si no los ke tengan cpu's de la família AMD K6 se quedan sin mandrake

Enga, salu2

Escrito originalmente por sergiox



Briareos_H diste en el clavo, no eres ningun tonto amigo.

De todas formas lo de debian NO ES UN PECADO... esta hecho aproposito y es una de sus caracteristicas esenciales "corre hasta en una patata".

POR ESO siempre el viejo sergiox dice: cada distribucion tiene un fin especifico... no tiene sentido hoy en dia instalarte una debian en tu pc multimedia cuando hay distro especializadas para eso (lease mandrake) en donde todos los paquetes estan compilados para 686 (es criticada por eso) y te autodecta el hard y tiene urpmi. bah! casi nada.

Yo uso debian en mi pc secundaria y he hecho una prueba para que vean la diferencia entre un paquete debian para 386 (las Vorbis Tools), y las vorbis tools compiladas por mi para mi micro. (un celeron 400).

Codifique el mismo wav primero con el binario 686 y luego con el 386 que viene con la debian.

Adjunto PNG

Como ven... es increible, hay una diferencia de +1 minuto!!! Encima el kernel de mi debian esta recompilado para 686 y varias de las librerias las recompile para 686 (las libao por ejemplo)... asi que si estuviera la debian original los resultados podrían haber sido incluso mas IMPRESIONANTES.


salu2

PD: veo que el foro crece dia a dia, cada vez vamos tocando temas mas interesantes.

Eso de que mandrake corre mas que debian pues no se que decirte, yo diria que no, normalmente las mandrake y similares llevan un kernel demasiado cargado, hice la pruba con redhat8.0 y por ejemplo en modo gráfico sin hacer nada(en gnome2), chupaba 210-220megas de Ram y en debian con el kernel por defecto y también con gnome2 70-80megas solo de Ram, asi que no se yo si cambiaria facilidad por rendimiento, no merece la pena, lo unico que no me gusta de debian es lo que tardan en sacar packetes de la rama estable por eso en cuanto salga gentoo 1.4final(que sale a final de mes) la voy a probar porque creo que es la distro de mis sueños[looco]

Saludos

Si, tienes razon, los paquetes que vienen en los cds estan todos para i586. Excuse me.

En cambio los paquetes que se bajan con urpmi de los repositorios, estan el 90% compilados para i686.

En cuanto a la migracion a gentoo (u otras) se va a notar mucho cuando debian tenga un instalador tipo "next next next". Conociendo el snobismo de los usuarios linux muchos se pasaran a gentoo solo por usar algo "menos" popular.


salu2

Escrito originalmente por torrente2

Eso de que mandrake corre mas que debian pues no se que decirte, yo diria que no, normalmente las mandrake y similares llevan un kernel demasiado cargado, hice la pruba con redhat8.0 y por ejemplo en modo gráfico sin hacer nada(en gnome2), chupaba 210-220megas de Ram y en debian con el kernel por defecto y también con gnome2 70-80megas solo de Ram, asi que no se yo si cambiaria facilidad por rendimiento, no merece la pena, lo unico que no me gusta de debian es lo que tardan en sacar packetes de la rama estable por eso en cuanto salga gentoo 1.4final(que sale a final de mes) la voy a probar porque creo que es la distro de mis sueños[looco]

Saludos

Mmmm... no creo que se deba al kernel... ya que todo viene de forma modular.
Esa enorme diferencia de memoria puede ser culpa de los servicios que tengas corriendo, las configuraciones graficas que tengas puestas etc, etc.

Yo no dije que mandrake corra mas rapido, solo que trae todo compilado para procesadores mas modernos. Debian esta todo para 386, si tienes un procesador de pocos megahertz desaprobechas cualquier cantidad de performance al no usar las instrucciones pentium.

No se porque todo ese delirio cuasi-mistico con la debian, salvo el sistema de paquetes, las demas cosas son comunes en casi todas las distros. No hay magia lastimablemente.

Ojo que quede claro... Debian Roolz!!! amo debian, de hecho la uso todo los dias. Pero hay que ser conciente de sus "limitaciones" que son absolutamente justificadas. (estabilidad y compatibilidad)

salu2 y celebremos tanta diversidad![beer]

Jur Jur! Lo que aprende uno...

Realmente, gracias por todo lo explicado. Comienzo a entender varias cosas...

Pero... mi ignorancia sigue ahí... ¿qué es el gcc?

¿qué son exactamente las instrucciones internas del procesador? Me explico. Aquí decís que las instrucciones paramanejar los datos dentro del procesador, son diferentes en cada modelo de ¿chip?(no sé si donde se manejan los datos será realmente un chip u otro componente). ¿Se añaden nuevas instrucciones en cada modelo posterior a otro? No sé... es algo que conceptualmente no acabo de coger al 100% (seré muy cazurro, o querré profundizar demasiado...).

En linux ya veo que como siempre... todo es modificable... ¿Para qué modelo de procesador vienen los programas para windows?¿Vienen todos para i686?

Y comprendo ahora también muchas cosas de la estabilidad en los SOs con esto de las compilaciones... Y me ha gustado mucho la explicación de sergiox. Realmente parece que... para el usuario normal resulta mucho más eficaz y cómodo tener los paquetes en i686, así como para el que tiene un servidor, los i386 de debian deben ser un luoj para el negocio... Cada uno a lo suyo.

Jejeje! Y también me ha hecho gracia lo del snobismo... También creo que así sucede.... pero tampoco es nada nuevo ni exclusivo del mudno linux... en windows mismo viene pasando de igual manera. Personalmente creo que lo mejor es pedir opiniones, informarse y en base eso elegir lo que más te puede convenir a ti, no a otros. Eso sí, si se puede probar todo.... nunca está de más. Seguramente la elección sea mucho más acertada... porque cada uno es cada uno (vaya rollo acabo de soltar de repente eh? Ya os dejo....)

Gracias a todos por las explicaciones.

Salu2!

P.D: Sobre lo de tratar diversos temas en los foros... se va notando... mi problema es que .... sé poco y tengo demasiada curiosidad, jejeje! y veo que en lo último no me quedo atrás con otros compañeros del foro

Escrito originalmente por InDeeD
¿qué son exactamente las instrucciones internas del procesador? Me explico. Aquí decís que las instrucciones paramanejar los datos dentro del procesador, son diferentes en cada modelo de ¿chip?(no sé si donde se manejan los datos será realmente un chip u otro componente). ¿Se añaden nuevas instrucciones en cada modelo posterior a otro? No sé... es algo que conceptualmente no acabo de coger al 100% (seré muy cazurro, o querré profundizar demasiado...).

Vamos a ver, esto es no es facil, pero veo que no vas mal encaminado

Los micros procesan las instrucciones en binario, y cada familia de procesadores tiene su propio juego de instrucciones, de ahi que sean incompatibles los ix86 y los alpha, por ejemplo.

¿porque cuando obtienes el fuente y compilas el programa funciona en todas las maquinas, si las instrucciones son diferentes?, ahi hay que distinguir dos tipos de instrucciones, ya que por un lado estan las de los lenguajes de alto nivel (por ejemplo C, C++ o JAVA) que son independientes de la maquina bajo la cual se ejecuten, y por otro estan las instrucciones de bajo nivel, o lenguaje ensamblador, que es el que manejan los procesadores ya que ese lenguaje en si no es mas que binario.

¿Como pasar de un lenguaje a otro?, bueno, el compilador es el que se encarga de eso. A partir de un fuente escrito en un lenguaje de alto nivel el compilador genera el ejecutable para que el micro lo entienda usando instrucciones de bajo nivel. A diferentes micros incompatibles diferentes compiladores, aunque escriban ejecutables para diferentes lenguajes de alto nivel (espero que se me entienda )

Hay micros compatibles, como los 386 y los athlon, por poner un ejemplo. Como ya dije en otro post, athlon ejecuta TODO lo que haya sido compilado para 386, pero al reves es posible que esto no suceda, ¿porque?, porque es posible que al compilar en el athlon hayamos usado alguna instruccion que tenga ese micro que no tenga el 386, por ejemplo.

De esta forma, los P3 tienen un mayor juego de instrucciones que un P2, estos mas que un Pentium, etc ... quedandose abajo el 386, que digamos que es el elemento que esta mas abajo de la escalera y por eso decimos que todo lo que funcione en un 386 funciona en los demas

386, Pentium, P2 y P3 pueden hacer las mismas cosas, pero expresadas con diferentes instrucciones de bajo nivel. Para un P3 es mas optimo utilizar instrucciones de P3 que no las de un 386, pero eso no quita que con las de un 386 no vaya a funcionar. Lo hara, pero no aprovechando tanto el micro.


Ya para dejar el tema claro, si tu compilas TODO lo que tengas en tu pc (caso gentoo), el sistema te ira lo mas rapido que puede ir, ya que todos los programas aprovechan al maximo el micro ya que utilizan todo su juego de instrucciones. Si no compilas tambien funciona, pero al no aprovechar al maximo el juego de instrucciones no te va tan rapido como te podria ir si lo compilases todo.


Puf, que rollo , si alguno todavia esta despierto, espero que ya no tenga dudas si es que las tenia


Saludos!

Cada procesador tiene lo que se llama "set de instrucciones" que no son mas que el conjunto de operaciones que el micro puede hacer.

Por ejemplo un codigo en C es una "lista de palabras" que entiende el compilador, cuando lo compilas obtienes un "binario" que es una "lista de palabras" que es entendida por el microprocesador. Esas "palabras" son instrucciones del procesador. jeje que patetico soy cuando quiero sonar didactico. X-D

Cada arquitectura posee un set propio, el set de un PowerPC es totalmente distinto al de las Intel, y asi todo.

La arquitectura de intel se llama genericamente x86 y se viene usando desde hace mas de 20 años, desde el 8086 que fue el primero.

Asi que te puedes imaginar que el set de instrucciones se fue ampliando con cada procesador x86 que sale... el 286 tenia su set, luego el 386 agrego mas instrucciones a ese set, y el 486 agregó mas, y el 586 mas, etc. Es decir, cada procesador es un superconjunto de los anteriores.

Que tiene de bueno eso? Que son compatibles hacia atras... puedes ejecutar codigo de un 8088 en un Pentium4 20años posterior. Es la filosofia de intel, muchas veces cuestionada por ser muy conservadora.

Obviamente, un codigo compilado para 586 va a tener instrucciones que en un 386 no estan... entonces ese codigo no va funcionar en 386... pero SI en un 686. Capisci?

A todo esto de las instrucciones hay que sumarle las instrucciones "especiales"... lease MMX, 3Dnow, SSE, SSE2 etc etc. Por supuesto que si quieres usarlas tienes que compilar los programas especificando el soporte para ellas.

Respecto a windows, los programas para windows estan compilados segun la epoca en que salen al mercado y las necesidades propias del programa. Los programas win32 actuales casi todos estan en codigo 686 o 586. (supongo)

Lo que expliqué es muy general, si necesitas alguna puntualidad pregunta.

Espero que todo este rollo te sirva.


salu2[bye]

Juas Raulex hemos respondido los dos la misma cuestion!!! jajaja

De todas formas creo que ambas son complementarias.


salu2

Me gusta este hilo.

Respuestas escuetas

Vamos a ver .. q es gcc? es un compilador de c c++ .

Q tarea hace un compilador? como han dicho aqui pasa codigo semi-standart a codigo maquina ( instrucciones de micro)

Las diferencias donde radiqcan pues?


podemos tener una instruccion tan chorras como

println ("hola mundo");

El compilador lo q hace es pillar la instruccion y traducirla a un lenguaje q entiende la maquina a lo q se llaman instucciones de ensamblador ( en los ix86)

LAs diferencias radican en la traduccion a ese ensamblador o a codigo maquina, puesto q una chorrada tan simple como mover un dato de memoria a registro se traduce en lenguaje de microinstruccion en una tira de 1 y 0 q permite a la ALU ( unidad Algoritmico logica) y todo su chipset saber q tiene q hacer con esa instruccion.

Ya no solo hay diferencias de criterio en la construccion de micros sino tb hay diferencias en la arquitectura ( por ejemplo 32bits o 64bits)

( no se si me he explicado)

a lo q iba , q quizas en i386 una instruccion de c se traduce en 4 instrucciones

" mover dato 1 a registro1"+" mover dato 2 a registro2"+"hacer operacion" +"almacenar en registro 3" ... por ejemplo " ( ya se q realmente no es asi pero es para q me entiendan)

en un procesador SPARC de 64bits puede ser q se haga en 2 instrucciones
"mover dato1 a registro 1 y dato2 a registro2" + "hacer operacion y almacenar en registro3"


... me entendeis? jejejej es q estoy espeso hoy pero por ahi van los tiros , si quereis profundizar mas me lo decis.


p.d: esa es la explicacion pq hay compiladores de c para diferentes plataformas pq no es lo mismo ( aunque sea la misma instruccion de c) la traduccion para un i386 q para un sparc.

p.d2: Ya no entro en multiprocesador pq sino

Escrito originalmente por escufi
Vamos a ver .. q es gcc? es un compilador de c c++ .

mmm, eso es discutible

[root:~]$ gcc -v
Leyendo especificaciones de /usr/lib/gcc-lib/i386-linux/3.2.1/specs
Configurado con: ../src/configure -v --enable-languages=c,c++,java,f77,proto,pascal,objc,ada --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.2 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-java-gc=boehm --enable-objc-gc i386-linux
Modelo de hilos: posix
gcc versión 3.2.1

Por cierto, yo uso Debian y como ves tengo el gcc 3.2.1, así que eso de actualizar tarde depende de muchas cosas.

Debian es ante todo estabilidad y que funcione en las casi 11 arquitecturas que maneja debian, si si, no habeis leido mal y diferentes arquitecturas son diferentes tipos de procesadores

http://www.debian.org/ports/index.en.html

En la stable sólo se actualiza si hay bugs, y a ser posible no se actualiza la versión, por eso mismo es el Linux más utilizado en servidores, por su estabilidad.

En Sid estás a la última pero corres el peligro de pillar programas con bugs, en testing estas más seguro de encontrar bugs gordos y estas casi siempre al día.

En paquetes gordos como KDE y el gcc antes de pasar todo a esa nueva versión se espera a que sea estable y no hayan fallos. Si no te gusta ese funcionamiento siempre puedes compilartelo tu o pillar los debs de alguien que ya los haya hecho.

Lo primordial es la estabilidad y la seguridad y eso mismo hace que para cosas serias sea lo mejor, tal vez para el escritorio sería mejor tener todo compilado para i686, para eso desde hace un tiempo tienes el apt-build

http://packages.debian.org/unstable/devel/apt-build.html

Jejeje!!!

Gracias por el efuerzo de todos!!!

A vé... lo de la compatibilidad hacia atrás, y los niveles de programación lo entiendo perfectamente, al igual que lo que es un compilador y toda es clase de cosas (que aunque sólo lleve 3 meses de 1º de informática... algo he aprendido...).

Ya todo ha quedado mucho más claro. Es que de hardware todavía no he dado nada, y menos de la relación hardware-software...y weno, com yo me meto en todos los berenjenales... pos hago que os metáis vosotros también .

Gracias por todo. Al final creo que ha resultado un buen hilo para cualquiera que se quiera interesar un poco.

No sabía (auqnue ahroa que lo pienso parece muy lógico) que se programara igual para todas las plataformas, y que tan sólo cambiara el compilador, dependiendo de la plataforma donde se ejecute.

Lo de 32Bits y 64Bits de los procesadores, voy a buscar más información por ahí para saber algo más, aunque ya tengo ahí la idea.

Lo de las instrucciones... lo único que no entiendo es qué son exactamente... (pero en plan conceptual, no lo que hacen). Me explico. Por ejemplo... dependiendo del set quiere decir que a lo mejor... intel hace los pasos de una manera y SPARC de otra? Es que me cuesta entender cómo si en lo que a ellos les llega por ejemplo "leer dato, escribir pantalla, insertar dato", por ese orden... se pueda hacer de maneras diferentes... :-S ¿Acaso soy muy tonto?

Sobre lo de compilar según tu procesador (como se hace en gentoo por lo visto), ¿es muy difícil?¿qué nivel de programación hace falta?

Bueno... no se me ocurre nada más por ahora... (por ahora...)XDXDXD.

Mil gracias.

Salu2!

Pues sí, cada empresa se monta sus procesadores como quiere, y aunque la filosofía pueda ser la misma, las cosas no se hacen de la misma manera.

Por ejemplo, hay dos famílias clásicas de cpu's, las risc y las cisc, las primeras tienen un set de instrucciones muy reducido y de tamaño fijo, las cisc usan un set de instrucciones muy amplio y variable. Los procesadores Athlon, por ejemplo, son compatibles con las instrucciones i686 (que pertenecen a una filosofía cisc que intel ha usado siempre), pero curiosamente por dentro los datos se calculan en modo risc. Inte también hace esto desde la familia 686 (de pentium pro hacia adelante). Es por eso por lo que el compilador tiene que generar binarios diferentes, cada uno para la arquitectura que toque.

Por ejemplo, es posible que haya una familia de procesadores risc que no tengan una instrucción propia de multiplicar, por lo tanto el compilador tendrá que generar un cojunto de sumas que logren hacer la multiplicación. Sin embargo habrá procesadores cisc que ya incorporen esa operación, lo cual es menos tarea para el compilador.

Generalmente contra menos instrucciones haya más complicado lo tendrá el compilador, y al revés.

Lo que comentas de 32/64 bits es la cantidad de datos que ocupa cada instrucción. En el caso de los procesadores x86, son de 32 bits de momento, y AMD está a punto de sacara la família hammer de 64 bits. Contra más grande sea el tamaño de instrucción generalmente más potente es la cpu, pero eso sólo es uno entre muchos factores...

Para compilar para tu cpu, es muy fácil, ya que no eres tú el compila, tú das un comando y ya está En Linux se debe configurar el make.conf (el make.globals no suele hacer falta).

Concretamente se indica:

CHOST="i686-pc-linux-gnu" para indicar que tenemos un micro de esta familia.

y despues:

CFLAGS="-march=pentium3 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"

CFLAGS es para los programas escritos en C, y CXXFLAGS para los escritos en C++, que en este caso ponemos que sea la misma configuración.

Esto es lo que yo tengo puesto ahora, es decir, que optimice para Pentium 3, con un nivel 3 de optimización -que muchos programas importantes como el kernel o librerías gordas igualmente pasan y se compilan a nivel 2 para evitar inestabilidades- , -pipe que sirve para que no llene el disco de archivos temporales al compilar, y el otro comando es para máquinas que soportan el dupurado sin puntero de marco (creo que lo que hace es liberar un registro de la cpu).

El programa ya digo que puede hacer caso omiso de esta configuración por seguridad, pero la mayoría de programas normales usa lo que pongamos en esta línea. Por cierto, lo de march significa optimizar para tu cpu sin compatibilidad hacia atrás.

salu2

No sabía (auqnue ahroa que lo pienso parece muy lógico) que se programara igual para todas las plataformas, y que tan sólo cambiara el compilador, dependiendo de la plataforma donde se ejecute.

Ese es el IDEAL, y es para una de las cosas que se han creado los lenguajes de alto nivel.
Si se programara todo en ensamblador (que es lo mas cercano al lenguaje maquina) tendrias que programar el mismo programa tantas veces como plataformas quieras abarcar.
Lograr escribir un programa que se compile en todas las maquinas y compiladores es algo ideal y muy complejo... por eso se crearon los estandares, por ejemplo POSIX que define las llamadas al sistema, ANSI C que estandariza las funciones de C. Etc Etc.
Despues esta el tema de las maquinas virtuales pero ese es otro cantar. Aunque siempre la idea es lograr abstraerse del hardware y lograr programas "universales".

Lo de las instrucciones... lo único que no entiendo es qué son exactamente... (pero en plan conceptual, no lo que hacen). Me explico. Por ejemplo... dependiendo del set quiere decir que a lo mejor... intel hace los pasos de una manera y SPARC de otra? Es que me cuesta entender cómo si en lo que a ellos les llega por ejemplo "leer dato, escribir pantalla, insertar dato", por ese orden... se pueda hacer de maneras diferentes... :-S ¿Acaso soy muy tonto?

No, no eres tonto, la informatica es un negocio y cada empresa quiere imponer su metodo de hacer las cosas. Es como preteneder que todos los motores de los coches sean iguales. Sería algo muy lindo para los mecanicos, pero es casi imposible de que pase.
Tené en cuenta que el micro es algo muy complejo, tiene registros, buses, cache etc. Cada uno es un mundo, y cada empresa hace instrucciones especificas para su arquitectura.
Supongamos las instruccion ensamblador ADD, esta en casi todos los micros, pero cada uno la implementa de forma diferentes y lee los datos y de lugares disntintos. (en los cisc se lee directo de memoria, y en los risc solo desde registros por dar un ejemplo a la ligera) Asi que no puedes esperar que esa operacion tenga resultados iguales en todos los ambientes.

Escrito originalmente por escufi
Me gusta este hilo.

Respuestas escuetas

sobre todo eso, escuetos a mas no poder

Escrito originalmente por escufi
LAs diferencias radican en la traduccion a ese ensamblador o a codigo maquina, puesto q una chorrada tan simple como mover un dato de memoria a registro se traduce en lenguaje de microinstruccion en una tira de 1 y 0 q permite a la ALU ( unidad Algoritmico logica) y todo su chipset saber q tiene q hacer con esa instruccion.

Lo de la microinstruccion sucede en realidad en la Unidad de Control en vez de en la ALU, ya que esta ultima solo se encarga de operar con los datos, no de coordinar todo el tema. De todas formas creo que es mejor no empezar ahora a destripar los micros porque InDeeD empezo queriendo saber cosas a nivel general y a este paso acabamos diseñando uno y todo


Saludos!

Escrito originalmente por sergiox
Juas Raulex hemos respondido los dos la misma cuestion!!! jajaja

Si, eso me temo

Escrito originalmente por sergiox
De todas formas creo que ambas son complementarias.
salu2

Nunca esta mal tener varias explicaciones por si en alguna no te ha quedado claro

Saludos!

Uffff... madre miaaaaaaaaaa...
como me pongan un examen sobre procesadores... de 10 parriba

una duda (mas curiosidad k duda...) porke se toma como base el ¡386 y no el ¡286, por ejemplo... hay un gran salto del 286 al 386??¿?¿? en ke?? supongo k visto lo visto sera en el nº de instrucciones capaces de procesar (ojo, las k entiende, no su velx al procesarlas...)???

ayudaa

otra cosa... esto no es exactamente sobre micros pero...
en teoria, la distro de Debian linux para el micro SuperH de Hitachi... rularia en una DC no??¿?¿?
lo haria pelo o com?¿?¿
esto es simple curiosidad

Escrito originalmente por Retroakira
Uffff... madre miaaaaaaaaaa...
como me pongan un examen sobre procesadores... de 10 parriba

una duda (mas curiosidad k duda...) porke se toma como base el ¡386 y no el ¡286, por ejemplo... hay un gran salto del 286 al 386??¿?¿? en ke?? supongo k visto lo visto sera en el nº de instrucciones capaces de procesar (ojo, las k entiende, no su velx al procesarlas...)???

ayudaa

Si, basicamente porque el 386 fue un salto grande y fue el primer procesador de intel que empezo a tratar seriamente el tema de la memoria protegida (el 286 lo hacia pero de forma mas amateur). Se acuerdan del modo real (los famosos 640kb) y el modo protegido? Bueno es eso, el 386 permite trabajar en modo protegido direccionando teoricamente hasta 4gb de memoria ram. (el modo protegido es lo que permite el multitasking de los sistemas operativos actuales en donde cada programa tiene su espacio de memoria privado)
Esta explicacion es DEMASIADO general, es un tema bastante profundo hay libros enteros sobre ello. Pero la base es esa. Si quieren profundizar pueden conseguirse algun libro sobre sistemas operativos (yo tengo el de Tanenbaum) o alguno de arquitectura de computadores si les interesa mas lo "duro".

otra cosa... esto no es exactamente sobre micros pero...
en teoria, la distro de Debian linux para el micro SuperH de Hitachi... rularia en una DC no??¿?¿?
lo haria pelo o com?¿?¿
esto es simple curiosidad

Si esta todo compilado para SH4 que creo era el micro de la DC, teoricamente tendria que ejecutarse... y digo *ejecutarse* y no correr porque son cosas diferentes. Ya que la DC implica un monton de configuraciones especiales... vamos que es una arquitectura especial. Una computadora no es solo un micro.
Hay una distribucion hecha especialmente para DC busca en google si te insteresa el tema.

salu2

Escrito originalmente por InDeeD
A vé... lo de la compatibilidad hacia atrás, y los niveles de programación lo entiendo perfectamente, al igual que lo que es un compilador y toda es clase de cosas (que aunque sólo lleve 3 meses de 1º de informática... algo he aprendido...).

Vete haciendo la idea de que en la carrera mucha teoría pero poca práctica.

Ya todo ha quedado mucho más claro. Es que de hardware todavía no he dado nada, y menos de la relación hardware-software...y weno, com yo me meto en todos los berenjenales... pos hago que os metáis vosotros también .

Tampoco creas que vas a dar mucho.

No sabía (auqnue ahroa que lo pienso parece muy lógico) que se programara igual para todas las plataformas, y que tan sólo cambiara el compilador, dependiendo de la plataforma donde se ejecute.

Hombre no es lo normal, pero generalmente en los programas para Linux se suele hacer.

Sobre lo de compilar según tu procesador (como se hace en gentoo por lo visto), ¿es muy difícil?¿qué nivel de programación hace falta?

No tranquilo el emerge lo hace todo y tu solo tienes que poner unas cuantas variables de entorno.

Escrito originalmente por Briareos_H
Lo que comentas de 32/64 bits es la cantidad de datos que ocupa cada instrucción. En el caso de los procesadores x86, son de 32 bits de momento, y AMD está a punto de sacara la família hammer de 64 bits. Contra más grande sea el tamaño de instrucción generalmente más potente es la cpu, pero eso sólo es uno entre muchos factores...

Ahí has metio la pata un poco

Lo que son de 32 bits son los registros del procesador. De hecho los Itanium de Intel que son de 64 bits manejan instrucciónes de 128 bits (realmente son 3 instrucciones comprimidas pero eso es otra historia )

Escrito originalmente por Retroakira
una duda (mas curiosidad k duda...) porke se toma como base el ¡386 y no el ¡286, por ejemplo... hay un gran salto del 286 al 386??¿?¿? en ke?? supongo k visto lo visto sera en el nº de instrucciones capaces de procesar (ojo, las k entiende, no su velx al procesarlas...)???

Todo cambio de arquitectura implica que soporta más instrucciones para así acelerar un tipo de cosas que se utilizan actualmente.

Aparte de lo que ha dicho raulex, el salto del 286 al 386 implicó el salto de los 16bits a los 32 bits con todo lo que ello conlleva

Escrito originalmente por NetVicious

Aparte de lo que ha dicho raulex, el salto del 286 al 386 implicó el salto de los 16bits a los 32 bits con todo lo que ello conlleva

Muchas gracias a los dos, una de las ideas k me rondaba por la cabeza era precisamente esa, la del salto a los 32bit... pero no taba seguro

Escrito originalmente por NetVicious

Ahí has metio la pata un poco

Lo que son de 32 bits son los registros del procesador. De hecho los Itanium de Intel que son de 64 bits manejan instrucciónes de 128 bits (realmente son 3 instrucciones comprimidas pero eso es otra historia )

Completamente cierto. Ay dios mio, y el martes que viene exámen de arquitectura de computadores La verdad es que estas cosas es lo típico que uno tiene el conceptillo pero no tiene la definición clara... weno asias net por la aclaración.

salu2

oye no hay un hilo sobre hardware? jejeje Perdonad por mis cagadas pero a medida q iba contestando sabia q me iba equivokando un poco. A ver Teoricamente se de q hablo pero a veces es dificil expresarse por post ( no hay nada como la comunicacion cara a cara).

Si quereis conocer muy a fondo la arquitectura x86 y las caracteristicas de los procesadores de Intel aqui os dejo una pagina x86.ddj.com
Otra cosa, espero que me saqueis de una duda:
estoy cansado de oir de que los procesadores de 64 bits son mas potentes que los de 32 porque son capaces de mover mas informacion y no se que otras historias. Por lo que he aprendido de procesadores si un micro es de 32bits significa que el tamaño de sus registros de proposito general es de 32bits, ¿no? Pero eso no significa que el tamaño del bus sea de 32bits. Corregidme si me equivoco, pero hay procesadores de 32bits cuyo bus es mcho mayor. Sin ir mas lejos, el PowerPC G4 es un procesador de 32bits que creo que cumple esto que yo digo (bueno, aparte de otras lindeces como una FPU con registros de 128bits).
Bueno pues eso, corregidme si he metido la gamba hasta el fondo.

Salu2

Sip, un simple pentium 1 ya tenía el bus a 64 bits, por eso los módulos simm se tenían que poner de 2 en 2.

salu2

Jue... ya con lo de los bits me he empezado a perder un poco... pero bueno, buscaré por ahí si no.

Sobre la compilación... ¿hasta qué punto se puede configurar Debian para 686?

Gracias a todos. Me encanta este hilo, jeje!

Salu2!

Escrito originalmente por InDeeD
Sobre la compilación... ¿hasta qué punto se puede configurar Debian para 686?

Te bajas los fuentes con apt-get source y los compilas con dpkg-buildpackage (o mejor con el script apt-build).

y el gcc y lo demás?

Lo que quiero saber es si se puede optimizar debian para multimedia, tanto como mandrake y similares...

Vamos, que si... a pesar de ser debian, puedes poner TODO lo último y compilado para tu máquina, .

Salu2!

Si claro, casi todo lo último está en SID aunque ello igual conlleva algunos problemas de estabilidad, ya que en SID están casi siempre las últimas versiones de los programas, las cuales pueden ser betas y tener errores. Es el precio que hay que pagar por estár a la última

Yo uso testing y tengo algunos paquetes de SID (por ejemplo las XFree 4.2).

Peazo hilo
Y ya que veo que habeis tratado el tema de procesadores 32, 64 bits , me gustaria preguntar una cosa.
Es cierto eso que dicen que el Hammer de 64bits es capaz de trabajar perfectamente con aplicaciones a 32bits? Oh es que me he hecho una rallada mental.
Gracias.

A ver, los Itanium NO son x86 de 64 bits, su arquitectura se llama IA-64, la cual es TOTALMENTE incompatible con las aplicaciones actuales (que son x86 de 32 bits), por tanto si haces trabajar a un Itanium con las aplicaciones actuales su rendimiendo cae en PICADO.

Los Athlon 64 y los Opteron son x86 de 64 bits, es decir la x86 de 32 bits actual ampliada para utilizar registros de 64 bits, por lo que las aplicaciones actuales de 32 bits funcionarán igual o incluso mejor que con los procesadores actuales.

Interesante
Gracias por la info
Osea, de mayor Hammer

Escrito originalmente por Briareos_H
Sip, un simple pentium 1 ya tenía el bus a 64 bits, por eso los módulos simm se tenían que poner de 2 en 2.

salu2

Que alguien me corrija si me equivoco, pero yo siempre pense que en los pentium los modulos se ponian de 2 en 2 siendo ambos de la misma capacidad pero porque eran modulos SIMM.

Con la memoria edo pasaba eso, que habia que cuidar la paridad, pero antes de que saliese la edo habia otra que no cuidaba esa paridad, y esa era para 486 y anteriores. A partir que saliese la DIMM (o sdram, como yo la he llamado siempre) no hay tal problema y la puedes poner de 1 en 1, pero porque es DIMM, de hecho yo tengo ahora mismo una unica pastillita de esas

Briareos, yo creo que lo de poner la memoria de 2 en 2 no es por la arquitectura del micro, sino porque la memoria es SIMM y tiene esa restriccion. De todas formas ya mirare un libro que tengo si acaso

Saludos!

Escrito originalmente por cybercar
Es cierto eso que dicen que el Hammer de 64bits es capaz de trabajar perfectamente con aplicaciones a 32bits? Oh es que me he hecho una rallada mental.
Gracias.

Personalmente no conozco los Hammer, pero voy a comentar eso que dices de forma general

Un micro de 64bits puede trabajar con aplicaciones de 32bits, pero al reves no. Es algo asi como decir "si puedes trabajar con centenas, puedes trabajar con decenas", pero no al reves. Si trabajas con centenas esta claro que una decena "cabe", pero si quieres meter centenas en espacios de decenas no siempre podras hacerlo, porque cuando hayas superado el numero 99 la has liado.

Si el ejemplo es malo, esto no es totalmente cierto o alguien desea corregirme, tened en cuenta que tengo resaca


Saludos!

Escrito originalmente por RaUleX

Que alguien me corrija si me equivoco, pero yo siempre pense que en los pentium los modulos se ponian de 2 en 2 siendo ambos de la misma capacidad pero porque eran modulos SIMM.

Con la memoria edo pasaba eso, que habia que cuidar la paridad, pero antes de que saliese la edo habia otra que no cuidaba esa paridad, y esa era para 486 y anteriores. A partir que saliese la DIMM (o sdram, como yo la he llamado siempre) no hay tal problema y la puedes poner de 1 en 1, pero porque es DIMM, de hecho yo tengo ahora mismo una unica pastillita de esas

Briareos, yo creo que lo de poner la memoria de 2 en 2 no es por la arquitectura del micro, sino porque la memoria es SIMM y tiene esa restriccion. De todas formas ya mirare un libro que tengo si acaso

Saludos!

A ver, si usas un pentium 1 con memoria dimm, no necesitarás más de un módulo, pero porque la dimm es de 64 bits y el pentium 1 también, en cambio los módulos simm eran de 32, por eso necesitabas poner los módulos a pares. Tendría que haber especificado las dos cosas

salu2

Aprovecho para decir también, que por ejemplo las placas nForce 2 (y creo que las nForce 1) soportan bus de doble canal a la memoria RAM de 128 bits, por lo tanto para tener estas prestaciones necesitas poner lo módulos de 2 en 2, es lo mismo pero para el doble de ancho de banda de bus.

Eso sí, que yo sepa todos los procesadores x86 actuales siguen siendo de 64 bits de bus, corregidme si meto la pezuña

salu2

Escrito originalmente por NetVicious
Si claro, casi todo lo último está en SID aunque ello igual conlleva algunos problemas de estabilidad, ya que en SID están casi siempre las últimas versiones de los programas, las cuales pueden ser betas y tener errores. Es el precio que hay que pagar por estár a la última

Yo uso testing y tengo algunos paquetes de SID (por ejemplo las XFree 4.2).

Y se notan las XFree 4.2.1 con respecto a las 4.1?

PD: Las XFree4.2.1 están tambien en testing.....


Saludos

Hombre no he notado mucho cambio, tal vez un poco en velocidad

Y lo de testing jeje, yo las bajé de SID en cuanto las colgaron, cuando llevan 10 días en SID sin fallos las pasan a testing. Yo las X 4.2.1 las tengo ya más de 3 meses puestas

Escrito originalmente por RaUleX
Un micro de 64bits puede trabajar con aplicaciones de 32bits, pero al reves no.

No siempre, como he dicho los Itanium no son arquitectura x86 y por tanto si los pones a ejecutar x86 de 32 bits lo tienen que emular y su rendimiento cae en picado.

buabua... cuantos post hay... iba a contestar a algunas preguntas pero veo que ya habeis respondido de sobras...

Pero en cuanto a lo de los 64 bits una aclaración:

La arquitectura de los Intel Intanium (I y II) es totalmente diferente a las de la familia x86... y cualquier software construido para estos ensambladores de 32 bits no es ejecutable... Bien podriamos decir que algunos programas funcionan, pero porque estos no son ejecutados totalmente de forma directa por el procesador sino que son interpretados por el sistema operativo (vease Linux o el .NET) y por asi decirlo, "lo emula sin necesidad de emulador"... estan implementando tecnicas de interpretación de la misma manera que lo hace un interprete de JAVA pero a lo grande (directamente interpretan ensamblador y no lenguaje intermedio!!!). Pero esto tiene limitaciones y no todas las aplicaciones existentes (de 32 bits) funcionan... y se ha de recurrir a la emulación, cosa que es más lenta todavia.

Es por eso, que los del proyecto MONO tienen tanta prisa en portar la especificación del C# a LINUX: los programas en C# funcionan en cualquier maquina que tenga un interprete de este (como JAVA) pero además... a una velocidad proxima a la de C.

Por eso mismo es por lo que todavia no disponemos en las tiendas (de forma abierta al publico medio) de maquinas Intel de 64 bits... para no crear mas controversia sobre "vale la pena migrar el usuario medio a 64 bits?"

Saludetes

Uno de los posts mas intesesantes que he leido por aqui en mucho tiempo