next up previous contents
Next: Lexical Structure of the Up: SALTO Target Description Specifications Previous: Hardware Resources

Reservation Tables

 

A reservation table lists all resources used by the corresponding instruction and, for each resource, describes the type and schedule of the accesses made to that resource, and any relevant renaming and scheduling constraints associated with that resource.

Resources can be designated by basic resource and class names, as specified positional operands of the instruction, or as sets of registers (multi-registers).

Reservation tables are not named. Therefore, to avoid replication of code in the descriptions of instruction sets, each reservation table should be defined as a cpp macro, and the resulting macro subsequently invoked in relevant instruction descriptions.

The syntax of reservation table definitions is

< reser_table>::=

 ( reser_table
  [ 
    (<any_resource_ref>
         [ 
                  (<usage>)
		  <schedule_info>
                  (class (name "<class_name>"))0|1
                  (norename)0|1
    ]  
  )+  
    ])  

< any_resource_ref>::=

  
          <resource_ref> |
	  <positional_param> |
	  <multiregister>


< positional_param>::=

 ( match_arg
<num_arg>)  


< multiregister>::=
 ( multi_reg
<positional_param> <index> <size>)  


< schedule_info>::=
  
          (at_cycle <at>) |
          (from_cycle <from>) (to_cycle <to>)


where
  • <usage> is either read or write (registers or memory), or use (functional units);
  • <class_name> is the name of the class of resources which can be substituted to the current resource during resource renaming; this class must already be defined;
  • (norename), if present, indicates that the resource cannot be substituted (renamed); this property takes precedence on the specification of a renaming class;
  • <positional_param> matches the specified operand in the operand list of the instruction (or family thereof) to which the reservation table applies; <num_arg> is the position (counted from 0) of the operand;
  • <multiregister> corresponds to a multi-register, i.e., an aggregate resource consisting of <size> consecutive hardware registers beginning <index> registers from the base register designated by match_arg; e.g., if the first operand of the instruction is r32, (multireg (match_arg 0) 4 2) corresponds to a multi-register set consisting of registers r36 and r37 -- two registers starting four registers past r32; the offset <index> can be negative;
  • <from> is the number of the first cycle at which the resource is reserved;
  • <to> is the number of the last cycle at which the resource is reserved;
  • <at> is the only cycle at which the resource is reserved: (at_cycle n) is equivalent to (from_cycle n) (to_cycle n).

Example:

; resource common to all 'ftough' instructions
; instruction loading and decoding
#define ISSUE_FTOUGH (ress (name "issue2") [(use) (at_cycle 1)])

; general registers' class
#define   GP_REG_C   (class (name "GP_reg"))

; reservation table of 'ftough' instructions on the TM architecture
#define R_FTOUGH \
 (reser_table [ \
        ISSUE_FTOUGH \
        (ress (name "ftough") [(use)   (from_cycle 1) (to_cycle 16)]) \
	(ress (match_arg 0)   [(read)  (at_cycle 1) GP_REG_C]) ; guard \
        (ress (match_arg 1)   [(read)  (at_cycle 1) GP_REG_C]) ; rsrc1 \
        (ress (match_arg 2)   [(read)  (at_cycle 1) GP_REG_C]) ; rsrc2 \
        (ress (match_arg 3)   [(write) (at_cycle 17)]) ; rdest \
        ])


next up previous contents
Next: Lexical Structure of the Up: SALTO Target Description Specifications Previous: Hardware Resources

Erven Rohou
Fri Oct 17 09:15:29 MET DST 1997