gforth
[Top][All Lists]
Advanced

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

Re: [gforth] Running Gforth on Mips64el


From: Bernd Paysan
Subject: Re: [gforth] Running Gforth on Mips64el
Date: Sun, 25 May 2014 15:11:17 +0200
User-agent: KMail/4.11.5 (Linux/3.11.10-11-desktop; KDE/4.11.5; x86_64; ; )

Am Sonntag, 25. Mai 2014, 05:03:51 schrieb David Kuehling:
> >>>>> "David" == David Kuehling <address@hidden> writes:
> > I googled around on the topic and it does not look like something
> > usable exists in autoconf.  I think the cleanest way would be to check
> > (via configure?) for the corresponding C-compiler #defines.  Of course
> > that would have to be implemented for every (supported) machine-type
> > and ABI.  I'd volunteer for the MIPS part.  I think the topic would
> > also be relevant for at least i386 (i386 vs. X32 ABIs) and ARM (eabi
> > vs. oabi, although these are pretty subtile, ABI-CALL may not even
> > show any differences).  Maybe amd64 also (windows vs. linux ABI, do
> > these have names?)
> 
> 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.
> The autoconf support for detecting host triplet (AC_CANONICAL_HOST [1])
> seems to be completely broken and unusable (e.g. it returns
> 'mips64el-unknown-linux-gnu' for both mipsel and mips64el/N64).  However
> 'gcc -dumpmachine' seems to reliably give host triplets that encode all
> information relevant to code generation:
> 
>   mipsel-linux-gnu                (mipsel)
>   mips64el-linux-gnuabi64         (mips64el/N64)
>   x86_64-linux-gnu                (amd64)
> 
> There seem to be efforts to standardize on host triplets [2], so I'd say
> we piggyback on these efforts instead of trying to reinvent the wheel.
> 
> 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?  In
> the examples above cpu would be 'mipsel', 'mips64el', 'x86_64'.
> 'vendor' would be 'unknown' and OS would be 'linux-gnu', or
> 'linux-gnuabi64'.

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

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.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

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