New 8bit micro controller back-end

Hi all,

I’m new to LLVM dev mailling list and I’m starting to discover some aspects of LLVM.

Actually I’m looking for a solution to create a tool chain for my own chip (a 8bit micro controller processor) that include a compiler/linker/assembler toolset and a simulator/debugger.

From what I’ve read, LLVM is a good tool to implement a compiler for this proprietary platform, but I have the following questions:

  • Is there estimation (from your experiences) of the work required to implement a backend for a simple 8bits micro controller architecture (1 men-month, 10 or 100 ?)
  • Is it possible to create a debugger/simulator (at C and assembler level) with LLVM ?

Thanks for your help and advices

Regards

Guillaume

Hello Guillaume,

- Is there estimation (from your experiences) of the work required to
implement a backend for a simple 8bits micro controller architecture (1
men-month, 10 or 100 ?)

What is the instruction set of your microcontroller? How rich it is?
What is the architecture? Is it RISC-y?

Hello,

It is a RISC with around 60 instructions like a 80c51 instruction set (without mul/div) and with Direct or indirect memory acces.

There is a protected / user mode but the processor keep small and simple.

2009/11/23 Anton Korobeynikov <anton@korobeynikov.info>

Hello

It is a RISC with around 60 instructions like a 80c51 instruction set
(without mul/div) and with Direct or indirect memory acces.

My estimate is something like a man-week for a person, who knows what to do :slight_smile:

I guess the instruction set is pretty similar to msp430's for which we
already have a backend. In such situation you might just grab this
backend, remove all 16-bit stuff (basically, 8 bit and 16 bit are
quite "parallel" there) and tweak stuff a bit.

Ok great news but as currently I don’t have the “know what to do”, it would probably take longer…
I suppose your estimate only include backend update.

Can I have more detail about the Simulator/Debugger part(at an assembler level?) ? I’m not sure if LLVM is able to provide such functionalities.

2009/11/23 Anton Korobeynikov <anton@korobeynikov.info>

Our 8-bit port for PIC16 has taken roughly about 18 months to get to where we are now. Our instruction set is not orthogonal, data memory is banked, program memory is paged, there is only one accumulator and two pointer registers, and the use of indirect memory access is really expensive. So we had to implement some non conventional approaches to get the model working.

For the most part, LLVM generic optimizations (except for mem2reg kind of optimizations) reduce the code size pretty good and typical applications that we use for PIC16 fit in the memory without problem.

We use clang and LLVM just to generate assembly output. We have our own assembler, linker and debugger. In fact we have to implement some of our tricks in the linker and assembler in order to allow mix of C and assembly projects. If your users only want to use C, then you can probably use a lot more of the analysis capabilities of LLVM than what we use.

Our ABI and model of code generation is probably far from what you need, but you may find some tricks in our port that can be useful to you as well.

Regards

Ali

Thanks for this feedback, I think our chip architecture is between a PIC16 and a 8051.

You have written 18 months, but with how many developpers ?

I will take a look at the PIC16 LLVM port to have a better view of the work done and todo.

Regards

Guillaume

2009/11/23 <Alireza.Moshtaghi@microchip.com>

Hello

Our 8-bit port for PIC16 has taken roughly about 18 months to get to where
we are now. Our instruction set is not orthogonal, data memory is banked,
program memory is paged, there is only one accumulator and two pointer
registers, and the use of indirect memory access is really expensive. So we
had to implement some non conventional approaches to get the model working.

I assumed that the architecture in question is pretty similar to one
seen in msp430.
For something PIC16-like the time efforts are much higher, yes.

Can I have more detail about the Simulator/Debugger part(at an assembler
level?) ? I'm not sure if LLVM is able to provide such functionalities.

LLVM does not provide anything for this, so, you will need to write
all this from scratch.

That's pretty optimistic, even for someone who knows what to do.

The learning curve for TableGen is quite steep. I would budget at least a
year for everything; learning TableGen, writing patterns, custom lowering,
testing, etc.

And that's for a relatively simple, orthogonal ISA.

Of course this happens iteratively. You learn a little TableGen (mostly by
looking at existing backends and asking lots of questions), write a few
patterns, learn a little more and so on.

                                -Dave

Hello, David

That's pretty optimistic, even for someone who knows what to do.

It depends on the target. If it is pretty straightforward, than you
can do almost all the stuff automatically.
The estimate I provided was the real time for first working version
for msp430 backend.

If it is just 'normal' RISCy architecture and one should not care
about ABI weirdness (this is usually true for MCUs), then the estimate
is correct. You just provide patterns for all the operations, expand
everything unsupported. After that you need to write bunch of libcalls
and first version is ready :slight_smile:

Surely, optimization stuff & supporting of some "nice" features will
require much more time.

Which is straightforward once you know what you're doing. Before that
point, however, it's very non-trivial. Basically I'm saying our documentation
needs a lot of work. :slight_smile:

                               -Dave

Hello, David

Which is straightforward once you know what you're doing. Before that
point, however, it's very non-trivial. Basically I'm saying our documentation
needs a lot of work. :slight_smile:

Yeah. I'm even trying to fix the situation somehow... :wink:

It's improved a lot lately, thanks Anton! I am also trying to contribute
where I can.

                           -Dave

Hello

It is a RISC with around 60 instructions like a 80c51 instruction set
(without mul/div) and with Direct or indirect memory acces.

My estimate is something like a man-week for a person, who knows what to do
:slight_smile:

That's pretty optimistic, even for someone who knows what to do.

The learning curve for TableGen is quite steep. I would budget at least a
year for everything; learning TableGen, writing patterns, custom lowering,
testing, etc.

1 year is an eternity in LLVM year. ARM target was up and functional in about 2 months of time.

Evan

I won’t work at full time on this project and I fear the first week is used to read documentations :slight_smile:

The better way to have an idea is to start backend developement. I’ll try to work on this backend for a month and will see if I’m on the right way.

2009/11/24 Evan Cheng <evan.cheng@apple.com>

Hello, Guillaume

I won't work at full time on this project and I fear the first week is used
to read documentations :slight_smile:

Some advices:

1. There are some docs in llvm site
2. http://llvm.org/devmtg/2009-10/Korobeynikov_BackendTutorial.pdf
3. Look into existing backends. E.g. for msp430 & systemz all the
history of backend bringup was preserved in step-by-step fashion.

And after a year much of what you learned is going to be obsolete...

This is a form of a "patches are welcome" email. :slight_smile: But since you've been through a lot of the pains involved in learning TableGen, et al, your input to the documentation would be useful.

-bw

Yes, from people who already knew TableGen. And did that include testing and
all the stuff that goes into hardening and making it production-ready?

It's no sin to admit that TableGen is complex. It's a powerful tool.

                           -Dave