Re: [Tack-devel] all of Ack-5.5 under Linux

[<u-...@ae...>]

On Thu, Jun 21, 2018 at 12:30:23AM +0200, David Given wrote:
> > "a combinations of a CPU and an OS syscall API"?

> Yup. In fact, 5.5 had the same divide, it's just it put both types of thing
> in the same mach directory --- this is why there's a mach/minix (containing
> the OS-specific bit) and a mach/i386 (containing the CPU-specific bit). I
> split these into two directories because I found it confusing.

Sigh.

> The libc is currently in lang/cem/libcc.ansi, and it contains both the
> OS-generic things like strcmp() and malloc(), and also some OS-specific
> things like system() and stdio, which rely on Posix system calls. This is
> all mixed together and there's no (good) way for a plat to configure it.

> > The reusable parts do not logically "belong" to any "machine target"
> > so for clarity should have their own place.
> 
> What do you mean by reusable parts in this context?

I mean that the product, the useful "platform" implementations are being
constructed from pieces of varying generality (the libcs, the runtime
support like floating point routines, even the code generators can have
common parts).

For example a "malloc()" implementation can be usable with multiple
OS APIs and multiple CPUS, but probably not suit all of the ones or the
others.

It would be quite straightforward to have a copy of each needed piece to
be present at each "platform" but then we'd have lots of duplicated code.

The duplicated part would be what I call "reusable" (i.e. not "specific"
nor "common", the latter being an extreme special case of "reusable").

It is the irregularity of reusability of different parts of the code
which makes the picture cloudy.

To make it better, the first thing could be to write down
a document about the relations/reuse of the different parts of the code.

The next step would be to streamline the namespacing (the directory
tree allocation) so that all differently used parts would be separated
from each other.

OTOH the right thing is of course what works for you the developer.

Regards,
Rune