gm2
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Partial success building the trunk on MSYS2/Windows platform


From: Gaius Mulley
Subject: Re: Partial success building the trunk on MSYS2/Windows platform
Date: Thu, 27 Oct 2022 16:19:07 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Runar Tenfjord <runar.tenfjord@gmail.com> writes:

> Excellent,


Hi Runar,

> Currently I am using ArchLinux for testing and development.
> It builds flawlessly as expected.

great news thanks!

> When gm2 is back ported to GCC12, I will submit a build recipe to the MSYS2
> repository and get some help with the outstanding issued.

awesome!

> Some other issues:

> * BITSET64 seems to be missing. Is this temporary or some
>  fundamental reason for the omission?

BITSET was fixed to WORD/INTEGER/CARDINAL.  But you're right as gm2
supports CARDINAL64 (if the architecture supports it) and
INTEGER64/WORD64 - then it looks like an oversight that BITSET64 is
missing!  Thanks I will fix this and test.  I suspect it might need
some runtime support - (if I recall from past experimentation).

> * I find that the WORD type is 32bit on my 64bit installation.

Yes as SIZE(WORD) = SIZE(BITSET) = SIZE(INTEGER) and on a LP64 system
(or amd64) then sizeof(int) = 4.

>  Is this connected to the above issue? Or due to portability?

It is also connected to interfacing to C (SIZE(INTEGER) == SIZE(WORD) ==
sizeof(int)) necessary for the underlying libraries.  Hence we can use
CARDINAL64 or INTEGER64 without breaking anything (but we cannot
guarantee CARDINAL64 will exist).

> * Can platform differences (Linux_x86_64, Windows64, etc) be switched
>  with the preprocessor or must this be handled by outer build system
>  like make?

The preprocessor can be used in user programs (some of the testsuite
does this for example).  The codebase of gm2 doesn't do this though as
the compiler is bootstrapped by converting it to C (or C++).  Is there a
particular problem you are trying to solve re: preprocessor?  I tend to
use the preprocessor in the underlying C code connecting to the system
calls though.  These choices were mainly down to keeping everything as
simple as possible (re: host/build/target differences).

regards,
Gaius



reply via email to

[Prev in Thread] Current Thread [Next in Thread]