gforth
[Top][All Lists]
Advanced

[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

Attachment: pgpeOdJnACDF8.pgp
Description: PGP signature


reply via email to

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