<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>
The cross-wordsize problem of gcc was indeed lame, but it is long since gone.<br><br><br> Gcc has an almost-great cross-build story. <br> Ld has a good cross-build story. Though it doesn't support as many systems as gcc. <br> The problem is getting headers and libraries. <br> I've been trying to a build ia64-linux toolset from source but I haven't gotten glibc/linux-headers to work out. <br> Producing .S and .o from .c (w/o #include) is easy enough. <br><br><br>On Windows, cross-compilers are now also common, a lot of the tools are x86-hosted despite targeting AMD64, IA64, and more (Windows CE: PowerPC, MIPS, ARM, SH.)<br>Though I think NT/MIPS, NT/PowerPC, NT/Alpha had only native compilers released -- presumably there were cross compilers at least for bootstrapping.<br><br><br>Anyway, if you just conserving space, then "BITS FOR" should work fine.<br>If you need to interface with C, and you can't change the C, you should be able to get something to work, but it will possibly be somewhat non-portable, esp. endian-specific.<br>I think besides endianness, there is another factor, where cm3 tries to be C-compatible.<br>Like, how aligned bitfields need to be.<br><br><br>I only recently learned the rules for NT bitfields.<br>First, aside, in C, bitfields can only be int or unsigned.<br>In Microsoft C however, they can be any integer type.<br>The layout rules are affected by the type.<br>I think the rules are that the type of the bitfield determines the alignment of the loads/stores to access it.<br><br>That is:<br>struct {<br> unsigned char a;<br> unsigned char b:1;<br>}<br><br>vs.<br>struct {<br> unsigned char a;<br> unsigned int b:1<br>}<br><br>In the first case, b is at byte offset 1.<br>In the second case, it is at byte offset 4.<br><br><br>I don't remember what order the bits are allocated within bytes.<br><br><br>Anyway, it isn't portable stuff.<br><br>I used to like bitfields for compactness.<br>Lately I disfavor them, because I like to be able to predict the layout of a struct.<br>Still, they can be useful:<br> 1) again, compactness<br> 2) lining up with some external definition, esp. hardware (e.g. page tables) <br> 3) ability to do stuff like:<br><br>union {<br> unsigned AsInt;<br> struct {<br> unsigned a : 1;<br> unsigned b : 1;<br>
unsigned c : 1;<br> } s;<br>
} u;<br><br>You can test AsInt for non-zeroness to see if any of a/b/c are set.<br>That can be useful.<br><br>Though, if layout-predictability is important, I'd just do one of:<br><br>struct<br>{<br> unsigned char a, b, c;<br> unsigned char any;<br>}<br><br>and require setters of a/b/c to set any,<br><br>or<br>struct<br>{<br> unsigned char a,b,c;<br>}<br><br>require checking a || b || c.<br>Problem is -- when d is added, have to update all the uses.<br><br>Then again..C++<br><br>struct<br>{<br> unsigned char a,b,c;<br> bool Any() { return a || b || c; }<br>}<br><br>only one place to update.<br><br><br>Anyway...<br> - Jay<br><br><br><div><div id="SkyDrivePlaceholder"></div><hr id="stopSpelling">From: dragisha@m3w.org<br>Date: Thu, 19 Jan 2012 23:51:34 +0100<br>To: jay.krell@cornell.edu<br>CC: m3devel@elegosoft.com<br>Subject: Re: [M3devel] packing problem… how exactly does modula-3 pack data into records??<br><br>
<meta http-equiv="Content-Type" content="text/html; charset=unicode">
<meta name="Generator" content="Microsoft SafeHTML">back in 1997-8 I did an LINUXALPHA port of pm3.<div><br></div><div>All portability problems I met were in C. And biggie was with gcc and its inability (at the moment) to cross compile on 32bit platform for 64bit RISC (lots and lots of registers on target machine).</div><div><br></div><div>So, speaking about C and portability... No such thing.</div><div><br></div><div>Your m3core.h work is great, by the way. I do a lot of low level stuff and it helps a lot. Thanks! :)</div><div><br></div><div><div><div>On Jan 19, 2012, at 11:42 PM, Jay K wrote:</div><br class="ecxApple-interchange-newline"><blockquote><span class="ecxApple-style-span" style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;orphans:2;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;widows:2;word-spacing:0px;font-size:medium"><span class="ecxApple-style-span" style="font-family:Tahoma;font-size:13px">(then again -- endian-knowledge can be used to make ntohl/htonl highly optimized.)<br><br><br>I know it's a little wierd what I say -- C is impelementation-dependent and we try<br>to be C compatible. And m3core/libm3 used to have some dependency<br>on this C compatibility, e.g. the waitpid stuff. But I believe I removed all<br>such dependency.<br></span></span></blockquote></div><br></div></div> </div></body>
</html>