[M3devel] naming conventions for split/composed interfaces?

[Olaf Wagner]

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