Re: gcc tricore porting

Re: gcc tricore porting

[Mikael Pettersson]

(Note I'm reading the gcc mailing list via the Web archives, which
doesn't let me
create "proper" replies. Oh well.)

On Sun Jun 18 09:58:56 GMT 2023, <eterno.claudio@gmail.com> wrote:
> Hi, this is my first time with open source development. I worked in
> automotive for 22 years and we (generally) were using tricore series for
> these products. GCC doesn't compile on that platform. I left my work some
> days ago and so I'll have some spare time in the next few months. I would
> like to know how difficult it is to port the tricore platform on gcc and if
> during this process somebody can support me as tutor and... also if the gcc
> team is interested in this item...

https://github.com/volumit has a port of gcc + binutils + newlib + gdb
to Tricore,
and it's not _that_ ancient. I have no idea where it originates from
or how complete
it is, but I do know the gcc-4.9.4 based one builds with some tweaks.

I don't know anything more about it, I'm just a collector of cross-compilers for
obscure / lost / forgotten / abandoned targets.

/Mikael

Re: gcc tricore porting

[Joel Sherrill]

[-- Attachment #1: Type: text/plain, Size: 1474 bytes --]

On Mon, Jun 19, 2023, 10:36 AM Mikael Pettersson via Gcc <gcc@gcc.gnu.org>
wrote:

> (Note I'm reading the gcc mailing list via the Web archives, which
> doesn't let me
> create "proper" replies. Oh well.)
>
> On Sun Jun 18 09:58:56 GMT 2023, <eterno.claudio@gmail.com> wrote:
> > Hi, this is my first time with open source development. I worked in
> > automotive for 22 years and we (generally) were using tricore series for
> > these products. GCC doesn't compile on that platform. I left my work some
> > days ago and so I'll have some spare time in the next few months. I would
> > like to know how difficult it is to port the tricore platform on gcc and
> if
> > during this process somebody can support me as tutor and... also if the
> gcc
> > team is interested in this item...
>
> https://github.com/volumit has a port of gcc + binutils + newlib + gdb
> to Tricore,
> and it's not _that_ ancient. I have no idea where it originates from
> or how complete
> it is, but I do know the gcc-4.9.4 based one builds with some tweaks.
>


https://github.com/volumit/package_494 says there is a port in process to
> gcc 9. Perhaps digging in and assessing that would be a good start.
>

One question is whether that code has proper assignments on file for
ultimate inclusion. That should be part of your assessment.

--joel

>

I don't know anything more about it, I'm just a collector of
> cross-compilers for
> obscure / lost / forgotten / abandoned targets.
>
> /Mikael
>

Re: gcc tricore porting

[Richard Earnshaw (lists)]

On 03/07/2023 15:34, Joel Sherrill wrote:
> On Mon, Jul 3, 2023, 4:33 AM Claudio Eterno <eterno.claudio@gmail.com>
> wrote:
> 
>> Hi Joel, I'll give an answer ASAP on the newlib and libgloss...
>> I supposed your question were about the licences question on newlib,
>> instead you were really asking what changed on the repo libs...
>>
> 
> It was a bit of both. If they put the right licenses on the newlib and
> libgloss ports, you should be able to use them and eventually submit them.
> But GCC, binutils, and gdb would be gpl and require an assignment to the
> FSF. That is all I meant.

It's not quite as restricted as that.  For GCC, I suggest reading 
https://gcc.gnu.org/contribute.html#legal for more details.

I think there are similar processes in place for binutils as well.  (I'm 
not quite so sure for GDB).

R.

> 
> An option here is to reach out to the authors and ask if they are willing
> to do the FSF assignment. If they are, then any GPL licensed code from them
> might be a baseline.
> 
> It looks like their current products may be based on LLVM.
> 
> --joel
> 
> 
> C.
>>
>>
>> Il giorno dom 2 lug 2023 alle ore 19:53 Claudio Eterno <
>> eterno.claudio@gmail.com> ha scritto:
>>
>>> Hi Joel, can you give me more info regarding newlib or libgloss cases?
>>> Unfortunately I'm a newbie on th9is world...
>>> Thank you,
>>> Claudio
>>>
>>> Il giorno dom 2 lug 2023 alle ore 17:38 Joel Sherrill <joel@rtems.org>
>>> ha scritto:
>>>
>>>>
>>>>
>>>> On Sun, Jul 2, 2023, 3:29 AM Claudio Eterno <eterno.claudio@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi, Joel and Mikael
>>>>> taking a look at the code it seems that the repo owner is higtech
>>>>> <https://hightec-rt.com/> but we have no confirmations.
>>>>> In fact, after a comparison with gcc 9.4.0 original files i see this on
>>>>> a lot of ("WITH_HIGHTEC") [intl.c]:
>>>>> [image: image.png]
>>>>> Probably this version of gcc is a basic version of their tricore-gcc
>>>>> and probably works fine but that repo doesn't show any extra info.
>>>>> Seems also impossible to contact the owner (that account doesn't show
>>>>> any email or other info)..
>>>>> Honestly with these conditions, from gcc development point of view,
>>>>> that repo has no value.
>>>>>
>>>>
>>>> Without an assignment, you can't submit that code. That's a blocker on
>>>> using it if there isn't one.
>>>>
>>>> But you can file an issue against the repo asking questions.
>>>>
>>>>
>>>> Anyway this is a good starting point...
>>>>>
>>>>
>>>> Maybe not if you can't submit it. Anything that needs to be GOL licensed
>>>> and owned by the FSF is off limits.
>>>>
>>>> But areas with permissive licenses might be ok if they stuck with those.
>>>> Look at what they did with newlib and libgloss.
>>>>
>>>> --joel
>>>>
>>>>
>>>>> C.
>>>>>
>>>>>
>>>>>
>>>>> Il giorno lun 19 giu 2023 alle ore 18:55 Joel Sherrill <joel@rtems.org>
>>>>> ha scritto:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jun 19, 2023, 10:36 AM Mikael Pettersson via Gcc <
>>>>>> gcc@gcc.gnu.org> wrote:
>>>>>>
>>>>>>> (Note I'm reading the gcc mailing list via the Web archives, which
>>>>>>> doesn't let me
>>>>>>> create "proper" replies. Oh well.)
>>>>>>>
>>>>>>> On Sun Jun 18 09:58:56 GMT 2023, <eterno.claudio@gmail.com> wrote:
>>>>>>>> Hi, this is my first time with open source development. I worked in
>>>>>>>> automotive for 22 years and we (generally) were using tricore
>>>>>>> series for
>>>>>>>> these products. GCC doesn't compile on that platform. I left my
>>>>>>> work some
>>>>>>>> days ago and so I'll have some spare time in the next few months. I
>>>>>>> would
>>>>>>>> like to know how difficult it is to port the tricore platform on
>>>>>>> gcc and if
>>>>>>>> during this process somebody can support me as tutor and... also if
>>>>>>> the gcc
>>>>>>>> team is interested in this item...
>>>>>>>
>>>>>>> https://github.com/volumit has a port of gcc + binutils + newlib +
>>>>>>> gdb
>>>>>>> to Tricore,
>>>>>>> and it's not _that_ ancient. I have no idea where it originates from
>>>>>>> or how complete
>>>>>>> it is, but I do know the gcc-4.9.4 based one builds with some tweaks.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> https://github.com/volumit/package_494 says there is a port in
>>>>>>> process to gcc 9. Perhaps digging in and assessing that would be a good
>>>>>>> start.
>>>>>>>
>>>>>>
>>>>>> One question is whether that code has proper assignments on file for
>>>>>> ultimate inclusion. That should be part of your assessment.
>>>>>>
>>>>>> --joel
>>>>>>
>>>>>>>
>>>>>>
>>>>>> I don't know anything more about it, I'm just a collector of
>>>>>>> cross-compilers for
>>>>>>> obscure / lost / forgotten / abandoned targets.
>>>>>>>
>>>>>>> /Mikael
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Claudio Eterno
>>>>> via colle dell'Assietta 17
>>>>> 10036 Settimo Torinese (TO)
>>>>>
>>>>
>>>
>>> --
>>> Claudio Eterno
>>> via colle dell'Assietta 17
>>> 10036 Settimo Torinese (TO)
>>>
>>
>>
>> --
>> Claudio Eterno
>> via colle dell'Assietta 17
>> 10036 Settimo Torinese (TO)
>>
> 

Re: gcc tricore porting

[Alexander Monakov]

On Mon, 19 Jun 2023, Mikael Pettersson via Gcc wrote:

> (Note I'm reading the gcc mailing list via the Web archives, which
> doesn't let me create "proper" replies. Oh well.)

(there's a public-inbox instance at https://inbox.sourceware.org/gcc/
but some messages are not available there)

Alexander

gcc tricore porting

[Claudio Eterno]

[-- Attachment #1: Type: text/plain, Size: 558 bytes --]

Hi, this is my first time with open source development. I worked in
automotive for 22 years and we (generally) were using tricore series for
these products. GCC doesn't compile on that platform. I left my work some
days ago and so I'll have some spare time in the next few months. I would
like to know how difficult it is to port the tricore platform on gcc and if
during this process somebody can support me as tutor and... also if the gcc
team is interested in this item...
Claudio
-- 
Claudio Eterno
via colle dell'Assietta 17
10036 Settimo Torinese (TO)

Re: gcc tricore porting

[Richard Biener]

On Sun, Jun 18, 2023 at 12:00 PM Claudio Eterno via Gcc <gcc@gcc.gnu.org> wrote:
>
> Hi, this is my first time with open source development. I worked in
> automotive for 22 years and we (generally) were using tricore series for
> these products. GCC doesn't compile on that platform. I left my work some
> days ago and so I'll have some spare time in the next few months. I would
> like to know how difficult it is to port the tricore platform on gcc and if
> during this process somebody can support me as tutor and... also if the gcc
> team is interested in this item...

We welcome ports to new architectures.  Quick googling doesn't find me
something like an ISA specification though so it's difficult to assess the
complexity of porting to that architecture.  If you know other embedded
archs and can identify one with similar features and restrictions the
easiest is to look at an existing port to such similar architecture.

Richard.

> Claudio
> --
> Claudio Eterno
> via colle dell'Assietta 17
> 10036 Settimo Torinese (TO)

Re: gcc tricore porting

[Michael Matz]

[-- Attachment #1: Type: text/plain, Size: 1525 bytes --]

Hello,

On Mon, 19 Jun 2023, Richard Biener via Gcc wrote:

> On Sun, Jun 18, 2023 at 12:00 PM Claudio Eterno via Gcc <gcc@gcc.gnu.org> wrote:
> >
> > Hi, this is my first time with open source development. I worked in
> > automotive for 22 years and we (generally) were using tricore series for
> > these products. GCC doesn't compile on that platform. I left my work some
> > days ago and so I'll have some spare time in the next few months. I would
> > like to know how difficult it is to port the tricore platform on gcc and if
> > during this process somebody can support me as tutor and... also if the gcc
> > team is interested in this item...
> 
> We welcome ports to new architectures.  Quick googling doesn't find me
> something like an ISA specification though so it's difficult to assess the
> complexity of porting to that architecture.

https://en.wikipedia.org/wiki/Infineon_TriCore
https://www.infineon.com/dgdl/TC1_3_ArchOverview_1.pdf?fileId=db3a304312bae05f0112be86204c0111

CPU part looks like fairly regular 32bit RISC.  DSP part seems quite 
normal as well.  There even was once a GCC port to Tricore, version 3.3 
from HighTec (now part of Infineon itself), but not even the wayback 
machine has the files for that anymore:

https://web.archive.org/web/20150205040416/http://www.hightec-rt.com:80/en/downloads/sources.html

Given the age of that port it's probably better to start from scratch 
anyway :)  (the current stuff from them/Infineon doesn't seem to be 
GCC-based anymore?)


Ciao,
Michael.

Re: gcc tricore porting

[Claudio Eterno]

[-- Attachment #1: Type: text/plain, Size: 2077 bytes --]

Hi Michael
in your reply you mentioned "DSP". Do you want to use the DSP instructions
for final assembly?
Michael, based on your experience, how much time is necessary to release
this porting?
And.. have you any idea about where to start?

Ciao
Claudio

Il giorno lun 19 giu 2023 alle ore 16:16 Michael Matz <matz@suse.de> ha
scritto:

> Hello,
>
> On Mon, 19 Jun 2023, Richard Biener via Gcc wrote:
>
> > On Sun, Jun 18, 2023 at 12:00 PM Claudio Eterno via Gcc <gcc@gcc.gnu.org>
> wrote:
> > >
> > > Hi, this is my first time with open source development. I worked in
> > > automotive for 22 years and we (generally) were using tricore series
> for
> > > these products. GCC doesn't compile on that platform. I left my work
> some
> > > days ago and so I'll have some spare time in the next few months. I
> would
> > > like to know how difficult it is to port the tricore platform on gcc
> and if
> > > during this process somebody can support me as tutor and... also if
> the gcc
> > > team is interested in this item...
> >
> > We welcome ports to new architectures.  Quick googling doesn't find me
> > something like an ISA specification though so it's difficult to assess
> the
> > complexity of porting to that architecture.
>
> https://en.wikipedia.org/wiki/Infineon_TriCore
>
> https://www.infineon.com/dgdl/TC1_3_ArchOverview_1.pdf?fileId=db3a304312bae05f0112be86204c0111
>
> CPU part looks like fairly regular 32bit RISC.  DSP part seems quite
> normal as well.  There even was once a GCC port to Tricore, version 3.3
> from HighTec (now part of Infineon itself), but not even the wayback
> machine has the files for that anymore:
>
>
> https://web.archive.org/web/20150205040416/http://www.hightec-rt.com:80/en/downloads/sources.html
>
> Given the age of that port it's probably better to start from scratch
> anyway :)  (the current stuff from them/Infineon doesn't seem to be
> GCC-based anymore?)
>
>
> Ciao,
> Michael.



-- 
Claudio Eterno
via colle dell'Assietta 17
10036 Settimo Torinese (TO)

Re: gcc tricore porting

[Michael Matz]

[-- Attachment #1: Type: text/plain, Size: 4336 bytes --]

Hello,

note that I know next to nothing about Tricore in particular, so take 
everything with grains of salt.  Anyway:

On Mon, 19 Jun 2023, Claudio Eterno wrote:

> in your reply you mentioned "DSP". Do you want to use the DSP instructions
> for final assembly?

It's not a matter of me wanting or not wanting, I have no stake in 
tricore.  From a 20-second look at the Infineon architecture overview I've 
linked it looked like that some DSP instructions could be used for 
implementing normal floating point support, which of course would be 
desirable in a compiler supporting all of C (otherwise you'd have to 
resort to softfloat emulation).  But I have no idea if the CPU and the DSP 
parts are interconnected enough (hardware wise) to make that feasible (or 
even required, maybe the CPU supports floating point itself already?).

> Michael, based on your experience, how much time is necessary to release
> this porting?

Depending on experience in compilers in general and GCC in particular: 
anything between a couple weeks (fulltime) and a year.

> And.. have you any idea about where to start?

If you don't have an assembler and linker already, then with that.  An 
assembler/linker is not part of GCC, but it relies on one.  So look at 
binutils for this.

Once binutils are taken care of: Richis suggestion is a good one: start 
with an existing port of a target with similar features as you intend to 
implement, and modify it according to your needs.  After that works (say, 
you can compile a hello-world successfully): throw it away and restart a 
completely new target from scratch with everything you learned until then.  
(This is so that you don't start with all the cruft that the target you 
used as baseline comes with).

It helps if you already have a toolchain that you can work against, but 
it's not required.

You need to be familiar with some GCC internals, and the documentation 
coming with GCC is a good starting point: 
  https://gcc.gnu.org/onlinedocs/gccint/
(the "Machine Description" chapter will be the important one, but for that 
you need to read a couple other chapters as well)

There are a couple online resources about writing new targets for GCC.  
Stackoverflow refers to some.  E.g. 
  https://stackoverflow.com/questions/44904644/gcc-how-to-add-support-to-a-new-architecture
refers to https://kristerw.blogspot.com/2017/08/writing-gcc-backend_4.html 
which is something not too old.  For concrete questions this mailing list 
is a good place to ask.


Good luck,
Michael.

> 
> Ciao
> Claudio
> 
> Il giorno lun 19 giu 2023 alle ore 16:16 Michael Matz <matz@suse.de> ha
> scritto:
> 
> > Hello,
> >
> > On Mon, 19 Jun 2023, Richard Biener via Gcc wrote:
> >
> > > On Sun, Jun 18, 2023 at 12:00 PM Claudio Eterno via Gcc <gcc@gcc.gnu.org>
> > wrote:
> > > >
> > > > Hi, this is my first time with open source development. I worked in
> > > > automotive for 22 years and we (generally) were using tricore series
> > for
> > > > these products. GCC doesn't compile on that platform. I left my work
> > some
> > > > days ago and so I'll have some spare time in the next few months. I
> > would
> > > > like to know how difficult it is to port the tricore platform on gcc
> > and if
> > > > during this process somebody can support me as tutor and... also if
> > the gcc
> > > > team is interested in this item...
> > >
> > > We welcome ports to new architectures.  Quick googling doesn't find me
> > > something like an ISA specification though so it's difficult to assess
> > the
> > > complexity of porting to that architecture.
> >
> > https://en.wikipedia.org/wiki/Infineon_TriCore
> >
> > https://www.infineon.com/dgdl/TC1_3_ArchOverview_1.pdf?fileId=db3a304312bae05f0112be86204c0111
> >
> > CPU part looks like fairly regular 32bit RISC.  DSP part seems quite
> > normal as well.  There even was once a GCC port to Tricore, version 3.3
> > from HighTec (now part of Infineon itself), but not even the wayback
> > machine has the files for that anymore:
> >
> >
> > https://web.archive.org/web/20150205040416/http://www.hightec-rt.com:80/en/downloads/sources.html
> >
> > Given the age of that port it's probably better to start from scratch
> > anyway :)  (the current stuff from them/Infineon doesn't seem to be
> > GCC-based anymore?)
> >
> >
> > Ciao,
> > Michael.
> 
> 
> 
>