[M3devel] naming conventions for split/composed interfaces?

Fri Apr 25 08:37:13 CEST 2008

Copying around 64 bytes per stat call is never going to be the bottleneck.I am not 100% sure, but I believe every stat call is akernel call. Data already has to be copied betweenkernel and user mode, and some i/o, possibly cached,has to occur.Maybe if someone stats a bunch of files, and thenstats them many times afterward.
I'm all for thin (zero thickness) wrappers, keeping things fast, but header cloning really bugs me.
If you really want to stat a lot of files, at somepoint you'll win by using something like opendir/readdirto just get all the data -- given some readdir thatreturns the needed stat information.On Windows this is simply FindFirstFile/FindNextFile.
(and yes I realize I'm partly rearranging deck chairs -- the readdir has to return
some struct with the same issues as stat, however maybe there'd be knowledge
of it operating on larger data and less tendency to slow it down)
> generic posix directory to speed ports
Sounds like a good compromise.And existing ports could even try it and measure the difference maybe.
> swig vs. my compiler-based idea vs. generating some other> way only what is needed
Good point. I did some stuff for Cygwin along these linesthat may be close to just right.
Fairly simple C code that prints out the Modula-3.Again, what you could do, is in the build, optionallyrecompile/rerun the C and assert the output is unchanged.
This is super easy for constants and chosing the rightinteger type for record fields.It is easy enough for getting the record fields in the rightorder, and asserting that you didn't miss any (no holes), thoughI didn't do that (yet).
Perhaps I should try that?Come up with reasonably simple very very portable C (probablyc++, with specific reasons) code that prints out..well..some set of .i3 files that bother me.I guess it is fairly scientific, which .i3 files describeC and which Modula-3.It is presence of <* external *>, the types they take and return.Constants, harder to identify mechanically.
I also made a large stab to determine exactly what is neededand no or very little more. The Cygwin stuff should be a goodbasis for determing this, except it doesn't use pthreads.

Another problem here not yet addressed is picking out functionsignatures. I think some simple uses of C++ templates mightwork here, but I have to experiment.

There would still be much duplicity, but I guess generated(and still checked in, and often regenerated), is better thanhand written once and then not checked through time.Granted, if you get Ustat.i3 wrong, you do tend to find andfix the bugs fairly fast, but I'd like "static" checkingto get this stuff right.
I'm not going to do much of anything here for now,but maybe I'll get around to it. It depends what bugs me most. :)
 - Jay

> Date: Fri, 25 Apr 2008 08:19:05 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com> Subject: RE: [M3devel] naming conventions for split/composed interfaces?> > Quoting Jay <jayk123 at hotmail.com>:> > > What cost are you willing to pay?> > It is EASY to write one simple Ustat.i3 and UstatC.c that is correct > > for all platforms, totally portable, simple, efficient enough etc. > > The cost of avoiding the wrapper is pain, uncertainty, much higher > > risk of the implementation being wrong or becoming silently wrong, > > though...> > In case of stat, copying the structure may lead to performance bottle-> necks in I/O intensive programs (like build systmes etc.). Build> systems for example may start by stat-ing ten thousands of files in> their first phase.> > I'd not object to adding something like a generic posix subdir,> which could be used for fast porting, but I wouldn't want this> to be used for current plaforms if it has performance impacts.> > > Well, how about this suggestion?> > How about we start writing some C code that asserts the correctness > > of the .i3 files?Or even having the compiler output such C code? > > Just make sure it compiles?> > This sounds more than what I'd like to do. I think we need to> analyze what exactly M3 really needs from the underlying target> platform, and automate a way of generating the correct interfaces for> that. Something configure-like that will only be used for porting> (or checking the correctness of existing interfaces).> > > Ustat.i3 would get some directive LIKE:> >> > <* PRAGMA C-derived "#include sys/stat.h", "struct stat" *>> > struct_stat = RECORD ... END> >> > The second parameter is the type that the record should "match".> >> > This would generate and a compile a file something like:> > #include <sys/stat.h>> > #define size(a,b,c) (sizeof((a)(a*)0)->b == c)> > #define field(a,b) ((a*)0)->b)> > #define offset(a,b) ((size_t)a)> >> > type_size_size(struct stat, 0x123)> > size(struct stat, st_dev, 8)> > size(field(struct stat, st_dev), 8)> > size(field(struct stat, st_ino), 8)> > offset(field(struct stat, st_dev), 0)> > offset(field(struct stat, st_ino), 8)> > etc.> >> > where all the numbers on the right are what the compiler computes.> >> > This way, the transcription of C into Modula-3 is checked for correctness.> >> > It can be optional -- like for cross builds that might have a C > > compiler or headers/libs.> > I have to admit, there is an aspect of avoiding C that I really like > > -- the idea of building one tool for all targets, all in one, no > > need to get a cross compiler or headers/libs. To me that is a > > potential big upside to avoiding wrappers.> > I would even suggest -- can the dtoa.c and hand.c be rewritten in Modula-3.> > dtoa.c was very very gnarly last I looked. Could be they dropped > > support for IBM/Cray/VAX and it's simpler now, I don't know. While I > > like the idea, I would be reluctant because I don't understand the > > code much.> > hand.c though, I strongly suspect can be written in perfectly > > portable efficient Modula-3.> > There have been some discussions in the past about updating or> replacing dtoa.h in M3. Have a look at the mailing list archives> before spending too much time on it.> > > It may or MIGHT not compiler down as efficiently, just if the > > compiler doesn't do a good job, but I don't think, like, "there any > > layers in the model" that prevent it, like you wouldn't have to do > > extra heap allocs or copies. You might get some extra array bounds > > checks, that would be good to avoid introducing.> >> > Well, I'm too busy right now, but:> >> > 1) I'll maybe the errno wrapper in NT386. As long as you avoid the > > thread-unsafe library, this area has been stable forever.> > And building in a dependency on thread safety is a good thing.> >> > 2) I'll see about rewriting hand.c in Modula-3 and see if I can > > convince myself there's no perf loss.> >> > 3) I look at gtoa.c to confirm it is still way to gnarly to consider > > changing.> >> > 4) Eventually see about building in this checking. It removes the > > upside of not having a compiler/headers, that's why optional.> >> > 5) Wonder about automating generation of the Modula-3 in the first > > place? Something like SWIG? I don't know.> > Problem with #4 and #5 is special cases. Coming up with some > > mechanized translation that actually exists and works.> > SWIG has already been tried at least twice for M3, and found to be> somewhat unhandy and insufficient. It does not really speed up the> process of getting correct M3 interfaces for C headers IIRC.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080425/ed0bc6a2/attachment-0002.html>