Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Begin specifying object model #393

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions specs/language/basic.tex
Original file line number Diff line number Diff line change
@@ -404,6 +404,7 @@
type or if the sequence of types defined by the scalar representation \(SR(T1)\)
and scalar representation \(SR(T2)\) are identical.

\Sec{Storage Duration}{Basic.Storage}
\Sec{Lvalues and rvalues}{Basic.lval}

\p Expressions are classified by the type(s) of values they produce. The valid
40 changes: 16 additions & 24 deletions specs/language/declarations.tex
Original file line number Diff line number Diff line change
@@ -74,37 +74,29 @@

\Sub{Aggregate Initialization}{Decl.Init.Agg}

\p An \textit{aggregate} is a vector, matrix, array, or class.

\p The subobjects of an aggregate have a defined order. For vectors and arrays
the order is increasing subscript order. For matrices it is increasing subscript
order with the subscript nesting such that in the notation
\texttt{Mat[M][N]}, the ordering is \(Mat[0][0]...Mat[0][N]...
Mat[M][0]...Mat[M][N]\). For classes the order is base class, followed by member
subobjects in declaration order.

\p A \textit{flattened ordering} of subobjects can be produced by performing a
depth-first traversal of the subobjects of an object following the defined
subobject ordering.
\p An \textit{aggregate} is a vector, matrix, array, or class that does not have
explicit constructors (\ref{Classes.Special}) or non-public data members
(\ref{Classes.Access}). An aggregate may contain non-aggregate members as long
as the non-aggregate members have default constructors and copy constructors
defined.

\p Each \textit{braced initializer list} is comprised of zero or more
\textit{initializer-clause} expressions, which is either another braced
initializer list or an expression which generates a value that either is or can
be implicitly converted to an rvalue. Each assignment-expression is an object,
which may be a scalar or aggregate type. A \textit{flattened initializer
sequence} is constructed by a depth-first traversal over each
assignment-expression in an initializer-list and performing a depth-first
traversal accessing each subobject of the assignment-expression.
which may be a scalar or aggregate type. A \textit{element-wise initializer
sequence} is constructed by concatenating the scalar element ordering
Copy link
Collaborator

@farzonl farzonl Feb 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I see how this would work for matricies and vectors and 1 dim arrays. I'm not as clear on how it works for multi dim Arrays and Classes of classes/structs. I think the depth-first traversal algorithm covered finding these nested initalizers. Can you explain what concatenating is doing here to cover cases like arrays of classes and classes of classes?

Second should we link scalar element ordering to line 363 in specs/language/introduction.tex?

When I think scalar i'm thinking the non container types like primitive types like float/int/bool/etc which makes me think we are excluding classes, but thats at odds with the types Aggregate Initialization covers.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you suggesting something other than the (\ref{Intro.Object.SubOrdering}) that is right after the use of the term?

(\ref{Intro.Object.SubOrdering}) of each initializer-clause.

\p An initializer-list is a valid initializer if for each element \(E_n\) in the
target object's flattened ordering there is a corresponding initializer \(I_n\)
in the flattened initializer sequence which can be implicitly converted to the
element's type.

\p An initializer-list is invalid if the flattened initializer sequence contains
more or fewer elements than the target object's flattened ordering, or if any
initializer \(I_n\) cannot be implicitly converted to the corresponding element
\(E_n\)'s type.
target object's scalar element ordering there is a corresponding initializer
\(I_n\) in the element-wise initializer sequence which can be implicitly
converted to the element's type.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe reference E_n here, 'which can be implicitly converted to 'E_n's type'


\p An initializer-list is invalid if the element-wise initializer sequence
contains more or fewer elements than the target object's scalar element
ordering, or if any initializer \(I_n\) cannot be implicitly converted to the
corresponding element \(E_n\)'s type.

\Sec{Function Definitions}{Decl.Function}
\Sec{Attributes}{Decl.Attr}
60 changes: 60 additions & 0 deletions specs/language/introduction.tex
Original file line number Diff line number Diff line change
@@ -327,3 +327,63 @@
\p The alignment requirements of an offset into device memory space is the size
in bytes of the largest scalar type contained in the given aggregate type.

\Sec{\acrshort{hlsl} Object Models}{Intro.Object}

\p An \acrshort{hlsl} program is a collection of operations that create,
destroy, and otherwise manipulate \textit{objects}. An object has a
\texttt{type} (\ref{Basic.types}). An object is created by a \textit{definition}
(\ref{Basic.Decl}), or by the implementation when needed, as in the example
cases of lvalue-to-rvalue conversions (\ref{Conv.lval}) or call expression
argument temporaries (\ref{Expr.Post.Call}). An object can have a name
(\ref{Basic.preamble}). An object has a \textit{storage duration}
(\ref{Basic.Storage}), which impacts its \textit{lifetime}
(\ref{Intro.Object.Lifetime}).

\p An object may contain other objects; an object contained by another object is
called a \textit{sub-object}. An object that is not contained by any other object
is called a \textit{complete object}.

\p An object or sub-object that is a non-intangible type will have an associated
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I recall there being some disagreement about this term before, non-intangible type. I think its easy to skim over this word and hear 'non tangible' type. Could we be more clear and say 'Not an Intangible type'? Or do we need a one word phrase?

memory location. An object of intangible type will only have a memory location
if it contains a sub-object of non-intangible type (\ref{Basic.types}).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tangible type?


\Sub{Sub-object Ordering}{Intro.Object.SubOrdering}

\p The sub-objects of an object have a defined order. For vectors and arrays
the order is increasing subscript order. For matrices it is increasing subscript
order with the subscript nesting such that in the notation
\texttt{Mat[M][N]}, the ordering is \(Mat[0][0]...Mat[0][N]...
Mat[M][0]...Mat[M][N]\). For classes the order is base class, followed by member
sub-objects in declaration order.

\p Objects that have explicit construction or destruction behavior
(\ref{Classes.Special}) or non-public data members (\ref{Classes.Access}) are
\textit{non-decomposable}.

\p A \textit{scalar element ordering} of sub-objects can be produced by
performing a depth-first traversal of the sub-objects of an object following the
defined sub-object ordering. A scalar element ordering will include
non-decomposable sub-objects as whole objects not deconstructed into their
sub-objects.

\begin{note}
\p Consider the code below:

\begin{HLSL}
struct Firetruck {
int Wheels[4];
half2 Lights;
bool Siren;
RWBuffer<float4> Hose;
};
\end{HLSL}

\p The scalar element ordering of sub-object types is: [\texttt{int}, \texttt{int},
\texttt{int}, \texttt{int}, \texttt{half}, \texttt{half}, \texttt{bool},
\texttt{RWBuffer<float4>}]. This ordering preserves the
\texttt{RWBuffer<float4>} rather than traversing into its sub-objects because it
is a non-decomposable sub-object.

\end{note}

\Sub{Object Lifetime}{Intro.Object.Lifetime}
2 changes: 2 additions & 0 deletions specs/language/placeholders.tex
Original file line number Diff line number Diff line change
@@ -7,6 +7,8 @@
\Ch{Classes}{Classes}
\Sec{Static Members}{Classes.Static}
\Sec{Conversions}{Classes.Conversions}
\Sec{Member Access Control}{Classes.Access}
\Sec{Special Member Functions}{Classes.Special}
\Ch{Templates}{Template}
\Sec{Template Instantiation}{Template.Inst}
\Sec{Partial Ordering of Function Templates}{Template.Func.Order}