public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <jeffreyalaw@gmail.com>
To: Sophie 'Tyalie' Friedrich <dev@flowerpot.me>
Cc: GCC Development <gcc@gcc.gnu.org>
Subject: Re: Building a GCC backend for the STM8
Date: Sun, 28 Jan 2024 21:08:24 -0700	[thread overview]
Message-ID: <c8672cae-8f94-4425-8cb8-9f4f91d3c8af@gmail.com> (raw)
In-Reply-To: <d526a458-fd47-489a-9d0c-205c0e31ccaa@flowerpot.me>



On 1/27/24 20:41, Sophie 'Tyalie' Friedrich via Gcc wrote:
> Hello dear people,
> 
> I want to try building a GCC compiler backend for the STM8 
> micro-controller target in order to make this wonderful architecture 
> more accessible.
> 
> But as I'm fairly new in this area of building compiler backends for 
> GCC, I would need a bit of guidance / read material to get started. Do 
> you have recommendations for anything? And is there interest in such work?
There is a GCC internals manual which I would strongly recommend you 
read and keep handy.  It describes most of the basic concepts necessary 
to write a functioning machine description.

Second I would strongly recommend you start with an existing port for a 
chip that has similar characteristics.  If you make a good choice on 
ports to copy, this can dramatically reduce your development time.  GCC 
supports over 30 distinct families of processors.  If you're lucky one 
will map reasonably closely to the STM8.  Some processor families have 
had their ports removed due to lack of maintenance and lack of 
processors deployed in the wild.  Point being there may be older ports 
that match STM8 better than what's in the tree now.  I just don't know.

You're going to need an assembler, linker and libraries.  Those are not 
part of the compiler proper.  They are usually co-developed as part of 
doing a new port.  You'll probably want a debugger too.  The assembler, 
linker, binary utilities and debugger are the gdb-binutils project.  A C 
library can be found in the newlib-cygwin project.

If there is an existing compiler and you need/want to be compatible with 
calling conventions, then it's obviously advisable to get a copy of any 
ABI documentation that may be available.  Otherwise you'll have to get a 
copy of that other compiler and reverse-engineer the ABI.

GCC includes a significant testsuite.  For port bring-up, the c-torture 
tests are usually the most interesting, especially the compile and 
execution tests.

This will be a non-trivial project, almost certainly measured in months 
for an experienced GCC developer.  Good luck.

jeff

  parent reply	other threads:[~2024-01-29  4:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-28  3:41 Sophie 'Tyalie' Friedrich
2024-01-28 17:27 ` Marc
2024-01-29  4:08 ` Jeff Law [this message]
2024-01-30 12:07 ` Oleg Endo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c8672cae-8f94-4425-8cb8-9f4f91d3c8af@gmail.com \
    --to=jeffreyalaw@gmail.com \
    --cc=dev@flowerpot.me \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).