Re: Processor specific optimisations

jgd@cix.co.uk (John Dallman)
24 Jan 2002 14:52:46 -0500

          From comp.compilers

Related articles
Processor specific optimisations mpointie@eden-studios.fr (MickaŽl Pointier) (2002-01-17)
Re: Processor specific optimisations pfroehli@ics.uci.edu (Peter H. Froehlich) (2002-01-18)
Re: Processor specific optimisations dave@cyclicode.net (Dave Hudson) (2002-01-18)
Re: Processor specific optimisations rickh@capaccess.org (2002-01-18)
Re: Processor specific optimisations usenet@gehre.org (2002-01-18)
Re: Processor specific optimisations walter@bytecraft.com (Walter Banks) (2002-01-24)
Re: Processor specific optimisations jgd@cix.co.uk (2002-01-24)
Re: Processor specific optimisations thp@cs.ucr.edu (2002-01-24)
Re: Processor specific optimisations RLWatkins@CompuServe.Com (R. L. Watkins) (2002-01-24)
Re: Processor specific optimisations mpointie@eden-studios.fr (MickaŽl Pointier) (2002-01-28)
Re: Processor specific optimisations rickh@capaccess.org (2002-01-28)
Re: Processor specific optimisations mpointie@eden-studios.fr (MickaŽl Pointier) (2002-01-30)
Re: Processor specific optimisations Ulrich.Teichert@gmx.de (2002-01-30)
[4 later articles]
| List of all articles for this month |

From: jgd@cix.co.uk (John Dallman)
Newsgroups: comp.compilers
Date: 24 Jan 2002 14:52:46 -0500
Organization: By appointment only
References: 02-01-077
Keywords: optimize
Posted-Date: 24 Jan 2002 14:52:46 EST

mpointie@eden-studios.fr (MickaŽl Pointier) wrote:


> So, the question finaly is: Is it possible to apply the modern
> compiler optimisation strategies to this old processor and have a
> result that an experimented 6502 assembly coder would have a hard time
> to beat ?


The 6502 has always been difficult to compile for. Trying to create
the kind of operations you need to build, say, object code for C out
of, has always seemed to require using some kind of virtual machine
with its registers held in zero page. These seem to be less efficient
than mildly skilled hand-coding (I spent several years working on the
Robo BitStik CAD system for the 6502 in the eighties).


The 6502 is pretty good at running interpreters, so compiling to some
form of bytecode and then interpreting that can work; most of the
compilers for the 6502 that were any use worked this way, and I'd
advise following their example. Designing a bytecode that works well
and quickly is the trick.


One method that we used for squeezing arithmetic into fewer
instructions and saving zero page was to have a work area outside zero
page, but at a fixed and well-known machine address on a page
boundary. You can then use X and Y indexes to pass the locations of
data objects in this page around between subroutines that actually do
the work.


If you could impose the limit that a stack frame was limited to 256
bytes of data, you could use this technique for representing C stack
frames. It means implementing alloca() gets interesting, but with such
a small-memory machine, you want to be very careful about allowing
dynamic allocation anyway.


---
John Dallman jgd@cix.co.uk
                    "C++ - the FORTRAN of the early 21st century."


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.