►
From YouTube: OMR Architecture 20191010
Description
Agenda:
* OMR default components
* OMR API documentation
* OS macro usage
B
Everyone
to
this
week's
Omar
architecture
meeting
this
week
we
have
three
topics:
to
discuss:
I'm
going
to
depart
a
little
bit
from
the
order
in
which
I
have
the
agenda
I'm
going
to
talk
about
2257
first,
so
we'll
get
right
into
that.
So
2257
is
about
applying
the
consistent
use
of
OS
macros
throughout
the
Omar
component.
B
If
you
look
at
the
way-
and
this
really
originated
from
the
compiler
component
and
the
way
that
there
are
a
number
of
uses-
evicted,
many
variations
of
operating
system-
macros
that
are
being
used
throughout
the
compiler
and
early
on
in
the
compiler
development
we
this
is
before
it
was
actually
open
sourced.
We
created
a
number
of
sort
of
standard
macros
that
we
wanted
to
be
able
to
use
when
referring
to
Linux
or
Windows
or
Mac
OS.
B
That
kind
of
thing
and
we
wanted
to
deploy
those
throughout,
but
we
never
actually
did
since
then
I
thought
that
so
it
made
a
good
suggestion
that
we
should
probably
apply
this
throughout
OMR
and
then
looking
throughout
the
rest
of
the
components
in
OMR,
especially
the
port
library.
There
seem
to
be
a
very
wide
spectrum
of
operating
system,
macros
that
are
that
are
being
used.
B
So
what
I'd
like
to
propose
is
that
we
take-
let's
say
the
ones
that
we
have
for,
that
we've
already
got
for
the
compiler
and
then
make
them
more
general
make
them
as
available
as
part
of
a
general
include
that
can
be
used
throughout
the
rest
of
the
code
base.
So
that
way,
for
example,
our
underscore
Linux,
rather
than
j9
OS,
Linux
or
Magina,
and
PowerPC
Linux.
That
kind
of
thing,
so
that's
one
spect
of
it.
The
other
is
whether
or
not
those
OS
macro
should
actually
be
combined
with
other
architecture
macros
as
well.
B
So,
for
example,
the
combining
Linux
with
PowerPC
Linux
for
PowerPC
64
I,
like
the
readability
of
that,
but
I'm
I'm,
less
sold
on
the
I'm
less
sold
on
that
I
think
maybe
just
to
begin
with.
Let's
have
a
discussion
about
just
the
OS
macros,
simple,
the
consensus
on
that
and
then
I
think
can
go
from
there.
So
anybody
have
any
thoughts
on
that.
D
B
There's
a
couple
of
things,
so
one
are
the
macros
that
the
different
built
compilers
use
to
distinguish
operating
between
operating
systems.
There
is
some
some
consistency
between
those,
but
given
the
breadth
of
the
compilers
that
Folmar
builds
with.
There
are
some
that
don't
support
all
of
those
there's
actually
a
sort
of
a
standard
list.
You
can
find
some
page
somewhere
online
that
describes
all
the
compilers
here's
here's,
what
the
standard
macros
are.
B
There
are
ones
that
seem
to
be
originating
from
j9
where,
but
but
there's
nothing
really
j9
specific
about
it
right
so
that,
like
they
use
j9
Linux
something
hurricane
on
hammer
or
something
like
that,
so
those
are
like
a
non
hammer
is
basically
sending
in
for
x86
64
right,
so
so
I
think
undoing.
Some
of
that
as
well,
would
provide
a
bit
of
clarity.
D
B
So
this
issue
was
originally
created
to
do
that.
Okay,
writing
and
then
I.
Remember
this
one
and
someone
actually
came
along
and
took
on
that
PR
and
or
took
on
that
issue
and
and
did
some
work
for
that,
and
then
we
decided
that
it
might
be
worth
to
go
beyond
that
so
throughout
the
rest
of
the
code
base.
B
D
D
B
E
D
B
E
F
F
G
G
Mean
the
other.
The
other
question,
though,
is
like,
if
you're
going
to
build
you're
going
to
do
across
compiled
compiler
that
you
are
using
necessarily
has
to
define
the
right
sort
of
built-in
macros
for
the
target
plastic
so
doing
it
based
off
of
rather
than
even
doing
it
in
the
configure
doing
it
off
of
what
does
this
compiler
actually
say?
You
be
more
consistent
right.
Just
for
clarity.
Are
we
asking
about
cross
compiling
omr
itself
or
compiling.
D
Age,
so
I
was
asking
okay,
so
like
is
it,
it
seems
to
me
like
something's.
He
makes
should
pass
him
or
whatever
the
configure
in
like
it.
It's
the
thing,
that's
typically
detecting
what
the
platform
is
a
dealing
with,
with
how
you're
how
you're
going
to
build
a
wall
or
wouldn't
that
be
a
more
natural
place
to
be
defining
the
old,
are
so.
D
And
then
that
would
be
like
it
would
generate
a
header
file
that
would
be
rather
than
having
a
master
header
file
that
has
some
crazy
mix
of
whole
pound
of
deaths,
things
that
someone
would
have
to
decode
all
the
time
to
figure
out
what
the
hell's
going
on
the
same
logic
would
probably
existence
you
make.
So
he
wouldn't
that
yeah,
but
it's
more
always.
D
B
I
B
G
Blank
macro
where
he
was
just
mean,
but
we
have
a
standard
list
of
the
means
for
the
OS
as
an
expanded
list
of
the
means
for
the
architectures.
If
you
just
plug
those
in,
you
could
fill
the
appropriate
and
annan
and
whatever
so
that
we
want
to
go
and
change
how
any
of
this
is
factored
later
on.
You
don't
have
to
go
and
do
it
everywhere
in
the
codebase
right.
So
you
just
let
the
preprocessor
expand
the
thing
into
the
appropriate
logical
expression
rather
than
baking
it
in
everywhere.
G
So,
like
you
can
leave
some
of
the
prefixes
and
stuff
off
cause,
you
could
toke
and
paste
them
in
just
go.
You
know
test
and
you
know
test
environment
or
test
whatever
we
call
it
when
it
come
a
PPC
64
right
and
there
could
even
be
some
other.
Oh,
you
could
have
some
variants
that
have
additional
parameters.
Berg
we're
still.
You
know
if
you're,
if
you
have
other
well.
G
You
don't
have
to
worry
about,
should
I
be
doing
if
death
or,
if
defined
or
all
that
other
we're
contes
so
pounded.
The
only
other
crap
that
comes
up
when
you're
dealing
with
s
III
processor
am
on
board.
With
that
some
of
those
function
makers
would
be
a
little
ugly,
cuz
you'll.
Have
that
token
pasting
other
things
to
make
it
work,
but.
G
G
B
Okay,
so
I'll
summarize
what
we've
talked
about
here
in
the
issue
itself
and
probably
broaden
the
scope
of
it
I
know:
there's
a
PR
I'll
have
to
sort
of
see
the
PR
that
was
open
against
it
already
just
to
sort
of
be.
If
there's
some,
hopefully
the
be
some
code
that
can
be
salvaged
from
that
from
that
PR
still,
but
is
there
any
other
discussion
that
anybody
wants
to
have
on
this?
E
Think
one
of
the
things
that
I
would
be
concerned
about
in
a
lot
of
the
non
compiler
code
since
we're
expecting
the
platform
definitions
to
come
from
the
command
line.
Sometimes
we
might
be
testing
what
platform
were
on
before
we've,
including
Omar
config
H.
So
if
the
configuration
header
is
what's
specifying,
what
platform
we're
building
for
I
don't
know.
E
Sort
of
worried
that
there
might
be
places
where
we
have
to
move
the
configuration
header
earlier
into
a
file
and
I
think
maybe
we
should
talk
about
adding
it
to
our
coding
conventions
that
at
the
top
of
every
header
we
should
be
including
Omar
config.
Instead
of
putting
Omar,
can
think
in
alphabetic
order.
E
G
B
D
D
D
D
Talk
to
too
many
Americans,
and
so
it
just
kind
of
raised
a
you
know.
His
main
point
was
that
he
got
caught
by
surprise
by
those
build
dependencies
because
they
hadn't
been
documented
anywhere
and
they
weren't
part
of
our
documentation
for
what
needed
to
be
installed
in
a
system
in
order
to
do
a
build
and
he's
right.
It
was
right
and.
D
So
there's
there's
this
document
building
with
C
Bank
that
we
have,
which
does
talk
about
a
few
of
the
component
variables
that
you
use
when
you're
trying
to
configure
Omar
to
be
built,
but
I,
don't
think
that
documentation
has
sufficient
detail
on
what
are
the
available
variables
that
you
can
use?
What
are
their
default
settings
in
Omar
and
what
are
the
implications
with
are
any
on
divinities
when
you
activate
certain
components
and
so
I.
D
This
issue
that
I
opened
was
around
trying
to
figure
out.
You
know
shouldn't
we
really
be
documenting
all
of
that
stuff.
I,
don't
know
if
it
needs
to
go
into
building
what
see
make
or
it
could
be
in
its
own
independent
document,
but
it
seems
like
for
consumers
of
the
Omar
project.
This
is
important
information
to
know
what
your,
what
what
components
you
need
to
specify.
If
you
want
to
build
it
for
your
youth
case,
I
guess
there's
also
kind
of
a
question
that
came
up
in
the
in
the
specific
DDR
discussions.
D
D
B
Think
that
my
personal
preference
is
that,
because
we
often
market
this
as
a
tool
box,
so
to
okay,
whoever
pick
and
choose
the
components
you
want.
If
you
are
picking
and
choosing,
you
should
therefore
pick
and
then
enable,
as
opposed
to
getting
the
entire
hardware
store
and
then
removing
right
sections
that
you
don't
want.
D
There's
a
separate
discussion
here
which
Keith
raised
in
the
solving
to
is
that
we
want
to
make
sure
that
we're
still
testing
everything.
Even
if
we
were
to
disable
everything
you
want
to
make
sure
that
we're
still
testing
everything.
I
think
I'd
like
to
consider
that
a
separate
issues
like
that's
kind
of
what
Flags
do
we
turn
on
in
our
poll,
requests
testing
to
make
sure
that
we're
not
breaking
anything
versus
what
do.
What.
B
What's
the
experience
that
people
get
when
they
try
to
consume
the
program,
the
other
thing
is
perhaps,
as
part
of
the
documentation
is,
what
are
the
flags
you
have
to
specify-
let's
say
Alice,
emic
and
like
to
actually
enable
that
component,
that
you
want
right.
I
know
that
for
the
like
the
compiler
test,
it's
not
that
obvious
that
you
have
to
also
specify
other
components,
and
maybe
that's
also
part
of
the
documentation,
the
dependencies
so
so
having
that
specified
summer.
B
A
D
So
I
think
we
need
I,
mean
I.
Think
one
of
the
two
defaults
either
the
two
defaults
is
probably
fine.
I
think
there's
been
some
of
the
I
confess
I,
like
Darryl's
argument
that
if
we're
arguing
at
the
toolbox
we
shouldn't
be,
you
know
putting
a
hammer
and
a
saw
and
a
screwdriver
and
a
jigsaw,
and
you
know
just
crowbar
into
your
hands
and
asking
you
to
figure
out
which
you
need
to
use.
D
B
E
E
Yeah
other
other
than
that
you
can
you're,
usually
pretty
free
to
enable
or
disable
components
as
you
want.
I
did
write
a
small
utility
that
can
check
to
make
sure
that
component
prerequisites
are
satisfied,
but
then
we
never
actually
went
to
go.
Use
it
because
we're
looking
to
look
at
possibly
changing
the
way
that
the
build
system
works
so
that
there
are
no
global,
build
plagues.
E
How
that
who
will
know
what
the
dependencies
were?
You
specified
the
dependencies,
so
you
admit
you
know
the
GC
requires
that
the
port
is
on
and
the
example
requires
that
the
GC
is
on.
And
then,
if
you,
if
the
user
specifies
a
set
of
flags,
that's
invalid,
then
it
would
air
out
in
when
C
makers
running-
and
we
just
tell
you
about
like
what
dependencies
were
missing.
B
E
Well,
how
I
guess
it
depends
on
how
you
want
it
to
work
if
I
enable
a
component,
but
then
I
don't
enable
its
dependencies.
I
want
that
component
to
automatically
enable
them
and
then
can
I
somehow
force
the
build
into
a
state
where
it's,
where
it
has
an
invalid
configuration
or
I,
don't
know
it
just.
It
depends
on
how
you
really
want
these
things
to
work.
We
think
of
you
was
able
to
component.
You
want
its
dependencies
to
be
enabled
I,
don't
know
what.
I
I
D
J
D
Mean
people
shouldn't
have
to
figure
out
that
Gigi
is
dependent
on
important.
Even
if
there's
an
error
message,
it
comes
out.
So
you
you
dummy,
you
didn't
specify
that
port
and
thread
were
there
and
she
depends
on
port
threat
like
the
most
natural
thing
is
you'd
write,
the
GC
depends
on
port
so
that
then
you'll
add
the
port
flag
and
then
you'll
say
dummy
port
needs,
bread,
add
threat
and
alright,
like
this
sorry
yeah,
oh
right,
no
I,
don't
think
it's
just.
D
E
B
D
G
D
It
seems
to
me
it's
not
necessarily
a
component
now
enablement
a
feature
flag
or
something
like
that
and
really
do.
We
really
need
to
distinguish
components
from
features.
I
don't
know
what
like.
If,
then,
you
really
need
any
different
frame.
I
want
dr
I.
Don't
want
DDR
I
want
CUDA
I
don't
want
to,
though
I
don't
know
that
we
need
to
distinguish
components
from
features,
but
I
think
it
should
be
I.
Think
people
should
be
able
to
say
I,
don't
want
CUDA
and.
D
F
D
E
B
D
E
Because
the
computer
would
have
to
specifically
develop
support
for
the
garbage
collection
policy
which
involves
new
glue.
You
know
changes
in
in
the
consuming
application,
so
it's
not
something
that
can
just
sort
of
be
enabled
without
developing
support,
for
so,
at
least
in
the
case
of
GC
policies.
Those
would
be
by
default
and
a
user
would
have
to
specifically
opt
into
them
and,
as
a
part
of
that
developed
support
for
the
policy.
G
G
D
C
D
What
are
what
what
do
you?
What
do
we
think
should
be
in
able
from
that's
kind
of
the
spectrum
of
what
we
think
should
be
enabled
disabled
bowl
at
the
team,
a
command-line
versus?
What
would
you
you
know,
implement,
for
example,
and
optimizer?
That's,
you
could
be
filed
it
with
make
the
strategies
that
you
implement
the
strategies
on
the
optimization
that
you
really
care
about.
D
B
This
is
for
the
purposes
of
this
discussion.
We
were
talking
about
the
major
components
as
opposed
to
the
I.
Think
the
enabling
finer-grained
is
a
much
a
discussion
that
we
we
need,
a
lot
more
thought
into,
and
definitely
a
separate
discussion,
because
there
are
some
gray
areas
to
like,
but
you
just
came
up
with
GC
there
right
traducción,
but
it
also
needs
features,
enabled
and.
B
D
B
Still,
don't
know
what
you
mean,
but
I
think
I
think
everything
should
be
off
by
default
and
I
agree
with
the
statement
as
well
that
it's
a
separate
story
for
testing
really
good.
That's
a
different
answer
for
testing
testing.
Yes,
we
should
make
sure
that
anything
that
we
any
components
that
we
provide
are
enabled
in
some
way
and
we
have
tests
that
run
against
them,
so
they
don't
go
stale.
Oh.
G
E
G
E
So
one
other
thing
that
I
just
want
to
float
out
there
is
that
NC
make
it's
possible
to
do
a
test
in
omr
to
see
if
OMR
is
the
top-level
project
or
if
it's
a
subdirectory
of
a
bigger
project.
So
one
thing
that
we
can
look
at
doing
is:
if
Omar
is
a
top-level
project,
we
could
enable
the
bundle
consumers
that
we
have
in
Omar.
So
we
can
say,
like
okay,
we've
detected
your
building,
Omar
standalone,
so
we're
enabling
the
example
and
ship
builder
and
the
test
compiler
and
the
FV
+
FV
testing.
D
E
That
point
no
well
you
actually
at
least
I,
don't
know
about
the
compiler
but
see
if
you
want.
If
you
want
to
enable
the
GC,
you
need
to
provide
glue
and
the
way
you
provide
glue
is
through
C
make.
So
you
still
need
to
write
like
a
C
make
wrapper
project
to
install
the
glue
into
the
GC.
So
you
can't
just
have
a
make
file
to
build
Omar.
A
D
So
I'm
not
convinced
that
that
I
mean
that's
not
the
case
for
the
compiler
right.
You
can
just
build
a
ship
builder
and
then
you
can
just
use
just
builder
independently.
You
don't
need
it.
You
can
just
run
C
mate
with
a
Nomar
directory
and
wherever
and
then
take
the
JIT
builder
library.
Out
of
that.
E
E
Down
that
so
I
guess
I
just
thought
that
it
might
be
easier
for
you
know
if
we're
trying
to
demo
JIT
builder
to
people
it's
easier
for
people
to
say
download
this
run,
so
you
make
run
the
build
and
there's
no
configuration
that
they
need
to
provide
it.
Just
sort
of
works
and
ship
builders
on
by
default,
for
the
people
who
wanted
it
and
for
the
people
who
are
using
home.
B
C
D
C
E
C
A
B
D
D
G
I
guess
the
question
is:
are
any
of
these
components
that
we're
needing
to
build
against
also
runtime
dependencies?
If
they
are,
then
there
should
be
a
dependencies
on
MD
or
something
saying
if
your
own
are
was
built
with
this
support.
You
require
this
thing
to
be
available
in
the
environment
if
we
aren't
making
it
up.
Oh
you're,
Heather
right
now
with
kudos
I
cancer.
D
D
G
Guess
my
what
I
was
trying
to
express
was
that
if
the
dependency
may
manifest
as
a
runtime
dependency,
there
should
be
a
top-level
markdown
file
with
that
list
of
dependencies
and
under
what
circumstances
it's
required
and
what
the
error
looks
like.
If
you
don't
have
it
and
then
in
the
teammate
file.
Anything
that's
good.
As
a
good
point
builds.
Those
aren't
see
make
right
on
that's
because
if
you
make
it's
an
aspect
of
creating
the
build
environment,
come
on,
that's
why
even
the
run
environment
or
Omar
you
build
the
demo
and
then
stuff.
G
F
E
D
Anyway,
if
you
have
a
test,
failure
on
say,
Linux
and
you
work
on,
say,
Mac
OS,
because
you
don't
have
a
Linux
box,
recreating
that
environment
from
scratch
to
run
that
test
and
duplicate.
The
failure
is
not
always
easy,
so
I
created
that
dumper
container,
which
has
a
do
build
in
it,
so
it'll
just
pop
up
to
a
building
those
sit
there
and
do
whatever
you
want.
D
B
D
D
You
know,
sort
of
track
down
where
I
knew
the
words
there
was
documentation
and
a
bunch
of
the
header
falls
invitation
ball,
but
it's
kind
of
spread
out
and
spread
throughout
the
components
that
are
that
are
there
so
I
think
we
should
probably
spend
some
time
trying
to
collect
together.
Some
of
that
documentation
is
not
very
complete
either
it's
their
dotted
and
comments
in
there
that
we're
a
document,
a
parameter
by
specifying
its
name
and
that's
the
documentation
for
the
parameter.
D
So
that's
not
ideal,
even
though
in
most
cases
it's
pretty
easy
to
reason
about
what
that
friend
or
is.
We
should
probably
do
better
than
that.
So
I
think
ahead
of
the
next
release.
Whenever
that
is,
that's
I
guess
a
topic
for
the
next
one
of
these
meetings.
I
think
I
think
we
should
try
hard
to
collect
together,
API
documentation
for
port
thread
and
util
and
and
try
to
put
that
somewhere
so
that
we
can.
D
D
The
main
question,
I
guess,
is
who's
going
to
do
that
and
I
don't
think
we're
going
to
have
a
release
in
the
next
two
weeks.
So
it's
like
it's
not
like
urgent
urgent
that
we
do.
This
I
think
our
next
release
is
likely
to
be
at
least
a
month
or
two
away
at
least,
but
we
have
to
discuss
that
and
I
think
we
do
need
to
schedule
this
work.
D
G
B
B
I
think
that
yeah
I
mean
terms
of
document
in
the
API
me
I
think
it
might
like
at
some
point
the
compiler
is
going
to
become
an
epi
stable
whatever.
That
means,
but
I
think
that
whatever
that
means
might
be
influenced
about
by
how
like
we
need
to
think
about
how
we're
actually
gonna
exposed
the
API
to
the
compiler
right,
I,
don't
know
if
you'd
actually
quite
done,
that
yes
there's
but.
B
D
By
the
next
meeting,
no
I
don't
know
we
don't
do
anything
but
the
next
release.
Well,
there's
we
need
to
discuss
what
what
we're
going
to
do
with
over
leave
is
going
forward
right.
So
we
just
put
out
server
got
1.0
as
kind
of
stake
in
the
ground.
Here
are
here's
where
we
are
I
think
we
need
to.
We
need
to
have
a
discussion
around.
How
are
we
going
to
do
release
going
forward?
Are
we
going
to
time
box?