<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>kind of obnoxious of me here sorry:<BR>
<BR>
<BR>
I am not volunteering to do any work here. :)<BR>
<BR>
I propose that declaration that interface with C be declared PACKED (if that even exists) or BITS n FOR (I know that exists; it was pointed out to me and I have been using it).<BR>
I would like to be able to say BYTES n FOR, but ok, I say BITS n * 8 FOR.<BR>
<BR>
I propose there be a command line switch, or interface/module-level pragma that issues warnings or errors for any apparent need to insert any padding. <BR>
<BR>
I propose that any padding for alignment that is needed to interface with existing C code be explicitly inserted.<BR>
<BR>
I propose that when you say BITS n FOR, you be able to get a warning/error if the size isn't exactly right.<BR>
I know it is already an error today if the size is too small, but I assume the compiler will grow the type to fit if it is "too big" and I'd rather not have that.<BR>
On the other hand, while I have been using BITS n FOR, I make up an arbitrary type. That is, I say:<BR>
<BR>
Foo = BITS exact FOR RECORD<BR>
blah blah <BR>
pad : BITS exact FOR arbitrary small type such as [0..0]<BR>
END;<BR>
<BR>
While I don't want the compiler to expand Foo up to exact, I don't care about the [0..0] thing.<BR>
I guess in the interest of being less lazy and coming up with a simpler feature set, I am willing to be more precise in the padding. Or maybe a new type can be invented BITS exact for Padding. And maybe you can tack on ":= 0" to it, no matter the size. (Notice how in the socket code, the type of the padding can't be changed willy nilly because there is code to zero initialize it; seems a little bit lame to me.) <BR>
<BR>
I would probably volunteer to do some of the header repair here.<BR>
<BR>
Alignment issues bother me and I think we might be in a position to solve them once and for all for Modula-3, in a reasonable simple, clear, reliable, multi-target way. <BR>
<BR>
Part of this proposal would need to distinguish at least three scenarios:<BR>
exact layout for interfacing with existing C <BR>
stable layout for interface with self -- declare some new type in Modula-3 that I can pickle on multiple platforms but which Modula-3 can determine the layout of; padding can be inserted here but it must be the same across various time/space/configuration <BR>
don't care layout for data that will only ever be in memory and shared amongst code built by the same basic compiler with the same declarations; padding can be inserted here and vary from build to build or such <BR>
<BR>
another case: exact layout for interfacing with existing Modula-3/pickles. <BR>
<BR>
Or maybe simply pickles need persisted metadata about the various fields, offsets, sizes?<BR>
I have never used pickles or looked at the code...<BR>
<BR>
<BR>
- Jay<BR><BR><BR><BR>
<HR id=stopSpelling>
<BR>
> Date: Sat, 23 Feb 2008 11:31:36 -0600<BR>> From: rodney.bates@wichita.edu<BR>> To: darko@darko.org<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] <*LAZYALIGN*><BR>> <BR>> I guess I misunderstood. I had the idea from the quoted text below that MAC OS X needed a mixture<BR>> of lazy and strict alignment. If every platform uses the same alignment rules for all types of all<BR>> programs on the platform, then the alignment rule property can just be made an additional field of<BR>> the RTPacking.T.<BR>> <BR>> This is much easier to do without compatibility problems, because this value is encoded in bits<BR>> in a 32-bit word in pickle headers, with unused bits that are now ignored. The alignment strategy<BR>> could just be in another bit.<BR>> <BR>> <BR>> From a post on 2-11:<BR>> ---------------------------------------------------------------------------------------------------------<BR>> That's not quite right. Certain Mac API structures need to be aligned to Motorola 68K alignment for <BR>> historical reasons. All other structures should use normal alignment to be compatible with C and <BR>> Unix interfaces. The alignment change was implemented to be supported only in packed structures as <BR>> a natural and intuitive way to "force" alignment. You could view it as a bug fix to overly <BR>> restrictive alignment rules in packed structures.<BR>> <BR>> <BR>> On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote:<BR>> <BR>> > It sounds like all that Mac OS X needs is for _all_ types in an entire<BR>> > program to use the liberal packing rules. Have I understood correctly?<BR>> > I would have no grief over that.<BR>> ---------------------------------------------------------------------------------------------------------<BR>> <BR>> Darko wrote:<BR>> > The alignment rules are particular to a platform, not a type (at least <BR>> > after we get rid of the pragma), so is there no field where we can <BR>> > encode some information about the platform in the pickle header or <BR>> > something? Where is endian stored?<BR>> > <BR>> > <BR>> -- <BR>> -------------------------------------------------------------<BR>> Rodney M. Bates, retired assistant professor<BR>> Dept. of Computer Science, Wichita State University<BR>> Wichita, KS 67260-0083<BR>> 316-978-3922<BR>> rodney.bates@wichita.edu<BR><BR><br /><hr />Need to know the score, the latest news, or you need your HotmailŪ-get your "fix". <a href='http://www.msnmobilefix.com/Default.aspx' target='_new'>Check it out.</a></body>
</html>