Re: [Tack-devel] Update on porting effort

[Carl E. C. <cec...@ya...>]

 Greetings,               Ok, I do understand your point of view and I have no issue with it, but I have several questions related to it once again.. sorry for the bother.
Do we agree that we should avoid POSIX calls in the C layer, and stick with ANSI C if possible (might not be possible in certain cases), right? 
Now a real use case:* I have replaced in LLgen mkstemp() by tmpnam() it is now fully ANSI, even though it has known race conditions, something acceptable for this project, right?* But you might already know tmpnam() is completely broken in Visual C++ and simply cannot be used.
In that case, for Visual C++ how do you solve it, or other ANSI C libraries which has such issues... how you fix it? The solution i made is to add TMPNAM wrapper as a function in machdep.c and then if necessary in the future, add platform specific parts for those broken libc API's there directly... Not sure if this is the correct approach though.
On the other hand, if POSIX calls are required, then we need to implement them on the platforms that are missing them, this is what you are saying? Using the semantics of the real POSIX API instead of a wrapper, so the "system" library would actually emulate the POSIX calls?
And for low-end platforms, we simply have libc simply call as directly as possible the kernel, by doing typedef's, etc, right, making it minimal, right?
Just trying to understand... Carl




    On Saturday, February 16, 2019, 10:32:08 PM GMT+8, David Given <dg...@co...> wrote:  
 
 Yup, that's exactly what I mean. Lose the library completely and use Posix interfaces throughout. On systems which need it, we can just typedef FILE to an int and then implement fread() as a tiny wrapper around read().
(We should probably have this anyway as a libc option. It looks like the ACK is mostly used for real for very small systems; I'm currently doing a tonne of work on the 8080 backend for Fuzix, and I get persistent bug reports from some working with CP/M that the stdio is just too big.)
This is equivalent to what the system library currently does --- except without the conceptual overhead of having to deal with an extra API with its own semantic quirks. Carl's reaction above on seeing File* is exactly what I'm trying to avoid here. Provided we make a reasonable effort to use a minimal subset of the APIs available, there's little work here and a lot of win.
Code is cheap; understanding is expensive. Making the code easier to understand makes it easier to work with, and therefore there's more likelihood that people will understand what's going on (which we desperately need; a lot of the code is very opaque).
Plus, on systems which don't need the small library, we get stdio file buffering for free and faster compiles.

On Sat, 16 Feb 2019 at 14:14 <u-...@ae...> wrote:

On Sat, Feb 16, 2019 at 11:54:31AM +0100, David Given wrote:
> Being able to build the ACK on small systems is definitely valuable, and we
> should keep it.

Appreciated.

> That said, I'm not sure that using a custom system library's the right way
> to do this. These days C is much more standard than it was back then and
> the need for custom wrappers to make sure that, e.g., realloc with NULL
> works properly isn't necessary. A lot of the stuff in system is equivalent
> to the standard Posix calls, or is unused completely (sys_lock --- in fact,
> I see that function's not even built!).
> 
> What I'd propose as a compromise is:
> 
> - if a system function is a trivial reimplementation of Posix, replace it
> with the Posix version.
> - *do* replace File* with FILE*. If it turns out to be too expensive later,
> we can replace the buffered stdio with an unbuffered implementation
> equivalent to the one in system, but using the standard interfaces.

I am not sure I am fully following you (any code accidentally
dereferencing *File would break with *FILE because FILE is opaque,
but this might be a non-issue here), assume that you intend to replace
references to the "system" library entries everywhere with corresponding
Posix and stdio equivalents, dropping the library out of existence,
or possibly keeping some entry points not falling under the cases above (?)

If this is a correct interpretation, I do not like to sound negative,
but unfortunately I anticipate some drawbacks.

One is to have to make changes in many files, this implies some
additional work and a risk for subtle breakage.

The other is a loss of the presently sufficient constrained interface.

When someone would have to adapt Ack to a new constrained environment,
one would have a challenge to find out which Posix/libc subset needs
to be ported there.

At that time the necessary set of operation will probably become larger
that today, if more Posix/libc calls will be introduced in different
parts of the code.

It is hard to expect that an Ack developer would always have in mind to
double check whether a certain Posix / C library call is already being
used or not.

> This way we should end up with standard interfaces, which makes things
> easier to work on and maintain, but still allow the small systems.

This particular interface is small (17 entry points?) and the implementation
takes 449 lines in *.[hc] and 324 lines of nroff in the man page.
An implementation of a minimal standard-compatible unbuffered
stdio would probably take at least about the same amount of LOC even if
the man page would become redundant (?).

To get some idea, I checked with avr-libc:
(buffered stdio, so take it with a large grain of salt, but anyway)
The docs say: "only a limited subset of standard IO is implemented"

The non-formatted i/o stdio code:
avr-libc-2.0.0/libc/stdio$ ls *.c | grep -v printf | grep -v scanf | xargs wc | tail -1
 1067  5812 39654 total

Everything in stdio:
avr-libc-2.0.0/libc/stdio$ wc * | tail -1
 4998  23588 160132 total

Rune


_______________________________________________
Tack-devel mailing list
Tac...@li...
https://lists.sourceforge.net/lists/listinfo/tack-devel