| |
Martin Piper
Registered: Nov 2007
Posts: 634 |
A Simple Commodore 64 Game in C++17
CppCon 2016: Jason Turner Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17
https://www.youtube.com/watch?v=zBkNBP00wJE
Rather interesting to watch the compiler in action from: https://youtu.be/zBkNBP00wJE?t=747 |
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
1:20h of stating the obvious ;_; |
| |
Mr. SID
Registered: Jan 2003
Posts: 421 |
Yes, we all know that C++ can be used as a glorified macro language. :)
Still doesn't really help though, it doesn't really make anything easier. |
| |
MagerValp
Registered: Dec 2001
Posts: 1055 |
I thought it was a thoroughly enjoyable demo of zero cost abstractions. The point was obviously not that you should use C++ to write C64 code. |
| |
Mr. SID
Registered: Jan 2003
Posts: 421 |
Exactly. The C64 part didn't really add anything. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
I think one of the questions from the audience had the most relevance: "how do you ensure the optimizations and abstractions stay at zero overhead when the compiler, optimizer and transpiler evolves". You don't which is, for the target platform, critical in this case. Hence, interesting techniques but really not worth it imo. |
| |
Danzig
Registered: Jun 2002
Posts: 428 |
Quote: I think one of the questions from the audience had the most relevance: "how do you ensure the optimizations and abstractions stay at zero overhead when the compiler, optimizer and transpiler evolves". You don't which is, for the target platform, critical in this case. Hence, interesting techniques but really not worth it imo.
but in real life: this is how treu love was done :-D |
| |
MagerValp
Registered: Dec 2001
Posts: 1055 |
@Mr. SID: It added hard limitations and a fun demo. C64 light saber pong is a lot more interesting than some modern 8-bit microcontroller board.
@JackAsser: That was indeed the best question, pity he didn't answer it. One forgotten const or changed optimization and your code explodes. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
The use of 32bit x86 as an IR was an interesting decision. I wonder if there are any 16 bit llvm targets that would have been a better fit? Admittedly the x86 code generator's probably the most mature at this stage. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
both gcc and llvm backend are targetted at 32bit CPUs.... and all the hacks that try to generate 16 or even 8bit code are really ugly, and result in really ugly code - thats why probably :) |
| |
MagerValp
Registered: Dec 2001
Posts: 1055 |
ARM support is also mature and battle tested, and I would've thought that thumb would be better suited as IR on the way to 6502. Still, for the purpose of the talk i386 worked just as well. |
| |
Mr. SID
Registered: Jan 2003
Posts: 421 |
I guess that's not helpful because:
Quote:
Thumb has all the advantages of a 32-bit core:
32-bit address space
32-bit registers
32-bit shifter, and Arithmetic Logic Unit (ALU)
32-bit memory transfer.
Only the opcodes are 16bit, so you still have all the same problems you have on x86. |
| |
Peacemaker
Registered: Sep 2004
Posts: 243 |
grrr. fuck you commodore, why didnt you make this machine 32bit? so c++ would be more useable :( |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Quote: grrr. fuck you commodore, why didnt you make this machine 32bit? so c++ would be more useable :(
😂😂😂 |
| |
MagerValp
Registered: Dec 2001
Posts: 1055 |
Quoting Mr. SIDOnly the opcodes are 16bit, so you still have all the same problems you have on x86.
Well except the ARM instruction set is actually sane :) |
| |
TWW
Registered: Jul 2009
Posts: 541 |
I watched the presentation and got inspired to code this manually.
However the original contained some things I wanted to improve and still see if the result (size / # of instructions) could match the compiler. These are the points which were improved:
- start with RUN command OR autorun (added)
- No clear screen when stared (Implemented)
- Border color not set (Implemented)
- Use full screen size instead of 256 pixels (9 bit arithmics vs 8 bit) (Implemented)
- Ball getting stuck bug when bouncing off a player if it still has collision detected. (Fixed)
- Decimal score to 99 (Implemented)
- Limit player top & bottom (min/max Y) (Fixed)
- 1 player sprite-colour not set (same as background) (Fixed)
- Reset both ball and player position after a miss. (Implemented)
- Cosmetic - moved the score away from the screen centre (Implemented)
The result ended up as follows (original values obtained from the presentation):
Original x86 (No idea of the compiled size):
- Compiled: 83 x86 instructions - excluding boilerplate (graphics)
- Compiled: 231 x86 instructions total incl. gfx
Compiled: 419 x6510 instructions total
- 126 bytes of graphics written => 2 instructions each byte = 252
- 419 - 252 = 167 instructions for gamecode (estimated)
compiled: 1005 bytes (6510)
- Graphics = 5 x 126 = 630b
- 1005 - 630 = 375 bytes without graphics (estimated).
After adding the improvements above I ended up with:
hand coded Size excl. gfx: 301 bytes vs 375 bytes
hand coded size Incl. gfx: 390 bytes vs 1005 bytes
hand coded excl. gfx: 115 Instructions vs 167 Instructions
hand coded incl. gfx: 139 Instructions vs 419 Instructions
At least some improvement. Actually only 32 instructions more than the x86 version looking only at the game code. |
| |
hedning
Registered: Mar 2009
Posts: 4595 |
A Simple Commodore 64 Game in C++17 |
