Thumb, que no es un ISA RISC, se creó por las ventajas que tenía de densidad mayor de código y que beneficiaba especialmente a entornos donde había menos memoria o esta se conectaba externamente con un ancho de 16 bits en lugar de 32. No es un paso atrás, cubre unas necesidades, además de que en los ARM normales es simplemente un ISA opcional, no el único (sí es el único en los ARM M, pero no en los otros que tienen ambos ISA) y puedes conmutar entre ambos.
Para mi no cubria una necesidad, yo lo vi como un simple truco de marketing. Yo trabaje con los ARM embedded originales como el LCP11 que usaba ARM32 y no tuve ningun problema...en aquella epoca la gente de embedded estaba obsesionada con el tamaño del binario porque venian de trabajar con bichos minusculos con cuatro transistores. Los ARM embedded estrenaban una epoca en la que ese tema ya no era tan importante, si te quedabas corto de flash ponias un par de euros mas y te subias a la MCU siguiente.
A mí me gustan los RISC, pero Thumb (que no es RISC) me parece fácil de aprender por lo sencillo y poca cantidad de instrucciones que tiene, frente a lo que es un procesador de ordenador grande modernos, que tiene cientos y cientos de instrucciones y extensiones. No puedes comparar. Y no digamos ya si cogemos el churro tremendo, y que tanto repruebo, de los x86, que ya eran un churro en 16 bits (procesador CISC con mil peculiaridades y excepciones), que fue extendido después a los 32 bits, después con extensiones, después a los 64 bits (por parte de AMD) y con más extensiones. Vamos, este que domina el entorno desktop y servidor, es un churro tremendo.
No se porque piensas que thumb no es RISC. Thumb es un RISC raro porque lo embutieron en instrucciones de 16 bits, y porque lo hicieron bastante mal. Yo he trabajado con otra ISA de inst. de 16 bits, la SH de Hitachi (cuando toque la Dreamcast), y es mucho mas regular y eficiente. Para empezar mantiene los 16 registros de trabajo, no como Thumb con sus dolorosos 8.
Thumb es RISC; no tiene nada tipo "add.l (a0,d0.w),(a1)" ni nada por el estilo. Son inst. con el load/store bien separado del computo, y con 3 operadores en muchas instrucciones de computo. Un RISC tradicional.
La gente confunde a menudo el numero de inst. con la complejidad y con si es RISC o no.
Un PowerPC tiene un monton de inst. en papel, pero la sintaxis es mucho mas rigida que ARM (por ej).
El resultado es que hay muchas mas combinaciones de direccionamientos en ARM que en PowerPC, al final la seccion load/store de PowerPC es mas simplona que la de ARM.
Lo mismo pasa con las operaciones de computo: no puedes hacer algo como "rsb r0,r1,r2,lsl #8" en un PowerPC. Sus inst. son mas simples, aunque sean mas.
No sé si has llegado a manejar un ensamblador de 8 bits de su época. Había incuso ordenadores de 8 bits, por ejm algunos de Commodore (empresa que adquirió a MOS), que incluían en la ROM un monitor-ensamblador. A mí me parecían muy didácticos porque veías según introducías cada instrucción en ensamblador cómo se "traducían" a su código máquina: veías en cada línea qué era el opcode en código máquina y sus operandos de forma directa, y en el 6502 era muy sencillo, se aprendía muy bien. Al final aprendías de memoria gran parte de los opcpdes, de forma que podías identificar las instrucciones hasta en código máquina. En el DEBUG de MS-DOS no era así: no se mostraba al introducir cada instrucción, si querías ver el código máquina tenías que hacer un volcado hexadecimal posterior de esas direcciones.
Si, ahi aprendi yo asm, en un c64. Somos de la misma quinta creo yo.
El Z80 ciertamente es complicado de entender, lleva tiempo, porque tiene muchas instrucciones (para su época y para ser de 8 bits) y particularidades, es una pérdida de tiempo, pero el 6502, dentro de que también tiene sus peculiaridades, es sencillísimo, tiene pocas instrucciones y al mismo tiempo obliga a ejercer el ingenio. Tiene, eso sí, más modos de direccionamiento y más sofisticados, ahí radica una de sus ventajas frente al Z80 (éste tiene otras, como la mayor densidad de código y las instrucciones que operan sobre 16 bits). El 6502 se aprende en una fracción de tiempo de lo que requiere el Z80, es mucho más sencillo y por lo tanto, dentro de los 8 bits clásicos, lo considero mejor a nivel educativo. Aunque el procesador bueno de 8 bits fue el Motorola 6809 (que ya llegó tarde a los 8 bits y era más caro) que era maravilloso, el mejor de 8 bits con diferencia.
Programar en esos bicho te obliga a usar el ingenio, pero en mi opinion no para nada bueno. Es como hacer sudokus, si te ayuda en algo con las matematicas sera tangencialmente, porque no esta relacionado con lo que hace un matematico.
Para resolver cualquier tonteria en un 6502, como ordenar una lista de numeros grandes, te tienes que poner a solucionar un monton de rollos no relacionados con tu algoritmo, como el hecho de que un bucle simple no puede pasar de 256 o que todas las sumas añaden el ultimo carry (y le tienes que meter un clc delante).
A mí el 68000 me encantó en su momento, pese a ser CISC era muy ortogonal, y una maravilla comparado con el sufrimiento que eran los x86 de 16 bits con sus registros de usos especializados-LIMITADOS y donde sólo podía direccionar directamente 64KB, algo ridículo, mientras que el 68k direcciona toda la memoria de forma plana. Como digo yo: si repruebo el x86 es porque lo sufrí a ese nivel 😀
Si, dentro de los CISC el 68000 es el que menos te hace sufrir. El x64 actual seguramente no se va mucho (al menos tiene 16 registros), pero solo lo he mirado de refilon. El VAX tenia fama de ser un gran CISC, pero nunca lo he tocado.
Desde que empece a tocar el RISC todo el tema CISC me parece un error mayusculo que aun estamos pagando.
MIPS me gustaba mucho en su momento, pero ya está abandonado. Supongo que si quieres un RISC lo suyo es enseñar ARM o RISC-V. Pero a eso te voy: dentro de que son procesadores RISC, lo que son sencillas son sus instrucciones, no así los procesadores ni la cantidad de instrucciones: pueden tener un montón de instrucciones (ahí como ejm el PowerPC era un RISC muy complejo). Es que además no es un ISA, son unos cuantos: en ARM, aparte de las diferentes extensiones, tienes un ISA de 32 bits, y otro, INCOMPATIBLE, diferente, de 64, vamos es aprender dos arquitecturas base diferentes. Aprenderlo lleva más tiempo que aprender 6502.
Lo dices como si el que quiere aprender ensamblador estuviera obligado a estudiar todas las inst. y ISAs y esquinas raras del procesador...cuanta gente se miraba el soporte BDC en un 6502 o un z80? Pocos.
Lo importante es el nucleo de fruta, lo que te va a escupir un GCC al compilar en la ISA en la que estas trabajando. Y te aseguro que es mucho mas facil enseñar eso (que pueden ser 30-50 inst simples) que enseñar un 6502, que en apariencia es sencillo y en la practica es una jungla (porque adaptar cualquier algoritmo a 6502 es una lucha por la supervivencia).
Me parece un acierto. Supongo que es mucho mejor que lo que hace el profesor que mencioné que enseña Z80 (ahora la variante de Sharp que usa la Game Boy, que es casi más un Intel 8080 que un Zilog Z80). Enseñar Z80 sí que me parece un despropósito (no malintencionado, pero sí condicionado por la historia peronal del profesor), al ser un procesador de 8 bits complejo con tantas peculiaridades.
Por curiosidad, ¿das en clase el ISA ARM de 32 bits, el de 64, o ambos?
La de 32, pero hace años que deberia haberme pasardo a 64.
Tengo un problema logistico con eso, durante un año dispongo de Raspberrys y podria enseñar ARM64, pero los otros dos dependo de emuladores y trabajo con el de GBA que es bastante practico y te muestra una maquina a bajo nivel. Necesito un sustituto para el emulador que rule ARM64 y no acabo de ver ningun claro.
