RE: [Tinycc-devel] C6x Port

[Peter \"Firefly\" Lund]

On Sat, 8 Mar 2003, TK wrote:

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

Thank you :)

Just got home from work, did you? ;)

> When I first moved the code to VC++ 6.0 I had difficulty including any

Why didn't you try mingw or cygwin?  You don't get nice pictures during
the install but it is still pretty simple to do.

I think that could have saved you some of the burden -- but then you
wouldn't have had such a great debugger.

(I hate gdb with a vengeance -- I'm slowly writing my own with a user
interface cloned from the old text mode Turbo Debugger.  If that had
existed when you started and you had known about it, would it have
changed your priorities?)

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

Arrg!

> In
> retrospect that was a mistake.

Precisely :)

If one does that, one should do it in a separate file...

Always, always, always minimize the dependencies.

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

I think you actually missed to mark most of them -- but never mind.  They
are quite easy to find (I've got diff, the greatest thing since sliced
bread :) ).

> 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

Oh yeah, that reminds me... you include io.h -- do you actually use that?
AFAIR you haven't changed the buffered file I/O code, so it actually still
uses the POSIX interface, doesn't it?

(open, read, close)

If it doesn't, it should be quite simple to put it into a module of its
own that uses whatever is optimal/possible on the current platform.

Something like mmap() and madvise() would perhaps even speed it up --
caveat: I haven't profiled anything yet.  I'm still in the phase where I'm
trying to understand things and document them while hopefully fixing a bug
here and there.

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

:)

You should have built your own toy compilers in high school like everybody
else ;)

You might want to google for Jack Crenshaw and his "Let's Build a
Compiler" tutorials...

> I guess I could do the same with the original code if I knew
> how to debug under Linux, but I don't.

Like I said: I hate gdb with a vengeance.  You have to be a prime nerd
with too much time on your hand to have learned to use it well and love
it.  The same goes for emacs.

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

Hmm... I don't intend to try to host tcc on Windows just yet, but I do
intend to do so one day.

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

Fine by me -- as far as I'm concerned, you own that backend.  We just have
to get it integrated properly -- since it is the first extra backend to
tcc, there are some things that need to be done to make it nice.  After
that it should be very simple for different backend maintainers to work
without stepping on each other's toes.

> 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

Something like that, yes.

> 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

Ingenious use of a debugger :)

I would have had to actually understand the code, you know ;)

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

Thanks.  I'll keep that list in mind.

Do you have any good, authoritative links to docs on C67?  I'm not just
thinking about the official manuals, but also things like what the inline
assembler normally looks like, what the C extensions are, various gotchas
(definitely not mentioned in the manuals!) etc... ?

To translate into the IA-32 domain, I'm not just thinking of the manuals
at www.intel.com but also www.sandpile.org and
http://www-106.ibm.com/developerworks/library/l-ia.html

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

Yes, it is very nice C code :)

-Peter

Why should George W. Bush care what the American people think?
After all they did not vote for him.