Re: [gforth] Running Gforth on Mips64el

[Anton Ertl]

On Sun, May 25, 2014 at 03:11:17PM +0200, Bernd Paysan wrote:
> Am Sonntag, 25. Mai 2014, 05:03:51 schrieb David Kuehling:
> > After some more googeling I think the right approach would be to give
> > Gforth programs access to the host triplet that defines CPU, OS and ABI.

Yes.

> > Shall we just expose the full value returned by 'gcc -dumpmachine' or
> > split it into CPU and OS components as done by AC_CANONICAL_HOST? 
>
> Hm, this doesn't seem to be standardized well enough, the SuSE triple looks 
> wrong, and there's even a quadruple.
> 
> suse> gcc -dumpmachine
> x86_64-suse-linux
> > arm-linux-androideabi-gcc -dumpmachine
> arm-linux-androideabi
> > arm-none-linux-gnueabi-gcc -dumpmachine
> arm-none-linux-gnueabi
> debian$ gcc -dumpmachine
> x86_64-linux-gnu

The quadruple is a triple where the last component ("linux-gnu" and
"linux-gnueabi") contains a "-".  The Suse triple looks ok (ok, Suse
is no hardware vendor, but the vendor part is not that important these
days anyway), the Debian triple looks wrong.

> I would suggest to have separate the triple so that you can query the 
> processor, the OS and the ABI separately.  E.g. the typical place for OS is 
> OS-specific calls or structures in C bindings, and you usually don't care if 
> that is one or the other ABI.

Yes, if we have consistent component names, splitting and doing STR=
on the components would be the way to go.  As it is, I wonder if it
wouldn't be better to provide the whole string and then use SEARCH to
check for the architecture and/or the OS/ABI.

- anton