[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.
</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,
Ken Raeburn <=