<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'>I model this in C like:<div><br></div><div><br></div><div>M3C.m3:</div><div><div>        print(self, "/*declare_open_array*/typedef struct {");</div><div>        print(self, element_type.text);</div><div>        print(self, "* _elts; CARDINAL _size");</div><div>        IF bit_size > Target.Integer.size * 2 THEN</div><div>            print(self, "s[");</div><div>            print(self, IntToDec((bit_size - Target.Integer.size) DIV Target.Integer.size));</div><div>            print(self, "]");</div><div>        END;</div><div><br></div><div><br></div><div>that is..and this i stinky that I get the struct "size",</div><div><br></div><div><br></div><div>size == 2 * sizeof(integer):</div><div><br></div><div><br></div><div>struct {</div><div>T* elements</div>size_t size;</div><div>}</div><div><br></div><div><br></div><div>else:</div><div> N = size - sizeof(INTEGER) / sizeof(INTEGER)</div><div> T ** elements; // where the number of star is N</div><div>  size_t sizes[N]</div><div><br></div><div><br></div><div>It is kind of lame that the frontend just gives the overall size</div><div>and the backend is just left to assume the layout like that.</div><div><br></div><div>Really, the frontend should declare a type "pointer to pointer to pointer" with</div><div>the right "depth", and then a record with that pointer and a size or fixed size array of sizes.</div><div><br></div><div><br></div><div>Again, really ugly how it works now where backend is just given a size and can only</div><div>assume the layout.</div><div><br></div><div>I don't know what a "dope vector" is. A value used as an initializer?</div><div><br></div><div><br></div><div>It is even worse for subarray. In this case we aren't even told it is an open array, just</div><div>some random struct with a size. That is what I first want to fix. It should declare an open array,</div><div>assuming they do have the same layout, which I think they do.</div><div><br></div><div><br></div><div>subarray temporaries and jmpbufs are I believe the only place the frontend passes so little</div><div>type information.</div><div><br></div><div><br></div><div>For jmpbufs I'm hoping to notice their name, and, unfortunately expensive, replace them</div><div>with #include <setjmp.h> and jmpbuf, instead of just a struct with an array of bytes.</div><div><br></div><div><br></div><div><br></div><div><br></div><div> - Jay<br><br><br><div>> 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></div></div>                                         </div></body>
</html>