El artículo actualmente afirma
luego mas tarde
Parece que alguien se quedó confundido con la gente que llama al lenguaje de máquina nativo "código enhebrado por subrutina", que la mayoría de la gente diría que es lo opuesto al código enhebrado. Si el "código enhebrado por subrutina" es un tipo de código enhebrado, entonces prácticamente todo el código es código enhebrado de un tipo u otro. (La única excepción es el código que no tiene *ninguna* subrutina, ¿verdad?).
Creo que Chuck Moore desarrolló el término "código enhebrado" para describir a Forth, es decir, código enhebrado indirecto o código enhebrado directo.
¿Alguno de estos otros compiladores/intérpretes realmente generó código con subprocesos indirectos o código con subprocesos directos? Sé que algunos compiladores BASIC y PASCAL generan "código p"...
-- DavidCary 12:37, 13 de julio de 2005 (UTC)
Estoy muy interesado en la variedad de técnicas de llamada a subrutinas (lo que algunas personas llaman los tipos de "modelo de subprocesamiento").
Se está desarrollando una interesante discusión aquí, pero está empezando a eclipsar lo que la mayoría de la gente considera como "código enhebrado" (código enhebrado indirecto y código enhebrado directo).
¿Existe un artículo mejor en otro lugar (o un buen nombre para un artículo, si aún no existe) para hablar sobre las técnicas de llamada a subrutinas en general, dejando este artículo para centrarse en ITC y DTC?
-- DavidCary 12:37, 13 de julio de 2005 (UTC)
:X SI. "Verdadero" ENTONCES...etc.
(1) CALL <rutina para poner "etiqueta" en la pila de retorno> (2) LLAMAR SI (3) CALL <rutina para poner la dirección de la cadena "Verdadero" en la pila> (4) LLAMA ." (5) <etiqueta>: (6) LLAMA ENTONCES ... etc
Eliminé En algunas computadoras hay diferentes tipos de instrucciones de llamada de subrutina que utilizan diferentes longitudes de direcciones. En estos casos, los programadores a menudo podrían lograr usar una forma más corta mediante el uso de código enhebrado, porque no veo qué relevancia tiene: una llamada enhebrada siempre es más corta que incluso la instrucción de llamada de subrutina más corta.
Eliminé Threading is ... processing by ... the CPU (B) porque las CPU con las que estoy familiarizado no pueden procesar directamente código enhebrado (excepto el llamado "código enhebrado de subrutina"). Pero es teóricamente posible que alguna CPU tenga hardware especial para procesar directamente código enhebrado. ¿Existe realmente una CPU así? -- DavidCary 12:37, 13 de julio de 2005 (UTC)
¿Podría alguien agregar un enlace a los artículos de Brad Rodríguez "Avanzando"?
https://www.bradrodriguez.com/papers/moving1.htm
Además, creo que 'w' es 'registro de trabajo', no 'puntero de palabra'.
—El comentario anterior sin firmar fue añadido por 68.60.59.250 ( discusión • contribs ) 13:17, 20 de abril de 2006 (UTC2)
¿Escuché a alguien afirmar que "no todas las CPU modernas tienen instrucciones de llamada"[1]?
Ciertamente, muchos diseños recientes de CPU hechos en casa (Wikibooks:Diseño de microprocesadores/Envoltura de cables) no tienen una instrucción de llamada, pero la mayoría de la gente los llama "retro" en lugar de "modernos".
¿Qué CPU sería esa? No puedo pensar en *ninguna* CPU fabricada después del RCA 1802 de 1976 que no tuviera una instrucción de llamada.
-- 68.0.124.33 ( discusión ) 18:33 18 ene 2008 (UTC)
Parallax_Propeller tiene una instrucción de ensamblador 'CALL' (que comparte los bits de instrucción con el código de operación de 'JMP'), pero no un puntero de pila (esa instrucción no se puede usar para código reentrante), por lo que creo que califica ;-} — Comentario anterior sin firmar agregado por Guenthert (discusión • contribuciones ) 20:41, 20 de julio de 2015 (UTC)
Recientemente, alguien cambió la última oración de
a
Revertí esa edición, aunque esa nueva última oración es *generalmente* cierta, de manera aislada: *generalmente* las secuencias redundantes de instrucciones se pueden acortar mediante el uso de subrutinas.
Sin embargo, no es posible "utilizar subrutinas" para eliminar las secuencias redundantes particulares mencionadas en la oración anterior. (¿O me estoy perdiendo algo?)
El objetivo principal del artículo es que *existe* una manera de "almacenar esta información exactamente una vez" (código enhebrado) y los distintos tipos de enhebrado son distintas maneras de implementar ese objetivo.
Sospecho que mucha gente pasa por alto la última pregunta y la malinterpreta: ¿cómo puedo mejorar el artículo aclarándolo? -- 68.0.124.33 ( discusión ) 14:40 30 may 2008 (UTC)
Una edición reciente [2] implica que el "código enhebrado" es una reinvención de algo usado "desde los primeros días de las computadoras".
Reconozco que no sabía mucho sobre los primeros ordenadores mainframe. Así que:
-- 68.0.124.33 ( discusión ) 05:32 30 ene 2009 (UTC)
Este artículo podría:
¿Qué enfoque ayuda a las personas a comprender mejor este tema?
En algún momento, este artículo utilizó el enfoque (b).
Lamentablemente, una edición bien intencionada ([3]) eliminó el primer paso o los dos primeros de esa secuencia. Esto deja la sección "Desarrollo" Threaded_code#Development con varias referencias confusas a "los códigos de bytes" y "el intérprete de decodificación y envío descrito anteriormente" que ya no existen.
¿Sería más fácil entender este artículo si volvemos al enfoque (b) o si eliminamos esas referencias pendientes y tratamos de cambiar al enfoque (a)? -- DavidCary ( discusión ) 18:23 15 may 2011 (UTC)
He cambiado a (a) pero las referencias pendientes permanecen en el código fuente (comentadas), por si acaso. Puede ser prudente mover el texto hacia abajo, donde de hecho se proporciona un intérprete de bytecode después de que se realiza la discusión del código enhebrado. eritain ( discusión ) 19:09, 12 de junio de 2019 (UTC)
Este artículo utiliza una notación que no he visto antes, sin explicar qué es ni qué significa, lo que hace que el artículo sea difícil de entender. La notación se parece un poco a C, pero no es C. ¿Por qué nadie más ha comentado sobre esto?-- greenrd ( discusión ) 11:21 26 oct 2013 (UTC)
Dado que Forth es el ejemplo más común de una implementación de código subprocesado, ¿por qué los ejemplos están en C en lugar de en ensamblaje o pseudocódigo?
C y Forth se encuentran en extremos opuestos del espectro en muchos aspectos. Simplemente parece *incorrecto* dar ejemplos de código enhebrado utilizando modismos de C. 87.68.22.118 (discusión) 19:39 23 feb 2014 (UTC)
Un ejemplo simple (en la fuente de la máquina virtual Parrot ) con códigos de operación de base de funciones, núcleo de código de operación conmutado y núcleo CGOTO es examples/c/nanoparrot.c. Hice algunas pruebas hace mucho tiempo, consulte Nanoparrot. -- mj41 ( discusión ) 22:01, 30 de octubre de 2015 (UTC)
Actualmente, los ejemplos de pseudocódigo son lo suficientemente similares a C como para que la gente pueda asumir que siguen las reglas de C. Sin embargo, cada uno de estos ejemplos es víctima de un comportamiento indefinido, más específicamente, de modificaciones y accesos no secuenciados. Para aclarar a los lectores del artículo el comportamiento exacto de cómo se vería esto en un lenguaje similar a C, creo que deberíamos reescribir el pseudocódigo similar a C para que no contenga lo que se considera un comportamiento indefinido en C. Sin embargo, para intentar trabajar en pos de un mejor artículo, me gustaría saber si alguien tiene ideas potencialmente mejores sobre lo que se podría hacer. Estaba pensando en cambiar por completo los estilos de pseudocódigo. ¡Gracias!
Bulbazord (discusión) 04:10 11 nov 2016 (UTC)
He sugerido una modificación de sintaxis a continuación: específicamente, no usar el carácter & para cada elemento de la matriz y cambiar de un estilo C-switch a un estilo C-procedimiento: considero específicamente que el uso de bloques nombrados es sintácticamente beneficioso. 2602:301:7764:AC00:9ED:9E40:9294:D87 (discusión) 22:43 1 jun 2019 (UTC)
La sección que describe el código de subproceso directo dice lo siguiente:
Esta forma es simple, pero puede tener costos adicionales porque el hilo consta solo de direcciones de máquina, por lo que todos los demás parámetros deben cargarse indirectamente desde la memoria. [1]
Antes de dar un ejemplo de código de subproceso directo que contiene constantes en línea (A y B), en contradicción directa con la cita que he proporcionado anteriormente. Propongo que se utilice la siguiente redacción en su lugar:
Esta forma es simple, pero si el hilo consta únicamente de direcciones de máquina, entonces todos los demás parámetros deben cargarse indirectamente desde la memoria, lo que puede generar sobrecarga.
Además, se utiliza una gramática similar a C (en particular, se utilizan conmutadores), pero parece que se hace referencia a las constantes mediante una dirección, ¡pero se las utiliza como valores! Recomiendo reemplazar las instancias de &A o &B con A o B simples, y utilizar una gramática de estilo de procedimiento de C en lugar de una gramática de conmutador de C, tal vez con algo como "saltar" o "saltar a" al comienzo de una referencia a otro fragmento de código, para aclarar la forma en que se está utilizando el código en cuestión.
2602:301:7764:AC00:9ED:9E40:9294:D87 (discusión) 22:39 1 jun 2019 (UTC)
Referencias
No se introduce la abreviatura "TIL" (subsección RPL ). Probablemente se refiere a "lenguaje interpretado por subprocesos" , pero no está definido (¿qué es exactamente?).
¿O lenguaje interpretativo-enhebrado, no lenguaje interpretado-enhebrado?
-- Mortense ( discusión ) 18:25 20 may 2021 (UTC)
Las frases "que lee el lenguaje simbólico poco a poco" y "cada bit existe en un solo lugar" utilizan la palabra "bit", que puede confundirse con el significado informático, en lugar de, por ejemplo, "pequeño". Por si acaso las primeras máquinas leían bits individuales mientras interpretaban, abrí esta discusión en lugar de hacer la edición. 47.154.80.218 (discusión) 18:49 29 nov 2022 (UTC)