289 lines
13 KiB
Ada
289 lines
13 KiB
Ada
------------------------------------------------------------------------------
|
|
-- --
|
|
-- GNAT RUN-TIME COMPONENTS --
|
|
-- --
|
|
-- T A R G P A R M --
|
|
-- --
|
|
-- S p e c --
|
|
-- --
|
|
-- $Revision: 1.13 $
|
|
-- --
|
|
-- Copyright (C) 1999-2001 Free Software Foundation, Inc. --
|
|
-- --
|
|
-- GNAT is free software; you can redistribute it and/or modify it under --
|
|
-- terms of the GNU General Public License as published by the Free Soft- --
|
|
-- ware Foundation; either version 2, or (at your option) any later ver- --
|
|
-- sion. GNAT is distributed in the hope that it will be useful, but WITH- --
|
|
-- OUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY --
|
|
-- or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License --
|
|
-- for more details. You should have received a copy of the GNU General --
|
|
-- Public License distributed with GNAT; see file COPYING. If not, write --
|
|
-- to the Free Software Foundation, 59 Temple Place - Suite 330, Boston, --
|
|
-- MA 02111-1307, USA. --
|
|
-- --
|
|
-- GNAT was originally developed by the GNAT team at New York University. --
|
|
-- It is now maintained by Ada Core Technologies Inc (http://www.gnat.com). --
|
|
-- --
|
|
------------------------------------------------------------------------------
|
|
|
|
-- This package obtains parameters from the target runtime version of
|
|
-- System, to indicate parameters relevant to the target environment.
|
|
|
|
-- Conceptually, these parameters could be obtained using rtsfind, but
|
|
-- we do not do this for three reasons:
|
|
|
|
-- 1. Compiling System for every compilation wastes time
|
|
-- 2. This compilation impedes debugging by adding extra compile steps
|
|
-- 3. There are recursion problems coming from compiling System itself
|
|
-- or any of its children.
|
|
|
|
-- For all these reasons, we read in the source of System, and then scan
|
|
-- it at the text level to extract the parameter values.
|
|
|
|
-- Note however, that later on, when the ali file is written, we make sure
|
|
-- that the System file is at least parsed, so that the checksum is properly
|
|
-- computed and set in the ali file. This partially negates points 1 and 2
|
|
-- above although just parsing is quick and does not impact debugging much.
|
|
|
|
package Targparm is
|
|
|
|
-- The following parameters correspond to the variables defined in the
|
|
-- private part of System (without the terminating _On_Target). Note
|
|
-- that it is required that all parameters be specified in system.ads.
|
|
|
|
-----------------------------------
|
|
-- Control of Exception Handling --
|
|
-----------------------------------
|
|
|
|
-- GNAT provides two methods of implementing exceptions:
|
|
|
|
-- Longjmp/Setjmp (-gnatL)
|
|
|
|
-- This approach uses longjmp/setjmp to handle exceptions. It
|
|
-- uses less storage, and can often propagate exceptions faster,
|
|
-- at the expense of (sometimes considerable) overhead in setting
|
|
-- up an exception handler. This approach is available on all
|
|
-- targets, and is the default where it is the only approach.
|
|
|
|
-- Zero Cost (-gnatZ)
|
|
|
|
-- This approach uses separate exception tables. These use extra
|
|
-- storage, and exception propagation can be quite slow, but there
|
|
-- is no overhead in setting up an exception handler (it is to this
|
|
-- latter operation that the phrase zero-cost refers). This approach
|
|
-- is only available on some targets, and is the default where it is
|
|
-- available.
|
|
|
|
ZCX_By_Default_On_Target : Boolean;
|
|
-- Indicates if zero cost exceptions are active by default. Can be modified
|
|
-- by the use of -gnatZ and -gnatL switches.
|
|
|
|
GCC_ZCX_Support_On_Target : Boolean;
|
|
-- Indicates that when ZCX is active the mechanism to be used is the
|
|
-- standard GCC ZCX mechanism (introduced in GCC 3.1)
|
|
|
|
Front_End_ZCX_Support_On_Target : Boolean;
|
|
-- Indicates that when ZCX is active (and GCC_ZCX_Support is not set)
|
|
-- the mechanism to be used is the GNAT front end specific ZCX mechanism
|
|
|
|
---------------------------------------
|
|
-- High_Integrity (No Run Time) Mode --
|
|
---------------------------------------
|
|
|
|
-- In High_Integrity mode, there is no system run-time, and the flag
|
|
-- Opt.No_Run_Time is set so that the language is appropriately
|
|
-- restricted to forbid construct that would generate run-time calls.
|
|
|
|
High_Integrity_Mode_On_Target : Boolean;
|
|
-- Indicates that this build is for a high integrity mode version of
|
|
-- GNAT, so that no run time is permitted.
|
|
|
|
-------------------------------
|
|
-- Control of Stack Checking --
|
|
-------------------------------
|
|
|
|
-- GNAT provides two methods of implementing exceptions:
|
|
|
|
-- GCC Probing Mechanism
|
|
|
|
-- This approach uses the standard GCC mechanism for
|
|
-- stack checking. The method assumes that accessing
|
|
-- storage immediately beyond the end of the stack
|
|
-- will result in a trap that is converted to a storage
|
|
-- error by the runtime system. This mechanism has
|
|
-- minimal overhead, but requires complex hardware,
|
|
-- operating system and run-time support. Probing is
|
|
-- the default method where it is available. The stack
|
|
-- size for the environment task depends on the operating
|
|
-- system and cannot be set in a system-independent way.
|
|
|
|
-- GNAT Stack-limit Checking
|
|
|
|
-- This method relies on comparing the stack pointer
|
|
-- with per-task stack limits. If the check fails, an
|
|
-- exception is explicitly raised. The advantage is
|
|
-- that the method requires no extra system dependent
|
|
-- runtime support and can be used on systems without
|
|
-- memory protection as well, but at the cost of more
|
|
-- overhead for doing the check. This method is the
|
|
-- default on systems that lack complete support for
|
|
-- probing.
|
|
|
|
Stack_Check_Probes_On_Target : Boolean;
|
|
-- Indicates if stack check probes are used, as opposed to the standard
|
|
-- target independent comparison method.
|
|
|
|
Stack_Check_Default_On_Target : Boolean;
|
|
-- Indicates if stack checking is on by default
|
|
|
|
----------------------------
|
|
-- Command Line Arguments --
|
|
----------------------------
|
|
|
|
-- For most ports of GNAT, command line arguments are supported. The
|
|
-- following flag is set to False for targets that do not support
|
|
-- command line arguments (notably VxWorks).
|
|
|
|
Command_Line_Args_On_Target : Boolean;
|
|
-- Set False if no command line arguments on target
|
|
|
|
-- Note: this is prepared for future use, but not yet used, since we
|
|
-- do not yet have a way of propagating Targparm params to the binder
|
|
|
|
-----------------------
|
|
-- Main Program Name --
|
|
-----------------------
|
|
|
|
-- When the binder generates the main program to be used to create the
|
|
-- executable, the main program name is main by default (to match the
|
|
-- usual Unix practice). If this parameter is set to True, then the
|
|
-- name is instead by default taken from the actual Ada main program
|
|
-- name (just the name of the child if the main program is a child unit).
|
|
-- In either case, this value can be overridden using -M name.
|
|
|
|
Use_Ada_Main_Program_Name_On_Target : Boolean;
|
|
-- Set True to use the Ada main program name as the main name
|
|
|
|
-- Note: this is prepared for future use, but not yet used, since we
|
|
-- do not yet have a way of propagating Targparm params to the binder
|
|
|
|
----------------------------
|
|
-- Support of Long Shifts --
|
|
----------------------------
|
|
|
|
-- In GNORT mode, we cannot call library routines, and in particular
|
|
-- we cannot call routines for long (64-bit) shifts if such routines
|
|
-- are required on the target. This comes up in the context of support
|
|
-- of packed arrays. We can only represent packed arrays whose length
|
|
-- is in the range 33- to 64-bits as modular types if long shifts are
|
|
-- done with inline code.
|
|
|
|
-- For the default version, for now we set long shifts inlined as True
|
|
-- This may not be quite accurate, but until we get proper separate
|
|
-- System's for each target, it is a safer choice.
|
|
|
|
Long_Shifts_Inlined_On_Target : Boolean;
|
|
-- Indicates if long (double word) shifts are generated using inlined
|
|
-- code (and thus are permissible in No_Run_Time mode).
|
|
|
|
----------------------------------------------
|
|
-- Boolean-Valued Floating-Point Attributes --
|
|
----------------------------------------------
|
|
|
|
-- The constants below give the values for representation oriented
|
|
-- floating-point attributes that are the same for all float types
|
|
-- on the target. These are all boolean values.
|
|
|
|
-- A value is only True if the target reliably supports the corresponding
|
|
-- feature. Reliably here means that support is guaranteed for all
|
|
-- possible settings of the relevant compiler switches (like -mieee),
|
|
-- since we cannot control the user setting of those switches.
|
|
|
|
-- The attributes cannot dependent on the current setting of compiler
|
|
-- switches, since the values must be static and consistent throughout
|
|
-- the partition. We probably should add such consistency checks in future,
|
|
-- but for now we don't do this.
|
|
|
|
AAMP_On_Target : Boolean;
|
|
-- Set to True if target is AAMP.
|
|
|
|
Denorm_On_Target : Boolean;
|
|
-- Set to False on targets that do not reliably support denormals.
|
|
-- Reliably here means for all settings of the relevant -m flag, so
|
|
-- for example, this is False on the Alpha where denormals are not
|
|
-- supported unless -mieee is used.
|
|
|
|
Machine_Rounds_On_Target : Boolean;
|
|
-- Set to False for targets where S'Machine_Rounds is False
|
|
|
|
Machine_Overflows_On_Target : Boolean;
|
|
-- Set to True for targets where S'Machine_Overflows is True
|
|
|
|
Signed_Zeros_On_Target : Boolean;
|
|
-- Set to False on targets that do not reliably support signed zeros.
|
|
|
|
OpenVMS_On_Target : Boolean;
|
|
-- Set to True if target is OpenVMS.
|
|
|
|
--------------------------------------------------------------
|
|
-- Handling of Unconstrained Values Returned from Functions --
|
|
--------------------------------------------------------------
|
|
|
|
-- Functions that return variable length objects, notably unconstrained
|
|
-- arrays are a special case, because there is no simple obvious way of
|
|
-- implementing this feature. Furthermore, this capability is not present
|
|
-- in C++ or C, so typically the system ABI does not handle this case.
|
|
|
|
-- GNAT uses two different approaches
|
|
|
|
-- The Secondary Stack
|
|
|
|
-- The secondary stack is a special storage pool that is used for
|
|
-- this purpose. The called function places the result on the
|
|
-- secondary stack, and the caller uses or copies the value from
|
|
-- the secondary stack, and pops the secondary stack after the
|
|
-- value is consumed. The secondary stack is outside the system
|
|
-- ABI, and the important point is that although generally it is
|
|
-- handled in a stack like manner corresponding to the subprogram
|
|
-- call structure, a return from a function does NOT pop the stack.
|
|
|
|
-- DSP (Depressed Stack Pointer)
|
|
|
|
-- Some targets permit the implementation of a function call/return
|
|
-- protocol in which the function does not pop the main stack pointer
|
|
-- on return, but rather returns with the stack pointer depressed.
|
|
-- This is not generally permitted by any ABI, but for at least some
|
|
-- targets, the implementation of alloca provides a model for this
|
|
-- approach. If return-with-DSP is implemented, then functions that
|
|
-- return variable length objects do it by returning with the stack
|
|
-- pointer depressed, and the returned object is a pointer to the
|
|
-- area within the stack frame of the called procedure that contains
|
|
-- the returned value. The caller must then pop the main stack when
|
|
-- this value is consumed.
|
|
|
|
Functions_Return_By_DSP_On_Target : Boolean;
|
|
-- Set to True if target permits functions to return with using the
|
|
-- DSP (depressed stack pointer) approach.
|
|
|
|
-----------------
|
|
-- Data Layout --
|
|
-----------------
|
|
|
|
-- Normally when using the GCC backend, Gigi and GCC perform much of the
|
|
-- data layout using the standard layout capabilities of GCC. If the
|
|
-- parameter Backend_Layout is set to False, then the front end must
|
|
-- perform all data layout. For further details see the package Layout.
|
|
|
|
Frontend_Layout_On_Target : Boolean;
|
|
-- Set True if front end does layout
|
|
|
|
-----------------
|
|
-- Subprograms --
|
|
-----------------
|
|
|
|
procedure Get_Target_Parameters;
|
|
-- Called at the start of execution to read the source of System and
|
|
-- obtain and set the values of the above parameters.
|
|
|
|
end Targparm;
|