On 04-Oct-2000, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > + % These instructions generate no actual code and do not affect
> > + % control flow, they are simply part of instr for
> > + % convenience.
> > +:- pred equivalent_to_nop(instr).
> > +:- mode equivalent_to_nop(in) is semidet.
> > +equivalent_to_nop(end_block(scope(_), _)).
> > +equivalent_to_nop(comment(_)).
> > +equivalent_to_nop(start_block(scope(_), _)).
> > +
> > + % These instructions can branch control flow.
> > +:- pred can_branch(instr).
> > +:- mode can_branch(in) is semidet.
> > +can_branch(br(_)).
> > +can_branch(brtrue(_)).
> > +can_branch(brfalse(_)).
> > +can_branch(beq(_)).
> > +can_branch(bge(_, _)).
> > +can_branch(bgt(_, _)).
> > +can_branch(ble(_, _)).
> > +can_branch(blt(_, _)).
> > +can_branch(bne(_, _)).
> > +can_branch(switch(_)).
>
> Experience has shown that for these kind of things it is generally
> better for maintenance to make them boolean functions rather than
> predicates, so that you get determinism errors if you add a new
> alternative and forget to update these procedures.
I agree. The problem is that there are around 100 IL instructions in a
very flat datatype, and there are 3 boolean functions we want to define.
Ah well, it's mostly cut and paste, so I'll do it now.
> > + % comments
> > + ; comment_term(term)
> > + ; comment(string)
> > + ; some [T] comment_thing(T).
>
> What requirements are there on `T' here?
> E.g. must it be a type for which `io__print' works?
> What if it is a higher-order type, for example,
> or a type which is or contains c_pointer?
`T' has to work with pprint__to_doc. I've added a comment to this
effect.
>
> > + ; wchar_ptr(string) % a string to convert to unicode
>
> Is the string supposed to be
>
> (a) composed of only 8-bit characters
> (b) composed of characters which might include unicode characters
> if/when the underlying Mercury implementation supports
> unicode in strings
> (c) unicode encoded in UTF-8
> (d) something else?
None of the above, wchar and unicode is not yet implemented. XXX has
been added.
> > + % a list of interfaces that we implement
> > + % XXX should probably just use an empty list to represent
> > + % noimplement
> > +:- type implements
> > + ---> implements(list(classname))
> > + ; noimplement.
>
> That XXX should be fixed at some point
> (not necessarily before committing it).
>
> > + % declarations that can form the body of a method.
> > +:- type methoddecl
>
> I think it would be clearer if that type was named
> `methodbodydecl' or (even better) `method_body_decl'.
>
> > + ---> emitbyte(byte) % raw byte output (danger! danger!)
>
> Are those bytes the IL binary representation, or are they x86 instructions?
The documentation says
"emits an int32 to the code section of the method".
So I think it's intended to be used for IL bytecode output. I should
change it to use int32, however (now done).
>
> > + ; maxstack(int) % maximum stack size (still needed?)
>
> What are the units -- bits? bytes? something else?
The documentation says
% "Defines the maximum size of the stack,
% specified by the int32"
and that's all she wrote.
I'll mark it with an XXX.
> > + % the body of a .data declaration
> > +:- type data_body
> > + ---> itemlist(list(data_item))
> > + ; item(data_item).
>
> Is there any difference in semantics between `itemlist([X])'
> and `item(X)'? If so, what is it? If not, why are there
> two different ways of representing the same thing?
The documentation says
<ddBody> ::= <ddItem> | { <ddItemList> }
The body consists of either one data item or list of data items
in braces. A list of data items is similar to an array.
And that's all.
So I think we can safely say "I have no idea". I'll put an XXX in
there.
> > +ilasm__output_decl(comment(CommentStr)) -->
> > + io__write_string("// "),
> > + io__write_string(CommentStr),
> > + io__write_string("\n").
>
> What if CommentStr contains newlines? If that is not allowed,
> it should be documented in the data type definition.
I've changed it to use the `label' feature of pprint.m so you can
have newlines in your comments if you wish. Also I've fixed this
elsewhere.
(more to come, including a new relative diff).
--
Tyson Dowd #
# Surreal humour isn't everyone's cup of fur.
trd at cs.mu.oz.au #
http://www.cs.mu.oz.au/~trd #
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to: mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions: mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------