[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cc65 competition?

BruceMcF wrote:

On Apr 18, 6:47 pm, Harry Potter <maspethro...@aol.com> wrote:


On Apr 13, 3:44 pm, Harry Potter <maspethro...@aol.com> wrote:



On Apr 13, 3:00 pm, BruceMcF <agil...@netscape.net> wrote:



Rather than try to replace cc65, improve it. Then each feature on your
list is added to what cc65 already provides.



I understand.  Thank you.


Let me add to that.  I have some ideas that I think would improve
compiled C code:

*    Calculation optimizations: All work would be done at compile
time, and only actual data modifications would be written to code.



Yes, that would be a normal optimization ... the first optimizations
are the easiest, and then the more aggressively you pursue it, the
smaller the returns, but given that the target is going to fit into a
64 address space it should be possible to be fairly aggressive.


Certainly doing constant computations at compile time is a good
start--and it permits the use of well-named constants in expressions
without compromising run-time efficiency.


*    Stack optimizations: Instead of using the stack to save
intermediate results, I could use, on the inner-most ones, a zeropage
environment variable.



OTOH, if the programmer has the best idea which inner routines are
going to be called the most often, a register local variable
allocation might be higher priority. Its a matter of balancing the zp
used by the compiler and the zp locations left free to assembly
language routines of the user ... given, of course, large chunks are
in use by the Kernal.


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.


*    Pointer/index: If possible, zeropage pointers would be referenced
directly or through an index.



With the 65816, this is easier, because it has the richer set of stack
indexed addressing ... with a 6502 C, often the stack pointer is
copied to the X index through TSX and the X-indexed address mode is
used for local variables ... $101,X; $102,X and so on ... which means
that zero page pointers through an index may involve register
juggling.


Using a 256-byte stack for both return addresses and parameters is
really pushing it.  ;-)  The parameter & local variable stack should
almost certainly be a memory structure pointed to by a zero-page
pointer.  Having it grow "against" the heap is pretty standard.


OTOH, a small register set means that its probably a bounded problem
with an unambiguous solution, and you use whichever way is the
best ... but there may have to be a speed/size priority setting.


Zero page has room for several "general registers" that could hold
interesting data types.


*    __fastcall and register declarations: I don't know if other 6502
C compilers do this, but I plan to allocate three words in zp for
register and __fastcall declarations and use unused environment space
for excess register declarations.



This seems like the biggest bang for the buck ... straightforward to
manage and much easier to manage, including direct use as pointers
rather than copying from the stack to a work location in the zero page
for indirect addressing.


And an option for inlining small functions can also be a big winner,
and a very effective time-space tradeoff.

-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."