[LLVMdev] Inline Assembly (unique arch string for llvm)

Chris Lattner sabre at nondot.org
Thu Sep 16 22:28:16 PDT 2004


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/




More information about the llvm-dev mailing list