Re: [Tinycc-devel] TCC on ARM

[Rob Landley]

On Friday 01 December 2006 4:21 pm, tike64 wrote:
> Rob Landley <address@hidden> wrote:
> > On Friday 01 December 2006 2:07 pm, Rob Landley wrote:
> > > The only way this _can_ matter is if A) this sub_ddmmss() thing
> runs
> > > on the host, not on the target (in which case, why the heck is it
> > > assembly?), B) the test is wrong and confusing host with target.
> 
> I can't understand too clearly what is the libtcc1 needed for. Could it
> be that it is for long-long and float operations and those are not
> supported on arm target? Then the libtcc1 would not be built for cross
> compiler at all

Exactly.  If tcc has the code to create arm binaries when running on i386, 
then it has the code to create arm binaries when running on arm.  Something 
is confused.

> but is tried to build for native arm-arm compiler in 
> error. Shouldn't I then fix the Makefile to never build libtcc1 for arm
> target?

I think we need to figure out what libtcc1 does.  Glancing at libtcc1.c it 
seems to be the same as libgcc, I.E. functions to support for 64 bit math on 
32 bit platforms (calls to which get generated when you do math on uint64_t 
or "long long" -- when there's no assembly opcode for this, it has to call a 
function behind the scenes).

For some of the 64-bit math, they have hand-optimized assembly routines to do 
it.  But this becomes part of the generated binary, which means this is for 
the _target_, and the test they're doing is for the _host_, which is wrong.

The question is, how the heck does this work when cross-compiling?  Either 
there's code somewher else to do this (perhaps unoptimized C routines, which 
would suck but suck portably), or else it's spitting out i386 machine code in 
the arm binaries and attempts to use uint64_t on arm just don't work right 
now, and nobody's noticed yet.

There may already be a patch for this in the mailing list archive...

> > Ok, looking closer:
> > 
> > 1) It's not in assembly, it's just ugly.
> > 
> > 2) It's not actually necessary.
> > 
> > This thing is only used in rt_error(), which is called from a signal
> > handler to try to give a better error message rather than just
> letting
> > the signal kill the compiler in case of a division by zero error or 
> > some such.
> 
> Now you are probably talking about the rt_get_caller_pc warning.

You're right, I was looking at the wrong chunk.

> Based 
> on your notes I think that the code does the right thing and maybe the
> #warning could be simply removed

Actually, what I did in my fork (http://landley/hg) was just remove that whole 
debug signal handler thing.  If tcc segfaults itself, I can run it under gdb 
or something to see what the heck happened.  This is exactly the kind of 
host-specific knowledge that I really don't think a compiler should have.

A compiler really isn't special, it's just a program for converting input 
files into output files.  So is a png->gif converter.  This whole "host vs 
target" thing just doesn't come _up_ with a png->gif converter, and if you 
stop and think about it why does a compiler care either?  You produce 
binaries for $TARGET.  Whether or not they run on the current machine is 
irrelevant.

Rob

P.S.  Yes, I know I've been ignoring my fork for the last 6 weeks because I 
don't want to step on Fabrice's toes, nor do I particularly have time to 
maintain the thing for anyone but myself.  But you know what?  I'm going to 
ignore the whole issue and putter away as I feel like it.  I'm going to make 
it work for me, and merge the patches I feel like merging, and if anybody 
wants to use my tree (or take patches from my tree and apply them to cvs) 
they're welcome to.  Personally, find CVS a bit of a pain to work with.

(Oh, and now that I've got a real mercurial web thingy up, 
http://landley.net/hg/tinycc has links to produce tarballs at the top of it.)
-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery