<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'>Interesting. I hadn't thought of that.<div><br></div><div>We do "need" symbolic names. Well..they could be omitted, but:<div><br></div><div> - Having symbolic names is great for debugging, vs. making up names.</div><div><br></div><div> - This assumes between C and Modula-3 the rules for the naming are close enough.</div><div> I already handle things like if you have a record field named "int", I change it.</div><div> For every reserved word as far as I knew (something I needs to be checked against K&R, ANSI, and C++latest).<br><br>This idea of "nth" then unifies constant array indices with record fields?<br>I would have likely had two parameters, a string/id and an integer.</div><div>Or two different functions.</div><div><br></div><div>Oh..I guess this isn't to avoid the strings, but pass them when defining the type,</div><div>and not repeatedly for access?</div><div><br></div><div><br></div><div>> BYTESIZE(INTEGER)</div><div><br></div><div>I know this is trickier but I consider it almost the same problem.</div><div><br></div><div>Imagine I have this C code:</div><div><br></div><div>typedef struct T1 { size_t a,b; } T1;</div><div>T1* pt1;</div><div><br></div><div>pt1->b</div><div><br></div><div>(*size_t*)(((char*)pt1) + sizeof(size_t))</div><div><br></div><div><br></div><div>while the second is not idiomatic, and may skirt alignment/padding rules (imagine if a was a char and b a size_t), it is just about as portable.</div><div><br></div><div><br></div><div>And you can write Modula-3 that way, with LOOPHOLE, ADR, BITESIZE, etc.</div><div><br></div><div><br></div><div>I think "expressions" or "constant expressions" need to be maintained in "string" or "structural" form and passed to the backend...</div><div>"string" would be, like, the original Modula-3.</div><div>"structural" would be parse them and make an "expression tree" with nodes like plus, minus, multiplication, division.</div><div><br></div><div><br></div><div>I think, perhaps, the expression tree would be optional. Backends that ignore them could say so and save that cost.</div><div><br></div><div>I believe most/all Modula-3 constant expressions render trivially in C.</div><div><br></div><div>Really, like,</div><div>RTIO.PutInt(BYTESIZE(INTEGER));</div><div><br></div><div>ideally translates to C involving the string/type "INTEGER", and not INT32 or INT64.</div><div><br></div><div>I have to go.</div><div><br> - Jay<br><br><div><hr id="stopSpelling">Subject: Re: [M3devel] "get member reference" /load/store(field name)?<br>From: hosking@purdue.edu<br>Date: Mon, 10 Aug 2015 14:37:03 +1000<br>CC: m3devel@elegosoft.com<br>To: jay.krell@cornell.edu<br><br><br><div><blockquote><div>On Aug 10, 2015, at 2:23 PM, Jay K <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:</div><br class="ecxApple-interchange-newline"><div><div dir="ltr" style="font-family:Calibri;font-size:16px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;">I want load/store of field names, or of constant array indices, to include a string or M3.ID indicating the field name.</div></div></blockquote><div><br></div>A cleaner solution is to use types and request the nth field of the type, etc. That way we don’t need symbolic names for the fields.</div><div><br><blockquote><div><div dir="ltr" style="font-family:Calibri;font-size:16px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;"><div>This way, the C backend can avoid hardcoding the offsets. A step toward target-independent generated C.</div><div><br></div><div>Ok?</div><div><br></div><div><br></div><div>Similarly, I want expressions involving BYTESIZE(INTEGER) or BITSIZE(INTEGER) or BYTESIZE(pointer) or BYTESIZE(RECORD or ARRAY involving INTEGER or pointer) etc. to be in a state that the C backend can render them in a target-independent way. Thoughts?</div></div></div></blockquote><div><br></div><div>That is a bit trickier if not impossible. Modula-3 inherently exposes these as compile-time integer constants.</div><div><br></div><blockquote><div><div dir="ltr" style="font-family:Calibri;font-size:16px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;"><div><br></div><div>Basically, I want to generate one version of C that works on all targets.</div><div>Currently we are far from that, and it isn't easy.</div><div>The jmpbuf change was a small step in that direction.</div><div><br></div><div><br></div><div> - Jay<br><br><br></div></div><span style="font-family:Calibri;font-size:16px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;display:inline !important;">_______________________________________________</span><br style="font-family:Calibri;font-size:16px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;"><span style="font-family:Calibri;font-size:16px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;display:inline !important;">M3devel mailing list</span><br style="font-family:Calibri;font-size:16px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;"><a href="mailto:M3devel@elegosoft.com" style="font-family:Calibri;font-size:16px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;">M3devel@elegosoft.com</a><br style="font-family:Calibri;font-size:16px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;"><a href="https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel" style="font-family:Calibri;font-size:16px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;" target="_blank">https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel</a></div></blockquote></div><br></div></div></div> </div></body>
</html>