<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'><div>> BYTESIZE(INTEGER)</div><div><br></div><div>I have other ideas here.</div><div><br></div><div><br></div><div> 1) Give up. Be like the 3.6 release and have target-specific boot archives, and target specific intermediate C, like current.</div><div><br></div><div><br></div><div> 2) kinda of compile everything twice. The generated C would be: </div><div><br></div><div> #ifdef _LP64_ // or such </div><div><br></div><div> ... </div><div><br></div><div> #else </div><div><br></div><div> ... almost but not quite the same .. </div><div><br></div><div> #endif </div><div><br></div><div>To cut down cost somewhat, rereading dead code, it could be:</div><div> foo32.c </div><div> foo64.c </div><div> foo.c </div><div> #ifdef _LP64_ </div><div> #include "foo64.c" </div><div> #else</div><div> #include "foo32.c" </div><div> #endif </div><div><br></div><div><br> 3) Sort of compile as always/only 64bit, when using C backend. <br> Specifically, in m3middle/Target.m3, when using C backend, setup 64bit types. </div><div><br></div><div><br></div><div> And in M3C output something like: </div><div><br></div><div> #ifdef _LP64_ /* or such -- not quite*/ <br> #define PAD64(x) /* nothing */ <br> #else <br> #define PAD64(x) int x##pad; <br> #endif </div><div><br></div><div> RECORD T1 = <br> a: REF INTEGER; <br> END; </div><div><br></div><div> => <br> struct T1 <br> { <br> INTEGER* a; <br> PAD64(a); /* after any pointer field in a record */ <br> }; </div><div><br></div><div><br> This is an efficiency loss on 32bit platforms but maybe ok. <br> It would gain a certain compatibility, i.e. in persistance formats. </div><div> Local variables not in a record..would possibly be put into such a record, depending</div><div> on if we could guarantee the entire pointer doesn't get overwritten..consider unusual valid Modula-3 such as:</div><div> Cstring.memset(ADR(ptr), 0, BYTESIZE(ptr)); </div><div><br></div><div><br></div><div> so we would have to pad out locals also. Possibly subject to #ifdef _LP64_. </div><div><br></div><div><br> Big problem here would be interfacing with actual C code.<br> For example Win32 and X Windows.</div><div> If not for that, I was thinking this is a very viable approach.</div><div> Given that, I'm not sure.</div><div><br></div><div> Maybe as I was saying really kind of preserve all constant expressions symbolically and let the C backend rerender them.</div><div>including stuff like:</div><div> a: ARRAY [0.. BYTESIZE(INTEGER)] OF CHAR. </div><div>or</div><div><div> a: ARRAY [0.. BYTESIZE(INTEGER) * 2] OF CHAR. </div><div>or</div><div><div> a: ARRAY [0.. (BYTESIZE(INTEGER) = 32) * 4 + (BYTESIZE(INTEGER) = 64) * 8] OF CHAR. </div></div></div><div><br></div><div>would have to be certain basically what is constant in Modula-3 is constant in C.</div><div><br></div><div> - Jay<br><br><br><br><br></div><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 17:02:37 +1000<br>CC: m3devel@elegosoft.com<br>To: jay.krell@cornell.edu<br><br><br><div><blockquote><div>On Aug 10, 2015, at 4:55 PM, Jay K <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:</div><br class="ecxApple-interchange-newline"><div><div style="font: 16px/normal Calibri; text-transform: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; white-space: normal;" 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></div></div></blockquote><div><br></div><div>The names are in the type.</div><br><blockquote><div style="font: 16px/normal Calibri; text-transform: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; white-space: normal;" dir="ltr"><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></div></div></div></blockquote><div><br></div><div>Yes.</div><br><blockquote><div style="font: 16px/normal Calibri; text-transform: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; white-space: normal;" dir="ltr"><div><div>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></div></blockquote></div><br></div> </div></body>
</html>