Porting a Core, DeMiSTified – Part 1 – 2020-02-24

There are many FPGA cores out there which could be ported to the Turbo Chameleon 64 cartridge. In some cases it’s just a question of somebody doing the legwork, in other cases it gets a little bit more involved – but can we do anything to make the amount of work required more manageable?

Long-time readers will know by now that I don’t ask that kind of question out loud unless I already know that the answer is yes!

The EightThirtyTwo ISA – Part 22 – 2020-05-04

What better way to celebrate Star Wars Day than with a multi-CPU code density shoot-out?! (Well, OK, most people can probably name a dozen better ways without even trying – but this is how I’m choosing to spend it!)

I was curious to know just how well the code density of EightThirtyTwo code generated by the VBCC backend stacks up against other architectures, so I compiled a fixed codebase, namely the OSD control module from one of the many Minimig variants, targetting 832, m68k, MIPS, OpenRISC, RISC-V ARM, and even i386 and x86-64. The results make for interesting reading…

The EightThirtyTwo ISA – Part 21 – 2020-04-12

One facility that’s so far been sorely missing from the EigthThirtyTwo CPU is any form of provision for on-chip debugging. That is about to change!

The EightThirty Two ISA – Part 20 – 2020-04-03

I’m continuing to make gradual improvements to the EightThirtyTwo toolchain, and over the last few days I’ve given my attention to linker libraries, and endian issues.

While I initially intended EightThirtyTwo to be a big endian CPU, it occurred to me early on that I could make endian-ness configurable with a generic parameter. This I did, and having set that “littleendian” parameter to “true” for testing, I never actually changed it back, so all my testing over the last few months has actually been in little endian mode!

The EightThirtyTwo ISA – Part 19 – 2020-03-25

One my main goals when starting the EightThirtyTwo project was to minimise the amount of block RAM I needed to devote to firmware; indeed, this was even more of a goal than was raw speed.

So how does the architecture measure up to that goal?

The EightThirtyTwo ISA – Part 19 – 2020-03-08

In my experiments a few days ago I noticed an odd problem with the EightThirtyTwo toolchain – namely that the following construct worked just fine:

char string[]="Hello, world!";

but the following didn’t:

char *string="Hello, world!";

The EightThirtyTwo ISA – part 18 – 2020-02-19

Having added partial results forwarding I figured I’d better check that I hadn’t broken dual-thread mode in the process. (Spoiler alert: I had!)

The EightThirtyTwo ISA – Part 17 – 2020-02-16

I was looking today at ways of improving the throughput of the EightThirtyTwo CPU. The design as it stands is very simple, and didn’t make any attempt to perform result forwarding or instruction fusing. These are both strategies for improving the performance of certain constructs, and I wasn’t sure which of these two techniques I should use.

In brief, without either mechanism implemented, when the CPU encounters code such as:

    li 0
    mr r0

it has to wait until the first instruction has finished writing to the tmp register before moving its new contents into the pipeline, and only then finally writing it to r0.

The EightThirtyTwo ISA – Part 16 – 2020-02-08

In my last post I touched briefly on the 832a assembler which I wrote as the first part of my solution to improving the code density of compiled C code.

An assembler that takes a single source file and spits out a ready-to-run binary file is not particularly difficult to write, but it’s not particularly useful either – in order to be useful we need to be able to link together multiple code modules.

Thus, 832a now has a cousin: 832l, the linker.