Re: [cc65] c64 question

Date view Thread view Subject view

From: Mike McCarty (jmccarty_at_ssd.usa.alcatel.com)
Date: 2001-03-19 21:45:05


On Mon, 19 Mar 2001, Ullrich von Bassewitz wrote:

> 
> On Mon, Mar 19, 2001 at 02:26:24PM -0600, Mike McCarty wrote:
> > Well, some implementations don't use a stack unless necessary, but
> > rather implement arguments to routines which do not *need* to be
> > re-entrant (most of them, in my experience) as statically allocated
> > locations. In this case, there is no stack manipulation, hence no need
> > to disable interrupts.
> 
> This is not only difficult to check (because the compiler cannot see if a
> function is called from somewhere outside the module), but does also violate

Certainly it can. The gnu C compiler does this automatically as an
optimization even for machines which have a reasonable (read 16 bit)
stack pointer. If a routine is declared "static" then the compiler
knows, and  can check for aliased pointers. Especially it can know if
it is told by the programmer by...

> the ISO C standard. So it's not really an option in my eyes, even if cc65

using an ISO C Standard compliant #pragma.

> allows it (at least for local variables).


> > Well, that enters into a whole other realm of questioning. I saw
> > questions about feasibility and run time cycles, not preferences.
> 
> It's not preferences, it's "advantages" :-)

I have reasons, you have preferences, he has biasses.

;-)

Ultimately: You support the compiler. You don't like that solution, so
it won't exist.

Which is ok.

Mike
----
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I can explain it for you, but I can't understand it for you.
I don't speak for Alcatel      <- They make me say that.

----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.


Date view Thread view Subject view

This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:39 CET