Alewife parser

[ghost]

I said last week I would write the parser for the concrete syntax for Alewife.

[ghost]

I have a parser that reads Hamlet files, including the existing caps.hl. This is undoubtedly not what we want going forward, but since we want to be compatible it's a starting point.

Where shall I put it? tools/alewife? tools/alewife/frontend?

[ghost]

(note that it has a certain amount of stuff it carries along with it for now, in order to be runnable)

[alexpatel]

Wonderful!

Either tools/alewife or tools/alewife/frontend, I only quickly threw together the directory structure today and was going to model off of the OCaml in bintools (but there really is no organization now).

[ghost]

I think I'll do frontend/. We should actually probably let Ming decide :-)

[alexpatel]

Okay, great, I moved the C AST things into backend/ as well

[alexpatel]

^^ @mwookawa

[ghost]

I pushed it to a branch.

[alexpatel]

Can you put it on Harvard-PRINCESS/Guppy instead of Harvard-PRINCESS/barrlefish? All our dev work so far has been there

[mwookawa]

tree notwithstanding, we do need to map out the intended semantics of all the little one-off qualifiers in the type declarations. i am seeing:

1. ensure that this mly parses caps.hl in the tree.
2. sketch out the intended semantics of hamlet's common case cap A from_self inherits B { lvaddr a1; }
3. enumerate and roughly define the qualifiers.. eg, 'eq', is_always_copy, is_never_copy, etc.

the major one I see not being able to express without also special casing something in alewife is qualifier that is being used to avoid splitting a single capability into two new capabilities with new types when retyping.

[ghost]

Here are the qualifiers on caps:

• is_always_copy
• is_never_copy
• from
• from_self
• abstract
• inherit
• can_retype_multiple

The is_always_copy/is_never_copy qualifiers are mutually exclusive and also can't be used at the same time as from or from_self. (The original hamlet parser tries to enforce this syntactically and makes a mess.) I don't have any idea what the intended semantics are, except that in the original hamlet code part of the implementation of inherit is tangled up in the parser.

The qualifiers on members:

• address
• size
• eq

where I have no idea what "eq" means, but IIUC the address and size qualifiers designate exactly one field and say that this field contains the address or size (respectively) of the underlying physical data. These properties can also be defined with (very limited) expressions.

What do you mean by "ensure that this mly parses caps.hl in the tree"?

(the branches should be fixed) (by which I mean I believe they are fixed, not that they still need to be)

[ghost]

There are three things that can/should be done with this grammar, none of which I assume are a high priority and all of which might be obsoleted by the coming Alewife concrete syntax:

1. Add an include syntax so we can put each machine's MD caps in a separate file, and (ideally) include them all at once so the main caps file doesn't have to be edited to add a new machine;
2. Strengthen the grammar so all the various caps on qualifiers can be stated in any order instead of having to be in the "right" order;
3. Fix caps.hl to not use "cap" as a field name as well as a reserved word in the syntax, and remove the corresponding workaround from the mly file.

Let me know if any of these are wanted, and when you have a concrete syntax (or AST declaration or both) for alewife let me know and I'll hook it up.

(I set it to you because it's awaiting your pleasure - set it back to me when the time comes)