[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gforth] Running Gforth on Mips64el
From: |
David Kuehling |
Subject: |
Re: [gforth] Running Gforth on Mips64el |
Date: |
Sat, 24 May 2014 16:42:47 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) |
>>>>> "Anton" == Anton Ertl <address@hidden> writes:
> Ultrix was only ever 32 bit (even on the machine with an R4000 that we
> had). Later I tested on IRIX (mipseb), but I doubt if this was MIPS64
> (even though the CPU was).
> Gforth 0.6.2 ran on hardware like AMD64 and IA-64 that it had not been
> tested on before, and that portability should be still there. The
> threading model needs no machine-dependent stuff, and even dynamic
> superinstructions need relatively little (and are disabled on unknown
> platforms).
My fear was more like some 32-bit MIPS-specific optimizations
(inline-assembly for double precision math or explicit register
allocation) being automatically enabled for mips64.
Yes, this stuff working out-of-the-box is a good indicator of Gforth's
portability
>> > What bugs me is that there is no way to determine the ABI of the >
>> underlying OS from within Gforth. Typeing MACHINE TYPE just gives >
>> 'mips' on both O32 and N64 ABIs. Gforth' MIPS assembler needs to
>> know > the ABI as register aliases differ by ABI. I could patch it
>> to just > check CELL-size and assume N64 if CELL=8 and O32 if CELL=4,
>> but then > it'll still fail on N32 MIPS systems (and O64 systems,
>> though these > should be extremely rare or non-existent).
>>
>> What does config.guess return on these different machines? I see
>> only mips or mips64, which we both turn to mips (actually, we should
>> keep mips64 as is), but I have no idea how to distinguish between O32
>> and N32.
Maybe 'mips64' is turned to 'mips' because it fails to indicate the
width of the user-space but just repeats what 'uname -m' reports? All
my oabi32 Debian installations on MIPS machines (Loongson2f and -3a)
report 'mips64' for 'uname -m'. For Loongson3A the Linux nowadays
doesn't even have an option to compile a 32-bit kernel.
> We could have a variable ABI-NAME or somesuch, but how to set it
> portably?
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?)
cheers,
David
--
GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk2.gpg
Fingerprint: B63B 6AF2 4EEB F033 46F7 7F1D 935E 6F08 E457 205F
pgpeOdJnACDF8.pgp
Description: PGP signature
Re: [gforth] Running Gforth on Mips64el, David Kuehling, 2014/05/24