►
From YouTube: OMR Architecture Meeting 20221020
Description
JitBuilder 2.0 Update [ @mstoodle ]
A
Snafu
is
associated
with
this
talk,
and
hopefully
people
still
enjoy
it
all
right.
So,
in
terms
of
an
outline
I
mean
this
is
this
is
really
just
an
incremental
update.
So
there's
nothing
really
earth-shattering.
That's
happening
here.
The
the
bulk
of
what
I
wanted
to
talk
about
today
on
the
meeting
was
around
Omar
and
cmake
integration.
A
So
the
fourth
topic
there,
but
there
are
a
few
other
things
that
I
wanted
to
give
some
updates
on
and
just
kind
of
directional
sort
of
things
that
might
be
happening
with
with
jb2
as
as
I
go
forward
here
and
just
things
that
I've
been
developing.
So
you
know
what's
there
so
the
first
one
on
this
list
is
that
I
in
jb2
I
have
been
using
kind
of
STL
containers
to
for
lists
and
vectors
and
and
and
so
on,
in
various
aspects
of
the
IL
data
structures.
A
I
might
be
moving
away
from
that
now.
I've
made
one
first
step
in
that
direction
because
it
made
a
lot
of
sense
for
me
and
hopefully
most
people
have
at
least
a
basic
idea
in
their
heads
of
jb2.
I
didn't
have
to
give
a
refresher
on
it.
Maybe
I
should
have,
but
nonetheless,
one
of
the
fundamental
parts
of
the
jbil
is
an
operation
which
is
kind
of
what
you'd
think
it
would
be
just
from
the
name.
A
A
You
could
iterate
through
them,
but
it
made
sort
of
it
made
for
sort
of
an
awkward
API
for
trying
to
walk
through
the
the
entire
graph
of
like
a
control
flow
graph,
because
you're
flipping
from
Builders
to
operations
all
the
time
and
and
the
operation
in
order
to
walk
through
a
builder.
You
needed
an
iterator
and
if
you
ever
had
to
walk
away
from
like
if
you
had
an
operation
that
jumps
away
to
someplace
else
in
order
to
continue
iterating.
A
You
kind
of
have
to
remember
where
your
iterator
was
in
the
Builder
that
you
came
from,
so
that
when
you
came
back,
you
could
restart
in
the
right
place
and
and
and
so
you're
always
kind
of
flipping
back
between
which
Builder
am
I
in
and
what
is
its
iterator
and
and
where
am
I
iterating
in
it.
So
I
I
decided
in
the
end
that
it
would
be
much
easier
if
operation
just
became
sort
of,
embedded
and
embedded
doubly
linked
list,
and
that
makes
things
a
lot
actually
a
lot
easier.
A
Actually,
because
that
you
can
basically
a
program.
Point
can
now
be
represented
as
a
pointer
to
an
operation,
and
from
that
from
that
pointer
you
can
kind
of
walk
up
or
down
or
forwards
or
backwards
in
the
control
flow
graph
very
easily.
You
can
remember
where
you
came
from
with
by
just
storing
a
pointer
to
an
operation
and
that
operation
can
be
used
to
continue
an
iteration
in
either
direction
inside
the
inside.
A
The
Builder
object
that
it
comes
from
and
and
since
an
operation
has
a
parent
pointer
to
the
Builder
that
contains
it,
you
can
always
kind
of
go
up
or
or
go
to
the
other
Builder
operation
builders
that
might
be
referenced
by
an
operation.
So
anyway,
it's
it's
kind
of
made
things
a
lot
easier
for
walking
around
inside
or
around
the
the
IL
constructs
here
and
I
confess.
A
I
didn't
really
find
very
much
use
from
the
iterators
themselves
other
than
the
fact
that
you
could
just
kind
of
ask
for
one
and
they
need
to
read
through
it.
But
I
did
find
that
the
out
the
iterator
data
structure
kept
permeating
all
over
the
place
and
and
and
trying
to
remember
it.
All.
The
time
was
was
kind
of
a
pain
in
the
butt
so
anyway.
A
So
this
this
simplified
things
and
I
think
it's
a
I
mean
it
on
the
one
sense
you'd
say:
well,
the
list
is
kind
of
polluting
the
the
the
purity
of
the
operation,
but
actually
I
think
this
notion
that
operation
star
is
a
like
a
pointer
to
an
operation.
Is
a
program.
Point
actually
makes
the
fact
that
it's
it's
in
this
doubly
linked
list
and
also
has
a
parent
pointer
to
its
Builder
I.
Think
that
actually
is
in
essence
of
a
fairly
fundamental
aspect
of
the
operation
right.
A
It
makes
it
into
a
program,
point
and
I
think
that's
a
very
valuable
kind
of
abstraction
for
for
it,
so
I
I
think
I'm
going
to
keep.
This
I
also
have
to
say
that
I'm
I
haven't
generally
been
a
big
fan
of
what
the
STL
allocators
have
required
in
omr,
as
general
I
mean
I,
know,
there's
I
know,
there's
there's
some
advantages
to
being
able
to
use
STL
containers
and
the
iterators
and
so
on
as
part
of
the
Omar
compiler.
A
A
One
of
the
biggest
new
things
that
I've
added
since
the
last
time
I
talked,
is
that
I've
brought
in
more
of
the
original
API
from
jetbuilder,
one
that
was
used
for
virtual
machine
State
manipulation,
so
I've
defined
a
VM
extension,
which
is
called
the
m
and
VM
extension,
which
adds
the
bytecode
builders
and
the
virtual
machine.
State
and
three
of
the
virtual
machine
state
implementations,
Register
register
instruct
and
operand
stack.
I
didn't
do
operand
array
yet,
but
it
should
be
a
fairly
since
it
was
a
fairly
straightforward
modification
to
operand
stack.
A
It
should
be
a
fairly
straightforward
modification
to
bring
it
into
this
scheme
as
well.
I
took
the
two
code,
samples
that
already
existed
in
jetbuilder,
one
for
for
VM
registers
and
all
brand
stock
and
turned
them
into
tests
that
are
in
the
VM,
slash
test
directory
now
and
those
kind
of
get
automatically
added
to
the
tests
that
are
run
for
jetbuilder
too.
If,
if
it's
ever
built,
it's
an
extension
like
any
other
one,
so
it
can
be
loaded
optionally
by
a
compiler.
A
So
if
a
compiler
needs
these
VM
extensions,
it
can
load
them
if
it
doesn't
need
them.
It
doesn't
have
to
load
them
the
load,
the
load,
the
statement
that
you
need
in
order
to
load
it
I've
shown
there
as
an
example,
is
compiler.load
extension
and
using
the
the
VM
extension
type
to
automatically
cast
for
you,
I
guess.
All
of
so.
A
So
the
VM
extension
depends
on
the
base
extension.
Basically,
I
did
introduce
a
new
yeah
all
right,
so
this
this
may
be
a
controversial
thing
here.
So,
if
you
remember
from
my
earlier
presentations,
jb2
is
not
a
static
single
assignment
IL.
It
could
be
used
to
implement
an
SSA
IL,
but
it
is
currently
not
an
SSA
IL
like
it's.
Not
enforced,
it's
not,
it
doesn't
require
you
to
to
do
things.
A
However,
values
are
kind
of
implicitly
SSA
in
that
you
define
it
once
and
then
you
can
and
then
you
you
can
use
it,
but
you
can't
you're
not
supposed
to
override
it.
However,
as
part
of
the
virtual
machine
State
support
in
jet
Builder
one,
there
was
this
little
service
that
nobody
was
supposed
to
use,
except
for
the
virtual
machine,
State
implementation,
which
would
copy
over
the
of
a
value
from
one
from
one
value
on
top
of
another
one.
A
Basically,
so
that
you
could
reuse
the
all
of
the
information
about
where
that
value
is
stored,
it
could
be
reused
by
jit
Builder
one.
Now
it
was
a
little
bit
more
important
than
jit
Builder
one,
because
it's
a
jet
Builder
one
is
a,
is
a
pass-through
API.
So
it's
it's
actually
generating
Omar
compiler
IL,
as
you
make
calls-
and
you
don't
know
at
the
point
of
a
use
of
a
value.
You
don't
know
that
you've
generated
the
code
for
all
of
the
definitions
that
would
need
to
reach
that
use.
A
So
jit
Builder
one
kind
of
head
to
head
to
be
able
to
do
this
thing,
because
the
the
most
normal
way
that
you
would
you
would
you
would
be
translating
code
you'd,
you'd
Define,
some
like
you'd
push
something
onto
an
operand
stack
on
One
path
and
then
you'd
flow
down,
and
you
and
and
some
use
later
on
would
pop
it
off
the
operand
stack
and
use
it.
But
then
you,
you
might
be
translating
some
other
control
flow
path
which
pushes
a
different
value
onto
that.
A
That
position
in
the
All
Brand
stack
and
then
creates
a
control
flow
Edge
that
that
joins
in
the
in
in
the
middle
of
the
previous,
deaf
and
use.
So
in
that
sense,
you've
already
generated
the
code
for
the
first
Def
and
the
first
use.
So
you
really
have
to
be
able
to
modify.
You
know
the
values
that
are
coming
in
on
this
new
flow
path
that
just
got
created
so
that
it
can.
It
can
flow
into
the
code
that
you've
already
of
the
use
that
you've
already
built.
A
Now,
that
problem
doesn't
exist
in
jetbuilder
2
per
se,
because
you
in
jit
Builder
2,
you
generate
all
the
IL
and
then
all
the
IL
gets
translated
later
on,
but
for
now
it
operates
a
lot
like
jetbuilder
one
does
so
to
to
kind
of
I'll
Loosely
use
the
word
formalize,
but
I.
Don't
think
this
is
a
very
formalized
thing
yet
I
I
I
created
a
pseudo
operation
called
merge
def,
which
allows
you
to
do
this
kind
of
the
same
kind
of
merging
thing.
A
The
idea
is
essentially
that
it
lets
you
create
a
deaf
use.
Web
like
here
are
all
the
definitions
that
use
this
web
or
you
can
it's
almost
like
a
value.
It's
a
way
of
instantiating
a
value
number.
If
you
like
right,
where
different
value
number
is
not
quite
the
right
word
either,
but
where
all
these
definitions
can
reach
this
use,
and
you
need
them
to
be
able
to
at
the
use
point
you
need
to
use,
you
can
only
reference
a
single
thing.
So
it's.
A
How
do
you
get
that
thing
and
and
and
have
all
of
the
different
definitions
come
together?
The
idea
here
is:
is
that
it's
not
like
freewheeling,
you
can,
you
know,
go
and
combine
definitions
all
over
the
place
and
and
generate
all
kinds
of
crazy
things.
The
idea
would
be
to
limit
this
so
that
it's
sort
of
similar
in
nature
to
what
you
would
do
with
SSA
in
a
way.
A
A
Else
to
say
here,
you
know
that
last
comment
is
just
basically
it's
it's
kind
of
replicating
a
bunch
of
support
that
was
in
jv1
that
was
very
useful
for
building
different
compilers,
so
it's
kind
of
important
infrastructure
for
people
who
are
who
have
used
jb1
in
the
past.
Most
people
who
were
right
using
jb1
in
the
past
were
taking
advantage
of
byte
code
Builder,
and
these
virtual
machines
State
functions
so
they're
now
available
in
jb2
for
use.
A
Along
the
same
lines,
I
started
making
an
explicit
complex
extension,
because
complex
was
one
of
the
examples
that
was
used
with
jit
Builder
one
as
a
sort
of
thing
that
you
could
introduce
in
digit
Builder
as
a
as
a
new
type,
but
it
was
always
hard
to
do
in
jit
Builder
one.
It
required
a
lot
of
effort
to
create
new
types
and
to
to
be
able
to
to
manipulate
and
reference
them,
and
it
was
kind
of
ugly.
A
A
So,
in
this
case,
the
the
idea
is
that
you've,
you've
got
this
thing
called
a
complex
type,
but
you
don't
have
direct
code
generation
support
for
it.
So
you
need
something
to
take
the
complex
all
of
these
uses
of
complex
types
and
all
of
the
operations
that
operate
on
complex
types
and
translate
them
into
lower
level
kind
of
Il
that
that
you
know
how
to
generate
code
for
right
as
a
sort
of
proof
point
for
being
able
to
do
more,
complicated
and
wicked
things
where
you
may
not
it's
it's.
It's
not
hard
to.
A
Imagine
writing
direct
code
generation
support
for
something
like
a
complex
type,
but
if
your
type
got
really
really
complicated,
then
you
might
not
want
to.
You
know
generate
code
directly
for
it.
Maybe
so
in
this
it's
sort
of
a
you
know,
testing
out
this
this
mechanism
and
it
drives
the
requirement
for
type
replacement,
so
type
replacer
is,
is
a
is
a
a
facility
that
I
talked
about
in
one
of
my
previous
talks
on
this,
where
it
again
it's
sort
of
a
semi-automatic
mechanism
for
replacing
user-defined
types.
A
It
brings
the
notion
that
a
user-defined
type
should
have
a
layout
defined
associated
with
it,
which
is
kind
of
like
the
physical,
it's
a
struct,
but
it
doesn't
have
to
be
as
strict,
but
it
usually
is
a
struct
which
sort
of
provides
the
physical
layout
for
the
various
bits
in
in
your
user-defined
type.
So
in
the
case
of
complex,
it's
a
struct
that
has
a
real
and
an
imaginary
part
and
and
has
whatever
float
whatever
size
float.
A
It
is
that
you
want,
in
this
particular
case
of
generalized
it
a
bit
from
how
I've
used
complex
in
the
past
and
then
and
then
the
type
replacer
kind
of
knows
that
whenever
you're
working
on
a
value,
that's
that
has
the
type
complex
or
complex
fluke.
32
say
that
that's
actually
two
float
32
is
one
that's
associated
with
the
real
part
and
one
that's
associated
with
the
imaginary
part,
and
it
can
sort
of
automatically
help.
You
translate
code
that
references,
you
know
a
complex
value.
A
It
will
automatically
help
you
carry
around
the
two
constituent
bits
and
then,
if
your
operations
are
very
very
straightforwardly
map
onto
the
the
different
bits,
then
it
will
automatically
translate
them.
So,
for
example,
an
ad
you
know
an
ad
just
adds
the
corresponding
real
bits
and
the
corresponding
imaginary
bits
together
and-
and
that
gives
you
your
result-
that
that
can
be
done
automatically
by
by
type
replacer.
But
something
like
multiply
or
the
more
complicated
like
magnitude
or
conjugate.
A
Those
ones
are
more
complicated
and
they
require
you
to
write
code
that
that,
basically
you
know
it
will.
It
will
apply
that
code
as
it's
doing
this
type
replacement
thing
to
to
inject
specific
sequences
that
deal
with
the
various
real
and
imaginary
parts,
and
it
provides
mechanisms
for
you
to
to
talk
about
those
those
intermediate
bits
while
you're,
while
you're
generating
the
code.
A
It
understand
how
to
deal
with
that.
So
I'm
not
going
to
talk
about
that
anymore,
because
it's
a
it's.
It's
not
quite
well
formed
in
my
head.
Yet
what
that's
going
to
look
like,
but
it's
it's
starting
to
give
me
ideas
in
that
space
and
that's
also
coming
up
in
I've,
also
been
most
recently
actually
I'm.
Not
going
to
talk
about
that.
A
Right,
okay,
so,
and
so
this
yeah,
so
this
is
really
just
the
same
complex
kind
of
types
that
I've
talked
about
in
the
past.
You
know
the
the
main
addition
here
is
that
I've
sort
of
templatized
a
complex
type
so
that
it
can
have
sort
of
a
a
different
base
type
and
it's
going
to
Define.
Both
complex
float,
32
and
complex
float
64..
A
A
It
didn't
actually
help
as
much
as
I
had
thought
it
was
going
to
when
I
started,
but
but
because
most
of
the
actual
underlying
support
for
jetbuilder
is
actually
in
the
Omar
compiler,
in
the
form
of
the
the
files
that
are
in
the
IL
gen
directory.
So
it
doesn't
actually
split
those
out
at
all.
But
nonetheless
there
are.
A
There
are
a
couple
of
things
that
you
can
do
differently
in
jit,
Builder
2,
when
you
do
this
and
it
sort
of
decouples
jit,
Builder
2
Evolution
from
jit
Builder
Revolution,
which
seemed
like
a
not
awful
story.
Given
that
we
have
a
number
of
compilers
that
were
built
on
top
of
jit
Builder
one
and
the
API
does
change
between
jit
Builder
1
and
jit
Builder
2.,
once
I
copied
everything
to
jb2
I
removed,
anything
that
wasn't
specifically
needed
so
lljb,
for
example,
I
removed
that
directory
now
from
jit
Builder
to
from
jb2.
A
It's
still
there
in
jit
Builder,
obviously
and
I'm,
not
saying
that
that
lljb
isn't
interesting
from
a
jb2
perspective,
but
it's
not
needed
for
the
jv2
implementation
right
now.
So
that's
I
was
trying
to
strip
out
anything.
I
didn't
need
I
created
a
new
directory
like
a
new
sort
of
top
level
directory
I,
guess
underneath
jb2,
which
I
just
called
API
and
I
totally
open
to
a
better
name.
A
I
couldn't
come
up
with
a
good
name
for
it,
so
I
just
called
it
API
and
then
I
put
all
of
the
jv2
implementation
underneath
this
API
directory
and
so
and
then
from
a
cmake
integration.
Standpoint,
I
added
a
new
ulmar
underscore
gb2
flag,
which
dictates
whether
gb2
gets
built
or
not.
It
does
require
that
you
build
the
Omar
compiler
still
because
it's
it
requires
the
Omar
compiler.
A
So
there
are
a
couple
of
side
notes
here
that
I
thought
might
be
of
of
interest,
so
I
have
not
been
using
the
Omar
compiler
code
format
for
jv2,
just
as
a
I
wanted.
I
wanted
to
have
a
more
personal
experience
with
using
the
the
sort
of
different
code
formats
that
we
had
discussed
in
the
context
of
the
other,
the
other
efforts
where
we,
where
we
talked
about
changing
the
code
format,
so
it
uses
sort
of
the
target
code
format
that
we
talked
about
more
or
less.
A
It's,
not
exact
and
I,
don't
enforce
it.
I
just
kind
of
manually
implemented
four
spaces
and
it
doesn't
use
the
curly
brace
formatting
that
that
the
Omar
compiler
uses
Etc.
So
it
and-
and
you
know,
I
I
just
wanted
to
see
what
the
code
would
look
like
and
I
would
say
largely.
The
code
is
at
least
as
readable
as
the
Omar
compiler
code
may
be
better
in
certain
ways,
and
certainly
no
certainly
no
harder
to
read
than
the
Omar
compiler
code
is
so
I'm
I'm.
You
know
even
even
more
in
favor
of
a
code
format.
A
Change
at
this
point
than
I
was
previously,
and
the
other
point
here
is
that
it's
really
a
Linux
platform
kind
of
thing
right
now,
so
it
it
assumes
libdiel
is
there.
So
that's
how
it
does
the
extension
loading,
so
it
it.
It
is,
it
is
a
little
bit
platform
specific,
it's
not
leveraging
any
of
the
any
of
the
the
the
port,
the
the
Omar
Port
library
at
all.
A
A
The
more
code
I'm
going
to
generate
and
the
bigger
a
code
drop
is
going
to
be
in
the
end
to
bring
this
into
Omar
I.
Would
say
it's
it's
kind
of
at
a
point
where
it's
quite
useful,
I
think
it'll
be
even
better
once
I
get
the
debugger
going,
which,
as
I
mentioned
I'm
in
the
process
of
doing
right
now.
A
So
I'm
kind
of
thinking
that
this
might
be
like
now
or
very
soon
from
now
might
be
the
right
time
to
talk
about
integrating
this
into
omr,
and
that's
one
of
the
other
reasons
why
I
went
down
this
path
of
trying
to
see
what
it
would
look
like
you
know.
Obviously,
there
are
pros
and
cons
of
of
doing
that.
A
So
it's
like
I,
on
the
one
hand,
I'd
love
to
get
this
into
the
project
so
that
more
people
can
help
me
with
it.
If
they
really
wanted
to
not
that
I'm
really
expecting
a
lot
of
help
there.
But
on
the
other
hand,
I
know
it's
going
to
be
effort
and-
and
it's
going
to
be
a
burden
to
the
committers
to
to
deal
with
people
changing
it.
A
A
A
I
can't
hear
you
just
to
confirm.
Okay,
thank
you.
Thanks,
Kevin
I
appreciate
that
all
right,
well,
I
I,
know
I'm
kind
of
hitting
people
point
blank
with
it.
So
I
guess
I'll
ask
everyone
to
kind
of
start
thinking
about
that
a
little
bit
if
you
can,
in
whatever
spare
time
you
can
afford
here
and
and
if
you
have
opinions,
feel
free
to
reach
out
to
me
and
we
can
discuss
a
greater
detail
or
maybe
we
can
come
back
and
discuss
it
at
the
the
next
Omar
architecture
meeting
or
something
like
that.
A
A
But
it's
kind
of
I
think
the
easiest
place
to
integrate
it
to
start
with,
and
then
then
I
can
work
on
breaking
it
apart,
so
that
it
can
parts
of
it
can
move
into
the
core
and
then
maybe
it
doesn't
have
to
necessarily
be
attached
to
functions,
which
are
things
that
get
introduced
in
the
base.
Extension
support
for
functions
that
is
as
I
mentioned,
contributing
to
Omar
is
a
big
question.
A
In
my
mind,
right
now
and
and
that
I've
asked
for
feedback
for
and
then
the
rest
of
the
points
here
are
really
just
different
kinds
of
things.
That
I
think
need
to
get
done
and
and
I'm
so
I've
sort
of
made
some
progress
on
some
of
these
as
I
went,
but
but
there's
and
some
of
them
have
completely
not
started
yet
so
I
guess
I
could
have
ordered
these
to
make
that
a
little
bit
more
obvious,
but
anyway
the
the
I'll
just
go
through
them
in
order.
A
So
right
now,
jb2
generates
native
code
by
making
jit
Builder
one
calls
right
it
after
you
generate
the
jit
Builder
2
IL,
once
you
request
that
it
be
compiled,
it
basically
walks
over
the
jit
Builder
to
Il
and
makes
jit
Builder
one
calls
to
actually
generate
Omar,
compiler
IL,
which
is
then
compiled.
So
it's
kind
of
a
it's
a
more
more
redundancy
than
is
needed
here
at
Builder.
There's,
no
reason
why
jit
Builder
2
could
not
be
directly
generated
by
the
Omar
compiler
IL.
A
In
fact
you
could
take
that
a
step
further
and
say:
there's
no
reason.
Nobody
sorry
there's
no
reason
a
person
Couldn't
Write
a
native
code
generator
directly
in
jetbuilder
too,
but
you
know
I
think
that's
not
a
direction
that
I've
that
I'm
likely
to
pursue
directly
myself
I
think
the
the
most
that
I
would
do
here
is
to
generate
code
directly
from
jv2
down
to
Omar,
compiler,
IL
and
I.
Think
Jeep.
A
You
can
do
a
better
job
doing
that
with
the
jit
Builder
IL,
because
you
can
see
all
the
IL
at
once
and
you
can
use
information.
You
can
glean
from
the
Builder
from
the
IL
to
generate
better
Omar,
compiler
IL
right
from
the
get-go
and
require
fewer
sort
of
cleanup
passes
than
jit
Builder
one
requires
so.
As
I
mentioned,
jit
Builder
one
is
really
a
pass-through
API.
So
it's
it
has
to
be
a
little
bit
conservative
in
how
it
generates
IL
so
that
it
it
can.
A
A
A
A
A
A
big
area
of
you
know
where
I've
been
trying
to
do
better
with
jb2
than
than
we've
done
historically
with
the
Omar
compiler
or
legit
Builder.
One
for
that
matter
is
to
be
able
is
to
write
more
unit
tests,
so
base
extension
has
a
fairly
I,
won't
say
complete,
because
it
there
are
certain
operations
and
types
that
are
very
well
tested
in
the
base
extension.
A
I
can't
remember
the
exact
number
I
computed
it
once,
but
it's
something
on
the
order
of
two
thousand
tests
and
each
one
of
those
is
an
individual
compilation
that
gets
you
know
it
compiles
something
and
runs
a
test
on
it
and
runs
multiple
tests
on
it
and
gets
results
and
verifies
that
they're
all
correct,
and
then
some
of
them
are
positive
tests.
Some
of
them
are
negative
tests
Etc.
A
So
it's
it's
a
it's
better
than
it
has
been,
but
it's
still
not
as
good
as
it
could
be,
and
what
I'd
really
like
to
do
here
is
is
is
spend
some
time
building
a
real
unit
test
framework
here.
That's
that
would
you
know
where
the
tests
for
operations
are
sort
of
implemented,
very
close
to
where
the
operations
themselves
are
implemented,
and,
and
so
you
could
maintain
them
and
fairly
represented
at
a
fairly
high
level.
A
So
you
wouldn't
need
to
you
know,
write
very
much
infrastructure
in
order
to
add
new
unit
tests
for
for
different
operations
right
now,
it's
pretty
ad
hoc
and
it
relies
a
lot
on
Macros
and
it
gets
pretty
confusing
to
see
what
the
again
it
it
does
a
lot
of
unit
tests,
but
it's
not
a
very
pretty
implementation.
I
wouldn't
say
I'm,
not
all
that
proud
of
it
other
than
the
fact
that
it's
there
writing
more
documentation
is
obviously
an
important
thing
for
this.
A
I've
started,
but
it's
at
a
quite
high
level
right
now,
it's
kind
of
like
when
I
get
when
I
when
I
don't
feel
like
writing
code,
but
I
feel
like
doing
something.
I'll
try
to
write
down
a
few
lines
of
documentation
in
various
places,
so
it's
kind
of
being
added
to
on
a
slow
and
not
always
steady
Pace,
but
I
am
trying
to
fill
in
some
of
the
sort
of
you
know.
What
is
what
are
the
concepts
here?
What
are
how
do
they
relate?
How
do
they
fit
together?
A
A
I,
don't
think
it
would
be
very
hard
to
write
a
dataflow
engine
that
operates
on
it,
especially
now
that
the
operation,
a
pointer
to
an
operation,
is
a
program
point,
but
I
just
haven't
done
it
and
there's
there's
so
many
other
things
that
need
to
be
done.
That
I'm
trying
to
get
done
before
I
get
myself
excited
about
writing
a
dataflow
engine
which
is
at
least
one
of
the
fundamental
pieces
that
you
need
in
a
compiler
analysis
framework,
but
it's
currently
not
there
and
then.
A
A
But
I
just
don't
have
I
haven't
had
the
time
to
to
start
it,
but
I
think
a
lot
of
the
base
infrastructure
is
now
there,
and
so
you
know,
adding
a
vector
extension
would
be
really
JB
to
work
more
than
than
maybe
some
JB
jb1
work
to
oral
Mark
compiler
work
to
generate
the
code
and
I
think
that's
basically
it
I,
don't
think
I
have
anything
else,
yeah
questions.
So
does
anyone
have
any
questions.
A
All
right,
let
me
ask
a
question,
then
it
is
the.
Is
it
a
problem
that
I
didn't
give
a
refresher
on
what
jb2
looks
like
is.
That
part
is
that
a
guy
I
know
I'm
I'm
very
close
to
this.
So
it's
very
easy
for
me
to
to
associate
what
all
the
words
meant
in
the
presentation
to
the
things
that
I've
been
doing
so
should
should
I
have
included
a
refresher
on
jb2
before
I
went
into
all
of
this
detail.
A
So
if
anybody
has
any
more
questions
or
questions
occur
to
you
that
you
want
to
ask,
feel
free
to
reach
out
and
I'm
always
happy
to
to
talk
about
it,
and
maybe
maybe
what
I'll
do
is
I'll
give
come
back
in
another
little
while
and
give
a
more
refresher
on
what
jb2
looks
like
and
then
a
shorter
version
of
this
update
that
that
revisits.
Some
of
the
questions
and
we'll
see
how
that
goes.