#
|
#
|
# $Id: README,v 1.2 2001-09-27 11:59:04 chris Exp $
|
# $Id: README,v 1.2 2001-09-27 11:59:04 chris Exp $
|
#
|
#
|
|
|
Building RTEMS
|
Building RTEMS
|
==============
|
==============
|
See the file README.configure.
|
See the file README.configure.
|
|
|
Directory Overview
|
Directory Overview
|
==================
|
==================
|
|
|
This is the top level of the RTEMS directory structure. The following
|
This is the top level of the RTEMS directory structure. The following
|
is a description of the files and directories in this directory:
|
is a description of the files and directories in this directory:
|
|
|
INSTALL
|
INSTALL
|
Rudimentary installation instructions. For more detailed
|
Rudimentary installation instructions. For more detailed
|
information please see the Release Notes. The Postscript
|
information please see the Release Notes. The Postscript
|
version of this manual can be found in the file
|
version of this manual can be found in the file
|
c_or_ada/doc/relnotes.tgz.
|
c_or_ada/doc/relnotes.tgz.
|
|
|
LICENSE
|
LICENSE
|
Required legalese.
|
Required legalese.
|
|
|
README
|
README
|
This file.
|
This file.
|
|
|
c
|
c
|
This directory contains the source code for the C
|
This directory contains the source code for the C
|
implementation of RTEMS as well as the test suites, sample
|
implementation of RTEMS as well as the test suites, sample
|
applications, Board Support Packages, Device Drivers, and
|
applications, Board Support Packages, Device Drivers, and
|
support libraries.
|
support libraries.
|
|
|
doc
|
doc
|
This directory contains the PDL for the RTEMS executive.
|
This directory contains the PDL for the RTEMS executive.
|
|
|
Ada versus C
|
Ada versus C
|
============
|
============
|
|
|
There are two implementations of RTEMS in this source tree --
|
There are two implementations of RTEMS in this source tree --
|
in Ada and in C. These two implementations are functionally
|
in Ada and in C. These two implementations are functionally
|
and structurally equivalent. The C implementation follows
|
and structurally equivalent. The C implementation follows
|
the packaging conventions and hiearchical nature of the Ada
|
the packaging conventions and hiearchical nature of the Ada
|
implementation. In addition, a style has been followed which
|
implementation. In addition, a style has been followed which
|
allows one to easily find the corresponding Ada and C
|
allows one to easily find the corresponding Ada and C
|
implementations.
|
implementations.
|
|
|
File names in C and code placement was carefully designed to insure
|
File names in C and code placement was carefully designed to insure
|
a close mapping to the Ada implementation. The following file name
|
a close mapping to the Ada implementation. The following file name
|
extensions are used:
|
extensions are used:
|
|
|
.adb - Ada body
|
.adb - Ada body
|
.ads - Ada specification
|
.ads - Ada specification
|
.adp - Ada body requiring preprocessing
|
.adp - Ada body requiring preprocessing
|
.inc - include file for .adp files
|
.inc - include file for .adp files
|
|
|
.c - C body (non-inlined routines)
|
.c - C body (non-inlined routines)
|
.inl - C body (inlined routines)
|
.inl - C body (inlined routines)
|
.h - C specification
|
.h - C specification
|
|
|
In the executive source, XYZ.c and XYZ.inl correspond directly to a
|
In the executive source, XYZ.c and XYZ.inl correspond directly to a
|
single XYZ.adb or XYZ.adp file. A .h file corresponds directly to
|
single XYZ.adb or XYZ.adp file. A .h file corresponds directly to
|
the .ads file. There are only a handful of .inc files in the
|
the .ads file. There are only a handful of .inc files in the
|
Ada source and these are used to insure that the desired simple
|
Ada source and these are used to insure that the desired simple
|
inline textual expansion is performed. This avoids scoping and
|
inline textual expansion is performed. This avoids scoping and
|
calling convention side-effects in carefully constructed tests
|
calling convention side-effects in carefully constructed tests
|
which usually test context switch behavior.
|
which usually test context switch behavior.
|
|
|
In addition, in Ada code and data name references are always fully
|
In addition, in Ada code and data name references are always fully
|
qualified as PACKAGE.NAME. In C, this convention is followed
|
qualified as PACKAGE.NAME. In C, this convention is followed
|
by having the package name as part of the name itself and using a
|
by having the package name as part of the name itself and using a
|
capital letter to indicate the presence of a "." level. So we have
|
capital letter to indicate the presence of a "." level. So we have
|
PACKAGE.NAME in Ada and _Package_Name in C. The leading "_" in C
|
PACKAGE.NAME in Ada and _Package_Name in C. The leading "_" in C
|
is used to avoid naming conflicts between RTEMS and user variables.
|
is used to avoid naming conflicts between RTEMS and user variables.
|
By using these conventions, one can easily compare the C and Ada
|
By using these conventions, one can easily compare the C and Ada
|
implementations.
|
implementations.
|
|
|
The most noticeable difference between the C and Ada83 code is
|
The most noticeable difference between the C and Ada83 code is
|
the inability to easily obtain a "typed pointer" in Ada83.
|
the inability to easily obtain a "typed pointer" in Ada83.
|
Using the "&" operator in C yields a pointer with a specific type.
|
Using the "&" operator in C yields a pointer with a specific type.
|
The 'Address attribute is the closest feature in Ada83. This
|
The 'Address attribute is the closest feature in Ada83. This
|
returns a System.Address and this must be coerced via Unchecked_Conversion
|
returns a System.Address and this must be coerced via Unchecked_Conversion
|
into an access type of the desired type. It is easy to view
|
into an access type of the desired type. It is easy to view
|
System.Address as similar to a "void *" in C, but this is not the case.
|
System.Address as similar to a "void *" in C, but this is not the case.
|
A "void *" can be assigned to any other pointer type without an
|
A "void *" can be assigned to any other pointer type without an
|
explicit conversion.
|
explicit conversion.
|
|
|
The solution adopted to this problem was to provide two routines for
|
The solution adopted to this problem was to provide two routines for
|
each access type in the Ada implementation -- one to convert from
|
each access type in the Ada implementation -- one to convert from
|
System.Address to the access type and another to go the opposite
|
System.Address to the access type and another to go the opposite
|
direction. This results in code which accomplishes the same thing
|
direction. This results in code which accomplishes the same thing
|
as the corresponding C but it is easier to get lost in the clutter
|
as the corresponding C but it is easier to get lost in the clutter
|
of the apparent subprogram invocations than the "less bulky"
|
of the apparent subprogram invocations than the "less bulky"
|
C equivalent.
|
C equivalent.
|
|
|
A related difference is the types which are only in Ada which are used
|
A related difference is the types which are only in Ada which are used
|
for pointers to arrays. These types do not exist and are not needed
|
for pointers to arrays. These types do not exist and are not needed
|
in the C implementation.
|
in the C implementation.
|
|
|
