• file
• revisions
• annotate
• diff
• comparison
• raw

src/share/vm/adlc/Doc/Syntax.doc@98cb887364d3 (annotated)

src/share/vm/adlc/Doc/Syntax.doc

Fri, 27 Feb 2009 13:27:09 -0800

author

twisti

date

Fri, 27 Feb 2009 13:27:09 -0800

changeset 1040

98cb887364d3

parent 435

a61af66fc99e

child 1907

c18cbe5936b8

permissions

-rw-r--r--

6810672: Comment typos
Summary: I have collected some typos I have found while looking at the code.
Reviewed-by: kvn, never

duke@435	1	#
duke@435	2	# Copyright 1997-1998 Sun Microsystems, Inc. All Rights Reserved.
duke@435	3	# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
duke@435	4	#
duke@435	5	# This code is free software; you can redistribute it and/or modify it
duke@435	6	# under the terms of the GNU General Public License version 2 only, as
duke@435	7	# published by the Free Software Foundation.
duke@435	8	#
duke@435	9	# This code is distributed in the hope that it will be useful, but WITHOUT
duke@435	10	# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
duke@435	11	# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
duke@435	12	# version 2 for more details (a copy is included in the LICENSE file that
duke@435	13	# accompanied this code).
duke@435	14	#
duke@435	15	# You should have received a copy of the GNU General Public License version
duke@435	16	# 2 along with this work; if not, write to the Free Software Foundation,
duke@435	17	# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
duke@435	18	#
duke@435	19	# Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara,
duke@435	20	# CA 95054 USA or visit www.sun.com if you need additional information or
duke@435	21	# have any questions.
duke@435	22	#
duke@435	23	#
duke@435	24
duke@435	25	JavaSoft HotSpot Architecture Description Language Syntax Specification
duke@435	26
duke@435	27	Version 0.4 - September 19, 1997
duke@435	28
duke@435	29	A. Introduction
duke@435	30
duke@435	31	This document specifies the syntax and associated semantics for the JavaSoft
duke@435	32	HotSpot Architecture Description Language. This language is used to describe
duke@435	33	the architecture of a processor, and is the input to the ADL Compiler. The
duke@435	34	ADL Compiler compiles an ADL file into code which is incorporated into the
duke@435	35	Optimizing Just In Time Compiler (OJIT) to generate efficient and correct code
duke@435	36	for the target architecture. The ADL describes three bassic different types
duke@435	37	of architectural features. It describes the instruction set (and associated
duke@435	38	operands) of the target architecture. It describes the register set of the
duke@435	39	target architecture along with relevant information for the register allocator.
duke@435	40	Finally, it describes the architecture's pipeline for scheduling purposes.
duke@435	41	The ADL is used to create an architecture description file for a target
duke@435	42	architecture. The architecture description file along with some additional
duke@435	43	target specific oracles, written in C++, represent the principal effort in
duke@435	44	porting the OJIT to a new target architecture.
duke@435	45
duke@435	46
duke@435	47	B. Example Syntax
duke@435	48
duke@435	49	1. Instruction/Operand Syntax for Matching and Encoding
duke@435	50
duke@435	51	// Create a cost attribute for all operands, and specify the default value
duke@435	52	op_attrib op_cost(10);
duke@435	53
duke@435	54	// Create a cost attribute for all instruction, and specify a default value
duke@435	55	ins_attrib ins_cost(100);
duke@435	56
duke@435	57	// example operand form
duke@435	58	operand x_reg(REG_NUM rnum)
duke@435	59	%{
duke@435	60	constraint(IS_RCLASS(rnum, RC_X_REG));
duke@435	61
duke@435	62	match(VREG) %{ rnum = new_VR(); %} // block after rule is constructor
duke@435	63
duke@435	64	encode %{ return rnum; %} // encode rules are required
duke@435	65
duke@435	66	// this operand has no op_cost entry because it uses the default value
duke@435	67	%}
duke@435	68
duke@435	69	// example instruction form
duke@435	70	instruct add_accum_reg(x_reg dst, reg src)
duke@435	71	%{
duke@435	72	match(SET dst (PLUS dst src)); // no block = use default constructor
duke@435	73
duke@435	74	encode // rule is body of a C++ function
duke@435	75	%{
duke@435	76	return pentium_encode_add_accum_reg(rnum);
duke@435	77	%}
duke@435	78
duke@435	79	ins_cost(200); // this instruction is more costly than the default
duke@435	80	%}
duke@435	81
duke@435	82	2. Register Set Description Syntax for Allocation
duke@435	83
duke@435	84	reg_def AX(SOE, 1); // declare register AX, mark it save on entry with index 0
duke@435	85	reg_def BX(SOC); // declare register BX, and mark it save on call
duke@435	86
duke@435	87	reg_class X_REG(AX, BX); // form a matcher register class of X_REG
duke@435	88	// these are used for constraints, etc.
duke@435	89
duke@435	90	alloc_class class1(AX, BX); // form an allocation class of registers
twisti@1040	91	// used by the register allocator for separate
duke@435	92	// allocation of target register classes
duke@435	93
duke@435	94	3. Pipeline Syntax for Scheduling
duke@435	95
duke@435	96
duke@435	97	C. Keywords
duke@435	98
duke@435	99	1. Matching/Encoding
duke@435	100	a. instruct - indicates a machine instruction entry
duke@435	101	b. operand - indicates a machine operand entry
duke@435	102	c. opclass - indicates a class of machine operands
duke@435	103	d. source - indicates a block of C++ source code
duke@435	104	e. op_attrib - indicates an optional attribute for all operands
duke@435	105	f. ins_attrib - indicates an optional attribute for all instructions
duke@435	106	g. match - indicates a matching rule for an operand/instruction
duke@435	107	h. encode - indicates an encoding rule for an operand/instruction
duke@435	108	i. predicate - indicates a predicate for matching operand/instruction
duke@435	109	*j. constraint - indicates a constraint on the value of an operand
duke@435	110	*k. effect - describes the dataflow effect of an operand which
duke@435	111	is not part of a match rule
duke@435	112	*l. expand - indicates a single instruction for matching which
duke@435	113	expands to multiple instructions for output
duke@435	114	*m. rewrite - indicates a single instruction for matching which
duke@435	115	gets rewritten to one or more instructions after
duke@435	116	allocation depending upon the registers allocated
duke@435	117	*n. format - indicates a format rule for an operand/instruction
duke@435	118	o. construct - indicates a default constructor for an operand
duke@435	119
duke@435	120	[NOTE: * indicates a feature which will not be in first release ]
duke@435	121
duke@435	122	2. Register
duke@435	123	*a. register - indicates an architecture register definition section
duke@435	124	*b. reg_def - indicates a register declaration
duke@435	125	*b. reg_class - indicates a class (list) of registers for matching
duke@435	126	*c. alloc_class - indicates a class (list) of registers for allocation
duke@435	127
duke@435	128	3. Pipeline
duke@435	129	*a. pipeline - indicates an architecture pipeline definition section
duke@435	130	*b. resource - indicates a pipeline resource used by instructions
duke@435	131	*c. pipe_desc - indicates the relevant stages of the pipeline
duke@435	132	*d. pipe_class - indicates a description of the pipeline behavior
duke@435	133	for a group of instructions
duke@435	134	*e. ins_pipe - indicates what pipeline class an instruction is in
duke@435	135
duke@435	136
duke@435	137	D. Delimiters
duke@435	138
duke@435	139	1. Comments
duke@435	140	a. /* ... */ (like C code)
duke@435	141	b. // ... EOL (like C++ code)
duke@435	142	c. Comments must be preceeded by whitespace
duke@435	143
duke@435	144	2. Blocks
duke@435	145	a. %{ ... %} (% just distinguishes from C++ syntax)
duke@435	146	b. Must be whitespace before and after block delimiters
duke@435	147
duke@435	148	3. Terminators
duke@435	149	a. ; (standard statement terminator)
duke@435	150	b. %} (block terminator)
duke@435	151	c. EOF (file terminator)
duke@435	152
twisti@1040	153	4. Each statement must start on a separate line
duke@435	154
duke@435	155	5. Identifiers cannot contain: (){}%;,"/\
duke@435	156
duke@435	157	E. Instruction Form: instruct instr1(oper1 dst, oper2 src) %{ ... %}
duke@435	158
duke@435	159	1. Identifier (scope of all instruction names is global in ADL file)
duke@435	160	2. Operands
duke@435	161	a. Specified in argument style: (<type> <name>, ...)
duke@435	162	b. Type must be the name of an Operand Form
duke@435	163	c. Name is a locally scoped name, used for substitution, etc.
duke@435	164	3. Match Rule: match(SET dst (PLUS dst src));
duke@435	165	a. Parenthesized Inorder Binary Tree: [lft = left; rgh = right]
duke@435	166	(root root->lft (root->rgh (root->rgh->lft root->rgh->rgh)))
duke@435	167	b. Interior nodes in tree are operators (nodes) in abstract IR
duke@435	168	c. Leaves are operands from instruction operand list
duke@435	169	d. Assignment operation and destination, which are implicit
duke@435	170	in the abstract IR, must be specified in the match rule.
duke@435	171	4. Encode Rule: encode %{ return CONST; %}
duke@435	172	a. Block form must contain C++ code which constitutes the
duke@435	173	body of a C++ function which takes no arguments, and
duke@435	174	returns an integer.
duke@435	175	b. Local names (operand names) are can be used as substitution
duke@435	176	symbols in the code.
duke@435	177	5. Attribute (ins_attrib): ins_cost(37);
duke@435	178	a. Identifier (must be name defined as instruction attribute)
duke@435	179	b. Argument must be a constant value or a C++ expression which
duke@435	180	evaluates to a constant at compile time.
duke@435	181	*6. Effect: effect(src, OP_KILL);
duke@435	182	a. Arguments must be the name of an operand and one of the
duke@435	183	pre-defined effect type symbols:
duke@435	184	OP_DEF, OP_USE, OP_KILL, OP_USE_DEF, OP_DEF_USE, OP_USE_KILL
duke@435	185	*7. Expand:
duke@435	186	a. Parameters for the new instructions must be the name of
duke@435	187	an expand rule temporary operand or must match the local
duke@435	188	operand name in both the instruction being expanded and
duke@435	189	the new instruction being generated.
duke@435	190
duke@435	191	instruct convI2B( xRegI dst, eRegI src ) %{
duke@435	192	match(Set dst (Conv2B src));
duke@435	193
duke@435	194	expand %{
duke@435	195	eFlagsReg cr;
duke@435	196	loadZero(dst);
duke@435	197	testI_zero(cr,src);
duke@435	198	set_nz(dst,cr);
duke@435	199	%}
duke@435	200	%}
duke@435	201	// Move zero into a register without setting flags
duke@435	202	instruct loadZero(eRegI dst) %{
duke@435	203	effect( DEF dst );
duke@435	204	format %{ "MOV $dst,0" %}
duke@435	205	opcode(0xB8); // +rd
duke@435	206	ins_encode( LdI0(dst) );
duke@435	207	%}
duke@435	208
duke@435	209	*8. Rewrite
duke@435	210	9. Format: format(add_X $src, $dst); | format %{ ... %}
duke@435	211	a. Argument form takes a text string, possibly containing
duke@435	212	some substitution symbols, which will be printed out
duke@435	213	to the assembly language file.
duke@435	214	b. The block form takes valid C++ code which forms the body
duke@435	215	of a function which takes no arguments, and returns a
duke@435	216	pointer to a string to print out to the assembly file.
duke@435	217
duke@435	218	Mentions of a literal register r in a or b must be of
duke@435	219	the form r_enc or r_num. The form r_enc refers to the
duke@435	220	encoding of the register in an instruction. The form
duke@435	221	r_num refers to the number of the register. While
duke@435	222	r_num is unique, two different registers may have the
duke@435	223	same r_enc, as, for example, an integer and a floating
duke@435	224	point register.
duke@435	225
duke@435	226
duke@435	227	F. Operand Form: operand x_reg(REG_T rall) %{ ... %}
duke@435	228	1. Identifier (scope of all operand names is global in ADL file)
duke@435	229	2. Components
duke@435	230	a. Specified in argument style: (<type> <name>, ...)
duke@435	231	b. Type must be a predefined Component Type
duke@435	232	c. Name is a locally scoped name, used for substitution, etc.
duke@435	233	3. Match: (VREG)
duke@435	234	a. Parenthesized Inorder Binary Tree: [lft = left; rgh = right]
duke@435	235	(root root->lft (root->rgh (root->rgh->lft root->rgh->rgh)))
duke@435	236	b. Interior nodes in tree are operators (nodes) in abstract IR
duke@435	237	c. Leaves are components from operand component list
duke@435	238	d. Block following tree is the body of a C++ function taking
duke@435	239	no arguments and returning no value, which assigns values
duke@435	240	to the components of the operand at match time.
duke@435	241	4. Encode: encode %{ return CONST; %}
duke@435	242	a. Block form must contain C++ code which constitutes the
duke@435	243	body of a C++ function which takes no arguments, and
duke@435	244	returns an integer.
duke@435	245	b. Local names (operand names) are can be used as substitution
duke@435	246	symbols in the code.
duke@435	247	5. Attribute (op_attrib): op_cost(5);
duke@435	248	a. Identifier (must be name defined as operand attribute)
duke@435	249	b. Argument must be a constant value or a C++ expression which
duke@435	250	evaluates to a constant at compile time.
duke@435	251	6. Predicate: predicate(0 <= src < 256);
duke@435	252	a. Argument must be a valid C++ expression which evaluates
duke@435	253	to either TRUE of FALSE at run time.
duke@435	254	*7. Constraint: constraint(IS_RCLASS(dst, RC_X_CLASS));
duke@435	255	a. Arguments must contain only predefined constraint
duke@435	256	functions on values defined in the AD file.
duke@435	257	b. Multiple arguments can be chained together logically
duke@435	258	with "&&".
duke@435	259	8. Construct: construct %{ ... %}
duke@435	260	a. Block must be a valid C++ function body which takes no
duke@435	261	arguments, and returns no values.
duke@435	262	b. Purpose of block is to assign values to the elements
duke@435	263	of an operand which is constructed outside the matching
duke@435	264	process.
duke@435	265	c. This block is logically identical to the constructor
duke@435	266	block in a match rule.
duke@435	267	9. Format: format(add_X $src, $dst); | format %{ ... %}
duke@435	268	a. Argument form takes a text string, possibly containing
duke@435	269	some substitution symbols, which will be printed out
duke@435	270	to the assembly language file.
duke@435	271	b. The block form takes valid C++ code which forms the body
duke@435	272	of a function which takes no arguments, and returns a
duke@435	273	pointer to a string to print out to the assembly file.
duke@435	274
duke@435	275	Mentions of a literal register r in a or b must be of
duke@435	276	the form r_enc or r_num. The form r_enc refers to the
duke@435	277	encoding of the register in an instruction. The form
duke@435	278	r_num refers to the number of the register. While
duke@435	279	r_num is unique, two different registers may have the
duke@435	280	same r_enc, as, for example, an integer and a floating
duke@435	281	point register.
duke@435	282
duke@435	283	G. Operand Class Form: opclass memory( direct, indirect, ind_offset);
duke@435	284
duke@435	285	H. Attribute Form (keywords ins_atrib & op_attrib): ins_attrib ins_cost(10);
duke@435	286	1. Identifier (scope of all attribute names is global in ADL file)
duke@435	287	2. Argument must be a valid C++ expression which evaluates to a
duke@435	288	constant at compile time, and specifies the default value of
duke@435	289	this attribute if attribute definition is not included in an
duke@435	290	operand/instruction.
duke@435	291
duke@435	292	I. Source Form: source %{ ... %}
duke@435	293	1. Source Block
duke@435	294	a. All source blocks are delimited by "%{" and "%}".
duke@435	295	b. All source blocks are copied verbatim into the
duke@435	296	C++ output file, and must be valid C++ code.
duke@435	297
duke@435	298	Mentions of a literal register r in this code must
duke@435	299	be of the form r_enc or r_num. The form r_enc
duke@435	300	refers to the encoding of the register in an
duke@435	301	instruction. The form r_num refers to the number of
duke@435	302	the register. While r_num is unique, two different
duke@435	303	registers may have the same r_enc, as, for example,
duke@435	304	an integer and a floating point register.
duke@435	305
duke@435	306
duke@435	307	J. *Register Form: register %{ ... %}
duke@435	308	1. Block contains architecture specific information for allocation
duke@435	309	2. Reg_def: reg_def reg_AX(1);
duke@435	310	a. Identifier is name by which register will be referenced
duke@435	311	throughout the rest of the AD, and the allocator and
duke@435	312	back-end.
duke@435	313	b. Argument is the Save on Entry index (where 0 means that
duke@435	314	the register is Save on Call). This is used by the
duke@435	315	frame management routines for generating register saves
duke@435	316	and restores.
duke@435	317	3. Reg_class: reg_class x_regs(reg_AX, reg_BX, reg_CX, reg_DX);
duke@435	318	a. Identifier is the name of the class used throughout the
duke@435	319	instruction selector.
duke@435	320	b. Arguments are a list of register names in the class.
duke@435	321	4. Alloc_class: alloc_class x_alloc(reg_AX, reg_BX, reg_CX, reg_DX);
duke@435	322	a. Identifier is the name of the class used throughout the
duke@435	323	register allocator.
duke@435	324	b. Arguments are a list of register names in the class.
duke@435	325
duke@435	326
duke@435	327	K. *Pipeline Form: pipeline %{ ... %}
duke@435	328	1. Block contains architecture specific information for scheduling
duke@435	329	2. Resource: resource(ialu1);
duke@435	330	a. Argument is the name of the resource.
duke@435	331	3. Pipe_desc: pipe_desc(Address, Access, Read, Execute);
duke@435	332	a. Arguments are names of relevant phases of the pipeline.
duke@435	333	b. If ALL instructions behave identically in a pipeline
duke@435	334	phase, it does not need to be specified. (This is typically
duke@435	335	true for pre-fetch, fetch, and decode pipeline stages.)
duke@435	336	c. There must be one name per cycle consumed in the
duke@435	337	pipeline, even if there is no instruction which has
duke@435	338	significant behavior in that stage (for instance, extra
duke@435	339	stages inserted for load and store instructions which
duke@435	340	are just cycles which pass waiting for the completion
duke@435	341	of the memory operation).
duke@435	342	4. Pipe_class: pipe_class pipe_normal(dagen; ; membus; ialu1, ialu2);
duke@435	343	a. Identifier names the class for use in ins_pipe statements
duke@435	344	b. Arguments are a list of stages, separated by ;'s which
duke@435	345	contain comma separated lists of resource names.
duke@435	346	c. There must be an entry for each stage defined in the
duke@435	347	pipe_desc statement, (even if it is empty as in the example)
duke@435	348	and entries are associated with stages by the order of
duke@435	349	stage declarations in the pipe_desc statement.
duke@435	350