Port to CodeWarrier

[Jimen Ching]

On Wednesday, September 30, 1998 11:41 AM, Steven Johnson [SMTP:sbjohnson at ozemail.com.au] wrote:
> that it was a continuous series of "Gotchas". I could have probably
> moved the code for an MPC860 to a special version of RTEMS for MPC860
> and CW, but that would of meant not being able to take ready advantage
> of upgrades and fixes.
  ^^^^^^^^^^^^^^^^^^^^^

I don't see this as a problem if you contribute the changes back to
OAR Corp.  Maybe their engineers will see the problems and fix the
code so support of a different development environment is possible.
If you do the _Intel_ thing and keep the changes to yourself, then
you do not have the privilege to complain.

> 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.

Easy to avoid?  I for one would like to hear how.  Remember we're
talking about an Operating System, not an application.  OS's require
more hardware specific information than most apps.  Since RTEMS is
hard-real time, it must also be fast.  So given all of these
requirements, I would like to know how to make an OS easy to port to
different development environments.

Porting OS's rank up there with porting a compiler.

> Things that would make life easier for those that dont use Unix or GCC:
> 1. Assembler Code Files that follows a standard Assembler format. (ie,
> no C Pre-processor directives).

This does not allow you to inline the assembly code.  When the assembly
code is just one line, making a function call is simply not acceptable.

> 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.

Believing that a makefile can replace a configure script is false
security to me.  Either you've never tried it or you haven't ported
enough software to enough different systems.  True, configure is more
geared towards CLI environments.  But CLI environments are usually
more powerful.  If your IDE doesn't support scripting, then it is too
weak to be an OS development environment.  This is not about maintenance,
it is about the ability to setup the build environment with a single
tool.  Makefiles can't do that.

> 3. Avoid Inline assembler as every implementation is different and the
> GCC Implementation is especially bizare. If Inline assembler is
> required, then surround it in an #ifdef GCC_INLINE_ASM block, so that
> porters can add things like #elsif CW_INLINE_ASM the entire function
> should be #'d this way, as some compilers do not allow Inline assembler
> to be inserted mid stream of a function. (Code Warrior for example).

There is no such thing as 'avoid inline assembler'.  At least not in
hardware specific code.  If you don't believe this, then you haven't
written fast real-time software in C.  Yes, it is possible.

> possible, and avoid GNU Make specific features, or if it uses them, they
> should be commented in the makefile so that someone porting the makefile
> can understand what piece of magic is being performed on the code. It

Sorry, but making this comment is equivalent to a cobol programmer who
wants to port a C program to cobol, asking the C programmer to comment
the code so it can be ported easier.  If you are porting a piece of code
by looking at the source, then learn the language first.  Otherwise,
read the documentation and rewrite the source in whatever language you
want.  This applies to any source, whether it be a makefile or C.

> Make, how a seperate directory tree is created, this tree bears very
> little obvious relationship to the original tree?? Also the act of
> creating Header files at build time makes it very difficult when
> perusing the code to find where things come from (it took me forever to
> find where rtems/score/targopts.h was). ie, it is nowhere in the source
> distribution.

This is the only thing I can agree with.  Though building headers at
compile time may not be avoidable, you want to do that as a last resort.
If you want to know of a better environment, look at EGCS' build
environment.  It does generate some headers, but most system dependent
headers are already created in the config directory.  The headers it
creates are ones needed to build tools to compile EGCS.  It is hard
to avoid that.  EGCS also has the added advantage of building the
compiler for multiple targets from the same source.  You can't do that
with RTEMS 3.6.0 because of this broken build environment.

I should mention now that I've ported the executive to i960Hx.  There
are some problems with the sysctl instruction that I still need to
look into.  But basically, the i960CA code worked without change.
The differences between the two processors did not affect the core
RTEMS itself.  I did not port any of the libs or BSPs, since the
hardware I'm using is a proprietary system.  I did use GNU CC.  But
I manually copied the header files into the include directory hiearchy.

What is the status of 4.0 with respect to i960 processors?  I can send
patches for the cpu.h and i960types.h files, but all I did was copy
and pasted the PRCB data structure and renamed it.  Otherwise, there
were no other changes to the CPU dependent parts.  There were no CPU
dependent code in the executive itself, so there's no changes.

> One of the other factors that on RTEMS development that hinders this
> sort of porting is not having ready access to in-development snap shots.
> It seemed pointless to me to do all this porting effort to 3.6.0 only to
> have to do it all again with 4.0.0. I Understand OARCORPs concerns here,
> but i think a more open development would produce a better product in
> the long run. Open Source code benifits from an open development model,
> Pre-stable snapshots should be readily available, but they should be
> marked as Prerelease snapshots, people can then use them or not at their

You tell them, brother.  I should also point out that Cygnus has now
thrown their hats into the RTOS market.  So, OAR, I suggest you think
hard about it.  I am curious why Cygnus didn't choose RTEMS though.
Did they contact OAR before developing their own RTOS?  After all,
their newlib is used by RTEMS.  Does anyone know the differences
between RTEMS and Cygnus' eCOS?  Is it easy to move between them?
Thanks in advance for any info.

--jc
--
jimen at adtech-inc.com
Adtech, Inc.