On Sat, Jan 11, 2003 at 06:43:52PM +0100, Dr. Ing. Dieter Jurzitza wrote:
> I think you've got me wrong. This define __SPARC_ARCH__ was only an
> *assumption* of mine. In fact, I am sure this define does *not*
> exist. Maybe I wasn't clear enough.
>=20
> But according to Thomas's discovery one could say __sparc__ instead.
Yes, __sparc__ does indeed work. I just made a patch for sane 1.0.7 as
used in the Aurora Linux RPM and rebuilt the RPM for sane-backends.
xsane (and hence sane) works fine now. As for performance: I can't
judge, as I have no comparison, but I'll test the same RPM on the SS20
as well some time tomorrow.
As for defines: I found this handy line of code on google (the output
you see below is for the U5/Aurora Linux 0.42):
[emgaron@lu-tze emgaron]$ gcc -dM -E - < /dev/null
#define __USER_LABEL_PREFIX__
#define __SIZE_TYPE__ unsigned int
#define __PTRDIFF_TYPE__ int
#define __HAVE_BUILTIN_SETJMP__ 1
#define __GNUC_PATCHLEVEL__ 0
#define __ELF__ 1
#define __WCHAR_TYPE__ int
#define __NO_INLINE__ 1
#define __GNUC_MINOR__ 96
#define __WINT_TYPE__ unsigned int
#define __sparc__ 1
#define __unix 1
#define unix 1
#define _LONGLONG 1
#define __REGISTER_PREFIX__
#define __linux 1
#define __GNUC__ 2
#define __linux__ 1
#define __VERSION__ "2.96 20000731 (Red Hat Linux 7.3 2.96-113)"
#define __GCC_NEW_VARARGS__ 1
#define linux 1
#define __unix__ 1
(In case someone is wondering about the compiler: Aurora is based on
RHL 7.3, basically an effort to get RHL on Sparc again).
As you can see, there's no indication that this is a 64bit machine -
which is not really surprising, as this is compiled/run from within
the 32bit userland. For all that gcc cares, it's 32bit, AFAIK.
> The question that ought to be answered by Abel (?) is whether it
> makes sense to globally switch to the old interface for sparc for
> the sake of simplicity - I do not know how big is the performance
> impact of this.
Performance is only one issue - you mention the other one below: 64bit
will come back to bite... :-} Not only in the x86 arena, also on the
Sun market - the prices of second hand UltraSparcs are dropping and
among them are quite a few nice machines to play around with at
home...:-)
[...]
> I am asking whether there is anywhere a declaration within the
> gcc-header files (or some kernel call, or whatsoever ...) that could
> be used as above for Ultra only. I personally do not know - but
> maybe someone on the list does.
I'm by no means an expert, but if I understand the results of my
google research correctly, there is no simple define to solve this. In
fact, one of the things I found when googling for "__sparc64__" was
a discussion between FreeBSD and NetBSD developers about whether gcc
should be patched to always set this define on Sparc64, regardless of
whether the compile is 32bit or 64bit. Aparently, it was regarded as a
bad idea by most. So, from my limited amount of knowledge I'd probably
go for a solution via configure, but I'm certain that Abel & Co know a
lot better than me what to do.
> Maybe one could check that in the configure script - do not ask me to do
> this, configure is something quite strange for me.
:-) I've only worked with it once but I think it's not *that* difficult
and it's definitely capable of doing this check.
Anyway, at least I can tackle that pile of magazines now with a faster
machine - thank a bunch, folks!
Cheerio,
Thomas
> P.S. Sch=F6nes Wochenende!
Danke, gleichfalls! :-)
--=20
---------------------------------------------------------------------------=
--
Thomas Ribbrock http://www.ribbrock.org ICQ#: 15839919
"You have to live on the edge of reality - to make your dreams come true=
!"
