Live data from Hacker News

Explaining my fast 6502 code generator

pubby.games

31–40 of 52 posts

Re: Explaining my fast 6502 code generator

#31
post #21

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.

Does it avoid ZP addresses with special purpose for the system when doing this?

Re: Explaining my fast 6502 code generator

#32
post #17
post #14

Earlier 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…

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

#33
post #17
post #14

Earlier 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…

[deleted]

Re: Explaining my fast 6502 code generator

#35
post #30
post #28

Earlier 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…

Yup, that was me too. The BBC Micro was a great 6502 dev environment (for the time).

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

#36
I'd like to see this same technique applied to x86, and what the performance is like without the "illegal instructions" (omitting them from generation would probably be trivial). It's relatively well known that one of the ways Asm programmers can beat compilers is on instruction selection, and that's what this technique seems to excel at.

Re: Explaining my fast 6502 code generator

#37
post #19

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

WASM isn’t really even an assembly language, despite the name.

Re: Explaining my fast 6502 code generator

#38
post #24

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.

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…

6502 also had some "little things". E.g., it's jump indirect didn't work across page boundaries: http://www.6502.org/tutorials/6502opcodes.html#JMP

Re: Explaining my fast 6502 code generator

#39
post #32
post #17

Earlier 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…

You can get a Beeb with 64k. The Master even comes with 128k standard, if I’m not mistaken.

Re: Explaining my fast 6502 code generator

#40

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

That's an excellent point. I hadn't heart of furthest in the future, but it looks like it does solve step 1. Past that though, it doubt it can be used because each of the 6502's registers are different and don't support the same operations. It's a good idea though, and might work for some specific RISC architecture where all registers behave the same.
Post reply on HN