[EMAIL PROTECTED] (Ludovic Courtès) writes: > Greg Troxel <[EMAIL PROTECTED]> writes: > >> This just adds defines for more platforms, plus fixes a comment typo. >> >> $NetBSD: patch-ae,v 1.13 2007/07/20 00:09:22 gdt Exp $ >> >> support for NetBSD/alpha, NetBSD/sparc64, and NetBSD/x86_64 >> > I'm unclear about some of the changes below. > >> -# if defined(__NetBSD__) && defined(__sparc__) >> +# if defined(__NetBSD__) && (defined(__sparc__) || defined(__sparc_v9__)) > > Two questions: > > 1. Isn't `__sparc__' defined on V9? On GNU/Linux, it seems that it is > defined on both V9 and V8, so no special treatment is required.
I tested on both NetBSD 4-stable on an ultra2, and on 3-stable on an ultra5. Both had __sparc__ defined. On the ultra2, I built guile from pkgsrc without this patch, and then did 'make check' and it passed. So I'd say the __sparc_v9__ can be safely omitted. But, I'm nervous that 64-bit sparc and 32-bit sparc aren't the same thing, and don't necessarily have the same alignment rules and sizes. > 2. Unless I'm mistaken, this is equivalent to > > #if (defined(__NetBSD__) && (defined(__sparc__))) || > (defined(__sparc_v9__)) > > while this should probably be: > > #if defined(__NetBSD__) && (defined(__sparc__) || > (defined(__sparc_v9__))) Sorry, I don't follow this at all - it looks fine to me. But it's moot, as the change can be skipped. >> +# if defined(__NetBSD__) && defined(__x86_64__) >> +# define X86_64 >> +# define NETBSD >> +# define mach_type_known >> +# endif > > [...] > >> +# ifdef X86_64 >> +# define MACH_TYPE "X86_64" >> +# define ALIGNMENT 8 >> +# define ALIGN_DOUBLE >> +# define CPP_WORDSZ 64 >> +# ifdef NETBSD >> +# define OS_TYPE "NETBSD" >> +# endif >> +# if defined(NETBSD) >> +# define HEURISTIC2 >> + extern char etext; >> +# define DATASTART ((ptr_t)(&etext)) >> +# endif >> +# endif > > Strangely enough, we don't have `LINUX && __x86_64__' either. > Interestingly, of these constants, it seems that Guile uses only > `HEURISTIC2'. For instance, Guile's GC gets the alignment constraint > through the definition of `SCM_STACKITEM'. There's a comment in gc_os_dep.c that says ALIGNMENT needs to be defined. The other arches seem to define it. (Not arguing that it's used.) I suppose the challenge is to figure out how/why guile works on Linux amd64 systems. > Hence my question: didn't the NetBSD/i386 support suffice on x86-64? > What exact problem did it solve? I don't know - I can inquire. But amd64 (as we call it) is a different processor architecture, with a different pointer size, so I don't see how the i386 support would apply. I would not expect the i386 preprocessor symbols to be defined, but I don't have a netbsd/amd64 system (I really should set one up). Not sure this is relevant, but: On NetBSD, an amd64 system is all 64-bit native code. If there's i386 compat code, it's in /emul/netbsd32. The "lib64" convention is not used at all. > The other bits are indeed applicable. Thanks - I'll adjust the patch when there's a new release, dropping whatever you merged and also the sparc v9.
