[HN Gopher] Explaining my fast 6502 code generator
       ___________________________________________________________________
        
       Explaining my fast 6502 code generator
        
       Author : pubby
       Score  : 92 points
       Date   : 2023-03-24 19:18 UTC (3 hours ago)
        
 (HTM) web link (pubby.games)
 (TXT) w3m dump (pubby.games)
        
       | commandlinefan wrote:
       | > my compiler generates faster code than GCC, LLVM, and every
       | other compiler I compared it to
       | 
       | GCC and LLVM can target the 6502?!?
        
         | binarycrusader wrote:
         | For LLVM, I don't think it's in the official repo, but yes:
         | 
         | https://github.com/llvm-mos/llvm-mos
        
         | acuozzo wrote:
         | GCC: Via an old, unofficial port:
         | https://github.com/itszor/gcc-6502
        
       | thechao wrote:
       | This is a Massalin superoptimizer.
        
         | pubby wrote:
         | From a quick skim of Massalin's paper, they seem similar in how
         | they generate combinations of instructions and prune, but
         | different in other areas. Superoptimizer spews out every
         | combination of instruction (even invalid ones) in a search for
         | true optimality, and uses boolean logic + emulation to
         | determine equivalent code sequences to prune. 6502 algorithm
         | only generates combinations it knows will work, and uses a
         | symbolic approach to determine equivalence. Its results are not
         | always optimal, and portions like the PBQP stuff is obviously
         | different.
        
       | billyjobob wrote:
       | All the other compilers in the comparison are C compilers, right?
       | Whereas this compiler is compiling its own home made language? So
       | not sure how the comparison can be valid.
        
         | mmphosis wrote:
         | I think NESFab is a medium level programming language targeting
         | the NES 6502. On NES, the Decimal flag has no effect.
         | 
         | GNU Compiler Collection no longer targets 6502, but an older
         | version of the GNU C Compiler could. LLVM targeting 6502 is
         | limited. There is also the cc65 cross compiler. [1]
         | 
         | LLVM [2] and GCC [3] are compiler and toolchain technologies.
         | The name _Low Level Virtual Machine (LLVM)_ is no longer
         | officially an acronym, and the _GNU C Compiler_ is now the GNU
         | Compiler Collection (GCC).
         | 
         | [1] https://www.cc65.org/ [2] https://www.llvm.org/ [3]
         | https://gcc.gnu.org/
        
         | pubby wrote:
         | FWIW the custom language is very close to C, and the examples
         | are pretty much a 1-1 transposition.
         | 
         | I agree with you though on a different note. It's dubious to
         | compare compilers by benchmarking them, because tests are
         | highly arbitrary and are won/lost based on single weak links.
         | It's not really an exact science, but rather something you can
         | start with to figure out how things are behaving. I mostly base
         | my opinions by looking at the assembly code each compiler
         | generates, but a single bar graph is a better presentation for
         | articles.
        
       | Scaevolus wrote:
       | Does this code generator spill to zero-page? Do you have to do
       | anything special for allocations there?
        
       | ajross wrote:
       | Bookmarked this to read about optimizers, because it looks great.
       | 
       | That said, I clicked on the link because it had "6502" in the
       | title. And... this isn't very interesting as a retrocomputing
       | activity. To be blunt: there's absolutely no way in hell a
       | compiler architecture like that is ever going to be self-hosting
       | in 64k of memory space.
        
         | iainmerrick wrote:
         | Not interesting to you, but other people may differ! A cross-
         | compiler targeting the 6502 is still interesting to some. As
         | the article notes, these compiler techniques weren't invented
         | in the 70s because computers weren't powerful enough to make
         | good use of them. What's wrong with exploring what the original
         | hardware is capable of when freed from those restrictions?
        
           | ecpottinger wrote:
           | It is my understanding the the GEOS system was developed on a
           | more powerful machine than the C64/Atari computers it was
           | used on. This let then have the entire code in memory and
           | then processed for common functions. They could not do this
           | on the the 64K-8 bit computers at the time.
        
           | ajross wrote:
           | There's nothing "wrong" with it. I'm just saying that if I'm
           | going to read an article about fun 6502 activities, I want to
           | see it hosted on an Apple II. If I want to read about
           | compiler techniques, I'd prefer to see it targetting a more
           | orthogonal (or less weird, anyway) architecture.
        
         | troad wrote:
         | I don't think of retro-computing as an activity limited solely
         | to the hardware and software that existed at a given time,
         | that's far too restrictive for me.
         | 
         | 6502 is an architecture, not a specific machine, nor even the
         | set of machines that supported that architecture in the past.
         | The architecture is and remains interesting on its own! (6502
         | assembly remains a really good intro to assembly, for instance,
         | even for people that have never even seen a C64.)
         | 
         | There is absolutely scope for people to do fun things with 6502
         | that could never run on a C64 or an Apple II. The vast majority
         | of 6502 code today runs in emulation, so there's really no
         | reason to artificially gimp it to ape the limitations of any
         | given machine. (Unless emulating that specific machine of
         | course!)
        
           | ajross wrote:
           | > 6502 assembly remains a really good intro to assembly
           | 
           | It... really is not, though. It doesn't teach you macro
           | assemblers as they exist in the modern world. It doesn't
           | teach you interaction with the linker except in the simplest
           | ways.
           | 
           | And while the instruction set is "simple" in the sense that
           | it can be understood on a page of paper, lots of critically
           | important ideas don't exist in a meaningful way. Modern
           | techniques like register assignment aren't possible given the
           | limitations and non-orthogonality of the CPU state. There's
           | no "ABI" equivalent you can use to call a standard function,
           | and even something as foundational as "passing arguments" to
           | a function isn't directly expressible, because the "stack
           | pointer" isn't actually a pointer. In point (heh) of fact,
           | _no pointers are pointers_ because the 6502 doesn 't actually
           | have an abstraction for a memory address!
           | 
           | Everyone should learn to hack on an Apple II (and good grief,
           | not a Commodore unless you are trying to learn VIC-II or SID
           | hardware), but not to teach themselves "assembly" as a skill
           | they might apply elsewhere.
           | 
           | In fact it's almost the same argument used for why we teach
           | new kids Python and not BASIC. The latter just isn't a useful
           | tool for expressing the concepts you need to learn.
        
             | Luc wrote:
             | Wow you really are into telling people what they should do.
        
       | ecpottinger wrote:
       | This does far more than I did back in my PET and then Amiga days,
       | but one thing I did was write a multi-pass compiler. Each pass at
       | first found ways to make the come better (usually smaller so it
       | ran faster). Even simple code I wrote could see a 10-20%
       | improvement.
       | 
       | Of-course, this is because the original code was quick and dirty.
       | I wonder what improvement modern compilers could have added.
        
       ___________________________________________________________________
       (page generated 2023-03-24 23:00 UTC)