This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Chill vs. Pascal sets (was: undefined reference to `__setbits')
Andreas Schwab wrote:
> |> #define SET_WORD_SIZE (sizeof (char) * sizeof (SET_WORD))
> |> #define SET_SHORT_SIZE (sizeof (char) * sizeof (SET_SHORT))
> |> #define SET_CHAR_SIZE sizeof (char)
>
> I think this should rather be:
>
> #define SET_WORD_SIZE (CHAR_BIT * sizeof (SET_WORD))
> #define SET_SHORT_SIZE (CHAR_BIT * sizeof (SET_SHORT))
> #define SET_CHAR_SIZE CHAR_BIT
Yes, of course. However these macros are being used in the
Chill run time library that is distributed with gcc-2.95.x.
Does this really work correctly in Chill???
In order to have working sets we now introduced our own
`__setbits()' into the Pascal run time library - which is
more efficient than Chill's one, BTW.
There are yet other problems with the existing Chill
implementation of sets. At the moment, re-implementing Pascal
sets using the existing Chill support in the backend would mean
a serious drawback.
Instead, I am suggesting the following changes to the backend:
* Sets are a sequence of bits. Chill is bundling them
to 8-bit bytes. For efficiency reasons, this should
be generalized to allow for 32/64-bit words instead.
We could introduce a constant `BITS_PER_SET_UNIT' or
similar that could be set to `BITS_PER_UNIT' in Chill
and to `BITS_PER_WORD' in Pascal.
* Chill sets are not aligned; a `set of 4..7' fills the
_lower_ half of a byte. In Pascal, the lower bound is
rounded down to a multiple of `BITS_PER_SET_UNIT', so
`set of 4..7' fills the _upper_ half of a byte.
If we introduce a new constant `SET_ALIGNMENT'
holding zero in Chill and `BITS_PER_WORD' in Pascal,
`get_set_constructor_bits()' (tree.c) can easily handle
both cases.
* What's the issue with `BYTES_BIG_ENDIAN'? Why don't we
consistently use the mask `1 << bitpos' on all machines to
access the `bitpos'th bit in a word?
* In `store_constructor()' (expr.c) there should be a
comment indicating that the `__setbits()' function has to
be supported by the language-specific run time library.
(Since there are different values of `BITS_PER_SET_UNIT'
and `SET_ALIGNMENT', this is indeed language-specific.)
If these problems cannot be solved, there is no point using
`SET_TYPE' nodes for Pascal sets. In that case, we would have
to introduce a `LANG_TYPE' and need a hook in `expand_expr()' to
handle values of that type. I suspect that such a hook exists
already, but I did not find it yet.
Greetings,
Peter
--
http://home.pages.de/~Peter.Gerwinski/ - G-N-U GmbH: http://www.g-n-u.de
Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118
GnuPG key fingerprint: 9E7C 0FC4 8A62 5536 1730 A932 9834 65DB 2143 9422
keys: ftp://ftp.gerwinski.de/pub/keys/ - AntiSpam: http://spam.abuse.net
Anyway, I would prefer to have