This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

C167 support


OK, time to tell my story :)

I need a free compiler (+ assembler, binutils, etc) for the Infineon 
C167 architecture. My idea was to get acquainted with the GCC 
internals and once my exams are over to start adding support for it 
to GCC.


There is already currently a GCC adapted (by HighTec) for the C167, 
however it's based on GCC 2.7.2 (Sun Nov 26 14:47:42 1995). I somehow 
have the feeling that trying to port their changes to a more recent 
GCC would be hell. My feeling is enhanced by the fact it looks like 
they have changed at at least 300 files (for gcc, gas, binutils and 
gdb together), and they also made many changes unrelated to C167 
support.

Also, I'd like if C167 support would end up in the main gcc tree, 
rather than my own version of it (I do believe that's what you guys 
also recommend), however with the HighTec stuff that ain't gonna 
happen. They're making money off their version, and based on that 
I've read they very reluctantly released the sources, only after 
someone slapped them around the ears with the free demo (binary) that 
was available on their site (and covered by the GPL). Ofcourse 
HighTec only released those parts strictly necessary by the GPL, and 
put them in a corner somewhere on their site.

Sounds to me it's unlikely they'd sign a copyright assignment ;-)


I have a few questions:

1. Should I further investigate that they've done to GCC, or should I 
rather avoid their source like the plague and begin from scratch to 
avoid copyright issues?

2. What's the best way to get acquainted with GCC's internals? I'm 
pretty good at C/C++ programming, know assembly for a few processors, 
and I've written a simple compiler (scripting lang -> bytecode) some 
time ago, but GCC is fairly large.. what parts are the most 
important? (I have already read some of the GCC internals manual, but 
it seems more like a reference to me)  My current idea is to compile 
some simple programs with -da, look at the intermediate files, and 
then dig into the source to find where things are transformed to the 
next step and how, but I welcome better suggestions ofcourse :)

3. The C167 architecture has a segmented memory architecture 
(actually much more awful than plain "segmented", but I'll leave that 
for later). I have an idea on how to best deal with this, but it 
involves a language extension. Would that be OK, assuming it does not 
affect other targets?

4. Unless the general feeling is "we don't want your segmented C167 
crap in our beautiful GCC", could someone send me 
"request-assign.future" so I can start coding once my exams are over 
without having to wait for the paperwork to complete?


If wanted, I can give a summary of the parts of the C167 architecture 
that affect GCC. (it's a rather simple architecture, except for the 
memory stuff)

  - Matthijs

PS please CC replies directly to me, I'm subscribed to the digest

Matthijs van Duin
- PGP Key: 0x2D6F0BA7
- FP: 205D F7BA FFAD 9070 AB9E  C5A8 BDB0 CA1B 2D6F 0BA7 -


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]