Restos de interrupción

[Fidel Martins]

El tema es que:
Hago un código usando una interrupción y después la abandono, cambio el proyecto, pero la interrupción se queda ocupando espacio, aunque desactivada. Entonces la borro toda y esto crea un problema, pues aun hay bits no declarados de la  "Interrupción" borrada. Y asi no genera el archivo".asm".

[Fidel Martins]

Por ahora la solución que tengo, es copiar lo que sirve y empezar otro proyecto.

[Fer_TACA]

Fidel,
Para solucionar ese problema, debes ir a herramientas ->depurador de registros y dar ok.
Luego vuelve a compilar.
Si te sigue diciendo que faltan bits por declarar, cierra el programa y vuelve lo abrir. Con una nueva compilación se suele arreglar.
Se que es una "lata" pero así se soluciona la mayor de las veces.
Y si no se soluciona debes decírselo a Niple.
No obstante si quieres que lo revise, adjunta el proyecto y le hecho un vistazo

F

[DominusDRR]

El tema es que:
Hago un código usando una interrupción y después la abandono, cambio el proyecto, pero la interrupción se queda ocupando espacio, aunque desactivada. Entonces la borro toda y esto crea un problema, pues aun hay bits no declarados de la  "Interrupción" borrada. Y asi no genera el archivo".asm".

O sea, si no eres tu quien maneja la interrupción, es decir que lo hace el compilador, lo que sucede es cuando sucede dicha excepción, lo primero que se hace es guardar el contexto (el valor del/los acumulador/res, contador de programa y otros registros que se necesita para que el CPU regrese a donde estaba) y una vez finalizado dicho evento, se "recupera" el contexto.

Obviamente cuando puedes tener varias interrupciones con distintos tipos de prioridad, si una interrupción es por decirlo, interrumpida por otra de un nivel superior, también debe guardarse el contexto de la primera interrupción, respecto a la segunda que ocurre.

Ese espacio donde guardas dicha información, debe ser reservada y no es infinita, razón por la cual deberías escribir un código evitando que se desborde ese tamaño asignado.

Pero si usas un compilador, podría decirse que no deberías preocuparte por eso.

[Fer_TACA]

El tema es que:
Hago un código usando una interrupción y después la abandono, cambio el proyecto, pero la interrupción se queda ocupando espacio, aunque desactivada. Entonces la borro toda y esto crea un problema, pues aun hay bits no declarados de la  "Interrupción" borrada. Y asi no genera el archivo".asm".

O sea, si no eres tu quien maneja la interrupción, es decir que lo hace el compilador, lo que sucede es cuando sucede dicha excepción, lo primero que se hace es guardar el contexto (el valor del/los acumulador/res, contador de programa y otros registros que se necesita para que el CPU regrese a donde estaba) y una vez finalizado dicho evento, se "recupera" el contexto.

Obviamente cuando puedes tener varias interrupciones con distintos tipos de prioridad, si una interrupción es por decirlo, interrumpida por otra de un nivel superior, también debe guardarse el contexto de la primera interrupción, respecto a la segunda que ocurre.

Ese espacio donde guardas dicha información, debe ser reservada y no es infinita, razón por la cual deberías escribir un código evitando que se desborde ese tamaño asignado.

Pero si usas un compilador, podría decirse que no deberías preocuparte por eso.

Ese no es el problema. Radica en que cuando creas una interrupción y compilas el programa, si más tarde modificas el programa y ves que no necesitas la interrupción vas y la borras(eliminas).
Es entonces cuando al volver a compilar, Niple da unos errores de no reconocer unos bits.

F.

[DominusDRR]

El tema es que:
Hago un código usando una interrupción y después la abandono, cambio el proyecto, pero la interrupción se queda ocupando espacio, aunque desactivada. Entonces la borro toda y esto crea un problema, pues aun hay bits no declarados de la  "Interrupción" borrada. Y asi no genera el archivo".asm".

O sea, si no eres tu quien maneja la interrupción, es decir que lo hace el compilador, lo que sucede es cuando sucede dicha excepción, lo primero que se hace es guardar el contexto (el valor del/los acumulador/res, contador de programa y otros registros que se necesita para que el CPU regrese a donde estaba) y una vez finalizado dicho evento, se "recupera" el contexto.

Obviamente cuando puedes tener varias interrupciones con distintos tipos de prioridad, si una interrupción es por decirlo, interrumpida por otra de un nivel superior, también debe guardarse el contexto de la primera interrupción, respecto a la segunda que ocurre.

Ese espacio donde guardas dicha información, debe ser reservada y no es infinita, razón por la cual deberías escribir un código evitando que se desborde ese tamaño asignado.

Pero si usas un compilador, podría decirse que no deberías preocuparte por eso.

Ese no es el problema. Radica en que cuando creas una interrupción y compilas el programa, si más tarde modificas el programa y ves que no necesitas la interrupción vas y la borras(eliminas).
Es entonces cuando al volver a compilar, Niple da unos errores de no reconocer unos bits.

F.

Ese niple, con todos los problemas que leo aquí en el foro, da un mal rollo, parece un proyecto beta, y no una herramienta profesional con varios años de existencia.