cc65 competition?
in [Commodore]
|
Prev: CBM Repair Problem
Next: scanning manuals
From: Michael J. Mahon on 19 Apr 2008 14:45 BruceMcF wrote: > On Apr 19, 2:32 am, "Michael J. Mahon" <mjma...(a)aol.com> wrote: > >>For a 6502, zero page *is* the "registers". Nothing of interest to >>a compiler--like pointers or integers--will fit in the processor's >>registers. > > > Yes, but at the same time, much of low level interfacing with the > Kernal > from C involves treating zero page locations as either a global > integer > variable or global pointer variable. > > I took it that he was referring to that kind of use of the zero > page ... > the zero page *used as* memory that is quicker to get to and quicker > to use when dereferencing a pointer. And page 0 is the natural place for "register" variables, both the declared ones and the ones needed by the compiler/runtime. >>Using a 256-byte stack for both return addresses and parameters is >>really pushing it. > > > Yeah, I can see a pointer to a software stack structure passed on > the hardware stack before making the 6502 call. You don't even need to pass it, since it is a global page 0 variable. > With that, you only use the TSX register one time, at the start of > a called function, to set up the local variable pointer in the zp, > and possibly at the end if that slot in the hardware stack is used, > for ANSI C returns, as the pointer to the return value, or for K&R > returns, for the return value itself. So X would be free during > the routine, but Y would be in heavy use. Every function call/entry/exit maintains the global procedure stack, so it never needs to be passed, and is always implicitly in "sync" with the hardware stack for return addresses. > The general point stands ... without the built in stack frame address > modes of the 65816, there's going to be one of the two index > registers > that is in use to reference local variables. True--or indeed to reference *anthing* relative to a pointer. >>And an option for inlining small functions can also be a big winner, >>and a very effective time-space tradeoff. > > > Yes, I overlooked this entirely, but but there are a lot of > optimizations available for a zp routine that are not available > outside the zp. If you take a "threaded code" approach for operations on larger data types, then putting a bit of that code on page 0 can do wonders for speed--at the cost of precious real estate, of course. -michael NadaPong: Network game demo for Apple II computers! Home page: http://members.aol.com/MJMahon/ "The wastebasket is our most important design tool--and it's seriously underused."
From: BruceMcF on 19 Apr 2008 23:39 On Apr 19, 2:45 pm, "Michael J. Mahon" <mjma...(a)aol.com> wrote: > You don't even need to pass it, since it is a global page 0 variable. So its just a local stack frame in parallel with the hardware return stack. I never felt the urge to crack the hood on C, but I realize it is a lot more demanding of stack real estate than Forth.
From: Michael J. Mahon on 20 Apr 2008 03:53
BruceMcF wrote: > On Apr 19, 2:45 pm, "Michael J. Mahon" <mjma...(a)aol.com> wrote: > >>You don't even need to pass it, since it is a global page 0 variable. > > > So its just a local stack frame in parallel with the hardware return > stack. I never felt the urge to crack the hood on C, but I realize it > is a lot more demanding of stack real estate than Forth. Exactly. And the stack demand depends on programming style--lots of parameter or local variables means lots of stack frame. Since style is out of control of the compiler, you have to assume that there will be lots of stuff on the stack. -michael NadaPong: Network game demo for Apple II computers! Home page: http://members.aol.com/MJMahon/ "The wastebasket is our most important design tool--and it's seriously underused." |