🚀 go-pugleaf

In article <49a61t8epk5iuuqrr6rvpnp6g0ic1d6nkm@4ax.com>, DrPanic <drpanic_esto_sobra_@teleline.es> wrote:
>On Wed, 15 Nov 2000 22:10:11 GMT, mallok <jsegam@terra.es> wrote:
>
>>"Miguel A. Fuentes" escribi�:
>>
>>> Desde hace mucho tiempo estoy programando y he visto multitud de
>>> aplicaciones, grandes y peque�as, y JAM�S he visto un GOTO, casualidad?
>>

Llevo 20 a�os programando y s�lo utilice goto en Cobol, ya que hab�a 
situaciones en las que no tenias alternativas, por las limitaciones del 
lenguaje.

Hace poco estaba escribiendo una aplicaci�n, implementada como un 
mini-lenguaje de programaci�n orientado especificamente al problema. La 
aplicaci�n consta de un compilador que generada c�digo para una m�quina 
RISC "virtual" basada en stack y un interprete de implementa dicha m�quina 
(que elegante suena!). Todas las instrucciones son del tipo CODIGO_OPERACION 
OPERANDO.

El asunto es que cuando comence a trabajar en la optimizaci�n del c�digo 
generado finalmente vine a entender lo malo que puede ser el goto.

Este mini-lenguaje carece de goto (carece de muchas cosas, esa es la idea), 
por lo que al ir generando c�digo pod�a estar muy seguro del contexto en el 
cual se generaba y las optimizaciones que podia aplicar. Por ejemplo, cuando 
descubria que estaba generando una secuencia:
        - Push variable.
        - Incrementar en uno el tope del stack.
        - Pop y almacenar valor en variable.

la podia sustituir directamente por una s�la instrucci�n que incrementaba 
directamente la variable en memoria, sin pasar por el stack.

Tambi�n aplique algunas optimizaciones a las comparaciones y saltos que se 
generan al encontrar if, while, etc., con resultados desastrosos en la 
ejecuci�n. Por ejemplo, inocentemente sustitui:
        - Comparar stack contra cero.
        - Saltar a X si es comparaci�n OK.
por
        - Compara stack contra cero y saltar a X (si es comparaci�n es OK).

Lo que no me hab�a percatado es que en el primer caso, la segunda instrucci�n 
podia ser el destino de algun goto previo, asi que fundir ambas instrucciones 
no iba a producir el resultado deseado originalmente (que eran dos saltos en 
cadena).

En resumen: el uso de "goto" destruye el contexto en el cual est�s trabajando. 
Si estas en una secci�n a la cual puedes llegar por uno o varios goto, puede 
ser d�ficil determinar el contexto en que se ejecuta esa secci�n. Si no sabes 
en que estado est�n tus archivos, variables y demases, se hace bien cuesta 
arriba escribir c�digo.

Andr�s