Joel Sherrill 80f2885b70 2005-05-14 Sergei Organov <osv@topconrd.ru>
PR 746/rtems
	Optimize realloc(). The problem is that realloc() can neither grow
	nor shrink efficiently the current memory region without support
	from underlying heap/region modules. The patch introduces one new
	routine for each of heap and region modules, _Heap_Resize_block(),
	and rtems_region_resize_segment(), respectively, and uses the
	latter to optimize realloc().

	The implementation of _Heap_Resize_block() lead to changing of the
	heap allocation strategy: now the heap manager, when splits larger
	free block into used and new free parts, makes the first part of
	the block used, not the last one as it was before. Due to this new
	strategy, _Heap_Resize_block() never needs to change the user
	pointer.

	Caveat: unlike previous heap implementation, first few bytes of
	the contents of the memory allocated from the heap are now almost
	never all zero. This can trigger bugs in client code that have not
	been visible before this patch.

	* libcsupport/src/malloc.c (realloc): try to resize segment in
	place using new rtems_region_resize_segment() routine before
	falling back to the malloc()/free() method.
	* score/src/heap.c:
	(_Heap_Initialize): change initial heap layout to reflect new
	allocation strategy of using of the lower part of a previously
	free block when splitting it for the purpose of allocation.
	(_Heap_Block_allocate): when split, make the lower part used, and
	leave the upper part free. Return type changed from Heap_Block* to
	uint32_t.
	* score/include/rtems/score/heap.h:
	(Heap_Statistics): added 'resizes' field.
	(Heap_Resize_status): new enum.
	(_Heap_Resize_block): new routine.
	(_Heap_Block_allocate): return type changed from Heap_Block* to
	uint32_t.
	* score/src/heapwalk.c: reflect new heap layout in checks.
	* score/src/heapsizeofuserarea.c: more assertions added.
	* score/src/heapresizeblock.c: new file.
	(_Heap_Resize_block): new routine.
	* score/src/heapfree.c: reverse the checks _Heap_Is_block_in() and
	_Heap_Is_prev_used() on entry to be in this order.
	* score/src/heapallocate.c, score/src/heapallocatealigned.c:
	ignore return value of _Heap_Block_allocate().
	* score/Makefile.am (HEAP_C_FILES): added src/heapresizeblock.c.
	* rtems/include/rtems/rtems/region.h:
	(rtems_region_resize_segment): new interface routine.
	(_Region_Process_queue): new internal routine called from
	rtems_region_resize_segment() and rtems_region_return_segment().
	* rtems/src/regionreturnsegment.c: move queue management code into
	the new internal routine _Region_Process_queue() and call it.

	* rtems/src/regionresizesegment.c: new file.
	(rtems_region_resize_segment): new interface routine.
	* rtems/src/regionprocessqueue.c: new file.
	(_Region_Process_queue): new internal routine containing queue
	management code factored out from 'regionreturnsegment.c'.
	* rtems/Makefile.am (REGION_C_FILES): Added
	src/regionresizesegment.c, and src/regionprocessqueue.c.
	* ada/rtems.adb, ada/rtems.ads: Added Region_Resize_Segment.
2005-05-20 19:15:41 +00:00
2004-10-22 14:49:47 +00:00
2004-12-30 12:24:42 +00:00
2005-05-20 08:53:30 +00:00
2004-09-24 06:32:10 +00:00
2000-02-08 18:36:21 +00:00
1997-04-22 16:50:29 +00:00
2003-03-25 08:55:26 +00:00

#
#  $Id$
#

Building RTEMS
==============
See the file README.configure.

Directory Overview
==================

This is the top level of the RTEMS directory structure.  The following 
is a description of the files and directories in this directory:

  INSTALL
    Rudimentary installation instructions.  For more detailed
    information please see the Release Notes.  The Postscript 
    version of this manual can be found in the file
    c_or_ada/doc/relnotes.tgz.

  LICENSE
    Required legalese.

  README
    This file.

  c
    This directory contains the source code for the C 
    implementation of RTEMS as well as the test suites, sample 
    applications, Board Support Packages, Device Drivers, and 
    support libraries.

  doc
    This directory contains the PDL for the RTEMS executive.

Ada versus C
============

There are two implementations of RTEMS in this source tree -- 
in Ada and in C.  These two implementations are functionally
and structurally equivalent.  The C implementation follows
the packaging conventions and hierarchical nature of the Ada 
implementation.  In addition, a style has been followed which 
allows one to easily find the corresponding Ada and C 
implementations.  

File names in C and code placement was carefully designed to insure
a close mapping to the Ada implementation.  The following file name 
extensions are used:

   .adb - Ada body
   .ads - Ada specification
   .adp - Ada body requiring preprocessing
   .inc - include file for .adp files

   .c   - C body (non-inlined routines)
   .inl - C body (inlined routines)
   .h   - C specification

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
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 
inline textual expansion is performed.  This avoids scoping and
calling convention side-effects in carefully constructed tests 
which usually test context switch behavior.

In addition, in Ada code and data name references are always fully
qualified as PACKAGE.NAME.  In C, this convention is followed 
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
PACKAGE.NAME in Ada and _Package_Name in C.  The leading "_" in C
is used to avoid naming conflicts between RTEMS and user variables.
By using these conventions, one can easily compare the C and Ada
implementations.

The most noticeable difference between the C and Ada83 code is 
the inability to easily obtain a "typed pointer" in Ada83.  
Using the "&" operator in C yields a pointer with a specific type.
The 'Address attribute is the closest feature in Ada83.  This
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 
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
explicit conversion.  

The solution adopted to this problem was to provide two routines for
each access type in the Ada implementation -- one to convert from
System.Address to the access type and another to go the opposite
direction.  This results in code which accomplishes the same thing
as the corresponding C but it is easier to get lost in the clutter
of the apparent subprogram invocations than the "less bulky"
C equivalent.

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 
in the C implementation.
Description
RTEMS is a ​real-time executive in use by embedded systems applications around the world and beyond
Readme 126 MiB
Languages
C 93.9%
Assembly 3.4%
Ada 1.4%
Python 0.3%
HTML 0.3%
Other 0.4%