OpenCores
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

powered by: WebSVN 2.1.0

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