TCC (Tiny C Compiler) Port for AVR 8-bit architecture

Go To Last Post
16 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey fellas, I'm new here. Welcome me smiley

So, I've been working lately on porting TCC (Tiny C Compiler) to support AVR targets, and I must say, that's one hell of a compiler.

Here's a Github repo if you want to monitor the progress or check the code yourself https://github.com/mohamed-anwar/avr-tcc

 

What's working for now:

- Supported data types: char [1 Byte], (short) int [2 Bytes], pointer (partially)

- Basic arithmetic (addition/subtraction) on integer data types.

- Function calling (using register passed arguments only, no support for stack arguments yet)

 

The problem with TCC is that it's heavily oriented around 32-bit architectures, porting it to support 8-bit arch. is a stretch ... also it's a one pass compiler so achieving optimization would be tricky (I might have to write a 2nd pass optimizer, but that's for later).

 

Anyway contributions, suggestions and ideas are all welcome.

Cheers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Perhaps you should tell us why TCC.

 

Most here use GCC, (or commercial compilers), and don't plan to move.

 

If you want to make your "own" AVR compiler I would suggest LCC, at least for just working code it's a relative small process (small and efficient code is an other story).

 

  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The main "competitor" to GCC in open source compilers right now is clang/LLVM I would have thought. That's probably where it's worth putting "AVR effort" as it really is a challenger for GCC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Or SDCC. Less sexy, more 8-bit. A long-abandoned AVR port comes with the sources, but needs the register allocator to be rewritten from scratch.

 

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:
Perhaps you should tell us why TCC.

Yes - that was my though exactly!

 

Of course, "because it's there" can be a valid reason,  but it is helpful to understand motivation - especially when you yourself seem to be saying that it's a non-ideal starting point:

manwar wrote:
The problem with TCC is that it's heavily oriented around 32-bit architectures, porting it to support 8-bit arch. is a stretch ... also it's a one pass compiler...

But maybe you just like a challenge?!

 

 

clawson wrote:
... clang/LLVM ... really is a challenger for GCC

Purely out of interest, what makes you say that?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The Clang arguments are set out here:

 

https://clang.llvm.org/compariso...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I closely followed the decision making path of another software house who recently had to make up their mind on how to adapt their own compilers for a given architecture to the future (and new architectures they will port their main product to). After serious consideration of gcc, they went the LLVM/clang route for the backends.

Einstein was right: "Two things are unlimited: the universe and the human stupidity. But i'm not quite sure about the former..."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Simply put: Boredom.

I like how challenging it seems, personally I'm really satisfied with GCC and write the parts I really need to be WYSIWYG in assembly.

I think, however, that TCC could be a good choice for OTA updates in a system where AVR services as a microcontroller interface for another CPU (ARM possibly?) which is very limited in memory and computation power. While that's not a very good reason to dig deeper into TCC, if you combine it with my fascination of TCC (and Fabrice Bellard, seriously this guy rocks!) it wouldn't seem very counter-intuitive after all.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

manwar wrote:
I think, however, that TCC could be a good choice for OTA updates in a system where AVR services as a microcontroller interface for another CPU 

I don't see how choice of compiler - any compiler - is of any relevance there at all?

 

another CPU (ARM possibly?) which is very limited in memory and computation power

Err ... relative to an AVR, an ARM has virtually limit-less memory and computation power!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

manwar wrote:
I think, however, that TCC could be a good choice for OTA updates in a system where AVR services as a microcontroller interface for another CPU 

I don't see how choice of compiler - any compiler - is of any relevance there at all?

 

another CPU (ARM possibly?) which is very limited in memory and computation power

Err ... relative to an AVR, an ARM has virtually limit-less memory and computation power!

 

Compiling source on-chip instead of just flashing the binary (For context, I have home automation system based on ARM for web-services/computation and an abundance of different AVR MCUs, when pushing new changes to code the ARM processor triggers a build for all different chips connected to it, flashes them and viola!)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yet again. The entire thing is just because I was bored enough. There is no meaningful reason behind it, I like TCC, I like AVR, so let's put them together.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

manwar wrote:
Compiling source on-chip instead of just flashing the binary

Oh dear - that just prompts the "Why??" question again!

 

frown

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

manwar wrote:
Compiling source on-chip instead of just flashing the binary

Oh dear - that just prompts the "Why??" question again!

 

frown

 

The comment above puts it crystal clear xD ... there are no limits to where boredom may drive you. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Compiling C "on chip" on an AVR is an interesting ... challenge.   Not "obviously impossible" - CP/M machines with 64k (or less) used to run acceptable compilers (usually in multiple passes.  But still, you have 256k on an ATmega2560/)  Intermediate storage and RAM are likely to be problems;  programmers have forgotten how different a system with 48k of user RAM is from a system with 64k of ROM but only 8k of RAM.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think the OP is referencing a situation where the AVR is a satellite to (say) an ARM.  That ARM could then be used to rebuild and upload a new firmware image for the AVR.  Many people already do this with an RPi and an Arduino.

 

Our very own Bingo600 used to provide RPi builds of the Atmel toolchains whenever a Atmel released a new version.  I think the last one he did was 3.4.3:

http://www.avrfreaks.net/forum/new-raspi-toolchain-based-atmel-343

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]