I really don't understand why this 32-bit gone myth is happening. It was
poor wording at least. Debian doesn't even support the ancient 32-bit sparc
CPUs. Modern SPARC ABIs (post 1997) require 64-bit CPUs even when running
in 32-bit code, it's like x32 ABI in x86 land.
SPARCv7, SPARCv8 = old
Le 18/04/2014 14:16, Patrick Baggett a écrit :
I really don't understand why this 32-bit gone myth is happening. It
was poor wording at least. Debian doesn't even support the ancient
32-bit sparc CPUs. Modern SPARC ABIs (post 1997) require 64-bit CPUs
even when running in 32-bit code, it's like
Hi,
OpenJDK 8 is being packaged [1] and I'm looking for porters willing to
try and compile it on other architectures. So far it builds fine on
amd64 and some work has started for kFreeBSD. No other architecture has
been tested yet, so any help is welcome.
Thank you,
Emmanuel Bourg
[1]
Yeah, I understand why you would believe that. I'm not blaming you, I just
want to let everyone know the sentence 32-bit code generation as we use it
is no longer supported upstream is incorrect. You can see on the GCC 4.7
[1] and 4.8 [2] changes list that removing any SPARC code generation
I don't understand, there is no warning of abi or architecture deprecation
in the release notes of gcc, neither 4.7 nor 4.8.
Maybe they have information I don't, but I doubt it. I'll dig in the gcc
mailing list to see if I can find something related.
Sébastien
Doh, beat me to it by a
Doh, beat me to it by a minute. Yeah, you see what I mean. :)
It would be platform suicide to drop 32-bit code generation. Like many
RISC architectures, switching to 64-bit is only done for apps that
need it, because it is not free and will not, in general, make apps
faster. Anyone who has
6 matches
Mail list logo
