SCOUG-Programming Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Sat, 1 Jan 2005 16:19:33 PST8
From:	Peter Skye <pskye@peterskye.com >
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com
Subject:	SCOUG-Programming: A bit too much to byte

Content Type: text/plain

Lynn H. Maxson wrote:
>
> it's good to have an adrenaline shot.

My pleasure. :-)

> Once again you make as assumption. In a PL/I aggregate,
> either array or structure, you have the option of ALIGNED or
> UNALIGNED of the aggregate as a whole or any subset within
> it. Thus depending on the data type you can either be bit (for
> bit strings) aligned in a sequence or byte (for character
> strings) aligned. With UNALIGNED you can opt for byte
> alignment (except for bit strings which do get padded on the
> right with binary zeros) for all other data types.

It is somewhat difficult to use an unaligned structure containing
interspersed byte-sized values and non-byte-sized bit strings. To wit,

1 MyDifficultStructure UNALIGNED;
2 ABC CHAR(1);
2 BITS3 BIT(3);
2 XYZ CHAR(1);
2 BITS5 BIT(5);

In the above, XYZ is an 8-bit character but is not on a byte boundary.
The entire structure consumes 3 bytes exactly with no wasted bits.

Processing of the XYZ value requires accessing its 8 byte-unaligned
bits, thus some amalgam of "rotate register" instructions are necessary
to make the value useable. The fact that PL/I pads the two BIT()
strings on the right so they are byte-aligned results in a 4-byte, not
3-byte, structure.

If I am sending data from a satellite on a low-bandwidth channel, or if
I am storing a huge quantity of records and want to conserve storage
space, then having a 3-byte rather than 4-byte structure is a valid
requirement.

You complain that PL/I pads the BIT() spaces resulting in 4, not 3,
bytes for the structure. May I suggest a different approach?

MyDifficultStructure CHAR (3);

The ABC value is now SUBSTR(_,1,1) but I know you seek a more compact
solution, so I suggest

PROC GetABC;
PROC SetABC;
PROC GetBITS3;
PROC SetBITS3;
PROC XorBITS3;
etc

and then code appropriately, for example

call SetABC('A'); /* ABC = 'A'; */
call SetBITS3('010'); /* BITS3 = '010'; */
etc

To me, the code is just as readable either way.

> You cannot write in C "a = b = c;", where a, b, and c can be
> bit or character strings or arithmetic variables as well as
> aggregates of such. The corresponding result is "0" for
> "false" and "1" for "true" whether element or aggregate
> variable. If "a" is a bit string, then it's values are 0'b or '1'b;if
> character string, '0' or '1';and if arithmetic, 0 or 1 regardless
> whether b or c have the same or mixed data types.
>
> That's the advantage of strong typing combined with default
> conversion.

It occurs to me that you have a distaste for visible function calls.
The following two expressions should generate the same machine code:

X = a = b = c;
and
X = COMP( COMP(a,b), c );

Frankly, the second one with the visible function calls is more readable
to me. I can see which comparison occurs first. But perhaps I'm being
too linear in wanting the detail.

> "tfResult = EQUAL(A,B);"
>
> Nice try. Of course, tfResult cannot be a bit string in C.
> As a result it can only be a char or int in C.

How about

call SetBit( tfResult, 1, EQUAL(A,B) );

to set the first bit of tfResult equal to the value of "a = b".

> I never said that a programmer explicitly doing conversion in
> an expression was bad, only that in PL/I he had a choice to do
> it or not.

This is valid but I'd like you to extend the thought. As I suggested in
my previous message, the compiler knows what has been parsed and can
display the statement either way. So why not have an option to do so?
Here is succinct and verbose code based on my proposed compiler option:

X = a = b = c;
X = COMP( COMP(a,b), c );

This has nothing to do with data types per se, although the compiler can
keep track of data types while compiling or a Data Control Block (DCB)
can be used at run time.

> A list aggregate, however, does not as its
> sub-lists and elements are connected through "links", i.e.
> addresses, and do not necessarily occupy a contiguous area.

Okay, "linked lists" and "arrays of pointers". Thanks.

In PL/I, I was intrigued by the DCB's because they moved a large amount
of the logic to the run time library. Any given function can look at a
DCB, find out what the parameter "type" is, and call a conversion
routine if necessary.

Are you suggesting that strong typing should allow for run time
determination of data types in a manner similar to DCBs?

> That says when you evaluate an expression involving a list
> aggregate or list aggregates it results in a list aggregate of 0,
> 1, or more values.

> I do not seek the succinctness of an APL expression. Instead
> I seek to match its textbook source. If the textbook (problem
> set) is succinct, I see no reason why the program (solution
> set) should be any less so. If it is clear in one, then
> certainly that transfers to the other.

Within limits, Lynn. There's a heck of a lot of APL which isn't, shall
we say, "clear" to me on first read.

> Now we will have an opportunity over the next couple of
> months with the support of Greg and Sheridan to start to
> compile the "one roof compendium" you mention. This means
> that we not only look at the code, but also try to capture
> how they formed their thinking in setting up to write it.

Sounds like two compendiums to me. One for language, and one for
algorithms.

> I have a focus on productivity. That says I have an absolute
> abhorrence of programming methodology that requires not
> only multiple different written forms, multiple different
> languages within a given form, and multiple tools depending
> on form, but also one which allows incompatibilities to occur.
> I assert that you can with a single tool, a single language, a
> single form replace and avoid all that.

I look forward to future developments on your assertion. Perhaps the
Programming SIG can be a focus group for some early and tricky syntax,
such as "should this loop be executed at least once" (DO UNTIL versus DO
WHILE, in other words should the loop test be placed at the beginning or
end of the loop)?

- Peter

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 01 | January | 2005 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.