►
From YouTube: OMR Architecture Meeting 20200618
Description
Agenda:
* Conclusion of extensibility analysis of OMR compiler [ @oneturkmen ]
* Continue review/actioning of stale issues [ @0xdaryl ]
* Create documentation for the Eclipse OMR project (#165)
* Add more information about platform support (#214)
* Reinstate z9 / z10 ALS on z Systems (#667)
* Declarative Runtime Builder DSL (#670)
* Multiformat VM | Reuse Existing Code | AST Interpreter (#683)
* Comparison to graal / truffle (#1118)
* Produce an object file with Compiler/JitBuilder (#1170)
A
Okay,
welcome
everyone
to
this
week's
Omar
architecture
meeting.
Today
we
have
a
couple
of
topics.
The
first
is
a
talk
from
Bhatia
from
the
University
of
Alberta,
who
will
provide
some
results
from
the
extensibility
analysis
that
they
did
on
the
Omar
compiler.
So
I'll
turn
it
over
to
patear.
To
take
you
through
that.
Thank
you.
Darrell.
B
Can
you
see
them?
Yes,
right,
hi
everyone?
My
name
is
bethere
and
I'm,
a
master's
student
at
the
University
of
Alberta
summer
lab.
Today
we
are
going
to
present
our
collaboration
work
on
the
very
built
implementation
challenges
in
equip
so
amar.
As
you
know,
Eclipse
Omar
is
a
set
of
reusable
c++
components
for
building
the
language.
Runtimes
has
components
such
as
JIT
compiler
and
garbage
collector.
B
For
example,
we
could
build
our
own
virtual
machine
for
Python
or
Java,
or
our
own
programming
language,
since
Omar
supports
many
different
languages
and
architectures
Omar
has
the
mechanism
to
manage
its
variability.
As
you
probably
already
know,
it
supports
architecture
such
as
x86
power
arm
and
is
also
being
used
for
compiling
languages
such
as
Java
and
Python.
B
In
this
talk
will
focus
only
on
the
variability
in
the
compiler
component,
as
is
the
most
largest
and
the
most
central
component
in
eclipse'
Omar,
so
Eclipse
Oh
mark
very
built
mechanism
is
a
variant
of
statical
morphism,
so
everything
has
to
be
resulted
compel
them
to
be
able
to
do
so.
Omar
uses
a
combination
of
extensible
classes,
C++
namespaces
as
several
other
construct.
The
reason
behind
such
a
complex
mechanism
is
performance.
B
However,
the
queuing
mechanism
has
several
challenges
that
impede
simplicity
and
usability
Omar
and
present
challenges
for
both
Omar
developers
and
clients.
Thus,
our
goal
in
this
collaboration
is
to
help
all
mark
developers
understand
very
built
in
their
code
and
investigate
the
very
built
implementation
alternatives
in
2017
2018.
At
the
beginning
of
our
study,
who
thought
static.
B
Polymorphism
was
the
root
of
all
problems
behind
a
very
built
implementation
in
Omar,
whether
it
was
just
too
complex
to
understand
for
client
developers
and
made
it
more
difficult
to
maintain
a
further
improve
code
to
support
more
downstream
projects
that
use
Omar.
Our
first
attempt
to
elevate
the
challenges
regarding
the
mechanism
was
to
switch
to
dynamic
pole
Murphy's.
We
hoped
that
it
would
make
it
easier
to
manage
variability
Nomar,
even
at
a
small
runtime
cost
and
previous
researchers.
B
In
this
study
wrote
a
few
articles
on
the
challenges
with
the
current
mechanism,
as
well
as
the
transition
to
dynamic
polar
fizzle.
They
developed
Almar
statistics,
a
tool
that
would
help
omar
and
client
developers,
managed
their
variability
and
made
it
easier
to
visualize
and
understand
the
extensible
classes
that
they're
using
those
three
factors,
some
of
the
extensible
classes
to
use
dynamic,
polar
ism
constructs
such
as
virtual
methods.
However,
there
were
still
challenges,
requirements
and
constraints
beyond
static
polymorphism,
which
dynamic
pool
morphism
alone
cannot
address.
B
We
decided
to
take
a
step
back
to
get
a
complete
picture
of
all
the
challenges
and
constraints
in
our
mark
from
the
complete
picture.
Our
latest
focus
on
this
work
as
researchers
is
to
identify
design
challenges
posed
by
the
current
very
built
mechanism
and
explore
any
better
design
alternatives
or
tools
and
techniques
that
could
have
both
Omar
and
client
developers.
B
Well,
then,
analyze
the
results
and
came
up
with
a
list
of
requirements
based
on
continuous
discussions
with
the
team.
We
prioritize
the
requirements
based
on
their
level
of
importance
based
on
the
challenges
as
well
as
constraints.
We
came
up
with
a
set
of
eleven
requirements
for
a
new
design
after
discussions
with
the
team,
we
prioritize
this
and
you
can
see
secret
of
six
of
them
here
on
the
slides.
B
B
So
a
virtual
machine
takes
a
source
code
written
the
same
language
and
executes
it
to
be
able
to
reason
what
it,
what
to
do.
At
a
certain
point
of
a
program
lifetime,
a
virtual
machine
uses
its
own
set
of
up
codes.
Each
up
code
specifies
the
instruction
to
perform,
for
example,
icon
loads,
an
integer
constant,
while
elkins
loads,
a
64-bit
or
long
did
your
constant
initial
cook
has
a
list
of
properties
such
as
name
token
and
other
properties
used
by
the
virtual
machine,
for
example
the
return
type
or
the
argument
types.
B
The
files
that
you
see
here
are
named
differently,
but
for
the
sake
of
brevity,
we
decided
to
name
them,
of
course,
at
HTTP,
which
contain
enum
values
of
called
properties.
That
HPP,
which
contain
array
like
entries
with
all
of
called
properties
and
opcode
in
under
VP,
where
opcode
enum
values
are
included.
B
So
all
this
files
refer
to
the
same
set
of
up
codes.
Each
of
these
files
provide
a
certain
piece
of
information
for
each
of
the
corresponding
upload.
The
first
element
in
opcode
in
opposite
HTTP,
corresponds
to
the
first
array
inside
the
opcode
properties
that
HTTP
and
the
second
element
corresponds
to
the
second
entry
in
the
compiler
component.
B
The
same
logic
stands
for
the
rest
of
up
code.
The
problem
here
is
that
if
you
accidentally
swap
a
constant
Elkins
on
up
codes
to
the
HPP,
the
long
constant
up
code
will
not
have
the
property
that
integer
constant
should
have
had,
so
this,
in
fact,
may
introduce
bugs
that
may
be
very
hard
to
debug,
because
the
order
of
this
up
codes
in
these
files
are
not
tracked
automatically
so
either
client
developers
or
IBM
developers
or
our
developers.
B
Sorry,
we
will
need
to
manually
track
the
order
you
know
know
the
different
files
with
all
these
op
codes.
So
if
you
did
everything
correctly,
this
is
an
equivalent
of
what
you
would
get
after
pre-processing
all
macros,
and
this
is
a
comment
from
one
of
these
files
in
DOMA.
You
know
mark
compiler
component.
In
the
previous
example,
we
just
saw
two
of
them,
but
in
reality
they
are
about.
There
are
more
than
ten
of
these,
so
accidentally
forget
edges.
Just
one
of
these
files,
we
may
introduce
box
that
may
on
the
pop
up
at
runtime.
B
Therefore,
we
need
a
centralized
way
of
control
of
these
sub
codes
and
their
corresponding
properties,
and
the
problem
here
is
that
C++
there
is
no
natural
way
of
extending
C+
C++
unions
or
in
apps
the
same
way
you
would
extend
classes
or
structs.
So
this
leads
to
extending
of
codes
being
more
confusing
and
error-prone,
so
as
I
step
to
serve
the
requirements
were
gathered,
but
first
looked
into
the
literature
of
existing
mechanisms.
Since
there
is
a
variety
of
mechanisms
for
variability
management,
we
focus
on
the
three
most
relevant
to
Omar.
B
In
this
talk
in
general,
the
mechanisms
vary
from
being
fine-grained
to
coarse-grained.
In
other
words,
a
fine-grained
mechanism
is
at
the
level
of
statements,
for
example,
if
conditions,
and
then
you
have
methods
and
functions
and
more
coarse-grained
mechanism,
such
as
classes
and
even
coarser
components
and
modules.
In
addition,
the
mechanisms
can
be
they're
applied
at
compile
time,
both
time
or
run
time.
B
B
Parameters
are
quite
easy
to
understand
and
use
and
most
programming
languages
support
these,
because
most
programming
languages
have
if
statements.
On
the
other
hand,
though,
they
create
coq,
low
and
add
runtime
overhead,
because
now
you
should
deploy
all
of
these
statements
to
production,
and
all
of
these
statements
should
be
evaluated
at
runtime.
It
gives
affirm.
Our
parameters
could
actually
contribute
to
simpler
and
more
usable
design,
they're
already
being
used
to
manage
compiler
options,
for
example.
However,
they
cannot
solve
all
the
requirements.
B
First,
they're
useless
in
terms
of
the
UNAM
extension
Union
in
an
extension
problem,
and
there
is
really
no
way
that,
if
statements
could
help
resolve
the
need
for
variant
constructors
between
architectures
next
now
released.
Our
patterns
patterns
are
a
set
of
reusable
and
general
solutions
to
common
problems,
to
commonly
the
reoccurring
problems
in
software
design,
April
or
heard
about
Factory
singleton.
The
creator
and
strategy
patterns,
since
the
solutions
are
general
enough
to
be
coded
in
most
opie
languages.
There
are
discipline
guidelines
of
how
to
implement
them.
B
However,
we,
before
implementing
a
certain
pattern,
we
should
know
all
the
extension
points.
What
are
the
points
through
which
you
can
supply
additional
functionality
to
in
your
program,
for
example
like
providing
callbacks
and
JavaScript
functions
or
jQuery
plugins,
and
if
you
missed
something
in
our
way,
the
pattern
may
later
turn
out
completely
useless
and
probably
even
harmful
and
some
of
the
patterns.
That
also
add
boiled
boilerplate
code,
as
well
as
make
code
more
complex.
B
So,
given
the
discipline
nature
of
design
patterns,
it
could
be
somewhat
useful
to
apply
this
in
nomar
to
bring
in
simplicity
and
usability.
It
could
actually
make
it
easier
for
developers
both
Omar
and
client
developers
to
communicate
with
each
other
and
better
understand
that
very
built-in
mechanism,
because
the
patterns
are
well
known
in
the
developer
community.
However,
all
Mart
developers
are
not
going
to
stop
working
on
the
features
and
instead
into
large-scale
refactoring,
some
to
some
design
pattern.
B
B
Last
but
not
least,
we
have
Fisher
oriented
programming,
it's
a
mechanism
that
relies
directly
on
the
notion
of
features.
The
core
idea
is
to
decompose
your
software
into
features
it
provides,
and
ideally
you
would
have
a
component
or
a
module
per
feature
so
that
you
can
make
so
that
you
make
sure
that
you,
you
ensured
a
separation
of
concerns
you
can
see
on
the
screen.
The
diagram,
that's
called
the
feature
model.
The
model
depicts
all
features
of
a
system
and
the
relationship
between
different
features.
B
For
example,
the
fields
circle
near
the
base
rectangle
on
the
Left
represents
a
mandatory
feature,
so
it
doesn't
matter
whether
so
doesn't
matter
which
end
product
you
deploy.
The
base
feature
is
going
to
be
always
there,
but
the
circles
that
are
not
filled
to
represent
optional
features.
Therefore,
you
could
have
a
way
to
the
graph
or
color
graph
or
both
weighted
and
color
graph.
Similarly,
in
Omar,
you
could
mandate
certain
completion
processes
or
logarithms
to
run
an
optimization
on
back-end
phase,
as
well
as
provide
some
optional
ones.
B
If
they
apply
in
clients
case,
the
following
figure
shows
that
we
can
create
four
different
end
products,
namely
the
basic
graph
where
the
graph
color
graph
and
both
weight
at
and
calligraph.
Each
of
these
gray
boxes
represents
a
future
module
to
use
classes
across
future
modules.
We
need
a
way
to
override
certain
methods.
This
is
a
snippet
written
in
Jack.
Language
Jack
is
a
simple
and
extension
of
the
Java
language
for
future
oriented
programming.
B
Here
class
requirement
is
used
instead
of
sub
classing.
The
refinement
is
a
form
of
mixin
based
inheritance
in
which
subclasses
or
mix
ents
are
abstract
in
the
sense
that
they
can
be
applied
to
different
concrete's
the
classes.
You
can
also
think
of
Nixon
based
inheritance
as
the
static
counterpart
to
the
decorator
pattern.
B
Mix-Ins
are
also
somewhat
useful.
Two
traits
in
the
Russ
programming
language
and
in
this
example,
we're
refining
class
graph
to
add
the
notion
of
edge
weights
since
the
our
original
graph
doesn't
does
understand
the
the
notion
of
weight
and
in
the
weight
weighted
layer,
we're
adding
a
the
notion
of
edge
weights
to
make
the
graph
weighted
with
feature
oriented.
Programming
developers
really
get
a
good
feature
traceability
because,
ideally,
since
we
have
each
feature
per
module,
it's
easy
to
track
where
each
feature
is
located.
However,
feature
oriented
programming
requires
additional
tool.
B
Support,
simplest,
buzzient,
provide
any
specific
contracts
for
feature
oriented
programming,
and
the
paradigm
has
only
been
used
so
far
in
academia
in
no
more
feature
oriented
programming.
The
paradigm
correction
will
help
improve
simplicity
and
usability
of
the
project.
It
would
be
much
easier
to
track
where
each
feature
is
located
and
to
how
and
how
to
combine
these
features
into
the
important.
B
We
also
looked
into
existing
industrial
case
studies
of
highly
configurable
software
when
surveying
the
literature.
Most
of
things
that
show
case
studies
focus
on
extracting
a
software
product
line
from
already
existing
set
of
end
products.
It
means
that
a
given
set
of
end
product
product
ABC
the
researchers,
wanted
to
extract
the
commonality
between
these
products
into
reusable
assets
so
that
they
can
potentially
tailor
these
reusable
assets
absolves
the
products
to
more
markets.
For
example,
ml
kolitar
is
a
family
of
compilers
for
ml
pollak.
B
Our
language,
their
family
of
products,
is
different
from
Walmart
because
they
focus
all
in
a
single
language,
namely
the
amount
of
poly
our
while
Omar
strives
to
support
many
different
sources.
Similarly,
polyglot
is
a
is
an
extensible
front-end
compiler,
which
only
compiles
java
to
java
bytecode,
which
is
again
different
from
all
mark.
B
On
the
other
hand,
omar
is
already
highly
configurable
system.
It's
software
assets
are
the
c++
components
like
just-in-time
compiler,
garbage
collector
and
a
bit
read
like
library
its
products.
It's
for
the
duration
process
is
realized
through
the
use
of
c
make
in
the
build
system
and
the
C
preprocessor
and
in
the
end
developers
are
able
to
derive
end
product,
such
as
open,
j9,
JVM,
virtual
machine
for
Ruby,
small
talk
and
few
other
languages.
So
that's
your
case.
Studies
didn't
help
much
because
the
project's
the
projects
they
have
are
much
less
in
complexity.
B
B
So,
instead
of
trying
to
satisfy
everything
so
all
the
requirements,
at
the
same
time
with
a
single
mechanism
we
divide
and
conquer,
we
pragmatically
examined
one
problem
at
a
time
and
proposed
a
solution
to
it.
Using
our
approach,
we
implement
a
solution
to
the
C++
Anam
extensibility
issue.
We
as
researchers
chose
this
particular
requirement
because
it's
concrete
enough
that
it
doesn't
require
much
involvement
from
the
team
members
and
if
salt
would
have
a
positive
impact
on
the
proving
code
quality
and
making
the
process
of
extending
opcodes.
You
know
more
much
easier
and
simpler.
B
Now,
let's
take
a
look
at
what
we
can
do
about
the
UNAM
extensibility
problem.
After
looking
at
the
literature,
as
well
as
open
source
software,
that
can
go
into
two
directions.
The
first
one
relies
on
an
external
domain,
specific
language.
The
second
one
uses
the
C
preprocessor
and
it
smothers.
The
first
direction
takes
an
inspiration
from
table
J
and
n
LLVM
tooled
for
recording
architecture.
Specific
information
table
jump
provides
a
variety
of
constructs,
such
as
definitions
and
classes.
B
The
TD
files
contain
the
information
in
the
particular
DSL
named
Lilu
table
gen,
which
are
then
transformed
into
dot
Inc
files
or
the
C++
include
files.
The
include
files
are
later
generated.
These
include
files
are
generated
by
the
tool
which
are
consumed
by
the
classes
in
the
back
end.
In
a
novel
via,
for
example,
the
x86,
the
x86
back-end,
defines
the
register
class
named
gr
32
that
holds
all
of
its
32-bit
registers.
So
if
certain
instruction
needs
to
use
one
of
these
registers,
it
can
reference.
B
This
particular
part,
this
particular
definition
or
when
the
operation
involves
what
some
of
these
registers
so
table.
Gen
doesn't
have
to
be
directly
used
in.
Oh
my,
it
just
gives
us
sort
of
an
inspiration
or
a
concept
of
what
a
domain-specific
language
we
could
devise
or
not
Oh.
For
example,
in
our
own
DSL
we
could
add
additional
contracts
for
extensibility
so
that
we
can
reuse
some
of
the
opcode
information
in
Amara.
We
could
have
also
developed
our
own
DSL
I'm
concerning
it
doesn't
work
well
because
it
doesn't
really
help
solve
the
extensibility
issue.
B
In
a
sense,
the
downstream
projects
or
the
clients
will
still
have
difficulties,
maintaining
their
opcode
files.
In
addition,
both
Omar
and
client
developers
will
have
to
learn
the
new
DSL,
alternatively,
within
the
same
direction,
instead
of
devising
a
new
DSL
who
could
use
a
set
of
JSON
files,
as
well
as
some
Python
script,
that
would
consume
the
information
about
opcodes
from
the
json
schema
and
output,
simple
passwords.
B
In
that
way,
they
could
eliminate
the
need
to
manually
change
the
opcode
files.
It's
also
easy
to
understand
and
use
JSON
file.
It's
pretty
intuitive.
However,
all
Mart
developers
try
to
keep
the
system
as
minimal
as
possible
in
terms
of
his
dependencies
and
do
not
want
to
include
any
unnecessary
Python
dependencies
in
the
project.
This
approach
would
additional
force
client
developers
to
install
Python
on
their
computers,
their
platforms,
as
well
as
all
Mart
developers
who
would
need
to
solve
Python
on
the
build
servers
on
build
servers
for
all
the
supported
platforms.
B
The
second
direction
takes
in
an
inspiration
from
SpiderMonkey
a
JavaScript
engine
developed
by
Mozilla.
This
solution
is
used
in
the
agent
that
also
contains
a
chief
compiler
and
has
its
own
set
of
up
codes.
It
uses
macros
for
keeping
the
opcodes
information.
In
this
example,
we
store
the
information,
such
as
the
name
and
properties
of
op
codes
in
the
form
of
a
macro.
This
code
snippet
developers
from
Mozilla
defined
for
each
opcode
macro,
which
has
parameter
called
macro.
The
this
parameter
then
gets
invoked
with
all
the
information
about
op
codes.
B
Let's
see
how
we
can
use
this
for
each
of
code,
macro
say
for
some
file.
You
just
want
to
get
the
names
of
all
macros,
you
don't
really
care
about
the
index
or
the
second
argument
representing
some
information
about
other
codes,
so
you
define
a
gif
named
macro
in
the
bottom
figure,
which
just
returns
the
name
and
a
coma.
Since
we
call
the
macro
in
inside
a
list,
as
you
define
get
named
macro,
you
pass
it
as
an
argument
to
the
for
each
of
code
macro,
which
then
invokes
get
named
macro
for
all
op
codes.
B
So
you
are
calling
this
method
here
this
macro
here,
and
this
is
an
equal
to
what
you
would
get
in
the
yet.
This
is
actually
a
result
of
pre-processing
the
macro
which
simply
returns
names
of
pop
codes
along
with
comas.
So
there's
really,
as
you
can
see
here,
this
solution
is
definitely
not
the
best
solution
and
there
is
really
no
silver
bullet.
As
you
can
see,
it
takes
a
bit
of
effort
to
understand.
What's
going
on
here.
B
It
also
doesn't
directly
make
suppose
bus,
enums
and
unions
extensible
in
the
end,
though,
which
O's
to
implement
this
macro
based
solution,
because
it
has
been
the
preferred
one
by
the
Oh
Marty
due
to
its
minimalism
and
simplicity,
and
it
actually
does
solve
the
problem
of
making
it
easy
to
extend
and
track
up
codes
and
different
files.
As
of
today,
the
implementation
is
complete,
but
has
not
been
yet
introduced
into
the
master
branch.
B
We
have
opened
their
pull
requests
at
the
github
repository
at
the
hallmark
repository
on
github,
where
have
incremental,
published
changes
and
communicated
this
video
Marty.
So
in
total
we
introduced
one
central
header
file
with
735
op
codes,
each
containing
40
properties.
We
replace
the
alt
content
of
12
header
files.
Some
of
you
may
know
that
some
of
these
files
contain
more
than
10
10,000
lines
of
code
with
a
single
macro
in
each
not
more
than
50
lines
of
garbage.
B
While
some
of
these
requirements
and
challenges
we
discussed
may
be
specific
just
to
Ammar.
We
think
that
experience
that
we
acquired
working
with
a
very
built-in
elomar
could
be
very
useful
for
other
industrial
case
studies.
First,
when
we
started
calibration
back
in
2017
the
focus
solely
on
the
idea
of
extensible
classes,
we
explore
the
transition
to
dynamic,
bore
morphism,
but
quickly
realized
that
there
are
challenges
and
constraints.
The
dynamic
polymorphism
cannot
resolve.
B
Well,
we
had
regular
discussions
with
the
team
with
our
direct
collaborators.
We
realize
that
a
bigger
conversation,
but
the
whole
team
is
necessary
to
get
the
complete
picture.
Second,
as
researchers,
we
were
inclined
to
think
that
latest
and
greatest
will
always
be
the
welcome
solution
for
the
requirements.
However,
the
introduced
and
discussions
with
the
team
revealed
that
there
are
constraints
that
can
rule
that
him
easily
rule
out
such
options.
For
example
the
least
common
denominator
of
suppose.
B
Past
version
must
be
supported
on
all
different
platforms,
meaning
that
all
Mart
developers
cannot
really
use
all
of
the
C++
14
awesomest
bus
17
features
that
could
actually
help
solve
some
of
the
requirements.
A
third
realize
that
the
complete
recall
of
the
system
to
use
larger
strategies
such
as
fish
oriented
programming,
requires
direct
involvement
of
the
team
members.
The
master
for
engineering
effort
and
process
requires
deep
expertise
of
the
core
base
which
a
research
team
will
not
be
able
to
have.
Despite
collaborating
for
a
couple
of
years.
B
That's
it
when
it
came
to
working
on
a
specific
or
engineering
effort.
We
were
able
to
implement
that,
while
just
needing
code
review
from
the
team
finally
would
like
to
thank
Xiao,
Li,
Dao,
mizenko,
Ian
and
Darryl
Meyer
for
their
involvement,
various
stages
of
this
work
and
for
continuously
giving
valuable
feedback.
We
would
also
like
to
thank
everyone
in
the
team
who
have
helped
us
answering
our
questions
on
reviewing.
Our
pull.
B
Requests
in
summary
were
presented
a
very
built
implementation
mechanism
in
Omar
and
the
reason
behind
using
static
polymorphism,
who
also
talked
about
identifying
analyzing
and
synthesizing
requirements
for
a
new
design.
After
all,
requirements
were
identified,
will
look
different
to
one
of
them,
namely
the
C++
enum
Union
extensibility
issue
for
finding
solutions
for
the
requirements.
We
explore
solutions
from
existing
literature.
We
present
a
silver
collection
directions
for
solving
one
of
such
requirements,
namely
the
the
C++
in
our
mission,
and
we
shared
our
experience
as
researchers.
That
could
be
useful
for
other
industrial
key
studies.
Thank
you.
A
Specifically
about
not
just
data,
but
if
there's
ways
that
this
could
be
applied
to
code
as
well
to
code
actual
executable
code,
I'm
gonna
specialize
this
method
with
components
from
you
know
this
for
this
architecture.
For
this
project,
that
kind
of
thing
I
mean
there's
a
number
of
challenges
with
that,
but
I'm
just
wondering
if
you've,
given
that
any
thought.
B
For
that
particular
issue,
not
really
since
we
only
focus
on
trying
to
sort
of
like,
even
if
you
find
some
solution
from
the
open
source
software,
we
try
to
see
how
we're
particularly
fit
up
codes
and
their
accessibility
issue,
but
with
regards
to
being
able
to
use
it
specifically
for
code.
Oh
there.
C
A
C
Think
it
can
work
is
most
of
actually
like
for
the
main
specific
language
of
this
is
for
generating
code.
So
you
have
a
specification
of
some
sort,
and
the
language
allows
you
to
specify
different
parameters,
different
kind
of
options,
and
then
you
can
generate
things.
So,
if
you're
saying
that
for
a
lot
of
the
extensions,
it's
really
more
or
less
a
template,
they
are
it's
a
pattern
that
keeps
recurring
but
with
different
parameters.
D
A
C
C
B
C
From
and
kind
of
consistency,
if,
if
it's
all
about
like
generate
a
code,
that
it's
not
gonna,
touch
I,
think
it's
okay,
because
you
could
keep
that
traceability.
The
problem
arises
if
somebody
tries
to
actually
change
that
generate
a
code
somehow,
and
then
you
need
to
reflect
that
back
into
the
original
specification.
C
B
C
A
Think
so
I
mean
I
I,
think
you've
got
a
poll
request,
open
I,
think
it's
been
under
various
stages
of
reviews:
I
think
that
just
needs
one
final
push
to
kind
of
get
that
in,
but
we
did
discuss
this
on
a
community
call.
You
know
a
few
months
ago
and
I
think
that's
what
sort
of
precipitated
some
of
this
work
so
I
think
that
there
is
support
in
the
community
for
or
for
doing
this.
So
it's
just
a
matter
of
getting
that
in.
A
Okay,
anything
else
for
good
here,
not
thank
you
very
much
it
here
for
presenting
for
presenting
that
I
said.
Will
the
community
will
certainly
work
on
getting
your
your
pull
request
integrated
into
the
and
you
know,
hopefully
that
will
serve
as
a
you
know,
sort
of
a
model
for
other
kinds
of
data
tables
being
refactored
that
way
and
an
integrated.
So
thank
you
for
that.
Thank.
B
A
Sure,
okay,
thank
you!
So,
let's
see
we
have
40
minutes.
So
let's
move
on
okay,
so
we're
going,
and
so
because
we
have
because
we
have
time
we
only
had
one
agenda
item
I
thought
that
we
would
continue
the
work
that
we've
been
doing
to
review
some
of
the
older
issues
that
we
have
so
that
we
can
make
some
progress
on
these
so
I
picked.
Some
I
picked
a
bunch
today
that
I,
hopefully
we
can,
we
can
get
through.
So
the
first
is
165.
A
It
was
created
in
the
very
early
days
of
the
Omar
project,
even
before
the
compiler
component
was
was
open
sourced.
So
just
after
the
the
initial
contribution,
this
is
really
just
a.
In
my
opinion.
At
least
it
seems
to
be
a
just
a
request
that
the
more
documentation
be
contributed
to
the
Omar
project.
A
There's
not
there
were.
There
were
a
couple
of
questions
in
there
about
like:
where
do
we
put
it
and
that
kind
of
thing,
but,
but
really
there
has
been
not
really
any
activity
in
there
for
almost
four
years
now
and
I'm.
Thinking
that
this
particular
one
well,
first
of
all,
what
is
the
purpose
of
this
of
this
particular
issue
anymore
and,
and
secondly,
you
know
I
think
that
it
could.
You
could
probably
be
closed.
I'm
not
I'm,
not
sure
that
it's
the
umbrella
document
for
for
for
documentation.
A
E
A
A
I'll
do
that:
okay,
okay
moving
on
to
214,
so
that
is
another
old
one.
Where
I
think
somebody
got
an
initial
look
at
the
Omar
project
when
it
was
first
created
and
they
discovered
that
there
wasn't
really
a
lot
of
documentation
on
what
platforms
it
was
supported
on
I.
Think
you
can
kind
of
derive
that
based
on
the
builds
that
are
happening
but
I
even
even
now.
I.
Don't
think
that
we
are
fairly
explicit
about
what
platforms
are
supported
and.
A
Yeah,
so
the
the
work
here
might
just
be
to
add
some
documentation
to
the
readme,
for
example,
that
really
just
describes
the
supported
platforms
and
and
go
from
there
so
I
don't
think
it
needs
to
be
closed,
but
I
think
that
the
direction
we
just
needs
to
be
clarified
a
bit.
What
the
next
step
here
is
any
comments
on
that
or
thoughts.
E
I
think
this
one
should
be
placed
on
the
backlog
and
the
reason
is
because
of
the
next
item
you
have
there.
So
unless
we
explicitly
state
which
platforms
we
support,
we
can't
drop
support
for
any
of
the
processors
that
we
claim
support
for
I
guess
this
is
kind
of
fitting
into
the
next
item.
For
examples
at
9
is
currently
not
supported
on
any
shipping.
Linux
distribution
of
maintaining
that
code
in
our
repository
is
probably
not
warranted,
but
I
can't
unless
we
clearly
state
that.
E
E
A
Okay,
the
other
thing
that
has
come
up
as
well
back
to
214
is
support
for
32-bit
platforms
and
and
where
we
are
with
that,
we
don't
really
know
minimal
testing
that
happens
on
x86,
but
I.
Don't
think
any
other
testing
happens
on
other
platforms
for
32-bit.
The
question
is
whether
or
not
that's
even
the
supported
configuration.
A
Okay,
so
we'll
keep
214
and
then
four
six,
six
seven
he
said
lines
at
ten
I
think
you
had
a
comment
and
they're
about
waiting
for
some
or
waiting
for
some
feature
to
be
tested.
That
was
a
about
three
years
ago,
other
than
the
documentation
aspect.
Is
there
something
else?
That's
you
need
to
happen
for
667
to
be
yeah.
E
A
A
Already,
let's
see
next
one
I
have
in
my
list,
is
670
and
I.
Don't
have
that
issue
in
front
of
me,
but
when
I
recall
this
was
a
someone
from
outside
the
the
usual
the
usual
project
members
that
came
belonging
into
third
Omar
and
was
asking
about
creating
a
DSL
that
would
feed
into
something
like
jet
builder,
and
they
had
some.
The
thinking
behind.
That
was
that
it's
it's
a
bit
easier
to
express
some
of
the.
A
A
This
might
require
a
bit
more
design
and
a
little
bit
more
research
in
order
to
get
it
done,
so
we
could
potentially
apply
a
research
tag
to
those
google
Summer
of
Code
labels
as
well,
but
I
wouldn't
necessarily
want
to
label
this
one
as
a
google
Summer
of
Code
item
just
because
it
I
don't
think
it
is
it's
just
there's
too
much
thinking
that
would
have
to
go
into
it
front.
Well,
that
to
happen.
A
F
I
think
this
one
is
a
dead
issue,
I'm
trying
to
sort
of
understand
what
does
these
cases,
and
maybe
one
interpretation
is
that
he'd
like
to
be
able
to
have
multiple
compiler
components
linked
into
a
single
VM
or
it
could
be
just
one
compiler
component
capable
of
consuming
yeah.
You
know
if
I
could
formats
it's
not
entirely
clear.
What
he's
asking
for
yeah.
D
Yeah,
the
only
thing
I'd
add
to
that
is
that
we
do
have
a
pull
request.
That's
languishing
from
one
of
the
chaos
projects,
which
was
the
tree
interpreter
for
the
JIT,
which
we
may
still
want
to
make
sure
we
get
around
to
merging
at
some
point.
I
just
wasn't
qualified
to
do
that,
because
I
was
involved
in
its
development,
so
I
don't
want
to
be
doing
a
soft
merge.
A
D
A
A
Okay,
the
next
one
is
1118,
which
was
a
question
again
from
the
community
asking
for
a
comparison
between
what
we
have,
what
we're
offering
in
omar
versus
what
is
available
in
in
truffle
and
gras,
and
john
duma
vich
wrote
up
a
very
nice
articulate
answer
to
the
to
the
question
and
I
think
that
there
was
some
further
disc
after
that
which
moved
which
moved
things
forward
as
well
I.
The
question
has
actually
been
answered
so
in
terms
of
what
was
originally
requested.
A
A
Yes,
so
I
think
the
answer
needs
to
have
a
home
somewhere.
It's
need
to
find
where
that
home
actually
is
I.
Think
at
the
very
least,
creating
a
document
that
lives
in
the
documentation
directory
or
in
the
readme
somewhere
that
describes
the
difference
would
be
would
be
helpful.
I
thought
we
did
start
an
FAQ
at
one
point,
though
I
must
be
thinking
of
something
else.
D
Well,
I
think
we
need
to
be
and
we
need
to
create
somewhere
where
we
can
use
those
kinds
of
compare
and
contrast,
because
I
mean
people
are
also
going
to
ask
about
how
OMR
compares
to
LLVM
or
how
Omar
compares
to
some
of
the
other
frameworks
that
are
out
there.
So
having
a
place
to
articulate
that
is
probably
sensible,
because
it's
kind
of
important
for
people
who
don't
know
what
Omar
is
to
be
able
to
figure
out
what
it
is
right
relative
to
other
things.
They
understand
right.
A
D
Mean
one
possibility
could
be
that
we
could
create
it
as
a
markdown
document
in
the
root
of
the
docs
folder,
just
kind
of
say
something
like
you
know,
comparison
compiler
frameworks
and
then
reference
it
from
the
readme
or
something
like
that's
right,
like
where
you're
saying
what
is
OMR
and
then
you
can
have
a
section
there.
That
says,
if
you're
already
a
a
compiler,
slash,
runtimes
aficionado,
look
here
for
a
comparison
to
other
frameworks.
So
you
can
understand
the
unique
value
proposition
of
Omar
or
something.
A
There
was
a
fair
bit
of
discussion
that
happened
in
this
in
this
issue,
a
lot
of
back-and-forth
between
mark
and
the
when
the
person
asking
the
the
question
in
the
end.
However,
what,
since,
since
this
question,
was
asked,
we
have
actually
gone
and
implemented
better
support
for
generating
elf
objects.
There
was
an
initial
implementation
done
around
the
time
of
this
question,
which
is
usable
and
then
a
couple
of
years,
back
Nazim
came
along
and
and
and
re-architected
that
a
bit
to
make
a
more
more
consistent
implementation
of
it,
a
more
usable
implementation
of
it.
A
So
that's
still
there.
We
do
have
limitations.
Obviously,
with
our
elf
support,
we
can't
we
only
do
code,
for
example.
At
this
point,
we
don't
support
data
relocations
or
anything
like
that,
but
for
the
for
the
purposes
of
this
question,
I
think
the
the
you
know
we
I
think
we've
answered
its
in
the
sense
that
we
we
do
want.
A
There
is
some
support
available
for
generating
elf,
but
I
think
the
broader
issue
of
work,
more
complete,
elf
support
still
needs
to
get
done,
and
so
perhaps
that
might
be
an
issue
unto
itself
rather
than
tacit
tacking
it
on
to
this
question.
So
the
rounding
of
the
support
for
health
would
be
one
of
the
ways
to
go.
A
One
of
the
things
that
we
had
talked
about
as
well
with
when
when
a
zine
was
looking
at
LL
JB
was
one
other
extension
of
that
would
be
to
actually
have
that
go
directly
to
an
object
file
so
that
you
can
link
it
against
other
things
and
and
use
it
in
other
kinds
of
comparisons.
So
that
could
be
a
further
extension
of
this
work.
Should
somebody
want
to
do
that.