Hardware manuals are often written using hex notation.
rather than bit position.  Doing these translations by
hand is tedious and error prone. It would be convienent
to specify set constants in Hex.

ReadyBits = { 0,2,4 }; (* constant of type SET *)
ReadyBits = SYSTEM.VAL(SET,0DH); (* ?, too verbose *)
ReadyBits = 0DS; (* wishful thinking ? *)

Similarly it would be convienent to have a standard
procedure for converting numeric constants to bit position.

PROCEDURE WaitUntilClear;
CONST
        memIO = 100;
        ReadyBit1 = 080X;
        ReadBit2 = 04X;
BEGIN
        WHILE ~ SYSTEM.BIT( memIO, BITPOS(ReadyBit1) DO END;
        WHILE ~ SYSTEM.BIT( memIO, BITPOS(ReadyBit2) DO END;
END WaitUntilClear;

On machines that use ports for IO, eg. PC's
        memIO := ReadPort( 100 );
        SYSTEM.BIT( SYSTEM.ADR( memIO ), BITPOS( ReadBit1 ));

Whitney

hexNum = digit { hexDigit }
character = hexNum "X"
integer = hexNum "H"
integer = hexNum "B"
set = hexNum "S"

Hex constants ending in "B" would specify the bit/set position
of the so-called "on" bit.
Eg.
        01B = 0
        02B = 1
        04B = 2
        07B    error; does not specify a unique bit
        08B = 3
        010B = 4

        08B IN 0DS = TRUE
        SYSTEM.BIT( 0F000H, 010B ) (* bit 4 on at mem[0F000H] *)

The motivation of this proposal is improve on the agreement of
source code with hardware specifications. The later which
are often written in terms of hex notation rather than
or in addition to bit position notation.

Any questions or comments ?

Whitney

So, with this in mind, and since SYSTEM is probably imported already, why
do just do the following:

    IF x IN SYSTEM.VAL(SET, 0DH) THEN (* Sept 21 *) END;

As for SYSTEM.BIT, it is not defined to take a set, but instead a bit
number.  So, you already have to know which bit you want to test.  Making
it into a set does not really help that much.

It is perhaps nice in some situations, but is it necessary?

Taylor "~(non compos mentis)" Hutt
Sept 21: Visit your local record store.

: >integer = hexNum "B"
: >set = hexNum "S"
: >Hex constants ending in "B" would specify the bit/set position
: >of the so-called "on" bit.

: Yes.  While an interesting idea, this is definitely non-portable.  You are
: imposing some bit ordering on SET when you make this proposal.

Have I ? I would expect the bits of a set to map to hex but
I don't think that implies any bit ordering.

Take the case where a bit pattern 0001 is used on
a microchannel card. This card could go into an Intel on
RS6000 based machine. The bit patterns of these machines
are different  - one treats it as the most significant
bit the other as the least significant bit.

Conversely thr same set would yield different bit patterns
on these machines.
1000 binary = { 0 } = 01S = 01X = 01H = 1    OR
0001 binary = { 0 } = 01S = 01X = 01H = 1

Clearly seperate code will have to be used on the RS6000
and on the Intel machines to cover for the differences
between those machines even though the card itself uses
only one bit pattern.

: So, with this in mind, and since SYSTEM is probably imported already, why
: do just do the following:
:     IF x IN SYSTEM.VAL(SET, 0DH) THEN (* Sept 21 *) END;

too tedious.

CONST
        ReadyBits = 0DS;

        IF x IN ReadyBits THEN
        END;
OR
        REPEAT
                val := SYSTEM.VAL(SET, ReadPort( 100H ));
        UNTIL ReadyBits * SYSTEM.VAL( SET, val ) = 0;

: As for SYSTEM.BIT, it is not defined to take a set, but instead a bit
: number.  So, you already have to know which bit you want to test.  Making
: it into a set does not really help that much.

That is why I defined hexNum "B". It would be number of the
so-called "on"  position of the set. This the number used by
SYSTEM.BIT and on the left hand side of the IN expression.

: It is perhaps nice in some situations, but is it necessary?

No it is not necessary, it is redundant in the sense that so
is REPEAT, IF, etc given WHILE. In contrast to
REPEAT, IF, etc SET is rarely used. Adding more
properties to SET thus seems a bit odd. On the otherhand
Oberon doesn't have a direct way of expressing
bitsets as they often appear in the literature which
is more often than not ( for better or worse ) in
hex notation. I think using hex for sets is a
convience similar to using ASCII for communication.

Whitney

If it looks non-portable, and it smells non-portable, then it must be
non-portable.  The problem with this proposal is that it allows you to
intermix non-portable code with portable code in a manner that does not
make it stand out.  Since you admit that different code must be written
for different machines, it should be isolated into some non-portable module.
It would seem that a failure to do this would enable the programmer to do
Bad Things without being conciously aware of that fact, as is required by
the SYSTEM module.

The need for this is really not clear to me.  The hardware is less likely
to suffer revision-itis than is the software, so what is the problem of
manually calculating the bit positions and set values once at the
beginning of the development of the non-portable module?

Taylor "I don't eat beets" Hutt
You are less likely to be shot while dining at Burger King than McDonald's.

        SYSTEM.VAL(SET, 1) = {0}

assuming you are on a 32-bit machine. On a big endian machine, on the other
hand, bit 0 is the most significant bit, and the equivalence would be:

        SYSTEM.VAL(SET, 1) = {31}

Marc

Marc-Michael Brandis
Institute for Computer Systems
ETH-Zentrum (Swiss Federal Institute of Technology)
CH-8092 Zurich, Switzerland

: The problem with this is that there is no standard bit ordering, or no
: standard correspondence between variables of type SET and variables of type
: LONGINT. The above assignments to ReadyBits would be equivalent on little-
: endian machines, but not so on big-endian machines (IBM RS/6000 and
: HP PA-RISC). Stated otherwise, on a little endian machine, bit 0 is the least
: significant bit, and therefore the following would hold:

:       SYSTEM.VAL(SET, 1) = {0}

: assuming you are on a 32-bit machine. On a big endian machine, on the other
: hand, bit 0 is the most significant bit, and the equivalence would be:

:       SYSTEM.VAL(SET, 1) = {31}

Thanks for straightening that out. From this example and others it is
clear that
        SYSTEM.VAL( SET, n ) # LONGINT

If I have it correct now then :

{ 1000.. binary = { 31 } = 80000000S } # { 01X = 01H = 1 }   little endian
{ ..0001 binary = { 0 } = 01S   } = { 01X = 01H = 1 }   big endian

Does this detract from using hex constants for SETs ?
I guess that for general use the answer is yes, but hardware
stuff no. I think it would be exceptable to prevent hexNum "S"
from being used unless SYSTEM was imported.

Whitney