From: Arvid Norberg (c99ang_at_cs.umu.se)
Date: 2001-03-07 23:51:40
Hello,
Thanks for all your answers.
>There is no such declaration for cc65, because the compiler does not
have
>enough information to generate the necessary code. Here is why:
>
>An interrupt may not execute C code, without some helper code written
in
>assembler, because several routines may not interrupted and then
called
>recursively. This is not the fault of cc65, it's a problem of the
6502,
>because it is not able to manipulate 16 bit values in one atomic
transaction.
What happens when the 6502 gets an interrupt?
I've always imagined that the folowing steps are performed by the CPU:
1. CPU registers were pushed onto the stack (a, x, y, pc).
2. execution jumped to the interrupt handler
3. when rti is reached, the resgisters are popped back and execution
continues where it was interrupted.
I don't see what pushing ints onto the stack has to do with this.
> [...]
>If this routine is interrupted while the overflow from low to high
byte of the
>stack pointer is not corrected, any C routine using the stack (and
most do)
>that is called in an interrupt will overwrite parts of the stack that
are not
>owned by the function. The same is true for all other functions
manipulating
>the stack pointer.
>
>So one condition for calling C code in an interrupt would be a
separate stack.
>This stack switching cannot be done by the compiler, because the
second stack
>has to be allocated somewhere, and the compiler has no knowledge how
to do
>that. This is the main reason that just using an additional keyword
for
>declaring interrupt handlers is not enough.
This means that I don't understand why the stack get messed up.
>Another problem is that there are "registers" in the zeropage that may
be
>trashed by the code executed in the interrupt.
>
>So, the second condition for calling C code in an interrupt handler
would be
>that the zero page locations needed by the compiler must be saved
before
>calling C code and restored afterwards.
>
This, I can understand, is a problem.
(Not that I know what those register migth contain, especially for a
void function that takes no parameters).
> [...]
>Apart from that, it is better to use a "void" parameter list for
functions
>that don't take any parameters. If the compiler knows that there are
no
>parameters, it is able to generate better code. An empty parameter
list means
>in C: "This function may take any number of arguments", which means
that the
>compiler has to generate code to remember the number of parameters
passed.
Thanks, I'm just using c++ too much these days. ;)
I would appreciate answers to my questions, but if you don't want to
spend your time on answering them, I won't blame you.
--------------------
I also think I've found a minor bug in cc65. The following code:
#include <conio.h>
void main(void)
{
char a = -1;
if (a < 0 || a > 2) cputs("a < 0 or a > 2\n");
}
generates the following warning, when compiled.
test.c(6): Warning: Condition is never true
thanks,
---
Arvid Norberg
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:39 CET