URL
https://opencores.org/ocsvn/scarts/scarts/trunk
Subversion Repositories scarts
[/] [scarts/] [trunk/] [toolchain/] [scarts-binutils/] [binutils-2.19.1/] [cgen/] [hardware.scm] - Rev 7
Go to most recent revision | Compare with Previous | Blame | View Log
; Hardware descriptions. ; Copyright (C) 2000, 2009 Red Hat, Inc. ; This file is part of CGEN. ; See file COPYING.CGEN for details. ; This is the base class for all hardware descriptions. ; The actual hardware objects inherit from this (e.g. register, immediate). ; This is used to describe registers, memory, and immediates. ; ??? Maybe other things as well, but this is all that's needed at present. ; ??? Eventually rename to <hardware> but not yet. ; Name used in semantics. ; This is for cases where a particular hardware element is ; sufficiently different on different mach's of an architecture ; that it is defined separately for each case. The semantics ; refer to this name (which means that one must use a different ; mechanism if one wants both machs in the same semantic code). ; The type, an object of class <array>. ; (mode + scalar or vector length) ; Indexing support. ; An object of class <hw-asm>, or a subclass of it, or ; #f if there is no special indexing support. ; For register banks, a table of register names. ; ??? Same class as VALUES. ; ??? There are currently no descriptions that require both an ; INDICES and a VALUES specification. It might make sense to ; combine them (which is how things used to be), but it is odd ; to have them combined. ; Table of values. ; An object of class <hw-asm>, or a subclass of it, or ; #f if there is no special values support. ; For immediates with special names, a table of names. ; ??? Same class as INDICES. ; Associative list of (symbol . "handler") entries. ; Each entry maps an operation to its handler (which is up to ; the application but is generally a function name). ; Get/set handlers or #f to use the default. ; Associative list of get/set handlers for each supported mode, ; or #f to use the default. ; ??? An interesting idea, but not sure it's the best way ; to go. Another way is to explicitly handle it in the insn ; [complicates the RTL]. Another way is to handle this in ; operand get/set handlers. Another way is to have virtual ; regs for each non-default mode. Not sure which is better. ;(getters . #f) ;(setters . #f) ; List of <isa> objects that use this hardware element ; or #f if not computed yet. ; This is a derived from the ISA attribute and is for speed. ; Flag indicates whether this hw has been used in a (delay ...) ; rtl expression ; Accessors ; ??? These might be more properly named hw-get/hw-set, but those names ; seem ambiguous. ; Mode,rank,shape support. ; Return default mode to reference HW in. ; Return a boolean indicating if X is a hardware object. ; ??? <hardware-base> to be renamed <hardware> in time. ; Return #t if HW is a scalar. ; Return number of bits in an element of HW. ; Generate the name of the enum for hardware object HW. ; This uses the semantic name, not obj:name. ; If HW is a symbol, it is already the semantic name. "HW_""HW_"; Return a boolean indicating if it's ok to reference SELF in mode ; NEW-MODE-NAME, index INDEX. ; Hardware types are required to override this method. ; VOID and DFLT are never valid for NEW-MODE-NAME. "mode-ok? method not overridden:"; Return mode to use for the index or #f if scalar. "get-index-mode method not overridden:"; Compute the isas used by HW and cache the results. ; Was this hardware used in a (delay ...) rtl expression? ; FIXME: replace pc?,memory?,register?,iaddress? with just one method. ; Return boolean indicating if hardware element is the PC. ; Return boolean indicating if hardware element is some kind of memory. ; ??? Need to allow multiple kinds of memory and therefore need to allow ; .cpu files to specify this (i.e. an attribute). We could use has-attr? ; here, or we could have the code that creates the object override this ; method if the MEMORY attribute is present. ; ??? Could also use a member instead of a method. ; Return boolean indicating if hardware element is some kind of register. ; Return boolean indicating if hardware element is an address. ; Assembler support. ; Baseclass. ; The mode to use. ; A copy of the object's mode if we're in the "values" ; member. If we're in the "indices" member this is typically ; UINT. ; Keywords. ; Keyword lists associate a name with a number and are used for things ; like register name tables (the `indices' field of a hw spec) and ; immediate value tables (the `values' field of a hw spec). ; ; TODO: For things like the sparc fp regs, have a quasi-keyword that is ; prefix plus number. This will save having to create a table of each ; register name. ; Prefix value to pass to the corresponding enum. ; Prefix of each name in VALUES, as a string. ; This is *not* prepended to each name in the enum. ; Associative list of values. ; Each element is (name value [attrs]). ; ??? May wish to allow calling a function to compute the ; value at runtime. ; Accessors ; Parse a keyword spec. ; ; ENUM-PREFIX is for the corresponding enum. ; The syntax of VALUES is: (prefix ((name1 [value1 [(attr-list1)]]) ...)) ; NAME-PREFIX is a prefix added to each value's name in the generated ; lookup table. ; Each value is a number of mode MODE. ; ??? We have no problem handling any kind of number, we're Scheme. ; However, it's not clear yet how applications will want to handle it, but ; that is left to the application. Still, it might be preferable to impose ; some restrictions which can later be relaxed as necessary. ; ??? It would be useful to have two names for each value: asm name, enum name. ;; Pick out name first to augment the error context. ;; default to NAME- "-";; FIXME: parse values. """: mode"": enum-prefix"": name-prefix"; Read a keyword description ; This is the main routine for analyzing a keyword description in the .cpu ; file. ; CONTEXT is a <context> object for error messages. ; ARG-LIST is an associative list of field name and field value. ; -keyword-parse is invoked to create the <keyword> object. "";; #f indicates "not set" ""; Loop over each element in ARG-LIST, recording what's found. ;; Renamed to enum-prefix in rtl version 0.8. "print-name renamed to enum-prefix";; enum-prefix added in rtl version 0.8. "invalid hardware arg";; Renamed to name-prefix in rtl version 0.8. "prefix renamed to name-prefix";; name-prefix added in rtl version 0.8. "invalid hardware arg""invalid hardware arg"; Now that we've identified the elements, build the object. ; Define a keyword object, name/value pair list version. "define-keyword"; Define an enum so the values are usable everywhere. ; One use is giving names to register numbers and special constants ; to make periphery C/C++ code more legible. ; FIXME: Should pass on mode to enum. ;; Prior to rtl version 0.8 we up-cased the prefix here ;; and added the trailing - ourselves. "-"; Parsing support. ; List of hardware types. ; This maps names in the `type' entry of define-hardware to the class name. ; Parse an inline keyword spec. ; These are keywords defined inside something else. ; CONTAINER is the <ident> object of the container. "invalid keyword spec"; Name, comment, and attributes are copied from our container object. ; They're needed to output the table. ; ??? This isn't quite right as some day a container may contain multiple ; keyword instances. To be fixed in time. ;; PRIVATE: keyword table is implicitly defined, it isn't ;; accessible with current-kw-lookup. ;; This is unused, use a magic value to catch any uses. "UNUSED"; prefix ; value ; Parse an indices spec. ; CONTAINER is the <ident> object of the container. ; Currently there is only special support for keywords. ; Otherwise MODE is used. ; The syntax is: (keyword keyword-spec) - see <keyword> for details. "invalid indices spec""missing keyword name""unknown keyword""unknown indices type"; Parse a values spec. ; CONTAINER is the <ident> object of the container. ; Currently there is only special support for keywords. ; Otherwise MODE is used. ; The syntax is: (keyword keyword-spec) - see <keyword> for details. "invalid values spec""missing keyword name""unknown keyword""unknown values type"; Parse a handlers spec. ; Each element is (name "string"). ; Parse a getter spec. ; The syntax is (([index]) (expression)). ; Omit `index' for scalar objects. ; Externally they're specified as `get'. Internally we use `getter'. ; use default "((index) (expression))""(() (expression))""invalid getter, should be ""invalid rtx expression"; Parse a setter spec. ; The syntax is (([index] newval) (expression)). ; Omit `index' for scalar objects. ; Externally they're specified as `set'. Internally we use `setter'. ; use default "((index newval) (expression))""((newval) (expression))""invalid setter, should be ""invalid rtx expression"; Parse hardware description ; This is the main routine for building a hardware object from a hardware ; description in the .cpu file. ; All arguments are in raw (non-evaluated) form. ; The result is the parsed object or #f if object isn't for selected mach(s). ; ; ??? Might want to redo to handle hardware type specific specs more cleanly. ; E.g. <hw-immediate> shouldn't have to see get/set specs. "Processing hardware element "" ...\n""missing hardware type";; Pick out name first to augment the error context. "cgen_hw""unknown hardware type"; If this is a virtual reg, get/set specs must be provided. "virtual reg requires get/set specs"; If get or set specs are specified, can't have CACHE-ADDR. "can't have CACHE-ADDR with get/set specs""Ignoring "".\n"; Read a hardware description ; This is the main routine for analyzing a hardware description in the .cpu ; file. ; CONTEXT is a <context> object for error messages. ; ARG-LIST is an associative list of field name and field value. ; -hw-parse is invoked to create the <hardware> object. ""; name used in semantics, default is `name' ; hardware type (register, immediate, etc.) ; Loop over each element in ARG-LIST, recording what's found. "invalid hardware arg"; Now that we've identified the elements, build the object. ; Define a hardware object, name/value pair list version. "define-hardware"; Define a hardware object, all arguments specified. "define-full-hardware"; Main routine for modifying existing definitions. "modify-hardware"; FIXME: Experiment. This implements the :name/value style by ; converting it to (name value). In the end there shouldn't be two ; styles. People might prefer :name/value, but it's not as amenable ; to macro processing (insert potshots regarding macro usage). ; First find out which element. ; There's no requirement that the name be specified first. "hardware name not specified""undefined hardware element"; Process the rest of the args now that we have the affected object. ; done ; ignore, already processed "cgen_hw"; prepend attrs so new ones override existing ones "invalid/unsupported option"; Lookup a hardware object using its semantic name. ; The result is a list of elements with SEM-NAME. ; Callers must deal with cases where there is more than one. ; Same as current-hw-sem-lookup, but result is 1 hw element or #f if not ; found. An error is signalled if multiple hw elements are found. "ambiguous hardware reference"; Basic hardware types. ; These inherit from `hardware-base'. ; ??? Might wish to allow each target to add more, but we provide enough ; examples to cover most cpus. ; A register (or an array of them). ; Subroutine of -hw-create-[gs]etter-from-layout to validate a layout. ; Valid values: ; - 0 or 1 ; - (value length) ; - hardware-name "layout is not a list"; Done. Now see if number of bits in layout matches total width. "insufficient number of bits (need "")"; Validate next entry. "non 0/1 layout entry requires length""syntax error in layout, expecting `(value length)'""unknown hardware element""non-scalar hardware element""bad layout element"; Return the getter spec to use for LAYOUT. ; WIDTH is the width of the combined value in bits. ; ; Example: ; Assuming h-hw[123] are 1 bit registers, and width is 32 ; given ((0 29) h-hw1 h-hw2 h-hw3), return ; (() ; (or SI (sll SI (zext SI (reg h-hw1)) 2) ; (or SI (sll SI (zext SI (reg h-hw2)) 1) ; (zext SI (reg h-hw3))))) ; getter spec: (get () (expression)) ; ignore if zero ; ignore if zero "bad layout element"; Return the setter spec to use for LAYOUT. ; WIDTH is the width of the combined value in bits. ; ; Example: ; Assuming h-hw[123] are 1 bit registers, ; given (h-hw1 h-hw2 h-hw3), return ; ((val) ; (sequence () ; (set (reg h-hw1) (and (srl val 2) 1)) ; (set (reg h-hw2) (and (srl val 1) 1)) ; (set (reg h-hw3) (and (srl val 0) 1)) ; )) ; setter spec: (set (val) (expression)) "bad layout element"; Parse a register spec. ; .cpu syntax: (register mode [(dimension)]) ; or: (register (mode bits) [(dimension)]) "invalid register spec""bad register dimension spec"; Must parse and set type before analyzing LAYOUT. ; LAYOUT is a shorthand way of specifying getter/setter specs. ; For registers that are just a collection of other registers ; (e.g. the status register in mips), it's easier to specify the ; registers that make up the bigger register, rather than to specify ; get/set specs. ; We don't override any provided get/set specs though. ; Return boolean indicating if hardware element is some kind of register. ; Return a boolean indicating if it's ok to reference SELF in mode ; NEW-MODE-NAME, index INDEX. ; ; ??? INDEX isn't currently used. The intent is to use it if it's a known ; value, and otherwise assume for our purposes it's valid and leave any ; further error checking to elsewhere. ; ; ??? This method makes more sense if we support multiple modes via ; getters/setters. Maybe we will some day, so this is left as is for now. ; ??? Subject to revisiting. ; Only allow floats if same mode (which is handled above). ; Only allow non-widening if ints. ; On architectures where shortening/widening can refer to a ; quasi-different register, it is up to the target to handle this. ; See the comments for the getter/setter/getters/setters class ; members. ; Compensate for registers defined with an unsigned mode. ; Return mode to use for the index or #f if scalar. ; The program counter (PC) hardware register. ; This is a separate class as the simulator needs a place to put special ; get/set methods. ; Parse a pc spec. "indices specified for pc""values specified for pc""layout specified for pc"; The initial value of INDICES, VALUES is #f which is what we want. ; Indicate we're the pc. ; Memory. ; Parse a memory spec. ; .cpu syntax: (memory mode [(dimension)]) ; or: (memory (mode bits) [(dimension)]) "invalid memory spec""bad memory dimension spec""layout specified for memory"; Setting INDICES,VALUES here is mostly for experimentation at present. ; Return boolean indicating if hardware element is some kind of memory. ; Return a boolean indicating if it's ok to reference SELF in mode ; NEW-MODE-NAME, index INDEX. ; Allow any mode for now. ; Return mode to use for the index or #f if scalar. ; Immediate values (numbers recorded in the insn). ; Parse an immediate spec. ; .cpu syntax: (immediate mode) ; or: (immediate (mode bits)) "invalid immediate spec"; An array of immediates may be useful some day, but not yet. "indices specified for immediate""layout specified for immediate""getter specified for immediate""setter specified for immediate"; Return a boolean indicating if it's ok to reference SELF in mode ; NEW-MODE-NAME, index INDEX. ; ??? Subject to revisiting. ; Only allow floats if same mode (which is handled above). ; For ints allow anything. ; These are scalars. ; Addresses. ; These are usually symbols. ; Parse an address spec. "invalid address spec""indices specified for address""values specified for address""layout specified for address""getter specified for address""setter specified for address"; Return a boolean indicating if it's ok to reference SELF in mode ; NEW-MODE-NAME, index INDEX. ; We currently don't allow referencing an address in any mode other than ; the original mode. ; Instruction addresses. ; These are treated separately from normal addresses as the simulator ; may wish to treat them specially. ; FIXME: Doesn't use mode IAI. ; Misc. random hardware support. ; Map a mode to a hardware object that can contain immediate values of that ; mode. "Don't know h-object for mode "; Called when a cpu-family is read in to set the word sizes. ; Must be called after mode-set-word-modes! has been called. ; Builtins, attributes, init/fini support. ; Called before reading a .cpu file in. "\ Define a keyword, name/value pair list version. ""\ Define a hardware element, name/value pair list version. ""\ Define a hardware element, all arguments specified. ""\ Modify a hardware element, name/value pair list version. "; Install builtin hardware objects. ; Standard h/w attributes. "cache register address during insn extraction"; FIXME: This should be deletable. "the program counter""collect profiling data"; ??? The program counter, h-pc, used to be defined here. ; However, some targets need to modify it (e.g. provide special get/set ; specs). There's still an outstanding issue of how to add things to ; objects after the fact (e.g. model parameters to instructions), but ; that's further down the road. "memory"; Ensure memory not flagged as a scalar. "signed integer""unsigned integer""address""print_address"; Instruction addresses. ; These are different because the simulator may want to do something ; special with them, and some architectures treat them differently. "instruction address""print_address"; Called after a .cpu file has been read in.
Go to most recent revision | Compare with Previous | Blame | View Log