[m-dev.] for review: The .NET MSIL backend.

Tyson Dowd trd at cs.mu.OZ.AU
Fri Oct 6 19:30:30 AEDT 2000


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
--------------------------------------------------------------------------



More information about the developers mailing list