Live data from Hacker News

Explaining my fast 6502 code generator

pubby.games

21–30 of 52 posts

Re: Explaining my fast 6502 code generator

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

Re: Explaining my fast 6502 code generator

#22
post #19
post #18

Earlier quoted context omitted.

Wow you really are into telling people what they should do.

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

[deleted]

Re: Explaining my fast 6502 code generator

#23
post #8

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.

Who in their right mind would self host 6502 development?

Re: Explaining my fast 6502 code generator

#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 word of a 4K page... :-(

Re: Explaining my fast 6502 code generator

#25
post #19
post #18

Earlier quoted context omitted.

Wow you really are into telling people what they should do.

> 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

#27
post #11

Earlier quoted context omitted.

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?

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.

Okay, here's an article about calculating e to 116,000 digits on an Apple ][: https://archive.org/download/Apple_2_Woz_e_Calc_1981/Apple_2...> (warning, PDF!). I found it interesting to read, even though I never owned an Apple ][, nor did I ever own a 6502-based computer (well, except for the Atari 2600). I was, however, able to apply the techniques to computers I did own (6809 and 8088 based).

Re: Explaining my fast 6502 code generator

#28
post #23
post #8

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.

Who in their right mind would self host 6502 development?

Plenty of teenagers in the 80s writing games for the various home computers at the time (Apple ][, Atari 400 & 800, Commodore 64).

Re: Explaining my fast 6502 code generator

#29

> my compiler generates faster code than GCC, LLVM, and every other compiler I compared it to GCC and LLVM can target the 6502?!?

For LLVM, I don’t think it’s in the official repo, but yes: https://github.com/llvm-mos/llvm-mos

I think it's possible LLVM-MOS gets into mainline LLVM eventually. The devs have done a good job getting all the kinks ironed out.

BTW, mysterymath, one of the most prominent LLVM-MOS contributors, left this comment on their current code gen. (I'm posting it here for visibility):

"In LLVM-MOS, we mainly struggle with its register allocator; the rest of the backend is really quite reasonable. The "Greedy register allocator" in LLVM is a just finely tuned priority allocator with nice live-range splitting. It works great for zero page cache locations, but it's just not tuned very well for tight register classes like those involving the processor's three architectural registers. I've half a mind to implement Hack's SSA-based register allocator in LLVM to use on A, X, and Y; this would clean up the oodles of spurious copies LLVM-MOS spits out in the worst cases."

Re: Explaining my fast 6502 code generator

#30
post #28
post #23

Earlier quoted context omitted.

Who in their right mind would self host 6502 development?

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 contemporaries did not have

The floppies helped immensely with self-hosted development of larger programs. Imagine losing all your assembler work due to a crash running it because it was tempting to skip rhe time of several minutes saving to tape. Floppies were reasonably fast for saving before running things, but few people I knew had them.

It also gained a Z80 second processor (an add-on; and later a 68000), so rhe Z80 helped with development of 6502 code, as a RAM disk and editing scratchpad that survived 6502 crashes. And for running Wordstar, which was a decent editor.

Eventually I had someone else's ZX Spectrum hooked up to the BBC with a kind of home-made bit-banging serial port. That's when things started getting fancy, as my BBC's Z80 second processor's flavour of BBC BASIC could assemble Z80 code for the Spectrum, and run some Z80 binaries from other people's Spectrum software, with the BBC's 6502 providing display and sound emulation.

Post reply on HN