Live data from Hacker News

C++14 for the Commodore 64 [video]

youtube.com

21–28 of 28 posts

Re: C++14 for the Commodore 64 [video]

#21

Static optimization to inlined code that ONLY handles immediate numbers and addresses is fine, and interesting to see the full pipeline working. But that possibility is there really for any language and any asm platform. I remember seeing Forth compile down to 6502 or other asm code, where it compiled down to the asm instructions a human would write for the same task, with basically zero language overhead. HOWEVER, t…

Personally, I'm interested in programming for the sound chip; maintaining multiple harmonies with varying ADSR and noise to try to get as much depth as possible.

I'm not a low-level developer, so my progress thus far trying to fit an experiment-able design into 6502 machine code has been pretty slow going. Any chance to get closer to C syntax, real variables names and nested structure is a welcome relief to me. Thanks for mentioning cc65, I had not discovered it yet.

Re: C++14 for the Commodore 64 [video]

#22
post #20

Static optimization to inlined code that ONLY handles immediate numbers and addresses is fine, and interesting to see the full pipeline working. But that possibility is there really for any language and any asm platform. I remember seeing Forth compile down to 6502 or other asm code, where it compiled down to the asm instructions a human would write for the same task, with basically zero language overhead. HOWEVER, t…

Yes. This doesn't strike me as an especially productive line of attack, but maybe I'm missing something (hopefully not obvious), maybe I'm just not imaginative enough, and/or maybe I'm underestimating how much effort people might be willing to put into such an endeavour. This did get me thinking about the problem a bit this evening though. The 6502 is an awful target for many higher-level languages, but I think you c…

cc65 (http://cc65.github.io/cc65/) is probably the most popular C compiler for the 6502, and its has support for many of the old home computers. I only use its assembler, since it's one of the most powerful, but I'm somewhat familiar with its C side of things.

I believe it uses a manual 16-bit stack pointer for frames, and zeropage for globals and statics. Pointers have to be copied into zeropage to be dereferenced, and I think it might have a numeric stack somewhere for intermediate results when evaluating numeric expressions. It's not super fast by any measure (simply due to impedance mismatch between C and 6502), but it does work and is quite mature.

As a side note, most 6502 Forths do use zeropage for the operand stack, with heavy use of zp,X addressing in their operators.

Re: C++14 for the Commodore 64 [video]

#23

The spec for C++14 wouldn't fit on a Commodore 64. At 1300 pages, it wouldn't even fit on external storage (170k floppies).

Yes because the code emitted by a compiler is directly proportional to the size of the specification? I fail to see the point.

  >I fail to see the point.
That's ok, you don't need to see everything.

Re: C++14 for the Commodore 64 [video]

#24
post #20

Static optimization to inlined code that ONLY handles immediate numbers and addresses is fine, and interesting to see the full pipeline working. But that possibility is there really for any language and any asm platform. I remember seeing Forth compile down to 6502 or other asm code, where it compiled down to the asm instructions a human would write for the same task, with basically zero language overhead. HOWEVER, t…

Yes. This doesn't strike me as an especially productive line of attack, but maybe I'm missing something (hopefully not obvious), maybe I'm just not imaginative enough, and/or maybe I'm underestimating how much effort people might be willing to put into such an endeavour. This did get me thinking about the problem a bit this evening though. The 6502 is an awful target for many higher-level languages, but I think you c…

I don't think many people would write code like that by hand, but it's not completely insane given the requirements

Typically if you were programming for the 6502 back in the day, you would build up a rather large macro library to make things simpler.

Re: C++14 for the Commodore 64 [video]

#25

Earlier quoted context omitted.

Yes because the code emitted by a compiler is directly proportional to the size of the specification? I fail to see the point.

>I fail to see the point. That's ok, you don't need to see everything.

Humor me then. What's the point?

Re: C++14 for the Commodore 64 [video]

#26
post #21

Static optimization to inlined code that ONLY handles immediate numbers and addresses is fine, and interesting to see the full pipeline working. But that possibility is there really for any language and any asm platform. I remember seeing Forth compile down to 6502 or other asm code, where it compiled down to the asm instructions a human would write for the same task, with basically zero language overhead. HOWEVER, t…

Personally, I'm interested in programming for the sound chip; maintaining multiple harmonies with varying ADSR and noise to try to get as much depth as possible. I'm not a low-level developer, so my progress thus far trying to fit an experiment-able design into 6502 machine code has been pretty slow going. Any chance to get closer to C syntax, real variables names and nested structure is a welcome relief to me. Thank…

cc65 will certainly scratch the itch you've got. Since control of the sound chip doesn't require super fast code, the significant overhead of running C on a 6502 won't be an issue, and you'll be in a familiar environment.

However, there are also lots of music editors for the C64, both native and running on PCs, that can give you very fine grained control of the SID without programming. I believe GoatTracker is highly regarded, but there are lots.

Re: C++14 for the Commodore 64 [video]

#27
post #5

Earlier quoted context omitted.

There already seems to be a 6502 backend for LLVM specifically geared for c64: https://github.com/c64scene-ar/llvm-6502 Which means you can just use the clang frontend and even write C++17 code which compiles down to 6502 ML.

I was unable to get any of the existing 3 llvm 6502 backends to produce reasonable code. Which is why I went this route. I meant to mention that in the video...

By reasonable code do you mean performant, or just plain working?

Re: C++14 for the Commodore 64 [video]

#28
post #27
post #5

Earlier quoted context omitted.

I was unable to get any of the existing 3 llvm 6502 backends to produce reasonable code. Which is why I went this route. I meant to mention that in the video...

By reasonable code do you mean performant, or just plain working?

If I had to guess, now knowing that there's a crushing stack size limitation for 6502 CPU, probably "just plain working."
Post reply on HN