The EightThirtyTwo ISA – Part 14 – 2020-01-17

Here’s an optmisation I should have spotted much sooner: sign extension.

In the C programming language char and short types are converted to integers before being subjected to mathematical operations – so called “integer promotion”. There are circumstances where this can be avoided – and vbcc has a hook for precisely this purpose, allowing CPUs which have byte- or word-oriented versions of their arithmetic operations to avoid promotion. EightThirtyTwo doesn’t provide this luxury.

The EightThirtyTwo ISA – Part 13 – 2020-01-12

My project time over the last few weeks has been spent improving the vbcc backend for the EightThirtyTwo CPU, trying to find ways of making the generated code more efficient. Many of these changes have been simple tweaks, like avoiding sign-extensions when comparisons are only concerned with equality. I’ve also put some effort into recognising when a previous operation has left a value in the tmp register and thus when reloading it can be avoided.

The biggest improvement of all, however, has come from changing how the code generator handles loading and storing values. Previously I had reserved two GPRs – r0 and r1 – for the code generator, but on an architecture with only eight general purpose registers, one of which is the PC and one of which is busy being the stack, depriving the compiler of two registers hurts performance – so I’ve re-worked the code generator so that it reserves just one register for its own use.