<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> I guess we have other problems here -- packed records in the C backend.</div><div> But maybe we can provide some good value here.</div><div><br></div><div>In particular:</div><div><br></div><div> - I can put in the compiler-specific stuff, like:</div><div> #if _MSC_VER</div><div> #pragma pack(1)</div><div> #endif</div><div> at the top of every file.</div><div> Something for other compilers.</div><div> </div><div> - In the frontend, doing layout, if any padding is inserted</div><div> in a record, insert an array of chars.</div><div> </div><div> - generate static asserts that front end layout matches C layout</div><div> </div><div> OR maybe just accept C layout.</div><div> </div><div> </div><div> - Jay</div><br><br><div><hr id="stopSpelling">From: jay.krell@cornell.edu<br>To: hosking@purdue.edu<br>CC: m3devel@elegosoft.com<br>Subject: RE: [M3devel] Target.Allow_packed_byte_aligned<br>Date: Mon, 21 Sep 2015 14:41:02 +0000<br><br>
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style>
<div dir="ltr">I was asked what the point is: To have just one or two C outputs for distribution/bootstrapping.<div><br></div><div><br></div><div>Another option is I can verify that the n different outputs are the same and then eliminate them afterward.</div><div>i.e. verify this setting makes no different for wide swaths of code, but still leave it there for other code.</div><div><br></div><div><br></div><div>Again, per-target packing rules don't allow the records to be as easily written by one target and read by another. <span style="font-size:12pt;">Granted, such binary I/O is always problematic. Textual I/O is commonly used instead.</span></div><div><br></div><div><br></div><div> - Jay<br><br><br><div><hr id="ecxstopSpelling">From: jay.krell@cornell.edu<br>To: hosking@purdue.edu<br>CC: m3devel@elegosoft.com<br>Subject: RE: [M3devel] Target.Allow_packed_byte_aligned<br>Date: Mon, 21 Sep 2015 05:56:00 +0000<br><br>
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style>
<div dir="ltr">"stat" used to be packed and it was bad.<div>It is no longer.</div><div><div><br></div><div><br></div><div><div>Let's say I'm interfacing with hardware.</div><div>A lot of hardware can be presented to a variety of processors.</div><div>For example, every x86, amd64, arm32, and arm64 device probably has USB.</div><div>So target-specific rules don't help.</div><div><br></div><div><br></div><div>Let's say I'm interfacing with a file format.</div><div>Again, target-specific rules are clearly wrong.</div><div><br></div><div><br></div><div>The only place this really makes sense is interfacing</div><div>with things like x86 interrupt descriptor tables and such (which do have</div><div>unnatural layout I believe).</div><div>This can be handled by using chars and combing them, or</div><div>coming up with C code that uses whatever compiler-specific mechanism.</div><div><br></div><div><br></div><div>What is difficult to achieve is unnatural alignment and atomic access,</div><div>even though x86/amd64 I guess support that -- at least as long as you</div><div>aren't crossing a cache line. If you are crossing a cache line, then</div><div>I think one instruction is still going to exhibit non atomic access, at which</div><div>point you might as well read individual byte and reconstruct the larger integer.</div><div><br></div><div><br></div><div>And Modula-3 does have pragmas for types.</div><div><span style="font-size:12pt;"><* lazyalign *> and <* strictalign *></span></div><div><br></div><div><br></div><div>Arguably that is a better method -- as it might still give the same IR and C</div><div>across all targets.</div><div><br></div><div><br></div><div>As well, let's say I am defining a file format.</div><div>For this, it helps to have the same layout/alignment rules across all targets.</div><div>Though I'm torn on this -- the alignment of a 64bit integer should</div><div>typically be only 4 bytes on a 32bit target, so something like:</div><div><br></div><div>RECORD a: Ctypes.int; b:LONGINT END;</div><div><br></div><div>should/can be smaller on a 32bit target.</div><div><br></div><div>I believe with the changes I made years ago,</div><div>they will have the same layout, for better and worse.</div><div>Given that I can't likely unify IR/C for word size, maybe we should</div><div>fix that.</div><div><br></div><div>I should review the Win32 .i3 files for this, though it probably</div><div>doesn't occur, given the recentness of LONGINT.</div><div><br></div><div> - Jay<br><br><br><div><hr id="ecxstopSpelling">Subject: Re: [M3devel] Target.Allow_packed_byte_aligned<br>From: hosking@purdue.edu<br>Date: Mon, 21 Sep 2015 14:57:15 +1000<br>CC: m3devel@elegosoft.com<br>To: jay.krell@cornell.edu<br><br><div><br><br>Sent from my iPhone</div><div><br>On Sep 21, 2015, at 2:40 PM, Jay K <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:<br><br></div><blockquote><div>
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style>
<div dir="ltr">You mean, the source code will be in target-specific directories?<div>Isn't expected to be portable anyway?</div><div>Yet we should still provide a way to do it?</div></div></div></blockquote><div><br></div><div>Yes to all. M3 is meant to be a systems programming language and packed types are the way you handle layout for specific targets. Are you sure we don't have packed types in the libraries? I thought we used to.</div><br><blockquote><div><div dir="ltr"><div><br></div><div><br></div><div>I'm kinda keen on just not having them.</div><div>Very little code needs them.</div><div><br></div><div><br></div><div>I'd like to eliminate target-specificity, so that C code from the C backend</div><div>can be used to bootstrap any platform. I'm resigned to not quite make it there,</div><div>but I don't want unnecessary variation anyway.</div><div><br></div><div><br></div><div>I think can I decree the C backend is always big endian.</div><div>But word size I can't eliminate due to access to external data structures</div><div>with size_t/integer. So we'd always have at least two C targets -- 32bit</div><div>and 64bit.</div><div><br></div><div><br></div><div>Non-C targets can retain their "correct" endianness.</div><div>They don't interoperate anyway because of nested function implementation varying.</div><div><br></div><div><br></div><div>Again, this was only true for x86/amd64.</div><div>And there is a strange pragma to allow it on modules or types.</div><div>Instead of always on the target.</div><div><br></div><div><br></div><div>Allowing it on types is kinda close to what Visual C++ offers -- something scoped</div><div>instead of global.</div><div><br></div><div><br></div><div> - Jay<br><br><br><div><hr id="ecxstopSpelling">Subject: Re: [M3devel] Target.Allow_packed_byte_aligned<br>From: <a href="mailto:hosking@purdue.edu">hosking@purdue.edu</a><br>Date: Mon, 21 Sep 2015 14:30:15 +1000<br>CC: <a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>To: <a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br><br><div>Packed will generally be target-specific no?<br><br>Sent from my iPhone</div><div><br>On Sep 21, 2015, at 12:51 PM, Jay K <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:<br><br></div><blockquote><div>
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style>
<div dir="ltr">I don't believe this is portable.<div>Such code would only compile for x86/amd64 targets.</div><div>I think.</div><div>We want to cater to such target-specific constructs?</div><div>I should confirm it is target-specific?</div><div>I want to eliminate gratuitous target-specific aspects and devolve the IR to having essentially 3 variables -- word size and endian and NT vs. posix. Fewer if I can manage to.</div><div><br></div><div><br></div><div> - Jay<br><br><br><div><hr id="ecxstopSpelling">Subject: Re: [M3devel] Target.Allow_packed_byte_aligned<br>From: <a href="mailto:hosking@purdue.edu">hosking@purdue.edu</a><br>Date: Mon, 21 Sep 2015 12:47:07 +1000<br>CC: <a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>To: <a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br><br><div>Packed types are part of the language and their behavior should be preserved. Just because we don't use it on the libraries others do!<br><br>Sent from my iPhone</div><div><br>On Sep 21, 2015, at 12:19 PM, Jay K <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:<br><br></div><blockquote><div>
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style>
<div dir="ltr">I don't think so.<div>I built the system with it.</div><div>Granted, only one target.</div><div><br></div><div>If we had something like</div><div>TYPE T = BITS BITSIZE(INTEGER) + 8 FOR PACKED RECORD</div><div> a: CHAR</div><div> b:INTEGER</div><div>END;</div><div><br></div><div>I think it'd break that.</div><div>I'm not sure we any longer use packed types.</div><div>And such things would only work for x86/amd64 I believe.</div><div><br></div><div> - Jay<br><br><br><div><hr id="ecxstopSpelling">Subject: Re: [M3devel] Target.Allow_packed_byte_aligned<br>From: <a href="mailto:hosking@purdue.edu">hosking@purdue.edu</a><br>Date: Mon, 21 Sep 2015 10:44:59 +1000<br>CC: <a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>To: <a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br><br><div>We should be careful here. Might break something, no?<br><br>Sent from my iPhone</div><div><br>On Sep 21, 2015, at 2:53 AM, Jay K <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:<br><br></div><blockquote><div>
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style>
<div dir="ltr">I propose that Allow_packed_byte_aligned be set to FALSE for <span style="font-size:12pt;">all targets.</span><div><br></div><div>Or make it const.</div><div><br></div><div><br></div><div><span style="font-size:12pt;">Or remove it.</span></div><div><br></div><div><br></div><div>This will degrade slightly x86/amd64 but in, I speculate, fairly rare paths.</div><div>Specifically, if you manage to create a packed type with unaligned fields,</div><div>presumably loads/stores get converted to multiple aligned loads/stores followed</div><div>by putting stuff back together. The occurrence of the unaligned fields should</div><div>be very rare in the first place.</div><div><br></div><div><br></div><div><span style="font-size:12pt;">I does not affect any other target.</span></div><div><br></div><div><br></div><div>Granted, x86 and amd64 are the most common targets.</div><div><br></div><div><br></div><div>Ok?</div><div> - Jay<br><br><br></div> !
</div>
</div></blockquote><blockquote><div><span>_______________________________________________</span><br><span>M3devel mailing list</span><br><span><a href="mailto:M3devel@elegosoft.com">M3devel@elegosoft.com</a></span><br><span><a href="https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel" target="_blank">https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel</a></span><br></div></blockquote></div></div> </div>
</div></blockquote></div></div> </div>
</div></blockquote></div></div> </div>
</div></blockquote></div></div></div></div> </div></div></div> </div></div> </div></body>
</html>