As you might already know the R4000 and revision 1.0 of the R4400
processor suffer from a few errata that make 64-bit operation problematic
with standard code. Under certain conditions, doubleword addition and
extended shift instructions can produce incorrect results.
There is no hardware workaround available for these problems, but by
carefully selecting instruction sequences and avoiding certain operations
reliable code can be generated that does not trigger these problems. The
current version of Linux as present in our CVS executes specific tests for
these errata early during bootstrap and if found, then code is checked for
having been generated by tools that are aware of the respective problem.
If the code fails such a check then the kernel refuses to boot.
I'm pleased to announce a toolchain that supports software workarounds
for these errata is available at my site. The stable versions are:
1. binutils 2.14:
- mips64el-linux-binutils-2.14-3.src.rpm -- a source package,
- mips64el-linux-binutils-2.14-3.i386.rpm -- an i386 binary package,
2. gcc 2.95.4:
- mips64el-linux-boot-gcc-2.95.4-15.src.rpm -- a source package,
- mips64el-linux-boot-gcc-2.95.4-15.i386.rpm -- an i386 binary package.
3. glibc 2.2.5 (headers needed to rebuild gcc):
- mips64el-linux-boot-glibc-headers-2.2.5-6.src.rpm -- a source package,
- mips64el-linux-boot-glibc-headers-2.2.5-6.noarch.rpm -- an
architecture-independent binary package.
As implied by the names, all these are tools for a cross-compilation.
Binary packages are provided for convenience only -- a cross-binutils
binary package may be generated for any architecture with a native gcc
compiler from the source package which is self-contained and with the aid
of the supplied glibc headers, the cross-gcc package can be regenerated as
Due to the lack of support for mips64 in glibc 2.2.x, the gcc package is
provided in a minimal configuration (hence the -boot- infix) with the
plain C compiler and libgcc only. It is sufficient to build Linux
The toolchain enables workarounds in code generators whenever a 64-bit
output is requested (e.g. "-mabi=64") and either an R4000 or an R4400 CPU
is selected (e.g. "-march=r4000"), as appropriate for the workaround.
For the extended shift errata a workaround is activated for the R4000
CPU. There is no further control of the setting. When active,
problematic sequences of a multiplication or division and an extended
shift are avoided in the generated code.
For the doubleword addition errata a workaround is activated for both the
R4000 and the R4400 CPU. Additionally, there is a new option "-mdaddi"
and its negation -- "-mno-daddi", recognized by both gcc and gas, which
activate and deactivate the workaround respectively. There is a pair of
assembly directives, ".set daddi" and ".set nodaddi", as well, which
operate just like respective command line options. The workaround makes
gcc avoid emitting certain macro instructions that expand to sequences
containing problematic doubleword additions. For gas it makes problematic
doubleword additions, that would normally be machine instructions, be
expanded as macros using safe replacements. As a side effect certain
macros have a more strict requirement on their arguments as otherwise two
temporary registers would be needed. This is the reason gcc needs to
avoid such macros and also why code emitted by `gcc -mdaddi' could not
necessarily be successfully assembled by `as -mno-daddi'.
You are welcome to use the tools and I'll appreciate feedback. As a few
assembly bits of the kernel cannot be compiled with "-mno-daddi", I have
prepared appropriate patches, which are available upon request (version
2.4 only). If you have a processor which has its PRId in the range from
0x0400 to 0x044f inclusive and would like to use a 64-bit kernel, then the
tools are for you. I've been using 64-bit kernels built with these tools
with my R4400-based DECstation for some time now and they appear no less
stable than their 32-bit counterparts.
If there are problem reports with the tools I'm going to maintain them
for the time being, but in the long run I'm going to work on merging
appropriate bits into the mainline. Therefore I do not expect to put much
more work into these particular versions of tools and I'm focusing on
upgrading the changes to apply against current versions of software. In
particular I'm not going to write any more decent documentation than this
notice before I get the upgrade done (sorry). My goal is to get gcc
patches upgraded to 3.4 and attempt to merge them into 3.5. With respect
to binutils, I've already upgraded to 2.14.90 and I suppose to try a merge
attempt for 2.16.
The address of my site is the same as always:
'ftp://ftp.ds2.pg.gda.pl/pub/macro/' -- see the "SRPMS" and "RPMS"
directories for source and binary packages, respectively.
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+ e-mail: email@example.com, PGP key available +