[Top][All Lists]

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

Re: more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2

From: Ken Raeburn
Subject: Re: more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2
Date: Wed, 18 Nov 2009 00:52:03 -0500

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.


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....


reply via email to

[Prev in Thread] Current Thread [Next in Thread]