<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'>
Let's say we have something defined by hardware, I'm making this up,<br>and we have a C header already for it:<br><br><br> typedef struct x86_pte /* fictional page table entry */ <br> { <br> unsigned valid : 1; <br> unsigned execute : 1; <br> unsigned writable : 1; <br> unsigned physical_page : 29; <br> } x86_pte; <br> <br> <br> and I want to interface with this hardware from Modula-3. <br><br> What do I do? <br><br> ?Find the documenation, let's say it goes like: <br> ?<br> x86_pte_valid 0x80000000 <br> x86_pte_executable 0x40000000 <br> x86_pte_writable 0x20000000 <br><br> ?Translate that into Modula-3. <br> Do I write: <br><br> x86_pte = BITS 32 FOR RECORD <br> valid: BITS 1 FOR BOOLEAN; <br> executable: BITS 1 FOR BOOLEAN; <br> writable: BITS 1 FOR BOOLEAN; <br> physical_page: BITS 29 FOR [0...16_1FFFFFFF]; <br> END;<br><br>or do I write:<br> x86_pte = BITS 32 FOR RECORD <br> physical_page: BITS 29 FOR [0...16_1FFFFFFF]; <br> writable: BITS 1 FOR BOOLEAN; <br> executable: BITS 1 FOR BOOLEAN; <br> valid: BITS 1 FOR BOOLEAN; <br> END; <br><br>?or do I write something else (maybe physical_page isn't unpacked properly) <br><br><br> ?or do I write something unambiguous but possibly slow: <br><br> x86_pte_opaque = RECORD: <br> opaque: BITS 32 FOR ARRAY OF BITS 8 FOR [0..255];<br> END;<br><br><br> PROCEDURE Valid(pte: x86_pte): BOOLEAN = <br> BEGIN <br> RETURN Word.And(pte.opaque[0], 16_80) # 0; <br> END Valid; <br><br> PROCEDURE Writable(pte: x86_pte): BOOLEAN = <br> BEGIN <br> RETURN Word.And(pte.opaque[0], 16_40) # 0; <br> END Writable; <br><br> PROCEDURE Executable(pte: x86_pte): BOOLEAN = <br> BEGIN <br> RETURN Word.And(pte.opaque[0], 16_20) # 0; <br> END Executable; <br><br> PROCEDURE PhysicalPage(pte: x86_pte): CARDINAL = <br> BEGIN <br> RETURN Word.Or(Word.Or(Word.Or(Word.LeftShift(Word.And(pte.opaque[0], 16_1F), 24), Word.LeftShift(pte.opaque[1], 16)), Word.LeftShift(pte.opaque[2], 8), pte.opaque[3]); (* approx *) <br> END PhysicalPage; <br><br>Or maybe:<br><br>RECORD UnpackedPTE = RECORD<br> Valid, Executable, Writable: BOOLEAN;<br> Page: CARDINAL;<br>END;<br><br>filled in by the above functions and then accessed directly?<br><br><br><br> But I also want to write some sort of simulator -- i.e. I'm not necessarily running on a little endian system. <br><br><br>I believe the original authors desired a "straight" translation from C headers -- the first Modula-3 version above.<br>This allows for easier transliteration of /usr/include into m3core/unix.<br><br><br> However it does not allow for the "simulator scenario" -- where the host's C compiler is<br> different than the one that interprets the C struct I showed. <br> Nor does it allow well for what you want to do -- portability across machines. <br><br><br>C programmers face the same dilemna.<br>Know that their compiler is somehow sane and predictable and use nice/convenient bitfields,<br>or take no dependency on the unspecified bitfield behavior and unpack bits/bytes manually.<br><br><br>Where C programmers depend on bitfields, and where Modula-3 transliterates C headers,<br>it is profitable for Modula-3 to try to emulate the platform's C compiler's behavior.<br>I have gone and removed m3core's dependency on this.<br><br><br>Again, I believe that was the original authors' intent.<br><br><br>Clearly there are pluses and minuses to the various approaches.<br><br><br>If you look at the GNU binutils, I think they do stuff like:<br><br>struct packed_foo<br>{<br> unsigned char foo[2];<br> unsigned char bar[4];<br> unsigned char abc[8];<br>|;<br><br>struct unpacked_foo<br>
{<br>
unsigned short foo;<br>
unsigned long bar;<br>
unsigned long long abc;<br>
};<br><br>void unpack_foo(packed_foo* packed, unpacked_foo* unpacked)<br>{<br> unpack_little_endian(packed->foo, sizeof(packed->foo), &unpacked->foo, sizeof(&unpacked->foo));<br>}<br><br>void unpack_little_endian(unsigned char* packed, size_t packed_size, void* unpacked, size_t unpacked_size)<br>{<br> unsigned long long value = { 0 }; <br> size_t i = { 0 }; <br> assert(unpacked_size >= packed_size); <br> for (i = 0; < packed_size) <br> value = (value << 8) | packed[i]; <br> if (unpacked_size == 1) <br> *(unsigned char*)unpacked = (unsigned char)value; <br> else if (unpacked_size == sizeof(unsigned short)) <br> *(unsigned short*)unpacked = (unsigned short)value; <br> else if (unpacked_size == sizeof(unsigned long)) <br> *(unsigned long*)unpacked = (unsigned long)value; <br> else if (unpacked_size == sizeof(unsigned long long)) <br> *(unsigned long long*)unpacked = (unsigned long long)value; <br> else<br> assert(false); <br>}<br><br><br>This has the cost/tedium of copying, but it is very portable, while still letting the<br>compiler do a little of the layout for you.<br><br>
<br>If you are defining your own protocol, I think the opaque/unpacking strategy is safest,<br>albeit slowest and most tedious.<br><br><br>You could also be wasteful and not use bitfields in your protocol.<br><br><br> - Jay<br><br><br><br><br><br><div><div id="SkyDrivePlaceholder"></div><hr id="stopSpelling">From: dragisha@m3w.org<br>Date: Fri, 20 Jan 2012 22:59: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?? … "solved"<br><br>
<meta http-equiv="Content-Type" content="text/html; charset=unicode">
<meta name="Generator" content="Microsoft SafeHTML">Ok, it is your standpoint. I don't share it. <div><br></div><div>Right now my problem is solved. If I encounter its variation again, I'l fix it for myself.</div><div><br></div><div>Excuse "C does it too" does not ring too Modulee for me :).</div><div><br></div><div>dd</div><div><br><div><div>On Jan 20, 2012, at 7:11 PM, Jay 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">As in C, if you need portability and predictability, just don't use bitfields. Use integer types of size 8, 16, 32, or possibly 64 bits, and do the appropriate shifting and masking, possibly endian-dependent.<br><br><br>Actually, to avoid endian and packing/alignment concerns, use only 8 bit integers and optionally pack/unpack into more convenient types.<br><br><br>- Jay (phone)</span></blockquote></div><br></div></div> </div></body>
</html>