[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/
signature.asc
Description: This is a digitally signed message part.
Re: [gforth] Running Gforth on Mips64el, David Kuehling, 2014/05/24