lkml.org 
[lkml]   [2018]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4 3/7] mips: rename macros and files from '64' to 'n64'
Hi Paul,

> > My feeling has been n32 was invented at SGI as an afterthought, hence the
> > choice of having ABI32 or ABI64 defined for the 32-bit (now o32) and the
> > 64-bit (now n64) ABI respectively was reasonable.
>
> I'd agree if _MIPS_SIM were defined as _ABI32 for o32, but:
>
> $ mips-linux-gcc -mabi=32 -dM -E - </dev/null | grep ABIO32
> #define _ABIO32 1
> #define _MIPS_SIM _ABIO32
>
> ...so _MIPS_SIM is:
>
> _ABIO32 for o32
> _ABIN32 for n32
> _ABI64 for n64
>
> That doesn't seem very consistent to me, and means that there inevitably
> has to be some ugliness once there are multiple 64-bit ABIs.

The _ABI* macros were invented as a GNU feature long after _MIPS_SIM_*
ones, i.e. IIRC early 2000s vs mid 1990s. Only _MIPS_SIM_* macros are
referred in SGI documentation.

It is inconsistent and I don't know why whoever invented the _ABI* macros
didn't follow the original naming convention chosen by SGI for _MIPS_SIM_*
ones, i.e. _ABI32, _NABI32, _ABI64 (but then I don't know either why some
people have troubles with recognising patterns in existing code and then
following those patterns when making changes or additions to that code; I
guess that's just what some people are like).

BTW in case anybody wondered SIM stands for Subprogram Interface Model.

> To me it feels like the result of someone thinking "one 64-bit MIPS ABI
> ought to be enough for anybody". I'm undecided whether that person was
> shortsighted or a genius whose vision was simply incomprehensible to
> those of us that followed.

I think back when 64-bit processors were a new invention hardly anyone
thought about proliferating 64-bit ABIs. Remember that first MIPS systems
were high-end workstations and servers and n32 was invented as a means to
conserve memory, which wasn't seen as a necessity at the beginning. A
secondary goal might have been improving the performance of badly-written
32-bit software, by means of the better function calling convention n32
has over o32.

Notice for example that for a long time x86-64 only had a single native
64-bit ABI, which is LP64 like our n64, and it was only quite recently
that the x86-64 x32 ILP32 ABI was added, which is like our n32. And yet
at this very moment it is being discussed on LKML whether x32 actually has
any users beyond developers who maintain it and consequently whether it is
worth it to keep support for it in our kernel. To me it means in the
workstation and server segment there is still no need to conserve memory
(and with the ubiquity of 64-bit systems nowadays the need to maintain
unportable 32-bit software has largely disappeared).

So if anything was not expected it was the expansion of 64-bit MIPS
processors into the embedded market or indeed the scale of the expansion
of the embedded market itself, but I wouldn't call the lack of such an
expectation short-sightedness. It would be too bold a statement to me,
because the change was simply too revolutionary to be considered some 25
years ago. Nobody in early 1990s would think of a 64-bit computer in a
ballpoint pen or suchlike being a common device and the consequences for
code design it would have.

FWIW,

Maciej

\
 
 \ /
  Last update: 2018-12-11 11:59    [W:0.133 / U:0.816 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site