Set Constants in Hex 
Author Message
 Set Constants in Hex

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



Thu, 07 Mar 1996 07:25:01 GMT  
 Set Constants in Hex
Here is an amendement to my proposal for hex constants
for type SET.

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



Thu, 07 Mar 1996 23:58:13 GMT  
 Set Constants in Hex

Quote:

>Here is an amendement to my proposal for hex constants
>for type SET.

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

Yes.  While an interesting idea, this is definitely non-portable.  You are
imposing some bit ordering on SET when you make this proposal.  By your
own admission, this is most useful when dealing with specific hardware --
non-portable in itself.

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.



Fri, 08 Mar 1996 06:49:47 GMT  
 Set Constants in Hex
: >Here is an amendement to my proposal for hex constants
: >for type SET.

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



Fri, 08 Mar 1996 09:50:43 GMT  
 Set Constants in Hex

Quote:



>: >Here is an amendement to my proposal for hex constants
>: >for type SET.

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

>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

Yes, for example: the compiler implementor is not required to make a HEX 1
correspond to SET { 0 }.  MIN(SET) is 0 and MAX(SET) is implementation
defined, and other than that, an implementor is free to create them in any
fashion seen fit.  If an implementation choose to use bit 31 as { 0 }, then
so be it.  You, the programmer using the compiler, would have to know
about the compiler's SET habits when doing hardware support,
regardless if you use your notation or the conventional { } notation.

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.

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

One man's trash is another man's treasure.  (Admittedly not the best pithy
statement I could probably use, but it will suffice).  There is a logic
behind the tedium here -- it strongly shouts to the reader "SYSTEM DEPENDENT".
As I stated before, your proposal does not show non-portable code in as
good a fashion.

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

This is also non-portable.  A SET is not a representation of hardware.
SYSTEM.BIT allows you to check a specific bit in a memory location.  x IN
set allows you to see if a specific integer is in a SET.  These are not
the same operations.

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?

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

In summation, bitsets, as they appear in hardware manuals, are
specifically non-portable and do not naturally correspond to the Oberon
datatype SET.  No amount of syntactic sugar will make them a portable
feature, so I feel you should resign yourself to writing a
SYSTEM-dependent module.

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



Fri, 08 Mar 1996 19:36:47 GMT  
 Set Constants in Hex



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

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}

Marc

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



Fri, 08 Mar 1996 19:46:07 GMT  
 Set Constants in Hex


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

: 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



Fri, 08 Mar 1996 22:15:15 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Hex to Bin, Bin to Hex, Hex to Dec, Dec to Hex

2. bug in hex constant definition?

3. VB hex constant conversion

4. Pow! and type of hex constants

5. Hex constants and bitmasks

6. 32 bit Hex constants for integers

7. convert hex #'s and letters to one string constant

8. Hex constants in ELF90

9. Setting a web hex color as background color for a canvas

10. hex code of instructions in X86 set (searching for)

11. How to set string to NULL (Hex value 00)

12. Two SET constants I don't know

 

 
Powered by phpBB® Forum Software