Foro de elhacker.net

De antemano digo, esta es una pregunta netamente teórica
Cuando hablo de que es programar no me refiero al concepto sino cuál es su procedimiento que hace que funcione. ¿Cómo se programa un hardware desde cero?
Me explico: suponiendo que yo fuera un multimillonario y quisiera desperdiciar mi dinero desarrollando un sistema operativo desde cero el cual no tenga como base a MS-DOS, UNIX, LINUX o cualquier otro que se les ocurra... Que debo conocer para realizar este proyecto en caso de que fuera así. Como se crea el kernel, el lenguaje de programación, el hardware y como se fusionan para que funcionen. Y por ultimo en caso de que esto se llevara a cabo por alguna empresa u organización, ¿este nuevo sistema sería mejor que los ya existentes ya que en la actualidad contamos con mas tecnología?

Diu, en España son las 8 am namas jejeje pero mola, mola la pregunta. Reiventar la rueda desde cero. Quizá se podría hacer un lenguaje de programación sin buffer overflows. Aunque a muchos no les gustaría xD. No tengo ni idea en realidad...

Para programar "desde cero" sobre un hardware, deberías de usar el lenguaje nativo que use ese hardware. Normalmente ensamblador que es el "lenguaje natural" de los microprocesadores.

Pero nadie va a hacer eso, puedes usar un lenguaje como C sobre otro sistema operativo para escribir uno nuevo compilandolo.

Por ejemplo buena parte de Unix se escribió inicialmente en ensamblador, pero una vez que las herramientas disponibles fueron las adecuadas, se reescribió en C

Los lenguajes de programación son herramientas para crear código que se ejecute sobre una determinada plataforma y hacer que su paso a otras plataformas sea mas sencillo. Es posible crear un SO desde cero usando ensamblador, pero por cuestiones de eficiencia esto es raro que se haga, excepto para nuevos procesadores donde lo que se hace es facilitar el uso de otros lenguajes y desde ahi seguir desarrollando

Pero vamos, el lenguaje "básico" a nivel de hardware es el ensamblador, o mas correctamente el código máquina. Ambos son "lo mismo" pero el ensamblador usa mmemonicos en lugar de las instrucciones nativas para una mayor facilidad

https://es.wikipedia.org/wiki/Mnem%C3%B3nico

Si uno fuera multimillonario, lo que haría sería diseñar el mismo hardware, eso te libera de entrada de tener que amoldarte al hardware. Puedes además potenciar aquellas áreas donde uno cree que se necesite más énfasis...
..yo por ejemplo no le veo mucho sentido a tener una CPU por un lado y una GPU por otro. Creo que una buena CPU debería hacer innecesario disponer de una GPU.

Cuando diseñas el hardware, tú mismo al hacerlo, esás formalizando como será el ensamblador de ese hardware. Siempre se parte de la CPU, luego se puede rediseñar el resto del hardware o reutilizar lo ya existente. Por ejemplo cosas como la memoria, quizás no valga la pena molestarse en rediseñarlas, pero las BIOS, están pidiendo a gritos que sí... La propia BIOS debería ser un mini Sistema Operativo en sí mismo, no solo para la configuración hardware del equipo si no para hacer operaciones básicas de lectura y escritura sobre unidades de almacenamiento, eso implica que el propio BIOS entonces deberia alojar algún que otro driver...

Una vez se tenga el hardware listo, el diseño del software, el S.O. depende de lo que quieras que haga y el hardware permita. Básicamente considera que todo lo que el hardware no tenga de fábrica, rediseñado en software será siempre hackeable.

El Kernel, debes considerarlo como el 'bucle principal de trabajo' del sistema operativo, así que deberá tener asignadas funciones como la distribución de tareas, la compartimentación de la memoria, la atención d eprioridades, la seguridad, etc... El diseño de ello parte más d elas ideas propias que uno tiene sobre como debería ser, que sobre imitar lo que otros ya hacen. Básicamente si tratas de imitar lo que haga otro S.O. es fácil que acabe siendo mucho más lento. cuando tienes un diseño particular ya pensado, suele estar diseñado junto a otras partes que hacen que el 'todo' sea algo mucho más sólido y funciones con mucha más eficiencia (imagina la diferencia entre el motor de un coche donde cada pieza es diseñada sola, pero teniendo presente las características del resto de piezas, sus tamaños y la posición que ocupan, con abrir un motor y pretender encajar ahí ahora una pieza para que haga algo nuevo que no tenía en diseño).

El lenguaje de programación, es independiente... quiero decir que se pueden diseñar tantos como se desee y la forma en que trabajen sucede lo msimo, piensa que lo único preciso es el compilador, que de una forma u otra lo que hace es como se ha de traducir el código de dicho lenguaje al ensamblador que entienda ese hardware. el ensamblador en última instancia es también un lenguaje intermedio, que se traduce a binario, pero ya de una forma 'natural', es decir los lenguajes ensamblador, también pueden ser rediseñados. Es lo que se llama "codificación de instrucciones", por ejemplo pueden dedicare 2 bytes para el código de operación, otros 2 bytes para especificar el modo de dirección y registro y otros bytes adicionales cuando por ejemplo se reciben datos inmediatos (que pueden ocupar 1,2,4,8 bytes extras)...

En el diseño hay que decidir y definir que conjunto de instrucciones se abordarán e incluso el tamaño de bits de los buses. 8,16,32,64,128 ???. Fácilmente se ve que si admite esos tamaños, al ser 5 variantes, solo para especificar el tamaño se precisan 3 bits. Por supuesto esto es aparte de la diferenciación en las propias instrucciones y por tanto uno podría llamar Mov a todas lasinstrucciones de transferencia de datos, o llamarla Mover o llamarlas individualmente según el tamaño de bytes que se muevan del origen al destino, por ejemplo:
MovL0 EAX,EBX
MovL1 EAX,EBX
MovL2 EAX,EBX
MovL3 EAX,EBX
Podrían estar diciendo que solo se mueve 1,2,4 u 8 bytes (los más bajos de EBX a EAX)
La alternativa MovL0 EAX,EBX lo sería de la actual Mov al,bl,
Fijándose como la decisión afecta solo al diseño externo del lenguaje ya que la 'codificación de la instrucción' al final seguramente serían idénticas, y la elección de una u otra manera, podría por ejemplo simplificar cometer menos errores y detectarlos más fácilmente, a cambio de tener una tabla de instrucciones visiblemente más larga, frente a una tabla de instrucciones más reducidas (pero más compleja) y sujeta a una mayor dificultad de aprendizaje y resolución de errores...

Por último, no veo a donde quieres ir con eso de"¿este nuevo sistema sería mejor que los ya existentes..?" A qué nuevo sistema te refieres?. Que yo lea, no has definido nada nuevo, solo plantes la hipotética posibilidad de hacer algo, sin especifcar cómo ni qué... en cualqier caso, la respuesta a ello es Depende. Depende de qué se haga, depende de si la idea en la cabeza finalmente es posible hacerse y se hace o si al final se trunca y se hace otra cosa distinta.

En general una vez que se ha definido bien un sistema podría establecerse dado su rendimiento, si mejora algo y en qué areas o no a lo ya existente. La potencia d elos actuales procesadores, recáe básicamente en 3 cosas: la velocidad de ejecución, el procesado en paralelo y la miniaturización alcanzada... cada una está interrelacionado con el resto. La velocidad de ejecución también depende de la miniaturización, cuando más pequeño sea el proceso de estampado del chip, más cerca estarán los componentes, menos distancia recorrerán y por tanto antes llega la señal eléctrica a su destino. cuantos más millones de puertas tengas, más posibilidades de procesador en paralelo hay de poder resolver más de una instrucción a la vez, la cantidad de pertas también dependerá de la miniaturización, la disipación de calor suele ser un problema constante, cuanto mas pequeños, menos calor emite cada una y cuanto menos calor individual, menos acumulado en total y por tanto pueden añadirse más componentes hasta un límite aceptable, a su vez cuantos más haya y más puertas concurran para realizar una o un grupo de instrucciones (no necesariamente siempre cieto), más veloz resultará.

El procesado en paralelo se ha resuelto muy bien con los múltiples cores, pero también se llega a un cuello de botella por la ineficiencia al concurrir todos a la vez a la memoria, por eso más de un core dedicado a la misma y específica tarea (en general del mismo proceso del mismo programa), suele implicar acceder a la misma área de memoria que queda bloqueada y por tanto compiten por su acceso de lo que resulta inefectivo... es más eficiente (para el procesado general), que cada núcleo opere sobre una tarea distinta, así es más probable que no se pisen y bloqueen en el acceso a memoria.

En defnitiva... como te decía que un sistema sea mejor o no que otro, debe como mínimo ser teorizado en todos sus detalles, simplement ediciendo que 'si hago algo nuevo', es insuficiente para decir nada que no suene prepotente, ya que se estaría adivinando como será algo, sobre lo que nadie sabe nada.

Ahora si tu pregunta fuera: ¿pueden mejorarse los sitemas actuales con un nuevo rediseño sea del software o del hardware?. La respuesta es sí en ambos casos... ya que todos los sistemas actuales arrastran con su legado, que es un pesado lastre.
Puestos a apostar, yo lo haría por un hardware nuevo con un software nuevo... para superar límites estúpidos, resolver problemas de segurdiad desde el hardware y mejorar muchos aspectos en todas las áreas...

no... las gpu y cpu no funcionan igual, no procesan el mismo tipo de calculo de la misma manera, sin contar que un gpu actual (GTX 1080i) no funciona como 4 nuecleos @3Ghz , sino como 3584 nucleos @1,4MHz ... por otro lado los calculos no están priorizados igual, los que la gpu hace en un ciclo, no necesariamente lo hará la gpu, por sus distintas naturalezas de uso, no puedes sustituir uno con otro e integrar los 2 en una sola capsula tampoco vale mucho la pena por el costo, consumo y calor, entre más seccionable el hardware mejor porque se puede adaptar mejor a necesidades y presupuestos

Creo que no has entendido a nuestro interlocutor... habla o más abre la posibilidad de diseñar nuevo...
Nadie habla de ser igual a... hablamos de diseñar algo nuevo... y según tú, acaso no se puede hacer que exista una y solo una CPU que acometa todas las tareas que se requieran sean gráficas o de cálculo?... Siempre se podrá consturir un chip nuevo y aislar en él la seguridad, pero actualmente está integrada en la propia CPU... y si un día se separa, va a resultar que ya será imposible reintegrarlas de nuevo?.

Que las GPU actuales tengan problema de disipación de calor es otra historia y tiene que ver con el diseño y sobretodo ambición del fabricante... Limitación en cuanto diseño, no lo tiene.

no es eso, es que se trata de mucha potencia junta (el consumo del procesador en Watts es directamentr proporcional al calor liberado, y por la naturaleza de la gpu a demás libera más calor) esa es una de las razones por lo que los cpu se han limitado en potencia y tamaño...

si se puede diseñar algo nuevo, pero tambien sería diseñar toda la arquitectura de software y todas las nuevas teorías de uso a demás que se vean las limitaciones...

pero desde mi punto de vista que en un pc todo sea seccionable, que si incluso en lugar de tener nucleos, tuvieras procesadores independientes, mejor, porque implica que puedes adquirir más puntualmente potencia sobre presupuesto y adaptar a necesidades más puntuales

TYAN  S4992

(http://www.noticias3d.com/imagenes/noticias/200811/image.php.jpg)

Saludos.

El tamaño de las instrucciones y el tamaño de los buses es relacionar velocidad con tocino

El tamaño de las instrucciones normalmente está relacionado con el tamaño de los registros interno de la cpu. Si vas "a las bravas" y diseñas la CPU desde cero sin problemas de retrocompatibilidad de ningún tipo puedes ir a registros de 64 bits o incluso a dobles de 128 o lo que te parezca, pero los fabricantes no siempre tienen esa libertad

Es muy fácil decir "vamos a olvidarnos de todo y empezar con procesadores de 64 puros", siempre que no tengas que ofrecer a nadie compatibilidades anteriores.

Al margen de eso, lo procesadores no son solo de uso general, se fabrican con muchos propósitos y en realidad es el propósito quien determina la arquitectura que vas a usar en tu nuevo procesador. Si tu mercado es el industrial, el de telefonía, servidores, uso general, militar, etc... cada uno tiene sus requerimientos

si yo fuera un multimillonario y quisiera gastar dinero en software, pues haria como Mark Shuttleworth, me bajo un kernel de linux, contrato 1 edificio lleno de programadores y de ahí se inventa a ver que producto se le puede sacar una ganancia a nivel empresarial.

aunque es retrospectiva, preferería invertir mi capital en acciones de bajo riesgo el cuál es más seguro y menos costoso en terminos de sacrificar tiempo.

La potencia es la suma de todo, claro está, pero a medida que la industria progresa, la miniaturización va consiguiendo que lo que antes generaba un watio, ahora se requiere 10 veces más para alcanzar ese watio de consumo.
Es inaceptable la situación a la que se llegó aprox,. en el 2010, donde ya había tarjetas gráficas que demandaban fuentes de alimentación con 1000 watios. Al final, el precio de comprar un PC caro, no llegaría  a nada, comparado con el gasto mensual en la tarifa de la luz si (como muchos) el PC está encendido una media entre 8 y 24 horas al día...
Ahora después de 7 años, están anunciando que (con tecnología IExpress 4.0), consumirán menos, haciendo innecesario cables para conectarlos (las tarjetas gráficas) directamente a la fuente de alimentación.
Por otro lado, Intel (incluso AMD) cuando fabrican sus chips más consumistas, para ordenadores de escritorio esperan no sobrepasarse los 130 watios, cuando lo habitual ronda los 65w.
No les costaría nada, pero nada, fabricar procesadores 10 veces más potentes que una GPU, si tuvieran la seguridad que anque consumieran 800w. luego los clientes los iban a aceptar y pagar el precio de los procesadores y del consumo mensual de la tarifa de la luz.
Android (es una opinión mía particular, aclaro) ha sabido aprovechar muy bien su fecha de lanzamiento en los móviles justo en esa coyuntura con la elevada demanda de consumo por parte de las gráficas y que tiraban al usuario para atrás, en una fuerte apuesta por procesadores en la parte de os telefónos móviles (celulares).


Te recuerdo que en esas llevaba Intel desde el 2000 o así, con placas multiprocesador, hasta que a mediado del 2004, cambiaron a multicore. La razón?. que hacer múltiples cores, aunque sigue siendo un reto en lo que a compartir recursos se refiere, multiplica la capacidad de proceso, sin tener que requerir duplicar todas las estructuras del procesador, basta un multplexado de algunos buses y añadir una UAL (y sus estructuras consecuentes), por cada core extra y pelearse con la sincronización.
El resultado final es que un chip con 2 ó 4 cores, no cuesta el 2 o 4 veces más como sucederíoa con 2 o 4 procesadores, tampoco aumenta el volumen ni la cantidad de transistores x2 o x4, sino quizás por 1'2 y 1'5 para el 2 y 4 cores respectivamente.

Y por si sirve de algo, mi idea sobre los múltiples cores, difiere con cierta sustancialidad de lo que finalmente intel sacó (y el resto imitó)... en mi idea, entraba hacer varios cientos de cores, y debería ser bastante sencilla (aunque la pelea con la memoria sería igualmente inevitable), y deberia poder permitir redefinir el tamaño de buses desde fuera, siendo la suma de las salidas de cada core un único bus gigante, podría redistribuirse al gusto y necesidades diseñando un nuevo elemento cuya misión sería precisamente esa... (por ejemplo si finalmente la suma de cores, arrojara un bus total de 512bits,  podría repartirse de múltiples maneras, podría haber un bus de 512 bits, pero podría igualmente solicitarse 2 buses de 256bits, o 4 de 128bits, incluso 3 de 32 bits y 3 de 128, etc.... y sería mediante software tal decisión según el programa en ejecución lo demandara, esto es; sujeto a requisito y disponibilidad).

Por aquellas fechas (2004), intel también anunciaba memorias en 3dimensiones, pero por lo que se ve, aún no han logrado salir adelante con ellas.

---------------------------------------


O no lees, o lo olvidas pronto.
yo puse:
Es lo que se llama "codificación de instrucciones", por ejemplo pueden dedicare 2 bytes para el código de operación, otros 2 bytes para especificar el modo de dirección y registro y otros bytes adicionales cuando por ejemplo se reciben datos inmediatos (que pueden ocupar 1,2,4,8 bytes extras)...

En el diseño hay que decidir y definir que conjunto de instrucciones se abordarán e incluso el tamaño de bits de los buses. 8,16,32,64,128 ???.
De hecho, desde el 80386, las instrucciones se codifican exactamente con ese número de bytes: 2 para instrucciones, 2 para el campo MODRM + los bytes adicionales que pudieran requerir si hay un operando inmediato o de memoria.

Exactamente... es muy fácil, cuando se parte de la premisa que plantea Skynet: "suponiendo que yo fuera un multimillonario y quisiera desperdiciar mi dinero desarrollando"


...????

Dejen de opinar cualquier cosa.

Programar es escribir codigos y disenar un formulario para que se forme un programa a partir de eso.

Programar funciona de la siguiente manera con el sistema informativo:

Tu escribes un codigo que el sistema operativo entienda. Por ejemplo en C#, Delphi, Java

Es evidente que necesitas aprender bastante sobre el tema, además de tener un poco de humildad.

Saludos!

Pues por lo que yo entendí:

UX
----
Programar (alto nivel)
----
Programar (menos alto nivel) {este se repite tanto como quieras}
----
Sistema operativo (programa)
----
Programar ASM en función del Sistema Operativo (las instrucciones varían según el SO)
----
Hardware


Y luego puede haber puentes. Que comuniquen las distintas capas.


Seguramente no esté bien explicado... Y tampoco sabría hacerlo de 0 ni vamos....