►
From YouTube: OMR Architecture Meeting 20211125
Description
Agenda:
* Vector IL opcode redesign
A
B
I
sure
think
there
so
yeah
so
today
I'll
present
a
redesign
of
vector
io.
Of
course
I
have
to
mention
first
that
we
already
had
the
presentation
like
a
few
years
ago.
This
is
a
new
one
based
on
previous
proposal,
but
it
changed
so
much
that
I
essentially
started
from
scratch.
You're
only
writing.
One
slide
remains
from
previous
presentation,
so
it's
basically
a
completely
new
redesign
and
first
I'll
talk
about
motivation.
B
Our
proposal
and
examples
of
that
proposal
and
summary
and
of
course,
at
the
end,
feel
free
to
ask
questions,
and
hopefully
you
have
a
discussion.
Oh
yeah,
so
motivation
is
actually
like
some
presentation
with
some
amendments.
Since
then,
we
have
we're
considering
more
vector
length.
We
would
like
to
support
architectures
like
more
architectures,
actually
intel,
powersd
and
arm
and
as
before.
Of
course,
it
will
help
others.
Indeed
it
actually
can
be
expanded.
B
There
are
several
pieces,
essentially
vector
sizes
and
there's
one
called
species
preferred
which
can
have
any
length
supported
on
a
platform
and,
of
course
we
should
be
able
to
support
different
sizes
in
one
compilation,
and
the
current
approach
is
only
one
100
like
we
have
some
support
for
rsmd
right,
so
128
bit
length
is
implied
only
one
length
and
data
data
types
describe
vector
layout.
Precisely
since
we
don't
have
many.
B
Essentially,
we
listed
all
possible
combinations
of
that
fit
into
128
bit
or
scalar
types
and
of
codes
are
what
we
call
typeless
like
we
add,
the
const
and
data
type
can
be
derived
from
children
from
symbol
reference
or
actually
can
be
cached
on
node,
for
example,
for
the
const,
and
there
are
of
course,
limitations.
Only
one
length
is
supported
right
now,
adding
new
enum
for
every
possible
combination.
We
need
to
add,
like
manually
and,
of
course,
like
with
every
new
length
sort
of
growth
considerably
and
current
typeless
implementation
actually
had
some
issues.
B
B
I
first
like,
let's
covered
our
existing
data
structures,
of
course,
without
the
basic
file
structures,
and
we
have
a
node
class.
Of
course
that
has
refers
to
I
love
code
class
and
in
turn,
I'll
opcode
class
has
just
one
member
like
enum
I'll
codes
num.
So
it's
like
one
to
one
corresponding
they're
like
you
can
go
from
enum
to
class
from
class
to
in
inaudible
kind
of
conversion
operators,
so
they
almost
like
identical,
except
that
in
the
class.
B
B
They're,
like
interchangeable,
due
to
all
kind
of
operators
being
defined
and
then
enum,
of
course,
the
one
that
has
like
around
600
enums
and
conceptually
not
like.
We
don't
encode
anything
which
is
least
enough
by
number,
but
conceptually
each
from
each
enum.
We
can
derive
the
result,
type
operation
and
source
type
in
in
most
general
case,
like,
for
example,
I
to
f
right
result.
Type
is
f
right
for
float.
B
B
It's
a
set
of
all
possible
data
types,
it's
a
product
of
e
and
s
like
elements
and
sizes.
Right,
yes,
and
set
of
all
possible
objects,
as
I
said,
like
things,
are
important,
so
result
type,
source,
type
and
operation,
so
product
of
three
sets
and
the
source
type,
maybe
not
a
best
name
but
say,
for
example,
it's
clear
for
conversion
right
the
resource
and
result
for
say,
for
example,
vector
load.
It's
not
not
if,
like
first
child
in
the
tree,
it's
it's
a
vector.
B
Without
any
modifications,
I
would
say
and
also
koji-
and
I
would
say
just
due
to
the
sheer
number
of
all
these
combinations
right-
it's
needs.
It
needs
to
be
structured
right.
First
of
all,
for
example,
we
should
not
ask
like
anywhere,
I
think,
for
specific
combinations,
specific
member
or
this
set,
but
like
group,
it
may
be
by
operation
and
by
type
by
length
depends
on
platform.
I
think,
but
definitely
need
to
structure
it
somehow
in
order
to
maintain
the
code.
B
So
they
said,
there's
two
constraints
right,
and
these
are
two
steps
that
we
need
to
represent,
enop
and,
and
so
would
actually
providing
only
really
three
ways
to
represent
data
sets.
In
a
program
in
general
like
in
any
program
but
in
omar
specifically,
we
have-
and
you
of
course
need
to
consider
existing
code
in
omr.
B
This
thing
implementation,
so
first
we
can
represent
them
as
classes
right,
for
example,
with
that
d,
can
we
can
reuse
that
data
type
class
that
we
have,
which
has
to
add
it's
already,
has
essentially
element
type,
add
the
size
to
it.
Another
instance
variables
right
variable
and
the
op
code.
We
already
have
a
class,
we
just
kind
of
split
like
into
three
variables
right
now.
We
just
have
op
code
right,
but
we
would
have
like
that
two
types.
C
B
B
Another
approach
is
essentially
hash.
These
values
into
one
number
like
we
can.
We
can
represent
each
tuple
or
triple
as
one
integral
value
unique
integral
value.
For
example,
there
is
some
mapping
function
from
this
triple
to
integer
or
like
from
this
both
to
integer,
but
then
we
also
need
a
function
that,
given
that
unique
number
I
you
can
get
each
member
from
that
number.
B
B
We
discussed
that
and
basically
debugging
like
not
easy
to
understand
the
meaning
of
that
integral
value
like
what
exactly
of
code
it
refers
to,
and,
of
course,
we
need
to
can
make
it
compatible
with
existing
inauds,
because
we
already
you
know
they
have
to
be
this.
I
has
to
be
the
same
size
as
existing
num.
B
I
will
show
examples
and
then
so
this
approaches
a
b
and
c.
We
just
can
list
all
set
members
in
the
form
of
nouns,
as
we
do
right
now,
kind
of
like
in
a
dance
form
like
listen
and
they
can
be
referred
in
the
source
and
can
be
in
a
debugger,
but
definitely
that
part
kind
of
directly
referred
in
the
source
violates
constraints.
One
and
two
that
I
mentioned
before
size,
of
course,
will
be
smaller.
B
I
would
say
at
least
like
a
thousand
you
know
to
me,
one
of
the
new
op
codes
need
to
be
added.
We
can
also
consider
like
automatically
generating
emails
and
encoding
this
that
I
essentially
into
enum
value
like
saying
some
enum,
like
I
don't
know
just
some
reload
equal,
some
encoded
value,
but
I
then
I
sort
of
it
becomes
like
similar
to
b.
I
would
consider
as
part
of
b
at
least
maybe
there's
some
modifications,
but
then
c
becomes
close
to
b
distance
some
way.
B
B
D
B
So
basically
yeah
like
it's
the
classes,
nice,
but
a
lot
of
changes,
encoding
easier,
like
sort
of
three
vector
lengths,
almost
like
as
the
variable
like
a
member
of
some
class,
because
we're
gonna
have
many
and
treat
them
as
variables.
Essentially,
for
instance,
like
midfield
and
c
kind
of
you
know,
can
be
modified
but
sort
of
in
a
sort
of
to
distinguish
from
kind
of
like
I
would
say.
Yes,
it's
essentially
the
current
approach
of
one
listing
or
all
enums.
E
B
B
Okay,
like
more
in
this
terms
like,
for
example,
vector
of
length
128
consisting
of
it
that
will
be
source
type
right,
okay
mask
will
be
of
mask
type.
It
was
going
to
be
vector,
but
we
probably
might
we
might
need
to
have
mask
separate
type
for
mask.
But
let's
assume
mask
it's
like
a
vector
as
well.
B
B
It
will
be
essentially
vector
of
different
type
right.
It
will
be
yeah.
It's
a
very
good
example.
Right
result
will
be
also
for
elements,
but
they
will
be
of
type,
probably
actually
one.
Second,
it's
still
it
depends.
We
need
to
look
at
the
library,
it
will
return,
also
four
elements,
but
they
will
be
sort
of
like
boolean
right.
E
B
B
B
E
B
E
B
E
B
Yeah,
but
very
good,
very
good
question,
so
any
questions
about
this
yeah.
So
basically,
this
is
more
like.
If
you
don't
consider
mask
it's
like
well,
even
with
masks,
I
would
say
it's
sort
of
it's
a
results
course
type
and
operation,
for
example,
for
reduction
right.
A
typical
example
source
will
be,
I
don't
know
floating
point
vector,
operation
will
be
reduction,
vector,
reduction
and
result
type
will
be
floating
point.
B
So
yeah
yeah,
even
in
the
pan
of
any
proposal,
we
need
to
consider
sv
right
a
c.
It's
different,
a
bit
from
other
architectures.
It
introduces
something
called
scalable
vectors
and
there
are
a
couple
rules,
but
in
most
general
case
you
can
have
vectors
of
128
bits
up
to
2k
and
in
128
bit
increments.
B
So
you
can
have
already
like
16
at
least
16
lengths,
but
only
one
length,
but
the
length
can
be
configured
by
implementation,
like
I
think
it's
by
maybe
by
alcoholic
or
you
can
consider
at
some
point,
and
it
can
be
clear
that
well
if
for
studying,
compilers,
basically
they
need
to
generate.
Essentially
they
don't
know
what
it
is.
So
they
need
to
generate
steady.
Compilers
have
to
generate,
like
essentially
dynamic
type.
B
You
know
like
like
dynamic
stack,
you
know
and
the
sort
of
unknown
temporaries
of
unknown
type,
even
but
for
just
a
time
compiler
it
can
be
queried
queried
at
at
runtime
during
common
compilation.
So
it
was.
I
couldn't
like
figure
out
exactly
sort
of
unknown.
Theoretically,
I
think
it
can
be
that
configured
length
can
be
changed
while
process
is
running
even
at
certain
points,
but
I
think
you
just
can
call
some
functions
some.
B
B
B
C
B
One
like
variable
length
and
because
we
don't
even
know
what
it
is
right
like
we
can
before
we
start
running
right
at
runtime
and
and
also
electric.
In
addition,
those
three
lengths
also
has
64
bit
length,
even
though
we
probably
not
gonna
use
like
we
don't
have
64-bit
registers,
but
I
think
it's
good
to
represent
it
as
a
separate
type,
because
maybe
a
half
of
128
bit
register
can
be
used,
vector
register.
B
B
We
can
use
like
you
know,
just
one
bite,
one
to
represent
all
combinations
use,
say
four
upper
four
beats
for
vector
length.
As
I
said,
we
need
three,
but
maybe
one
is
for
future
and
lower
four
bits
for
existing
scalar
types,
like
those
data
types
that
we
have
and
the
last
one
is
num
types,
so
we
can
use
static,
assert
right
for
num
types.
Actually,
maybe
it's
incorrect
right.
It's
basically!
B
B
B
B
And
then
what
about
supported,
vector,
lengths
and
types?
I
think
it's
easy
to
control
like
because
there
will
be
a
limited
number
of
actually
places
where
we
create
and
we
vector
types
and
go
to
vector
p,
expansion
for
vector
library
or
rsmd,
and
then
we'll
just
be
asking
why
cody
and
which
combinations
are
supported,
which
already
do
seem
for
other,
simply
because
I
didn't
do
that
and
then,
when
we
convert
one
type
to
another,
some
transformation
happen
again.
We
just
need
to.
I
think
it's
similar
to
other
types.
B
So
this
is
data
type.
So
basically
the
bottom
line
it
can
be
encoded,
combination
of
element,
type
types
and
vectors
can
be
encoded
in
one
white
as
well
right
now.
So
what
about
opcode
opcode
right
now
stored
this
variable,
let's
say
ignom,
and
then
it
currently
has
its
size,
four
bytes,
and
so
we
can
encode
all
op
codes
into
four
bytes,
because
data
type
is
one
byte
operation.
B
Two
bytes
should
be
enough
because
we
have
right
now
around
600.
We
don't
plan
to
add
more
and
then
we
need,
as
I
said,
two
data
types.
So
it's
like
one
for
the
result,
one
for
source
and
two
bytes
of
operations.
So
four
and
and
again,
if
it's
at
some
point
not
enough,
we
just
need
to
make
that
enum
bigger
and
again.
B
We
need
to
a
cert
that
exists
essentially
operation
right
fits
into
two
bytes
right,
so
we
need
to
cover
the
third
and
also
very
important
that
I
start,
of
course,
that
the
whole
enum
fits
because
we
essentially
we
need
to
fit
all
this
and
correct
values
here
right.
So
we
need
to
assert,
but
that's
nice,
that
it
fits
right
and
maybe
even
specify
the
size
of
enamel
explicitly.
B
I
will
show
an
example
and
as
similar
to
data
types
and
then
can
continue
getting
the
value
vector
op
code,
the
value
of
vector
upcode.
I
get
off
code
value
that
method.
We
have
exactly
the
same
way
as
for
other
op
codes
and
use
them
and
compare
compare
them
with
the
set
them
on
the
node
and
so
on,
but
but
they
just
won't
be
able
to
refer
them
explicitly
in
the
source
sort
of
like
hidden
enough
and
vector
op
calls
can
be.
B
You
can
say,
ask
what
code
is
a
tractor
right
or
get
result
type
get
source
get
operation
and
in
this
case,
operation
will
be
like
separate
email.
I
will
show
an
example
and
it
can
be
used.
It
will
be
used
to
create
new
op
calls
vector,
of
course,
and
also
in
the
code,
maybe
like
grouping
them
like
by
add
reducing
spell
by
operation.
B
I
will
show
example
and
yeah
and
of
course,
as
you
know
like,
essentially
this
value
is
used
for
referring
to
different
tables
and
dispatching
all
kind
of
handlers
and
that
code
will
have
to
be
changed
like,
but,
hopefully,
somehow
encapsulated
like
say
for
vector
of
code.
U,
in
order
to
get
handler
for
vector
of
coding
in
special
case
and
regarding
rt,
I
think
again,
it's
similar
to
other
code,
and
you
know
instructions
we'll
need
to
invalidate
method
if
compiled
in
vector
compiled
in
actual
vector
length
don't
match.
B
B
B
B
Instead,
we'll
have
new
enum
vector
operations.
I
would
call
it
not
opcos.
Of
course
it's
something
not
code.
It's
already
like
it's
a
triple
red
operation.
It's
just
a
sort
of
abstract
operation,
so
probably
better
to
call
it
vector
operations
and
that
will
be
used
to
create
vector,
op
codes
right
and
then
create
all
these
separate
parts
of
it
results.
Source
operation.
A
B
A
B
B
B
B
B
B
B
And
if
it's
type
is
vector
we
will
call
create
vector,
op
code
right.
This
will
be,
of
course,
definitely
it'll
be
function,
separate
function
that
creates
that's
the
whole
idea.
It
has
to
be
kind
of
encapsulated
right.
That
encoding
has
to
be
in
separate
function,
create
vector
op
code
and
in
case
of
load,
as
I
mentioned,
like
type
result
and
source
type
are
the
same
and
vector
operation
is
reload,
indirect,
read,
so
that's
a
node
creation
example
and
then
again
using
opcode
similar
to
using
data
types.
F
B
B
Maybe
yeah
combine
these
two
checks
together
now,
actually
yeah
we're
probably
going
to
have
something
like
this
vector
address
and
then
check
element
type
and
do
something
special
for
vectors
and
similar
forces
which
are
actually
with
switch
still.
We
don't
need
to
rewrite
switch
like
just
a
sensation,
add
default
gates,
so
code,
examples
and
in
trace
file.
B
B
What
I
sort
of
like
about
it
is
that
it's
a
conceptual
it's
very
close
to
the
current.
I
would
say:
non-vector,
of
course,
regular
of
codes
in
a
sense
that
all
information
is
kept
in
the
op
code
yeah.
It
may
be
encoded
differently
right,
but
the
encoding
is
the
separate
function.
You
know,
we
don't
even
see
how
it
is
encoded.
Usually
we
don't
even
look
there
right.
B
We
just
know
that
our
op
code
uniquely
represents
sort
of
contains
all
information
we
need
and
in
coding
and
sort
of
like
travels,
find
like
throughout
the
optimizer
and
all
the
transformations
and
all
the
information
is
preserved
in
the
hope,
code
and
yeah
and,
of
course,
I
generated
on
the
fly.
So
we
don't
need,
we
don't
generate
like
the
ones
that
we
don't
need,
because
there
are
quite
a
few
of
them
right
and
I
would
say
another
good
part
is
like
yeah
sort
of
minimum
changes
to
existing
code
non-vector
code.
B
I
would
say
no,
of
course,
if
you
release
somebody
really
also,
you
can
create
like
reference
to
very
specific
vector
type
or
op
code,
but
generally
there
is
no
like
enums
that
can
know
that
might
be
used
in
a
source,
just
only
like
general
queries
right,
and
I
think,
because
it's
so
close
to
current
approach,
we
can
consider
like
somehow
extending
it
or
optimizing
it.
For
example,
right
now
right,
most
of
the
op
codes
result
in
source
type
is
the
same,
for
example
right.
G
G
H
B
Check
all
the
places
kind
of
the
hope
is
that
we
don't
have
that
many
places
all
right,
for
example,
for
op
codes.
We
know
all
the
tables
right
and
usually
we
use
some
general
sort
of
dispatch
code
for
data
types.
I
also,
I
don't
think
we
have
many
places
when
built
tables
indexed
by
data
type,
but
yeah
that's
sort
of
it's
where
we
need
to
be
careful.
Yeah.
G
B
G
Now
the
problem
is
you're
going
to
have
to
change
all
the
code,
all
the
existing
code.
That
might
currently
have
a
problem
like
this
right,
like
anywhere,
where
you're
now
manipulating
the
data
type.
You
could
all
of
a
sudden
have
a
value
that
is
outside
the
range
and
everywhere,
where
that
code
is
used,
which
isn't
necessarily
using
get
data
type
directly,
would
need
that
kind
of
assert
or
masking
or
whatever.
B
B
G
B
B
G
Yeah
well
at
least
I
know
mmr.
I
guess
that's
something
we
can
check
by
just
scanning
through
the
code.
The
concern,
then,
is:
are
there
any
non-obvious
cases
because
of
possible
indirections,
like
I
said
before,
where
you're
storing
something
in
the
variable
and
then
pass
that
on
somewhere
and
then
that
variable
gets
used
to
index
somewhere?
It's
it
it's
it's
possible
to
find
out,
but
possibly
it's
going
to
take
some
time
and
some
work
and
then
for
downstream
projects.
G
G
G
B
D
There's
also
a
danger
that,
if
you're
not
changing
the
num
types
value,
then
even
even
can
like
downstream
consumers
that
wrote
safe
code
that
asserts
it
or
that
checks
that
that
num
types
isn't
great
or
they
could
run
into
trouble.
I
guess
if
they,
I
guess,
they'll
still
detect
something
that
an
actual
value
that
is
greater
than
num
types
in
a
cert.
So
that's
good,
but
I
mean
we
can't.
We
can't
know
what
downstream
consumers
may
have
created,
what
tables
they
may
have
created
and
just
index
into
right.
That's,
I
guess.
C
B
B
G
B
In
this
case
is
a
problem
tables
because
essentially
we're
different
between.
If
you
go
back
to
this
approaches,
b
and
c
right,
what
is
different
here,
it's
kind
of
like
what
I
would
call
sort
of
dense,
enum
right,
which
you
can
use
as
the
index,
and
here
it's
some
kind
of
almost
like
you
know
it's
a
unknown
value.
It's
you
cannot
use
it
as
a
text,
so
that
makes
difference
for
tables.
I
would
say.
D
The
problem
is
because
sometimes
isn't
changing
right,
so
if
somebody
is
indexing
into
a
table,
they're
probably
checking
that
the
size
of
the
table
that
they've
got
is
like,
if
they're
going
to
assert
on
something
it
would
be
a
static,
assert
that
the
size
of
the
table
has
num
types
in
it
and
we're
not
in
this
scheme.
Num
types
doesn't
change
so
that
doesn't
break
but
then
later
on,
you
index
into
it
with
something
that
has
a
value
greater
than
num
types.
B
I
I
B
D
B
C
D
B
G
D
D
D
B
A
A
B
D
K
B
B
G
C
G
B
K
D
One
of
the
areas
where
I
had
a
moderate
concern
was
if
you're
working
in
a
native
debugger
like
gdb
and
you're,
looking
at
a
node
structure
and
right
now,
if
you
print
out
a
tr
node
structure,
you'll
at
least,
if
you're
working
with
omar
with
a
debug
build,
you
can
actually
get
the
op
code,
values
you'll
get
them,
you
can
print
out
the
structure
and
it
will.
It
will
see
them
and
print
out
what
the
op
code
is.
But
in
this
scenario
it
will
that
will
turn
into.
H
D
I'm
not
going
to
be
the
one
to
work
with
this
very
much
at
least
not
recently.
It
hasn't
been
me
working
with
this,
so
the
team's
going
to
have
to
deal
with
this
more
than
I'm
going
to
have
to
deal
with
it.
So
I'm
I'm
willing
to
swallow
my
concern
about
that.
If
no
one
else
is
concerned
about
it
and
it
doesn't
seem
like
there's
a
there's-
a
widespread
concern
about
it.
D
So,
given
that,
I
guess
that
I
I'm
not
gonna,
I'm
not
gonna
argue
for
c
or
b
in
that
case,
for
sure
I
think
b
is
a
fine
approach.
As
long
as
we
address
the
concerns
that
were
raised
earlier
by
leo,
I
think
devin's
suggestion
is
a
good
one,
yeah
consistently
for
data
type
and
op
code,
because
I
think
you
have
the
same
problem
with
both
of
those.
B
D
More
or
less
I
got
I
don't
know,
I
don't
know
how
much
more
of
a
decision
we
need
to
make
here
I
mean
you're
gonna
have
to
make
a
thousand
more
decisions
once
you're
as
you're
going
through
and
implementing
this
and
deciding
it,
and
you
know
unless
somebody
wants
to
really
object
to
to
be
which
I
haven't
heard
anybody
getting
upset
about,
but
please
do
get
upset
if
you
are
upset
about
it
like
tell
us
that
you're
upset
about
it.
Otherwise,
I
would
say
just
move
forward.
D
G
B
B
G
You
know
yeah
yeah.
My
preference
for
c
is
to
do
more
with
more
than
just
that
right,
because,
among
other
things,
it
would
also
solve
a
lot
of
debuggability
issues
because
sure
you
could
just
generate
the
values
so
that
they
match
whatever
encoding
format
has
been
proposed
here,
but
you
would
also
have
the
enum
name
associated
with
it.
So
looking
in
gdb,
it
would
still
work.
B
Yes,
I
think
I
think
that's
important
to
that
part
I
think,
is
important.
Should
they
be
sequential
values
or
they
should.
That
makes
I
think,
the
biggest
difference
when
I
said
to
distinguish
like
clearly
a
b
and
c
by
c.
I
mostly
my,
I
meant
sequential
numbers
here,
just
added
like
how
they
can
be
sort
of
merged
with
b,
but
the
c
in
most
kind
of
general
way
is
sequential
numbers.
So
I
think
that's
what
we
need
to
decide,
so
those
enums
should
be.
D
Okay,
that's
the
difference.
You
see
between
c
and
b.
Then
that's
not
that's,
not
how
I
was
interpreting
it
yeah.
That
was
not
how
I
was
interpreting
that
either
I
would
I
would
not
recommend
using
sequential
numbers.
I
would,
I
would
assume
you'd
do
the
encoding
and
then
just
tool
would
just
generate
the
enum
to
match
that
encoding
so
that
you
could
still
extract
the
fields
that
you're
talking
about,
because
I
think
it
is
valuable
to
be
able
to
do
that.
B
I
definitely
meant
that
c
is
sequential,
but
if
we
encode
what
I
was
saying,
if
encode,
then
it
becomes
close
to
b.
Basically,
then
we'll
look
at
it
as
b,
but
without
but
plus
debugging
abilities,
so
we
can
then
have
b
and
somehow
think
how
we
can
generate
those
names,
but
the
essence
of
the
still
you
need
some.
You
know
function
that
decodes
them
and
calls
them
decodes
them
right.
B
B
G
G
B
I'm
not
completely
sure
num
type
will
have
very
different
meaning.
Then
it
will
be
sort
of
like
maximum
encoded
world.
It's
not
going
to
be
a
number
of
emails.
It
will
be
sort
of
like
the
maximum
value
you
can
have
it
it'll
be
like
you
know,
ffff
or,
like
you
know,
into
max
or
something
or
unsigned
in
max
rate,
it
will
have
different
meaning
because
it's
very
important
to
distinguish,
like
you
know,
right
versus
encoded
enough.
So
it's
very
important.
I
B
B
B
B
D
B
G
B
Tables
right,
that's,
I
think
the
main
problem,
and
what
I'm
saying
is
the
only
way
to
reference
be
able
to
reference
problems
is
to
list
all
like
make
them
on
regular
enough
without
values.
Compiler
will
give
them
sequential
numbers
and
which
will
make
them
in
like
in
indexes.
You
can
use
them
as
an
index.
Compiler
will
take
care
of
it,
but
as
soon
as
you
encode
it
right.
D
D
B
G
G
So
the
difference
is
that
you,
when
you
sorry
go
ahead,
mark
go
ahead
leo
that
to
me
the
the
difference
here
is
you
have
when
you're
thinking
about
the
work
to
implement,
say,
b,
you
have
to
think
about
the
work.
It's
also
going
to
take
to
update
existing
code.
That
is
broken,
which
is
code
potentially
both
in
omr
and
downstream
projects.
B
B
G
C
B
D
D
B
We
would
like
to
use
the
extra
tool
and
to
generate
old
possible
values
which
can
be
sort
of
from
yeah,
just
kind
of
isolate
it
and
generate
all
the
values.
But
then,
as
mark
actually
was
saying
right
like
to
make
it
consistent,
then
the
block
tool
should
be
generating
those
functions
too
right
because
we
want
to
keep
it
consistent
right,
android
rule
all
kind
of
functions
that
we
need
actually,
maybe
just
so
two
functions
that
encodes
and
decodes
the
values.
B
G
So
just
playing
devil's
advocate
here.
If
you
made
the
tool,
also
generate
those
functions,
you
could
make
the
tool
like
you
could
make
the
tool
then
generate
the
enum
sequentially
and
make
it
generate
tables
such
that
those
function
just
turned
into
a
lookup
into
a
table,
and
you
get
back
the
sync
property
values
right
and
you
wouldn't
be
able
to
decode
it
manually.
But
you
wouldn't
do
that
because
you
could
just
call
the
functions
to
do
it.
D
I
I
B
B
B
Exactly
exactly
actually
that's
what
I
mean
was
trying
to
say
in
the
summary
right.
If
we
see
the
only
difference
between
b
and
c3
is
ability
to
debug,
but
maybe
we
can
decide
on
that
later
right
like
we
need
to
create
this
functions,
we
need,
if
that's
only
difference
we
can
decide
later
on
that.
Maybe
yes
generate
those
names.
Maybe.