Does this code generator spill to zero-page? Do you have to do anything special for allocations there?
Since it combines register allocation with instruction spilling is innate - there isn't a special spilling phase. Spilled variables are assigned ram addresses after code generation occurs at link time, with the most frequently used going to zeropage.
Explaining my fast 6502 code generator
31–40 of 52 posts
Re: Explaining my fast 6502 code generator
#32Earlier quoted context omitted.
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 peop…
> 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 techniqu…
In summary, please tell us how many shades of mucky greyish brown you get with the Apple II. Because with the C64, you get 13.
Re: Explaining my fast 6502 code generator
#33Earlier quoted context omitted.
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 peop…
> 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 techniqu…
Re: Explaining my fast 6502 code generator
#34Re: Explaining my fast 6502 code generator
#35Earlier quoted context omitted.
Plenty of teenagers in the 80s writing games for the various home computers at the time (Apple ][, Atari 400 & 800, Commodore 64).
That waa me. My 6502 "IDE" was a BBC Micro, with it's excellent BBC BASIC ROM that had inline 6502 assembler built-in to the BASIC language. It was so good and accessible, and documented in the Advanced User Guide, that after learning BASIC starting age 10, I learned 6502 a few months later and was able to reverse engineer and modify other people's games not long after that. I had the luxury of floppy drives which my…
Several years after I moved on from the Beep to a PC, I again had the opportunity to use my knowledge of 6502 assembly. A rally-driving friend asked me to look into changing the fuel curves in their Toyota's ECU. Turns out that many early 90s ECUs used 6502s. I whipped up a 6502 disassembler (in Turbo Pascal) and was able to reverse engineer the ROM dump and make the required adjustments. Fun times.
Re: Explaining my fast 6502 code generator
#36Re: Explaining my fast 6502 code generator
#37Earlier quoted context omitted.
> Wow you really are into telling people what they should do. Saying "6502 is not a good platform for learning assembly" is simply not the same thing as saying "you should not learn assembly language with a 6502 assembler", and I don't understand how you're interpreting it that way. It's just giving you my opinion and advice. By your own logic, you are now trying to censor my ability to give that opinion and advice.…
If you were being honest you would say wasm is a good platform for learning assembly and JavaScript the perfect first programming language.
Re: Explaining my fast 6502 code generator
#38This 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.
Geez, 25 years ago I was being boggled by how sophisticated was the code generated by the C compiler we shipped at SGI. For the MIPS architecture, as for most contemporary architectures, re-ordering memory accesses to minimize cache misses was FAR more important to execution speed than the specific selection of machine instructions. Of course for early MIPS there were little things like, don't put a jump in the last…
Re: Explaining my fast 6502 code generator
#39Earlier quoted context omitted.
> 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 techniqu…
I was almost with you, because much as I love the 6502, it is kind of weird by modern "standards". But then: the Apple II? Like, wtf man. C'mon. The Apple II is shit . Is it just because you like that sweet double density disk throughput? Well, fair enough, but then why not go for the BBC Micro. 2 MHz, plus 80 columns. OK, so it only has 32 KB RAM... meanwhile, you are still American. In summary, please tell us how m…
Re: Explaining my fast 6502 code generator
#40I may have misunderstood, but I believe step 1 (eliding loads) is simply a cache scheduling problem. The optimal solution is the greedy "furthest in the future" eviction policy.