This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]