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 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 > > 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. > > > >