more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2

more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2

[Ken Raeburn]

Compiling with SCM_DEBUG_TYPING_STRICTNESS=2 causes SCM to be defined  
as a union type (though the comments say a struct type), which  
enhances the type checking by making random conversions and casts to  
and from pointer and integer types not work without going through the  
correct conversion macros/functions.

Problem is, we're doing some of those.

It also means constant values for static initializers ("{ { BITS } }")  
have a different form from run-time expressions generating certain  
values ("scm_pack (BITS)" calls an inline function), and comparisons  
can't be done with "==" and "!=".  (In fact, tags.h already says "SCM  
values can not be compared by using the operator ==", right above the  
definition of scm_is_eq.)

Guess what we're also doing? :-)
And I haven't even tried compiling Ludovic's bdw-gc-static-alloc  
branch yet, just master.

I can clean some of this up trivially -- SCM_PACK/SCM_UNPACK as  
needed, change == to scm_is_eq.  The initializers make it slightly  
less trivial, and I can imagine different courses of action.

#1: We continue to not support static initialization.  Move most of  
the initializations in the library to the per-file init functions, and  
for stuff like the ra_iproc tables in array-map.c we may want *one*  
internal initializer macro (SCM_I_UNSPECIFIED_INIT or  
SCM_I_UNDEFINED_INIT? maybe even something zero-valued) for filling in  
slots in static structures without getting compiler warnings about  
missing initializers.

#1a: Extend #1 later with whatever internal macros are needed to  
provide the right initialization syntax for constructs used in bdw-gc- 
static-alloc based on the STRICTNESS setting.

#1b: Try to supplement #1 with changes to SCM_PACK or SCM_MAKIFLAG to  
make it not considered a compile-time constant even with STRICTNESS<2  
and thus SCM_UNSPECIFIED, SCM_BOOL_F, etc are never suitable for  
static initialization, catching this problem earlier in the future.  I  
believe a use of a comma expression will suffice, but finding a form  
that doesn't generate compiler warnings and doesn't generate run-time  
code could be tricky.  (Though, it becomes easier if we require only  
no performance impact when optimizing and with ... what, inline  
function support? gcc?)

#1c: Try to supplement #1 by defaulting to STRICTNESS=2 on platforms  
where the union is passed and returned the same way as the pointer or  
integer in function calls, and where there isn't a significant  
performance impact.  Probably selected via cpp macros in __scm.h,  
since an autoconf feature test would be difficult at best, and still  
specific to the compiler used for building libguile and not the one  
used to build the application.  This helps us avoid the "==" and  
random casting part of the problem better in the future.  Mac OS X  
(10.5, Intel) seems to use the same calling convention both ways in  
one simple test, though I haven't tried performance testing.

#2: Drop STRICTNESS=2 support and really support static initialization  
with the current macros.

#3: Keep STRICTNESS=2 support, and support static initialization, even  
for application code, with a bunch of new macros.

Thoughts?  My preference is for #1 now, and #1a/b/c when convenient or  
needed.

Ken

more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2

[Ken Raeburn]

[[ Resending from an account I'm actually subscribed with. ]]

Compiling with SCM_DEBUG_TYPING_STRICTNESS=2 as discussed in __scm.h  
causes SCM to be defined as a union type (though the comments say a  
struct type), which enhances the type checking by making random  
conversions and casts to and from pointer and integer types not work  
without going through the correct conversion macros/functions.

Problem is, we're doing a lot of those.

It also means constant values for static initializers ("{ { BITS } }")  
have a different form from run-time expressions generating certain  
values ("scm_pack (BITS)" calls an inline function), and comparisons  
can't be done with "==" and "!=".  (In fact, tags.h already says "SCM  
values can not be compared by using the operator ==", right above the  
definition of scm_is_eq.)

Guess what we're also doing? :-)
And I haven't even tried compiling Ludovic's bdw-gc-static-alloc  
branch yet, just master.

I can clean some of this up trivially -- SCM_PACK/SCM_UNPACK as  
needed, change == to scm_is_eq.  The initializers make it slightly  
less trivial, and I can imagine different courses of action.

#1: We continue to not support static initialization.  Move most of  
the initializations in the library to the per-file init functions, and  
for stuff like the ra_iproc tables in array-map.c we may want *one*  
internal initializer macro (SCM_I_UNSPECIFIED_INIT or  
SCM_I_UNDEFINED_INIT? maybe even something zero-valued) for filling in  
slots in static structures without getting compiler warnings about  
missing initializers.

#1a: Extend #1 later with whatever internal macros are needed to  
provide the right initialization syntax for constructs used in bdw-gc- 
static-alloc based on the STRICTNESS setting.

#1b: Try to supplement #1 with changes to SCM_PACK or SCM_MAKIFLAG to  
make it not considered a compile-time constant even with STRICTNESS<2  
and thus SCM_UNSPECIFIED, SCM_BOOL_F, etc are never suitable for  
static initialization, catching this problem earlier in the future.  I  
believe a use of a comma expression will suffice, but finding a form  
that doesn't generate compiler warnings and doesn't generate run-time  
code could be tricky. (Though, it becomes easier if we require only no  
performance impact when optimizing and with ... what, inline function  
support? gcc?)

#1c: Try to supplement #1 by defaulting to STRICTNESS=2 on platforms  
where the union is passed and returned the same way as the pointer or  
integer in function calls, and where there isn't a significant  
performance impact. Probably selected via cpp macros in __scm.h, since  
an autoconf feature test would be difficult at best, and still  
specific to the compiler used for building libguile and not the one  
used to build the application.  This helps us avoid the "==" and  
random casting part of the problem better in the future.  Mac OS X  
(10.5, Intel) seems to use the same calling convention both ways in  
one simple test, though I haven't tried performance testing.

#2: Drop STRICTNESS=2 support and really support static initialization  
with the current macros.

#3: Keep STRICTNESS=2 support, and support static initialization, even  
for application code, with a bunch of new macros.

Thoughts?  My preference is for #1 now, and #1a/b/c when convenient or  
needed.

Ken

Re: more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2

[Ken Raeburn]

On Sep 1, 2009, at 02:23, Ken Raeburn wrote:
> I can clean some of this up trivially -- SCM_PACK/SCM_UNPACK as  
> needed, change == to scm_is_eq.  The initializers make it slightly  
> less trivial, and I can imagine different courses of action.

Okay, not quite so trivial as I blithely asserted.

It looks like the eval code is going to be annoying too -- lots of  
case labels that are constructed by making SCM values and then  
extracting bits from them with ISYMNUM, which won't work with a  
union.  I'm thinking, maybe an enum or list of macros to define the  
basic set of integers, and then apply SCM_MAKISYM to the enumerator  
values, and then we can refer to the values symbolically without  
extracting bits out of constructed SCM values?

The smob creation macros play fast and loose with types, and accept  
anything that can be cast to scm_t_bits... which doesn't include union  
types like SCM in this mode; extracting values is similarly messy.   
I'm not sure that can be cleaned up without changing the API.

There are also bits that I suspect won't build cleanly if SCM is an  
integer (STRICTNESS=0), too.

Ken

Re: more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2

[Ludovic Courtès]

Hi Ken,

Ken Raeburn <raeburn@raeburn.org> writes:

> Compiling with SCM_DEBUG_TYPING_STRICTNESS=2 as discussed in __scm.h

Another compilation flag that must be rarely used.  :-)

Do you find it useful?

> It also means constant values for static initializers ("{ { BITS } }")
> have a different form from run-time expressions generating certain
> values ("scm_pack (BITS)" calls an inline function), and comparisons
> can't be done with "==" and "!=".  (In fact, tags.h already says "SCM
> values can not be compared by using the operator ==", right above the
> definition of scm_is_eq.)
>
> Guess what we're also doing? :-)
> And I haven't even tried compiling Ludovic's bdw-gc-static-alloc
> branch yet, just master.

Indeed, we're in trouble.

> #1: We continue to not support static initialization.
[...]

> #1a: Extend #1 later with whatever internal macros are needed to
> provide the right initialization syntax for constructs used in bdw-gc- 
> static-alloc based on the STRICTNESS setting.
>
> #1b: Try to supplement #1 with changes to SCM_PACK or SCM_MAKIFLAG to
> make it not considered a compile-time constant even with STRICTNESS<2
> and thus SCM_UNSPECIFIED, SCM_BOOL_F, etc are never suitable for
> static initialization, catching this problem earlier in the future.
[...]

> #1c: Try to supplement #1 by defaulting to STRICTNESS=2 on platforms
> where the union is passed and returned the same way as the pointer or
> integer in function calls
[...]

> #2: Drop STRICTNESS=2 support and really support static initialization
> with the current macros.
>
> #3: Keep STRICTNESS=2 support, and support static initialization, even
> for application code, with a bunch of new macros.

My preference is for #2 because: (1) I've never used it ;-), and
(2) we're moving away from C anyway.  Hmm, weak arguments maybe.

Anyway, in the meantime, we can conditionalize static initialization
stuff from bdw-gc-static-alloc on STRICTNESS == 0 and keep everyone
happy.

Does that sound reasonable?

> It looks like the eval code is going to be annoying too

I wouldn't worry much about this one either as its probably doomed, once
Andy's eval cleanup work is mature.

Things have been moving too fast lately!

Thanks,
Ludo'.

Re: more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2

[Ken Raeburn]

On Sep 1, 2009, at 15:47, Ludovic Courtès wrote:
>> Compiling with SCM_DEBUG_TYPING_STRICTNESS=2 as discussed in __scm.h
>
> Another compilation flag that must be rarely used.  :-)
>
> Do you find it useful?

Not so far. :-)  There seems to be a lot of otherwise correct code  
making assumptions about using casts or "==" or whatever; I haven't  
sorted out whether there are actual bugs being flagged in there too.

The corresponding code in Emacs has helped me track down code that was  
being sloppy about mixing integers and Lisp values, and that was good,  
since I'm trying to change things so that integers represented in Lisp  
have bit patterns different from the integers themselves, so you  
really need to make the distinction.  But IIRC it took a while to make  
it work again, because nothing was really using it when I started  
poking at it.

In the Guile case, I'm a tiny bit concerned about some of the pointer/ 
int games played (e.g., I'm pretty sure C99 does not guarantee that  
you can convert an arbitrary uintptr_t value to pointer and back and  
be guaranteed of getting the original value... but I don't know of a  
platform that actually violates that assumption), but only a tiny bit.

> My preference is for #2 because: (1) I've never used it ;-), and
> (2) we're moving away from C anyway.  Hmm, weak arguments maybe.
>
> Anyway, in the meantime, we can conditionalize static initialization
> stuff from bdw-gc-static-alloc on STRICTNESS == 0 and keep everyone
> happy.
>
> Does that sound reasonable?

Sure.  Actually, STRICTNESS=1 is the default -- 0 makes SCM an  
integer, 1 makes it a pointer to a struct, which adds a little more  
type safety, and 2 makes it a union, which breaks casting,  
initialization, etc.

>> It looks like the eval code is going to be annoying too
>
> I wouldn't worry much about this one either as its probably doomed,  
> once
> Andy's eval cleanup work is mature.
>
> Things have been moving too fast lately!

I'm not going to complain about that! :-)

Ken

Re: more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2

[Ludovic Courtès]

Hi!

Ken Raeburn <raeburn@raeburn.org> writes:

> In the Guile case, I'm a tiny bit concerned about some of the pointer/
> int games played (e.g., I'm pretty sure C99 does not guarantee that
> you can convert an arbitrary uintptr_t value to pointer and back and
> be guaranteed of getting the original value... but I don't know of a
> platform that actually violates that assumption), but only a tiny bit.

Really?  I think the whole purpose of `uintptr_t' is to allow that,
isn't it?

>> Anyway, in the meantime, we can conditionalize static initialization
>> stuff from bdw-gc-static-alloc on STRICTNESS == 0 and keep everyone
>> happy.
>>
>> Does that sound reasonable?
>
> Sure.  Actually, STRICTNESS=1 is the default -- 0 makes SCM an
> integer, 1 makes it a pointer to a struct, which adds a little more
> type safety, and 2 makes it a union, which breaks casting,
> initialization, etc.

Oh, right.

Thanks,
Ludo'.

Re: more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2

[Ken Raeburn]

On Sep 2, 2009, at 04:08, Ludovic Courtès wrote:
>> In the Guile case, I'm a tiny bit concerned about some of the  
>> pointer/
>> int games played (e.g., I'm pretty sure C99 does not guarantee that
>> you can convert an arbitrary uintptr_t value to pointer and back and
>> be guaranteed of getting the original value... but I don't know of a
>> platform that actually violates that assumption), but only a tiny  
>> bit.
>
> Really?  I think the whole purpose of `uintptr_t' is to allow that,
> isn't it?

It's the other way around that's guaranteed to work: void* ->  
(u)intptr_t -> void*.  So any value originally derived from a valid  
pointer will work, but arbitrary values may not.  Also, C99 talks  
about uintptr_t as being capable of holding a converted pointer-to- 
void; strictly speaking, I don't think it requires that a direct  
conversion from/to any other pointer type (except possibly char*) work  
the same way.

So, for example, uintptr_t may have 64 bits on a machine that uses 48- 
bit pointers (segment+offset? also, some embedded processors have non- 
power-of-two pointer or integer sizes, though I don't know whether  
they have pointer and int types matching in size); pointers may have  
trapping representations (invalid segment number?); storing an integer  
value into a pointer register may cause certain bits to be masked off;  
manipulation of pointer values in general registers may not preserve  
bits known by the compiler not to be set in any valid or null  
pointers; etc.

And then there's the whole NULL-vs-0 thing -- "0" is a null pointer  
constant in source code, but strictly speaking the compiler produces a  
null pointer constant there; it doesn't imply that the null pointer  
has the same binary representation as 0, nor that a non-constant zero  
value when cast to a pointer will be a null pointer, nor that memset(, 
0,) gives you null pointers, nor that a null pointer cast to uintptr_t  
will have the value 0, etc.

(For example, in an architecture with one pointer format for segment +  
word offset, and a second representation for segment + word offset +  
bit offset into word, a void* may require the second form, but a  
struct pointer might use the former, if all structs are required to be  
word-aligned.  And converting a pointer to uintptr_t could just copy  
bits around, giving consistent results only if you use the same  
pointer form consistently in the conversions.  And all-bits-zero may  
store an invalid segment number that could lead to a trap when loaded  
into a pointer register, and a "null pointer" may be represented with  
a reserved non-zero segment number.  This is not completely  
theoretical... I once used a platform with multiple pointer types and  
a null pointer representation using segment number -1, which could be  
loaded without faulting but not dereferenced, but I'm rusty on some of  
the details, and never got familiar with the C environment on it.)

Like I said, most platforms I know of, and all I know of that we're  
likely to care about, will still meet these assumptions to the best of  
my knowledge, so it's probably not a big problem.  But as a bit of a  
language pedant, I did notice...

Ken

Re: more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2

[Ludovic Courtès]

Hi!

Ken Raeburn <raeburn@raeburn.org> writes:

> On Sep 2, 2009, at 04:08, Ludovic Courtès wrote:
>>> In the Guile case, I'm a tiny bit concerned about some of the
>>> pointer/
>>> int games played (e.g., I'm pretty sure C99 does not guarantee that
>>> you can convert an arbitrary uintptr_t value to pointer and back and
>>> be guaranteed of getting the original value... but I don't know of a
>>> platform that actually violates that assumption), but only a tiny
>>> bit.
>>
>> Really?  I think the whole purpose of `uintptr_t' is to allow that,
>> isn't it?
>
> It's the other way around that's guaranteed to work: void* -> 
> (u)intptr_t -> void*.  So any value originally derived from a valid
> pointer will work, but arbitrary values may not.
[...]

Hmm, I see.  Thanks for the interesting explanation!

Now I understand that I've been lucky enough to live in a beautiful
world with power-of-two pointer types, NULL == 0, etc.  ;-)

Thanks,
Ludo'.

Re: more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2

[Neil Jerram]

ludo@gnu.org (Ludovic Courtès) writes:

>>> Anyway, in the meantime, we can conditionalize static initialization
>>> stuff from bdw-gc-static-alloc on STRICTNESS == 0 and keep everyone
>>> happy.
>>>
>>> Does that sound reasonable?
>>
>> Sure.  Actually, STRICTNESS=1 is the default -- 0 makes SCM an
>> integer, 1 makes it a pointer to a struct, which adds a little more
>> type safety, and 2 makes it a union, which breaks casting,
>> initialization, etc.
>
> Oh, right.

I've never used the non-default STRICTNESS either, and static
initialization sounds like a nice feature; so I'm also happy with
blowing away STRICTNESS 2.

Then, given that you (Ken) think that STRICTNESS 0 doesn't work
either, I'd favour hardcoding the STRICTNESS 1 macros and then
discarding the whole STRICTNESS concept.

     Neil

Re: more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2

[Ken Raeburn]

On Sep 8, 2009, at 19:37, Neil Jerram wrote:
> Then, given that you (Ken) think that STRICTNESS 0 doesn't work
> either, I'd favour hardcoding the STRICTNESS 1 macros and then
> discarding the whole STRICTNESS concept.

That (0 not working) is only a guess, but I'll try it out to see.

I kind of like keeping STRICTNESS 2, because I'm a bit uncomfortable  
with the amount of casting going on in some places, and the degree to  
which it could (theoretically) be masking actual bugs.  But if opinion  
goes against me I'm willing to work on the changes you describe.

Ken

Re: more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2

[Andy Wingo]

On Tue 01 Sep 2009 08:26, Ken Raeburn <raeburn@raeburn.org> writes:

> On Sep 1, 2009, at 02:23, Ken Raeburn wrote:
>> I can clean some of this up trivially -- SCM_PACK/SCM_UNPACK as
>> needed, change == to scm_is_eq.  The initializers make it slightly
>> less trivial, and I can imagine different courses of action.
>
> Okay, not quite so trivial as I blithely asserted.
>
> It looks like the eval code is going to be annoying too

All this will be gone within a month, hopefully. Further details to
come.

I don't see it as such a big problem to play "fast and loose" with
types, honestly... one day we'll have native compilation, and it's all
just words there.

Andy
-- 
http://wingolog.org/

Re: more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2

[Ken Raeburn]

Picking up this thread again...

I've run some basic tests, and it looks like setting  
SCM_DEBUG_TYPING_STRICTNESS to 0 (which causes SCM to be defined as an  
integer type) also fails, though not quite as messily as setting it to  
2.

On Sep 16, 2009, at 15:20, Andy Wingo wrote:
> I don't see it as such a big problem to play "fast and loose" with
> types, honestly... one day we'll have native compilation, and it's all
> just words there.

(Sorry, as a former compiler guy, I find my "portability" buttons  
being pushed here....)

Words with what representation?  Take a look at SCM2PTR and  
PTR2SCM ... for the old Cray systems.  As the comment above the  
definition indicates, the machine has an unusual pointer  
representation.  Still compliant with the C spec, as far as I know;  
just not what you'd expect from most machines.

We've got code using SCM2PTR and PTR2SCM in some places.  We've got  
code simply casting values in other places.  Unless the uses are  
carefully matched up to do the corresponding conversions in both  
directions, we're practically guaranteeing that the code will never be  
portable to the old Cray.  Even without that, I'm skeptical whether a  
Cray port of BDW-GC would be able to process our SCM objects there,  
since apparently our SCM objects are represented rather differently  
from native pointers.

We also cast function pointer types in places.  Pointers are not  
required to all have the same representation, nor to be passed or  
returned in function calls the same way.  There are also ABIs where  
pointers are passed around one way, and integers another way.  Take  
the address of a function with one kind of argument, and call it  
through a pointer to a function type with a different argument, and  
the calling sequence may not match how the function attempts to access  
its arguments.

Among modern general-purpose computers, the behavior's going to be  
pretty consistent -- to some people, "modern general-purpose computer"  
means x86 only, *maybe* one or possibly two other architectures,  
definitely a flat address space and uniform pointer representations  
the size of some standard integer type -- but try porting to older  
systems or some embedded processors, and some of the assumptions start  
to fail.  Do we even have a good idea what the assumptions we're  
making, beyond the basic requirements for a compliant C  
implementation, are?

I know it's tempting to ignore older systems and only worry about  
modern ones, but what of the people who might want to use Guile in  
other packages?  If we limit Guile's portability, we're also forcing  
that limitation on any such other packages.  One of my nagging  
concerns, which I have avoided investigating thus far, is whether  
Guile (and the BDW-GC library) will support all the platforms that  
Emacs does.  Do they support s390, sh3, or vax systems?  How about AIX  
4.2?  All of those are listed in the configure script for Emacs.  If  
someone revives the VMS port of Emacs, will they be able to port Guile  
and libgc (and libunistring and ...)?

The advantage of the STRICTNESS=2 code is that it forces additional  
discipline; simple casts can't paper over all the conversions.  It may  
seem like an annoyance to treat "SCM" and "void *" and "int" as  
requiring explicit conversions, but if someday someone tries porting  
to a platform like the old Cray, C code written with the assumption  
that "it's all just words (and we know what the representations look  
like)" may cause them no end of headaches.  Such an assumption *is*  
valid when we start looking at code generation for specific  
architectures.  But despite any cracks about C being a "high level  
assembly language", it *is* more abstract and such assumptions don't  
hold true for C in the general case.

If all we were discussing was whether the "guile" program should be  
available on older platforms, that would be one thing.  But we're  
talking about the extension library we want to promote for widespread  
use, in GNU programs and presumably elsewhere.  Should we really tell  
people, "you have to choose between portability to these old or  
uncommon platforms, and being able to use this extension library"?   
Especially if they're already supporting old platforms and not yet  
supporting Guile?

In my not-so-humble opinion, the onus should be on us to keep the  
Guile library as portable as possible (and push implementors of the  
libraries that libguile depends on in the same direction), and leave  
it to the application writers to decide what they want to do in terms  
of supporting old or unusual platforms, rather than having us impose  
limitations on them.

</soapbox>

I still don't have any specific proposal to make STRICTNESS!=1 work  
throughout our code, but I do expect it would be somewhat intrusive in  
places.  (For example, some macros that do "interesting" things with  
the values they're passed, I'd probably want to change to inline  
functions, at least when BUILDING_LIBGUILE under gcc, so we can do  
type checking of the supplied values, and then add conversion calls or  
casts or whatever as necessary.  The static initialization macros  
would almost certainly need changes.)  So unless I've swayed some of  
the maintainers, I'm not going to spend much more time on it.

In fact, if the general opinion is "screw the unusual platforms, let's  
hard-code the default STRICTNESS=1 case and get rid of the rest so  
people like Ken stop trying to play with it", I'm also willing to do  
the coding for that, too.  But as I've indicated, I do think it's the  
wrong direction....

Ken

Re: more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2

[Ludovic Courtès]

Hi Ken,

I agree that we should strive to make Guile portable, especially since
we are to stuff it into Emacs.

From time to time, I test it on some “exotic” hardware architectures of
the GCC Compile Farm (MIPS, Alpha, PPC64, etc.), and it’s been working
pretty well so far.  I also got accounts on Tru64, AIX, and now Solaris
and HP-UX, which I’m hoping to put to good use by the time we release 2.0.

That said, I’m not too worried about the Cray pointer thing.  IOW, it’s
OK for me to live with potential Cray breakage until someone with access
to such a machine (how many are there around the world?) can come up
with a bug report or a fix.

Now, if ‘SCM_DEBUG_TYPING_STRICTNESS’ can help us prevent breakage,
that’s nice.  I’ve never used it so far, and never felt the need to use
it, but I’d be glad to follow your lead on this matter.  :-)

Thanks,
Ludo’.

Re: more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2

[Ken Raeburn]

On Nov 18, 2009, at 04:37, Ludovic Courtès wrote:
> From time to time, I test it on some “exotic” hardware architectures  
> of
> the GCC Compile Farm (MIPS, Alpha, PPC64, etc.), and it’s been working
> pretty well so far.  I also got accounts on Tru64, AIX, and now  
> Solaris
> and HP-UX, which I’m hoping to put to good use by the time we  
> release 2.0.

Actually, I wouldn't consider any of those terribly "exotic", unless  
you're using one of the early Alphas that didn't support byte-access  
operations.  But at least we get some tests with strict memory  
alignment requirements, etc.  Windows testing would be kind of  
important, too.  Have access to any embedded systems?  (Of course, if  
they're not POSIX, the thread system would require some more porting  
work... and it might show up areas where we've made other unwarranted  
assumptions.)

Actually, Alpha is also interesting in that the spec permits weak  
memory ordering -- so that one processor could execute "x = 1; y = 2;"  
and even without the compiler playing games, a second processor may  
see y modified before x.  Such a machine can easily support C  
(multiprocessor interactions are outside the spec) and POSIX (mutex  
calls can incorporate memory barriers to force synchronization), but I  
believe libguile assumes strict ordering between threads.  I don't  
know if the actual processor implementations or OSes permit such  
reordering.  Testing Guile on a multiprocessor system using weak  
memory ordering would be interesting; I suspect, though, that it would  
simply not work reliably.

> That said, I’m not too worried about the Cray pointer thing.  IOW,  
> it’s
> OK for me to live with potential Cray breakage until someone with  
> access
> to such a machine (how many are there around the world?) can come up
> with a bug report or a fix.

It would be "better" in some sense if someone could try it out and let  
us know for sure what the situation is -- if any of the machines still  
exist.  I wouldn't try to fix it for the Cray without someone out  
there actively interested in using that version, but I don't want to  
turn a blind eye to problems I'm confident would come up for  people  
in reasonable (if unusual) C environments.  And I'm concerned that the  
fixes would involve things like changing a macro, that currently works  
with SCM or pointer types, into two macros, one for SCM values and one  
for pointers -- that would mean an API change might be required in  
order to finish a port.

> Now, if ‘SCM_DEBUG_TYPING_STRICTNESS’ can help us prevent breakage,
> that’s nice.  I’ve never used it so far, and never felt the need to  
> use
> it, but I’d be glad to follow your lead on this matter.  :-)

That's one... ;-)

Ken

Re: more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2

[Andy Wingo]

Hi :)

On Wed 18 Nov 2009 21:40, Ken Raeburn <raeburn@raeburn.org> writes:
> On Nov 18, 2009, at 04:37, Ludovic Courtès wrote:
>> Now, if ‘SCM_DEBUG_TYPING_STRICTNESS’ can help us prevent breakage,
>> that’s nice.  I’ve never used it so far, and never felt the need to
>> use
>> it, but I’d be glad to follow your lead on this matter.  :-)
>
> That's one... ;-)

I'm happy to have it help out, but "with other people" ;) Perhaps I can
be the one ensuring that it works as it currently does? ;)

Andy
-- 
http://wingolog.org/

Re: more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2

[Ludovic Courtès]

Hi,

Ken Raeburn <raeburn@raeburn.org> writes:

> Actually, I wouldn't consider any of those terribly "exotic", unless
> you're using one of the early Alphas that didn't support byte-access
> operations.

And there’s also SPARC, which doesn’t support unaligned accessed (Linux
reifies them as SIGBUS, as on Alpha IIRC.)

> Windows testing would be kind of important, too.  Have access to any
> embedded systems?

Neil regularly tests on MinGW:
http://autobuild.josefsson.org/guile/#GNU%20Guile-i586-pc-mingw32msvc .

[...]

> Testing Guile on a multiprocessor system using weak
> memory ordering would be interesting; I suspect, though, that it would
> simply not work reliably.

Hmm, I dunno, but there’s already much to be dealt with on multicore
x86(_64) IMO.

[...]

> I wouldn't try to fix it for the Cray without someone out
> there actively interested in using that version, but I don't want to
> turn a blind eye to problems I'm confident would come up for  people
> in reasonable (if unusual) C environments.

Do you have specific platforms in mind?  This Cray/Unicos pointer
representation really seems surreal to me, so I’d be glad to hear of
systems with similar singularities.

Thanks,
Ludo’.