x86_64 machine code (linux),
175 99 76 bytes
400080: 66 bf 09 00 mov $0x9,%di
400084: 6a 0a pushq $0xa
400086: 89 fe mov %edi,%esi
400088: 89 f0 mov %esi,%eax
40008a: f7 e7 mul %edi
40008c: 6a 20 pushq $0x20
40008e: 3c 0a cmp $0xa,%al
400090: 7d 02 jge 400094 <_printInteger.L1>
400092: 6a 20 pushq $0x20
400094: 66 31 d2 xor %dx,%dx
400097: b3 0a mov $0xa,%bl
400099: 66 f7 f3 div %bx
40009c: 83 c2 30 add $0x30,%edx
40009f: 52 push %rdx
4000a0: 66 85 c0 test %ax,%ax
4000a3: 75 ef jne 400094 <_printInteger.L1>
4000a5: 6a 3d pushq $0x3d
4000a7: 66 57 push %di
4000a9: 80 04 24 30 addb $0x30,(%rsp)
4000ad: 6a 78 pushq $0x78
4000af: 66 56 push %si
4000b1: 80 04 24 30 addb $0x30,(%rsp)
4000b5: ff ce dec %esi
4000b7: 75 cf jne 400088 <_table.L3>
4000b9: ff cf dec %edi
4000bb: 75 c7 jne 400084 <_table.L2>
4000bd: 66 ba 00 08 mov $0x800,%dx
4000c1: b0 01 mov $0x1,%al
4000c3: 66 bf 01 00 mov $0x1,%di
4000c7: 48 89 e6 mov %rsp,%rsi
4000ca: 0f 05 syscall
This is a dump of the binary file, and all of this is 175 bytes. It basically does the same two loops that all the answers do, but printing to the console is a bit harder and basically requires pushing the characters to print onto the stack in reverse, and then making a (linux specific) syscall to actually put those chars into stdout.
I've now optimized this so that only 1 write operation is performed (faster!) and has magic numbers (wow!) and by pushing the entire result onto the stack backwards before making the syscall. I also took out the exit routine because who needs proper exit code?
Here's a link to my first and second attempts, in their original nasm syntax.
I welcome anyone who has any other suggestions on how it can be improved. I can also explain the logic in more detail if anyone is curious.
(Also, it doesn't print the extra spaces to make all the columns aligned, but if that's required I can put the logic in at the cost of a few more bytes).
EDIT: Now prints extra spaces and is golfed down even more! It's doing some pretty crazy stuff with the registers, and is probably unstable if this program were to be expanded.
forloops? Where's the challenging (interesting) part? \$\endgroup\$
for. Ok, I use