Re: And the question was? (Re: Amazing, two new articles on Computerworld.com

In article <f6114h$5qa$1@xxxxxxxxxxxxxxxxxxx>, John Reagan <john.reagan@xxxxxx> writes:
Bill Gunshannon wrote:

proprietary extension. The original point was that the PLI/I language
took alignment into consideration and included alignment instructions
as a part of the language which means it is reasonable to expect a
program using it to be somewhat portable. C and Pascal do not share
this feature. Any concern for alignment is little more than an after-
thought.


Well, so does COBOL (see the SYNCRONIZED clause).

As a member of a standards committee, it is hard for a language to
predict behavior & performance of future hardware. COBOL and PL/I
provide some sort of "using my crystal ball, I think I need some
alignment help right here". What if my crystal ball is broken and I
actually needed alignment help somewhere else?

Allowing/requiring the human to "help" the compiler produce code on some
current hardware (much less future hardware) seems silly to me. Kinda
like the "register" declaration in C. Not really part of any language
design, but just a crutch for a brain-dead compiler.

Computer languages allow you to represent some algorithm to the
underlying hardware. How does alignment help you do that?

The mindset of the Pascal committee (the only one I can speak for
personally) is that alignment (or any physical implementation detail)
doesn't add to the ability to describe more algorithmic detail. We left
things vague for things like interpreters, p-code, ASCII or EBCID, etc.
to all live within the standard.

Maybe I'm missing the point.

If all we're worrying about is a performance hint for ephemeral
storage layout within a single compilation unit then I certainly agree
that embedding a hint mechanism into the standard is silly.

But if we're worrying about the ability to specify field layout
for purposes of cross-language programming or for data storage on
a file or data transport across the network then the ability of
the programmer to apply some sort of "representation specification"
is surely important. Encoding the relevant syntax and semantics
into the standard is surely a reasonable way to ensure both
portability and interoperability.

I may even want to know that the record data I pass in main line
code compiled with version 3.1 will be properly understood in
a subroutine compiled under version 3.2. [On the other hand,
I'd rather expect my vendor to keep things consistent enough
that I don't have to overspecify things just to get alignment behavior
that is consistent between minor releases of the same compiler]

.

Relevant Pages