Port to CodeWarrier

[David J. Fiddes]

Hi,

>There is a real issue here. It seems that those that write These GNU
>Programs expect people to be using Unix and GCC. The programs are very
>heavilly targeted to these platforms. Moving to an alternate platform
>invokes a whole world of pain. In my "opinion" this should be easy to
>avoid, but it appears as if no one is really interested in the problem.

GNU does stand for GNU is Not Unix...  :)

RTEMS is tied to GNU C and associated make tools... this is a good thing
IMHO as it allows us all to use essentially the same toolset with only the
target processor type and host machine differing between users. RTEMS
supports half a dozen processors if we had half a dozen toolsets in common
use maintianing and testing the thing would be an astronomic task. At the
moment Joel can find the vast majority of build time bugs by building each
processor toolset and all the supported BSPs on a couple of host platforms
(Linux and Solaris ?). You couldn't do that realistically using any other
development tool(s).

For the record Geoffroy Montel and I (both total unix newbies) "ported"
RTEMS so that it built under Windows NT in a couple of afternoons. A little
bit of configure/autoconf tidying was needed to get things working really
neatly but other than that it all worked more or less straight off. You do
need to use Cygwin32(http://www.cygnus.com/misc/gnu-win32/) to provide a
unix like environment under NT but that aside it works fine on a standard NT
box. I use MS Visual Studio as my primary editor/development environment and
get on fine with my other unix based RTEMS developers.

>1. Assembler Code Files that follows a standard Assembler format. (ie,
>no C Pre-processor directives).

This would have made my recent Motorola ColdFire a real pain... you need to
have a decent method of conditional defines. Using a C pre-processor seems
like a good idea to me.

>2. No ./Configure script. Replace it with a simpler make file. Yes you
>have to maintain the make file, but you have to maintain the autoconf
>script anyway, so it seems to be false economy to me.

This is what allowed the Cygwin32 port of RTEMS to just work.... Autoconf
was able to find what tools were installed and cope with the fact that hosts
programs end with .EXE and a whole manner of little annoying details with a
few small fixes to the autoconf script. The addition of autoconf to RTEMS
has been a major leap in usability. Relying on only makefiles and
environment variables as version up to and including 3.6.0 did made it very
hard to use and understand from a beginners stand point.

>3. Avoid Inline assembler as every implementation is different and the
>GCC Implementation is especially bizare.

The GCC implementation of inline assembler and constraints is the most
powerful and complete I have met. Other peoples inline assembler
implementations are usually incomplete and dangerous or inefficient. On the
downside... GCC's inline assembler is astoundingly badly documented. There
are people who are fixing this as well as folk who know how it works and are
prepared to help with problems you might have though.


>Currently ive given up on using Code Warrior for code development, not
>because it is a bed tool, it is excellent, rather because i cant get it
>to build RTEMS. My fall back position is to compile the lot under Linux
>using GCC (ie, its prefered environment, Unix and GCC). Im Hoping
>against Hope that ELF and DWARF are really standards and the the Code
>Warrior Debugger will read the Files produced by GCC and allow me to
>debug. If it wont ill be forced to not use RTEMS at all, as i havent
>seen a BDM Debugger for GDB, nor do i have the time to write one. :(

Debugging RTEMS and using gdb in general is tough under a non-Linux system.
A number of BDM interface drivers are available for Mot CPU32 processors
running under Linux... a similar driver for the ColdFire is under
development. PPC should be fairly easy. Making an RTEMS build/debug machine
that runs Linux and can be accessed via X-Windows/telnet might be a cheap,
viable option if you have an old machine lying about.

Dave