►
From YouTube: OMR Architecture Meeting 20230720
Description
*JitBuilder 2.0 Update [ @mstoodle ]
A
Okay,
welcome
everyone
to
the
July
20th
Omar
architecture
meeting.
Today
we
have
one
topic
on
the
agenda,
so
Mark
studly
will
be
taking
us
through
some
of
the
advances
that
he's
been
making
on
jit
Builder
2.,
so
I'll
turn
it
over
to
mark.
B
Thanks
bro,
so
this
is
the
longest
running
use
of
a
version
number
because
it's
never
actually
been
released
as
2.0
at
this
point,
but
I
have
been
making
some
progress
on
a
bunch
of
different
things
and
I
wanted
to
give
an
update
to
everybody
on
where
things
stand,
because
the
way
you
use
jetbuilder
2
has
changed
a
little
bit
from
in
in
the
quest
to
make
it
better
and
easier
to
use.
B
So
I've
got
part
one
here,
because
I
think
I
probably
have
enough
content
that
have
a
an
introductory
discussion
about
how
things
are
going
to
are
now
working
with
jit,
Builder,
2.
and
I
reserved
a
couple
of
in-depth
topics
to
do
a
follow-on
I
can
might
be
able
to
schedule
it
in
two
weeks
to
do
a
follow-on
to
go
into
more
depth
on
things
like
allocation
and
memory
allocation
and
and
the
dynamic
extensibility
mechanisms.
But
I
will
introduce
those
here
in
this
talk.
B
Initially,
the
the
motivations
were
around
usability
because
there
had
been
some
issues
with
you
know:
people
using
the
jit,
Builder
API
and
getting
confused
about
it
versus
the
Omar
compiler,
and
it
was
it
can
be
more
difficult
to
work
with
both
types
of
Frameworks
because
they
operate
very
differently.
In
addition,
some
of
the
logging
was
kind
of
incomplete,
with
legit
Builder
API,
just
because
it
was
an
API.
It
was
a
pass-through
API,
so
it
was
a
little
bit
more
difficult
to
log
what
was
happening.
B
You
know
following
on
from
that.
It
also
became
kind
of
clear
to
me
that
extensibility
was
a
very
useful
feature
and
I
wanted
to
grow,
that
aspect
of
bitbuilder
to
be
able
to
make
it
easier
for
people
to
add
new
types
and
add
new
operations
and
and
that
kind
of
translated
in
eventually
into
my
head
to
the
I
I
really
had
to
make
a
new
compiler
out
of
this.
So
it's
growing
into
its
own
ir
and-
and
it
has
some-
you
know-
similarities
to
the
existing.
B
The
the
older
Builder
API
that
people
are
familiar
with
and
the
flavor
is
still
the
same,
but
on
my
path
towards
enabling
easier
experimentation
and
more
extensibility
and
easier
extensibility
I've
changed
things
around
a
little
bit
and
defined
a
few
new
Concepts
and
a
lot
of
it
will
start.
Looking
like
a
lot
like
a
compiler
more
like
a
compiler
than
the
original
jetbuilder
IL
looked
like
so
you
know
I'm,
trying
to
make
it
much
more
free
for
people
to
try
out
new
things
outside
of
the
sort
of
restrictions
of
the
Omar
compiler.
B
Framing
I
called
it
so
I
think,
because
Omar
is
used
as
part
of
open
j9,
and
it
has
a
very
strong
use
case.
In
that
sense,
we
have
to
be
a
little
bit
careful
about
how
we
augment
the
Omar
compiler.
This
allows
a
little
bit
more
wild
and
crazy
stuff
to
happen
independently.
So
you
can
try
stuff
out
and
and
explore
lots
of
more
interesting
types
of
things.
B
B
You
can
create
compilers
and
load
extensions
that
are
that
are
called
as
shared
libraries,
dynamically
load
them
into
a
compiler
instance,
and
and
use
them
and
just
a
point
on
notation
here,
so
that
last
word
on
the
slide,
which
is
in
red
and
in
the
in
the
monotype
font.
That's
the
notation
I'm
going
to
use
when
I
use
the
actual
code
name
for
something
in
jit,
Builder
2
as
part
of
the
slide,
so
just
to
distinguish
it
from
other
words
and
other
uses
of
things.
B
So
when
I
mean
the
jit
Builder
2
actual
class,
that's
there
that's
the
notation
that
I'll
use
so
you'll
see
that
riddled
quite
extensively
through
this
presentation
so
and
I
and
I
kind
of
structured.
This
talk
differently
than
other
talks,
so
I
kind
of
I
made
it
into
more
of
a
here's.
How
you
use
jit,
Builder
2
and
use
that
as
a
framework
to
introduce
the
various
Concepts
that
I've
been
working
on
as
opposed
to
the
here's,
how
this
works?
B
Here's,
how
this
concept
Works,
here's,
what
this
concept
is
and
how
it
works,
Etc,
so
you'll
it
will
be
introducing
things
as
I.
Go
there'll,
be
a
little
bit
of
a
shock
for
some
of
the
the
negotiations
and
and
ideas,
but
I'll
try
to
explain
things
as
I
go
and
if
I
miss
anything.
Please
feel
free
to
ask
a
question.
B
So
the
first
basic
step
in
using
jit
Builder
too,
is
to
create
a
compiler
object.
So
if
you
remember
in
jit
Builder,
there
was
a
this
init
jit
Builder
call
that
you
used
to
call
at
the
or
initi
initialize
jit,
sorry
initialize,
the
jit
haven't
used
it
in
a
long
time,
initialize
jit
that
you
would
call
which
would
you
know
and
initialize
it
legit
compiler,
and
you
would
then
be
able
to
generate
code
using
it
at
the
end.
You
do
shut
down
jit
and
there
was
only
ever
one
jit
you
can.
B
You
couldn't
call
initialize
chip
more
than
once
in
jetbuilder
2.
You
can
create
different
compiler
objects
which
basically
create
new
contexts
to
be
able
to
create.
You
know
incredibly
different
types
of
compilers
that
are
operating
at
the
same
time
in
the
same
process,
so
here
just
to
simplify
the
slides
and
I
kind
of
made
it
clear.
Everything
is
in
the
Omar
jit
Builder
namespace,
but
I
don't
use
the
Omer
to
build
their
namespace
anywhere.
B
So
please
just
assume
that
it's
there
then
the
idea
is
that
you
can
just
create
a
compiler
see
in
this
case
it
can
give
has
an
entity
name
or
you
can
give
it
a
name
if
you
really
want
to
to
distinguish
it
from
other
compilers,
when
that
object
goes
away,
that
compiler
basically
gets
completely
destructed.
B
So
you
can
imagine
that
there's
there's
like
an
initialized
jit
at
the
beginning
of
the
first
compiler
that
gets
created
and
there's
a
shutdown
at
the
end
of
the
at
the
end
when
it
gets
destructed
in
principle,
although
it's
not
actually
done
quite
that
way,
each
compiler
has
an
Associated
config
object,
which
is
how
you
basically
configure
how
it
works.
As
you
might
expect,
so
you
can
it's
got
kind
of
a
fluent
kind
of
API
there,
so
you
can
get
the
config
from
the
compiler
and
then
set
a
bunch
of
things.
B
If
you
want
to
set
things
you
can
you
can
use
the
each
one
has
a
different
config,
so
you
can
configure
compilers
differently
independently
I
guess
you
can
also
tailor
there's
some
things
like,
for
example,
if
you
want
to
provide
a
certain
kind
of
allocator
like
a
tracing
allocator
when
you
create
the
compiler
object
itself.
B
So
if
you
want
the
memory
allocator
that
the
compiler
is
going
to
use
to
be
a
tracing
allocator,
you
have
to
set
that
up
when
you're
Com
when
you're
creating
a
compiler
and
so
that
that's
something
that
you
can
do
in
a
config,
you
can
create
a
config
option.
Config
object
yourself,
configure
it
in,
however,
way
you
want
and
then
pass
that
thing
into
the
compiler
object
that
you
create,
and
it
will
use
that
config
object.
B
B
So
they're
completely
independent,
although
there
is
a
way
to
establish
a
parent-child
kind
of
relationship
between
compilers,
so
it's
possible
for
a
child
to
refer
to
a
parent's
memory,
but
the
allocation
is
controlled
specifically
by
the
by
each
compiler
object,
and
you
can
very
easily
ask
a
compiler
for
its
allocator
so
that
you
can
allocate
objects
that
have
the
same
life
cycle
as
the
compiler
and
just
like
in
Testarossa
once
the
compiler
goes
away,
all
its
memory
goes
away
as
well.
B
That's
the
principle
anyway.
It's
not
actually
how
it
works
right
now,
right
now
the
allocator
is
just
calling
malikin
free,
but
but
all
of
the
all
of
the
objects
within
jit
Builder
are
using
the
allocator
API
to
allocate
memory
through
that
API
So.
Eventually
it
will
do
the
thing
it's
supposed
to
do.
I'm
not
going
to
talk
again
about
allocations.
Specifically
in
this
talk,
it's
a
part
two
topic
to
be
to
be
expanded.
Upon
later,
can
I
ask.
A
A
question
yeah
sure
so
for
the
configuration
objects,
what
do
you
have
in
the
configure?
What
can
you
configure.
B
Not
very
much
right
now,
it's
it's
mainly
just
a
principal,
principled
concept,
but
it
does
have
some
things
for
you
know
specifying
tracing
it
does
have.
There
is
some
basic
support
for
like
perform
transformation
and
being
able
to
turn
certain
Transformations
on
and
off
that
kind
of
thing
in
there
aren't
very
many
things
that
use
performance
transformation
yet,
but
thank.
B
No,
it
doesn't
have
anything
like
that,
so
the
the
the
idea
for
command
line
processing
so
I
mean
if
you
use
the
Omar
compiler
under
the
covers.
Obviously
it
processes
TR
options
and
it's
whatever
it
wants,
but
for
the
jit
Builder
to
configure
itself,
the
idea
would
be
that
eventually
it
doesn't
do
this
now.
B
You
would
write
your
own
command
line
processor,
which
would
translate
your
command
line
options
into
the
command
line
of
the
config
object,
and
then
the
project
might
provide
a
default
implementation
of
a
config
that
has
a
particular
notion
of
what
command
line
options
look
like.
So
if
you
want
to
use
that
you
can
use
it,
but
otherwise,
if
you
have
an
existing
runtime
say
which,
which,
where
that
that
command
line
option
scenario,
doesn't
work,
then
you
can
do
your
own.
You
can
roll
your
own.
That's
the
idea!
Anyway!
B
It
could
there's
no
reason
why
you
couldn't
have
allocators
that
reuse,
the
Omar
ones,
if
you
wanted
to
but
I'm
yeah
I'm
keeping
it
separate
for
now,
because
so
one
possible
wild
and
crazy
Direction
here
is
the
jetbuilder
2
becomes
the
compiler
implementation,
so
it
subsumes
the
Omar
compiler.
There
are
other.
There
are
other
things
like
it.
Could
you
could
very
easily
make
an
llvm
code
generator
for
git
Builder
2
right
now,
like
it's
not
sort
of
it?
B
It
doesn't
have
jit,
Builder
or
Omar
compiler
baked
into
it
on
purpose
and
actually
I'll
talk
a
little
bit
about
that
when
I
get
to
extensions,
but
not
a
lot
all
right,
so
compilers
can
compile
things.
That's
a
very
useful
statement,
but
the
things
that
get
compiled
are
anything
that
subclass
is
a
thing
called
compile
unit
which
was
kind
of
the
most
basic
name
that
I
could
come
up
with
it.
B
I
didn't
want
to
use
the
unit
because
it
was
too
generic,
so
compile
unit
you
can
think
of
this
like
functions
or
traces
or
basic
blocks
or
funks,
or
helpers
or
bytecode
or
whatever.
Whatever
unit
of
compilation
you
want
to.
Have
you
can
in
principle,
create
a
subclass
of
compile
unit
to
handle
that
and
then
how
it's
compiled,
gets
described
by
a
thing
called
a
strategy
which
has
a
strategy
ID?
B
All
these
things
have
IDs
actually,
but
a
strategy
ID
that
you
can
pass
around,
and
then
you
can
request
that
you
compile
a
compile
unit
using
that
strategy,
so
this
code
here
shows
the
basic
process.
Here
you
create
a
compiler,
you
create
some
kind
of
compile
unit,
which
obviously
is
very
generic.
You
can't
actually
allocate
a
compiler
like
you
can,
but
it's
not
very
useful
because
it
doesn't
do
anything
and
then
you
get
your
hands
on
a
strategy.
B
B
You
know
hold
your
questions
about
that
section
of
code
just
now,
because
I'm
going
to
go
through
a
few
points
on
it
once
you've
done
the
compile,
it
creates
a
thing
called
a
compiled
body.
Everyone
should
recognize
these
names
from
testosterosa
world
or
just
compilers
in
general.
It
creates
a
compiled
body
object
which
is
associated
with
the
strategy
that
we
was
used
to
compile
it
right.
B
So
in
the
open,
j9
world,
this
would
be
a
cold
or
a
warm
or
a
hot
strategy
would
be
used
to
compile
some
Java
method,
and
you
could
ask
for
the
compiled
body
for
that
method.
If
it
was
cold
or
warm
or
hot
or
whatever
they
don't
they
don't
replace
each
other.
You
can.
You
can
have
multiple
compiled
bodies
stored
on
the
on
the
compile
unit,
and
then
each
compiled
body
can
provide
the
entry
points
that
you
need
to
access
it.
B
So
this
is
quite
sort
of
similar
to
how
you
would
have
done
this
with
jit
Builder
one.
But
you
can
ask
the
body
for
a
native
entry
point,
and
then
this
is.
This
is
kind
of
an
example
of
how
I
have
used
templates
throughout
jetbuilder
too,
as
kind
of
a
way
of
avoiding
having
static
casts
all
over
the
place.
B
You
basically
provide
a
type
and
that
type
gets
hidden
within
the
within
this
within
this
function
thing
so
you
you
just
see
a
native
entry
point
of
a
function,
prototype
thing
and
it
does
the
cast
for
you
and
and
occasionally
other
things
as
well,
like
there's
other
other
code
that
gets
hidden
behind
this
kind
of
template
notion,
but
you'll
see
this
in
a
number
of
different
places
and
then
the
idea
is,
you
can
just
call
after
like
SSC
function
in
this,
in
this
particular
case
right
because
you've
compiled
it
in
some
way
all
right.
B
So
there
are
some
things
in
here
that
I
didn't
talk
about
very
much,
so
let's
go
through
some
of
them,
so
so
compile
unit,
that's
obviously
a
very
generic
class.
It's
not
very
useful,
in
fact,
if
you,
if
you
do
actually
allocate
a
compile
unit
and
try
to
compile
it,
it
won't
do
anything
because
it
doesn't
generate
any
IL.
It
doesn't
tell
you
anything
about
how
to
compile
anything
it
just
kind
of
it
has
like
return,
true
basic
elements
to
to
to
to
make
the
compile
succeed,
but
it
doesn't
actually
do
anything.
B
So
you
need
to
add
new
kinds
of
compile
units
in
digit
Builder
to
using
things
called
extensions
and
I'll
talk
more
about
these
coming
up
in.
B
Yeah
I
think
of
it
like
a
it's
like
a
TR
method
right,
but
it
could
also
be
a
j9
method
like
it's.
It's
basically
just
a
thing
to
hang
on
to
the
things
that
you
want
to
compile,
and
then
so
extensions
can
are
able
to,
though
there's
ways
and
git
Builder
2.
That
extensions
can
add
new
compiled
unit
types.
Basically
subclassing
you
can.
All
extensions
can
also
add
new
strategies
if
they
want
to
do
different
types
of
compiles.
B
If
you
know
you
can
have
a
compile,
the
only
compile
strategy,
actually
that
jit
Builder
2
defines
is
the
Cogen
strategy
which
basically
just
does
Cogen,
doesn't
do
any
optimizations,
but
you
can
Define
new
passes.
You
can
add
those
passes
to
strategies.
You
can
Define
what
those
strategies
are
called
and
register
them
with
the
compiler,
and
then
you
can
use
your
compile
call
to
cause
it
to
use
that
strategy
when
it
compiles
a
particular
unit.
B
You
can
add
new
compiler
return
codes,
so
there
are
a
few
that
get
defined
by
the
compiler
itself
and
they're
accessed
off
the
compiler
object,
but
you
can
also
create
your
own.
You
can
register
your
own
compiler
return
code,
so
that
code
can
depend
on
those
return
codes.
B
There's
also
it
uses
exceptions
to
handle
exceptional
conditions,
and
you
can
Define
new
types
of
compiler
exceptions
that
can
get
passed
in
ETC
and
all
that
stuff
gets
handled
by
extension,
objects
which
I'll
again
eventually
talk
about,
but
it's
trying
to
give
you
a
flavor
for
how
these
things
get
packed
in
there's.
Also,
this
look
thing.
That's
sort
of
sprinkled
through
here
and
you'll
see
it
sprinkled
through
a
number
of
the
the
examples
that
I've
got
in
here.
B
So
this
is
I'm
going
to
talk
about
this
one
in
a
little
bit
more
detail.
I
have
a
whole
slide
dedicated
to
it.
So
many
of
the
objects
that
get
created
in
a
zip
Builder
2
get
tagged
with
their
creation
location.
So
this
is
really
a
debug
feature
trying
to
Aid
in
in
being
able
to
associate
specific
objects
with
where
they
got
created,
and
the
reason
why
I
thought
this
was
was
even
more
important
to
do
than
in
other
compilers
is
because
you're,
if
I'm
designing
an
extensible
code
framework
where
you're
going
to
be
reusing.
B
Other
people's
extensions
to
to
complete
a
compiler,
you
may
have
no
idea
where
a
particular
thing
actually
got
created
and
so
having
a
way
of
tracking
where
things
are
and
and
who
was
creating
the
line
of
code
actually
produced.
This
thing
is
actually
you
know,
I
considered
that
to
be
a
very
important
feature
here.
B
So
Luke
is
just
a
pre-processor
macro
that
expands
into
the
three
the
usual
three
arguments
that
locate
where
things
are
which
file
you're
in
which
line
number
you're
at
and
which
function
you're,
you're
in
the
middle
of,
and
then
there
are
corresponding
macros
that
allow
jit,
Builder
2
functions
to
kind
of
pass
those
things
around,
so
you
can
accept
a
location
as
a
parameter
in
a
function
to
force
somebody
to
pass
in
one
of
these
things.
If
you're
a
jit,
Builder
two
function.
B
That
needs
to
call
something
that's
going
to
allocate
more
stuff,
you
can
pass
the
location
through
so
that
it
goes
all
the
way
out
to
the
code
location,
that's
outside
of
jit
Builder
2
right.
So
you
don't
see
all
of
these.
All
of
these
things
being
created
by
jit,
Builder
2
itself.
You
pass
through
the
caller
context.
B
I'm,
pretty
sure
everyone
on
the
call
is
kind
of
twisting
their
mouth
and
let's
say
it's
unpleasant,
I
guess
this
is
I,
think
it's
going
to
be
very
useful
for
debugging
and
hopefully
it
outweighs
the
pain.
There
are
some
very
non-ideal
aspects
of
this
like,
for
instance,
it's
the
first
parameter
and
there's
three
of
them,
so
it
kind
of
uses
up
a
lot
of
the
registers
that
you
might
otherwise
use
for
passing
things
around.
So
it'll
probably
have
some
performance
impact.
It
does
clutter
up
the
code.
A
little
bit.
B
I
tried
to
keep
the
one
that
you
use
most
frequently,
which
is
on
the
caller
side,
the
loc
as
the
shortest
possible
thing
that
I
could
get,
but
it
does
kind
of
show
up
in
a
lot
of
places
and
it
does
kind
of
clutter
the
code
up
a
little
bit.
I
am
open
to
Alternative
suggestions
if
people
have
other
thoughts
for
better
ways
to
do
this,
but
it's
the
easiest
thing
that
I
could
come
up
with
and
I've
been
doing
this
fairly
consistently
since
I
started.
B
So
pretty
much
everything
in
the
compiler
right
now
does
have
this
sort
of
note
this
this
use
of
location
and
look
and
it's
there
and
you
know
it's
easy
to
Rel
It's
relatively
easy
to
expand
it
with
new
code
that
uses
the
polls
the
same
guidelines
basically
but
like
I,
say,
if
there's
other
ways
of
doing
this,
that
are
better.
That
I
haven't
thought
of.
Please
suggest
them
because
I'm
not
super
happy
with
it.
A
B
This,
this
location
is
not
not
necessarily
the
location
of
the
source
code
line
of
the
thing
that
you're
compiling,
necessarily
it's
more
of
a
where
in
the
compiler's
source
code,
yeah
I
did
this
thing
get
created
right
that
that
other
thing
that
you're
talking
or
that
other
that
other
notion
of
the
source
code
line
that
also
exists?
There's
a
thing
called
Source
location
that
you
can
specify
as
an
operation.
It's
actually
in
the
I
believe
it's
in
the
core,
the
core
extension
that
you
can
basically
tag.
It's
it's
like
an
operation.
B
C
B
A
and
a
file
and
such
and
so
on,
and
then,
when
we
compile
that
down
into
the
Omar
compiler,
it
basically
makes
up
by
code
indices
to
correspond
to
the
source
code
location.
So
it
does
track
all
the
way
down
it.
Just
you
have
to
monitor
things
a
little
bit,
because
the
old
Mark
compiler
doesn't
have
a
super
generic
notion
of
what
a
location
is.
B
B
Okay
and
so
I
didn't
talk
very
much
about
what
goes
into
a
compile
unit.
I
mean
you
can
kind
of
imagine
this,
but
here's
the
sort
of
one
slide
summary
of
the
IL,
which
obviously
isn't
a
lot
of
detail
so
and
there,
but
most
of
these
are
things
that
I
think
will
be
familiar
to
people
who've
used,
jit
Builder
before
or
who've
worked
on
compilers
before
there
are
a
couple
of
interesting
ones
that
I'll
spend
a
little
bit
of
extra
time.
B
Talking
about
so
we've
talked
about
compile
unit
already
the
two
new
ones
are,
this
top
level
scope
and
context
objects
I'm,
going
to
just
defer
that,
for
now,
like
scope
is
kind
of
associated
with
the
code
in
context
is
sort
of
associated
with
data,
but
just
suspend
those
for
a
minute.
While
I
talk
more
about
I,
guess
I'm,
going
to
talk
about
scope
right
away,
scope
is
really
an
abstraction
layer
over
the
flow
of
control
to
Builder
objects.
B
That's
a
really
weird
statement,
but
basically
it
provides
a
way
for
the
compiler
to
talk
about
code.
That
needs
to
happen
when
you
move
between
two
different
Builder
objects.
So
the
example
that
I
that
I
think
I
want
to
use
for
this
one-
and
let
me
know
if
it
doesn't
make
sense,
would
be
imagine
that
you're
compiling
in
a
secure
environment
and
you've
got
code
that
has
two
different
security
domains.
B
The
code
for
each
of
those
domains
would
be
in
when
different
Builder
objects
in
principle
right
and
if
you
wanted
to
transfer
control
from
one
to
the
other.
There
might
be
things
that
you
need
to
do
in
order
to
get
out
of
one
context
and
into
another
context,
so
the
scope
object
can
be
used
to
represent
that
kind
of
relationship
without
having
it
have
to
be
reflected
directly
in
the
IL
of
the
of
the
code
you're
compiling.
So
basically,
it
provides
a
way
to
to
it's
like
an
abstraction
layer.
B
C
B
So
I'm
not
going
to
talk
about
this
very
much
in
this.
In
this
talk,
so
I
don't
want
to
get
stuck
here,
and
it's
also
like
I
said:
I
haven't
really
thought
very
hard
on
how
to
explain
this
to
people,
but
I
did
want
to
mention
it
just
because
it's
a
new
thing
that
got
introduced
and
context
is
kind
of
of
the
same
flavor.
But
I'll
talk
about
it
later.
B
It's
the
same
thing
for
symbols
anyway,
Builders,
let's
get
back
to
something
more
basic,
so
Builders
are
basically
a
sequence
of
operation,
objects,
they're,
not
basic
blocks,
they're
single
entry,
and
they
can
have
multiple
exits.
They
can
also
have
internal
control
flow,
but
it
has
to
be
completely
contained.
Internal
can
control
flow
and
that
internal
control
flow
has
to
be
sort
of
managed
within
an
individual
operation.
So
the
best
example
of
an
internal
control
flow
is
an
if
then
else
right.
So
it
has
an
embedded
split
and
merge
it's
all
contained
within
the.
B
If
then
else
operation,
but
it
references
other
Builder
objects
for
holding
what
has
to
happen
on
the
then
side,
what
has
to
happen
on
the
else
side
and-
and
so
those
are,
those
are
sort
of
Builder
objects
that
are
referenced
from
inside
the
the
operation
and
that's
what
I
kind
of
got
ahead
of
myself
a
little
bit.
But
operations
are
what
we
use
to
describe.
B
B
It's
got
a
continue
label
that
you
might
need
to
break
to
to
jump
to,
and
so
the
Builder
objects
that
are
referenced
from
an
operation
can
be
either
Bound,
in
other
words,
they're
they're,
reflecting
this
internal
kind
of
control
flow
like
the
body
of
a
for
Loop
or
like
the
then
side
of
an
if
then
else
or
they
can
be
Unbound,
as
in
other
words
they're.
Just
a
pure
outward
flow
I'm
just
going
over
that
other
Builder
over
there
and
there's
no
relationship
I'm
not
going
to
come
back
into
this
Builder
from
there.
B
It's
an
example
of
that
would
be
something
like
an
if
compare
equal
to,
if
they're,
not
if
they're
equal
to
this,
then
go
Branch
over
there
and
you're
not
going
to
come
back.
So
these
Notions
are
kind
of
encapsulated
in
in
how
Builder
objects
hold
things
in
operations,
so
they're
a
little
bit
more
powerful
than
a
basic
block,
but
they're
not
completely.
C
B
So
so
the
for
Loop
itself
has
an
entry
Edge
that
gets
you
into
the
for
Loop
and
then
there's
an
exit
Edge
from
like
the
for
Loop
ends
at
some
point
and
that's
after
you've
finished
executing
the
for
Loop
and
then
as
you're
executing
the
operation,
the
for
loop
operation,
it's
managing
the
well
run
the
Builder
thing
run
the
body
Loop
do
the
test.
Is
it
done?
Do
it
again
right
it's
managing
that
control
flow,
so
it's
it
basically
handles
the
flowing
of
stuff
around
when
the
Builder
gets
it.
B
C
B
So
it's
a
it's
a
nested
IL
for
sure
it's
not
a
sort
of
like
a.
If
you
look
at
like
testerosis
IL,
for
example,
the
arrangement
of
blocks
they're,
all
very
linear
on
purpose
right,
there's,
no
multi-layers
right!
It's
just
a
it's
just
a
simple
list
of
operations
and
if
there's
an
operation,
that's
control
flow.
That's
the
end
of
the
block
and
you're
done
kind
of
right,
but
we've
used
that
to
do
you
know
we
put
those
blocks
together
in
Testarossa
to
do
like
methods
full
of
like
a
compile
unit.
B
That's
a
full
method.
We've
used
it
in
zpdt,
for
example,
to
do
Trace
I
build
traces
where
it's
a
different
sort
of
arrangement
of
things.
Builder
is
just
a
slightly
more
powerful
way
of
assembling
operations
and
they're.
They
make
it.
In
my
opinion,
they
make
it
a
little
bit
easier
to
do
extensions
that
can
create
fairly
powerful
new
operations,
that
and
in
in
pretty
General
ways.
B
C
Have
to
linger
on
this
point
that
much,
but
in
the
Java
side
recently,
I
was
thinking
about
the
effect
that
certain
guards
have
on
the
IL
and
in
particular,
osr
on
track
replacement
breaks,
blocks
and
requires
gra
to
pass
values
between
blocks
thinking
if
it
was.
If
there
was
a
nice
way
to
just
encapsulate
all
that
in
place
in
a
tree
and
have
it
almost
be
expanded
by
the
code
plan
and
not
break
a
block.
Whenever
you
insert
one
of.
B
These
parts,
so
that
sounds
more
what
you
just
described
at
the
level
that
you
just
described.
It
sounds
more
like
a
scope
thing
than
it
does
like
the
Builder
thing
in
itself.
Right.
So
so,
Scopes
like
I
I,
mentioned
scope
as
a
like.
Compile
unit
has
a
scope,
but
you
can
cap
inner
Scopes.
You
can
have
nested
Scopes
you
can
you
can
have
that
object
like
Builder
objects.
B
Basically,
a
builder
object
has
a
scope
that
it
links
to,
and
then
you
can
have
a
number
of
builders
that
have
that
scope
and
they're
the
the
builders
themselves.
Don't
necessarily
have
to
be
a
structured
control
flow
kind
of
thing.
They
can
come
from
anywhere
right.
The
the
easiest
thing
is
like
an
inline
scope.
Maybe
right,
like
the
inline
body,
has
its
own
scope
and
the
caller
has
a
scope
and
all
the
Builder
all
of
the
code,
that's
associated
with
the
caller,
can
have
the
callers
scope
and
the
inner
all
the
code.
B
That's
associated
with
the
inline
code
can
have
an
inline
scope
and
those
objects
can
have
different
things,
but
in
your
example,
you
could
have
a
scope
that
captures.
What
is
the
code
that's
covered
by
this
osr
guard
and
then
talk
about
what
has
to
happen
if
you
come
out
of
that,
that
section,
via
some
a
particular
exit
same
right.
B
Yeah
we
can
talk
about
it
in
more
detail,
another
time,
maybe
because
I
don't
want
to
get
stuck
here
for
too
long
all
right.
So,
let's
move
away
from
Builders
symbols.
So
symbols
don't
exist
in
the
zip
Builder
API,
but
they
do
in
the
jit
Builder
2
world
so
because
it
they
become
easier
ways
to
reference
memory.
Obviously
they
exist
in
the
Omar
compiler
and
they're
they're.
They
represent
different
types
of
memory.
That
operations
can
access.
B
B
They
could
also.
You
could
also
be
thinking
them
as
think
of
them
as
an
infinite
virtual
register
set,
but
they're,
not
necessarily
registers,
they're,
just
ways
of
passing
values
around
and
then
all
values
and
symbols
have
types.
So
you
can
ensure
type
safe
access
for
all
of
those
all
of
these
things
and
then
and
then
right
and
in
context.
So
context
is
similar
to
scope,
but
for
data
objects
and
the
reason
why
I
designed
this
context
notion
was
so.
The
the
entire
compile
unit
can
have
a
context
again.
B
There
can
be
inner
context,
but
it's
a
way
of
abstracting
away
how
the
how
the
function
or
how
the
compile
unit
accesses
symbols
and
the
the
motivating
reason
for
this,
which
I
think
is
a
generic
kind
of
use
case,
was
actually
in
the
debugger,
because
in
the
debugger,
when
I
was
building
a
debugger,
it
basically
takes
the
the
the
whole
set
of
the
frame,
the
parameters
and
the
values
and
says
well
they're,
not
actually,
in
those
places
directly
on
the
stack
frame,
they're
actually
being
maintained
in
this
array
of
debug
values
that
the
debugger
is
maintaining
outside
of
the
the
the
native
code
that
you're
generating,
and
so
this
context
layer
provides
a
mechanism
whereby
you
can
code
can
say,
I
need
to
access
the
symbol
and
when
the
context
can
provide
the
IL
that's
needed
in
order
to
actually
get
that
the
value
of
that
symbol
from
a
particular
element
of
the
of
the
context
like
the
like
the
debug
value
sitting
in
an
array
based
on
the
number
of
the
value
or
or
whatnot
again,
that's
probably
too
abstract.
B
All
of
these
things
other
than
the
compile
unit,
which
is
something
that
exists
outside
of
a
Compilation
All
of
the
get
created
inside
a
compilation.
So
there's
a
there's,
a
memory,
allocator,
that's
associated
with
a
compilation,
object
and
it's
the
thing
you
should
be
using
to
allocate
all
of
these
things
and
that's
basically
how
jit
Builder
2
is
set
up
to
do
this
and
that
had
some
implications
for
how
you
actually
write
the
code
that
you
use
to
specify
a
compile
unit
like
a
function
so
I
think
yeah.
B
So
the
the
next
few
slides
I'm
going
to
revisit
one
of
the
basic
examples
that
I've
used
to
talk
about
jit
builder
in
the
past,
which
is
generating
a
function
that
just
increments
a
32-bit
integer
value.
So
if
you
wrote
that
code
in
C,
it
would
look
like
this
with
the
n32t
being
returned
by
increment,
takes
a
value
in
it.
Just
Returns
value,
plus
one
right.
It's
a
little
bit
more
complicated
than
my
return,
three
famous
example,
but
it's
it's
not
very
much
more
complicated
right.
B
So
this
example
I'm
going
to
go
through,
is
specific
to
handling
a
32-bit
integer
type,
but
it
should
be
fairly
easy
to
see
how
you
could
generalize
this
for
any
numeric
type
quite
quite
easily.
The
basic
process
here,
which
is
the
same
thing
that
you
had
from
from
jit
Builders,
it's
just
the
names,
are
different
and
the
fact
that
there's
a
compiler
involved,
but
you
you
write
a
subclass
of
compile
unit.
That
knows
what
kinds
of
things
the
function
should
do
and
how
you
should
pass
in
value
and
what
you're
going
to
get
back.
B
Then
you
allocate
an
object
of
that
class
which
corresponds
to
this
increment
guide
that
you're
trying
to
compile.
And
then
you
ask
a
compiler
to
compile
it
and
then
the
thing
you
get
back
you
can.
You
can
call
that
just
like
it,
just
like
you'd
written
this
source
code
in
in
this
on
the
slide
and
pass
it
a
value,
so
we're
building
a
function
so
functions
in
just
Builder.
2
are
supported
by
an
extension
called
func
just
because
function
is
too
long.
B
So
the
way
that
you
get
access
to
a
func
extension
is
there's
a
there's,
a
particular
header
file
which
basically
gives
you
it
defines
everything
inside
this
namespace
funk
that
tells
you
how
to
use
what
you
can
do
in
functions.
There's
also
another
extension
called
base
that
gets
used
in
this
example,
which
provides
all
of
the
IL
support.
That's
kind
of
like
what's
in
git
Builder,
so
by
default,
I
think
I
mentioned
before
Builder
2
doesn't
really
have
very
much
itself
that
you
can
do
with
it.
B
B
Extension
present
loaded,
taking
up
memory
taking
up
space
and
your
cognitive
brain
whatever
and
bass
is
an
extremely
poorly
named
extension
that
just
provides
a
lot
of
like
ads,
sub
load,
store
or
not
even
load
store,
support
for
struct
support
for
pointers.
Things
like
that
and
then
and
then
so.
In
terms
of
kind
of
getting
going,
you
know
you
I'm
again
I'm
going
to
use
these
using
namespace,
funk
I,
don't
actually
recommend
doing
this
and
I
don't
do
it
in
any
of
the
code
base
anywhere.
I
use
more
like
this.
B
The
base
extension
notation
here
to
add
the
namespace
all
the
time,
which
is
why
I
like
a
short
namespacing,
but
you
create
a
compiler
and
then
you
can
load
an
extension
very
easily.
Just
by
giving
the
name
of
the
of
the
function
extension
class,
which
is
the
there
actually
is
an
object,
called
an
extension
object
and
you
give
that
object
name
and
it
will
go
and
load
it.
It
knows
what
its
name
is
from
a
name.
B
It
derives
a
a
library
file
name
to
load
dynamically
off
disk
and
it
goes
off
and
finds
it
and
it
hands
you
as
part
of
loading.
That
thing
it
creates
an
object
of
this
type
and
it
returns
it
to
you
and
then
you
use
this
function
later
on
to
do
all
the
kinds
of
things
that
the
function
extension
allows
you
to
do,
and
in
some
cases
you
can
refer
to
other.
B
You
can
refer
to
classes
that
are
also
loaded
as
part
of
the
function
extension
and
then
the
same
thing
you
can
do
for
the
base
extension
right
in
this
case.
You
just
create
the
base,
extension
object
and
and
load
it
and
the
compiler
will
load
it
and
give
you
an
object
back.
Obviously,
there
should
be
error.
Checking
here,
the
slide,
this
kind
of
notation
fxbxr
is
again
it's
because
you
see
these
quite
a
lot
in
the
code.
B
I
tend
to
use
very
short
names
for
them
to
try
and
distinguish
between
them
without
without
creating
a
lot
of
visual
clutter.
Now,
Funk
introduces
a
function
class
which
subclasses
compile
unit.
So
now
we
can
now
we
can
create
functions
to
compile,
and
the
expectation
is
that
that's
going
to
be
further
subclassed
by
some
compiler
environment
to
create
specific
functions.
So
in
this
case
it's
it's
like
the
method
Builder
that
you
had
in
jit
Builder,
except
that
Now
function
is
not
itself
a
build
or
object.
B
So
it
used
to
be
the
case
that
you
created
a
method
Builder
and
you
could
already
just
add
operations
to
it
and
you'd
be
adding
operations
to
the
code
path
that
gets
caught
when
you
call
them
the
the
function.
It
goes
and
starts
off
executing
those
operations.
However,
now
because
I
didn't
want
to
make
Builder
or
compile
unit
sort
of
cross-connected
function
is
not
a
builder
itself,
so
you
have
to
do
something
else
and
I'll
talk
about
what
that
is
later
in
jit
Builder.
There
were
basically
two
things
that
you
created.
B
You
created
a
Constructor
that
would
tell
you
about
what
the
what
the
function
did
and
how
you
would,
how
you
would
call
it
and
then
build
IL.
You
would
Define
to
build
the
IL
which
described
what
the
function
actually
does.
There
are
now
three
injit
Builder
two
one
of
them
is
the
same
Constructor,
but
you
can't
do
as
much
here
because
more
of
the
it's
hard
to
describe
parameters
because
you
need
types
and
you
need
symbols
and
those
things
are
only
supposed
to
be
mostly
created
inside
a
compilation
they
haven't
made
it.
B
You
haven't
started
a
compilation
yet
you're,
just
creating
this
object
to
be
compiled
so
that
that's
that's
those
two
things
have
been
kind
of
split
out
so
now,
there's
a
Constructor
where
you
can
do
a
little
bit
of
stuff
and
build
context,
is
something
that
now
gets
called
before
build
IL.
In
order
to
build
out
this
notion
of
what
the
function
is
that
you're
actually
calling
and
then
you
still
have
to
do,
build
IL,
build
IL
used
to
be
a
parameter-less
function
again
because
it
was
a
path
through
API.
B
It
was
a
lot
simpler
to
work
with
Now,
you
kind
of
need,
access
to
a
compilation,
object
and
I've,
also
augmented
that
with
passing
in
a
context
and
a
scope
object.
Technically,
these
things
are
accessible
from
the
compilation.
You
can
do
comp,
Arrow
scope
and
get
the
scope,
object
or
Arrow
context
and
get
the
context
object,
but
for
Simplicity,
State,
Simplicity
I
added
these
as
additional
parameters
and
again
it
just
kind
of
reduces
the
boilerplate
that
you
need
that
you
commonly
need
when
you're
writing
these
things.
You'll
see
examples
of
that
later
on.
B
B
B
None
of
this
code
has
any
dependency
on
on
Omar
compiler,
so
it's
all
completely
separate,
but
I'll
show
you
how
to
Builder
how
how
it
gets
into
the
Omar
compiler
later
via
gen
Builder,
but
the
same
basic
principle
right:
okay
and
then
another
common
thing
that
you
see
when
you,
when
you
have
to
do
these
is
to
you
know,
because
extension
objects
are
used
to
produce
IL.
You
kind
of
want
to
have
these
objects
around
the
readily
accessible,
so
I
often
produce
them
as
a
as
fields
on
the
on
the
object
right.
B
So
there's
a
core
extension
I'll
tell
you
about
later
a
function
extension
which
I
just
mentioned
base
extension
I
just
mentioned
right,
so
store
on
the
six
these.
Basically,
what
is
what
the
Constructor
is
going
to
set
all
of
these
things
up
and
remember
them,
and
then
I
also
sometimes
pass
around
symbol,
hold
the
symbol
so
that
it's
easier
to
remember
the
information
that
you
did
in
build
context
and
have
it
available
for
you
in
Bill
IL
very
easily
without
having
to
look
it
up
so.
A
B
So
function
extension
has
that
class
has
a
name
so
that
that
class
is
going
to
get
embedded
into
into
your
whatever
your
contact
is,
and
it
has
a
static
name
option
like
or
a
name
field
that
has
the
name
of
what
that
extension
is
called,
which
gets
trends
that
gets
pulled
out,
put
into
a
call
to
a
deal
load
loads,
a
static
library
that
has
that
name
off
disk
and
then
and
then
it
pulls
that
in
and
and
there's
a
library
load
right
and
then
it
calls
inside
when
it
once
it
loads
that
Library
it
looks
for
a
create
function,
then
it
can
pass
in
the
compiler
object
and
some
other
stuff,
and
it
calls
that
and
then
that
create
function
of
the
extension
actually
creates.
B
B
So
these
are
the
ways
that
you
can
get
access
to
various
extension
objects.
So
this
is
core
extension
is
something
that
gets
created
by
every
compiler,
so
every
compiler
creates
a
core
extension
and,
and
has
it
sitting
there,
so
you
can
just
ask
for
it.
There's
not
very
much
in
here
I'm
not
going
to
talk
very
much
about
it.
B
It's
some
very
basic
stuff
like
create
an
orphan
Builder
and
things
like
that,
and
then,
if,
if
an
extension
has
already
been
loaded,
you
can
call
lookup
extension,
it
will
go
and
find
the
object
for
you.
So
the
compiler
knows
how
to
find
the
extension
object
for
a
particular
type
two
if
it
wants,
if
you
want
so
rather
than
go
through
the
whole
load
process.
B
Again,
it
just
looks
it
up
in
in
its
little
list
and
then
the
value
part
gets
additionalized
to
null
initially
because
it
hasn't
been
defined
yet
and
then
the
only
thing
that
you
can
really
do
in
the
Constructor
is
you
can
Define
the
name
of
the
target
function
and
just
like
in
jit
Builder.
This
has
very
little
actual
value
in
terms
of
you
know
how
the
code
gets
generated,
but
it's
useful
from
a
debug
standpoint.
So
you
know
what
thing
you're
talking
about.
B
You
should
probably
be
in
red
but
anyway,
to
keep
my
notations
consistent,
but
anyway,
so
I'm
going
to
talk
about
both
of
these
in
in
in
the
next
few
slides,
but
at
a
high
level.
Basically
build
context
is
supposed
to
describe
how
the
function
interacts
with
this
environment
so
for
functions,
it's
it's
to
find
what
the
parameters
are
and
what
the
return
type
is
going
to
be
for
in
build
il's
case.
It's
supposed
to
describe
what
the
function
does
when
it's
called.
B
So
that's
going
to
build
the
I,
not
build
the
IL,
it's
in
the
name
and
how
it's
going
to
compute
the
values
that
it
will
return.
B
So
it
could
have
come
up
with
a
better
title
for
this.
So
here's
the
code
that
we're
that
we've
got
inside
build
context.
So
the
jit
Builder
code
for
this
basically
looked
like
define,
parameter
value
within
32
and
Define
return
type
in
32..
So
it's
not
much
more
complicated
than
in
the
jit
Builder
API.
Here
I've
shown
how
you
can
get
a
type.
So
again
types
aren't.
Actually,
there
are
no
that's
almost
true.
There
are
almost
no
types
that
are
defined
by
default
by
the
compiler.
B
There
is
actually
a
type
called
No
Type,
which
is
kind
of
like
void,
so
not
very
useful,
but
it's
there
and
then
extensions
can
add
their
own
types.
So
when
the
base
extension
gets
created
and
loaded,
it
allocates
a
number
of
types
and
it
makes
them
accessible
directly
off
of
the
object
here
as
a
as
the
the
Primitive
type.
So
these
are
the
same
primitive
types
that
are
familiar
from
jit
Builder
world.
You
know,
there's
int,
8,
16,
32,
64
float,
I,
renamed,
float
and
double
to
float,
32
and
float64
for
consistency.
B
There's
addresses
as
well.
One
thing
that's
interesting
about
types
is
that
they're
always
const,
so
you
can't
change
them
once
you've
created
them,
which
makes
it
awkward
to
pass
them
around
sometimes
but
managed
to
figure
it
all
out.
B
The
usual
C
plus
const
issues
right
so
so
here,
we've
just
said
that
the
parameter
type
that
we're
going
to
use
is
in
32,
and
then
we
have
to
define
a
parameter
which
we
do
on
the
contact.
We
tell
the
context
that
there's
a
parameter
to
be
defined,
we
give
it
a
name
and
what
the
type
is
going
to
be.
So
this
is
almost
exactly
the
same
as
what
we
would
have
done
in
jit
Builder,
the
API.
The
only
difference
is,
it
actually
returns
a
symbol
that
corresponds
to
that
parameter.
B
So
there's
another
thing
that
the
base,
or
actually
that's,
that
the
function
if
the
function
extension
creates,
is
a
a
parameter
symbol,
type
that
you
can.
You
can
store
there
and
then
the
other
piece
is
the
return
type.
So
you
can
it's
going
to
return
the
same
parm
type
and
it's
the
context
that
knows
about
all
of
this.
If
you
had
multiple
parameters,
you
can
call
the
find
parameter
multiple
times.
B
It
assumes
that
in
order
you're
calling
them
from
left
to
right,
It's
relatively
easy
to
do
that,
wouldn't
be
hard
to
change
this
that
you,
so
you
could
do
it
in
random
orders,
but
in
principle
this
usually
seems
to
be
good
enough.
B
All
right!
So
that's
build
context.
So
oh
look
at
that
right.
So
I
think
I
said
all
this
stuff
right
and
right.
Okay,
so
build
IL,
let's
get
into
actually
building
the
IL
now
so
the
first
thing
we
need
to
do
remember
I,
mentioned
that
in
in
jit
Builder
method,
Builders
were
Builder
objects,
so
you
could
automatically
just
put
code
into
them
and
functions
or
not
Builder
objects.
B
So
we
have
to
find
a
builder
object
to
put
this
in,
and
so
the
first
thing
we
do
is
ask
the
scope
which
got
passed
into
us
for
an
entry
point,
and
there
are
different
kinds
of
entry
points
that
can
be
stored
here,
but
Builder
entry
is
sort
of
the
the
one.
That's
always
there
for
or
or
it's
the
one
that's
commonly
used
when
you're
building
IL
and
you
can
ask
the
Builder
entry
for
its
Builder.
B
So
this
is
again
that
same
kind
of
notion
that
I
said
before,
except
this
one's
actually
doing
a
more
it's
doing
more
work
than
just
casting
it's
actually
looking
through
a
list.
A
list,
that's
dedicated
to
entries
of
entry,
zero
to
find
an
entry
point
that
has
the
type
of
Builder
entry
and
it
will
return
it
if
it's
got
it
so
again
should
be
error.
Checking
if
it's
not
there
Etc,
but
this
is
just
a
slide
and
then
Builder
entry
is
really
just
a
class
that
holds
on
to
it.
B
It's
an
entry
point
that
holds
onto
a
builder
object
for
you,
so
you
can
ask
it
and
get
it
back.
So
now
we've
got
entry.
This
is
the
place
where
this
is
the
code
path
that
corresponds
to
somebody
called
this
function,
and
this
is
the
code
that's
supposed
to
execute
right
and
they're
yeah.
Then
there
can
be
other
kinds
of
entries
like,
for
example,
what
the
end
of
compilation.
B
The
scope
will
hold
native
entry
points,
because
the
code
gen
will
have
generated
code
for
it
and
we'll
have
a
native
entry
point
associated
with
it,
which
then
gets
transferred
to
the
compiled
body
at
the
end
of
the
compilation
all
right.
So
once
we
have
the
entry
builder,
then
we
can
start
doing
our
code.
So
that
looks
like
this:
it's
very
similar
in
nature
to
the
to
what
you
would
have
seen
in
jit
Builder,
but
it's
actually
different,
so
I
just
wanted
to
call
out
and
I
simplify
a
little
bit.
B
So
the
red
bits
here
are
are
basically
just
showing
you
the
structure
of
the
computation
that
you're
doing
you've
got
a
value
that
you're
loading
and
it's
being
stored
into
a
value
T1.
You
have
a
constant
integer,
32-bit
integer
for
the
number
one
which
is
being
stored
into
T2
you're,
adding
those
together
and
then
and
then
taking
the
product
of
those
which
are
the
sum
of
those
which
is
stored
in
T3
and
returning
it
from
the
function
right.
B
So
that's
the
the
basic
structure
of
this,
but
there
are
some
elements
here
that
are
different
right.
So
so
let
me
just
step
away
from
it
for
a
second,
so
that
the
generic
way
that
you
added
operations
and
jit
Builder
was
you
had
you
got
some
Builder
objects
somewhere
and
you
call
Builder
Arrow
the
operation
that
you
wanted
to
do
and
pass
that
operations,
and
that
would
hand
back
if
it
produces
a
result.
It
hands
back
a
value.
Oh
actually,
it's
an
IL
value
and
this
is
il
Builder.
B
But
anyway,
you
get
the
basic
idea
in
jit
Builder
2
that
becomes
I
need
to
find
some
extension,
because
it's
the
extension
that
that
introduces
the
operations
that
I'm
going
to
work
with
so
I,
don't
know
how
to
do
an
ad
until
I've
got
an
extension
object.
That
tells
me
how
to
do
an
ad
so
now,
I
call
the
operation
on
an
extension
object
and
I
pass
it
this
location.
B
So
this
is
the
code
location,
that's
causing
this
piece
of
Il
to
get
generated,
so
I
pass
in
its
location,
the
Builder
object
where
it
needs
to
get
added,
and
then
it's
all
brands
and
then
that
thing
still
returns
a
value
if
it,
if
it
produces
a
value,
if
it
doesn't
produce
value,
obviously
it
doesn't
return
to
Value,
but
so
it's
it's
quite
similar.
The
only
difference
is
this
kind
of
extension
object
thing
got
added
in
here
and
the
and
the
Builder
had
to
be
demoted
to
a
a
parameter
that
you
send
in.
A
The
location
there
the
so
this
is
still
that
source
code
location,
as
opposed
to
where
I
am
generating.
That
ad.
B
Correct,
if
you
want,
if
you
wanted
to
pass
in
that
information,
you
would
call
something
like
the
core
extension
Arrow,
Source
location
and
you'd
encode.
The
information
instead
of
located
right.
You
have
to
create
a
there's,
actually
a
class
called
location.
You
create
a
location
which
describes
your
source
code
location
and
then
you
use
Source
location
to
inject
that
into
the
into
the
build
website.
C
One
question
does,
and
maybe
this
is
the
Builder
actually
build
anything.
There's
no.
B
Okay,
not
yet
well,
it
builds.
It's
I
mean
it's
adding
the
operation
to
a
list
of
operations
right,
but
right
now
it's
building
IL,
it's
not
actually
like
in
jit
Builder.
When
you
called
add
it
would
translate
that
into
IL
at
the
Omar
compiler
level
that
you
know
loaded
the
operation
loaded.
The
left
operand
from
the
stack
loaded,
the
right
operand
from
the
stack
issued,
an
IA
ad
in
the
case
of
the
32-bit
integer
one
and
then
stored
it
into
a
stack
location
right.
B
It
would
actually
generate
that
IL
in
the
Omar
compiler
and
then
it
would
forget
completely
like
you
wouldn't
be
able
to
know
what
you'd
done.
All
you
have
is
this
value
that
corresponds
to
the
thing
that
you
produce,
but
you
have
no
idea
that
that
thing
produced
a
32-bit
integer
that
it
was
an
ad
operation
that
it
came
from
two
other
values.
It
was
a
straight
pass-through
operation
what's
happening
in
this
case.
B
Is
it's
actually
building
up
the
structure
of
the
IL
in
memory
and
then
you
can
and
then
you
can
process
it
later
so
after
build
IL
finishes
all
after
all,
the
ILS
and
built.
That's
like
the
course
would
be
illgen
right
right.
Then
you
can
do
whatever
you
want
with
it.
You
can
do
analysis,
you
can
run
passes
on
it.
You
can
optimize
it
Etc,
none
of
that
exists,
but
you
could
do
that
in
person.
Well,
not
none
of
it
exists
because.
B
There
sort
of
but
I
won't
get
into
detail
here
and
I
don't
want
to
get
distracted
at
that
point
with
it.
So
we
can
talk
later.
If
you
want,
maybe
I
can
add
it
to
part
two
or
part
three,
all
right.
So
we
covered
this
okay.
So
let's
talk
a
little
bit
more
about
extensions,
because
I've
mentioned
them
a
few
times
and
and
brought
up
a
few
of
them.
So
there
are
some
extensions
that
already
exist
in
in
jb2.
The
most
basic
one
is
core
extension,
which
is
like
I
I.
B
Think
I
mentioned
earlier
is
automatically
loaded
into
every
compiler
object.
Compiler
should
be
red
and
monotype
font
there.
B
Some
of
the
common
facilities
are
things
like
orphan
Builder,
which
is
a
way
of
just
allocating
a
builder
object
to
start
doing
stuff
with
entry
Builders
how
you
allocate
specific
it
it
doesn't
it's
not
very
different,
but
it
it
creates
a
builder
specifically
for
the
purposes
of
being
an
entry
to
a
compile
unit.
B
Jit
Builder
2
is
not
limited
to
having
only
single
entry
points
like
single
entry
points
on
a
single
and
and
exits
from
things,
but
right
now
all
you
can
create
are
functions
even
in
printable
functions
could
have
multiple
entry
points,
but
nothing
uses
that
and
it
would
not
be
able
to
generate
code
for
it
if
anybody
did
specify
more
than
one
entry
point
so,
but
in
principle,
multiple
entry
points
are
supported,
so
you
could
have
multiple
entry
builders
for
a
particular
compile
unit
merge
depth
as
an
operation
that
I
don't
want
to
get
into
detail
on.
B
It
also
defines
a
simple
code,
generator
or
compiler
strategy,
which
all
it
does
is
try
to
invoke
a
code
generator.
So
there
is
no
code
generator
in
in
the
core
piece
of
jit
Builder
2,
but
other
extensions
can
load
a
code
generator
that
will
that
will
be
dispatched
when
this
code
generator
strategy
happens
and
I'll
talk
a
little
bit
about
that
on
one
of
the
next
lines.
B
I
mentioned
the
funk
extension
ad
support
for
compiling
C
like
functions
so
functions
a
compile
unit.
It
adds
a
function
type
which
can
represent
a
function,
signature
which
you
know
basically
captures
a
set
of
parameter
types
and
return
types
function.
Context
is
a
context
that
basically
defines
parameters.
It
has
a
place
to
store
parameters
and
a
place
to
store
local
variable
stock
variables.
B
Function.
Scope
is
a
is
a
scope
that
has
a
callable
entry
point
right.
So
that's
why
you
can
ask
a
scope
for
its
Builder
entry
and
it
can
hand
you
back
some
things
it
knows
about.
It
knows
that
it
needs
to
have
an
entry
point.
So
I
guess
you
should
I
could
say
function.
Scope
is
a
scope
that
has
all
it
covers.
An
entire
function
is
the
purpose
of
a
function
scope
it
could
you
could?
B
You
can
associate
smaller
sets
of
Builders
with
Scopes
as
well,
but
but
this
is
what
this
is,
what
function
brings
in
function?
Symbol
is
a
type
of
symbol
that
can
be
used
to
reference.
A
callable
function
Target,
so
you
can
call
a
function
symbol,
a
call
using
a
function
symbol,
basically
to
do
a
direct
call
to
something,
and
then
it
adds
specific
operations,
so
call
call
void.
Return
return,
void,
load
and
store
actually
the
function.
B
Extension
object
itself
doesn't
directly
expose
the
notion
of
call
void,
but
it
creates
IL
with
act
with
the
operations
called
call
void.
So
if
you,
it
has
a
call
service
that
you
can
create.
If
you
pass
it
in
the
right
set
of
operations
that
has
a
return
value,
it
will
use
a
call
if
it
doesn't
have
a
return
value.
It
will
produce
a
call
void,
so
it
kind
of
just
differentiates
a
little
bit
between
coal.
B
B
Are
direct
calls,
yes,
okay,
load
and
store
I'm,
actually
considering
moving
these
into
the
core
extension.
Just
because
there's,
like
symbol
is
kind
of
a
not
very
useful
thing
in
the
core
thing,
because
you
can't
do
anything
with
symbols,
so
so
the
notion
of
loading
and
storing
a
symbol.
Even
if
you
can't,
if
you
know
you
can't
create
a
type
of
symbol
in
the
core,
it
might
make
more
sense
for
load
the
store
to
be
there,
but
anyway,
haven't
done
that.
Yet,
as
I
said,
base
extension
is
an
extension.
B
That's
more
like
that,
provides
a
lot
of
the
facilities
that
you're
are
familiar
from.
Jit
Builder,
it's
incomplete
right.
Now,
it's
not
a
full
replacement
for
Egypt
Builder.
It
doesn't
have
all
of
the
arithmetic
operations
defined.
It
doesn't
have
all
of
the
it
Crea.
It
has
all
of
the
types
of
jit
builder,
plus
the
function
type
you
can
get
access
to
other
types,
but
and-
and
it
creates
all
of
the
Primitive
types
pointer-
allows
you
to
create
pointer
types,
struct
types
Etc
as
well.
B
As
you
know,
it
has
some
of
the
simple
arithmetic.
Like
add
mole,
sub,
that
type
stuff.
It
has
most
of
the
control
flow
from
jit
Builder
one,
although
it
doesn't
have
to
switch
right
now
and
all
a
lot
of
the
memory
operations
from
jit
Builder,
one
to
be
able
to
access
fields
from
struck
and
to
dereference
pointers
and
to
access
arrays,
and
things
like
that,
plus
a
few
pseudo
operations
that
help
simplify
things
like
constant
creation.
Etc
I'll
mention
it
here,
because
I
do
talk
about
it.
B
B
This
is
the
first
time
you'll
see
it
I'll
talk
about
it
later
in
the
talk,
but
basically
it
it
tacks
some
stuff
into
the
compilation
object
and
when
a
compilation
object
gets
created,
it
creates
some
base
extension
specific
stuff
for
managing
the
set
of
pointer
types
in
a
set
of
struct
types
that
have
been
created
for
the
compilation
that
you
can
access
via
a
compilation,
object
being
passed
around
and
also
does
one
for
function.
B
Extension
as
well
all
right
more
about
that
in
a
sec,
okay,
so
another
change-
that's
happened
in
jit,
Builder
2,
since
the
last
time
I
talked
to
you.
If
you
remember
any
of
this,
so
the
code
base
for
jit
Builder
2
used
to
have
a
bunch
of
jit
Builder
calls
sprinkled
throughout
it
everywhere.
B
So
every
type
and
every
operation
knew
how
to
make
jit
Builder
calls
to
to
produce
that
the
Ayah
to
produce
code
associated
with
those
things
so
to
manage
values
of
certain
of
the
of
those
types
to
create
constants
of
those
types
as
well.
As
you
know,
the
operation
like
what
does
it
mean
to
do
an
ad?
What
does
it
mean
to
do
a
load?
B
What
does
it
mean
to
do
a
sub,
and
all
of
that
was
sprinkled
throughout
the
whole
compiler
and
I
didn't
like
it
and
I
got
annoyed
with
it
and
decided
that
I
wanted
to
have
a
jit
Builder
extension
that,
where
all
of
the
details
of
jit
Builder
were
hidden
away
inside
that
extension,
so
that
in
principle,
if
you
didn't
want
to
use
jit
Builder
or
say
you
wanted
to
use
the
Omar
compiler
directly
or
say
you
wanted
to
use
llvm,
you
could
load
an
extension
that
would
provide
that
support
without
having
it
to
have
it
all
sprinkled
throughout
the
code
base.
B
So
you
imagine
if
you
would
wanted
to
support
the
Omar
compiler
and
jetbuilder
and
llbm,
then
you'd
have
three
copies
of
all
of
that
code.
Sprinkled
all
the
way
through
the
compiler
and
everybody
creating
an
extension
would
have
to
add
the
their
support
into
those
things
in
order
to
be
able
to
be
generated
by
those
code,
generators
and
so
on,
and
so
everybody
would
basically
have
to
modify
the
whole
code
base
all
the
time
which
sucked
I
didn't
like
it.
B
So
so
the
the
idea
was
that
or
I
wanted
to
explore
the
idea
of
encapsulating
all
of
that
within
a
JB
extension
extension
and
then
that
four
was
a
forcing
function
on
some
of
the
extensibility
mechanisms
to
be
able
to
figure
out
how
you
could
do
that
and
yet
be
able
to
deal
with
the
fact
that
well
maybe
the
base
extensions
loaded
or
maybe
it's
not
maybe
the
function
extension
is
loaded
or
maybe
it's
not.
And
how
do
you
handle
that
so?
B
But
the
first
thing
that
it
does
is
it
creates
a
code
generator.
The
code
generator
is
something
that's
defined
in
the
in
the
core
of
jit
Builder
2.
But
it's
it
doesn't
do
anything.
It
just
defines
an
API,
so
the
first
thing
it
does
is
it
actually
creates
a
real
code.
B
Generator
object,
a
JB
code
generator
object
and
install
that
as
the
one
that
get
dispatched
so
that
if
anybody
calls
compile
and
asks
for
the
Cogen
strategy,
then
it
will
end
up
invoking
the
JB
code,
generator
object
and
in
fact,
if
there
were
multiple
extensions,
that
created
code
generator
objects,
it
could
do
all
of
them.
So
in
principle,
you
could
imagine
a
really
interesting
world
where
you
load
a
JB
extension
and
an
llvm
extension,
and
it
generates
code
for
both
of
them,
and
then
you
can
compare
on
the
fly
on
in
memory.
B
What
the
differences
are
between
those
two
things
or
you
could
run
each
one
and
compare
the
performance
of
them
or
you
could.
You
know
selectively
do
that,
for
you
know
whatever
compile
units
you
want,
but
for
now,
let's
just
imagine
a
world
widget
Builder.
B
Also
when
this
extension
gets
created,
it
kind
of
it
registers
itself
and
I'm
not
going
to
go
into
details
and
how
it
does
this,
but
it
registers
itself
to
be
notified
when
other
extensions
are
created
so
that
it
can
watch
and
see.
Did
the
base
extension
get
loaded.
Did
the
funk
extension
get
loaded?
B
Did
the
VM
extension
get
loaded
and
then
when,
if,
if
and
when
those
extensions
do
get
loaded,
it
can
install
specific
add-ons
like
mix-ins
onto
their
they're,
actually
called
extended
passes
but
passes
that
can
handle
the
IL
generation
for
those
extensions
all
right,
so
the
operations
That
Base
defines
the
JB
extension
knows
about
the
base.
Extension,
it
knows
which
operations
are
in
it
and
it
can.
B
It
has
a
way
of
dispatching
the
jit
Builder
calls
in
order
to
handle
the
IL
for
what
gets
created
by
the
base
extension
and
similarly
for
the
funk
extension.
Similarly
for
the
VM
extension,
which
I
haven't
talked
about
yet,
but
hang
on
to
that
for
a
sec,
so
the
JB
code
generator
object
basically
just
walks
over
the
Intermediate
Language
that
gets
produced
as
part
of
build
IL
and,
and
it
makes
jit
Builder
calls
in
order
to
generate
native
code
by
the
Omar
compiler.
B
So
the
jb2
has
been
doing
this
forever,
but
it's
it's
now
been
kind
of
rearranged
so
that
it
actually
does
dispatching
through
the
extension
objects
to
be
able
to
to
make
sure
that
the
eye
all
gets
handled
by
all
these
little
objects
that
the
JB
extension
is
creating.
B
This.
This
whole
extension
at
some
point
will
be
supplanted
by
a
direct
Omar,
compiler
extension
I.
Don't
know
why
there's
no
space
there
so
that
it
won't
actually
use
jit
Builder
as
an
intermediary
right.
So
Chip
Builder
is
really
just
a
it's
a
a
very
simple
way
to
generate
code
that
should
Builder
2
leverages
to
generate
code.
But
what
should
be
really
happening
is
that
all
of
the
code,
that's
in
jit
Builder
that
allows
you
to
translate
those
code
into
Omar
or
Testarossa.
B
Il
should
really
be
in
its
own
extension
in
in
jet
Builder
2,
so
that
it
can
directly
go
to
the
Omar
compiler
code
and
I
think
we'll
have
a
an
ability
to
do
that.
A
lot
better,
because
it's
it's
really
a
code
generation
step.
It's
not
a
pass-through
API,
so
you
don't
just
see
the
API
calls
as
they're
as
they're
happening.
You
see
the
whole.
You
can
look
at
the
whole
code
and
know
what's
the
best
way
to
generate
code
for
for
all
of
this
stuff
together.
B
Yeah
and
then
another
one
that
exists
is
the
VM
extension.
So
this
one
was
this:
one
I
haven't
had
before
I,
don't
think,
but
basically
it's
the
virtual
machine,
State
and
virtual
machine
register
and
virtual
machine
operand
stack
and
bytecode
Builder,
which
is
all
the
facilities
that
make
it
easier
to
write,
jit,
compilers
and
privatize,
basically,
the
virtual
machine
state
as
you're
as
you're
writing
the
compiler.
B
So
you
know
our
the
web
assembly
jit,
John's,
T4,
JavaScript
thing
the
Lua
jit
all
of
the
Jets
that
we
use
leverage
this
facility,
these
kinds
of
facilities,
the
only
one
I
haven't
implemented,
is
virtual
machine
operand
array
just
like
in
the
first
time,
I
built
chip
Builder,
it's
left
as
an
exercise
for
an
Intrepid
contributor,
but
basically
this
handles
all
the
modeling
of
on
privatization
of
the
state
and
and
ends
up
generating.
B
You
know,
IL
that
corresponds
to
the
the
use
of
things
like
the
all
brand
stack
without
actually
using
the
Opera
in
stock,
and
it
depends
on
the
base
extension
and
on
the
function.
Extension
at
some
point
yeah
at
some
point.
I
did
have
that
comment
here,
but
I
also
added
this
of
in
and
expanded
on
that
point.
That
was
the
last
one
on
that
thing.
So
there
are
some
other
extensions
that
are
still
under
development
here,
there's
complex,
which
is
used
to
support
complex
values.
B
B
B
I'm
working
on
this
right
now
as
the
sort
of
next
thing
that
I'm
going
to
get
done
and
then
I
have
sort
of
some
proposed
things
that
I'm
thinking
about
as
sort
of
future
directions
here,
so
Sim
is
kind
of
like
the
core,
some
of
the
core
functionality
of
debug,
basically
to
help
you
the
the
idea
here
is
that
you
could
simulate
simulate
the
operation
of
Opera
of
simulate.
B
What's
going
to
happen
when
an
operation,
an
IL
operation,
runs
and
provide
ways
for
the
compiler
to
figure
out,
for
example,
what
a
constant
result
if
you
have
an
operation
that
has
all
constant
operands
and
it
has
no
external
state
that
it
depends
on
you
know
what
value
does
that
produce?
B
A
GC
extension
is
one
that
I've
been
wanting
to
do
for
a
long
time,
but
just
haven't
gotten
around
to
it.
It's
basically
support
integration
with
the
omrgc
or
another
garbage
collector.
You
know
the
idea
would
be
to
introduce
a
managed
address
type
which
you
could
then
allocate
objects
of,
and
that
would
be
managed
by
the
GC
and
so
you'd
know
to
generate
stack
maps
and
and
other
things
register,
Maps
I
guess
in
principle
two.
B
This
would
require
a
lot
of
integration
with
the
Omar
compiler
as
well,
in
order
to
get
that
working
and
that's
kind
of
not
a
not
a
path
that
I've
gone
down
yet.
But
it's
it's
a
direction
that
I'd
like
to
get
into
and
then
interpreter.
Builder
is
kind
of
the
big
one
that
I
really
love
to
get
to,
which
is
essentially
a
compiler.
That's
designed
to
simplify
the
creation
of
interpreter.
So
you
start
from
a
virtual
something
more
like
a
virtual
machine.
B
State
description
and
I'd
like
to
set
up
by
code
operators
and
and
Abstract
away.
What's
the
structure
of
The
Interpreter
and
have
The
Interpreter
Builder
like
this
compiler,
be
able
to
essentially
construct
an
interpreter,
and
you
know
use
it
to
even
automatically
generate
a
jit
compiler,
because
it
knows
what
all
the
byte
codes
do
and
you
get
a
simple
chip
compiler
out
of
it
or
a
simple
tracing
data
compiler
or
Etc,
and
you
could
do
different.
You
can
generate
different
kinds
of
interpreters.
You
could
do
switch
based
interpreters.
B
You
could
do
threaded
interpreters,
you
can
all
you
can
sort
of
make
that
the
the
mechanics
of
actually
arranging
all
of
those
things
you
could
do
it
all
automatically
and
then
you
could
even
design
compiler
passes
analyzes,
slash
improvements
that
could
enhance
the
design
of
The
Interpreter
that
are
specifically
know
that
they're
generating
an
interpreter.
B
B
We
do
still
have
15
minutes.
So
I'm
gonna
do
a
very
quick
high
level
overview
of
extensibility
in
jb2,
some
of
which
is
fairly
standard
stuff,
but
the
dynamic
extensibility
stuff
and
the
support
for
dynamic
mix-ins
and
extend
passes
that
I
talked
about
are
referenced
and
talked
a
little
bit
about
earlier.
B
I'll
give
a
little
bit
more
detail
on
this,
but
I
for
a
detailed
talk
through
this
I'm
going
to
have
to
do
another
presentation
because
there's
just
not
enough
time
to
go
through
at
all,
so
the
static
extensibility
mechanisms
are
all
just
basically
C
plus
plus
mechanisms,
and
this
is
all
fairly
standard
stuff.
So
you
know,
inheritance
can
be
used
when
the
new
capability,
if
you're,
extending
a
compiler
and
you're,
creating
a
new
capability
and
you're
going
to
be
allocating
the
new
thing
rather
than
the
base
class.
B
Then
that's
a
place
where
inheritances
is
appropriate
right.
So
the
examples
here
are
function.
Subclasses
compile
unit
with
the
expectation
that
function
objects
are
going
to
be
allocated
rather
than
directly
allocating
compile
unit
objects,
and
you
use
Virtual
functions
all
over
the
place
so
that
even
things
that
are
get
that
get
past
a
compile
unit
can
actually
have
their
behavior
overridden
by
what
function
defines
and
so
on.
B
The
the
or
you
know
the
follow-on
example
is
that
the
virtual
machine,
the
VM
extension,
actually
defines
a
VM
function,
subclass
a
function
with
the
expectation
that,
if
you're
going
to
use
that
functionality,
you
allocate
VM
function,
objects
and
that
those
are
going
to
get
allocated.
Now
the
because
the
compile
unit
is
a
nice
case
because
it's
completely
outside
of
the
compilation,
so
not
nothing
inside
the
compiler
actually
allocates
compile
units.
B
It's
things
that
the
external
user
of
the
compiler
is
going
to
is
are
going
to
allocate
so
there's
no
example
within
jit
Builder
2,
where
a
compile
unit
gets
allocated
and
then
passed
around.
So
there's
you
don't
have
to
extend.
You
don't
have
to
find
some
way
of
adding
your
extension
capability
into
those
kinds
of
objects,
but
that's
not
the
case
for
everything
in
the
compiler.
So
so
you
know
inheritance
Works,
where
it
works,
but
it
doesn't
work
for
everything.
B
Similarly,
composition
can
be
used
when
you
want
that
specific
object
and
you
don't
really
want
it
to
be
extended
in
any
way.
So
the
the
best
example
here
is
list
which
just
embeds
a
list
object
directly
in
something,
and
you
don't
really
expect
somebody
to
create
a
different
kind
of
a
list
and
want
it
to
be
used
instead
of
that
list.
B
Static
polymorphism,
which
we
use
in
the
Omar
compiler
in
a
variety
of
places,
isn't
specifically
prevented,
but
not
really
favored
and
that's
mostly
because
I
want
this
extensibility
to
be
more
dynamic
in
nature
and
not
really
statically
locked
in
place.
I
don't
want
you
to
have
to
build
it
a
particular
way.
I
want
you
to
be
able
to
assemble
the
compiler
that
you
want
dynamically.
B
This
is
probably
not
going
to
go
well
because
I've
been
writing
these
slides
very
close
to
this
actual
presentation,
but
let's
go
through
it
and
see
if
we
can
at
least
give
you
a
flavor
for
how
it
works,
if
not
the
sorry,
not
how
it
works,
how
it
gets
used
or
how
it
looks
in
a
code
base
as
opposed
to
how
it
actually
works.
So
there
is
a
dynamic
extension
mechanism
that
enables
allows
you
to
add
capabilities
to
existing
objects.
B
So
even
if
the
jit
builds
are
two
allocates
I'm
going
to
go
right
into
the
example,
even
if
jit
Builder
code
allocates,
for
example,
a
compiler
object
as
part
of
the
compile
process,
it's
actually
doing
a
new
compiler.
Sorry,
new
compilation
object,
so
there's
no
way
of
adding
anything
to
that
compilation
object
dynamically
because
it's
specifically
allocating
a
compilation
object.
It's
not
sort
of
deferred
to
say
which
type
of
compilation
object.
Would
you
like
you
can
do
that?
B
But
it's
a
it's
a
different
approach
to
doing
it
and
in
particular
you
might
not
know
like
different
extensions,
might
get
loaded
and
some
of
them
might
need
to
add
different
things
into
compilation,
so
you
don't
want
them
to
compete
right.
So
if,
if
the
base
extension
wants
to
add
something
to
compilation
and
the
function
extension
wants
to
add
something
into
compilation,
inheritance
becomes
a
really
difficult
way
to
manage
that,
because
you've
got
two
things
that,
like
the
art,
do
you
have
both
base
and
function?
Do
you
just
have
base?
B
Do
you
have
function?
Do
you
right?
What
are
you
extending
so
inheritance
doesn't
work
very
well.
So
jit
Builder
2
provides
a
mechanism
which
I'm
not
going
to
go
into
detail
on
how
this
works
in
this
talk,
but
it
allows
you
to
attach
what
I
call
add-on
objects
to
existing
other
objects
and
there's
a
way
of
registering
to
be
notified
of
when
certain
things
get
allocated
and
so
on,
and
and
it's
it's
quite
interesting
and
it
actually
ends
up
being
quite
easy
to
use
in
the
end.
B
But,
as
you
might
expect,
there's
some
performance
overheads
to
be
expected.
So
it's
not
something
you
want
to
use
arbitrarily
or
or
whimsically,
but
one
example
is
the
base
extension
which
attaches
an
object
called
a
base,
compilation
add-on
to
all
comp.
Any
compilation
object
that
gets
allocated.
It
creates
a
corresponding
base,
compilation,
add-on
and
in
that
add-on
object.
B
Basically,
it
includes
some
containers
to
maintain
the
set
of
pointer
types
that
have
been
created
in
a
set
of
struct
types
that
have
been
created
so
that
across
the
compilation
you
don't
end
up,
creating
multiple
copies
of
pointer
to
n32
it
can
and-
and
anybody
can
access
those
types
by
if
they're
past
a
compilation
object.
You
can
do
this.
B
Oh
sorry,
so
the
first
one
is
how
it
gets
allocated
right.
So
when
you
allocate
a
base
compilation
out
on
an
object,
one
of
the
things
that
gets
passed
in
is
the
the
root
object.
The
comp-op,
the
the
comp
object
that
it's
corresponding
to
and
then
you
can
just
do
comp
attach
law
of
this
type
and
it
there's
some
magic
in
there
to
say
to
recognize
that
it's
attaching
an
object
of
this
type
and
and
this
is
it
and
then
later
on
anybody
who's
passed
a
comp
object.
B
You
can
just
do
comp
add-on
and
pass
that
type
and
you'll
get
that
object
back,
and
you
can
only
add
on
one
of
a
particular
type.
So
it's
a
little
bit
Limited
in
that
standpoint,
but
it's
basically
a
way
of
saying:
hey,
store,
one
associate
one
of
these
with
this
object
and
then
later
on,
you
can
get
the
thing
that
you've
got
out.
B
So
you
have
to
know
that
you're
using
the
base
extension
on
both
ends,
but
it
can
pass
through
a
bunch
of
stuff
that
has
no
idea
that
there's
a
base
extension
loaded
or
or
that
it's
present
and
so
extension,
the
extension
objects
when
they
get
created
they
can
they
can
register
to
get
notified
when
things
are
allocated
so
that
add-ons
can
be
attached
Etc.
B
So
it's
it's
kind
of
neat
and
it's
it's
been
hanging
together
for
all
the
stuff
that
I
did
with
with
jit
Builder
2
and
with
the
base
compilation.
Sorry
with
the
bass
extension
so
far,
so
I'm
optimistic
about
this,
but
maybe
when
I
go
into
more
detail
on
this
in
part
two,
we
can
have
a
bigger
discussion
about
this.
B
So
so
when,
when
the
GB
extension
gets
loaded,
it
basically
has
a
model
of
delegating
the
handling
of
Il
components
to
the
extension
that
introduces
that
aisle
component,
so
similarly
to
when
you're
building
IL,
you
have
to
call
to
the
extension
object
to
say
it's
the
base
extension
that
knows
how
to
create
an
ad
operation
that
operation
when
it
gets
created,
also
stores
the
base
extension
object
on
it,
so
that
when
other
things
pick
up
that
operation,
they
can
say
who's
the
extension
that
created
you
and
then
there's
a
way
of
delegating
an
arbitrary
service
to
that
extension.
B
Object
using
a
similar
kind
of
mechanism
to
the
to
the
add-on
notion,
but
it's
slightly
different,
so
I
call
them
extended,
passes
and
I
I
created
this
one
first,
so
I
haven't
yet
figured
out
if
I
can
just
collapse
these
two
into
the
same
thing,
but
they
are
slightly
different
too.
B
So,
let's
see
do
I
really
want
to
go
into
detail
here.
It
might
not
be
the
right.
It
might
be
the
right
moment,
because
we're
kind
of
at
the
end
of
the
talk
I've
been
going
for
quite
a
long
time
here.
So
maybe
I'll
just
defer
this
to
say
there
is
this
notion
that
you
can
do
this.
So
this
is
how
the
JB
extension,
the
jit
Builder
extension,
works
that
it
uses
this
facility
to
to
delegate
the
handling
of
of
code
generation
to
the
various
extension
objects.
B
I
have
two
more
topics
to
kind
of
cover
quickly.
I've
talked
about
both
of
them
previously,
but
I
just
wanted
to
remind
everyone
about
the
integration
that
I
have
done
so
far
for
Omar.
So
so
all
of
this
right
now
builds
against.
B
Like
uses
the
Omar
build
system
in
moving
my
private
copy,
so
the
way
that
I
I
did
this
was
I,
took
the
chip
Builder
code
base,
which
is
a
an
ex
compiler
extension
in
the
Omar
compiler
and
I
made
a
separate
copy
of
that
called
jv2,
which
allows
me
to
evolve.
Jit
Builder,
independently
of
the
actual
jit
Builder
that
other
people
might
depend
on.
B
I
haven't
had
to
do
very
much
of
that,
so
it
might
not
be
necessary,
but
anyway
I've
done
it
and
then
I
took
out
anything
that
wasn't
specifically
needed
virgin
filter
two,
which
is
basically
the
core
to
Builder.
Api
I
created
an
API
specifically
for
jb2
under
it,
which
I
called
API,
not
very
imaginative,
I
know,
but
that's
where
it
is,
and
then
all
the
jit
Builder
2
implementation
is
underneath
API
and
then
underneath
so
the
core
stuff
is
all
in
the
API
directory.
B
And
then
there
are
directories
for
each
of
the
extensions
underneath
that
so
base
Funk
VM
core.
All
that
stuff
are
actually
core
extensions,
mod.
It's
it's
in
the
main,
API
directory
button
and
then
I
added
a
build
flag,
Omar
jb2
to
cmake.
So
you
can
build
it
and
right
now
gym.
Builder
2
just
builds
everything,
that's
there,
so
it
includes
all
the
all
of
the
extensions,
probably
should
have
their
own
things,
but
it
doesn't
right
now.
B
Also
each
one
of
the
extensions
has,
except
for
Funk
right
now,
has
tests
that
are
written
against
them
that
try
to
test
a
lot
of
their
functionality
so
base.
B
Does
a
242
different
tests
of
various
combinations
of
things
that
it
defines
it's
not
complete,
but
it's
better
than
nothing
and
so
you're
and
it
automatically
adds
those
tests
into
the
into
the
build
so
that
if
you
run
C
test,
it
runs
there's
about
six
of
them
that
run
at
the
beginning
and
right
now,
I've
got
it
set
up,
so
it
runs
every
one
of
them
under
Val
grind
to
verify
that
there
are
no
allocation
leaks
at
all
through
any
of
the
any
of
the
tests.
B
So
it
took
me
a
while
to
get
there,
but
but
they
all
are
currently
running
with
no
allocation
leaks
whatsoever
and
it
continues
to
test
those.
It
runs
them
under
the
sort
of
very
I
forget
the
name
of
the
option,
but
it's
like
extra
detailed
leak
checking
runs
that
it
does.
It
takes
about
20.
Well,
it
takes
about
15
seconds
to
run
the
base
test
because
it's
the
biggest
one
Anderson
there's
a
couple
of
side
notes:
I've
used
a
different
code
format
for
chip,
Builder,
2.
B
kind
of
like
I,
was
testing
out
sort
of
I.
Guess
the
how
I
liked
the
code
format
that
we
talked
about
in
one
of
our
earlier
designs,
so
it
uses
four
spaces
and
it
doesn't
use
the.
B
Curly,
brace
on
a
separate
line,
approach
and
stuff
like
that
anyway,
I
I,
I'm,
quite
fond
of
it
I
would
say,
but
I
also
didn't
find
that
it
was
like
it
didn't,
take
me
long
to
adjust
one
way
or
the
other.
So
it
wasn't
like
a
magical
productivity
enhancement
for
me,
but
it
was
but
I
I
do
find
the
code
structure
to
be
quite
nice
anyway
and
and
right
now,
extensions
are
all
very
Linux
focused.
So
it's
the
deal
was
being
used
as
the
thing.
B
So
it's
not
exactly
cross-platform
at
this
point,
but
you
know
these
are
things
that
could
be
enhanced.
Obviously,
and
I
did
talk
about
one
of
my
one
of
my
previous
ones
about
maybe
moving
away
from
STL
containers,
so
I've
taken
over
steps
to
move
away
from
STL
I,
don't
know
why
list
T
isn't
bloated
there.
It
should
be
so
I've
converted
most
of
the
internal
STL
container
container
container
use
to
to
using
an
internal
implementation
that
I
wrote
and
that
I
wrote
tests
against.
So
there's
the
list.
There's
a
an
iterator
class.
B
The
string
only
appears
in
one
place
and
the
only
one
that
I
have
not
tackled
yet
is
standard
map
which
is
going
to
be
a
fun
one,
but
I'll
get
there
eventually
I
just
haven't,
haven't
peeled
that
one
out
yet
so,
just
to
give
you
a
flavor
for
how
the
iteration
model
works,
the
iterators
are
passed
around
by
value
and
they
they
actually
create
a
copy
of
the
of
the
the
list
that
they
that
they
iterate
over.
So
the
iterator.
Can
you
ask
for
iterator?
B
It
could
be
done,
I
mean
I,
I'm,
actually
I'm,
actually
not
100.
Sure
I
was
correct
right
now
that
it
copies
the
iterator
I
know
it
does
in
certain
cases,
but
I'm,
not
sure
that
it
does
in
all
cases
right
now,
I'm
pretty
sure,
I
copied
things
because
I
didn't
want
them
to
I,
wanted
them
to
be
immutable,
but
it
also
does.
B
It
also
does
automatically
detect
if
the
underlying
container
changes
between
when
you
allocated
the
iterator
and
when
you
access
it
so
every
time
you
access
the
iterator,
it
goes
back
to
the
base
container
and
and
verifies
that
it
hasn't
changed
and
it
does
that
by
basically
every
time
it
changes
at
increments
of
counter
inside
the
container.
Basically,
and
then
it
just
caches
the
value
when
it
created
the
iterator
and
it's
it's.
The
values
in
the
container
is
different
than
it
knows.
It's
changed,
so
it's
been
mutated.
B
B
B
B
The
end
of
part,
one
so
I'll
I
I
have
an
intention
to
come
back
with
a
part
two
where
I'll
talk
more
about
allocators
and
and
go
into
more
details
on
the
dynamic
extensibility,
because
I
think
it's
a
pretty
interesting
area
and
I
didn't
have
time
to
cover
it
very
well
and
in
fact,
I
wrote
this
slide
three
minutes
before
the
start
of
this
presentation.
So
you
can
tell
how
quickly
I
put
some
of
this
together.
A
Right
thanks
Mark,
which
we'll
pause
there
for
questions.
If.
B
Yeah
sorry
I
didn't
intend
to
take
up
all
of
the
time.
So
if
anybody
wants
to
reach
out
to
me
with
questions,
I'd
be
happy
to
to
get
into
discussions
with
this
offline
or
or
we
can
leave
it
till
the
next
one
of
these
and
didn't
work,
censor.
A
Don't
okay!
Well,
if
there's
no
questions,
I
want
to
thank
Mark
for
a
very
good
introduction
to
dip
Builder
2
and
look
forward
to
part
two
in
the
coming
weeks.
Months
weeks.
Hopefully
awesome
all
right
thanks!
Everyone
for
attending
see
you
next
time.