[M3devel] Modula-3 bitfields
Mika Nystrom
mika at async.caltech.edu
Sat Aug 25 07:35:51 CEST 2012
Yeah I think Modula-3 historically tries to stay as close as possible to
an implied mapping to C. It's definitely *not* big-endian on a little-endian
machine.
Mika
Jay K writes:
>--_bf70e44f-528a-4dc1-b84a-af7891d54830_
>Content-Type: text/plain; charset="iso-8859-2"
>Content-Transfer-Encoding: quoted-printable
>
> > What mental model? > We have network order. Everything network is bit st=
>reams=2C from left to right=2C most > significant bits/bytes. Does any Mod=
>ula-2 or Modula-3 or C compiler follow this model?For a little endian targe=
>t? I'm skeptical.If it really is obvious=2C maybe we can make cm3 follow it=
>?Even if it breaks bitfield interop with C?I would like to have m3front and=
> M3C.m3 not have any target-endian dependentness.I do believe it would brea=
>k pickles=2C and some floating point code in m3core/libm3. ..because..you =
>see.. I think there some mental model in C compiler writer's heads...that c=
>m3 tries to adhere to=2C but which I might have diverged a bit from (look a=
>t the history of Target.m3). In particular=2C standard C only allows bit f=
>ields to be of type "int" or "unsigned".However it is a common extension to=
> allow the type of a bitfield to also unsigned/signed char=2C short=2C long=
>=2C and long long=2C and this does I believe affect the layout. Does that f=
>it your mental model? In your model=2C must a 32bit bit field be aligned on=
> a 32bit boundary? What does this look like: struct { unsigned a : 1=3B u=
>nsigned b : 32=3B}=3B? - Jay
> From: dragisha at m3w.org
>Date: Fri=2C 24 Aug 2012 21:53:44 +0200
>To: mika at async.caltech.edu
>CC: m3devel at elegosoft.com
>Subject: Re: [M3devel] Modula-3 bitfields
>
>What you are proposing is to do a compiler-level job with a library. Just b=
>ecause such a library exists does not mean it invalidates every other appro=
>ach. And we are talking about one of most complicated pieces of Modula-3 sy=
>stem=2C comparable in complexity with compiler. Of course=2C there are othe=
>r approaches too=2C like some kind of interface language=2C to be processed=
> into Modula-3 source code by cm3 build system.
>Your latest example is good illustration for my proposal too. Another simpl=
>e example to show a need for exact bit packing layout method. Thank you!
>=0A=
>--Divided by a common language
>Dragi=B9a Duri=E6dragisha at m3w.org
>=0A=
>=0A=
>
>On Aug 24=2C 2012=2C at 9:28 PM=2C Mika Nystrom wrote:
>And what does that mean=2C exactly? No gaps allowed? What does it
>mean=2C in particular=2C on a little-endian machine?
>
>What about ARRAY [0..1] OF BITS 31 FOR [0..16_8fffffff] ?
>
>What I am proposing isn't particularly difficult=2C it's not unportable=2C
>either. And much more powerful than any sets of pragmas. Not tied to
>your one architecture.
>
> Mika
> =
>
>--_bf70e44f-528a-4dc1-b84a-af7891d54830_
>Content-Type: text/html; charset="iso-8859-2"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style><!--
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 12pt=3B
>font-family:Calibri
>}
>--></style></head>
><body class=3D'hmmessage'><div dir=3D'ltr'> =3B>=3B What mental model=
>?<BR><div> =3B>=3B We have network order. Everything network is bit s=
>treams=2C from left to right=2C most</div><div> =3B>=3B significant b=
>its/bytes.</div><div> =3B</div><div> =3B</div><div>Does any Modula-=
>2 or Modula-3 or C compiler follow this model?</div><div>For a little endia=
>n target? I'm skeptical.</div><div>If it really is obvious=2C maybe we can =
>make cm3 follow it?</div><div>Even if it breaks bitfield interop with C?</d=
>iv><div>I would like to have m3front and M3C.m3 not have any target-endian =
>dependentness.</div><div>I do believe it would break pickles=2C and some fl=
>oating point code in m3core/libm3.</div><div> =3B ..because..you see.. =
>I think there some mental model in C compiler writer's heads...that cm3 tri=
>es to adhere to=2C but which I might have diverged a bit from (look at the =
>history of Target.m3).</div><div> =3B</div><div> =3B</div><div>In p=
>articular=2C standard C only allows bit fields to be of type "int" or "unsi=
>gned".</div><div>However it is a common extension to allow the type of a bi=
>tfield to also unsigned/signed char=2C short=2C long=2C and long long=2C an=
>d this does I believe affect the layout. Does that fit your mental model? I=
>n your model=2C must a 32bit bit field be aligned on a 32bit boundary?</div=
>><div> =3B</div><div>What does this look like:</div><div> =3B</div>=
><div>struct {</div><div> =3B unsigned a : 1=3B</div><div> =3B unsig=
>ned b : 32=3B</div><div>}=3B</div><div>?</div><div> =3B</div><div> =
>=3B</div><div> =3B- Jay<br> =3B</div><div><div id=3D"SkyDrivePlaceh=
>older"></div><hr id=3D"stopSpelling">From: dragisha at m3w.org<br>Date: Fri=2C=
> 24 Aug 2012 21:53:44 +0200<br>To: mika at async.caltech.edu<br>CC: m3devel at el=
>egosoft.com<br>Subject: Re: [M3devel] Modula-3 bitfields<br><br>What you ar=
>e proposing is to do a compiler-level job with a library. Just because such=
> a library exists does not mean it invalidates every other approach. And we=
> are talking about one of most complicated pieces of Modula-3 system=2C com=
>parable in complexity with compiler. Of course=2C there are other approache=
>s too=2C like some kind of interface language=2C to be processed into Modul=
>a-3 source code by cm3 build system.<div><div><br></div><div>Your latest ex=
>ample is good illustration for my proposal too. Another simple example to s=
>how a need for exact bit packing layout method. Thank you!</div><div><br></=
>div><div><div>=0A=
><span style=3D"color: rgb(0=2C 0=2C 0)=3B text-transform: none=3B text-inde=
>nt: 0px=3B letter-spacing: normal=3B word-spacing: 0px=3B white-space: norm=
>al=3B border-collapse: separate=3B orphans: 2=3B widows: 2=3B" class=3D"ecx=
>Apple-style-span"><span style=3D"color: rgb(0=2C 0=2C 0)=3B text-transform:=
> none=3B text-indent: 0px=3B letter-spacing: normal=3B word-spacing: 0px=3B=
> white-space: normal=3B border-collapse: separate=3B orphans: 2=3B widows: =
>2=3B" class=3D"ecxApple-style-span"><div style=3D"word-wrap: break-word=3B"=
>><div>--</div><div>Divided by a common language</div><div><br></div><div>Dr=
>agi=B9a Duri=E6</div><div><a href=3D"mailto:dragisha at m3w.org">dragisha at m3w.=
>org</a></div><div><br></div></div></span><br class=3D"ecxApple-interchange-=
>newline"></span><br class=3D"ecxApple-interchange-newline">=0A=
></div>=0A=
><br><div><div>On Aug 24=2C 2012=2C at 9:28 PM=2C Mika Nystrom wrote:</div><=
>br class=3D"ecxApple-interchange-newline"><blockquote><span style=3D"text-t=
>ransform: none=3B text-indent: 0px=3B letter-spacing: normal=3B word-spacin=
>g: 0px=3B white-space: normal=3B border-collapse: separate=3B orphans: 2=3B=
> widows: 2=3B" class=3D"ecxApple-style-span"><br>And what does that mean=2C=
> exactly?  =3BNo gaps allowed?  =3BWhat does it<br>mean=2C in parti=
>cular=2C on a little-endian machine?<br><br>What about ARRAY [0..1] OF BITS=
> 31 FOR [0..16_8fffffff] ?<br><br>What I am proposing isn't particularly di=
>fficult=2C it's not unportable=2C<br>either.  =3BAnd much more powerful=
> than any sets of pragmas.  =3BNot tied to<br>your one architecture.<br=
>><br> =3B =3B =3B =3BMika</span></blockquote></div><br></di=
>v></div></div> </div></body>
></html>=
>
>--_bf70e44f-528a-4dc1-b84a-af7891d54830_--
More information about the M3devel
mailing list