Save 2 bytes each in push and pop stack

[joshgoebel]

ADD supports a direct operand, so why not use it?

Also, what is the need for the 3 byte padding between stack frames?

[joshgoebel]

Oh, I get it now. You're leveraging the font functionality to help set the stack pointer. Any reason to not just do the math yourself (add/sub 15 to VE)?

You're also heavily dependent on your own implementation of static void _FX29() { uint16_t x = (op & 0x0F00) >> 8; I = 5 * v[x]; }. Since only 0-F are valid characters you could easily imagine a different implementation preventing the overflow with a bit mask: I = 5 * (v[x] & 0x0F). (and I think I've seen that in other implementations)

I suppose this is a few bytes smaller?

[glouw]

The funny thing about compilers is that one never remembers how they work (for the life of me I cannot even remember what any of these opcodes do!). I really do appreciate the pull request though. I'm going to review it in the coming weeks.

If memory serves me right, and I think you're right, pushing and popping abuses the font pointer to save V0-VE to ROM with the LD [I] instruction. I did do a writeup on it here: http://glouw.com/2018/03/05/C8C.html

Sadly it will either thrash the baked fonts, or the virtual machine itself if you were to run this on a COSMAC emulator like Emma 02 .

(As an aside, I wouldn't recommend writing a compiler by hand. This was really just an educational thing for myself. Tools like GNUBison are the way to go. I cannot recommend Bisqwit's tutorials on compilers enough: https://youtu.be/eF9qWbuQLuw).

[joshgoebel]

If memory serves me right, and I think you're right, pushing and popping abuses the font pointer to save V0-VE to ROM with the LD [I] instruction. I did do a writeup on it here: http://glouw.com/2018/03/05/C8C.html

Yes, the writeup was helpful.

I was just suggesting instead:

LD I, VE
LD [I], VE
ADD VE, 15

Feels purer to me - and more "correct" since we don't have an actual hardware spec for CHIP8. If it could be universally agreed that the "font load" DID/SHOULD overflow then the way you've done it is a pretty neat hack though (and the way it should be done, since it's 1-2 byte smaller).

Anyways the patch I submitted should work in any case.

I wouldn't recommend writing a compiler by hand.

It's fun though. I'm working on a Ruby-like (but not as dynamic) language that compiles down to CHIP8 now. I didn't realize someone had already done this with a C-like language though.

[glouw]

It certainly was a fun ride building this stuff. I used this for reference:

https://compilers.iecc.com/crenshaw/

It's in Pascal, but pascal translates well to anything.

[glouw]

Sadly, as for the 2 byte fix, I had a look over the opcode list: http://devernay.free.fr/hacks/chip8/C8TECH10.HTM

SUB is limited to [(8xy5) SUB Vx, Vy], but ADD supports direct values. Strange that they did that.

[joshgoebel]

Oh. Sorry. But it's all 8-bit math with wrap-around. SUB 15 just becomes ADD 240. Not that strange considering how easy it is. A nice compiler should really just support "sub Vx, #" as a virtual OP imho and then do the math for you.

[joshgoebel]

Updated the patch.