OpenCores
URL https://opencores.org/ocsvn/or1k/or1k/trunk

Subversion Repositories or1k

[/] [or1k/] [trunk/] [rtems/] [README] - Diff between revs 208 and 1765

Go to most recent revision | Only display areas with differences | Details | Blame | View Log

Rev 208 Rev 1765
#
#
#  $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.
 
 

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.