#303 Una es el uso ( programar en el ), que es necesario en ciertas situaciones, aunque % bajo, y otra es que te hace ser mejor desarrollador en lenguajes de mayor nivel.
#282 Usarlo, por ejemplo, en un proyecto que estoy haciendo yo ahora: un depurador ( software para ejecutar un programa paso a paso o de forma controlada y poder ver como fuinciona e incluso alterar su curso, etc. ). Este depurador, necesita engancharse a ciertos eventos de interrupcio o excepciones ( rutinas de dar servicio a interrupciones, en este caso no tanto de servir eventos de hardware sino interrupciones de eventos del propio procesador, como int3 para breakpoints software o int1 para eventos de ejecutar una sola instruccion y parar, lo que se conoce como "singlestep", etc. ). Bien, estas rutinas, y mas para el caso de un depurador, donde debes ser inocuo para el curso del programa que esta ejecutandose o estas depurando, debes controlar muy bien lo que ocurre cuando se producen esas excepciones, guardar el estado de todos los registros maquina, quiza ponerte en un estado favorable con mas pila, etc. Ahi usas rutinas en ensamblador. Desde esas pequeñas rutinas, pasas la ejecucion a algo en C, por ejemplo y ya en C, de forma comoda, pues pones la interfaz del depurador, etc. muestras el estado de registros que esa rutinita de excepcion hecha en ensamblador te ha guardado, permites si quieres modificar esos valores, sacas el codigo fuente a partir de donde apunte RIP ( puntero de instruccion o "program counter" ), etc. Lo que hace un depurador, vaya. Despues, cuando el usuario pide continua la ejecucion del programa, esa rutina hecha en C retorna y el control vuelve a esa rutina en ensamblador, que, otra vez con mucho cuidado, restaura el estado de los registros de la maquina ( tal cual se guardaron al entrar la excepcion, fuera un int3, un int1, o lo que sea o, si el usuario cambio alguno a proposito en esa interfaz hecha en C, pues restauraria todos menos los que el usuario ha cambiado ).
Y bueno, las entradas a syscalls o peticiones del sistema y demas, muchas cosillas asi, se hacen en ensamblador, no por optimizar, sino por tener 100% control de la maquina, cosa que un lenguaje, incluso tan a bajo nivel como C, no te permite. Si, hay lenguajes con cosillas hechas adhoc para estos casos, pero estan hechas para un conjunto de situaciones ( ejemplo: Rust ), no para todas, cosa que el ensamblador si te da.
#27 Bueno, por la diferencia de los sets de instrucciones de ps2 vs x86 moderno frente a ps3 vx x86 moderno, que si se parecen mas las instrucciones de los SPE de la ps3 con las instrucciones vectoriales de un x86 ( sea con SSE, sea con AVX ). Pero la velocidad de dichas instrucciones, la velocidad del tipo de RAM, los buses, etc... la ps3 exige bastante mas. Si el tiempo de ejecucion de la emulacion no es un factor, todavia, si no... no se
#17 Y quien decide cuales si y cuales no ? eso es CENSURA. ¿ Que hay algo que consideras panfleto ? No lo consumas, deja que la gente decida. O que pasa, ¿ que tenemos miedo a la libertad ?
#268 Si, se nota que te gusta. Yo me se muchos opcodes de instrucciones por que los veo dia a dia, no es que quieras aprenderlos, es que los memorizas sin querer.
Es una mezcla, las capas medias o altas acceden en general a capas mas bajas, pero hay excepciones. Aunque si, UEFI esta pensado para ser relativamente portable, la parte PEI ( Pre-EFI Initialization ) no, pero la parte DXE que viene despues y es bastante mas tocha, si. Incluso hay binarios compilados a lo que se conoce como EBC ( EFI Byte Code ) que son compatibles no ya a nivel de source sino a nivel binario. Ahora, esto es "on paper", luego... bueno, medio medio.
EDIT: E9 XXXXXXXX ( relativo de 32bit con signo que se suma al EIP o al RIP -extendido con signo- actual; nota: el EIP/RIP esta apuntando a la siguiente instruccion cuando la instruccion actual se ha decodificado y pasa a ejecutarse ). EAX como tal no es un solo opcode, son una combinacion de 3 bits en diferentes codificaciones de instrucciones, en las de acceso a memoria normales serian 000b en la parte ModRM, pero segun que tipo de instruccion toma parte de forma algo diferente.
#78 Los politicos Y EL FEMINISMO IMPERANTE, no escurras bulto.
Y lo que dices del marxismo, tan manido ya "es que eso no era marxismo de verdad". Venga por favor, ¿ hay que volver a explicar eso otra vez ? No convenceis a nadie que no estuviera convencido ya, ya me entiendes.
#9 totalitarismo ese que dices que, curiosamente, el feministeo imperante, "olvida" y no gasta para el ni un 1% de las energias que gasta para otras cosas, turbas incluidas.
#1 Lo estoy viendo, ya lo dije ayer, esto ya esta pasando en Canada, EEUU y no se si Suecia y mas sitios tambien. Estos van a empezar con los "unconscious bias trainings/tests" y a obligar a pasar por el aro ( aunque sea haciendo teatro ) a toda una serie de funcionarios y, quien sabe, quiza gente del ambito privado. No se si se obligara, los curriculos en ciertas carreras de humanidades y, en menor medida aunque igual de sectaria y dañina en la educacion infantil, ya se esta "obligando". Pero puede que sea con cosas "sutiles" como poner diferencias a subvenciones/ayudas ( que igual lo suyo es revisarlas, que muchas son mamoneo ), negandolas si no pasas por esos trainings y demas.
#246 A ver, que precisamente lo que digo en #98 es que el ensamblador no se usa por optimizar, que eso es falso a dia de hoy, o una verdad muy a medias. Ensamblador se usa pa cosas que requieren usarlo. Y saber ensamblador, mas que usarlo, saber, es conveniente para programar mejor y es necesario para cierto tipo de desarrollo de software.
#242 Uff, a ver a ver, la gran mayoria de drivers y sobre todo firmware de hoy dia, son instrucciones de procesadores, no son logica programada. Las microcode updates de los procesadores, si, aunque no se conoce muy bien por que son cerradas y bien cerradas, pero se asume que son tablas de logica programada. Pero es que eso representa muy poco % del firmware. Hoy dia, ademas, el firmware, por ejemplo en PC con UEFI, es 95% C, si, de bajo nivel ( no todo tampoco, hay mucha programacion tipo sistema operativo ) y tal, pero vamos, software normal y corriente.
A lo que te refieres en tu segundo parrafo, en UEFI, serian los PEIM de la fase PEI, muy poco % de todo el UEFI, que son eso, tocar bits en chips concretos para enrutar ciertas cosas fisicas a logicas ( no habla de paginacion ni nada de eso, sino de addressing PCI, puertos,... ), encender partes del chipset como el LPC ( Low Pin Count, bus donde se conectan las cosas viejas/lentas de un PC ), inicializar la DRAM ( inicialmente el procesador usa cache as ram, no puede acceder a DRAM hasta cierta fase, muy inicial ), etc. Pero eso, esto es muyyy poco codigo.
Pufff... comparar nazismo con marxismo, madre mia. Y se echan en falta las necesarias referencias, con las que ya no habria lugar a dudas y confusiones, de Socialismo PRUSIANO y de Oswald Spengler, aunque tampoco eran del todo afines, pero joder, ESE es el socialismo que querian los nazis, nada que ver, salvo quiza en lo militar y dictatorial, con las dictaduras marxistas.
#189 Hay unos cuantos de internals, algunos de ellos ya no valen, han quedado obsoletos. Las fuentes de NT4, W2K y W2K3 Server ( version WRK ) se han mirado algunas veces y bueno, esta bien, pero hoy dia no te ayudan mucho ( segun para que ). Tambien esta ReactOS, que bueno, mas que pa alguna cosilla... lo que vale es depurar y desensamblar.
#180 Bien, si, ya habia googleado ambas :). Pero bueno, en NT cuando un driver o el SO casca, tienes que buscarte la vida. Por supuesto una vision analitica y tu codigo a veces son suficientes o al menos te ayudan a acotar la cosa, pero hay que meterse al barro, mucho.
#155 No conozco apenas los *BSD, mas alla de haber instalado y trasteado algo con FreeBSD en su dia. Similar con linux, que he usado Gentoo Linux pa algunas cosillas y algunos desarrollos y tal e incluso para uso general, pero bueno, no son mi campo.
Supongo que pledge y unveil son una vuelta de rosca mas alla de los jails y demas, interesante.
Lo de las syscalls que dices, supongo que es por separar y simplificar para empequeñecer la superficie de error/ataque.
Yo soy desarrollador de drivers, pero orientado a temas de seguridad en NT. En cuanto a proyectos personales, hago cosas de bajo nivel de NT y tambien en UEFI, aunque bueno, arranco en UEFI pero manipulo la carga del SO ( NT, pero puede ser cualquiera ) y otras cosas. Saber ensamblador no es que ayude, es que sin ello no llegaras muy lejos.
#109 apetor 
