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.