Port-mips archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: mips64eb seems to be mostly 32-bit



On Sun, 04 Jul 2021 06:13:35 +1000
matthew green <mrg%eterna.com.au@localhost> wrote:

> > The odd thing is, whilst the kernel is aware that the CPU is 64-bit,
> > the userspace binaries from the install sets are 32-bit. The same
> > stands for the binaries that come from pkgsrc and for the binaries
> > compiled from C code natively on the system. Is there a fundamental
> > reason for this, or is this a build system issue?  
> 
> this is normal.
> 
> the binaries are 32-bit but require a 64-bit CPU, as they rely
> upon 64 bit registers existing, but run in a 32-bit address
> space, which generally reduces the memory requirements for the
> same task, and often the performance is the same (since the
> native 64-bit maths operations are available) or even better,
> and sometimes worse.
> 
> we are starting to prepare a pure-64 bit mips system, but it
> is still not quite ready for general usage (if you notice that
> -current/HEAD builds now include "mipsn64*" builds.  note the
> 'n' in the middle.  but these aren't for netbsd 9.x releases,
> and will hopefully be properly working for netbsd 10.x.)

Thank you for the comments Matthew. I understand n32 userspace is the
intended arrangement for mips64eb, which until recently was the only
build with Octeon kernel. Until you explained it, I didn't notice the
appearance of n64 builds, one of which seems to support Octeon too.

I also understand the n64 builds resemble OpenBSD/octeon (which is
fully 64-bit). The mipsn64eb directory index does not include X11, but
seems to include all the files my setup requires. The additional binary
packages would need to be built on the system, of course. I hope
pkgsrc-2021Q2 is good enough for that. Other than that, are you aware of
any particular issues that would make mipsn64eb unsuitable for compiling
and running C programs over SSH?

The system (a Buildbot worker) is going to run from USB storage, and it
would be nice to be able to move the storage between E100 and E300
devices as required. As the best support for Octeon seems to be in
NetBSD-current only, the system is going to run on snapshots until the
10.0 release regardless if the userspace is n32 or n64. Please correct
me if this is not the case.

This way, if I have to choose between two snapshots anyway and if
mipsn64eb is already viable for C userspace development and you think
it would be more useful to run another test system in n64 rather than
n32, I can try switching to mipsn64eb to see how it goes. Let me know
what you think.

-- 
    Denis Ovsienko


Home | Main Index | Thread Index | Old Index