►
From YouTube: OMR Compiler Extensible Classes 20180312
Description
This talk gives a high-level overview of the extensible class design in the Eclipse OMR compiler technology. It describes the motivation behind it, how to architect classes and enums for extensibility, and provides abstract and concrete examples.
A
A
Okay,
so
I'm
just
going
to
give
a
little
bit
of
history
behind
this,
so
what
we
started.
Looking
at
open
sourcing,
a
lot
of
this
compiler
technology
back
in
2013
five
years
ago.
You
know
we
we
had
the
the
technology
would
use
across
a
fairly
broad
spectrum
of
compiler
technology,
so
Java
C++
COBOL,
that's
the
sort
of
a
handful.
There
was
a
variety
of
different
consumers
of
this
technology
and
when
we
started
thinking
about
you
know
what
we
were
going
to
do
with
this
technology,
how
it
could
grow.
A
You
know
we
wanted
to
think
about
how
this
technology
could
be
used
in
the
cloud,
so
that
led
us
to
distilling
the
core
components
of
this
compiler
technology
into
an
open
source
toolkit
of
reusable
customizable
language,
agnostic,
compiler
components.
So
this
was
our
effort
on
pulling
apart
the
compiler
technology.
A
So
how
are
we
going
to
do
that?
So
how
are
we
going
to
take
that
technology
in
the
compiler
and
open
source
said
so
well?
What
we
did
was
we
started
with
the
the
very
large
blob
of
code
that
we,
that
was
Testarossa,
and
at
that
time
it
was
about
a
million
and
a
half
lines
of
code
and
what
we
did
was
we
identified
the
basically
the
core
pieces
of
that.
That
would
be
interesting
enough
to
be
able
to
build
parts
for
other
compilers
and
other
language
runtimes.
A
So,
for
example,
things
like
symbols
and
instructions,
and
you
know,
registers
that
kind
of
thing
all
these
different
kinds
of
classes
that
you'd
find
in
that
technology
they're,
definitely
applicable
in
other
compilers
as
well,
and
then,
once
we
kind
of
go
through
that,
we
sort
of
figured
out
what
the
what
parts
of
this
technology
could
somebody
actually
extend,
because
and
and
what
is
the
where
will
they
get
their
hands
on
the
different
parts
to
extend
so
things
like
classes?
For
example,
can
you
extend
a
class?
A
We
have
a
lot
of
data,
that's
sort
of
represented,
as
enumeration
so
can
be
extended,
or
if
you
look
at
things
like
up
the
aisle
opcodes
and
and
instruction
things
like
that,
they're
all
stored
in
these
static
tables.
So
is
it
possible
to
extend
those
as
well?
So
we
need
to
figure
out
what
all
these
different
parts
are
and
then
come
up
with
a
solution
within
Almar
such
that
these,
these
that
these
things
can
actually
be
extended.
A
So
what
do
we
want
extensibility
to
achieve?
So
we
have
a.
We
have
a
number
of
goals
here
so
first
and
first
off,
and
perhaps
one
of
the
most
important
ones
is
really
to
isolate
features
the
specific
projects.
So
if
you
start
off
with
a
base
layer
of
compiler
technology,
that
provides
a
very
common,
very
you
know
very
low-level
kind
of
support
for
variety
of
different
features:
different
projects
like
Ruby
or
Java,
or
different
architectures
like
arm
or
SH,
for
something
like
that
they
can
come
along
and
specialize.
A
Those
like
those
base
features
the
way
that
they
want
them
to,
and
they
can
actually
extend
them
as
well,
and
when
these
projects
you
know,
come
along,
you
know
you
don't
want
the
requirements
of
a
particular
architecture
or
requirements
of
a
particular
project
like
movie
or
Lua,
to
actually
start
injecting
some
of
those
requirements
into
the
base
layer.
You
want
to
keep
that
as
nice
as
pausing
it
nice
and
clean
as
possible
and
relying
we
did
not
pick
as
possible,
because
that
is
really
one
of
the
design
goals
behind
a
clip
so
amar.
A
So
we
want
to
be
able
to
isolate
features
to
different
from
different
projects.
We
want
to
minimize
the
impact
to
compilation
metrics
things
like
startup,
compile,
time
and
footprint.
So,
if
we're
starting
to
create
extensible,
extensible
compiler
technology,
there
are
a
number
of
ways
you
can
do
this
and-
and
we
don't
want
to
introduce
an
extensibility
mechanism-
that's
going
to
impact
one
of
those
metrics
in
a
very
negative
way.
A
Up
until
this
point
you
know
we
have,
as
we
were
developing
this
technology
for
the
past,
you
know
15
or
I,
guess
18
years
or
whatever
it
happened
to
be.
We
spent
a
lot
of
time
making
sure
that
all
those
metrics
were
very
carefully
adhere
to
and-
and
you
perform
well
and
all
those
in
all
those
cases.
So
we
don't
want
to
introduce
something.
That's
going
to
blow
all
that
out
of
the
water.
A
We
also
want
to
minimize
and
sort
of
future
merge
and
integration
costs
of
projects
that
may
be
consuming
this.
It
wouldn't
be
a
great
strategy
if
we
came
up
with
an
extensibility
mechanism
that
wasn't
easy
to
consume
by
a
by
another
project.
If
every
time
you
wanted
to
pull
in
a
new
Eclipse
Omar,
for
example,
we
put
a
bunch
of
new
features
there,
somebody
wants
to
consume
it.
A
We
also
want
to
be
able
to
allow
future
extensibility.
You
know
beyond
what
we
can
currently
think
of
and
order,
or
even
for
projects
that
don't
even
exist
yet,
so
we
want
to
make
sure
that
the
whatever
solution
we
came
up
with
was
flexible
enough
to
do
that,
and
the
last
thing
here
is
that
the
solution
must
be
compatible
with
the
existing
code
base
and
it's
supported
by
multiple
build
compilers.
So
we
had
a
new
as
we
were
going
through
this
exercise.
You
know
we.
A
We
decided
that
you
know
we
were
going
to
stay
with
C++
implementation,
languages,
a
language
and
all
the
any
solution
we
came
up
but
really
had
to
work
within
the
constraints
of
C++
and
the
level
of
C++
that
was
available
on
build
compilers
that
were
available
on
all
the
platforms
that
we
support.
So
this
includes
things
like,
like
all
the
processor
architectures,
but
also
things
like
the
LS
and
and
AIX
and
windows.
Almost
you
know
we
had
to
sort
of
take
the
lowest
common
denominator
about
all
those
and
make
sure
solution
works
works
there.
A
A
So
when
we
started
thinking
about
solutions
to
this,
it
was
really
there
were
very
heavily
influenced
by
the
state
of
the
world.
At
that
time,
which
is
2013
and
like
I
said
before
we
were
a
project
that
had
I
think
at
least
six
or
seven
different
projects
that
were
sort
of
extending
from
its
new
Java.
A
There
were
static
languages,
there
were
binary,
emulators
or
abandoned
binary
translators,
lots
of
different
stuff,
all
totaling
about
one
and
a
half
million
lines
of
code,
and
perhaps
one
of
the
key
things
that
really
influenced
a
lot
of
our
early
design
was
the
fact
that
a
lot
of
this
technology,
a
lot
of
these
components,
were
very
strongly
connected
and
they
beam
in
it
would
have
been
I
clean.
Ideally,
they
shouldn't
have
been,
but
I
think
the
way
they
all
I
kind
of
evolved
over
time
they
sort
of
started
to
develop
dependencies
on
each
other.
A
The
other
thing
about
going
forward
here
was
that
our
expectation
was
that
any
work
that
we
did
here
was
all
of
all
the
projects
that
were
going
to
be
consuming
this
this
kind
of
technology.
Well,
they
were
going
to
be
able
to
extend
it
as
they
wanted,
so
so
Java,
for
example,
we
knew
that
was
going
to
be
open
source.
We
open
source
that
last
year
there
was.
A
There
were
some
technology
that
we
knew
we're,
never
going
to
be
open,
sourced
or
they're
not
going
to
be
open
source
in
the
short
term
for
sure,
so
things
like
COBOL,
for
example,
and
yet
we
still
wanted
to
be
able
to
share
all
the
stuff
that
we
were
doing
with
across
all
these
projects.
So
we
needed
a
solution
that
was
going
to
work
with.
You
know,
closed
source,
stuff
and
open
source
stuff
and
have
it
all
have
it
all
fit
together.
So
that
was
sort
of
our
mindset
and
our
starting
point
here.
A
So
what
do
we
finally
come
up
with?
So
this
wasn't
the
first
solution.
I
think
this
is
about
the
fourth
solution
that
we
that
we
eventually
came
up
with.
It
was
a
very
iterative
process.
We
went
through
a
lot
of
sort
of
trial
and
error
and
what
worked?
What
didn't
work
and,
and
that
and
and
I
was
mentioning
C++
before
and
I'll
say
that
it
was
really.
It
really
influenced
a
lot
of
our
thinking
here,
like
the
limitations
of
sequels
plots
on
the
capabilities
with
sequel,
Plus
really
influenced
a
lot
of
lives.
A
It
will
only
find
one
implementation
that
you
care
about
when
you're
doing
your
bill
that
I'll
get
into
all
that
a
little
bit
later
and
the
the
mechanism
it
uses
a
copy.
You
can
extend
a
couple
of
different
things,
so
you
can
extend
class
definitions
or
you
can
actually
provide
inner
parts
of
data
structures
to
extend
so
classes
are
a
little
bit
easier
to
extend,
just
by
the
way
that
you
can
actually
just
continue.
Subclass
them,
but
things
like
enumerations
are
a
little
bit
more
difficult
to
do.
A
But
what
we've
done
is
we've
sort
of
taken
out
the
inner
parts
of
the
actual
data
parts
of
those
data
structures
and
allow
you
to
compose
those
across
multiple
projects
and
we'll
see
an
example
of
that
a
little
bit
later,
just
some
terminology,
a
compiler
product,
is
built
using
a
hierarchy
of
project,
a
target,
a
particular
architecture.
So
when
we're
talking
about
projects
here,
we're
talking
about
like
Omar,
for
example,
is
a
project
open.
A
J9
is
a
project
that
movie
or
Lua
would
be
a
project,
and
a
product
is
really
something
that
is
built
from
a
hierarchy
of
those
of
those
projects,
and
any
of
these
projects
can
actually
provide
processor
specialization
as
right.
So
you
can
actually
have
x86,
specialization
or
arm
specialization,
pretty
much
any
class
that
you
that's
in
this
hierarchy.
A
The
way
that
the
extension
mechanism
works
is
that
projects
do
extend
other
projects
and
within
a
single
project.
Like
I
just
said
you
can,
you
can
do
extension
and
specialization
by
architecture.
The
one
kind
of
rule
we
have
through
all
this
is
that
OMR
must
always
be
the
primordial
project.
It
must
always
be
the
base
of
the
hierarchy.
You
can't,
for
example,
you
know,
put
something
before
it
and
that
will
mark
derive
from
it
a
lot
of
things
you're
going
to
sort
of
fall
apart.
A
So,
a
little
bit
more
on
that,
so
the
include
path
enforces
a
search
order
over
the
products
to
make
sure
that
only
the
most
specialized
extensions
are
discovered
first.
So,
like
I
said
in
on
the
previous
slide,
you
can
have
multiple
implementations
of
something
in
your
project,
but
depending
upon
how
you
want
to
build
it.
At
this
moment,
the
iPad
will
find
the
right
extension
that
you
are
interested
in
and
each
product
is
actually
responsible
for
setting
the
I
path
makes
sense
for
that
particular
build.
A
You
don't
care
about
stuff,
that's
been
implemented
for
more,
you
don't
care
about
stuff,
that's
in
ruin
for
using
for
the
Z,
processor
or
arm,
doesn't
matter
it's
it's!
The
iPad
that
makes
sense
for
that
particular
project
and
the
way
that
the
whole
thing
kind
of
fits
together
is
by
making
sure
that
we
use
the
these
include
directives.
You
have
to
use
a
path.
You
can't
just
have
the
file
by
itself.
You
have
to
actually
have
to
have
a
stem
path,
and
you
can't-
or
you
shouldn't
be,
including
a
project
like
in
this
particular
example.
A
Here
in
the
code
Boland,
it
talks
about
trj
9.
That's
really
not
something!
That's
recommended,
except
and
very
in
very
select
circumstances
when
that
truly
is
required
to
specify
a
project.
If
you
want,
for
example,
to
include
the
code
generator,
you
should
just
include
Kogan
code
generator
on
HTTP
and
depending
on
what
what
the
eye
path
is
for
this
particular
product.
It
will
find
the
right
code
generator
that
that
should
be
included.
A
You
may
have
to
provide
a
specialized
I
have
for
a
very
specific
project
that
you're
working
on
like
if
I'm
editing
code
for
x86-
oh
you
know,
and
for
x86
and
and
Java
I
need
to
set
up
the
eye
path
correctly
in
my
IDE
to
be
able
to
find
all
the
parts
that
I
want.
Otherwise,
if
I
do
a
search
for
a
code
generator,
for
example,
I
might
be
finding
stuff
in
the
zeeco
again,
that's
not
interesting
to
me
at
all.
A
So
in
this
particular
example,
you
can
see
that
we're
starting
in
the
j9
project,
the
X
directory
there
and
okay.
You
guys
see
my
arrow
here.
The
X
directory
here
refers
to
the
fact
that
this
is
an
x86,
architectures,
specific
directory
and
a
be
64
the
further
specialization
of
that.
We
call
that
a
sub
architecture.
A
So
if
something
isn't
found
there,
the
next
directorial
search
is
the
is
the
next
least
specialized,
which
is
just
here
very
9x,
the
dist
x86,
and
if
I
can't
find
anything
there
to
look
in,
you
know
way
to
look
in
just
somewhere
in
the
j9
project.
If
you
can
find
stuff,
so
it'll
basically
walk
its
way
out
of
this
project.
They'll
then
do
the
same
kind
of
thing
in
the
Omar
project
as
well
and
eventually
you
know
it
should
find
something
in
and
then
the
worst
case.
A
A
If
you
look
at
the
the
top-level
namespace
is
omar
and
that's
reserved
for
omar
technology
and
then
when
you
look
within
a
particular
project,
so,
first
of
all,
after
that,
you
can
basically
use
any
namespace.
You
want
for
the
for
the
for
the
technology
you
want.
So,
for
example,
open
j9
uses
j9
as
its
name.
Space
is
very
looked
at
ruby
code
uses,
surprise
movie,
but
pretty
much
any
other
name
is
is
is
available
now
within
the
particular
project.
A
A
There
is
one
special
global
namespace
that
we
use
in
this
technology
and
that's
TR.
:
:
and
it's
used
for
something
that
we
call
concrete
classes
and
what
these
are
and
we'll
talk
about
that
in
just
a
second.
But
when
you
are
actually
composing
an
extensible
class
you're
actually
composing
these
up
from
what
we
call
extension
classes
and
then,
at
the
very
end,
once
you've
gotten
to
a
point
where
you
have
specialized
it
all
as
much
as
you
want.
A
What
you
do
is
you
actually
have
to
produce
to
what
we
call
a
concrete
class
that
somebody
can
actually
come
along
and
accentuate.
So
that's
sort
of
a
public
interface
key
or
to
your
extensible
class
is
something
that's
in
the
TR
namespace
and
TR.
:
:
is
something
that
can
used
in
any
project
at
any
time
to
get
the
complete
extensible
class
that
you've
just
produced.
A
Okay,
so
I
just
said
extensible
classes,
so
I
guess
I
should
maybe
define
what
we're
starting
to
talk
about
here.
So
my
extensible
class
is
really
a
class
that
can
be
composed
of
specializations
from
different
projects,
and
it
can
be
multiple
projects
at
the
same
time
or
to
have
multiple
architecture
expect
specializations
as
well.
Now
it
should
always
be
a
particular
extensible
class
should
only
have
like
one
architecture
like
you're,
not
going
to
be
extending
something
for
x86
a
little
bit
later
on
in
this
hike
extending
it
for
power.
A
It
should
be
one
straight
uniform
in
forest
tension.
The
composition
is
achieved
through
single
inheritance,
and
it's
extending
these
things,
like
it
called
extension
classes
that
each
project
must
provide
and
if
you're
familiar
with
CR
TP.
The
curiously
recurring
template
pattern,
which
is
a
way
of
doing
static
polymorphism
in
C++,
you'll
notice
that
it's
a
very
similar
technique
to
that.
A
We
did
investigate
using
CR
TP
as
as
a
way
of
doing
this,
and
it
turned
out
to
actually
not
work
as
well
as
we
had
hoped,
and
the
reason
was
because
of
its
use
of
suppose,
both
templates.
So
the
way
that
CRT
B
works
is
that
you
sort
of
pass
up
the
most
derived
class
as
a
template,
parameter
to
all
the
other
classes
in
the
hierarchy,
and
the
problem
with
using
templates
is
that
it
requires.
In
many
cases
you
require
you're
going
to
start
using
templates.
A
It
requires
the
definition
and
the
declaration
and
the
template
implementations
all
that
all
being
visible
at
once
and
when
I
talked
earlier
about
the
fact
that
we
were
very
strongly
connected
components.
That
was
a
problem
early
on
because
in
what
they
required
us
to
basically
pull
in
the
entire
world,
just
to
be
able
to
extend
the
class
and
the
reason
you
had
to
pull
in
all
that
stuff
is
because
of
the
template
and
so
early
on.
This
wasn't
a
great
solution
for
us.
A
A
So
why
are
we
not
using
virtual
functions?
Why
are
we
going
with
static
polymorphism?
So
performance
is
really
one
of
the
one
of
the
key
reasons
of
this.
When
we
had
first
started
to
work
in
2013,
you
know
there
certainly
was
some
immaturity
with
some
the
compilers
in
in
doing
d
virtualization.
They
were
serious
performance
problems
on
some
on
some
platforms
as
well.
When
you
had
a
lot
of
virtual
functions-
and
you
know
you're
keeping
an
eye
on
on.
A
You
know
like
our
compile
time,
performance,
and/or,
startup
performance,
which
has
always
been
very
critical
for
for
this
technology.
The
lack
of
in
mining
opportunities
could
add
up
over
over
time
with
the
with
the
fact
that
we
we
couldn't
inline
code,
you
basically
always
had
to
do
call
a
virtual
function.
A
The
other
thing
is
that
the
points
of
extension
within
this
hierarchy
are
now
virtual
functions
like
that's.
That
is
how
you
extend
the
classes
that
was
or
the
virtual
function,
and
there
were
some
concern
around
the
performance
consequences
and
downstream
projects,
and
you
know
one
of
the
examples
that
we
used
a
lot
when
we
were
thinking
about
this
was,
if
you
take
a
very
common
function,
that
there
is
right
now
like
is
fixed
before
the
target.
It's
a
question.
A
You
ask
the
the
compilation
to
see
if
I'm,
compiling
for
a
64-bit
target
or
not,
if
suddenly,
that
in
that
correct
query
is
used
everywhere
and
right
now,
it's
not
virtual.
If
someone
were,
if
you
wanted
to
make
that
an
extension
points
and
in
the
future
and
we
came
along
and
I
really
need
the
doing
that
was
to
basically
make
it
a
virtual
function.
That's
going
to
potentially
add
a
fair
bit
of
overhead.
That's
going
to
impact
all
downstream
projects
because
it's
used,
so
you
so
often.
A
So
if
somebody
suddenly
adds
a
virtual,
you
know
virtual
keyword
to
something
then
that
could
potentially
you
know,
disrupt
a
lot
of
things.
So
we
need
to
be
careful
about
that
and
then
perhaps
the
other
reason
that
that
motivated
a
static
polymorphism
approach.
Is
that
and
you
look
at
what
we're
actually
trying
to
achieve
here
when
we're
actually
putting
a
compiler
together
for
a
particular
architecture
project.
There's
not
really
that
many
structures
that
are
dynamically
polymorphic.
A
We
don't
really
need
to
use
the
dynamical
dynamic
polymorphism
mechanism
right,
so
you
can
pretty
much
figure
out
at
compile-time
what
your
or
your
hierarchy
is
going
to
be
and
what
classes
are
going
to
be
extended,
so
it
you
can
potentially
unlock
a
lot
of
performance
that
way.
So
a
lot
of
these
things
sort
of
pointed
toward
a
static
polymorphism
approach.
So
that's
that's
what
we
decided
to
go
with
okay,
so
I'm
going
to
take
you
through
a
few
examples
now.
A
So
let's
say
that,
let's
start
on
the
base
layer
and
we
want
to
create
some
kind
of
an
extension,
some
kind
of
a
class,
it's
going
to
live
in
Omar
and
we
just
create
some
code
for
it.
What
you
can
do
is
come
along
and
provide
those
some
power
specializations
to
that
class.
You
can
also
provide
some
x86
specializations
to
that
class.
You
can
come
along
and
be
even
further
refinement
on
the
x86
specializations
for
386,
or
you
can
do
nothing
at
all.
A
You
can
basically
just
not
want
to
extended
at
all
so
once
you've
got
these
extension
classes.
What
you
then
do
is
you
have
to
create
a
concrete
class
that
will
represent
the
bat
that
kind
of
an
extension
and
the
way
that
that
concrete
class
works
or
that
it
sort
of
extends
it
can
extend
each
of
these
different
architecture,
extensions
that
we
have
that
we
have
created
so
so,
as
it
says
here,
an
extension
class
is
a
class
that
is
used
in
the
composition
of
an
extensible
class.
A
A
The
way
that
the
specialization
works
is
through
class,
inheritance
and
method
overrides.
So
not
virtual.
Just
this
pyramid
method
over
lives
and
the
thing
about
the
extension
classicism
is
that
they
should
never
actually
be
instantiated
themselves.
The
only
way
the
only
place
where
they
should
be
extension
instantiated
is
through
you
know,
sub
classing
subclassing
them.
You
should
never
have
to
come
along
and
create
an
Omar
look
at
this
class
II
called
my
extension
class.
You
should
never
actually
have
to
create
an
ohm
on
my
extension
class.
A
You
should
only
ever
be
instantiating
the
concrete
class,
which
is
what
this
is
trying
to
say.
So
what
the
concrete
class
is?
It's
really
an
external
interface
to
the
extensible
class.
So
it
is
the
thing
that
is
actually
instantiated
when
you
want
to
create
this
class
and
it
lives
in
the
TR
namespace
and
what
it
really
does.
Is
it
just
inherits
from
the
most
specialized
extension
class
in
that
project.
A
So,
in
this
particular
case,
depending
on
what
what
and
how
you're
building
it
could
be
extending
from
power,
it
could
be
extending
from
x86
or
386,
or
it
could
be,
extending
nothing.
It
could
just
be
going
straight
to
the
I.
Don't
need
nothing!
No
architectural
specializations
coming
directly
from
the
extension
class
itself.
A
So
the
question,
then,
is:
how
do
we
figure
out
what
class
needs
to
be
extended
like
how
does
the
concrete
class
figure
out
what
what
which
one
is
actually
extending?
Oh
okay,
before
I,
get
to
that
rias?
There's
a
there's
a
sister,
further
refining
here
when
you
actually
end
up
building
these
things,
you
win
a
pretty
singing
an
effective
class
hierarchy.
A
So,
if
I'm
building
this
project
on
power
for
the
for
a
Power
Architecture,
this
is
what
my
cause
higher
is
going
to
look
like,
given
the
weight
of
the
iPads
work
and
all
that
kind
of
thing.
This
is
what
the
higher
class
art
is
going
to
look
like
so
you're
going
to
have
a
base
layer,
the
power
extension
and
then
the
concrete
class
is
going
to
extend
from
that
you're
not
going
to
see
any
of
the
other
stuff
for
any
of
their
architecture.
It's
really
just
going
to
be
just
power
same
thing
for
x86.
A
A
A
Well,
we
define
something
called
a
connector
and
each
extension
class
has
to
basically
provide
a
type
def
of
itself
to
a
connect
to
a
connector
in
that
project
and
and
and
then
the
the
iPads
and
other
sort
of
pound
to
find
magic
come
into
play
to
ensure
that
only
one
connector
per
hierarchy
will
actually
be
discovered
in
any
particular
product
build
and
when
you
have
some
concrete
classes
or
if
you
have
another
project,
for
example
like
j9.
The
way
that
it
actually
will
extend
something
in
your
in
this
base
extension
class.
A
A
A
It's
got
a
common
name
that,
depending
upon
what
the
I
path
is,
is
only
going
to
be
seen
only
one
of
those
is
going
to
be
found
and
if
you're,
if
you
want
to
extend
this,
if
you
want
have
another
project
that
extends
this
like
open
j9,
for
example,
all
open
j9
will
do,
it
will
provide
its
own
extension
class.
But
then
that
thing
just
simply
extends
the
connector.
It
doesn't
care
and
it's
a
power
implementation
or
an
x86
specialization
or
whatever
all.
It
knows
that
it
needs
to
extend
the
connector.
A
So
this
is
an
example
of
the
instruction
hierarchy
so
starting
at
the
very
base
layer
in
the
Omar
project,
we're
looking
at
the
the
header
file
that
basically
describes
the
the
API
for
the
instruction
class.
It
lives
in
the
code
gen
directory
and
this
particular
file
name
is
Omar
instruction
HPP.
So
that's
particularly
important
because
all
extension
classes
in
a
for
a
for
a
given
class,
all
the
extension
classes
in
the
same
project
should
have
the
same
should
have
the
same
name.
A
So
anything
that's
going
to
be
extending
all
of
our
instruction
that
each
piece
should
have
the
same
name
or
more
instruction
that
HBP
and
they're
never
going
to
live
in
the
same
directory,
they're
going
to
live
in
different
directories
because
we
had
an
x86
specialization
or
the
specialization
as
we'll
see
in
a
couple
of
slides.
It'll
live
in
a
different
directory
altogether
yeah.
A
So
basically,
if
the
connector
hasn't
been
defined
before,
if
we
haven't
seen
one
before,
we
need
to
actually
create
a
type
def
to
the
connector,
and
what
it's
really
doing
is
that
in
the
for
the
instruction
class
in
the
Omar
project,
what
it's
really
doing
is
saying
kid
is
only
going
to
be
one
instruction,
connector
name,
anything
that
wants
to
extend
the
OL.
Our
instruction
will
always
does
look
for
the
instruction
connector,
like
it's
going
to
look
for
that
one
name.
A
It's
not
going
to
look
for
it,
I,
don't
care
that
it's
a
mix
of
e6
I,
don't
care!
If
it's
and
power
doesn't
matter
I'm
just
going
to
look
for
that
one
name.
So
the
connector
is
an
instruction
type
deafening
and
you
homer
namespace.
Okay,
when
you
define
the
class
itself,
they
pack
to
the
class,
as
you
can
see,
it
lives
in
the
Omar
namespace,
and
we've
also
defined
this
sort
of
special
attribute
that
it's
a
macro,
but
it
actually
move,
will
map
to
an
attribute
for
the
most
build
compilers.
A
That
really
describe
the
fact
that
this
is
an
extensible
class
and
the
only
reason
that
this
that
this
exists
is
that
we
have
some
tooling
as
part
of
our
build.
That
will
check
that
these
class
hierarchies
are
formed
properly
and
that
things
and
that
certain
rules
of
exploring
these
classes
are
being
followed.
It's
actually
fairly
useful
to
detect
certain
kinds
of
errors
will
see
those
in
them
in
a
little
bit,
but
it's
useful
for
finding
those
kinds
of
errors,
but
you
should
use
it.
A
A
Okay,
so
this
is
the
source
file
and
you
can
pretty
much
call
the
source
files
whatever
you
want
when
it
comes
time
to
actually
consuming
extensible
classes.
You
basically
pick
and
choose
the
file
name
that
you
want
to
put
the
the
in
the
make
file
list
right,
so
you
can
call
them
whatever
you
want
as
long
as
they
live
in
separate
directory.
So
but
it
is
useful
to
keep
the
names
consistent,
I
find
here,
you
don't
actually
include
so
this
thing
wants
to
include
a
view
of
our
instruction
class
I
mean
is
created.
A
So
we're
still
in
the
Omar
project
and
let's
say
now
that
we
actually
wanted
one
to
provide
and
an
architecture
specialization.
So
in
this
case
we
wanted
to
provide
the
architecture
specialization.
So
that's
fine.
So
the
first
thing
that
we
need
to
do
just
like
the
other
file
is
to
actually
create
a
connector
and
notice
how
the
name
of
the
connector
is
still
the
same.
It's
in
the
Omar
namespace
it
it's
called
instruction
connector.
So
it's
the
name
is
still
exactly
the
same
as
it
was
in
the
debate.
A
A
Right
so
I
just
said
that
about
the
old
ones:
that's
the
same
name
for
the
instruction
connector.
So
given
the
way
that
the,
if
your
I
path
is
set
up
correctly
like
you
saw
before
it
should
be
from
those
from
the
most
specialized
to
the
least
specialized.
If
it's
set
up
correctly
when
you're,
if
I'm
building
on
Z
the
you
should
find
the
Z
instruction
class
specialization
before
the
vista
video
lamar
base
class,
so
you
should
find
this
or
more
instruction
of
each
PP
before
the
one
that
lives
in
just
Cogan.
A
Oh
my
instruction
at
HTTP
and
it's
easy
to
check
to
see
if
your
your
eye
path
is
incorrect,
because
if
we
had
already
seen
that
the
instruction
connector
was
defined,
that
means
that
we
had
already
processed
the
base
class
or
something
else.
And
if
that's
the
case,
something
is
very
out
of
whack
here
and
we
can.
You
should
be
able
to
die
at
compile
time
here
and
we
do
so
that's
what
this
particular
error
me.
If
you
happen
to
see
that.
A
So
because
this
is
a
z/architecture
extension
and
it's
going
to
be
extending
the
base
for
more
instruction,
it
needs
to
basically
reach
back
and
include
that
base
class.
So
here's
one
here's
an
example
of
where
you
should
use
a
project
specific
path,
so
in
this
particular
case
this
this
the
way
that
this
stem
path
is
written
here
is
it's
going
to
find
the
parent
of
this
particular
class.
A
And
then,
when
you
are
extending
it,
we
also
see
that
this
is
now
in
the
om
RNA
space.
It's
got
three
method
namespace
as
well.
You
still
say
that
it's
extensible
instruction
and
what
it's
deriving
from
is
omar
instruction.
So
this
is
its
immediate
parent.
So
the
architecture
instruction,
the
instruction
specialization,
is
going
to
be
extending
the
goal
of
our
instruction.
It's
not
extending
the
connector,
it's
because
we're
within
a
project.
So
it's
extending
the
instruction
of
child.
A
A
So
it
needs
to
include
the
Omar
instruction
of
HPP,
and
this
is
now
why
it's
important
for
all
those
files
to
have
the
same
name
because
I'm
a
different
project
here,
I'm
in
j9
I,
don't
know
I,
don't
care.
Well,
you
know
what
well
I,
don't
necessarily
care.
What,
with
all
our
instruction
I'm
actually
extended.
All
I
know
is
that
here
is
some
j9
specialization
for
whatever's
been
provided
in
in
Omar.
So
this
all
my
instruction
activity
could
be
coming
from
lead.
It
could
be
coming
from
the
base
it
could
be
coming
from.
A
A
Right
and
so
here
we're
defining
in
the
j9
namespace
its
instruction
class.
Again,
you
have
to
say
a
little
more
extensible
now
the
thing
that
it's
actually
extending
is
Omar
instruction
connector,
because
you
don't
really
know
when
you're
writing
the
source
code.
Here
you
don't
really
know
what
it
is,
is
you're
extending
B
or
X
or
whatever.
So
all
you
do
is
now
you
use
that
that
connector
name
and
that's
what
makes
it
all
sort
of
fit
together.
A
So
this
now
is
an
example
of
a
concrete
files
or
concrete
class
definition,
so
the
name
of
the
file
is
now
instruction
HPP,
and
you
remember
from
the
CPP
file
that
this
is
the
name
that
we
actually
used
when
we're,
including
in
the
in
the
CPP
file.
So
so
what
so?
The
way
that
this
actually
works
is
that,
because
this
particular
implementation
lives
in
t
rj
9,
he
has
to
include
the
j
9
instruction
HPP.
A
There
would
also
be
a
similar
one
in
oil
in
the
oil
Marko
gen
instruction
or
GBP,
but
it
would
include
cogent,
OMR
instruction
HPP,
so,
whichever
wherever
you,
whichever
level
of
the
hierarchy,
you
have
your
instruction
HP.
You
have
to
include
that
drain
on.
You
have
to
include
that
project
instruction
that
HBP
and,
of
course
the
iPass
will
figure
this
up
for
you.
A
This
is
where
we
put
that
we
put
this
in
the
chair,
our
namespace,
and
what
it's
really
going
to
be
defining
here
is
a
TR
in
the
chair,
namespace,
it's
creating
an
instruction
so
anytime.
You
want
to
create
one
of
these
things
and
create
an
instruction
you're,
actually
creating
a
TR
colon
colon
instruction.
That's
going
to
find
ok,
so
I
guess
I
can
pause
there
for
a
sec
to
see.
If
there's
any
questions,
I
know
it
might
take
a
little
bit
to
solve
a
lot
of
this
but
pause.
A
A
Ok,
if
not
we'll
go
on
to
the
next
kind
of
feature
of
this
of
this,
so
that's
how
the
hierarchies
are
kind
of
put
together.
One
thing
that
is
necessary-
and
this
is
a
particularly
point
for
anything
that
uses
a
static
polymorphism-
is
that
in
order
to
make
sure
so
the
way
that
this
hierarchy
kind
of
looks
it's
sort
of
it's
sort
of
upside
down
from
a
dynamic
polymorphic
hierarchy,
because
in
the
dynamic
polymorphic
hierarchy
you
kind
of
have
a
pointer
to
the
base
in
the
hierarchy.
A
In
this
particular
case,
you
actually
have
a
pointer
sort
of
look
to
the
most
specialized,
does
the
most
specialized
class.
So
in
order
to
make
sure
that
you're
going
to
be
when
you
want,
if
you
want
to
make
sure
that
you're
calling
the
correct
function
somewhere
in
this
hierarchy,
you
want
to
make
sure
that
you're
calling
the
most
specialized-
and
you
don't
have
the
virtual
keyword
anymore-
to
help
you.
It
doesn't
sort
of
resolve
this
at
runtime.
A
So
you
have
to
make
sure
that
you
downcast
any
sort
of
any
time
you
want
to
use
something
something
from
the
mist
pointer.
You
basically
have
to
make
sure
that
you
downcast
that
to
the
most
derived
class
and
let
the
compiler
figure
out
what
the
what
the
implementation
is
to
call.
So
this
is
a
I
guess
like
a
common
technique
in
in
instead
of
static
polymorphism.
So
what
this
is
saying
here
is
that
calling
the
most
specialized
member
function
in
an
extensible
hierarchy
requires
a
static
cast
and
receiver
to
the
concrete
class,
so
yeah.
A
So
basically
just
using
the
static
cast,
keyword
and
C++
you
cast
it
to
the
most
arrived
TR
Cohen
Cohen
class
without
a
down
cast,
the
implicit
receiver
is
the
list
in
the
dispatching
class.
So
if
you
don't
do
this,
then
the
the
problem
that
will
happen
is
that
if
you
just
call
a
a
function,
that's
been
extended
at
a
foo
in
some
class
in
that
hierarchy.
It's
going
to
find
the
food
in
that
particular
hierarchy.
It's
not
going
to
find
any
sort
of
specializations
that
you
may
have
done
on
that.
A
So
in
some
cases,
you're
going
to
get
the
wrong
function
being
called,
and
we
have
had
some
fairly
subtle
bugs
found
phone.
Because
of
this,
in
fact,
I
think
even
found
one
recently
with
with,
because
the
wrong
ones
being
called
enough
to
recent,
maybe
a
while,
though,
but
so
each
extension
class
has
to
work.
So
the
way
that
we've
make
this
a
little
bit
easier
to
get
around
is
that
each
extension
class
should
provide
a
self
method
that
performs
explicit
downcast.
So
you
use
self
whenever
you
want
to.
A
If
you
thought
about
using
this
in
the
past,
you
want
to
use
self.
Instead,
it's
really
more
of
a
convenience
than
the
explicitly
writing
out
that
static
casting
text,
because
it's
very
long
and
awkward
in
some
cases
to
write
out
the
full
static
cast
of
your
concrete
class.
But
the
onus
is
on
the
developer.
To
actually
do
this,
there
isn't
really
any
sort
of
C++
requirement
that
you
have
to
actually
have
to
do
this.
It
may
just
work
just
it
may
appear
to
work
just
fine,
but
you
may
get
the
bad
things
happening
on
you.
A
And
I'll
talk
a
little
bit
more
about
that
in
a
couple
of
slides,
because
we
have
some
tooling
that
helps
with
them
with
some
of
this
okay.
So
how
do
you
actually
use
extensible
classes?
Well,
the
way
you
simply
have
to
instantiate
the
concrete
class
right,
so
in
that
construction
hierarchy,
you
wouldn't
accentuate
a
TR
:
:
instruction
to
actually
create
an
instruction.
You
don't
never
instantiate
any
of
the
extension
classes
at
all.
A
The
source
file
should
include
the
concrete
class
header
file
without
any
sort
of
project
or
architecture
specializations.
So
in
this
particular
case,
the
code
generator
you're
just
going
to
including
toe
gen
code
generator
XP
key.
We're
not
saying
give
me
the
X
code,
gen
code,
generator,
HPP
and
you're,
trying
to
let
the
the
generalities
work
as
they're
supposed
to
and
what
the
ipad's
resolved.
Everything
for
you
do
not
use
concrete
class
header
files
and
other
header
files.
A
So
this
is
a
this
statement
really
kind
of
goes
back
to
the
problems
that
we
were
having
very
early
on
with
this,
when
you're
trying
to
open
source
of
technology
where
everything
was
very
was
very
connected
to
each
other.
So
you
would
have,
for
example,
the
cogenitor
class
and
include
the
instruction
hierarchy,
which
include
compilation,
which
would
include
the
erection
dependencies
and
everything
would
end
up.
A
They
pulled
together
into
one
big,
you
know
large
bolus
of
code,
and
it
was
very
difficult
for
the
include
mechanism
that
we
come
up
with
actually
work,
because
the
ordering
was
very
important
and
you
had
to
sort
of
resolve
these
dependencies.
So
the
the
general
advice
here
and
and
strongly
recommended
that
you
don't
actually
include
concrete
class
header
files
in
other
header
files
most
the
time
you
can
just
get
away
with
using
forward
declarations
and
the
other
thing
it's
actually
member
functions
yet
calling
member
functions.
A
A
A
If
you
do
decide
to
make
an
extensible
class
hierarchy,
that
doesn't
mean
that
you
can't
use
virtual
functions.
There
are
good
uses
of
virtual,
like
you
can
mix
the
two
static
polymorphism
and
dynamic
polymorphism.
So,
for
example,
we
have
I,
guess
have
the
negative
over
here.
Really,
if
you
look
at
in
some
cases
the
the
base,
you
can
provide
us
sort
of
a
common
base
class
which
is
defined
by
static
polymorphism,
but
then
you
can
create
a
dynamically
polymorphic
hierarchy
from
that.
So
be
sure.
A
If
you
look
at
the
instruction
hierarchies
themselves,
they
are
actually
all
dynamic,
polymorphic
hierarchies,
but
they
are
built
from
a
base
class
that
has
been
defined,
static,
cleaning,
so
processor
instruction
hierarchies
and
the
optimizer
itself.
They
it
still
uses
done
a
calling
a
polymorphism.
A
Okay,
so
I
talked
about
classes
to
quickly
want
to
show
you
how
we
use
this
kind
of
same
technique
to
extend
other
data
structures
as
well.
Because
if
you
look
through
the
code,
you
can
see
the
use
of
static
tables
you're,
going
to
see
the
use
of
enumerators
you're,
going
to
see
unions
in
some
cases
as
well,
and
there
are
ways
of
actually
applying
this
kind
of
trick
with
the
iPad
to
those
structures
as
well.
So
here's
an
example
of
how
the
opcode
the
ILO
opcodes
names
are
actually
defined.
A
So
this
is
actually
an
enum
and
if
you
look
at
how
it's
actually
defined
in
the
TR
name,
space,
there's
a
that's
where
the
aisle
opcodes
IAM
lives.
But
the
data
part
of
the
aisle
opcodes
is
actually
just
a
pound
include,
and
it
includes
something
called
IL
opcode
zina
HPP
and
the
way
that
this
works
is
that,
given
how
the
AI
path
is
set
up,
it'll
find
the
most
specialized
implementation
of
Iowa
code
mmnh
PP,
which
in
this
case
it's
found
one
in
TR
j9
and
the.
What?
A
What
would
what
you
would
find
in
that
file
is
something
that
looks
like
this
and
what
it
would
do
is
actually
include
the
the
j9
specialization
of
that
pileup
code
ena.
So
that
would
look
like
this,
and
the
first
thing
that
it
does
is
it
reaches
back
and
includes
the
o
of
our
implementation
of
it
as
well,
and
then
that
does
something
like
that
and
then
eventually
what
what
ends
up
getting
produced
is
composition
of
all
these,
which
looks
like
that.
A
So
using
that
same
kind
of
trick
of
with
I
path
magic,
you
can
basically
compose
and
extent
enums
as
you
abide
by
project.
So
it
turns
out
to
be
a
fairly
useful
way
of
doing
that
and
you
can
do
the
same
kind
of
trick
with
static
tables
as
well.
Unions
are
a
lot
more
problematic
and
I.
Don't
think
we
actually
have
a
great
solution
for
that
I'll
get
to
that
in
a
sec,
but
anyways.
This
is
how
you
put
together
in
ohms,
if
necessary
and
you're,
going
to
see
this
in
the
code
as
well.
A
You
look
can
do
it,
so
we
could
have
some
truly
to
make
some
of
this
easier.
One
thing
that
actually
we
have
is
a
linter.
It
actually
checks
that
the
expensable
classes,
if
providing
you
uses
the
ohm,
are
extensible
attribute.
It
can
check
a
variety
of
things
to
make
sure
that
the
classes
are
put
together
properly.
A
So,
for
example,
it
can
actually
tell
you,
when
you're
missing
at
this
point,
if
you're
using
this
implicitly
and
you're
missing
a
self
call,
it'll
actually
flag
that
and
it
will
fail
to
build.
We
do
run
this
kind
of
a
checker
on
every
build
in
a
clique,
so
Omar
there
is
a
linter
job
that
runs
at
a
little
bit.
We'll
do
this
over
the
code,
so
it'll
reject
anything
that
fails
like
this
there's
also
truly
to
help
rewrite
classes.
A
So
if
you
came
across-
and
this
isn't
necessarily
as
a
useful
as
it
was
in
the
past-
but
if
you
come
across
a
class
hierarchy
that
isn't
currently
extensible
but
you'd
like
it
to
be,
there
are
some
tools
available,
they're
all
based
on
clang.
That's
actually
them
are
checkers,
based
on
it
sort
of
playing
a
crying
tool
to
actually
rewrite
to
help.
A
You
rewrite
the
class
using
the
right
kind
of
needs
for
extensible
classes,
so
it
will
help
you
insert
the
self
calls
whenever
inputs
of
this
is
shown
that
sort
of
thing,
and
we
use
that
on
the
list-
maybe
that's
an
example.
We
use
that
on
the
node
class,
when
we,
when
we
did
that
work
so
there's
actually
a
research
group
in
at
the
University
of
Alberta.
That's
been
doing.
Some
work
on
projects
like
this
and
they've
actually
been
helping
us
to
develop
some
tooling
to
aid
with
further
ways
of
validating
extensible
classes
and
figuring
out.
A
When
you
know
what
parts
of
the
class
are
extensible,
you
know,
maybe
where
there
are
parts
of
the
hierarchy
that
we
have
missed,
extending
like
we,
we
should
have
extended,
but
we
didn't
that
sort
of
thing.
So
they've
been
very
helpful
in
in
developing
some
of
this
tooling,
so
maybe
someday.
We
can
actually
start
using
this
in
our
in
our
validation
parts
of
the
bill.
A
So
there
are
situations
where,
if
you
want
to
actually
provide
custom
parameters
to
your
constructor,
it's
going
to
be
difficult
to
do.
We've
actually
prototyped
I,
don't
know
if
that
code
never
actually
got
committed.
Just
just
I
mean
a
whole
piece
of
code
of
a
way
of
actually
putting
like
a
chain
of
these
constructors
together.
That
allows
you
to
do
architecture
specialization.
It
has
to
do
with
by
our
passing
up
like
another
class
altogether,
and
that
class
contains
all
the
different
things
that
you
might
want
to
specialize.
A
Maybe
I
could
dust
that
coat
off
if
anybody's
interested
in
seeing
that
I
can
dust
that
coat
off,
find
it
dust
it
off
and
get
it
out
there.
It
hasn't
really
been
this
too
much
the
fact
that
you
want
to
provide
your
own
constructor,
but
it
might
in
the
future.
We
may
need
to
actually
have
a
better
solution
here.
A
The
other
thing
is:
how
do
you
actually
go
about
identifying
extension
cords
so
right
now,
anything
in
these
classes
is
an
extension
point
and
that
could
potentially
be
problematic.
So
what
if
we
only
wanted
to,
you
know
provide
a
lot
of
Robotics
class.
It
only
has
two
extension
points.
Doesn't
that's
the
only
thing
I
want
to
be
user
to
be
able
to
specialize.
That's
not
really
possible
right
now,
so
we
need
to
potentially
think
of
ways
of
doing
that
in
the
future,
but
not
quite
sure
we
all
agree
answered
there.
A
Yet
if
you
start
using
self
a
lot,
you
can
see
it
all
over
the
code
and
it
actually
can
make
the
code
look
kind
of
ugly.
Like
I
said,
if
you
look
at
the
middle
class,
you
see
you'll
see
it
a
lot
if
it
can
make
the
code
ugly
to
look
at,
and
it's
probably
one
of
the
bigger
pain
points
that
people
have
with
this.
With
this
technique,
we.
A
Oh
so,
the
other
thing
is
in
line
function,
implementation,
extension,
class,
header
files,
so
it's
difficult
to
provide
an
inline
implementation
in
some
of
these
cloths
header
files,
for
the
reasons
that
I
said
earlier
and
that
you
actually
have
to
include
the
concrete
class
which
starts
to
pull
in
a
lot
more
stuff,
and
you
can
start
to
get
circular
dependencies
between
some
of
these
class
hierarchies
and
that's
not
going
to
they're
not
easy
to
resolve,
so
we
need.
We
need
better
solutions
to
that,
and
also
how
do
how
do
you
apply
this
technique
to
unions?
A
We
started
experimenting
with
it
to
see
if
we
can
come
up
with
some
solutions,
we
didn't
get
too
far
with
it.
Where
are
you
going
to
see?
A
lot
of
us
is
like
in
in
the
middle
class,
the
the
very
base
of
the
node
class.
You've
got
a
lot
of
unions
to
save
space
and
it's
difficult
to
to
tear
those
apart
and
make
them
extensible.
So
we're
still
thinking
about
that.
But
any
ideas
are
welcome
and
then
just
how
we
can
things
we
can
do
this
going
forward.
A
We
were
thinking
about
backing
off
our
initial
position
about
not
so
in
practice,
there's
actually
not
that
many
functions
that
actually
get
extended
or
specialized
in
any
sort
of
given
class
hierarchy.
So
what
we
thought
about
doing
was
actually
using
the
framework
of
composing
these
classes,
but
the
actual
extension
parts
just
using
virtual
functions,
and
we
don't
think
that
you
would
actually
get
a
lot
of
performance
impact
from
that.
But
we
wanted
to
measure
that.
A
But
the
idea
here
as
well,
so
we
get
rid
of
all
those
self
calls,
because
if
they
are
virtual
calls
the
you
never
gets
resolved,
naturally
at
compile
time
or
at
runtime.
So
the
the
code
would
look
a
lot
better.
So
there
are
some
potential
performance
issues,
but
we
wanted
to
measure
those
so
I
think
there's
actually
an
issue
opened
from
that
or
you
can
dig
that
out.
A
Add
more
typical
annotations
and
extensible
classes
yeah.
We
could
potentially
annotate
what
the
extensional
parts
of
the
class
are
so
so,
instead
of,
for
example,
using
virtual
as
the
previous
bullet
set,
we
could
actually
annotate
them
to
say
this
is
the
extension
point
and
we
can
actually
provide
tooling
to
help
validate
that
and
now
that
we
are
actually
much
further
along
than
we
were
like
four
years
ago
in
terms
of
deep,
be
coupling
a
lot
of
the
probably
see
RTP
solution
might
actually
work
a
little
bit
better
now
than
it
did
back
then.
A
So
there
is
the
potential
of
of
investigating
backs
in
the
future,
but
it's
not
really
very
high
in
the
priority
list
right
now,
just
because
of
the
disruption
it's
going
to
cause,
because
it's
going
to
be
a
fairly
big
refactoring
to
do
that.
But
I
do
know
similar
action
works,
oh
okay,
so
that's
a
woven
tour
of
extensible
classes,
I
think
that
I
mean
to
be
completely
honest.
A
A
And
if
there
are
getting
I
guess
we
could
become
adjourn.
I
think
the
next
I
think
the
next
call
that
I'd
like
to
do
will
start
to
touch
on
the
means,
the
semantics
buying
some
of
the
classes
in
the
code
generator,
so
the
things
that
we
actually
have
to
start
fleshing
out.
So,
for
example,
the
machine
classes
like
register
dependency
registers
instruction
hierarchies.
That
kind
of
stuff
start
talking
through
some
of
those.
Once
we
have
an
understanding
of
that,
then.