[Top][All Lists]

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

Re: [Tinycc-devel] Compiling qemu-0.8.2 with tcc (yes, I am insane).

From: Rob Landley
Subject: Re: [Tinycc-devel] Compiling qemu-0.8.2 with tcc (yes, I am insane).
Date: Mon, 9 Oct 2006 00:39:12 -0400
User-agent: KMail/1.9.1

On Monday 09 October 2006 12:02 am, address@hidden wrote:
> I hacked it to run on x86-64 by taking the comparison options out for
> target and replacing that witha generic "fill this with x86" stuff. 
> of course, it generates 32-bit code, but...

Cool!  But I think it's bedtime for me.  I read that three times and I'm still 
not quite sure what you said.  Let's see...

By "comparison options for target" do you mean the #ifdefs at the start of 
tcc.c that do #define TCC_TARGET_I386?  Or do you mean forcing the cpu type 
in ./configure?

I've been building all the cross-compilers (./configure --enable-cross).  
There are two parts here: Running on x86-64 when built with a 64 bit 
compiler, and producing an x86-64 binary.  In theory, these should be totally 

One thing I like about tcc is it's a simple data processor, taking text files 
as input and producing binary output based on that.  I don't see how this is 
significantly different from a docbook to pdf converter.  What host you're 
running on is _irrelevant_, that's the host compiler's job to care about 
that.  The code should be portable, but only so its behavior can be the same 
on each platform it runs on.  The job of tcc is to produce output binaries 
from C source, and it supports various output formats.  Whatever platform 
it's running on at the moment is a side issue.  Having significantly 
different "cross compiling" vs "native compiling" code paths (like gcc does) 
is deeply stupid.

The fact you're producing executable code is irrelevant, you could just as 
easily be churning out a gif.  Should tar and gzip care whether they're built 
on x86 or Arm?  After all, they read input files and write out executables 
all the time.  Should "tar xvjf blah.tbz" have a different codepath for 
extracting arm binaries out of the archive vs extracting x86 binaries?  No.  
Because it doesn't MATTER.  The fact it matters for gcc is because gcc is 
deeply broken.

If it matters even slightly for tcc, it should be fixed.  It sounds like you 
made it run on x86-64, from which it can presumably produce binaries for x86, 
arm, and whatever the heck c67 is?

Wow, the makefile for this way too complicated.  Is that what you removed?  
When you tell it to make cross compilers, it should produce "i386-tcc" and 
maybe create a symlink from tcc to that, not special-case the current 
platform like that...

I really, really, really want to remove the windows overgrowth from my copy of 
this file...

Right, bedtime.

Never bet against the cheap plastic solution.

reply via email to

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