tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Tinycc-devel] C6x Port


From: TK
Subject: RE: [Tinycc-devel] C6x Port
Date: Tue, 11 Mar 2003 08:29:44 -0800

Peter,

Thanks for the comments.  I don't really know of any good, authoritative
links for the C67.  If anyone does please let me know!   But here are
some TI links.  I find the documentation there quite good and accurate.

BTW I really like the C6711 chip.  If you're not familiar with it:  It
is relatively cheap (~$20-$30).  Has a theoretical peak of about 1 GFLOP
(you get maybe 1/10th of this in any real application, but that is true
of most processors).  Has 64Kbytes of 256 bits wide 0 wait state
internal RAM.  It doesn't need a heat sink.  Bolts right up to SDRAM.
And has a very efficient interrupt system (I've had useful interrupt
routines that executed in < 50ns!)

One thing that I have noticed that is especially true for this processor
is that a test and branch is particularly expensive.  5 cycles for the
load including latency, and 6 for the branch including latency.  In the
old days one would do everything possible to avoid a floating point
operation, but this thing can do about 50 FP operations (assuming values
are in regs) in the same time as it takes to check a flag!  I noticed
that it seems that TCC67 often generates 3 branches for each iteration
in a "for" loop.  And sometimes a branch to a branch, which is
particularly bad for this processor.  Again a second pass through the
generated code should be able to eliminate some of those.  But I guess
we trade efficiency for simplicity.  I was thinking about how to do
that.  The main problem seems to be that when some code is deleted, many
symbol references have to be adjusted to do the final relocations, but
on the other hand the relocation might be required to be made first, to
determine what is actually being referenced??   Insight here would be
appreciated...

Two main "gotchas" with this processor that I have found (and TI doesn't
really advertise) are that branches are not interruptable and that
interrupts make latency unpredictable.  These are not usually an issue
except for really tight optimized code (TCC67 doesn't currently have
that problem, ha, ha).  

A really tight "zero overhead" loop often is continuously branching
(multiple branches may even be occurring at different stages in
parallel, that is a new branch is started before previous branch has
taken "effect").  In this case the interrupt system is totally disabled
for the duration of the loop!  The TI compiler allows for you to specify
the max number of cycles this is allowed to occur.

The unpredictable latency is a bother when you try to utilize a single
register for multiples purposes exploiting the latency.  For example if
you do something like a LDW where you know that there will be a 4 cycle
latency before the register actually changes, you might use that
register for something else in the mean time (or store a previous value
2 cycles later).  That all works fine, EXCEPT if an interrupt occurs
during the 4 cycle latency!  Then it is as if there was no latency and
the result is most likely an unexpected result.  The only solution is to
turn off interrupts, or use more registers.

Anyway here are some links:    



C6711 CPU Instruction Set:

http://www-s.ti.com/sc/psheets/spru189f/spru189f.pdf



Compiler Tools: Includes how to inline assembly, how the compiler uses
regs etc.

http://www-s.ti.com/sc/psheets/spru187k/spru187k.pdf




Free 30 day Code composer evaluation.  Includes Simulator which should
allow loading of COFF files generated by the TCC67 compiler and allow
viewing of mixed C/assembly etc...

http://dspvillage.ti.com/docs/catalog/devtools/details.jhtml?templateId=
5121&path=templatedata/cm/tooldetail/data/fets_intro&toolTypeId=0&toolTy
peFlagId=2





TK


-----Original Message-----
From: Peter "Firefly" Lund [mailto:address@hidden 
Sent: Saturday, March 08, 2003 3:56 PM
To: TK; address@hidden
Subject: RE: [Tinycc-devel] C6x Port

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]