The EightThirtyTwo ISA – Part 11 – 2019-11-29

One of the first library functions to implement when experimenting with a new architecture is puts(), allowing the archetypal Hello World program to announce its presence.

The C standard printf() function is a bit trickier – for a number of reasons…

Firstly, printf() is a varargs function, so we have to define and then support calling conventions for varargs on the target architecture.

Secondly, we need to be able to convert integers to textual representations – in more than one base.

In the process of getting this working I have implemented a new instruction – “byt” which, similar to the previously-defined “hlf” instruction, modifies the storage size of the next load/store operation to operate on a byte rather than a full word. Previously, the only way of accessing bytes was via “ldbinc” or “stbinc” – both of which have automatic post-increment. These are easy enough to work with in assembler, but were a bit of pain for the C compiler backend. I now use “byt, st” when I don’t want the post-increment.

I’m also seriously considering replacing the now pretty-much redundant “sth” instruction with “stinc” – store with post-increment.

Anyhow, back to implementing printf(): Firstly, how do we implement varargs?

In order to answer that we need to have a clear understanding of how parameters are passed into functions in the first place.

Leaving aside possible future optimisations involving passing parameters in registers, parameters are pushed one at a time, in reverse order, onto the stack, so a invocation such as

printf("Meaning: %s, %d\n","(you're not going to like it)",42);

will translate to the following pseudo-code:

push 42
push (pointer to)"(you're not going to like it)"
push (pointer to)"Meaning: %s, %d\n"
call printf()

Since the stack grows downwards in memory, this means that once program flow is within the printf() function, the parameters can be accessed from the stack in ascending memory order. The simplest implementation of stdarg.h will thus take the address of the first argument (the pointer to the format string in this case) and store a pointer to the memory immediately following this. This pointer serves as a second pointer into the stack, and is incremented by the appropriate size every time we pick off a parameter to be printed.

Our simplistic stdarg.h looks like this:

typedef char *va_list;
#define va_start(ap,parmn) (void)((ap) = (char*)(&(parmn) + 1))
#define va_end(ap) (void)((ap) = 0)
#define va_arg(ap, type) (((type*)((ap) = ((ap) + sizeof(type))))[-1])

The va_arg() macro leaves one feeling like a castaway in a jungle of parentheses – but it increments ap by the size of the argument’s type, while at the same time reading an object of that type from the location pointed to by its old value!

Getting this working proved to be quite a challenge and shook out several different bugs in the backend in the process, but it does now seem to be working reliably.

So now we’re able to fetch varags from the stack, the next challenge is converting them to text.

Hexadecimal is relatively easy – we can simply bit-shift each 4-bit hex digit, and mask with “and”. Decimal, on the other hand, requires working division and modulo operations – neither of which are directly supported by our instruction set – so we need some division code.

Rather than create something from scratch I found some simple division code intended for ARM and translated it to EightThirtyTwo – this is what it looks like:

_div_u32byu32:
     stdec   r6
     mt  r3  // Save r3
     stdec   r6
     mt  r2
     and r2
     cond    EQ  // Division by zero?
          li  IMW0(PCREL(.end))
          add r7
     li  0
     mr  r0
     li  1
     mr  r3
.start:
     mt  r2
     cmp r1
     cond    SGT
         add r2  // Faster than lsl
         mt  r3
         add r3
         li IMW0(PCREL(.start))
         add r7
.next:
     mt  r2
     cmp r1
     cond    GE
         sub r1
         mt  r3
         add r0
         cond    EX
     li  1
     shr r2
     shr r3
     cond    NEQ
         li  IMW0(PCREL(.next))     add r7
.end:
     ldinc   r6
     mr  r3
     ldinc   r6
     mr  r7

I make that 37 bytes in total.

This routine takes the numerator in r1, denominator in r2 and returns both quotient and remainder – in r0 and r1 respectively, so the C backend just calls it and uses whichever result is appropriate – so the only detail to take care of is to make sure the division routine is linked with the binary.

The routine above only handles unsigned division – I have a signed variant which just keeps track of the signs, negating the operands and result as necessary – I just need to figure out how to handle the remainder in that situation!

The upshot is that the vbcc backend for EightThirtyTwo is now working weill enough that printf() – or rather a cut-down version of printf() that supports %s, %d, %x and %c format strings without modifiers – is now working nicely.