<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>As part of fixing this, I want M3CG_Ops.i3<div><span style="font-size: 12pt; "><br></span></div><div><span style="font-size: 12pt; ">declare_temp (s: ByteSize; a: Alignment; t: Type;</span><div> in_memory: BOOLEAN): Var;</div><div><br></div><div><br></div>to accept an optional m3t: TypeUID which can be either default to M3ID.NoID, if</div><div>that syntax is allowed, or all existing calls can initially pass M3ID.NoID.</div><div><br></div><div><br></div><div>The use in OpenArrayType.DeclareTemp will then be changed to something else.</div><div>DeclareTemp will look more like OpenArrayType.Compiler.</div><div><br></div><div><br></div><div>And, something will be done for jmpbufs, such having them be named and passing that name along</div><div>somewhere. Or giving them a special uid, or even their own special CG.Type?</div><div><br></div><div><br></div><div>And then, every use of CG.Type.Struct must come along with a TypeUID.</div><div><br></div><div><br></div><div>ok?</div><div><br></div><div>The C backend will/should actually be able notice the name of the jmpbuf type and substitute</div><div>in.. #include <setjmp.h> jmpbuf.</div><div><br></div><div>Other backends should substitute in the alloca use.</div><div><br></div><div>Or, it will be an internal parameter to the frontend for it to do the alloca transformation.</div><div><br></div><div>But this is getting ahead of things.</div><div><br></div><div>First -- change declare_temp to accept a TypeUID ok?</div><div><br></div><div><br></div><div><br></div><div> - Jay<br><br><br><div>> Date: Fri, 24 Jul 2015 09:57:37 -0500<br>> From: rodney_bates@lcwb.coop<br>> To: jay.krell@cornell.edu; m3devel@elegosoft.com; m3devel@elegosoft.com<br>> Subject: Re: [M3devel] better typing on SUBARRAY temporaries?<br>> <br>> <br>> <br>> On 07/24/2015 03:57 AM, Jay K wrote:<br>> > I model this in C like:<br>> ><br>> ><br>> > M3C.m3:<br>> > print(self, "/*declare_open_array*/typedef struct {");<br>> <br>> Presumably, this comment means you have some way of knowing, in M3C, that this is an open array?<br>> <br>> > print(self, element_type.text);<br>> > print(self, "* _elts; CARDINAL _size");<br>> > IF bit_size > Target.Integer.size * 2 THEN<br>> > print(self, "s[");<br>> > print(self, IntToDec((bit_size - Target.Integer.size) DIV Target.Integer.size));<br>> > print(self, "]");<br>> > END;<br>> ><br>> ><br>> > that is..and this i stinky that I get the struct "size",<br>> ><br>> ><br>> > size == 2 * sizeof(integer):<br>> ><br>> ><br>> > struct {<br>> > T* elements<br>> > size_t size;<br>> > }<br>> ><br>> ><br>> > else:<br>> > N = size - sizeof(INTEGER) / sizeof(INTEGER)<br>> > T ** elements; // where the number of star is N<br>> <br>> I would not do pointer to pointer to pointer ... here. Just "T* elements", regardless<br>> of the number of open dimensions. As I understand them, C's language-supported<br>> multidimensional arrays are like Modula3 multidimensional _fixed_ arrays, i.e.,<br>> the language does the multi-subscript address arithmetic, which means the type<br>> system needs to provide a static element size of each dimension. And that,<br>> except for the innermost, depends on the element count of the next inner<br>> dimension, which is not static here.<br>> <br>> So, the multiple dimensions are essentially flattened into one, and access to A[I,J,K]<br>> is lowered by the front end into explicit address arithmetic into the flattened<br>> array, using the values in the shape. Something like A[I*Shape[0]+J*Shape[1]+K]<br>> <br>> > size_t sizes[N]<br>> ><br>> ><br>> > It is kind of lame that the frontend just gives the overall size<br>> > and the backend is just left to assume the layout like that.<br>> <br>> If you know in M3C that it's an open array, you can infer what the layout is.<br>> But yes, it's kind of lame. This is just another of the several places we have<br>> seen that the front end has lowered things too far, and you have to<br>> You know it's generated by code in OpenArray.m3, and you know the general dope layout,<br>> and open dimension count, so you can generate an appropriate type.<br>> <br>> <br>> ><br>> > Really, the frontend should declare a type "pointer to pointer to pointer" with<br>> > the right "depth", and then a record with that pointer and a size or fixed size array of sizes.<br>> ><br>> ><br>> > Again, really ugly how it works now where backend is just given a size and can only<br>> > assume the layout.<br>> ><br>> > I don't know what a "dope vector" is. A value used as an initializer?<br>> ><br>> <br>> This is a very old and rather uninformative term for any block of stuff stored at runtime<br>> that describes some source programmer's real data and how to access it. The only alternative<br>> term I can think of would be "metadata", although that is rather overgeneral, and is usually<br>> used with quite different specific meanings. But it is data describing data.<br>> <br>> ><br>> > It is even worse for subarray. In this case we aren't even told it is an open array, just<br>> > some random struct with a size. That is what I first want to fix. It should declare an open array,<br>> > assuming they do have the same layout, which I think they do.<br>> ><br>> <br>> What you really need to know is that it's an open array, of which subarray is a subcategory.<br>> In our implementation, all open array values have the same dope. E.g., look for the case where<br>> a fixed array actual parameter is passed to an open array formal.<br>> <br>> ><br>> > subarray temporaries and jmpbufs are I believe the only place the frontend passes so little<br>> > type information.<br>> ><br>> ><br>> > For jmpbufs I'm hoping to notice their name, and, unfortunately expensive, replace them<br>> > with #include <setjmp.h> and jmpbuf, instead of just a struct with an array of bytes.<br>> ><br>> ><br>> ><br>> ><br>> > - Jay<br>> ><br>> ><br>> > > Date: Wed, 22 Jul 2015 19:30:12 -0500<br>> > > From: rodney_bates@lcwb.coop<br>> > > To: m3devel@elegosoft.com<br>> > > Subject: Re: [M3devel] better typing on SUBARRAY temporaries?<br>> > ><br>> > > I'm not exactly sure what you are asking, but here is some light on what<br>> > > you are seeing. These temporaries are exactly the dope the compiler uses<br>> > > to represent all open array values. First a pointer to the zeroth<br>> > > array element, then the "shape", as defined in M3 definition, 2.2.3, i.e.<br>> > > an array of element counts for each open subscript. For an open array<br>> > > parameter, this would be the machine representation of the parameter<br>> > > itself, authored in M3. (but passed by reference.) For a heap object,<br>> > > it is stored right before the elements themselves. For a SUBARRAY<br>> > > expression, it has to be a temporary. It also has to be constructed<br>> > > at the call site, as an anonymous temporary, when passing an entire fixed<br>> > > array to an open array parameter<br>> > ><br>> > > So, a good type for it might look like:<br>> > ><br>> > ><br>> > > RECORD<br>> > > Elements : REF ARRAY [0..Max, ... ,0..Max] OF ElementType<br>> > > ; Shape : ARRAY [0..OpenDepth-1] of CARDINAL<br>> > > END<br>> > ><br>> > > Max will be like the notorious TextLiteral.MaxBytes, i.e., we don't want any<br>> > > static limit here in the type of Elements, as it will be enforced dynamically,<br>> > > using Shape. But we don't want to just say REF ARRAY OF ElementType either,<br>> > > as this would mean another open array inside the dope, resulting in infinite<br>> > > recursion.<br>> > ><br>> > > On 07/22/2015 12:42 AM, Jay K wrote:<br>> > > > In the C backend I have a notion of "weak struct types" and "strong struct types".<br>> > > ><br>> > > ><br>> > > > "Strong" types have fields with types and names corresponding to the original Modula-3. i.e. they debug well.<br>> > > ><br>> > > ><br>> > > > "Weak" types have just arrays of characters (in a struct), sized/aligned to what the front end asked for. i.e. they debug poorly.<br>> > > ><br>> > > ><br>> > > ><br>> > > > Originally I had only weak types.<br>> > > > Ideally I have no weak types.<br>> > > > I'm down to very few weak types now.<br>> > > > I'd like to finish eliminating weak types.<br>> > > ><br>> > > ><br>> > > ><br>> > > > A quick investigation shows weak types come from open arrays and jmpbufs.<br>> > > > Open array temporaries from SUBARRAY specifically.<br>> > > ><br>> > > ><br>> > > ><br>> > > > Can we fix this?<br>> > > ><br>> > > ><br>> > > ><br>> > > > We have:<br>> > > > m3front/src/types/OpenArrayType.m3:<br>> > > ><br>> > > > PROCEDURE DeclareTemp (t: Type.T): CG.Var =<br>> > > > VAR<br>> > > > p := Reduce (t);<br>> > > > size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;<br>> > > > BEGIN<br>> > > > RETURN CG.Declare_temp (size, Target.Address.align,<br>> > > > CG.Type.Struct, in_memory := TRUE);<br>> > > > END DeclareTemp;<br>> > > ><br>> > > ><br>> > > > PROCEDURE Compiler (p: P) =<br>> > > > VAR size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;<br>> > > > BEGIN<br>> > > > Type.Compile (p.element);<br>> > > > CG.Declare_open_array (Type.GlobalUID(p), Type.GlobalUID(p.element), size);<br>> > > > END Compiler;<br>> > > ><br>> > > ><br>> > > > DeclareTemp is used in SUBARRAY expressions -- truly temporaries,<br>> > > > not variables authored by anyone in Modula-3.<br>> > > ><br>> > > ><br>> > > > Can this be easily fixed?<br>> > > ><br>> > > ><br>> > > > Thanks,<br>> > > > - Jay<br>> > > ><br>> > > ><br>> > > ><br>> > > > _______________________________________________<br>> > > > M3devel mailing list<br>> > > > M3devel@elegosoft.com<br>> > > > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel<br>> > > ><br>> > ><br>> > > --<br>> > > Rodney Bates<br>> > > rodney.m.bates@acm.org<br>> > > _______________________________________________<br>> > > M3devel mailing list<br>> > > M3devel@elegosoft.com<br>> > > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel<br>> <br>> -- <br>> Rodney Bates<br>> rodney.m.bates@acm.org<br>> _______________________________________________<br>> M3devel mailing list<br>> M3devel@elegosoft.com<br>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel<br></div></div> </div></body>
</html>