[M3devel] [M3commit] CVS Update: cm3

[Olaf Wagner]

Quoting Jay <jayk123 at hotmail.com>:

> Good, a happy customer. :)
>
>> GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386
>> GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNU
>> GNU_MODE = 2 % Use GNU tools maximally -- not existant but probably
>> easy
>>
>> Eh..I know, not great.. what do "minimally" and "maximally" mean.
>
> I'm still fishing for anyone to provide answers to these
> less important decisions that I have trouble with.
> Otherwise maybe no NT Cygwin system.
>
> TARGETs = { NT386, NT386GNU, NT386CYGWIN }?
> TARGETs = { NT386, NT386MINGWIN, NT386CYGWIN }?
> TARGETs = { NT386 + GNU_MODE }?
>
> The one reason I don't favor NT386 + GNU_MODE is that Cygwin has a   
> much larger jmpbuf than the others.
> I think same TARGET implies code can be linked together, and I think  
>  varying jmpbuf implies otherwise.
> So NT386 and NT386MINGWIN should rarely cross paths with NT386CYGWIN.

I think a new target is called for if I have understood everything right.
We need one pure native target (NT386), one pure-Cygwin-based target
(NT386_CYGWIN?) and one mix of runtime, gnu tools and mingwin
(NT386_MINGWIN?).

As NT386GNU already exists, we must decide if we want to use it as
we traditionally did (all Cygwin) or the mixed implementation
(Mingwin and much Windows RT).

> I also do NOT like this ad-hoc naming style.
> PPC_DARWIN, I386_DARWIN are much more to my style.
> The names should be somehow hierarchical, except, I realize, there   
> isn't necessarily one "path" of
> stuff which to name platforms, though the GNU folks have settled on   
> a way or two.
> They have triples or quadruples -- processor-hardware-os or such,   
> however this doesn't
> clearly suffice.

Well, yes, something more systematic would have been better, but
to break with the history will cause much trouble for all users and
the infrastructure. So I'd rather vote that only new targets get
more systematic names.

> Something that accomodates:
>   NT386 + LLVM
>   NT386 + Watcom, linker and/or backend and/or runtime
>   NT386 + Digital Mars linker and/or backend and/or runtime
>   A C generating backend, and then linker/runtime
>   and similar IA64, AMD64 variants would be good.

I'm not sure that a C generating backend would really help matters.
This was done in the first implementation of DEC, and they soon
abandoned it as C had proven to be a bad choice as intermediate language.
I agree it would be great for cross-compilation etc.

As far as C and RT dependencies of native Windows compilers go, I don't
see why this couldn't be just a question of another cm3.cfg setup.

> To a large extent, these can be few platforms, subject to   
> configuration, like if all
> the linkers consume a common file format (not clear), and if all the  
>  jmpbufs are the same
> size (known to be partly true, partly false).

Yes, jmpbuf is always a problem for user threads and exceptions.
On Unix systems the jmpbuf and other important low-level structures
are always defined by the system headers and independent of compilers
AFAIK, so I'm a bit surprised that it should be different on Windows.
But maybe I'm just wrong and haven't just seen the right counter
examples...

> Oh and another thing, the runtime dependency is very likely cuttable, however
> PRESUMABLY real world applications (if there are any) link in a   
> substantial amount of
> C or C++, in which case, it isn't necessarily cuttable.

Yes. Real world applications tend to link other libraries (C, C++,
Fortran, ...) and even often call other applications like sh etc.

> As well, if I can figure out a good way to do it, switching NT386   
> from awful slow
> frequent TlsGetValue/TlsSetValue to manipulating the linked list in   
> fs:0, that would be nice,
> and might incur a C runtime dependency, but well worth it. The way   
> Modula-3 works here
> is terrible. Another compromise option is probably   
> __declspec(thread), though there is trickiness there
> in terms of being in a .dll that isn't used by the .exe.

Such optimizations should be done depending on the target.

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