Port to CodeWarrier

[joel at oarcorp.com]

On Wed, 30 Sep 1998, Jimen Ching wrote:

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

The AMD a29k port was done to non-GNU tools (Sierra High C as I recall).
The PowerPC port was compiled long ago using Metrowerks on a Mac.  So it
is possible to use non-GNU tools to compile RTEMS.  That is not the choice
of most users.  The transition to GNU autconf was intended to ease the
pain of the 3.6.0 build procedure for the majority of RTEMS users.

The a29k port was submitted and is in the tree now.  We have no way to
compile it.

The Metrowerks ppc effort was never submitted.

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

It is a pain but it is possible.  It just requires someone interested
enough in (1) doing the port to non-GNU tools and (2) interested in
supporting it once it exists.  We do not buy licenses on every cross
toolset in the world. If a customer is interested in us supporting them on
non-GNU tools, then we will purchase the necessary tools. 

We would be amenable to porting to non-GNU tools for payment or for
supporting a customer's port to non-GNU tools.  

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

Both are usful efforts but both require someone who wants the results and
invest in it (time and money).

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

There is no such thing as standard assembly language or a way to inline
assembly.  This code is restricted to the CPU and BSP dependent
directories.  

Any good compiler should support the use of the C preprocessor independty
on any file.  THen you can pass the preporocessed assembly file to the
assembler.  This is how it was done in RTEMS for years.

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

We have discussed alternatives for building RTEMS in a non-UNIX totally 
IDE driven environment.  No one has ever approached OAR to implement this
or submitted a way of their own devising.

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

It is possible and a significant loss of speed.  The inline assembler is
again in the CPU and BSP dependent directories.  You would simply address
this as part of porting to a toolset.  It can and has been done before.

If we ported to another compiler which supported another flavor of inline
assembly, I would rewrite the inline assembly for that compiler.  Speed.

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

You are not supposed to port Makefiles in an autoconf environment.  You
teach autoconf about your environment and the Makefiles (and other
generated files) fall out by magic.

If there is a weakness in RTEMS' use of autoconf, it is that we did not go
far enough.

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

Very few files are generated at compile-time in RTEMS.  targopts.h may be
the only one.

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

This is a testimony to the original port and the manner in which the i960
architectural model was defined by Intel.  They clearly defined what was
portable across i960 models and what was not.  

If there were any changes, we would love to see them.

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

There has been some i960 activity but nothing submitted.  I think most
folks are similar to you in that they did so little, there is no
submission and no news.

I expect a new i960 BSP to be in a release past 4.0.  But that is based on
a user submission so there is never a guarantee.

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

I can't say much about any of the eCOS stuff other than to say that they
are targetting different markets.  Hopefully I will be able to say more by
the end of the week.

Development snapshots have been made available to a significant number of
people -- both paying customers and volunteers.

One of the issues is that up to and past 3.6.0, RTEMS was distributed
solely by the Army at their request.  This has changed recently and 4.0
will have a different distribution site.  

--joel
Joel Sherrill                    Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (205) 722-9985