[M3devel] Modula-3 bitfields

Dragiša Durić dragisha at m3w.org
Fri Aug 24 21:20:03 CEST 2012


As people in the world are divided in three groups, ones who can count and everybody else… So are we.

I am in this group with this fancy idea of Modula-3 being system programming language. You don't agree?

On Aug 24, 2012, at 8:10 PM, Mika Nystrom wrote:

> The Green Book doesn't actually define alignment rules does it?

  Most probably. That's why I mentioned prgma in the first place.

> 
> Your example as I recall also specified precisely 32 bits.
> 
> I can think of lots of ways things can go wrong.
> 
> Why would you want to tie the hands of the compiler writer to a particular
> layout?  Or clutter the interface with lots of pragmas…

  Pragma is good way to make things optional for some platforms, and to not change language definition. Platform specific, and working on AMD64 for example, is good enough.

> 
> Yeah OK there was a day when that was the way to do things.... I think
> that time is past.  The method I suggested could take advantage of
> situations where you know precisely how to construct the packed types.
> If you wanted.  But it would also be entirely portable and independent
> of compilers.  Heck you could generate C code at the same time and have
> free cross-language interoperability.  (Or any other sets of languages.)
> 
> You could also split bitfields in funny ways... 
> 
> Why would you do things any other way, really?  

  Being a Modula-2|3 programmer for 24 years obviously did funny things to me :). Like, I really started to like how high-level programs look like, esp ones doing various low-level stuff :). I like to think abstract, to write high-level, readable programs. Ones I don't have problems maintaining for prolonged time intervals.

  I don't need anything funny. I just need a way to represent, in a readable manner, standard communication data structures. So I can continue with my trade without C,

> 
> Here's an example.  A PCI Express DLLP is 32 bits of payload followed by
> a 16-bit CRC.  Should I be able to write this as follows:
> 
> DLLP = RECORD
>  payload : BITS 32 FOR [0..16_ffffffff];
>  crc     : BITS 16 FOR [0..16_ffff];
> END;
> 
> What then is the layout of 
> 
> ARRAY [0..1] OF DLLP;
> 

Maybe you meant to write: ARRAY [0..1] OF BITS 48 FOR DLLP; ?

> ?
> 
>    Mika

dd

> 
> =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:
>> 
>> --Apple-Mail=_91577572-D1CD-4E97-A777-A61FB5FE2B5A
>> Content-Type: multipart/alternative;
>> 	boundary="Apple-Mail=_01BB8F3E-2A9D-4270-9D92-38991735317E"
>> 
>> 
>> --Apple-Mail=_01BB8F3E-2A9D-4270-9D92-38991735317E
>> Content-Transfer-Encoding: quoted-printable
>> Content-Type: text/plain;
>> 	charset=utf-8
>> 
>> What mental model?
>> 
>> We have network order. Everything network is bit streams, from left to =
>> right, most significant bits/bytes. No need for mental model here, any =
>> communication oriented ISO, ETSI, ITU standard=E2=80=A6=20
>> 
>> I don't understand why you insist on C syntax here. C has its own =
>> problems and reasons why it's at war with most things mental. Please =
>> refer to my initial example instead.
>> 
>> --
>> Divided by a common language
>> 
>> Dragi=C5=A1a Duri=C4=87
>> dragisha at m3w.org
>> 
>> 
>> 
>> 
>> On Aug 24, 2012, at 7:48 PM, Jay K wrote:
>> 
>>> printf("%X %X\n", c.u.s.a, c.u.s.b);
>>> What do people expect?
>>> Do people really have a mental model as to what the layout rules are =
>> for bitfields?
>>> Are they obvious enough that every C compiler writer has actually =
>> implemented them the same and they become in a sense portable?=20
>> 
>> 
>> --Apple-Mail=_01BB8F3E-2A9D-4270-9D92-38991735317E
>> Content-Transfer-Encoding: quoted-printable
>> Content-Type: text/html;
>> 	charset=utf-8
>> 
>> <html><head></head><body style=3D"word-wrap: break-word; =
>> -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">What =
>> mental model?<div><br></div><div>We have network order. Everything =
>> network is bit streams, from left to right, most significant bits/bytes. =
>> No need for mental model here, any communication oriented ISO, ETSI, ITU =
>> standard=E2=80=A6 </div><div><br></div><div>I don't understand why =
>> you insist on C syntax here. C has its own problems and reasons why it's =
>> at war with most things mental. Please refer to my initial example =
>> instead.</div><div><br><div apple-content-edited=3D"true">
>> <span class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>> color: rgb(0, 0, 0); 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; -webkit-border-horizontal-spacing: 0px; =
>> -webkit-border-vertical-spacing: 0px; =
>> -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
>> auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span =
>> class=3D"Apple-style-span" style=3D"border-collapse: separate; color: =
>> rgb(0, 0, 0); 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; =
>> -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>> 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
>> auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div =
>> style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
>> -webkit-line-break: after-white-space; "><div>--</div><div>Divided by a =
>> common language</div><div><br></div><div>Dragi=C5=A1a =
>> Duri=C4=87</div><div><a =
>> href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org</a></div><div><br></div>=
>> </div></span><br class=3D"Apple-interchange-newline"></span><br =
>> class=3D"Apple-interchange-newline">
>> </div>
>> <br><div><div>On Aug 24, 2012, at 7:48 PM, Jay K wrote:</div><br =
>> class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span =
>> class=3D"Apple-style-span" style=3D"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; =
>> -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>> 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
>> auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span =
>> class=3D"Apple-style-span" style=3D"font-family: Calibri; font-size: =
>> 16px; ">printf("%X %X\n", c.u.s.a, c.u.s.b);<br>What do people =
>> expect?<br>Do people really have a mental model as to what the layout =
>> rules are for bitfields?<br>Are they obvious enough that every C =
>> compiler writer has actually implemented them the same and they become =
>> in a sense portable?<span =
>> class=3D"Apple-converted-space"> </span></span></span></blockquote></=
>> div><br></div></body></html>=
>> 
>> --Apple-Mail=_01BB8F3E-2A9D-4270-9D92-38991735317E--
>> 
>> --Apple-Mail=_91577572-D1CD-4E97-A777-A61FB5FE2B5A
>> Content-Transfer-Encoding: 7bit
>> Content-Disposition: attachment;
>> 	filename=signature.asc
>> Content-Type: application/pgp-signature;
>> 	name=signature.asc
>> Content-Description: Message signed with OpenPGP using GPGMail
>> 
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
>> 
>> iQEcBAEBAgAGBQJQN8DnAAoJEJtljYXUJo8xZsIH/3eJ6oSYCbMxR0osICTBayug
>> fWeDasX0FPM1/BglqM5pS5DzITUrVvSp1ldXUr6Na1RaPKc9kUvs521YNHG6yajs
>> tRO0A6T1subyKNjscPrYYUueT2EHABrg0qfVD6NeUHxeE35304CztXoNx0HMhKtx
>> 5CfNORPHoGl1utyKxj0OabDXnHDb3b34sgmHWBSBlNc2Mk1lBBcss3UJT5p2o8yq
>> M3p19YhPst/YQove/21UYEuDDJB4TiLl2rQaV4h5gPPTQLXGzF35VWRNeKsrWf8f
>> VhhwckLhgU6cvmLUaXacIulVdpdOfaavG2cg+62ptWNtIHv7frlSHsDxTjHYavk=
>> =1GwZ
>> -----END PGP SIGNATURE-----
>> 
>> --Apple-Mail=_91577572-D1CD-4E97-A777-A61FB5FE2B5A--

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120824/f34884a3/attachment-0002.sig>


More information about the M3devel mailing list