
<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div apple-content-edited="true"><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div>Header cloning is the price we pay for straightforward, uncomplicated, untangled, porting.  Yes, there is a small amount of effort (usually an hour or so in my experience) putting together the *very few* interfaces to match C headers in order to bring up a new target.  The resulting code is easily maintained as a faithful mirror of the original C headers.  I really think you are overstating the difficulty here, and as others have observed, this approach has not impeded the development and portability of the system.</div></span></span></span></span></span></span></span></span></div></span> </div><br><div><div>On Apr 25, 2008, at 2:37 AM, Jay wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: 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: 0; "><div class="hmmessage" style="font-size: 10pt; font-family: Tahoma; ">Copying around 64 bytes per stat call is never going to be the bottleneck.<br>I am not 100% sure, but I believe every stat call is a<br>kernel call. Data already has to be copied between<br>kernel and user mode, and some i/o, possibly cached,<br>has to occur.<br>Maybe if someone stats a bunch of files, and then<br>stats them many times afterward.<br><br>I'm all for thin (zero thickness) wrappers, keeping things fast, but header cloning really bugs me.<br><br>If you really want to stat a lot of files, at some<br>point you'll win by using something like opendir/readdir<br>to just get all the data -- given some readdir that<br>returns the needed stat information.<br>On Windows this is simply FindFirstFile/FindNextFile.<br>(and yes I realize I'm partly rearranging deck chairs -- the readdir has to return<br>some struct with the same issues as stat, however maybe there'd be knowledge<br>of it operating on larger data and less tendency to slow it down)<br><br>> generic posix directory to speed ports<br><br>Sounds like a good compromise.<br>And existing ports could even try it and measure the difference maybe.<br><br>> swig vs. my compiler-based idea vs. generating some other<br>> way only what is needed<br><br>Good point. I did some stuff for Cygwin along these lines<br>that may be close to just right.<br><br>Fairly simple C code that prints out the Modula-3.<br>Again, what you could do, is in the build, optionally<br>recompile/rerun the C and assert the output is unchanged.<br><br>This is super easy for constants and chosing the right<br>integer type for record fields.<br>It is easy enough for getting the record fields in the right<br>order, and asserting that you didn't miss any (no holes), though<br>I didn't do that (yet).<br><br>Perhaps I should try that?<br>Come up with reasonably simple very very portable C (probably<br>c++, with specific reasons) code that prints out..well..<br>some set of .i3 files that bother me.<br>I guess it is fairly scientific, which .i3 files describe<br>C and which Modula-3.<br>It is presence of <* external *>, the types they take and return.<br>Constants, harder to identify mechanically.<br><br>I also made a large stab to determine exactly what is needed<br>and no or very little more. The Cygwin stuff should be a good<br>basis for determing this, except it doesn't use pthreads.<br> <br>Another problem here not yet addressed is picking out function<br>signatures. I think some simple uses of C++ templates might<br>work here, but I have to experiment.<br> <br>There would still be much duplicity, but I guess generated<br>(and still checked in, and often regenerated), is better than<br>hand written once and then not checked through time.<br>Granted, if you get Ustat.i3 wrong, you do tend to find and<br>fix the bugs fairly fast, but I'd like "static" checking<br>to get this stuff right.<br><br>I'm not going to do much of anything here for now,<br>but maybe I'll get around to it. It depends what bugs me most. :)<br><br> - Jay<br><br><br><br><br><br><hr id="stopSpelling"><br>> Date: Fri, 25 Apr 2008 08:19:05 +0200<br>> From:<span class="Apple-converted-space"> </span><a href="mailto:wagner@elegosoft.com">wagner@elegosoft.com</a><br>> To:<span class="Apple-converted-space"> </span><a href="mailto:jayk123@hotmail.com">jayk123@hotmail.com</a><br>> CC:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a>;<span class="Apple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>> Subject: RE: [M3devel] naming conventions for split/composed interfaces?<br>><span class="Apple-converted-space"> </span><br>> Quoting Jay <<a href="mailto:jayk123@hotmail.com">jayk123@hotmail.com</a>>:<br>><span class="Apple-converted-space"> </span><br>> > What cost are you willing to pay?<br>> > It is EASY to write one simple Ustat.i3 and UstatC.c that is correct<span class="Apple-converted-space"> </span><br>> > for all platforms, totally portable, simple, efficient enough etc.<span class="Apple-converted-space"> </span><br>> > The cost of avoiding the wrapper is pain, uncertainty, much higher<span class="Apple-converted-space"> </span><br>> > risk of the implementation being wrong or becoming silently wrong,<span class="Apple-converted-space"> </span><br>> > though...<br>><span class="Apple-converted-space"> </span><br>> In case of stat, copying the structure may lead to performance bottle-<br>> necks in I/O intensive programs (like build systmes etc.). Build<br>> systems for example may start by stat-ing ten thousands of files in<br>> their first phase.<br>><span class="Apple-converted-space"> </span><br>> I'd not object to adding something like a generic posix subdir,<br>> which could be used for fast porting, but I wouldn't want this<br>> to be used for current plaforms if it has performance impacts.<br>><span class="Apple-converted-space"> </span><br>> > Well, how about this suggestion?<br>> > How about we start writing some C code that asserts the correctness<span class="Apple-converted-space"> </span><br>> > of the .i3 files?Or even having the compiler output such C code?<span class="Apple-converted-space"> </span><br>> > Just make sure it compiles?<br>><span class="Apple-converted-space"> </span><br>> This sounds more than what I'd like to do. I think we need to<br>> analyze what exactly M3 really needs from the underlying target<br>> platform, and automate a way of generating the correct interfaces for<br>> that. Something configure-like that will only be used for porting<br>> (or checking the correctness of existing interfaces).<br>><span class="Apple-converted-space"> </span><br>> > Ustat.i3 would get some directive LIKE:<br>> ><br>> > <* PRAGMA C-derived "#include sys/stat.h", "struct stat" *><br>> > struct_stat = RECORD ... END<br>> ><br>> > The second parameter is the type that the record should "match".<br>> ><br>> > This would generate and a compile a file something like:<br>> > #include <sys/stat.h><br>> > #define size(a,b,c) (sizeof((a)(a*)0)->b == c)<br>> > #define field(a,b) ((a*)0)->b)<br>> > #define offset(a,b) ((size_t)a)<br>> ><br>> > type_size_size(struct stat, 0x123)<br>> > size(struct stat, st_dev, 8)<br>> > size(field(struct stat, st_dev), 8)<br>> > size(field(struct stat, st_ino), 8)<br>> > offset(field(struct stat, st_dev), 0)<br>> > offset(field(struct stat, st_ino), 8)<br>> > etc.<br>> ><br>> > where all the numbers on the right are what the compiler computes.<br>> ><br>> > This way, the transcription of C into Modula-3 is checked for correctness.<br>> ><br>> > It can be optional -- like for cross builds that might have a C<span class="Apple-converted-space"> </span><br>> > compiler or headers/libs.<br>> > I have to admit, there is an aspect of avoiding C that I really like<span class="Apple-converted-space"> </span><br>> > -- the idea of building one tool for all targets, all in one, no<span class="Apple-converted-space"> </span><br>> > need to get a cross compiler or headers/libs. To me that is a<span class="Apple-converted-space"> </span><br>> > potential big upside to avoiding wrappers.<br>> > I would even suggest -- can the dtoa.c and hand.c be rewritten in Modula-3.<br>> > dtoa.c was very very gnarly last I looked. Could be they dropped<span class="Apple-converted-space"> </span><br>> > support for IBM/Cray/VAX and it's simpler now, I don't know. While I<span class="Apple-converted-space"> </span><br>> > like the idea, I would be reluctant because I don't understand the<span class="Apple-converted-space"> </span><br>> > code much.<br>> > hand.c though, I strongly suspect can be written in perfectly<span class="Apple-converted-space"> </span><br>> > portable efficient Modula-3.<br>><span class="Apple-converted-space"> </span><br>> There have been some discussions in the past about updating or<br>> replacing dtoa.h in M3. Have a look at the mailing list archives<br>> before spending too much time on it.<br>><span class="Apple-converted-space"> </span><br>> > It may or MIGHT not compiler down as efficiently, just if the<span class="Apple-converted-space"> </span><br>> > compiler doesn't do a good job, but I don't think, like, "there any<span class="Apple-converted-space"> </span><br>> > layers in the model" that prevent it, like you wouldn't have to do<span class="Apple-converted-space"> </span><br>> > extra heap allocs or copies. You might get some extra array bounds<span class="Apple-converted-space"> </span><br>> > checks, that would be good to avoid introducing.<br>> ><br>> > Well, I'm too busy right now, but:<br>> ><br>> > 1) I'll maybe the errno wrapper in NT386. As long as you avoid the<span class="Apple-converted-space"> </span><br>> > thread-unsafe library, this area has been stable forever.<br>> > And building in a dependency on thread safety is a good thing.<br>> ><br>> > 2) I'll see about rewriting hand.c in Modula-3 and see if I can<span class="Apple-converted-space"> </span><br>> > convince myself there's no perf loss.<br>> ><br>> > 3) I look at gtoa.c to confirm it is still way to gnarly to consider<span class="Apple-converted-space"> </span><br>> > changing.<br>> ><br>> > 4) Eventually see about building in this checking. It removes the<span class="Apple-converted-space"> </span><br>> > upside of not having a compiler/headers, that's why optional.<br>> ><br>> > 5) Wonder about automating generation of the Modula-3 in the first<span class="Apple-converted-space"> </span><br>> > place? Something like SWIG? I don't know.<br>> > Problem with #4 and #5 is special cases. Coming up with some<span class="Apple-converted-space"> </span><br>> > mechanized translation that actually exists and works.<br>><span class="Apple-converted-space"> </span><br>> SWIG has already been tried at least twice for M3, and found to be<br>> somewhat unhandy and insufficient. It does not really speed up the<br>> process of getting correct M3 interfaces for C headers IIRC.<br>><span class="Apple-converted-space"> </span><br>> Olaf<br>> --<span class="Apple-converted-space"> </span><br>> Olaf Wagner -- elego Software Solutions GmbH<br>> Gustav-Meyer-Allee 25 / Geb�ude 12, 13355 Berlin, Germany<br>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<br>><span class="Apple-converted-space"> </span><a href="http://www.elegosoft.com">http://www.elegosoft.com</a><span class="Apple-converted-space"> </span>| Gesch�ftsf�hrer: Olaf Wagner | Sitz: Berlin<br>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<br>><span class="Apple-converted-space"> </span><br><br></div></span></blockquote></div><br></body></html>