micro mips/mips32

The micro mips processor assembly language is basically 100% the same as mips32/mips64.
There are some assembler directives you add but for a base port, but that is all you need to do.

However, the binary instruction encoding is entirely different. There are a combination of 16 and 32 bit instruction encodings.

The question is, what's the best way to handle this?

Extending tablegen ?

You would want a single instruction to have multiple encodings dependent on the current mode we are compiler for.

Thoughts?

reed

The instructions are defined by their encodings, not the assembly syntax. You want separate instruction definitions for the different encodings and select. Between them in the assembler via sub target features. See ARM handling of thumb vs thumb2 vs arm for examples of how to do this.

The problem is that everything about the mips32 and micro mips 16 instruction is the same, aside from the encoding in to binary.

Seems like maybe we need to extend the notion of an instruction so that it can have alternate encodings depending on subtarget.

My understanding was that micro mips was similar to Thumb2, in that the smaller encodings have constraints on which registers can be read/written, because of the narrowing of the register fields in the encoding.

If that's the case, then it definitely makes sense to model the micro mips instruction set as distinct from the mips32 instruction set, in basically the same way that Thumb2 is done. The reason for this is this: in micro mips mode, you're going to need to split each opcode with a 16-bit variant (say, ADD) into two versions: the 16-bit version with constrained input/output registers, and the 32-bit version with unconstrained registers. Since this distinction doesn't exist in mips32, you'll want to have them entirely guarded under a micromips subtarget.

This really is almost exactly the same situation as Thumb2 on ARM. I strongly suggest you look at how it's implemented there.

--Owen

Micro mips is really 100% .s compatible with mips32.

There are no register field size constraints and such.

It's a strict superset of mips32. For the gcc port, the assembler is basically the only thing we changed.

The gcc port was just adding the ".micromips" directive to the .s file and maybe some tiny
driver work.

That is the quandary.

The entire .td file would have to be duplicated and just the instruction binary encoding changed.

Mips16 ,which is what I am almost finished with (base port), is more different and has a lot of restrictions and we followed some of the ideas in the Arm port as you describe.

There are some micro mips optimizations that can be done to make smaller code size but it's not needed for any kind of base port.

So, I'm thinking that maybe tablegen could be extended to allow for alternate instruction encoding.

We could also make some kind of tablegen front end macros.

I'm floating this email to elicit ideas on how we could approach the direct object emission problem.

The basic port to micro mips producing .s files is probably one weeks work at most.

Micro mips is really 100% .s compatible with mips32.

There are no register field size constraints and such.

It's a strict superset of mips32. For the gcc port, the assembler is basically the only thing we changed.

In LLVM, the assembler is integrated into the compiler. This is one major reason that duplicating the entire instruction set is the right thing to do.

The entire .td file would have to be duplicated and just the instruction binary encoding changed.

Right, I suspect a large amount of code was added to gas to support micromips, right?

-Chris