> > My personal belief is that the mips and mips64 trees
> > should ultimately be merged, and that creating additional
> > and gratuitous differences should be avoided.
> I don't think it's possible to be fully achieved. Some differences will
> have to exist, at least in the headers, but likely within the arch tree as
> well. The reason is binary code size or perfomance -- having R3000
> support code in mips64 binaries is simply ridiculous as is using 32-bit
> operations with 64-bit data on a 64-bit CPU. However, it is worth trying
> to minimize visible differences where possible, e.g. by convincing the
> compiler to optimize irrelevant bits away.
I am not interested in running R3000's with 64-bit
binaries - only in having common sources for both.
I fully expect that there will always be differences
between the platforms, but the last time I checked,
there were more identical or nearly identical source
modules across the two arch trees than there were
distinctly different ones. The result is that the
two subtrees tend to drift out of sync. For me,
it's really a "Software Engineering 101" kind of
thing that there should be exactly one instance
in the source tree of any source module that is
common to 32-bit and 64-bit MIPS kernels, and that
where the code cannot be common, sensible rules should
be applied in terms of when to put both sets of code
in the same module as conditionally complied blocks and
when to split things out into seperately maintained
modules. Etc. Etc.