[M3devel] naming conventions for split/composed interfaces?

[Tony Hosking]

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.

On Apr 25, 2008, at 2:37 AM, Jay wrote:

> 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 a
> kernel call. Data already has to be copied between
> kernel and user mode, and some i/o, possibly cached,
> has to occur.
> Maybe if someone stats a bunch of files, and then
> stats 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 some
> point you'll win by using something like opendir/readdir
> to just get all the data -- given some readdir that
> returns 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 lines
> that 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, optionally
> recompile/rerun the C and assert the output is unchanged.
>
> This is super easy for constants and chosing the right
> integer type for record fields.
> It is easy enough for getting the record fields in the right
> order, and asserting that you didn't miss any (no holes), though
> I didn't do that (yet).
>
> Perhaps I should try that?
> Come up with reasonably simple very very portable C (probably
> c++, 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 describe
> C 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 needed
> and no or very little more. The Cygwin stuff should be a good
> basis for determing this, except it doesn't use pthreads.
>
> Another problem here not yet addressed is picking out function
> signatures. I think some simple uses of C++ templates might
> work 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 than
> hand written once and then not checked through time.
> Granted, if you get Ustat.i3 wrong, you do tend to find and
> fix the bugs fairly fast, but I'd like "static" checking
> to 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/20e74bc5/attachment-0002.html>