Initialize the Pong sprite data at compilation time, and adjust the translation.

[dr-m]

Instead of generating code for initializing the sprite data, initialize the sprite data as compile-time constants. Adjust the translation for the x86 code generated by clang version 4.0.0-svn279916-1 (Debian GNU/Linux unstable).

TODO: Generate a Commodore program file, and test this. Add precise instructions or a script for building the examples.

[dr-m]

There was an extra level of indirection in my implementation of movl with a 16-bit operand in my 2nd commit, which I removed in the 3rd commit. Instead of referring to label and label+1, we must use #<label and #>label.
I successfully tested the translation by manually adapting the output for the DASM assembler, deleting some directives and converting the .asciz to hexadecimal. I used the starting address 0x900 (SYS2304), which caused the sprites to be located at 0xb00 and 0xb40.

[dr-m]

I rebased the fork. The first commit fixes the x86-to-6502 compiler, and the second one updates the example, using the C++11 alignas() attribute in the VIC_II::Sprite declaration.

[dr-m]

For what it is worth, I tried writing a constexpr VIC_II::Sprite::Sprite() constructor. I would change the type of VIC_II::Sprite::memory to std::array<uint8_t,63> and then use a variadic template to initialize a std::tuple of 63 uint8_t, and finally convert it to the std::array using some code from here: http://stackoverflow.com/questions/10604794/convert-stdtuple-to-stdarray-c11
The result was not only an insanely long compilation time, but also worse code. A subroutine _GLOBAL__sub_I_… would be generated for initializing the compile-time constant data.

[dr-m]

Finally, I figured out that by creating a template<bool multicolor> struct VIC_II::SpriteLine { uint8_t line[3]; } I can convert sprite data one line at a time, either using a 24-digit binary constant for multicolor=false, or using a 12-digit hexadecimal constant for multicolor=true (wasting 2 of each 4 bits). The constexpr SpriteLine constructor would convert the integer constant to 3 bytes. The Sprite<multicolor> would encapsulate an array of 21 SpriteLine<multicolor>.
With this arrangement, the sprite data will be compile-time constant even when using GCC and even when it is declared inside a function. (GCC 6.2.0 failed to compile the whole program; I tested by disabling some parts and specifying -std=c++14.)

[lefticus]

I've merged the branch, but the #< assembler syntax needs better support if it requires post processing of the assembly output

[dr-m]

Thanks for merging this!
The unary < and > operators for extracting the least significant and the most significant byte of a 16-bit word are implemented in all 6502 assemblers that I know of. I guess that this convention was borrowed from the Motorola 6800. The documentation of the TMPx assembler which you apparently used at http://turbo.style64.org/docs/turbo-macro-pro-tmpx-syntax contains an example of passing a 16-bit address to a puts-like system call ($ab1e in the Commodore 64 BASIC interpreter).
I had to postprocess the output, because the assembler that I used (dasm or xa65) did not support .asciz or some directives in the file preamble. (For what it is worth, the Debian archive includes xa65 but neither dasm or TMPx.)
It seems to me that x86-to-6502 should drop the leading $ from labels, because that prefix is equivalent to the C 0x prefix in all 6502 assemblers that I know of. While some 6502 assembler might be tweaked to accept lda #<$_ZL4sBat, other labels, such as ab1e, could be mistaken for a hexadecimal constant.
Perhaps an issue should be opened to introduce a command line switch to x86-to-6502 for choosing the 6502 assembler dialect.