Re: [Tinycc-devel] TCC on new ARM EABI (ARMEL) [PATCH]

[Daniel Glöckner]

On Sun, Oct 08, 2006 at 11:44:35PM -0400, Rob Landley wrote:
> What exactly does this do?  I mean, what _is_ arm EABI?  The codesourcery 
> page 
> on this says that EABI is a nickname for Arm's documented ABI: 
> http://www.codesourcery.com/gnu_toolchains/arm/faq.html#q_ABI_what_is_abi

http://www.arm.com/products/DevTools/ABI.html

> So what was tcc on arm doing _before_?  (Producing working but nonstandard 
> binaries that couldn't trade .o files with gcc, maybe?)

Something like that. I could not find any documentation when I wrote the
non-EABI ARM backend. Most of it was done by studying the behaviour of
a cross GCC that was provided by Sharp for my Linux PDA.

> What's a non-EABI ARM?  (Different kernel versions?  Different processors?)

Since 2.6.16 the Linux kernel has this config switch:

"config AEABI
        bool "Use the ARM EABI to compile the kernel"
        help
          This option allows for the kernel to be compiled using the latest
          ARM ABI (aka EABI).  This is only useful if you are using a user
          space environment that is also compiled with EABI.

          Since there are major incompatibilities between the legacy ABI and
          EABI, especially with regard to structure member alignment, this
          option also changes the kernel syscall calling convention to
          disambiguate both ABIs and allow for backward compatibility support
          (selected with CONFIG_OABI_COMPAT).

          To use this you need GCC version 4.0.0 or later."

As ARM devices usually don't run vanilla kernels, some vendors might
already have patched their kernels to EABI prior to 2.6.16.

> I'm confused by the start of your patch:
> 
> -       $(CC) $(CFLAGS) -DTCC_TARGET_ARM -o $@ $< $(LIBS)
> +       $(CC) $(CFLAGS) -DTCC_TARGET_ARM -DTCC_ARM_EABI -o $@ $< $(LIBS)
> ...
> +#ifdef TCC_ARM_EABI
> +#define TCC_ARM_VFP
> +#endif

The EABI is processor independent, but standardizes only the use of a
possibly available VFP floating point unit. As it doesn't specify how to
use a FPA unit, we use VFP instead.

> I take it that -DTCC_TARGET_ARM does not already imply -DTCC_ARM_EABI?  
> There's some value in selecting them independently?

I wanted to keep support for non-EABI systems.
-DTCC_TARGET_ARM does not imply -DTCC_ARM_EABI.

> (Should we have 
> something like menuconfig?  I'm in the process of helping genericize that 
> infrastructure so it can be more easily applied to other projects...)

I think that would be overkill.

> Same question for TCC_ARM_VFP, there's some value in being able to select it 
> discreetly?

You can build the Linux kernel for VFP coprocessors without using EABI.
But as GCC can't emit VFP instructions, I'm not shure about the calling
conventions.

> > I also made enums EABI compliant by changing VT_ENUM into a flag and
> > setting the basetype according to the enum values. But when I saw that
> > GCC behaves non-conforming, I undid that change.
> 
> Is this for compatability with gcc, or is this because that part of the ABI 
> seems kinda pointless if nobody implements it?

http://www.codesourcery.com/gnu_toolchains/arm/arm_gnu_linux_abi.pdf
Section 2.5, so it's Linux compatibility.

There is a thread about the enum issue on the v4l mailing list:
http://marc.theaimsgroup.com/?l=linux-video&m=114595413406507&w=2

> Back to the basic "what does this fix, what does switching it off mean" 
> question above...

If you have an operating system (libraries and kernel) compiled with a
new GCC using the new EABI, you need to define TCC_ARM_EABI. If you
don't, code compiled with GCC will expect some values at slightly
different addresses than where code compiled with TCC will write them.

Few ARM processors have a floating point unit. If you have a VFP unit,
define TCC_ARM_VFP. Else TCC uses FPA instructions.
The Linux kernel can emulate an FPA unit, but it looks like the VFP
support code won't be extended to emulate a full VFP unit (although the
changes would be minimal):
http://marc.theaimsgroup.com/?l=linux-arm-kernel&m=114181739608031&w=2

So people using EABI without VFP should not use float or double until
someone rewrites the backend to do all floating point stuff via the (EABI
standardized) soft-float functions. A prerequisite is to make TCC aware
that an integer register can contain a float or one half of a double.
Then we wouldn't need the #ifdef TCC_ARM_VFP block at the end of
gfunc_call and I would not have inserted that bug in gen_cvt_itof by
incorrectly using func_old_type.

To sum it up:
Floating point VFP still is a mess and works only for people with VFP
hardware and only until they cast a long long to a float/double.

> > Btw.:
> > ln -s /lib/libgcc_s.so.1 /usr/lib/tcc/libtcc1.a
> > is sufficient for most programs.
> 
> What does that do?

For TCC libtcc1.a contains functions for operations that can't be
expressed in 1~3 instructions. ARM processors have f.ex. no instructions
for divisions. So each time you divide two integers, a function from
libtcc1.a is called.
For GCC these functions are in libgcc_s.so.1 (if you built GCC with
--enable-shared). GCC has conventions for naming the functions and the
ARM EABI standardizes some of them.
So by making TCC use the GCC library (which is probably anyway needed
on the system), we can avoid to reinvent the wheel.
If, on some distant day, TCC can emit soft-float code, the floating
point library from libgcc_s.so.1 would need to be added to libtcc1.a as
well.

  Daniel