RE: [Tinycc-devel] C6x Port

[TK]

Peter,

I couldn't have made a more accurate description of what I did myself!

When I first moved the code to VC++ 6.0 I had difficulty including any
of the standard headers without being CPP.  At that time I thought it
would be good to make use of Windows message boxes and CStrings.  In
retrospect that was a mistake.  Windows (and I typically) like to make
heavy use of CStrings hence why I renamed the TCC CString type.  Of
course then there were many warnings on the type casts you mention.  I
don't like warnings so I tried to add all the explicit typecasts and I
tried to remember to mark them with a "//tktk".

Then after commenting out a few references to unix directories for
libraries and headers I was at a state where it could compile code to
memory and execute it! (with no references to libraries).  I (and some
of my friends) were blown away by single stepping through maybe a
thousand lines of code and watch code being compiled from start to
finish.  I guess I could do the same with the original code if I knew
how to debug under Linux, but I don't.  I think I still have that
version if anyone would like it.  I never did figure out what libraries
were required to be able to output an executable even for the CYGWIN
version.  CYGWIN seemed to use a different .o format or something.
Anyway I had no interest in generating PC code so I dropped it.

This brings up the issue of a RTL for the C67, also relocatable code.
It doesn't currently support input or output of relocatable code (or
libraries).  It can however input a linked .out file (that has a RTL)
within it and resolve calls to the RTL.  That suits my particular
application where my target will have a fixed program in it which is
like a mini OS for the board.  So in summary, the current state of the
TCC67 compiler is that it can input multiple .c files and a (possibly
multiple) .out file (symbols only) and create a .out file.

The TI Code Composer RTL is very good and has source available and the
license seems to say that it is allowed to be copied and modified as
long as it is used to generate code that executes on a TI chip. So I
believe it could be included.

Regarding all the #ifdef stuff, you are right.  I don't have any
preference if/how you want to merge/maintain it.  Probably what should
be done is to go through the i386gen.c file and remove all the #ifdefs
and make a new C67gen.c file.  The method I used in the port was that I
found that there seemed to be the lowest level routine g() that spit out
a byte of i386 code.  So I put an ASSERT fault in that routine.  Then I
tried to compile some code.  When it hit the ASSERT I looked up the
stack to see what it was doing and to find the lowest point where I
could put an #ifdef to divert to make some equivalent C67 code.  I found
it useful be able to be able to see right there how one fragment of code
was changed.  I was also thinking it might be useful if I needed to
modify a future version of TCC.

BTW things that gave difficulties in the i386->C67 port were:

First 10 parameters are passed in Regs/pairs (>10 or variable not
supported)
Floating point and int registers are the same
Register pairs are used for doubles
Floating point is not stack based
The C67 doesn't have memory operands
The C67 doesn't have condition codes (or a carry bit)
There are many more regs (I changed the reg type from char -> int)
Branches are absolute vs relative (all branches need relocation)
The C67 needs 2 instructions to load a 32 bit immediate value 
C67 doesn't have divide/mod instructions
I didn't attempt to support long longs or long doubles
C67 has a A/B sides of the processor with constraints on reg access
Stack points to last used vs next avail
C67 has latency - currently just insert worst case nops

However considering all these differences I thought the port went
smoothly thanks to how Fabrice organized things.

Thanks

TK




-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of
Peter "Firefly" Lund
Sent: Friday, March 07, 2003 4:24 PM
To: address@hidden
Subject: RE: [Tinycc-devel] C6x Port

On Fri, 7 Mar 2003, Peter "Firefly" Lund wrote:

> On Fri, 7 Mar 2003, Tom Kerekes wrote:
>
> > Yes.  Basically 1 instruction per cycle as well as nops placed after
so
> > the next bit of code can't use a result before it is ready.  This
makes
> > the generated code look really silly.  Probably a second pass could
be
> > added to eliminate unnecessary nops, store/loads, and even parallel
up
> > some things.  My main emphasis was getting it to generate correct
code.

I have now found some time to glance through the code.  After doing the
obvious things (telling unzip to do text file conversion, renaming
tcc.cpp
back to tcc.c, adding more files to my list of files to exclude from the
diff) I got a gargantuan patch of slightly over 160K.

Some of this is "noise", though:

 o a few changes to tcctest.c that shouldn't have happened.
 o casts of return values from tcc_mallocz() because tcc.c was renamed
to
   tcc.cpp and C++ doesn't allow implicit coercions from void * to any
   other kind of pointer whereas C does.
 o at least one case of whitespace change (spurious tab before sh_offset
   in elf.h).
 o TheTCCState doesn't seem to be used.

At least one of the types also seems to have been changed:

  CString -> CTString

Another contributor to the size is the fact that Tom has done some of
the
modularization work (creation of tcc.h, separate compilation of tcc.cpp
and WriteCoff.cpp).  Nice, but it does make comparisons and merging of
the
source a bit harder ;)

diffstat:
 TCC67/COFF.H            |only
 TCC67/WriteCoff.cpp     |only
 TCC67/WriteCoff.h       |only
 TCC67/elf.h             |   29
 TCC67/i386-asm.c        |   17
 TCC67/i386-gen.c        | 2790
+++++++++++++++++++++++++++++++++++++++++++++++-
 TCC67/i386-gen.original |only
 TCC67/libtcc.h          |    4
 TCC67/out.txt           |only
 TCC67/tcc.c             |  625 +++-------
 TCC67/tcc.h             |only
 TCC67/tccasm.c          |   34
 TCC67/tccelf.c          |  282 +++-
 TCC67/tcctest.c         |   14
 tcc-0.9.16/tcc_g        |only
 tcc-0.9.16/tcctest.ref  |only
 tcc-0.9.16/test.out2    |only
 tcc-0.9.16/test.ref     |only
 18 files changed, 3246 insertions(+), 549 deletions(-)

As you can see, I need to add *.ref and *.out2 to my list of files to
exclude from the diff :)

Tom, there's one thing I'm curious about:  why did you interweave the
new
code generator with the old one in i386-gen.c instead of making a new
"stand-alone" generator based on i386-gen.c?

My experience agrees completely with the view expressed in:

    "#ifdef Considered Harmful, or Portability Experience With C News",
    Henry Spencer and Geoff Collyer.

    http://www.chris-lott.org/resources/cstyle/ifdefs.pdf

-Peter


_______________________________________________
Tinycc-devel mailing list
address@hidden
http://mail.nongnu.org/mailman/listinfo/tinycc-devel