[ECOS] Re: GCC: different OS targets.

[ECOS] Re: GCC: different OS targets.

[Bart Veer]

>>>>> "utz" == The Utz Family <utz@serv.net> writes:

    utz> Isnt this the sort of thing that m4 is supposed to help with?

I am not sure how m4 would help here. m4 is a macro preprocessor. It
is more powerful than the standard C preprocessor cpp, but it is not
clear to me how to exploit that. Even if you converted some bits of
gcc to use m4 rather than cpp as the preprocessor, you would still be
making decisions at the time that gcc gets built rather than when gcc
gets run. Also, complicating gcc builds further by adding a dependency
on another tool is a bad idea.

Bart Veer // eCos net maintainer

Re: [ECOS] Re: GCC: different OS targets.

[Jonathan Larmour]

Brendan Simon wrote:
> 
> Jonathan Larmour wrote:
> 
> [snip]
> It would be nice to have just one compiler but I think I could live with having
> one compiler for each ABI, but having multiple compilers for the same ABI (eg
> EABI) seems wasteful.  I would probably still push for the one compiler and be
> able to select the multilibs to build (specify each lib or family of libs via
> configure).

But then you wouldn't have a single compiler - you would only have a single
source base. You would need to recompile things everytime you needed a new
multilib. Is this really that much better? Lazy compilation would be an
interesting idea though - thus hammering home the benefits of Open Source
:-).

> > BTW, for these reasons, making eCos use the standard toolchain isn't as
> > clean as we would like. We override the linker script, and use -nostdlib to
> > avoid picking up the default crt0's and libc. I don't know how easy it is
> > for other OS's to do something similar though.
> 
> Surely this is easily accomplised via the specs file (eg. -mecos).

Sure, if you are willing to encourage users to patch existing spec files
:-). Alternatively, you just do what we do and encourage users to use
Makefiles so they have less to type. That means you aren't forcing a user to
tamper with an existing toolchain, which they may be using for non-eCos
purposes as well.

Jifl
-- 
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
"I used to have an open mind but || Get yer free open source RTOS's here...
 my brains kept falling out."    || http://sourceware.cygnus.com/ecos
Help fight spam! http://spam.abuse.net/  These opinions are all my own fault

Re: [ECOS] Re: GCC: different OS targets.

[Brendan Simon]

Jonathan Larmour wrote:

> Roger Williams wrote:
> >
> > >>>>> Brendan Simon <brendan@dgs.monash.edu.au> writes:
> >
> >   > I would like to be able to build gcc _ONCE_ for powerpc-eabi and
> >   > be able to build the RTEMS, eCos (or any other OS) libraries and
> >   > install them in an appropriate place.
> >
> > Yes indeed, this would be *very* helpful.  I'm currently developing
> > MPC8xx code for no-OS, Linux, and Neutrino, and I have separate
> > development installations for each of these.  I want to start working
> > with eCos, but I dread the thought of yet another set of powerpc-eabi
> > tools and libraries...
>
> You only need a standard powerpc-eabi toolchain for eCos, not a special one.
> The only constraint is that it must be post egcs-1.1.2. gcc-2.95.1 should
> work absolutely fine.
>
> As Bart Veer mentioned on ecos-discuss, things like thread-safe C++
> exceptions require knowledge of the OS. However, to be honest, I think
> that's all there is. If you were not interested in thread-safe C++
> exceptions - and many RTOS folks aren't - then in general I don't think
> there is any technical reason for different toolchain targets, apart from
> convenience.

I would be (I think).  Surely this code would be part of gcc.  If it is
bleeding edge then the use of gcc snapshots or patches would work.


> But this isn't just convenience for the OS developers, but also for the
> compiler developers. If you consolidated two similar toolchains into one,
> e.g. powerpc-eabi and powerpc-elf, then this suddenly means you have to
> build (at least) twice the number of multi-libs when building a completely
> generic set of tools, in order to support the two ABIs. If you look at the
> current powerpc-eabi compiler, you'll see that it already has 25 multi-libs,
> which means building versions of libgcc, newlib, libio, and libstdc++ 25
> times, which is already painful and disk-intensive.

It would be nice to have just one compiler but I think I could live with having
one compiler for each ABI, but having multiple compilers for the same ABI (eg
EABI) seems wasteful.  I would probably still push for the one compiler and be
able to select the multilibs to build (specify each lib or family of libs via
configure).


> BTW, for these reasons, making eCos use the standard toolchain isn't as
> clean as we would like. We override the linker script, and use -nostdlib to
> avoid picking up the default crt0's and libc. I don't know how easy it is
> for other OS's to do something similar though.

Surely this is easily accomplised via the specs file (eg. -mecos).

Brendan Simon.

[ECOS] Re: GCC: different OS targets.

[Jonathan Larmour]

Roger Williams wrote:
> 
> >>>>> Brendan Simon <brendan@dgs.monash.edu.au> writes:
> 
>   > I would like to be able to build gcc _ONCE_ for powerpc-eabi and
>   > be able to build the RTEMS, eCos (or any other OS) libraries and
>   > install them in an appropriate place.
> 
> Yes indeed, this would be *very* helpful.  I'm currently developing
> MPC8xx code for no-OS, Linux, and Neutrino, and I have separate
> development installations for each of these.  I want to start working
> with eCos, but I dread the thought of yet another set of powerpc-eabi
> tools and libraries...

You only need a standard powerpc-eabi toolchain for eCos, not a special one.
The only constraint is that it must be post egcs-1.1.2. gcc-2.95.1 should
work absolutely fine.

As Bart Veer mentioned on ecos-discuss, things like thread-safe C++
exceptions require knowledge of the OS. However, to be honest, I think
that's all there is. If you were not interested in thread-safe C++
exceptions - and many RTOS folks aren't - then in general I don't think
there is any technical reason for different toolchain targets, apart from
convenience.

But this isn't just convenience for the OS developers, but also for the
compiler developers. If you consolidated two similar toolchains into one,
e.g. powerpc-eabi and powerpc-elf, then this suddenly means you have to
build (at least) twice the number of multi-libs when building a completely
generic set of tools, in order to support the two ABIs. If you look at the
current powerpc-eabi compiler, you'll see that it already has 25 multi-libs,
which means building versions of libgcc, newlib, libio, and libstdc++ 25
times, which is already painful and disk-intensive.

I am hoping we will eventually be able to make some changes to gcc that will
reduce it's dependency on the run-time side at gcc compile-time. But don't
hold your breath :-/.

BTW, for these reasons, making eCos use the standard toolchain isn't as
clean as we would like. We override the linker script, and use -nostdlib to
avoid picking up the default crt0's and libc. I don't know how easy it is
for other OS's to do something similar though.

Jifl
-- 
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
"I used to have an open mind but || Get yer free open source RTOS's here...
 my brains kept falling out."    || http://sourceware.cygnus.com/ecos
Help fight spam! http://spam.abuse.net/  These opinions are all my own fault

[ECOS] Re: GCC: different OS targets.

[Bart Veer]

>>>>> "Brendan" == Brendan Simon <brendan@dgs.monash.edu.au> writes:

    Brendan> There seems to be different builds of egcs/gcc for
    Brendan> various Operating Systems (eg. eCos, RTEMS). I
    Brendan> predominantly use the powerpc-eabi target. I currently
    Brendan> use it with No OS (NOS) on some MPC860 boards but would
    Brendan> like to use an OS. Both RTEMS and eCos use EABI as well,
    Brendan> so the same compiler should be useable for GCC targeting
    Brendan> RTEMS, eCos and NOS.

Unfortunately it is not that simple...

There are a number of areas where the compiler needs to be aware of
the target. The main example is C++ exception handling: the compiler
needs to have access to some per-thread data for this to work, and
the way to do this will vary between targets.

Ideally this sort of thing would be handled at run-time by having the
compiler contain a suitable scripting language interpreter and loading
in a script specific to the desired runtime. That way new target
systems or variations thereof can be accommodated without having to
change the compiler. Implementing this would be a lot of work.

Less ideal would be to have support for several different targets
built into gcc, and select one of them via a command-line switch.
Although I am not a gcc expert, my understanding is that this would
still be a lot of work because it does not match the way gcc works
internally.

The current implementation of gcc involves knowledge of the target to
being built directly into the compiler, which means you need separate
compiler installations for different runtimes. This is certainly
unfortunate, but tolerable for the majority of users.

Nearly all of the effort required will be in the compiler, so the
correct forum for this sort of discussion is the egcs mailing list -
see egcs.cygnus.com. However I doubt that anything will happen unless
somebody either does the work and contributes it, or somebody pays for
the work to be done and contributed.

    Brendan> I figure that the -m switch might be appropriate for
    Brendan> choosing the operating system. Powerpc has a -mads
    Brendan> (amongst others) switch which links the ads crt0.o file
    Brendan> and libads via the specs file. Does the specs file only
    Brendan> work with the -m switch all will it work with any other
    Brendan> swtich ? The -m switch could be used to select the
    Brendan> operating system. eg. "-m ads-rtems" or "-m rtems-ads". A
    Brendan> separate directory for the OS stuff would be setup in
    Brendan> $prefix$target/$os (eg. /usr/local/gcc/rtems/include and
    Brendan> /usr/local/gcc/rtems/lib) or maybe $prefix/$target/os/$os
    Brendan> (eg. /usr/local/gcc/os/rtems/... or
    Brendan> /usr/local/gcc/os/none/...).

The -m switch and the specs file make it easy to control some aspects
of builds, for example the file used for the startup, or the default
include path. It cannot readily control internals of the compiler such
as the implementation of exception handling.

Bart Veer // eCos net maintainer

[ECOS] Re: GCC: different OS targets.

[Roger Williams]

>>>>> Brendan Simon <brendan@dgs.monash.edu.au> writes:

  > I would like to be able to build gcc _ONCE_ for powerpc-eabi and
  > be able to build the RTEMS, eCos (or any other OS) libraries and
  > install them in an appropriate place.

Yes indeed, this would be *very* helpful.  I'm currently developing
MPC8xx code for no-OS, Linux, and Neutrino, and I have separate
development installations for each of these.  I want to start working
with eCos, but I dread the thought of yet another set of powerpc-eabi
tools and libraries...

-- 
Roger Williams                         finger me for my PGP public key
Coelacanth Engineering Inc    consulting & turnkey product development
Middleborough, Massachusetts           wireless * datacomm * DSP * ATE
tel +1 508 947-5585 * fax +1 508 861-0278 * http://www.coelacanth.com/