llvm dev - Sep 2004 - [LLVMdev] Inline Assembly (unique arch string for llvm)

On Thu, 2004-09-16 at 23:45, Chris Lattner wrote:
> On Thu, 16 Sep 2004, Andrew Lenharth wrote:
> > So I propose that llvm-gcc not consider itself any type of x86-linux
(or
> > what ever it platform it was compiled on), but rather create a new
> > architecture, say llvm (or perhaps 2, one for each bit and little
> > endian).  Thuse llvm-gcc -dumpmachine would return llvm-os.
> 
> Hrm, I would much rather just have LLVM be a drop in replacement for a C
> compiler.  As such, it should expose identical #defines to GCC.
A drop in replacement for "a C compiler" is rather a different
requirement than a drop in replacement for GCC.  If the goal is pure GCC
compatibility then sure, identical defines are fine.  My main point is
software tends to expect certain compilers (or a small number of
compilers) on certain platforms and tends to have work arounds (or
exploits) for their unique "features".  Which do you want to fix? 
Make
config scripts and headers think they are compiling to an arch "llvm"
or
make llvm work for evey assumption a piece of sw makes about how gcc
would behave on that arch/os?  I guess you are thinking the latter.  I
just thought that gcc has enough problems with things breaking when new
versions of gcc come out because they depended too closely on how gcc
behaved on a certain peice of code, that perhaps we don't want to try to
go down that path too.  (for example, although the linux kernel supports
several versions of gcc, there have been a slew of patches recently to
make things work on 3.5).

An argument for a seperate arch string is also that it makes llvm
bytecode (especially with a fully ported c library) very close to being
identical for similar platforms (pointer size and endian size being the
same mostly).  Unless I am missing something here.  Obviously OS
specific interfaces cannot be general, but for most software, those are
wrapped by the c library.

Why don't we have platform independence as an optional bytecode feature
for well behaved programs?  A couple intrinsics to do htonl and friends
would let a peice of bytecode be endian agnostic.

Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20040917/d657fdff/attachment.sig>

On Fri, 17 Sep 2004, Andrew Lenharth wrote:
> > Hrm, I would much rather just have LLVM be a drop in replacement for a
C
> > compiler.  As such, it should expose identical #defines to GCC.
>
> A drop in replacement for "a C compiler" is rather a different
> requirement than a drop in replacement for GCC.  If the goal is pure GCC
> compatibility then sure, identical defines are fine.  My main point is
My goal is to get very close to being a drop-in replacement for GCC.  As
time progresses, we will converge on that goal.  An important part of that
though is that we don't have to be more compatible with GCC than it is
with itself: if something breaks between versions of GCC, we shouldn't
really have to worry about it either.
> An argument for a seperate arch string is also that it makes llvm
A separate arch string would imply a LOT of complexity and many other
problems: it's not a panacea...
> bytecode (especially with a fully ported c library) very close to being
> identical for similar platforms (pointer size and endian size being the
> same mostly).  Unless I am missing something here.  Obviously OS
> specific interfaces cannot be general, but for most software, those are
> wrapped by the c library.
Not true at all.  In particular, various data structures have different
sizes based on their implementation (e.g. FILE), and many APIs may be
different.  C is not a language that is designed to be portable.

*If* we controlled all of the header files, *and* restricted the C
compiler to reject "nonportable" features, then we could provide
portability for the C subset that is left.  I actually think that this
would be a very interesting project, but it's not something I'm even
considering doing myself.
> Why don't we have platform independence as an optional bytecode feature
> for well behaved programs?  A couple intrinsics to do htonl and friends
> would let a peice of bytecode be endian agnostic.
LLVM bytecode files produced from portable languages (e.g. Java,
verifiable MSIL, or many others) should be portable, assuming the
front-end isn't doing something silly.  The problem with C is C, not LLVM.

-Chris

-- 
http://llvm.org/
http://nondot.org/sabre/

On Fri, 17 Sep 2004, Chris Lattner wrote:
> > Why don't we have platform independence as an optional bytecode
feature
> > for well behaved programs?  A couple intrinsics to do htonl and
friends
> > would let a peice of bytecode be endian agnostic.
>
> LLVM bytecode files produced from portable languages (e.g. Java,
> verifiable MSIL, or many others) should be portable, assuming the
> front-end isn't doing something silly.  The problem with C is C, not
LLVM.
Actually, I should clarify something there.  You're right that *many* C
programs might be portable.  For example, this is a portable C program:

int main() { return 42; }

The problem is that you want to be able to guarantee that a program, if
accepted by the compiler, is portable.  This is not something we have
today.

Another problem is that most C programs use more of the standard library
than this program.  The problem with the C standard library is that the
headers often include a ton of implementation details as inline functions
or macros.  This is why you need to control the headers as well as the
language dialect being compiled.

I'm afraid that I'm sounding too negative about this idea, but I
don't
mean to.  If this was implemented, it would be a huge boon to the free
software and open source communities: suddenly programs could be
distributed in binary form instead of source form, easing distribution.
Getting to this point though will take a lot of work.  :)

-Chris

-- 
http://llvm.org/
http://nondot.org/sabre/