f



Evolution of PL/I

Robin recently suggested that my early experience with PL/I was
out-of-date.   Since my PL/I programming was over twenty years
ago, I freely admit that this is probably the case.

So, my question is not intended to start a flame war, but to update
my knowledge about the language.   My motive for this is, in part
because I teach a comparative programming language course at
a nearby university.  It would be appropriate for me to avoid misleading
my students.

Much of my course deals with contemporary languages such as C++,
C#, Java, Eiffel, Ada (Ada 95),  functional languages (Lisp, Haskell,
Scheme, ML), and logic languages (e.g., Prolog).     I do include a
few lectures that include Fortran and COBOL, especially since those
languages have continued to evolve.

So, in the interest of having my facts right when I next teach this class,
I have a few questions about PL/I.    I hope no one will be offended by
my asking these directly in this forum.   Also, if you can include a code
fragment and a reference to the current PL/I standard in your reply, that
would be helpful.

1)  PL/I support for abstract data types

2)  PL/I support for full inheritance; extensible, encapsulated data types or
classes

3)  PL/I support for dynamic binding as used with polymorphic types

4)  PL/I support for polymorphism

5)  PL/I support for "design by contract" (a la Eiffel)

6)  PL/I support for functions as first class objects, or pointers to
                 functions, or some other easy way to pass functions as
arguments

7)  Garbage collection/storage reclamation for pointers


There are a lot more questions on my list buy my wife has been bugging me for
the
last five minutes to take her to lunch on this fine Monterey sunny Saturday.
This
list will have to suffice for now.

Thanks in advance to everyone.  Thanks to Robin for encouraging me to learn more
so I bring my knowledge up-to-date.

Richard Riehle


0
adaworks2 (748)
12/3/2005 7:26:43 PM
comp.lang.pl1 1741 articles. 0 followers. Post Follow

173 Replies
1180 Views

Similar Articles

[PageSpeed] 12

<adaworks@sbcglobal.net> wrote in message
news:Tjmkf.31584$tV6.20927@newssvr27.news.prodigy.net...
>Much of my course deals with contemporary languages such as C++,
>C#, Java, Eiffel, Ada (Ada 95),  functional languages (Lisp, Haskell,
>Scheme, ML), and logic languages (e.g., Prolog).     I do include a
>few lectures that include Fortran and COBOL, especially since those
>languages have continued to evolve.

As has PL/I.
    Though, of course, PL/I has not been in need
of "evolv"ing to the extent of, say, Fortran, as when PL/I
was designed/released, it already had many of the features
of Fortran (that have only been added to Fortran in recent years -from 1991-
such as (but not limited to) dynamic arrays and recursion.

> So, in the interest of having my facts right when I next teach this class,
> I have a few questions about PL/I.    I hope no one will be offended by
> my asking these directly in this forum.   Also, if you can include a code
> fragment and a reference to the current PL/I standard in your reply, that
> would be helpful.

A more appropriate question might be to enquire what
features are available in PL/I, or to peruse a language
reference manual.

    Some of the newer features of PL/I include enumerated types,
strong typing (heplful for the construction and
maintenance of linked lists, etc.) and a date data type
to facilitate the automatic handling of dates in both four-digit and
two-digit years.

    The builtins available have been extensively expanded,
and include an XML parser, sort [longstanding], WIDECHAR strings,
date and time, random number generator, floating-point enquiry
functions, more string-handling functions, and the like.

    Interfacing with other languages has been extended,
with - for example - specific support for C strings.

> Richard Riehle




0
robin_v (2737)
12/8/2005 12:01:02 PM
<adaworks@sbcglobal.net> wrote in message
news:Tjmkf.31584$tV6.20927@newssvr27.news.prodigy.net...
> 6)  PL/I support for functions as first class objects, or pointers to
>                  functions, or some other easy way to pass functions as
> arguments

PL/I has always been able to pass functions as arguments:

   call sub (a, F);

sub: proc (b, G);
    ...
    b = G(b);
end sub;

F: proc (p) returns (float);
   ...
end F;

As well as that, there are ENTRY variables that can be used
for much the same thing.


0
robin_v (2737)
12/11/2005 8:18:00 AM
<adaworks@sbcglobal.net> wrote in message
news:Tjmkf.31584$tV6.20927@newssvr27.news.prodigy.net...

> 1)  PL/I support for abstract data types

ADTs are provided by PL/I.
Refer to DEFINE ALIAS and DEFINE STRUCTURE statements,
and TYPE constructs.

dcl a type b;

b can be defined as having specific attributes,
and as a structure name (as introduced by a DEFINE STRUCTURE
statement).

Look under those keywords/statements in the IBM VA PL/I
for Windows Language Reference.


0
robin_v (2737)
12/12/2005 1:23:28 AM
Thanks Robin,

Do the ADT's include a capability for encapsulation?

Are the fully extensible (e.g., what some people call inheritance)?

Can you give an example of an extensible ADT.  Let me give you an
example, using a pseudo-language:

      class machine
         {
           public
               Turn_On();
               Turn_Off();
               Is_On() : return Boolean;
          private:
              Machine_On : Boolean := False;
         } end Machine;

where the implementation code is in a separate compilation unit.

In the above example, we could have (should have) made the machine
class (type) explicitly abstract so no objects could be created from it.
Then, we would have derived various kinds of specialized machines from
it, some of which might also be abstract.

Thanks,

Richard Riehle

==============================================================
"robin" <robin_v@bigpond.com> wrote in message
news:ki4nf.17743$ea6.3920@news-server.bigpond.net.au...
>
> <adaworks@sbcglobal.net> wrote in message
> news:Tjmkf.31584$tV6.20927@newssvr27.news.prodigy.net...
>
> > 1)  PL/I support for abstract data types
>
> ADTs are provided by PL/I.
> Refer to DEFINE ALIAS and DEFINE STRUCTURE statements,
> and TYPE constructs.
>
> dcl a type b;
>
> b can be defined as having specific attributes,
> and as a structure name (as introduced by a DEFINE STRUCTURE
> statement).
>
> Look under those keywords/statements in the IBM VA PL/I
> for Windows Language Reference.
>
>
>


0
adaworks2 (748)
12/18/2005 6:38:17 PM
I am going to assume that, because no one was able to post a PL/I
program that mapped to the class definition (below) that I posted in
December, that PL/I does not support the object-oriented class
model.

I will also assume that PL/I does not support extensible inheritance
since no one posted an example.

I am teaching a class in comparative programming languages this Quarter,
and, though I would have preferred to have been able to say a few things
about how PL/I has evolved with the times, it seems that it has not.  At this
point, I can only tell my students that PL/I is an old-fashioned language
that has not kept up with the new ideas that have emerged since its
original design and cannot be taken seriously for modern software
engineering.

Even COBOL has evolved to include object technology.  Even Fortran
has evolved in this way.   Other languages have also evolved to include
support for an object model.   Unfortunately, PL/I seems to remain
static -- unless someone can demonstrate that it has actually evolved
to support objects.

Thanks,

Richard Riehle

===================================================
<adaworks@sbcglobal.net> wrote in message 
news:t0ipf.42953$Zv5.15609@newssvr25.news.prodigy.net...
> Thanks Robin,
>
> Do the ADT's include a capability for encapsulation?
>
> Are the fully extensible (e.g., what some people call inheritance)?
>
> Can you give an example of an extensible ADT.  Let me give you an
> example, using a pseudo-language:
>
>      class machine
>         {
>           public
>               Turn_On();
>               Turn_Off();
>               Is_On() : return Boolean;
>          private:
>              Machine_On : Boolean := False;
>         } end Machine;
>
> where the implementation code is in a separate compilation unit.
>
> In the above example, we could have (should have) made the machine
> class (type) explicitly abstract so no objects could be created from it.
> Then, we would have derived various kinds of specialized machines from
> it, some of which might also be abstract.
>
> Thanks,
>
> Richard Riehle
>
> ==============================================================
> "robin" <robin_v@bigpond.com> wrote in message
> news:ki4nf.17743$ea6.3920@news-server.bigpond.net.au...
>>
>> <adaworks@sbcglobal.net> wrote in message
>> news:Tjmkf.31584$tV6.20927@newssvr27.news.prodigy.net...
>>
>> > 1)  PL/I support for abstract data types
>>
>> ADTs are provided by PL/I.
>> Refer to DEFINE ALIAS and DEFINE STRUCTURE statements,
>> and TYPE constructs.
>>
>> dcl a type b;
>>
>> b can be defined as having specific attributes,
>> and as a structure name (as introduced by a DEFINE STRUCTURE
>> statement).
>>
>> Look under those keywords/statements in the IBM VA PL/I
>> for Windows Language Reference.
>>
>>
>>
>
>
> 


0
adaworks2 (748)
4/12/2006 5:38:02 AM
Challenge type questions get ignored here. Your assumptions are therefore 
unwarranted. If you want to teach PL/I, you'll have to learn it yourself.

<adaworks@sbcglobal.net> wrote in message 
news:_m0%f.15192$tN3.11707@newssvr27.news.prodigy.net...
>I am going to assume that, because no one was able to post a PL/I
> program that mapped to the class definition (below) that I posted in
> December, that PL/I does not support the object-oriented class
> model.
>
> I will also assume that PL/I does not support extensible inheritance
> since no one posted an example.
>
> I am teaching a class in comparative programming languages this Quarter,
> and, though I would have preferred to have been able to say a few things
> about how PL/I has evolved with the times, it seems that it has not.  At 
> this
> point, I can only tell my students that PL/I is an old-fashioned language
> that has not kept up with the new ideas that have emerged since its
> original design and cannot be taken seriously for modern software
> engineering.
>
> Even COBOL has evolved to include object technology.  Even Fortran
> has evolved in this way.   Other languages have also evolved to include
> support for an object model.   Unfortunately, PL/I seems to remain
> static -- unless someone can demonstrate that it has actually evolved
> to support objects.
>
> Thanks,
>
> Richard Riehle
>
> ===================================================
> <adaworks@sbcglobal.net> wrote in message 
> news:t0ipf.42953$Zv5.15609@newssvr25.news.prodigy.net...
>> Thanks Robin,
>>
>> Do the ADT's include a capability for encapsulation?
>>
>> Are the fully extensible (e.g., what some people call inheritance)?
>>
>> Can you give an example of an extensible ADT.  Let me give you an
>> example, using a pseudo-language:
>>
>>      class machine
>>         {
>>           public
>>               Turn_On();
>>               Turn_Off();
>>               Is_On() : return Boolean;
>>          private:
>>              Machine_On : Boolean := False;
>>         } end Machine;
>>
>> where the implementation code is in a separate compilation unit.
>>
>> In the above example, we could have (should have) made the machine
>> class (type) explicitly abstract so no objects could be created from it.
>> Then, we would have derived various kinds of specialized machines from
>> it, some of which might also be abstract.
>>
>> Thanks,
>>
>> Richard Riehle
>>
>> ==============================================================
>> "robin" <robin_v@bigpond.com> wrote in message
>> news:ki4nf.17743$ea6.3920@news-server.bigpond.net.au...
>>>
>>> <adaworks@sbcglobal.net> wrote in message
>>> news:Tjmkf.31584$tV6.20927@newssvr27.news.prodigy.net...
>>>
>>> > 1)  PL/I support for abstract data types
>>>
>>> ADTs are provided by PL/I.
>>> Refer to DEFINE ALIAS and DEFINE STRUCTURE statements,
>>> and TYPE constructs.
>>>
>>> dcl a type b;
>>>
>>> b can be defined as having specific attributes,
>>> and as a structure name (as introduced by a DEFINE STRUCTURE
>>> statement).
>>>
>>> Look under those keywords/statements in the IBM VA PL/I
>>> for Windows Language Reference.
>>>
>>>
>>>
>>
>>
>>
>
> 


0
4/12/2006 2:21:52 PM
adaworks@sbcglobal.net wrote:
> I am going to assume that, because no one was able to post a PL/I
> program that mapped to the class definition (below) that I posted in
> December, that PL/I does not support the object-oriented class
> model.
> 
> I will also assume that PL/I does not support extensible inheritance
> since no one posted an example.
> 
> I am teaching a class in comparative programming languages this Quarter,
> and, though I would have preferred to have been able to say a few things
> about how PL/I has evolved with the times, it seems that it has not.  At this
> point, I can only tell my students that PL/I is an old-fashioned language
> that has not kept up with the new ideas that have emerged since its
> original design and cannot be taken seriously for modern software
> engineering.
> 
> Even COBOL has evolved to include object technology.  Even Fortran
> has evolved in this way.   Other languages have also evolved to include
> support for an object model.   Unfortunately, PL/I seems to remain
> static -- unless someone can demonstrate that it has actually evolved
> to support objects.
> 
> Thanks,
> 
> Richard Riehle
> 
<-- CUT EARLIER POSTS -->

For a teacher to adopt this kind of attitude is deplorable -- they have 
a responsibility to speak authoritatively only on subjects that you have 
mastered. Absence of information does not justify favoring one side of 
an argument.

Some of your students are likely to be better informed as to the 
specific issue; they may note the speciousness of your argument. Please 
reconsider your threat.

N. Shamsundar
University of Houston
0
4/12/2006 3:09:04 PM
<adaworks@sbcglobal.net> wrote in message
news:_m0%f.15192$tN3.11707@newssvr27.news.prodigy.net...
> I am going to assume that, because no one was able to post a PL/I
> program that mapped to the class definition (below) that I posted in
> December, that PL/I does not support the object-oriented class
> model.
>
> I will also assume that PL/I does not support extensible inheritance
> since no one posted an example.
>
> I am teaching a class in comparative programming languages this Quarter,
> and, though I would have preferred to have been able to say a few things
> about how PL/I has evolved with the times, it seems that it has not.  At this
> point, I can only tell my students that PL/I is an old-fashioned language
> that has not kept up with the new ideas that have emerged since its
> original design and cannot be taken seriously for modern software
> engineering.

In order to teach something, you first have to learn something
about the topic.

    Have you demonstrated that quality?  It appears not.

    To sit there and make glib statements such as
"it seems that it has not" [changed with the times],
is ample demonstration, if any further were needed.

    We have pointed you to some excellent sources.
Yet you expect somebody else to do your work for you.



0
robin_v (2737)
4/14/2006 11:18:46 AM
"Mark Yudkin" <myudkinATcompuserveDOTcom@boingboing.org> wrote in message 
news:443d0ce4$0$13565$5402220f@news.sunrise.ch...
> Challenge type questions get ignored here. Your assumptions are therefore 
> unwarranted. If you want to teach PL/I, you'll have to learn it yourself.
>
I am not teaching PL/I.   Rather, I am teaching a class in comparative
programming languages.   The focus of the course is on those languages
that include a modern approach to software development.   I don't
want my students to waste their time in the pursuit of a language that
seems to provide little hope of being useful.

Once upon a time I did write PL/I programs.   I know about some of
the good and bad points of the early language design from my direct
experience.

Richard Riehle 


0
adaworks2 (748)
4/14/2006 11:35:20 PM
"N. Shamsundar" <shamsundar_at_@uh.edu> wrote in message 
news:e1j56f$dubr$1@masala.cc.uh.edu...
>
> For a teacher to adopt this kind of attitude is deplorable -- they have a 
> responsibility to speak authoritatively only on subjects that you have 
> mastered. Absence of information does not justify favoring one side of an 
> argument.
>
Absence of information, especially when that absence supports the
opinion expressed, is a reasonable basis for expressing one's view.

I am not anti-PL/I.   Rather, I am simply asking about the status of
its evolution.    Has it evolved to support modern software paradigms?

All indications are that it has not.   I would like to know that the current
operational version of PL/I has evolved.

I offered an example of some pseudo-code in object-oriented programming
and asked how PL/I might approach that same problem.   It is a simple
request.  Does PL/I support object-oriented programming?   Apparently
not given that every answer to that question generates, not an example of
PL/I OOP code, but a tirade of defensive attacks on me personally.

> Some of your students are likely to be better informed as to the specific 
> issue; they may note the speciousness of your argument. Please reconsider your 
> threat.
>
There is almost nothing positive in the literature of comparative programming
languages written about contemporary PL/I.    Most books on the subject
do not even mention it anymore.  Earlier books did at least mention it.  Now
it is treated as a historical oddity that introduced some concepts, including
a badly designed model for exception handling.  This opinion may not correspond
with the viewpoint of those who still love and use PL/I -- it may even be 
unfair --
but students are discouraged from even considering it given the slant of the
current literature.

In my classroom, I try to give a positive picture of other older languages such
as COBOL and Fortran, both of which have evolved in significant ways.  In
particular, Fortran has evolved very nicely.

I more interested in information than in bombast.

OOP

Does PL/I support an object-oriented model that includes,

               -- extensible inheritance  (single, multiple
               -- dynamic binding
               -- polymorphism
               -- parameterized types
                       (e.g. like C++ templates, Eiffel generics, Java generics, 
or Ada generics)
               -- delegation

Is there a concept of "class?"   Or, more generally, a concept of extensible 
type classification.

Extensible inheritance involves being able to derived a new type from an 
existing type without
disturbing the stability of the existing type.   We can add new attributes as 
well as new methods.
I would love to see a simple example of how that is done in PL/I.

REGULAR EXPRESSIONS

Does PL/I include direct support (or a library for support of) regular 
expressions?   This is
a capability of growing importance in the world of Internet programming.

I suppose we could also ask about PL/I support for sockets, interaction with 
HTML, XML,
and other Internet features, but I would be suprised it being used for this kind 
of thing.  Might
I say, I would be pleasantly surprised to see it being used for such things.

There is not doubt that PL/I, in a earlier time, was effective for a lot of 
programming tasks.  It
had good numerical computational capabilities as well as good support for the 
IBM operating
systems (which I used to use a lot).

There remains the outstanding question of its support for contemporary 
computing.  Is there a
PL/I capability in the Microsoft .NET CLR facility?    I don't see it listed. 
Perhaps it is hidden
the way Ada is hidden.   In the case of Ada, the name of the .NET language is A# 
instead of
Ada.  Perhaps PL/I is present, but with a different name.

To be fair, every language has its purpose and its best environment.   I tell my 
students to pick the
right tool for the right job.  I don't want to them to pick C++ or Java when 
Python will be a better
choice.   Sometimes Java is a better choice than C++.    Sometimes, not always, 
Ada is a better
choice.   In other cases, contemporary COBOL or modern Fortran is a better 
option.   When
would I be better served by PL/I than modern Fortran?    Keep in mind that 
modern Fortran
has evolved far beyond the Fortran you might remember from the mid-1970's.

I would be happy to say some positive things about contemporary PL/I.   But, so 
far, it does
not seem that the language has evolved much past its original design.

Rather than berate me for this view, simply provide some examples that establish 
that the
contrary is true.    And, when I question those examples, engage me, not in a 
personal
attack, but in a well-formed set of examples that clarify your points.

Richard Riehle


0
adaworks2 (748)
4/15/2006 12:11:47 AM
"robin" <robin_v@bigpond.com> wrote in message 
news:qyL%f.6303$vy1.2514@news-server.bigpond.net.au...
>
> In order to teach something, you first have to learn something
> about the topic.
>
That was the purpose of my inquiry.
>
>    Have you demonstrated that quality?  It appears not.
>
Perhaps I can make some progress, at last.
>
>    To sit there and make glib statements such as
> "it seems that it has not" [changed with the times],
> is ample demonstration, if any further were needed.
>
To all appearances, it has not evolved much.   I hope to
shown that I am wrong.
>
>    We have pointed you to some excellent sources.
> Yet you expect somebody else to do your work for you.
>
Actually, the FAQ you suggested I read did not provide much
information about the questions I have asked.   Perhaps it would
be useful to someday update FAQ to deal with, in particular, the
issues of object-oriented programming.

Let me be clear that I am not persuaded that OOP is the final
answer to good programming.   There are some programs that
do not benefit much from OOP.  One reason I like Python is its
flexibility in available programming styles.   It supports OOP, when
I need it, scripting when that is all I need to do, Internet programming
when that is the task at hand, database, computation, highly portable
GUI programming, and many more facilities.   However, Python
is not a good for numerical work as other languages, including
PL/I.

A language that creates bytecode, for the JVM, is useful when the
code needs to travel around (e.g., agents) from one OS to another.
That means Java, Python, Smalltalk, or some other language that
generates JVM bytecode is sometimes appropriate.   My guess is,
though I might be wrong, that PL/I does not generate code for the
JVM.  Is that bad?   No.  It simply highlights one of the differences
in the targeted domain for PL/I programs.

You have consistently replied to me as if I were the enemy.  On the
contrary, I will be delighted to be a friend of PL/I.   However, I do
prefer to have my questions answered directly and factually.   If I
can walk into my classroom on Monday morning and announce that,
"I was in error.   PL/I really does support modern programming
paradigms such as OOP,"  you can be sure I will do so.

FAQ means "frequently asked questions."  Perhaps my inquiries are
not in the category of "frequently," but I am asking them.  In the
case of most other professors of computer science, they simply
write off PL/I as a historical language of little contemporary interest.
They don't bother to ask.  If you wish to deprecate the question,
so be it.   However, that attitude will not encourage others with
questions to ask them.  If I can refer students to a FAQ that is
actually informative, I will do so.

Richard Riehle 


0
adaworks2 (748)
4/15/2006 12:26:37 AM
<adaworks@sbcglobal.net> wrote in message
news:7TW%f.1923$Lm5.839@newssvr12.news.prodigy.com...
>
> "N. Shamsundar" <shamsundar_at_@uh.edu> wrote in message
> news:e1j56f$dubr$1@masala.cc.uh.edu...
> >
> > For a teacher to adopt this kind of attitude is deplorable -- they have a
> > responsibility to speak authoritatively only on subjects that you have
> > mastered. Absence of information does not justify favoring one side of an
> > argument.
> >
> Absence of information, especially when that absence supports the
> opinion expressed, is a reasonable basis for expressing one's view.

It's not a reasonable basis for classroom presentation.


0
robin_v (2737)
4/15/2006 3:13:12 PM
<adaworks@sbcglobal.net> wrote in message
news:7TW%f.1923$Lm5.839@newssvr12.news.prodigy.com...
> I suppose we could also ask about PL/I support for sockets, interaction with
> HTML, XML,
> and other Internet features, but I would be suprised it being used for this
kind
> of thing.

We have referred you to good sources.
You keep coming up with the same old questions,
indicating that you have not followed them.

Had you done so, you would have found the wealth of features
that PL/I contains, including a high speed XML parser.

>  In other cases, contemporary COBOL or modern Fortran is a better
> option.   When
> would I be better served by PL/I than modern Fortran?    Keep in mind that
> modern Fortran
> has evolved far beyond the Fortran you might remember from the mid-1970's.

Everyone in this forum is well aware of the developments in Fortran.
(BTW, many of the "new" features of Fortran since the
mid-1970s have been in PL/I since 1966.)

> I would be happy to say some positive things about contemporary PL/I.   But,
so
> far, it does
> not seem that the language has evolved much past its original design.

You keep parroting this, but can you explain why you remain
wholly ignorant of any new features of PL/I?


0
robin_v (2737)
4/15/2006 3:13:12 PM
"robin" <robin_v@bigpond.com> wrote in message 
news:c480g.7153$vy1.3116@news-server.bigpond.net.au...
>
> We have referred you to good sources.
> You keep coming up with the same old questions,
> indicating that you have not followed them.
>
> Had you done so, you would have found the wealth of features
> that PL/I contains, including a high speed XML parser.
>
OK.  What about the object-oriented programming capabilities?


You did not give me a resource that demonstrates the capabilities
for OOP in PL/I.    If you did, I must have missed it.

I am not the enemy.   If I am asking for information and do not
find that the answers are satisfactory, I will ask again until I
discover the facts.

So, until I am sure that PL/I has support for OOP, I will continue
to assume it does not.   Instead of a direct answer, I get criticized
for asking the question.

As I noted earlier, there would be some value in updating the PL/I
FAQ to make it clear that contemporary PL/I does support OOP,
if it does.   Sample code that shows how OOP is represented in
PL/I would be useful.

We once discussed the issue of assertions, using the Hoare triplet.  The
answer given in this forum was to use the pre-compiler.   While this might
seem a satisfactory solution from your viewpoint, it seems a little awkward
from mine.   Still, I accept that it is one way to approach the problem.   Few
languages, besides Eiffel, do a good job with this concern, but each language
has its own take on how to satisfy pre-, post-, and invariant conditions.

Since assertions are an important idea in modeling (e.g., UML, etc.) for
software engineering, it would be helpful for the PL/I FAQ to include some
examples of how this notion is dealt with in PL/I.

The fact that the information about PL/I is difficult to come by and difficult
to decipher is not my problem.   Those who wish to gain a greater acceptance
of the language have a responsbility to provide clear, complete, and useful
answers when the questions are asked.

I look forward to your help in preparing good educational materials.   My class
does not focus on PL/I.   I have time for one, at most two, one hour lectures
that cover the capabilities, benefits, and limitations of the language.   In 
those
one or two hours, I will include the history, the highlights, notes about 
contemporary
usage of the language, its relationship to other modern programming languages,
some comments about its design goals, etc.

I would like to have a free compiler my students could install on their laptops
so they could try it for themselves.   Many of my students are likely to do just
that.    They already do this with other languages that are available through
the Free Software Foundation.   And, the have no problem with arguing with
me about opinions I might express.   They are all graduate students and many
have already made up their minds before they come to my class.

At the very least, Robin, you can once again list the URL's you gave me in
the past.  I will make sure to pass those URL's on to my students when we
get the point where I introduce them to PL/I.     That should seem fair.

Richard Riehle 


0
adaworks2 (748)
4/15/2006 8:45:47 PM
> I am not the enemy.   If I am asking for information and do not
> find that the answers are satisfactory, I will ask again until I
> discover the facts.

You might try taking a look at the ANSI standard for PL/I

http://webstore.ansi.org/ansidocstore

and search for PL/I (that's uppercase letter i, NOT a one)

It'll cost you some money but if you're serious about needing
to know it might just be worth it.  If it's not in the standard, it's
only found in proprietary implementations.

Tom Lake 


0
tlake (477)
4/15/2006 9:33:50 PM
adaworks@sbcglobal.net wrote:

> I am going to assume that, because no one was able to post a PL/I
> program that mapped to the class definition (below) that I posted in
> December, that PL/I does not support the object-oriented class
> model.
> 
Do you mind to restate your orginal problem?

Just as side note, the p1lgcc project did receive an Object Oriented
extension.
I will do a more detailed writeup for the upcomming version 0.0.11 of
pl1gcc.

Henrik
pl1gcc.sourceforge.net
0
4/15/2006 10:41:03 PM
adaworks@sbcglobal.net wrote:
> "robin" <robin_v@bigpond.com> wrote in message 
> news:c480g.7153$vy1.3116@news-server.bigpond.net.au...

(snip)

>>Had you done so, you would have found the wealth of features
>>that PL/I contains, including a high speed XML parser.

You mean one that is part of the language, or one that happens
to be supplied with some compilers.  I believe that regular
expressions were also mentioned, but note that none of the
popular languages support them.  They are part of the POSIX
library on unix systems, and are also supported by many C
implementations, but they are not part of the C standard
library.  (As of C89, I don't know C99 so well, yet.)

There are XML and regular expression packages for Java,
but again not part of the Java standard.

> OK.  What about the object-oriented programming capabilities?

I haven't used OO PL/I, and I am not so interested in using it.
My Java programs are object oriented where necessary, but often
it seems to me that OO is overdone.  The Java UDP implementation,
for example, seems to be stretching the need for OO capabilities.

> You did not give me a resource that demonstrates the capabilities
> for OOP in PL/I.    If you did, I must have missed it.

> I am not the enemy.   If I am asking for information and do not
> find that the answers are satisfactory, I will ask again until I
> discover the facts.

That happens to be the wrong attitude for this newsgroup, though
you wouldn't know that, or why.

> So, until I am sure that PL/I has support for OOP, I will continue
> to assume it does not.   Instead of a direct answer, I get criticized
> for asking the question.

> As I noted earlier, there would be some value in updating the PL/I
> FAQ to make it clear that contemporary PL/I does support OOP,
> if it does.   Sample code that shows how OOP is represented in
> PL/I would be useful.

PL/I had many programming features years (or decades) before they
appeared in other languages.  Most of the reason it isn't so popular
is that it had those features before machines were powerful enough
to support them.  The PL/I (F) compiler will compile large programs
in 44K or RAM, but you might not want to wait until it is done.
(If needed, the symbol table is stored on disk.)


(snip)

> The fact that the information about PL/I is difficult to come by and difficult
> to decipher is not my problem.   Those who wish to gain a greater acceptance
> of the language have a responsbility to provide clear, complete, and useful
> answers when the questions are asked.

PL/I is mostly supported by IBM, and, as far as I know, because they 
want to support it.  It is reasonably well documented in IBM's manuals,
but there is not so much in the way of third party manuals as some other
languages.

> I look forward to your help in preparing good educational materials.   My class
> does not focus on PL/I.   I have time for one, at most two, one hour lectures
> that cover the capabilities, benefits, and limitations of the language.   In 
> those
> one or two hours, I will include the history, the highlights, notes about 
> contemporary
> usage of the language, its relationship to other modern programming languages,
> some comments about its design goals, etc.

That is probably about right.  As well as I know it, the design goals
included replacing both Fortran and COBOL.  If the compilation and 
execution were fast enough on a 360/40 that might have happened.

> I would like to have a free compiler my students could install on their laptops
> so they could try it for themselves.   

(snip)

There is a pl1gcc project, but I don't believe they are quite ready yet.

-- glen

0
gah (12851)
4/16/2006 2:24:32 AM
Just my personal opinion, but from the problems and disasters I'v seen 
happen, I think OOP is very overrated.

As far as isolating things, what Ive done in the past is put the data 
(depending on needs of the data) in external static/controlled 
structures and only used subroutines to access the data.

I may have to do more explicit work in creating the structure(s) and 
subroutines, but then I'm also sure that all th e hdden OOP support is 
messing something up on me.

Working in PL/1 under Multics where everything by default is dynamically 
linked you can change things on the fly including changing structures 
and subroutines and having the new ones replace the old ones by having 
the system re-dynamic link the changes.

another advantage on Multics is you didn't even have to write a 
subroutine until you raised dynamic_link_fault.  Multics allowed to to 
write and compile the missing item and then retry the failed link_fault 
and contineu running the 'program'.

note I mena both functions and subroutines when I say subroutines.

adaworks@sbcglobal.net wrote:
> "robin" <robin_v@bigpond.com> wrote in message 
> news:c480g.7153$vy1.3116@news-server.bigpond.net.au...
> 
>>We have referred you to good sources.
>>You keep coming up with the same old questions,
>>indicating that you have not followed them.
>>
>>Had you done so, you would have found the wealth of features
>>that PL/I contains, including a high speed XML parser.
>>
> 
> OK.  What about the object-oriented programming capabilities?
> 
> 
> You did not give me a resource that demonstrates the capabilities
> for OOP in PL/I.    If you did, I must have missed it.
> 
> I am not the enemy.   If I am asking for information and do not
> find that the answers are satisfactory, I will ask again until I
> discover the facts.
> 
> So, until I am sure that PL/I has support for OOP, I will continue
> to assume it does not.   Instead of a direct answer, I get criticized
> for asking the question.
> 
> As I noted earlier, there would be some value in updating the PL/I
> FAQ to make it clear that contemporary PL/I does support OOP,
> if it does.   Sample code that shows how OOP is represented in
> PL/I would be useful.
> 
> We once discussed the issue of assertions, using the Hoare triplet.  The
> answer given in this forum was to use the pre-compiler.   While this might
> seem a satisfactory solution from your viewpoint, it seems a little awkward
> from mine.   Still, I accept that it is one way to approach the problem.   Few
> languages, besides Eiffel, do a good job with this concern, but each language
> has its own take on how to satisfy pre-, post-, and invariant conditions.
> 
> Since assertions are an important idea in modeling (e.g., UML, etc.) for
> software engineering, it would be helpful for the PL/I FAQ to include some
> examples of how this notion is dealt with in PL/I.
> 
> The fact that the information about PL/I is difficult to come by and difficult
> to decipher is not my problem.   Those who wish to gain a greater acceptance
> of the language have a responsbility to provide clear, complete, and useful
> answers when the questions are asked.
> 
> I look forward to your help in preparing good educational materials.   My class
> does not focus on PL/I.   I have time for one, at most two, one hour lectures
> that cover the capabilities, benefits, and limitations of the language.   In 
> those
> one or two hours, I will include the history, the highlights, notes about 
> contemporary
> usage of the language, its relationship to other modern programming languages,
> some comments about its design goals, etc.
> 
> I would like to have a free compiler my students could install on their laptops
> so they could try it for themselves.   Many of my students are likely to do just
> that.    They already do this with other languages that are available through
> the Free Software Foundation.   And, the have no problem with arguing with
> me about opinions I might express.   They are all graduate students and many
> have already made up their minds before they come to my class.
> 
> At the very least, Robin, you can once again list the URL's you gave me in
> the past.  I will make sure to pass those URL's on to my students when we
> get the point where I introduce them to PL/I.     That should seem fair.
> 
> Richard Riehle 
> 
> 
0
multicsfan (63)
4/16/2006 12:13:47 PM
multicsfan wrote:

> Just my personal opinion, but from the problems and disasters I'v seen 
> happen, I think OOP is very overrated.

and note that OOP doesn't require an OO language, though it does
make it easier.  I used to use a graphics system that was OO and
written mostly in Fortran 66 (and some S/360 assembly).

> As far as isolating things, what Ive done in the past is put the data 
> (depending on needs of the data) in external static/controlled 
> structures and only used subroutines to access the data.

> I may have to do more explicit work in creating the structure(s) and 
> subroutines, but then I'm also sure that all th e hdden OOP support is 
> messing something up on me.

and that some people try to make things OO when it isn't natural, and 
doesn't really help any.


(big snip)

-- glen

0
gah (12851)
4/16/2006 6:44:20 PM
"Tom Lake" <tlake@twcny.rr.com> wrote in message
news:2Fd0g.8$LG.0@twister.nyroc.rr.com...
> > I am not the enemy.   If I am asking for information and do not
> > find that the answers are satisfactory, I will ask again until I
> > discover the facts.
>
> You might try taking a look at the ANSI standard for PL/I
>
> http://webstore.ansi.org/ansidocstore

A more worthwhile expedition would be to look at the
Language Reference, the URL of which was posted
recently.


0
robin_v (2737)
4/17/2006 2:40:58 PM
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:L8SdncJvzIBLN9zZ4p2dnA@comcast.com...
> adaworks@sbcglobal.net wrote:
> > "robin" <robin_v@bigpond.com> wrote in message
> > news:c480g.7153$vy1.3116@news-server.bigpond.net.au...
>
> (snip)
>
> >>Had you done so, you would have found the wealth of features
> >>that PL/I contains, including a high speed XML parser.
>
> You mean one that is part of the language, or one that happens
> to be supplied with some compilers.  I believe that regular
> expressions were also mentioned, but note that none of the
> popular languages support them.  They are part of the POSIX
> library on unix systems, and are also supported by many C
> implementations, but they are not part of the C standard
> library.  (As of C89, I don't know C99 so well, yet.)
>
> There are XML and regular expression packages for Java,
> but again not part of the Java standard.
>
> > OK.  What about the object-oriented programming capabilities?
>
> I haven't used OO PL/I, and I am not so interested in using it.
> My Java programs are object oriented where necessary, but often
> it seems to me that OO is overdone.  The Java UDP implementation,
> for example, seems to be stretching the need for OO capabilities.
>
> > You did not give me a resource that demonstrates the capabilities
> > for OOP in PL/I.    If you did, I must have missed it.
>
> > I am not the enemy.   If I am asking for information and do not
> > find that the answers are satisfactory, I will ask again until I
> > discover the facts.
>
> That happens to be the wrong attitude for this newsgroup, though
> you wouldn't know that, or why.
>
> > So, until I am sure that PL/I has support for OOP, I will continue
> > to assume it does not.   Instead of a direct answer, I get criticized
> > for asking the question.
>
> > As I noted earlier, there would be some value in updating the PL/I
> > FAQ to make it clear that contemporary PL/I does support OOP,
> > if it does.   Sample code that shows how OOP is represented in
> > PL/I would be useful.
>
> PL/I had many programming features years (or decades) before they
> appeared in other languages.  Most of the reason it isn't so popular
> is that it had those features before machines were powerful enough
> to support them.

That is, of course, nonsense.
You dont need a "powerful" machine to support the features
that PL/I had when first introduced.
    (Of the smaller IBM machines, the S/20 had a subset,
and ou could use PL/Ion a model 30 with a 32K store)
Indeed, even earlier machines were running HLLs.
    Among those was Algol on a machine with 384 words
of high speed memory, and a backup memory of 8K words.

>  The PL/I (F) compiler will compile large programs
> in 44K or RAM, but you might not want to wait until it is done.
> (If needed, the symbol table is stored on disk.)

The F compiler was not intended to run in 44K.
The D compiler was available for that.

> >   Those who wish to gain a greater acceptance
> > of the language have a responsbility to provide clear, complete, and useful
> > answers when the questions are asked.
>
> PL/I is mostly supported by IBM, and, as far as I know, because they
> want to support it.  It is reasonably well documented in IBM's manuals,
> but there is not so much in the way of third party manuals as some other
> languages.
>
> > I look forward to your help in preparing good educational materials.   My
class
> > does not focus on PL/I.   I have time for one, at most two, one hour
lectures
> > that cover the capabilities, benefits, and limitations of the language.   In
> > those
> > one or two hours, I will include the history, the highlights, notes about
> > contemporary
> > usage of the language, its relationship to other modern programming
languages,
> > some comments about its design goals, etc.
>
> That is probably about right.  As well as I know it, the design goals
> included replacing both Fortran and COBOL.  If the compilation and
> execution were fast enough on a 360/40 that might have happened.

PL/C has a compile speed around ten times faster than
the F compiler, and outperformed the COBOL and Fortran
compilers in terms of compile speed, and was on a par with the
WATFOR FORTRAN compiler.


0
robin_v (2737)
4/17/2006 2:40:59 PM
<adaworks@sbcglobal.net> wrote in message
news:%Xc0g.16181$tN3.9162@newssvr27.news.prodigy.net...
>
> The fact that the information about PL/I is difficult to come by and difficult
> to decipher is not my problem.

It is [your problem], if you intend to present it to a class.

    However, information about PL/I is neither "difficult to come by"
nor "difficult to decipher".

    The URLs of PL/I Language References have been posted
recently, and other sources and resources are readily available.

Bill Klein posted this link two weeks ago:
>Sent: Saturday, April 01, 2006 11:19 AM
>http://publibfi.boulder.ibm.com/epubs/pdf/ibm3lr40.pdf



0
robin_v (2737)
4/17/2006 2:41:01 PM
robin wrote:

(big snip)

> That is, of course, nonsense.
> You dont need a "powerful" machine to support the features
> that PL/I had when first introduced.
>     (Of the smaller IBM machines, the S/20 had a subset,
> and ou could use PL/Ion a model 30 with a 32K store)
> Indeed, even earlier machines were running HLLs.
>     Among those was Algol on a machine with 384 words
> of high speed memory, and a backup memory of 8K words.

There is overhead for many features, and some is there whether
you need that feature or not.  PL/I generated reentrant code,
where Fortran compilers generated static variables and static
register save areas.

>> The PL/I (F) compiler will compile large programs
>>in 44K or RAM, but you might not want to wait until it is done.
>>(If needed, the symbol table is stored on disk.)

> The F compiler was not intended to run in 44K.
> The D compiler was available for that.

F programs are for 64K machines, G for 128K, H for 256K.
A 360/40 with 64K has 20K for OS/360 PCP and 44K for user programs.
That was a design goal of the F compiler, though it might not have
run that way very often.

-- glen

0
gah (12851)
4/18/2006 4:44:30 AM
"robin" <robin_v@bigpond.com> wrote in message 
news:_NN0g.8877$vy1.5582@news-server.bigpond.net.au...
>
> A more worthwhile expedition would be to look at the
> Language Reference, the URL of which was posted
> recently.
>
OK.  I have been reading the language reference manual.    So far,
I see not explicit support for object-oriented programming.   In fact,
using the criteria of John Guttag (originator of the term Abstract
Data Type) I don't see very good support of ADT's.  Information
hiding, encapsulation, and data abstraction are not obvious, if they
are elements of the language at all.

However, I may be missing something.   I'll continue to examine the
LRM to see whether there is simply a different set of names in PL/I
for things that are named more explicitly in new languages.

In deriving new types, the language reference manual is quite explicit
about the inability to extend an existing type with new attributes.  This
would seem to eliminate inheritance as an option.   Overriding of
operations is not apparent, which would lead me to think that polymorphism
and dynamic binding are not standard features of the language.

If I am missing some part of the LRM that makes these things more
obvious, perhaps someone could give me a pointer to the exact
location in the manual where I will find these things.

Richard Riehle 


0
adaworks2 (748)
4/18/2006 6:05:08 AM
On Sat, 15 Apr 2006 22:41:03 +0000, henrik.sorensen@balcab.ch wrote:

>adaworks@sbcglobal.net wrote:
>
>> I am going to assume that, because no one was able to post a PL/I
>> program that mapped to the class definition (below) that I posted in
>> December, that PL/I does not support the object-oriented class
>> model.
>> 
>Do you mind to restate your orginal problem?
>
>Just as side note, the p1lgcc project did receive an Object Oriented
>extension.
>I will do a more detailed writeup for the upcomming version 0.0.11 of
>pl1gcc.
>
>Henrik
>pl1gcc.sourceforge.net

And to really make my point, if the professor got some useful
comments, perhaps he might motivate some of his students to work on
this project.  I have the impression that Henrik is the only one on
this project right now.

Or, the professor might even approach IBM about re-releasing the
Personal version of Visual Age PL/1, at the price of $129.  Help this
professor out and indeed he could become our friend, as he says.

Phil

0
4/18/2006 6:19:33 AM
On Sat, 15 Apr 2006 00:26:37 GMT, <adaworks@sbcglobal.net> wrote:


>
[much snipping]

>You have consistently replied to me as if I were the enemy.  On the
>contrary, I will be delighted to be a friend of PL/I.   However, I do
>prefer to have my questions answered directly and factually.   If I
>can walk into my classroom on Monday morning and announce that,
>"I was in error.   PL/I really does support modern programming
>paradigms such as OOP,"  you can be sure I will do so.

To everyone in this overheated non-discussion.

First, cool it guys!  Shouting at each other, hurling insults or
denigrating statements doesn't do anyone any good.   It also
guarantees that anyone new to this group won't dare post a question
lest he/she get a similar thunderbolt of derision aimed his/her way.

Second, not everyone is as "smart" as Robin assumes.  There might just
be people who read this group, who are actually seeking information
and knowledge.  Perhaps not small group of  "regulars" who have been
doing PL/1 since the 360 was a baby.  

Third.  IF (and I don't really know) one of the implicit objectives of
this group is to maintain and enhance interest in PL/1, then
adaworks@sbcglobal.net deserves a more complete answer.  Including
code fragments.  Not for his sake, since it appears that he has been
"judged" and found guilty of some awful "sins."   But for everyone
else's sake.  I know I would be interested in meaningful answers to
these questions.

Fourth.  For the sake of everyone reading this group, let's all try to
act like grownups.  If we are PL/1 knowledgeable chances are we're
over 35.  :)

>
>FAQ means "frequently asked questions."  Perhaps my inquiries are
>not in the category of "frequently," but I am asking them.  In the
>case of most other professors of computer science, they simply
>write off PL/I as a historical language of little contemporary interest.

True enough.

>They don't bother to ask.  If you wish to deprecate the question,
>so be it.   However, that attitude will not encourage others with
>questions to ask them.  If I can refer students to a FAQ that is
>actually informative, I will do so.
>
>Richard Riehle 
>

I might add that on a personal note, I used to work in the same
company as the inventor of Python.  At one point we were chatting and
I mentioned PL/1.  He had only "heard about it" but knew nothing
really.  

So, FIfth.  Since PL/1 was way ahead of its time (and arguably is
still better than some currently popular languages), it is to the
"greater good of PL/1" to adopt a more "open and receptive" attitude
to people who drop in here asking for information.  Who knows what
that could lead to?

In summary, the responses from Robin and some of the others in this
group are self-defeating.

Phil Burton
0
4/18/2006 6:19:46 AM
"robin" <robin_v@bigpond.com> wrote in message 
news:1ON0g.8882$vy1.8544@news-server.bigpond.net.au...
> <adaworks@sbcglobal.net> wrote in message
> news:%Xc0g.16181$tN3.9162@newssvr27.news.prodigy.net...
>>
>> The fact that the information about PL/I is difficult to come by and 
>> difficult
>> to decipher is not my problem.
>
> It is [your problem], if you intend to present it to a class.
>
If the information were easy to come by, I would not have so much
trouble getting simple questions answered by the PL/I experts in
this group.

I have posted a simple program in OOP style and asked what a corresponding
PL/I program would look like.   So far, no one has responded to that request.

You continue to make it sound as if I am interested in berating PL/I.   I will
present to my class the facts I am able to locate.   If the facts you think I
should present are not readily available to me, I'll present what I can find.

If you want to contribute to my presenting a positive view of the language,
I welcome that contribution.   I am presenting an overview of a number of
languages with about four or five languages in some depth.  Those in-depth
languages include Scheme, Prolog, C++, Python, and Ada.  They are five
examples of completely different approaches to programming language
design and represent contemporary language designs.

I also cover some other languages.   One of our faculty members is a Perl
enthusiast.  I invite him to present his advocacy of Perl.  Another likes
MatLab.  He demonstrates the virtues and power of Matlab.   The course
includes a brief treatment of COBOL (contemporary, not old-fashioned),
modern Fortran (current standard), Smalltalk, Eiffel, Ruby, Lisp, and
many more.   Naturally, we cannot cover all of these languages in the
depth we would like.   Students are given an opportunity to study one
language in-depth, not necessarily from the list above.   I will encourage
any student with an interest in PL/I to take it on as his/her class project
language.   So far, no student has ever shown interest in it.   If I can
get a student to take it on, you can be sure I will give that student as
much support as possible.

No student is going to take the trouble to learn a language that is not
up-to-date in its design features.   This would mean, for most students,
that there is support for OOP.   Standard PL/I does not seem to offer
that support.   As mentioned in another message, I am hard-pressed to
even see direct support for Abstract Data Types.

Now, instead of criticizing me, instead of telling me how awful I am,
and instead of personal attacks, let's see whether we can engage in
a dialogue that helps me make the case for PL/I.   Otherwise, I am
left with the view that I expressed in an earlier message.

Can we talk?

Richard Riehle 


0
adaworks2 (748)
4/18/2006 6:23:59 AM
adaworks@sbcglobal.net wrote:
> 
> "robin" <robin_v@bigpond.com> wrote in message
> news:1ON0g.8882$vy1.8544@news-server.bigpond.net.au...
> > <adaworks@sbcglobal.net> wrote in message
> > news:%Xc0g.16181$tN3.9162@newssvr27.news.prodigy.net...

<snip>

> If you want to contribute to my presenting a positive view of the language,

asking for flame wars...

<snip>

> languages include Scheme, Prolog, C++, Python, and Ada.  They are five
> examples of completely different approaches to programming language
> design and represent contemporary language designs.

contemporary:
Scheme(1975), Prolog(1970), C++(1983), Python(1991), and Ada(1979)
...., and I see only three (not completely) different approaches
 
<snip>
> I invite him to present his advocacy of Perl.

advocacy isn't, what experts are after

<snip>
> No student is going to take the trouble to learn a language that is not
> up-to-date in its design features.   This would mean, for most students,
> that there is support for OOP.

OOP is so eighties... - teach them Smalltalk or OORexx

<snip>

look up turing completeness

> Richard Riehle
0
4/18/2006 10:23:30 AM
On Mon, 17 Apr 2006 23:05:08 -0700, <adaworks@sbcglobal.net> wrote:

>
> "robin" <robin_v@bigpond.com> wrote in message
> news:_NN0g.8877$vy1.5582@news-server.bigpond.net.au...
>>
>> A more worthwhile expedition would be to look at the
>> Language Reference, the URL of which was posted
>> recently.
>>
> OK.  I have been reading the language reference manual.    So far,
> I see not explicit support for object-oriented programming.   In fact,
> using the criteria of John Guttag (originator of the term Abstract
> Data Type) I don't see very good support of ADT's.  Information
> hiding, encapsulation, and data abstraction are not obvious, if they
> are elements of the language at all.
>
> However, I may be missing something.   I'll continue to examine the
> LRM to see whether there is simply a different set of names in PL/I
> for things that are named more explicitly in new languages.
>
> In deriving new types, the language reference manual is quite explicit
> about the inability to extend an existing type with new attributes.  This
> would seem to eliminate inheritance as an option.   Overriding of
> operations is not apparent, which would lead me to think that  
> polymorphism
> and dynamic binding are not standard features of the language.
>
> If I am missing some part of the LRM that makes these things more
> obvious, perhaps someone could give me a pointer to the exact
> location in the manual where I will find these things.

Richard,

I see a number of problems with object oriented programming.  Languages
like c++ had as a starting point, C, which in itself has a rather low  
level of
abstraction.  After all, lexical scoping is a form of inheritance not  
supported
by C.  Extending data types is not a good thing.  As for 'abstract'data  
types
LIKE and TYPE are all that I have ever needed.  As fo Polymorphism  
(C++ academicians
seem to focus on the creation of nomenclature to make OOP seem like a  
legitimate
enterprise)  use of GENERIC allows you to overload procedures, although I  
have never
thought this a particularly good idea, for the same reason that I  
criticise OOP, to wit,
with the passage of time (assuming overloading is incrementally added in  
some fashion
and perhaps by different people)  the object's meaning becomes diffuse  
with the passage
of time and will likely become disused and replaced by some new object,  
thus obviating
one of the stated goals of OOP, viz., reusability of objects.

Never understood the value of data hiding nor what the OOP crowd really  
mean by
encapsulation.  Dynamic binding is, in my view, a function more in the  
purview of the
OS.

So, in summary,  languages like PL/I may not be modern in the sense of  
OOP, but then I
don't see that as a deficiency.  I don't have experience with C++, but I  
can tell you
(partially anecdotally and partially emprically) that C code costs about  
three times
as much as PL/I code.  This includes both the cost to develop as well as  
maintain.

Tom
>
> Richard Riehle
>
>

0
tom284 (1839)
4/18/2006 1:46:37 PM
"Wolfgang Riedel" <wolfgang.riedel@retarus.de> wrote in message 
news:4444BE22.728BA0A2@retarus.de...
>
> contemporary:
> Scheme(1975), Prolog(1970), C++(1983), Python(1991), and Ada(1979)
> ..., and I see only three (not completely) different approaches
>
I suppose it depends on what you are looking for.  These students, by
the way, have already had two Quarters of Java.

         1)  the date of design of the language is not a factor.
         2)  the languages do represent some different approaches;  from my
              perspective they are different because,
                    Scheme is a functional language
                    Prolog is a logic language
                    C++ is an object-oriented language with lots of
                            "gotchas" and highly error-prone
                    Python is an extremely flexible language that is
                              unlike any of the others in this list.
                    Ada (1983, 1987, 1995, and now 2005) is the most
                             type-safe of any language currently in use, and
                             continues to be one of the best choices for
                             safety-critical software.
           3) I do cover some new languages such as Ruby.

> <snip>
>> I invite him to present his advocacy of Perl.
>
> advocacy isn't, what experts are after
>
These are not experts.  They are graduate students in a class on comparative
programming languages.  They are learning about the design features, the
capabilities, and the relative merits of each language being studied.  I invite
enthusiasts of different languages because they can best make the case for
their favorite language.  The students are skeptical, as graduate students
should be, of any opinion expressed by me, my guest lecturers, or anyone
else.   Graduate students (in this case M.S. and PhD students) are a different
population from the typical undergraduate.   They never believe anything they
are told.  They listen, evaluate, and make up their own minds.
>
> OOP is so eighties... - teach them Smalltalk or OORexx
>
I agree with those of you who say that OOP is not the correct approach
for every problem.  Sometimes it is overkill.    Type safety is not always
necessary.    Compilation is not always the best approach.    Different
languages have different benefits (and drawbacks).   My advice to my
students is to pick the right language for the right problem, when they have
the option and the knowledge to do so.
>
> look up turing completeness
>
I am quite familiar with the work of Alan Turing, along with a lot
of other fundamental computer science theory and practice.  That is
not the topic at hand.

The purpose of my inquiry in this forum is to get more accurate information
about PL/I.  So far I have been able to find some resources, thanks to Robin
and others. However, along the way I have been pummeled for my queries.

Can we have a civilized conversation that does not involve deprecation,
personal attacks, impugning each other's intelligence, and mean-spirited
snideness?

If you have something to add regarding my inquiries about the current state
of PL/I, please share them.   If you simply want to show off how mean you
can be, I rather not hear it.

Thanks,

Richard Riehle 


0
adaworks2 (748)
4/18/2006 2:08:38 PM
On Tue, 18 Apr 2006 07:08:38 -0700, <adaworks@sbcglobal.net> wrote:

>
> "Wolfgang Riedel" <wolfgang.riedel@retarus.de> wrote in message
> news:4444BE22.728BA0A2@retarus.de...
>>
>> contemporary:
>> Scheme(1975), Prolog(1970), C++(1983), Python(1991), and Ada(1979)
>> ..., and I see only three (not completely) different approaches
>>
> I suppose it depends on what you are looking for.  These students, by
> the way, have already had two Quarters of Java.
>
>          1)  the date of design of the language is not a factor.
>          2)  the languages do represent some different approaches;  from  
> my
>               perspective they are different because,
>                     Scheme is a functional language
>                     Prolog is a logic language
>                     C++ is an object-oriented language with lots of
>                             "gotchas" and highly error-prone
>                     Python is an extremely flexible language that is
>                               unlike any of the others in this list.
>                     Ada (1983, 1987, 1995, and now 2005) is the most
>                              type-safe of any language currently in use,  
> and
>                              continues to be one of the best choices for
>                              safety-critical software.
I don't think Ada has a leg up on PL/I in this regard.  I'll bet we have  
as much PL/I
in the military as Ada.  If not, it is a close second.  BTW, CHILL was an  
official
language of the DCA for a number of years.

>            3) I do cover some new languages such as Ruby.
>
>> <snip>
>>> I invite him to present his advocacy of Perl.
>>
>> advocacy isn't, what experts are after
>>
> These are not experts.  They are graduate students in a class on  
> comparative
> programming languages.  They are learning about the design features, the
> capabilities, and the relative merits of each language being studied.  I  
> invite
> enthusiasts of different languages because they can best make the case  
> for
> their favorite language.  The students are skeptical, as graduate  
> students
> should be, of any opinion expressed by me, my guest lecturers, or anyone
> else.   Graduate students (in this case M.S. and PhD students) are a  
> different
> population from the typical undergraduate.   They never believe anything  
> they
> are told.  They listen, evaluate, and make up their own minds.
>>
>> OOP is so eighties... - teach them Smalltalk or OORexx
>>
> I agree with those of you who say that OOP is not the correct approach
> for every problem.  Sometimes it is overkill.    Type safety is not  
> always
> necessary.    Compilation is not always the best approach.    Different
> languages have different benefits (and drawbacks).   My advice to my
> students is to pick the right language for the right problem, when they  
> have
> the option and the knowledge to do so.
>>
>> look up turing completeness
>>
> I am quite familiar with the work of Alan Turing, along with a lot
> of other fundamental computer science theory and practice.  That is
> not the topic at hand.
>
> The purpose of my inquiry in this forum is to get more accurate  
> information
> about PL/I.  So far I have been able to find some resources, thanks to  
> Robin
> and others. However, along the way I have been pummeled for my queries.
>
> Can we have a civilized conversation that does not involve deprecation,
> personal attacks, impugning each other's intelligence, and mean-spirited
> snideness?
>
> If you have something to add regarding my inquiries about the current  
> state
> of PL/I, please share them.   If you simply want to show off how mean you
> can be, I rather not hear it.
>
> Thanks,
>
> Richard Riehle
>
>

0
tom284 (1839)
4/18/2006 3:19:42 PM
"Lady Margaret Thatcher" <Was_at_10_Downing_Street@bad_for_the_UK.org> wrote in
message
> Or, the professor might even approach IBM about re-releasing the
> Personal version of Visual Age PL/1, at the price of $129.

If Richard were to make a direct approach to Peter Elderon
of IBM, he may find that special arrangements can be made for the
class.


0
robin_v (2737)
4/19/2006 5:02:29 AM
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:YuednYNh-_A689nZnZ2dnUVZ_vidnZ2d@comcast.com...
> robin wrote:
> > That is, of course, nonsense.
> > You dont need a "powerful" machine to support the features
> > that PL/I had when first introduced.
> >     (Of the smaller IBM machines, the S/20 had a subset,
> > and ou could use PL/Ion a model 30 with a 32K store)
> > Indeed, even earlier machines were running HLLs.
> >     Among those was Algol on a machine with 384 words
> > of high speed memory, and a backup memory of 8K words.
>
> There is overhead for many features, and some is there whether
> you need that feature or not.  PL/I generated reentrant code,
> where Fortran compilers generated static variables and static
> register save areas.

That's because FORTRAN did not support recursion
(and did not support it until Fortarn 90 in 1991, 25 years later);
Nor did it support dynamic arrays, again not until 1991.
Meanwhile, ALGOL had it 6 years earlier.
Reentrant code per se does not contribute a major overhead.
If you wanted, you could have written the code to mimic
FORTRAM with everything static.  But then would have
had the clumsiness of FORTAN, with hard limits on
the bounds of arrays, and so on [that was a feature of
FORTRAN that, in the strict sense of the word, prevented
the writing of algorithms.

> >> The PL/I (F) compiler will compile large programs
> >>in 44K or RAM, but you might not want to wait until it is done.
> >>(If needed, the symbol table is stored on disk.)
>
> > The F compiler was not intended to run in 44K.
> > The D compiler was available for that.
>
> F programs are for 64K machines, G for 128K, H for 256K.
> A 360/40 with 64K has 20K for OS/360 PCP and 44K for user programs.
> That was a design goal of the F compiler, though it might not have
> run that way very often.
>
> -- glen


0
robin_v (2737)
4/19/2006 5:02:30 AM
<adaworks@sbcglobal.net> wrote in message
news:ok%0g.16724$tN3.1773@newssvr27.news.prodigy.net...
>
> "robin" <robin_v@bigpond.com> wrote in message
> news:_NN0g.8877$vy1.5582@news-server.bigpond.net.au...
> >
> > A more worthwhile expedition would be to look at the
> > Language Reference, the URL of which was posted
> > recently.
>
> OK.  I have been reading the language reference manual.    So far,
> I see not explicit support for object-oriented programming.   In fact,
> using the criteria of John Guttag (originator of the term Abstract
> Data Type) I don't see very good support of ADT's.  Information
> hiding, encapsulation, and data abstraction are not obvious, if they
> are elements of the language at all.

LIKE, DEFINE STRUCTURE, and the TYPE attribute
help here.

> However, I may be missing something.   I'll continue to examine the
> LRM to see whether there is simply a different set of names in PL/I
> for things that are named more explicitly in new languages.
>
> In deriving new types, the language reference manual is quite explicit
> about the inability to extend an existing type with new attributes.

The dimension attribute can be added.

>  This
> would seem to eliminate inheritance as an option.   Overriding of
> operations is not apparent,

That would require the use of the preprocessor.


0
robin_v (2737)
4/19/2006 5:02:31 AM
"Tom Linden" <tom@kednos.com> wrote in message
news:op.s77l64r2zgicya@hyrrokkin...
> On Tue, 18 Apr 2006 07:08:38 -0700, "Richard Riehle" <adaworks@sbcglobal.net>
wrote:
>
> > "Wolfgang Riedel" <wolfgang.riedel@retarus.de> wrote in message
> > news:4444BE22.728BA0A2@retarus.de...

> >                     Ada (1983, 1987, 1995, and now 2005) is the most
> >                              type-safe of any language currently in use, and
> >                              continues to be one of the best choices for
> >                              safety-critical software.
> I don't think Ada has a leg up on PL/I in this regard.  I'll bet we have
> as much PL/I in the military as Ada.  If not, it is a close second.

PL/I has excellent error detection and recovery,
which is essential for any real-time system.
    As has been pointed out (by Peter Flass?),
PL/I can emulate Ada's error-handling but not vice versa.


0
robin_v (2737)
4/19/2006 5:02:32 AM
<adaworks@sbcglobal.net> wrote in message
news:%Xc0g.16181$tN3.9162@newssvr27.news.prodigy.net...
>
> The fact that the information about PL/I is difficult to come by and difficult
> to decipher is not my problem.   Those who wish to gain a greater acceptance
> of the language have a responsbility to provide clear, complete, and useful
> answers when the questions are asked.

As I said before, it is not "difficult to come by" nor "difficult to decipher"
information about PL/I.
    There are several web-sites offering extensive information,
and LRMs are readily available.


0
robin_v (2737)
4/19/2006 5:02:33 AM
"Tom Linden" <tom@kednos.com> wrote in message
news:op.s77hvzg8zgicya@hyrrokkin...

>  use of GENERIC allows you to overload procedures, although I
> have never
> thought this a particularly good idea,

Generic procedures (like generic built-in procedures) were one of the
good things introduced by PL/I back in 1966.
    The use of user generic procedures (whether functions or subroutines)
helps deal with different data types automatically.  And very effectively.
    They are now (2006) regarded as so routine as far as builtins
are cncerned that we don't even think about it.
    One wonders how we got along without them for so long
in other languages.
    With generics, we can write routines that can deal with
(for example) real and complex data without having to bother
about anything in the CALL statement or function reference.
    Or with decimal and binary data, for example.


0
robin_v (2737)
4/19/2006 5:02:34 AM
<adaworks@sbcglobal.net> wrote in message
news:3C%0g.16726$tN3.3785@newssvr27.news.prodigy.net...
>
> "robin" <robin_v@bigpond.com> wrote in message
> news:1ON0g.8882$vy1.8544@news-server.bigpond.net.au...
> > <adaworks@sbcglobal.net> wrote in message
> > news:%Xc0g.16181$tN3.9162@newssvr27.news.prodigy.net...
> >>
> >> The fact that the information about PL/I is difficult to come by and
> >> difficult to decipher is not my problem.
> >
> > It is [your problem], if you intend to present it to a class.
>
> If the information were easy to come by, I would not have so much
> trouble getting simple questions answered by the PL/I experts in
> this group.

Perhaps there are no experts.
Or perhaps the jargon you use is foreign,
or that the questions are not understood.

But the information is "easy to come by".
It abounds in readily-available LRMs,
web-sites, and so on.
    However, there's no short-cut for an instructor
to doing the hack work necessary to ferret out the
information needed to present to class.  And that
means perusing the manuals and available literature.
    That's not our "job".  That's yours.  It's called
"research"  (and BTW not Tom Lehrer's version of it).


0
robin_v (2737)
4/19/2006 5:02:34 AM
<adaworks@sbcglobal.net> wrote in message
news:%Xc0g.16181$tN3.9162@newssvr27.news.prodigy.net...
>
> "robin" <robin_v@bigpond.com> wrote in message
> news:c480g.7153$vy1.3116@news-server.bigpond.net.au...
> >
> > We have referred you to good sources.
> > You keep coming up with the same old questions,
> > indicating that you have not followed them.
> >
> > Had you done so, you would have found the wealth of features
> > that PL/I contains, including a high speed XML parser.
> >
> OK.  What about the object-oriented programming capabilities?

Here's a v. short example of PL/I source for a program that
I did several years ago:

   GET (A);
   GET (B);
   C = A x B;
   PUT ('Matrix multiplication of A by B yields:');
   PRINT (C, 8);

(I posted the above on 12 Dec. last in response to one of your queries.)

In the code segment, A, B, and C are matrices.
For this code, no declarations are required.
The operator 'x' signifies matrix multiplication.
The dimensions of the arrays are given with the data.

> As I noted earlier, there would be some value in updating the PL/I
> FAQ to make it clear that contemporary PL/I does support OOP,
> if it does.   Sample code that shows how OOP is represented in
> PL/I would be useful.
>
> We once discussed the issue of assertions, using the Hoare triplet.  The
> answer given in this forum was to use the pre-compiler.   While this might
> seem a satisfactory solution from your viewpoint, it seems a little awkward
> from mine.   Still, I accept that it is one way to approach the problem.   Few
> languages, besides Eiffel, do a good job with this concern, but each language
> has its own take on how to satisfy pre-, post-, and invariant conditions.

The use of the preprocessor simplifies such assertions,
and can signal a condition, if the programmer desires,
when the assertion fails.

> Since assertions are an important idea in modeling (e.g., UML, etc.) for
> software engineering, it would be helpful for the PL/I FAQ to include some
> examples of how this notion is dealt with in PL/I.

I think I gave an illustration of its possible use.  If not, here is an example.
ASSERT (A < B);

> The fact that the information about PL/I is difficult to come by and difficult
> to decipher is not my problem.   Those who wish to gain a greater acceptance
> of the language have a responsbility to provide clear, complete, and useful
> answers when the questions are asked.

> I would like to have a free compiler my students could install on their
laptops
> so they could try it for themselves.   Many of my students are likely
> to do just that.

    If you were to make a direct approach to Peter Elderon of IBM,
you may find that special arrangements can be made for the class.

    A 60-day (free) evaluation version has been available for some time,
and was being used as recently as this year (so I deduce that it's still
current).


0
robin_v (2737)
4/19/2006 5:02:36 AM
"Tom Linden" <tom@kednos.com> wrote in message 
news:op.s77hvzg8zgicya@hyrrokkin...
>
> Richard,
>
> I see a number of problems with object oriented programming.  Languages
> like c++ had as a starting point, C, which in itself has a rather low  level 
> of abstraction.
Agreed.  C++ is a pretty awful language design, largely because it
is based on C.   The language is especially error-prone.   I am sure
it is far more error-prone than PL/I.   I sometimes wonder why people
complain about the errors in programs when they insist on using a
language that encourages erroneous constructs.
>
>After all, lexical scoping is a form of inheritance not supported
> by C.  Extending data types is not a good thing.
Sometimes is a very useful thing to be able to do.  However, it is
often misused or overused.   Extensible types is simply a capability
that, when it is appropriate, can be valuable.  Sadly, many software
people learn one new idea and use it for everything.

>As for 'abstract'data types LIKE and TYPE are all that I have ever needed.  As 
>fo Polymorphism  (C++ academicians
> seem to focus on the creation of nomenclature to make OOP seem like a 
> legitimate enterprise)
Here again, we have a mechanism that is often useful.   Not all languages
provide good support for this.   I think Eiffel does this quite well.  Java
also, but Java is not a language I particularly like.  It has shortcomings
for large-scale programs that do not become apparent to students and
professors accustomed to writing toy programs.
>
>use of GENERIC allows you to overload procedures, although I  have never 
>thought this a particularly good idea, for the same reason that I  criticise 
>OOP, to wit, with the passage of time (assuming overloading is incrementally 
>added in some fashion and perhaps by different people)  the object's meaning 
>becomes diffuse with the passage
> of time and will likely become disused and replaced by some new object,  thus 
> obviating one of the stated goals of OOP, viz., reusability of objects.
>
Genericity is one of the most valuable of all the features of type-based
languages, object-oriented or not.   Generics allow one to design resuable
components where the algorithm can be used for any data type without
making any change to the code.  The important type-based languages that
support OOP now support genericity.

For example, container classes are almost all designed as generic components.
A generic binary tree can be reused for any data type without making any
change to the algorithm that makes that tree work.   One need only to create
an instance of the code (instantiate it) with a new name and an indication of
the type of data to be stored in the tree.   I have used this feature of several
languages successfully.   Of all the features of object-technology, I like the
genericity option most.
>
> Never understood the value of data hiding nor what the OOP crowd really  mean 
> by encapsulation.  Dynamic binding is, in my view, a function more in the 
> purview of the OS.
>
Information hiding and encapsulation have proven their value in the simple
sense of building well-protected modules -- object-oriented or not.  This
idea helps support the concepts of high-cohesion and low-coupling.
>
> So, in summary,  languages like PL/I may not be modern in the sense of  OOP, 
> but then I don't see that as a deficiency.
I don't mean to imply that lack of support for OOP is a deficiency.   Different
languages are useful for different kinds of problems.   Modern Fortran is
an excellent example of an language that has evolved well.  It is not OOP in
the strict sense of that word.   It continues to provide superb support for
mathematical and scientific programming.    I mentioned Python in an earlier
post.  Python lets me do all kinds of useful things without having to think 
about
objects, dynamic binding, inheritance, or generics.  It is the right tool for 
solving
lots of software problems.

>I don't have experience with C++, but I  can tell you
> (partially anecdotally and partially emprically) that C code costs about 
> three times as much as PL/I code.  This includes both the cost to develop as 
> well as  maintain.
>
You don't have to roll in the mud with a pig to have some sense of what it means 
to
live a pig's life.   Avoid C++ for as long as possible.   It is a horrible 
language in the
context of today's programming requirements.  The simplest programs can turn 
into
nightmarish collections of unintelligible symbols that even the original 
programmer
cannot read.

Tomorrow, I have to begin the unit on C++ in my comparative programming language
course.  I need to cool-it a bit in expressing my opinion of C++.   However, on 
the
door of my office I have a sign, "C++ is its own Virus."   I plagiarized this 
quote from
a colleague in South Carolina.   He published a similar quote in a issue of 
Communications
of the ACM several years ago.

Thank your for a clear and thoughtful perspective.   You have always been one of 
those
people I could depend on for factual information, honest dialogue, and a 
fearless approach
to expressing your frank opinion.   Also important, you never resort to personal 
attacks,
disparagement of my character, or insults to my professionalism.

Best regards,

Richard Riehle


0
adaworks2 (748)
4/19/2006 6:33:59 AM
"robin" <robin_v@bigpond.com> wrote in message 
news:Fvj1g.9858$vy1.8549@news-server.bigpond.net.au...
>
> If Richard were to make a direct approach to Peter Elderon
> of IBM, he may find that special arrangements can be made for the
> class.
>
One more little point, please.

I am, as far as I can tell, one of the few professors of computer science
that is taking PL/I seriously enough to include a discussion of it in a
class on comparative programming languages.   The textbooks now
available devote almost no space to PL/I, often treating it as an
oddity of the distant past.

Some textbooks are quite mean in their treatment of it.

I am trying to provide some positive information to my students.  However,
my approach, with all the languages we cover, is to highlight both the good
and "bad" points of each language.  The students argue with me, as they
should, especially when I find fault with their own beloved favorite language.

Richard Riehle


0
adaworks2 (748)
4/19/2006 6:41:51 AM
On Tue, 18 Apr 2006 23:33:59 -0700, <adaworks@sbcglobal.net> wrote:

> Information hiding and encapsulation have proven their value in the  
> simple
> sense of building well-protected modules -- object-oriented or not.  This
> idea helps support the concepts of high-cohesion and low-coupling.

<SOAPBOX>
One of the things that bothers me about CS academia is the indiscriminate
proliferation of nomenclature under the mistaken view that putting a name
on something is knowledge. Are high-cohesion and low-coupling quantifiable
parameters?  I think not, and are better avoided.  I do have a similar  
distaste
for ad hoc extensions to any language particularly one as well defined as  
X3.53,
Extensions aren't bad, and indeed may be a very good thing,  but they  
should be
thought out in the context of the describing mechanism of the language  
itself.
So, for example,  suppose you want to add the keyword FOREVER to PL/I, you  
ask
yourself, what added functionality does it provide, and the answer is  
none,  Is it
a useful locution, maybe, can it be done otherwise, yes, gone.
</SOAPBOX>
0
tom284 (1839)
4/19/2006 1:30:50 PM
On Tue, 18 Apr 2006 22:02:30 -0700, robin <robin_v@bigpond.com> wrote:

> That's because FORTRAN did not support recursion
> (and did not support it until Fortarn 90 in 1991, 25 years later);
> Nor did it support dynamic arrays, again not until 1991.
> Meanwhile, ALGOL had it 6 years earlier.
> Reentrant code per se does not contribute a major overhead.
> If you wanted, you could have written the code to mimic
> FORTRAM with everything static.  But then would have
> had the clumsiness of FORTAN, with hard limits on
> the bounds of arrays, and so on [that was a feature of
> FORTRAN that, in the strict sense of the word, prevented
> the writing of algorithms.

Our FORTRAN compiler which was licensed to a number of computer  
manufactures
in the late 70's was reentrant, and had a number of useful extensions  
derived
 from PL/I.
0
tom284 (1839)
4/19/2006 1:34:22 PM

adaworks@sbcglobal.net wrote:
> "robin" <robin_v@bigpond.com> wrote in message 
> news:Fvj1g.9858$vy1.8549@news-server.bigpond.net.au...
> 
>>If Richard were to make a direct approach to Peter Elderon
>>of IBM, he may find that special arrangements can be made for the
>>class.
>>
> 
> One more little point, please.
> 
> I am, as far as I can tell, one of the few professors of computer science
> that is taking PL/I seriously enough to include a discussion of it in a
> class on comparative programming languages.   The textbooks now
> available devote almost no space to PL/I, often treating it as an
> oddity of the distant past.
> 
> Some textbooks are quite mean in their treatment of it.
> 
> I am trying to provide some positive information to my students.  However,
> my approach, with all the languages we cover, is to highlight both the good
> and "bad" points of each language.  The students argue with me, as they
> should, especially when I find fault with their own beloved favorite language.
> 
> Richard Riehle

In as much as most language infatuations seem religious in nature, I 
suspect you are teaching what amounts to comparative religion.

Richard Brady
0
rrllbrrady (106)
4/19/2006 5:32:37 PM
"Tom Linden" <tom@kednos.com> wrote in message
news:op.s79btornzgicya@hyrrokkin...
> On Tue, 18 Apr 2006 23:33:59 -0700, <adaworks@sbcglobal.net> wrote:
>
> > Information hiding and encapsulation have proven their value in the
> > simple
> > sense of building well-protected modules -- object-oriented or not.  This
> > idea helps support the concepts of high-cohesion and low-coupling.
>
> <SOAPBOX>
> One of the things that bothers me about CS academia is the indiscriminate
> proliferation of nomenclature under the mistaken view that putting a name
> on something is knowledge. Are high-cohesion and low-coupling quantifiable
> parameters?  I think not, and are better avoided.  I do have a similar
> distaste
> for ad hoc extensions to any language particularly one as well defined as
> X3.53,
> Extensions aren't bad, and indeed may be a very good thing,  but they
> should be
> thought out in the context of the describing mechanism of the language
> itself.
> So, for example,  suppose you want to add the keyword FOREVER to PL/I, you
> ask
> yourself, what added functionality does it provide, and the answer is
> none,

DO FOREVER is absolutely clear and unambiguous.
It's far better than DO WHILE ('1'B); can be understood by
anyone, and requires fewer characters.  It's also better than
GO TO.

>  Is it
> a useful locution, maybe, can it be done otherwise, yes, gone.

One could dispense with many constucts in any language.
    Don't need complex, don't need decimal, don't need character,
don't need floating-point, etc.  Just need integer.
    But all of them make the world an easier place to work in.
Including DO FOREVER.


0
robin_v (2737)
4/20/2006 2:52:30 AM
On Wed, 19 Apr 2006 19:52:30 -0700, robin <robin_v@bigpond.com> wrote:

> "Tom Linden" <tom@kednos.com> wrote in message
> news:op.s79btornzgicya@hyrrokkin...
>> On Tue, 18 Apr 2006 23:33:59 -0700, <adaworks@sbcglobal.net> wrote:
>>
>> > Information hiding and encapsulation have proven their value in the
>> > simple
>> > sense of building well-protected modules -- object-oriented or not.   
>> This
>> > idea helps support the concepts of high-cohesion and low-coupling.
>>
>> <SOAPBOX>
>> One of the things that bothers me about CS academia is the  
>> indiscriminate
>> proliferation of nomenclature under the mistaken view that putting a  
>> name
>> on something is knowledge. Are high-cohesion and low-coupling  
>> quantifiable
>> parameters?  I think not, and are better avoided.  I do have a similar
>> distaste
>> for ad hoc extensions to any language particularly one as well defined  
>> as
>> X3.53,
>> Extensions aren't bad, and indeed may be a very good thing,  but they
>> should be
>> thought out in the context of the describing mechanism of the language
>> itself.
>> So, for example,  suppose you want to add the keyword FOREVER to PL/I,  
>> you
>> ask
>> yourself, what added functionality does it provide, and the answer is
>> none,
>
> DO FOREVER is absolutely clear and unambiguous.
> It's far better than DO WHILE ('1'B); can be understood by
> anyone, and requires fewer characters.  It's also better than
> GO TO.

I think you missed the point, or perhaps I din't express myself well.
FOREVER adds no functioanlity to the language other than creating a
synonym of sorts.  The parser doen't need to be extended to support it
If you prefer such a locution then use the preprocessor
HAFNER> create pp.pli
t: proc options(main);
%replace TRUE by '1'B;
%dcl forever char;
%forever = 'while(TRUE)';
do forever;
  put skip list('hello');
  leave;
  end;
end t;
*EXIT*
HAFNER> pli pp
HAFNER> lin pp
HAFNER> run pp

hello

>
>>  Is it
>> a useful locution, maybe, can it be done otherwise, yes, gone.
>
> One could dispense with many constucts in any language.
>     Don't need complex, don't need decimal, don't need character,
> don't need floating-point, etc.  Just need integer.

That is a non sequitur and irrelvant.

>     But all of them make the world an easier place to work in.
> Including DO FOREVER.

It is, as I am sure you have experienced, very common for programmers to  
have
their own private toolbox which might include files for abbreviations,  
macros.
text editors and the like, which they take with them from job to job.


0
tom284 (1839)
4/20/2006 4:26:51 PM
robin wrote:
> "Tom Linden" <tom@kednos.com> wrote in message
> news:op.s79btornzgicya@hyrrokkin...
> 
>>On Tue, 18 Apr 2006 23:33:59 -0700, <adaworks@sbcglobal.net> wrote:
>>
>>
>>>Information hiding and encapsulation have proven their value in the
>>>simple
>>>sense of building well-protected modules -- object-oriented or not.  This
>>>idea helps support the concepts of high-cohesion and low-coupling.
>>
>><SOAPBOX>
>>One of the things that bothers me about CS academia is the indiscriminate
>>proliferation of nomenclature under the mistaken view that putting a name
>>on something is knowledge. Are high-cohesion and low-coupling quantifiable
>>parameters?  I think not, and are better avoided.  I do have a similar
>>distaste
>>for ad hoc extensions to any language particularly one as well defined as
>>X3.53,
>>Extensions aren't bad, and indeed may be a very good thing,  but they
>>should be
>>thought out in the context of the describing mechanism of the language
>>itself.
>>So, for example,  suppose you want to add the keyword FOREVER to PL/I, you
>>ask
>>yourself, what added functionality does it provide, and the answer is
>>none,
> 
> 
> DO FOREVER is absolutely clear and unambiguous.
> It's far better than DO WHILE ('1'B); can be understood by
> anyone, and requires fewer characters.  It's also better than
> GO TO.
> 
> 
>> Is it
>>a useful locution, maybe, can it be done otherwise, yes, gone.
> 
> 
> One could dispense with many constucts in any language.
>     Don't need complex, don't need decimal, don't need character,
> don't need floating-point, etc.  Just need integer.
>     But all of them make the world an easier place to work in.
> Including DO FOREVER.


Why do we need integer?  Why can't we just use some boolean or bit (True 
or False,  Yes or No, On or Off, One or Zero) type?

While we're at it, we ought to make simpler CPUs too. All we really need 
is a NOT operator and a conditional branch instruction.  If we want to 
avoid op-codes we can combine these into one instruction:  FBZ (Flip and 
Branch if Zero) with two addresses, the address of the bit to flip and 
the address to branch to, if the result at the address we flipped is 
zero.  Or alternatively the single instruction can be FBNZ.



LR
0
lruss (582)
4/20/2006 4:27:50 PM
"Tom Linden" <tom@kednos.com> wrote in message 
news:op.s79btornzgicya@hyrrokkin...
>
> <SOAPBOX>
> One of the things that bothers me about CS academia is the indiscriminate
> proliferation of nomenclature under the mistaken view that putting a name
> on something is knowledge. Are high-cohesion and low-coupling quantifiable
> parameters?  I think not, and are better avoided.  I do have a similar 
> distaste for ad hoc extensions to any language particularly one as well 
> defined as  X3.53,Extensions aren't bad, and indeed may be a very good thing, 
> but they  should be thought out in the context of the describing mechanism of 
> the language  itself. So, for example,  suppose you want to add the keyword 
> FOREVER to PL/I, you  ask yourself, what added functionality does it provide, 
> and the answer is  none,  Is it a useful locution, maybe, can it be done 
> otherwise, yes, gone.
> </SOAPBOX>
>
The concepts of high-cohesion and low-coupling were not the product of an
academic.   I believe the originated with Larry Constantine, not a person we
would classify as a "fuzzy-headed academic."     There actually is a set of
metrics we can apply to these two concepts.   Without going into those
metrics, most contemporary software professionals seem to agree that
a module that does one thing, and only one thing, and does it well is
easier to comprehend and easier to maintain.    That is high-cohesion. I
agree with you that the terminology is not as clear as it could be.   Low
coupling is a common practice in most of programming.   All Constantine
did was identify and label a practice already in use by experienced software
professionals.

Instead of

            loop Forever ...

which is effectively the infinite loop our mothers told us to avoid unless
we are wearing clean underwear, I prefer the command DWIM.  Most
readers of this forum will recognize DWIM as a statement from the
programming language, IDEAL (Intuitive Definitive Effortless
All-purpose Language) that translates to Do What I Mean.

The idea of sparse languages is growing in popularity.  Keep the core
language simple and do everything else with libraries.   One outcome of
this approach is to separate I/O entirely from core language. The sparse
language design advocates will continually ask whether a particular feature
should be part of the core language or deferred to a libray.

If C++ had not gone with the library model, it would be even more hideous
and difficult that it is now.

My ideal language would have at least one major characteristic: total
lack of ambiguity.    In today's world, there are no programming languages
that fit that criteria.  Some come close, but "no cigar."

In a 100 years programmers, if that is what they are still called, will regard
our bumbling efforts as the rough equivalent of the mathmeticians in the
time of Charlemagne.   We will be seen as being still in the "dark ages."
This does not relieve us of the responsibility to work hard at improving
things.   However, we, as a community of software professionals, need
to understand that none of the languages or tools we have available have
been written on stone tablets by the firey finger of God.  We have a long
way to go, still.

PL/I, Ada, C++, Java, Python, Effel and all the rest are products of imperfect
human reasoning.   I would hope that those who follow us would be able
to do better.  I guess I'll find out in a 100 years, if I decide to stick 
around.

Richard Riehle





0
adaworks2 (748)
4/20/2006 6:21:40 PM
"Richard Brady" <rrllbrrady@worrlldnet.att.net> wrote in message 
news:Vuu1g.22623$az4.22559@bgtnsc04-news.ops.worldnet.att.net...
>
> In as much as most language infatuations seem religious in nature, I suspect 
> you are teaching what amounts to comparative religion.
>
I make that point early in the course.   The religiofication of programming
languages has already become evident in the ranks of my graduate students.

I make fun of the fundamentalist movements that seem so predominant in
the world of programming.   So far, the students are starting to see that
taking an intractable religious view of their favorite language is not a
very scholarly thing to do.

In some cases, I even see some emerging apostates: former Java acolytes
who are now enjoying the sins of Python, for example.

Forgive me, Great Omnipotent Deity (GOD) of Programming Language Design
for leading these poor young students into temptation, many away from the
sanctified rites of object-oriented programming into the inquitiy of keeping
programs simple.

Richard Riehle 


0
adaworks2 (748)
4/20/2006 6:28:19 PM
adaworks@sbcglobal.net wrote:

> "Richard Brady" <rrllbrrady@worrlldnet.att.net> wrote in message 
> news:Vuu1g.22623$az4.22559@bgtnsc04-news.ops.worldnet.att.net...
> 
>>In as much as most language infatuations seem religious in nature, I suspect 
>>you are teaching what amounts to comparative religion.
>>
> 
> I make that point early in the course.   The religiofication of programming
> languages has already become evident in the ranks of my graduate students.
> 
> I make fun of the fundamentalist movements that seem so predominant in
> the world of programming.   So far, the students are starting to see that
> taking an intractable religious view of their favorite language is not a
> very scholarly thing to do.
> 
> In some cases, I even see some emerging apostates: former Java acolytes
> who are now enjoying the sins of Python, for example.
> 
> Forgive me, Great Omnipotent Deity (GOD) of Programming Language Design
> for leading these poor young students into temptation, many away from the
> sanctified rites of object-oriented programming into the inquitiy of keeping
> programs simple.

Did you have a bad experience with OOP?

LR
0
lruss (582)
4/20/2006 10:31:36 PM

adaworks@sbcglobal.net wrote:
[snip]
> PL/I, Ada, C++, Java, Python, Effel and all the rest are products of imperfect
> human reasoning.   I would hope that those who follow us would be able
> to do better.  I guess I'll find out in a 100 years, if I decide to stick 
> around.
> 
> Richard Riehle

I'mnot sure I'd say imperfect human reasoning, but in some cases (not 
necessarily thos above) the ego of someone saying, I don't like whats 
tehre and I can do it better or in other cases maybe just the NIH 
syndrom (if its not invented here, we don't use it;)  In some cases it 
can be, the tool exists, but for some reason we can't use it, 
proprietary language, too expensive, liscensing too restrictive and/or 
expensive for product distribution, etc.

Some languages are a response to specific needs or problems, some are 
responses due to lack of knwoing that there is already a solution.  If I 
know and have SNOBOL4, why should I need PERL to do string manipulation? 
  SNOBOL4 does a much better job with patterns and string manipulation 
and matching then PERL.
0
multicsfan (63)
4/21/2006 12:21:24 AM
<adaworks@sbcglobal.net> wrote in message
news:UiQ1g.72886$dW3.41868@newssvr21.news.prodigy.com...
>
> "Tom Linden" <tom@kednos.com> wrote in message
> news:op.s79btornzgicya@hyrrokkin...
> >
> > <SOAPBOX>
> > One of the things that bothers me about CS academia is the indiscriminate
> > proliferation of nomenclature under the mistaken view that putting a name
> > on something is knowledge. Are high-cohesion and low-coupling quantifiable
> > parameters?  I think not, and are better avoided.  I do have a similar
> > distaste for ad hoc extensions to any language particularly one as well
> > defined as  X3.53,Extensions aren't bad, and indeed may be a very good
thing,
> > but they  should be thought out in the context of the describing mechanism
of
> > the language  itself. So, for example,  suppose you want to add the keyword
> > FOREVER to PL/I, you  ask yourself, what added functionality does it
provide,
> > and the answer is  none,  Is it a useful locution, maybe, can it be done
> > otherwise, yes, gone.
> > </SOAPBOX>
> >
> The concepts of high-cohesion and low-coupling were not the product of an
> academic.   I believe the originated with Larry Constantine, not a person we
> would classify as a "fuzzy-headed academic."     There actually is a set of
> metrics we can apply to these two concepts.   Without going into those
> metrics, most contemporary software professionals seem to agree that
> a module that does one thing, and only one thing, and does it well is
> easier to comprehend and easier to maintain.    That is high-cohesion. I
> agree with you that the terminology is not as clear as it could be.   Low
> coupling is a common practice in most of programming.   All Constantine
> did was identify and label a practice already in use by experienced software
> professionals.
>
> Instead of
>
>             loop Forever ...
>
> which is effectively the infinite loop our mothers told us to avoid unless
> we are wearing clean underwear, I prefer the command DWIM.  Most
> readers of this forum will recognize DWIM as a statement from the
> programming language, IDEAL (Intuitive Definitive Effortless
> All-purpose Language) that translates to Do What I Mean.
>
> The idea of sparse languages is growing in popularity.

Perhaps.  Perhaps not.
In the cases of established languages, they keep growing.
Or a "bigger" version of it comes out.

>  Keep the core
> language simple and do everything else with libraries.   One outcome of
> this approach is to separate I/O entirely from core language. The sparse
> language design advocates will continually ask whether a particular feature
> should be part of the core language or deferred to a libray.

This depends on whether the language is designed to be
easy to use by the programmer, or easy to build for the
designer (which makes it difficult to use by the programmer).

> If C++ had not gone with the library model, it would be even more hideous
> and difficult that it is now.

Having a library doesn't make it any easier for the
programmer.  He still has to learn as much to write
programs (whether what subset he uses is language+library or
just language).  The library approach, however, makes it more
difficult for the programmer to use.


0
robin_v (2737)
4/21/2006 3:21:40 PM
"Tom Linden" <tom@kednos.com> wrote in message
news:op.s8bem1tdzgicya@hyrrokkin...
> On Wed, 19 Apr 2006 19:52:30 -0700, robin <robin_v@bigpond.com> wrote:
>
> > "Tom Linden" <tom@kednos.com> wrote in message
> > news:op.s79btornzgicya@hyrrokkin...
> >> On Tue, 18 Apr 2006 23:33:59 -0700, <adaworks@sbcglobal.net> wrote:
> >>
> >> > Information hiding and encapsulation have proven their value in the
> >> > simple
> >> > sense of building well-protected modules -- object-oriented or not.
> >> This
> >> > idea helps support the concepts of high-cohesion and low-coupling.
> >>
> >> <SOAPBOX>
> >> One of the things that bothers me about CS academia is the
> >> indiscriminate
> >> proliferation of nomenclature under the mistaken view that putting a
> >> name
> >> on something is knowledge. Are high-cohesion and low-coupling
> >> quantifiable
> >> parameters?  I think not, and are better avoided.  I do have a similar
> >> distaste
> >> for ad hoc extensions to any language particularly one as well defined
> >> as
> >> X3.53,
> >> Extensions aren't bad, and indeed may be a very good thing,  but they
> >> should be
> >> thought out in the context of the describing mechanism of the language
> >> itself.
> >> So, for example,  suppose you want to add the keyword FOREVER to PL/I,
> >> you
> >> ask
> >> yourself, what added functionality does it provide, and the answer is
> >> none,
> >
> > DO FOREVER is absolutely clear and unambiguous.
> > It's far better than DO WHILE ('1'B); can be understood by
> > anyone, and requires fewer characters.  It's also better than
> > GO TO.
>
> I think you missed the point, or perhaps I din't express myself well.

I didn't miss the point.  The point is that an infinite loop came
into vogue with structured programming.  GO TO was out.
DO WHILE ('1'B);
wasn't a particularly convenient way to express an infinite loop,
for the reason that I gave earlier, namely, that it wasn't clear
to everyone what it meant.  You could easily make a typo with it
(e.g., omit an apostrophe) which just wastes time.

> FOREVER adds no functioanlity to the language other than creating a
> synonym of sorts.  The parser doen't need to be extended to support it

To an extent, that's true, but then you lose the requirement that
no words are reserved, and once 'FOREVER' or any other
such word is set up that way, it cannot be used as an identifier.

> If you prefer such a locution then use the preprocessor
> HAFNER> create pp.pli
> t: proc options(main);
> %replace TRUE by '1'B;
> %dcl forever char;
> %forever = 'while(TRUE)';

You shouldn't need to do all that just to have a clear construct
for an infinite loop.

DO FOREVER;

is such a construct, and it's unequivically clear.

> do forever;
>   put skip list('hello');
>   leave;
>   end;
> end t;
> *EXIT*
> HAFNER> pli pp
> HAFNER> lin pp
> HAFNER> run pp
>
> hello
>
> >
> >>  Is it
> >> a useful locution, maybe, can it be done otherwise, yes, gone.
> >
> > One could dispense with many constucts in any language.
> >     Don't need complex, don't need decimal, don't need character,
> > don't need floating-point, etc.  Just need integer.
>
> That is a non sequitur and irrelvant.

It's directly relevant.  You're saying that FOREVER
is unnecessary duplication.

Removing every duplicated facility would make
the language tiny - any language.

But examples abound where that approach didn't work.
Pascal was one such (no proper strings, no proper I/O) etc.

> >     But all of them make the world an easier place to work in.
> > Including DO FOREVER.



0
robin_v (2737)
4/21/2006 3:21:41 PM
On Fri, 21 Apr 2006 08:21:41 -0700, robin <robin_v@bigpond.com> wrote:

> "Tom Linden" <tom@kednos.com> wrote in message
> news:op.s8bem1tdzgicya@hyrrokkin...
>> On Wed, 19 Apr 2006 19:52:30 -0700, robin <robin_v@bigpond.com> wrote:
>>
>> > "Tom Linden" <tom@kednos.com> wrote in message
>> > news:op.s79btornzgicya@hyrrokkin...
>> >> On Tue, 18 Apr 2006 23:33:59 -0700, <adaworks@sbcglobal.net> wrote:
>> >>
>> >> > Information hiding and encapsulation have proven their value in the
>> >> > simple
>> >> > sense of building well-protected modules -- object-oriented or not.
>> >> This
>> >> > idea helps support the concepts of high-cohesion and low-coupling.
>> >>
>> >> <SOAPBOX>
>> >> One of the things that bothers me about CS academia is the
>> >> indiscriminate
>> >> proliferation of nomenclature under the mistaken view that putting a
>> >> name
>> >> on something is knowledge. Are high-cohesion and low-coupling
>> >> quantifiable
>> >> parameters?  I think not, and are better avoided.  I do have a  
>> similar
>> >> distaste
>> >> for ad hoc extensions to any language particularly one as well  
>> defined
>> >> as
>> >> X3.53,
>> >> Extensions aren't bad, and indeed may be a very good thing,  but they
>> >> should be
>> >> thought out in the context of the describing mechanism of the  
>> language
>> >> itself.
>> >> So, for example,  suppose you want to add the keyword FOREVER to  
>> PL/I,
>> >> you
>> >> ask
>> >> yourself, what added functionality does it provide, and the answer is
>> >> none,
>> >
>> > DO FOREVER is absolutely clear and unambiguous.
>> > It's far better than DO WHILE ('1'B); can be understood by
>> > anyone, and requires fewer characters.  It's also better than
>> > GO TO.
>>
>> I think you missed the point, or perhaps I din't express myself well.
>
> I didn't miss the point.  The point is that an infinite loop came
> into vogue with structured programming.  GO TO was out.

You did.  That is irrelevant to this discussion.

> DO WHILE ('1'B);
> wasn't a particularly convenient way to express an infinite loop,
> for the reason that I gave earlier, namely, that it wasn't clear
> to everyone what it meant.  You could easily make a typo with it
> (e.g., omit an apostrophe) which just wastes time.

Not convenient?  Come on, we've got bigger fish to fry.

so type, DO WHILE(1);  BTW, I have trained many PL/I programmers and
have never found that this was a confusing construct

You are reaching for straws in your ever present need to have the last
word.
>
>> FOREVER adds no functioanlity to the language other than creating a
>> synonym of sorts.  The parser doen't need to be extended to support it
>
> To an extent, that's true, but then you lose the requirement that
> no words are reserved, and once 'FOREVER' or any other
> such word is set up that way, it cannot be used as an identifier.

Pursuing that argument you should forgo using the macroprocessor
because it would reserve tokens.

>
>> If you prefer such a locution then use the preprocessor
>> HAFNER> create pp.pli
>> t: proc options(main);
>> %replace TRUE by '1'B;
>> %dcl forever char;
>> %forever = 'while(TRUE)';
>
> You shouldn't need to do all that just to have a clear construct
> for an infinite loop.
Apparently what is clear to one person is not to another.
>
> DO FOREVER;
>
> is such a construct, and it's unequivically clear.
>
>> do forever;
>>   put skip list('hello');
>>   leave;
>>   end;
>> end t;
>> *EXIT*
>> HAFNER> pli pp
>> HAFNER> lin pp
>> HAFNER> run pp
>>
>> hello
>>
>> >
>> >>  Is it
>> >> a useful locution, maybe, can it be done otherwise, yes, gone.
>> >
>> > One could dispense with many constucts in any language.
>> >     Don't need complex, don't need decimal, don't need character,
>> > don't need floating-point, etc.  Just need integer.
>>
>> That is a non sequitur and irrelvant.
>
> It's directly relevant.  You're saying that FOREVER
> is unnecessary duplication.

No, it is not relevant.  Saying that FOREVER is gratuitous is not the same  
as
saying that you don't need other features of the language, such as those
you listed.

>
> Removing every duplicated facility would make
> the language tiny - any language.

I am not in favour of removing features from the language and am indeed in  
favour
of adding functionality that makes sense, and have in fact done so, such  
as certain
features for systems programming.  Removing duplicate features, would not  
make the
language any smaller, since they are duplicates.

More than one person has commented on the fact that PL/I is a large  
language and
can therefore be intimidating to the novice.  Adding new keywords doesn't  
help.

Do you like UPTHRU?

>
> But examples abound where that approach didn't work.
> Pascal was one such (no proper strings, no proper I/O) etc.
>
>> >     But all of them make the world an easier place to work in.
>> > Including DO FOREVER.
>
>
>
0
tom284 (1839)
4/21/2006 10:56:50 PM
<henrik.sorensen@balcab.ch> wrote in message 
news:d81a7$44415769$5448c4ad$10031@news.hispeed.ch...
>>
> Do you mind to restate your orginal problem?
>
This is not the exact same original problem.  However it does
reflect some of the essential ideas (except dynamic binding
and polymorphism).  It is a long post, and I apologize for
that, but a long post is necessary to comply with your request.

The problem is simply a class with attributes and methods
including encapsulation.   I wrote it in pseudocode so it would
not reflect any particular language.  Rather, it reflects some of
the more important ideas of OOP.

            class Machine
                  public:
                         Turn_On();            -- state modifer method
                         Turn_Off();            -- state modifier method
                         Is_On: Boolean;    -- state query method
                  private:
                         Is_Turned_On : Boolean := False;   -- attribute of 
machine
             end Machine;

in a separate source file automatically linked to the class definition

          class implementation Machine
                  Turn_On() begin     Is_Turned_On := True;  end Turn_On();
                  Turn_Off   begin     Is_Turned_Off := False; end Turn_Off();
                  Is_On       begin     return Is_Turned_On;     end Is_On;
          end implementation Machine;

Instances of class Machine can easily be declared.

                M1, M2, M3 : Machine;

Machine can be extended.

            class Rotating_Machine extends Machine
                  public:
                         Turn_On();                         -- overrides 
original method
                         Turn_Off();                        -- overrides 
original method
                         -- method, Is_On is inherited
                         Set_RPM(Speed : Float);   -- new state modifier method
                         require parameter Speed in range 0.0 through 
00.0;   -- precondition on Set_RPM
                         ensure RPM_Speed >= parameter 
       -- postcondition on Set_RPM
                         RPM_Is : Float;                 --  state query method
                         exception : RPM_Out_Of_Range;
                  private:
                         -- attribute, Is_Turned_On is inherited
                         RPM_Speed : Float := 0.0;
                         invariant RPM_Speed in range 0.0 through 2000.0
             end Rotating_Machine;

in a separate source file automatically linked to class definition

            implementation class Rotating_Machine
                        Turn_On begin
                               Machine.Turn_On();                -- call the 
method from the parent class first
                               Set_RPM (Speed => 0.0);      -- now set the speed 
to 0.0;
                        end Turn_On;

                        Turn_Off begin
                               repeat until RPM <= 
    -- slow down the machine
                                       RPM_Speed := RPM_Speed - 1.0;
                               end repeat;
                               Machine.Turn_Off();                               
  -- turn off the machine when the speed is 0.0
                         end Turn_Off;

                         Set_RPM begin
                               if assertion_error
                                  raise RPM_Out_Of_Range
                               else
                                  RPM_Speed := Speed;
                               end if;
                          end Set_RPM;

                          RPM_Is begin
                                return RPM_Speed;
                          end RPM_Is;
             end implementation Rotating_Machine;

I am not suggesting PL/I should like like this.    My original question was 
whether
there was a way, in PL/I to create a corresponding approach to the OOP problem.

Note a couple of things in this code:  separate compilation of the class 
definition
and the class implementation,  the ability to override methods, implicit 
inheritance,
require (a predcondition), ensure (a postcondition), and invariant.   I did not 
compile
this on a machine, nor did I test it, so there may be a couple of errors.   You 
may, if
you wish, focus on those errors and disparage the entire example for that 
reason, or
you may examine the unique properties of the example and provide a well-reasoned
answer.

Again, I am not condemning PL/I if it does not provide support for a model 
similar
to my example.   I am simply asking for information.

Thanks in advance,

Richard Riehle


Richard Riehle 


0
adaworks2 (748)
4/22/2006 6:41:51 PM
"robin" <robin_v@bigpond.com> wrote in message 
news:8M62g.12015$vy1.7801@news-server.bigpond.net.au...
> <adaworks@sbcglobal.net> wrote in message
>>
>> The idea of sparse languages is growing in popularity.
>
> Perhaps.  Perhaps not.
> In the cases of established languages, they keep growing.
> Or a "bigger" version of it comes out.
>
You are certainly correct that many languages, as they evolve, become
overburdended with complexity.     When OOP was added to Perl,
many Perl programmers wondered why it was necessary.
>
> Having a library doesn't make it any easier for the
> programmer.  He still has to learn as much to write
> programs (whether what subset he uses is language+library or
> just language).  The library approach, however, makes it more
> difficult for the programmer to use.
>
The Java library model is a good example of what you just stated.
However, libraries, when kept under control, do have some virtues.
We simply need to avoid going nuts in that direction.

Richard Riehle 


0
adaworks2 (748)
4/22/2006 6:46:23 PM
adaworks@sbcglobal.net wrote:

>> Do you mind to restate your orginal problem?
>>
> This is not the exact same original problem.  However it does
> reflect some of the essential ideas (except dynamic binding
> and polymorphism).  It is a long post, and I apologize for
> that, but a long post is necessary to comply with your request.
> 
thanks much appreciated.

henrik
0
4/23/2006 12:16:17 AM
"LR" <lruss@superlink.net> wrote in message 
news:44480b8e$0$3694$cc2e38e6@news.uslec.net...
>
> Did you have a bad experience with OOP?
>
I use OOP often.  It is an excellent approach to some kinds
of problems.   It is not the only approach.   My problem is
with those who regard OOP as the only way to do things.

For some kinds of software, OOP is exactly the right thing
to do.  However, OOP carries a fair amount of overhead
in some implementations.   I am sometimes required to do
problems related to hard, real-time software.  The alacrity
of interrupt handling can be a controlling factor.  Depending
on the requirements of the problem at hand, I may need to
choose an alternative to OOP.

For small, microcontroller problems, OOP carries too much
overhead.   PL/M, Forth, C, or Assembler are often far better
choices than Ada, C++, and Java or, dare I say it here, PL/I.

We programmers are just a bunch of worker-bees with a special
skill-set.  The programming languages, software development
methods, and maintenance gadgets, are just tools in our toolbox.
We need to understand when to select the right tool for the
right job.

Richard Riehle 


0
adaworks2 (748)
4/23/2006 12:42:00 AM

adaworks@sbcglobal.net wrote:
> "LR" <lruss@superlink.net> wrote in message 
> news:44480b8e$0$3694$cc2e38e6@news.uslec.net...
> 
>>Did you have a bad experience with OOP?
>>
> 
> I use OOP often.  It is an excellent approach to some kinds
> of problems.   It is not the only approach.   My problem is
> with those who regard OOP as the only way to do things.
> 
> For some kinds of software, OOP is exactly the right thing
> to do.  However, OOP carries a fair amount of overhead
> in some implementations.   I am sometimes required to do
> problems related to hard, real-time software.  The alacrity
> of interrupt handling can be a controlling factor.  Depending
> on the requirements of the problem at hand, I may need to
> choose an alternative to OOP.
> 
> For small, microcontroller problems, OOP carries too much
> overhead.   PL/M, Forth, C, or Assembler are often far better
> choices than Ada, C++, and Java or, dare I say it here, PL/I.

I take exception to your inclusion of PL/I in the above list as NOT one 
of the better choices.  I doubt if I still have the issue laying around 
but in the early '80s Byte Magazine ran an article with the results of 
several benchmarking tests.  Digital Research's (Dr. Gary Kildall) PL/I 
sub-subset G implementation on 8080 and x86 PC platforms outperformed 
every other language available at the time for PCs.  I still use it for 
various projects because of its lean and mean approach to clean code 
generation.

> 
> We programmers are just a bunch of worker-bees with a special
> skill-set.  The programming languages, software development
> methods, and maintenance gadgets, are just tools in our toolbox.
> We need to understand when to select the right tool for the
> right job.
> 
> Richard Riehle 
> 
> 
0
donaldldobbs (108)
4/23/2006 3:15:11 AM
"Donald L. Dobbs" <donaldldobbs@cox.net> wrote in message 
news:piC2g.5981$QP4.5877@fed1read12...
>
>
> I take exception to your inclusion of PL/I in the above list as NOT one of the 
> better choices.  I doubt if I still have the issue laying around but in the 
> early '80s Byte Magazine ran an article with the results of several 
> benchmarking tests.  Digital Research's (Dr. Gary Kildall) PL/I sub-subset G 
> implementation on 8080 and x86 PC platforms outperformed every other language 
> available at the time for PCs.  I still use it for various projects because of 
> its lean and mean approach to clean code generation.
>
I am familiar with the work of Kildall.   He was a professor of computer
science at the same school where I currently teach.   PL/M was in my
list of good languages from microcontrollers.   A subset of PL/I is
fine for this purpose.    However, I personally prefer either Assembler
or Forth.

The full implementation of PL/I is probably not appropriate for microcontrollers
mainly because most of what is included in the full language is unnecessary and
inappropriate for microcontroller programming.   For the record, my experience
in this realm is limited to the Intel 8051 and that domain is quite restrictive.

Richard Riehle 


0
adaworks2 (748)
4/23/2006 5:55:24 AM

adaworks@sbcglobal.net wrote:
> "Donald L. Dobbs" <donaldldobbs@cox.net> wrote in message 
> news:piC2g.5981$QP4.5877@fed1read12...
> 
>>
>>I take exception to your inclusion of PL/I in the above list as NOT one of the 
>>better choices.  I doubt if I still have the issue laying around but in the 
>>early '80s Byte Magazine ran an article with the results of several 
>>benchmarking tests.  Digital Research's (Dr. Gary Kildall) PL/I sub-subset G 
>>implementation on 8080 and x86 PC platforms outperformed every other language 
>>available at the time for PCs.  I still use it for various projects because of 
>>its lean and mean approach to clean code generation.
>>
> 
> I am familiar with the work of Kildall.   He was a professor of computer
> science at the same school where I currently teach.   PL/M was in my
> list of good languages from microcontrollers.   A subset of PL/I is
> fine for this purpose.    However, I personally prefer either Assembler
> or Forth.

Agree.

> 
> The full implementation of PL/I is probably not appropriate for microcontrollers
> mainly because most of what is included in the full language is unnecessary and
> inappropriate for microcontroller programming. 

Agree.

   For the record, my experience
> in this realm is limited to the Intel 8051 and that domain is quite restrictive.
> 
> Richard Riehle 
> 
> 
0
donaldldobbs (108)
4/23/2006 4:53:28 PM
"Donald L. Dobbs" <donaldldobbs@cox.net> wrote in message
news:piC2g.5981$QP4.5877@fed1read12...
>
> adaworks@sbcglobal.net wrote:

> > For small, microcontroller problems, OOP carries too much
> > overhead.   PL/M, Forth, C, or Assembler are often far better
> > choices than Ada, C++, and Java or, dare I say it here, PL/I.
>
> I take exception to your inclusion of PL/I in the above list as NOT one
> of the better choices.  I doubt if I still have the issue laying around
> but in the early '80s Byte Magazine ran an article with the results of
> several benchmarking tests.  Digital Research's (Dr. Gary Kildall) PL/I
> sub-subset G implementation on 8080 and x86 PC platforms outperformed
> every other language available at the time for PCs.  I still use it for
> various projects because of its lean and mean approach to clean code
> generation.

I can confirm the "tightness" of DR PL/I, of which
I used a lot recently when I was away from home for
an extended period.  There, I also did a small contract job
with it.  As to speed, the originator of the contract said
that he was "impressed".


0
robin_v (2737)
4/24/2006 12:07:34 PM
adaworks@sbcglobal.net wrote:
> "LR" <lruss@superlink.net> wrote in message 
> news:44480b8e$0$3694$cc2e38e6@news.uslec.net...
>> Did you have a bad experience with OOP?
>>
> I use OOP often.  It is an excellent approach to some kinds
> of problems.   It is not the only approach.   My problem is
> with those who regard OOP as the only way to do things.
> 
> For some kinds of software, OOP is exactly the right thing
> to do.  However, OOP carries a fair amount of overhead
> in some implementations.   I am sometimes required to do
> problems related to hard, real-time software.  The alacrity
> of interrupt handling can be a controlling factor.  Depending
> on the requirements of the problem at hand, I may need to
> choose an alternative to OOP.
> 
> For small, microcontroller problems, OOP carries too much
> overhead.   PL/M, Forth, C, or Assembler are often far better
> choices than Ada, C++, and Java or, dare I say it here, PL/I.
> 
> We programmers are just a bunch of worker-bees with a special
> skill-set.  The programming languages, software development
> methods, and maintenance gadgets, are just tools in our toolbox.
> We need to understand when to select the right tool for the
> right job.
> 
> Richard Riehle 
> 
> 

when i was in grad school, I wrote (1) a parser in APL for a compiler class, and 
  (2) a mini-database in SNOBOL4 for a Data processing class.  Both were done 
way ahead of time compared to my classmates using more traditional, FORTRAN or 
PL/1 style languages.  [Both profs, while accepting my perfectly valid, correct 
solutions as-is, changed their rules in following semesters to outlaw 
"non-traditional" languages.]

I got to play with an IBM 5100 in its APL mode.  A wonderful "little" box.  I'd 
have bought one if I could.

I agree with Mr.Riehle whole-heartedly and have made similar diatribes when I've 
taught classes.  Use the most appropriate language for the given Problem Domain.
O-O is nice, but not omni-appropriate.  The language you choose may let you 
devise a solution that is more efficient in some way than solutions suggested by 
other languages.

When I worked for StorTech, I had to design a hardware emulator.  Remembering a 
similar thing we did when I was in College, I wrote it in APL.  Had it done 
perfectly in 3 weeks, astounding my supervisor who expected several months' work.

One of the things that IBM did in their APL implementation was cause Arrays to 
use the minimal data storage necessary for the elements.  If you created an 
array of bits ("memory"), then it occupied exactly the number of bits needed by 
the dimensions (i.e., an array of 1K bits took up exactly 1K bits).

SNOBOL4's implementation included the side-effect that the name of a variable 
was itself a manipulatable string.  You could come up with some creative 
solutions playing off that feature.

You don't *think* in APL or SNOBOL4 or LISP or Prolog the way you do in a 
FORTRAN-style language.

The 'advantage' of Perl or Python over SNOBOL4 is that they allow "solutions" 
cast in the "traditional" mode (for-loops, while-loops, functions, formatted I/O).

last note: one of my school chums went to Kodak after graduation.  He worked for 
someone who was an advocate of "Gotoless" programming that was all the fad then. 
  Gary wrote to me once telling me how he decided to try the experiment of 
taking a BIG program in PL/1 and removing all the GOTO's (replacing them with 
things like "Do WHILE ('1') and such).  After some long (I forget now how long) 
time, he succeeded.  I asked him, given the herculean effort it seemed to take, 
if the effort was worth it the result?  He couldn't convince me that the 
resulting program was necessarily more efficient than the original, nor that all 
the changes he had to make produced code that was THAT much better maintainable 
than the original.  Maybe it was .. I never saw the code.

-- 
H.s.Modell
0
hsmodell (4)
4/25/2006 5:10:31 PM
"Howard Modell" <hsmodell@bcstec.ca.boeing.com> wrote in message 
news:IyAFpJ.8sJ@news.boeing.com...
>
> I got to play with an IBM 5100 in its APL mode.  A wonderful "little" box. 
> I'd have bought one if I could.
>
The IBM 5100 series is one more example of how IBM failed to correctly
assess the future.   This was a personal computer with a video display so
tiny that no one could take it seriously.   There was no interface to a
dumb terminal such as the popular ADM-1 (American Dream Machine 1),
nor did IBM bother to do anything to make it appealing.

Still, I saw small business purchasing it, contracting for custom software,
and using it for a wide range of applications.   In addition to APL, the
machine supported a reasonably good BASIC interpreter.  It could
have supported a scaled-down version of PL/I if anyone at IBM had
sufficient vision to realize its potential.

Over and over we have seen large U.S. companies lose out to smaller,
more inventive, more agile companies because of their lack of appreciation
for innovation, their failure to lead, and their bloated bureaucracies.

In a 1964 article in the IBM magazine, THINK, the author of an article
wrote, "The last act of a dying organization is to enlarge the rulebook."
I have seen this happen often with Silicon Valley companies that are
on the brink of disaster.  For example, one company I knew that was
about to sink into oblivion, realizing its vulnerability, instituted new
employee dress codes, tightened its attendance policy, and put in
place a lot of new regulations just before they were mercifully purchased
by a competitor and subsequently put our of their misery.

XEROX PARC could have been so much more successful if XEROX
had allowed them to behave as a separate company.   Tom Linden
makes a great point about how XEROX destroyed one of the finest
computer companies of its time.

Richard Riehle 


0
adaworks2 (748)
4/26/2006 12:34:17 AM

Howard Modell wrote:
[snip]
> 
> last note: one of my school chums went to Kodak after graduation.  He 
> worked for someone who was an advocate of "Gotoless" programming that 
> was all the fad then.  Gary wrote to me once telling me how he decided 
> to try the experiment of taking a BIG program in PL/1 and removing all 
> the GOTO's (replacing them with things like "Do WHILE ('1') and such).  
> After some long (I forget now how long) time, he succeeded.  I asked 
> him, given the herculean effort it seemed to take, if the effort was 
> worth it the result?  He couldn't convince me that the resulting program 
> was necessarily more efficient than the original, nor that all the 
> changes he had to make produced code that was THAT much better 
> maintainable than the original.  Maybe it was .. I never saw the code.
> 
I had a professor like that in college that very strongly encouraged 
goto less programming.  My experience is that it depends more on how the 
goto's are used.  I've had to deal with spaghetti code with branches all 
over the place, flags set/unset to determine where to goto, etc.  My 
opinoin is the main line/flow code should have the minimal number of 
goto's depending on the language and the application.  For the most part 
goto like transfers should be more reserved for exception handling/error 
reporting.

I've spent days/weeks untangling spaghetti code to figure out what 
programs I was maintaining/documenting were trying to do.  One place I 
worked for 10+ ears, the boss initially complained about the effort I 
spent undoing spaghetti code (he and a friend wrote the first version of 
the software) until it started paying off later as the increased ease of 
maintenance, cleaner code, faster/smaller code (space limited mini 
computer 56K/user), reduced errors at customer sites, easier fixing 
problems that did occur at customer sites, etc.  This realy paid off 
when the Y2K changes had to be done.  I also moved common blocks of 
inline code to subroutines.  In many cases the 'inline code blocks' were 
implimented differently by different people in different modules at 
different times so there could be as many as 50+ different versions of 
the inline code for something each with different bugs/errors that would 
show up under various conditions ;)
0
multicsfan (63)
4/26/2006 11:18:16 AM
"Howard Modell" <hsmodell@bcstec.ca.boeing.com> wrote in message
news:IyAFpJ.8sJ@news.boeing.com...
> One of the things that IBM did in their APL implementation was cause Arrays to
> use the minimal data storage necessary for the elements.  If you created an
> array of bits ("memory"), then it occupied exactly the number of bits needed
by
> the dimensions (i.e., an array of 1K bits took up exactly 1K bits).

As does PL/I.


0
robin_v (2737)
4/26/2006 2:35:24 PM
"multicsfan" <multicsfan@hotmail.com> wrote in message
news:YFI3g.4415$yI1.925@trnddc04...

> I've spent days/weeks untangling spaghetti code to figure out what
> programs I was maintaining/documenting were trying to do.  One place I
> worked for 10+ ears, the boss initially complained about the effort I
> spent undoing spaghetti code (he and a friend wrote the first version of
> the software) until it started paying off later as the increased ease of
> maintenance, cleaner code, faster/smaller code (space limited mini
> computer 56K/user),

Sheer luxury!  We had 384 words.


0
robin_v (2737)
4/26/2006 2:35:25 PM
multicsfan wrote:
> 
> 
> Howard Modell wrote:
> [snip]
>>
>> last note: one of my school chums went to Kodak after graduation.  He 
>> worked for someone who was an advocate of "Gotoless" programming that 
>> was all the fad then.  Gary wrote to me once telling me how he decided 
>> to try the experiment of taking a BIG program in PL/1 and removing all 
>> the GOTO's (replacing them with things like "Do WHILE ('1') and 
>> such).  After some long (I forget now how long) time, he succeeded.  I 
>> asked him, given the herculean effort it seemed to take, if the effort 
>> was worth it the result?  He couldn't convince me that the resulting 
>> program was necessarily more efficient than the original, nor that all 
>> the changes he had to make produced code that was THAT much better 
>> maintainable than the original.  Maybe it was .. I never saw the code.
>>
> I had a professor like that in college that very strongly encouraged 
> goto less programming.  My experience is that it depends more on how the 
> goto's are used.  I've had to deal with spaghetti code with branches all 
> over the place, flags set/unset to determine where to goto, etc.  My 
> opinoin is the main line/flow code should have the minimal number of 
> goto's depending on the language and the application.  For the most part 
> goto like transfers should be more reserved for exception handling/error 
> reporting.
> 
> I've spent days/weeks untangling spaghetti code to figure out what 
> programs I was maintaining/documenting were trying to do.  One place I 
> worked for 10+ ears, the boss initially complained about the effort I 
> spent undoing spaghetti code (he and a friend wrote the first version of 
> the software) until it started paying off later as the increased ease of 
> maintenance, cleaner code, faster/smaller code (space limited mini 
> computer 56K/user), reduced errors at customer sites, easier fixing 
> problems that did occur at customer sites, etc.  This realy paid off 
> when the Y2K changes had to be done.  I also moved common blocks of 
> inline code to subroutines.  In many cases the 'inline code blocks' were 
> implimented differently by different people in different modules at 
> different times so there could be as many as 50+ different versions of 
> the inline code for something each with different bugs/errors that would 
> show up under various conditions ;)


100% agreement.  I've been trying to advocate this viewpoint for decades. 
GOTO's are not harmful ... in moderation, e.g. staying on the same "page" of code.

DO WHILE (TRUE) and DO FOREVER with "breakouts" are not, repeat, NOT identical 
in logic to label: .... goto label.  When I see "DO WHILE (TRUE)" or "DO 
FOREVER", I immediately think "this code will never be exitted" (the definition 
of "FOREVER" or the *constant* TRUE).  Use of a "small range" GOTO implies 
NOTHING about whether that sequence of code will be exitted or not.  Logically, 
it is clearer.

-- 
H.s.Modell
0
hsmodell (4)
4/26/2006 5:50:55 PM
robin wrote:
> "Howard Modell" <hsmodell@bcstec.ca.boeing.com> wrote in message
> news:IyAFpJ.8sJ@news.boeing.com...

>>One of the things that IBM did in their APL implementation was cause Arrays to
>>use the minimal data storage necessary for the elements.  If you created an
>>array of bits ("memory"), then it occupied exactly the number of bits needed
>> by the dimensions (i.e., an array of 1K bits took up exactly 1K bits).

> As does PL/I.

As far as I know, the language doesn't specify that, though it is a
common implementation.  I believe that Java boolean arrays are often
implemented as one byte per element, though that depends on the JVM
implementation, not the Java compiler.

-- glen

0
gah (12851)
4/28/2006 5:39:30 AM
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:qOSdnXkyvvYTN8zZRVn-qw@comcast.com...
> robin wrote:
> > "Howard Modell" <hsmodell@bcstec.ca.boeing.com> wrote in message
> > news:IyAFpJ.8sJ@news.boeing.com...
>
> >>One of the things that IBM did in their APL implementation was cause Arrays
to
> >>use the minimal data storage necessary for the elements.  If you created an
> >>array of bits ("memory"), then it occupied exactly the number of bits needed
> >> by the dimensions (i.e., an array of 1K bits took up exactly 1K bits).
>
> > As does PL/I.
>
> As far as I know, the language doesn't specify that,

The language has always specified it, that is, since 1966.
The language makes specific provision for it --
    BIT data is UNALIGNED by default.
In this mode, data bits of adjacent elements are placed
adjacent to each other.
    The alternative, when ALIGNED is specified, aligns the
start bit of each element on a storage boundary.

> though it is a common implementation.

It has always been the implementation.


0
robin_v (2737)
4/30/2006 1:46:40 AM
On Sat, 29 Apr 2006 18:46:40 -0700, robin <robin_v@bigpond.com> wrote:

> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
> news:qOSdnXkyvvYTN8zZRVn-qw@comcast.com...
>> robin wrote:
>> > "Howard Modell" <hsmodell@bcstec.ca.boeing.com> wrote in message
>> > news:IyAFpJ.8sJ@news.boeing.com...
>>
>> >>One of the things that IBM did in their APL implementation was cause  
>> Arrays
> to
>> >>use the minimal data storage necessary for the elements.  If you  
>> created an
>> >>array of bits ("memory"), then it occupied exactly the number of bits  
>> needed
>> >> by the dimensions (i.e., an array of 1K bits took up exactly 1K  
>> bits).
>>
>> > As does PL/I.
>>
>> As far as I know, the language doesn't specify that,
>
> The language has always specified it, that is, since 1966.
> The language makes specific provision for it --
>     BIT data is UNALIGNED by default.
> In this mode, data bits of adjacent elements are placed
> adjacent to each other.
>     The alternative, when ALIGNED is specified, aligns the
> start bit of each element on a storage boundary.
>
>> though it is a common implementation.
>
> It has always been the implementation.
>
True, but with the proviso that some padding may occur.

0
tom284 (1839)
4/30/2006 2:10:57 AM
"Tom Linden" <tom@kednos.com> wrote in message
news:op.s8stojy0zgicya@hyrrokkin...
> On Sat, 29 Apr 2006 18:46:40 -0700, robin <robin_v@bigpond.com> wrote:
>
> > "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
> > news:qOSdnXkyvvYTN8zZRVn-qw@comcast.com...
> >> robin wrote:
> >> > "Howard Modell" <hsmodell@bcstec.ca.boeing.com> wrote in message
> >> > news:IyAFpJ.8sJ@news.boeing.com...
> >>
> >> >>One of the things that IBM did in their APL implementation was cause
> >> Arrays
> > to
> >> >>use the minimal data storage necessary for the elements.  If you
> >> created an
> >> >>array of bits ("memory"), then it occupied exactly the number of bits
> >> needed
> >> >> by the dimensions (i.e., an array of 1K bits took up exactly 1K
> >> bits).
> >>
> >> > As does PL/I.
> >>
> >> As far as I know, the language doesn't specify that,
> >
> > The language has always specified it, that is, since 1966.
> > The language makes specific provision for it --
> >     BIT data is UNALIGNED by default.
> > In this mode, data bits of adjacent elements are placed
> > adjacent to each other.
> >     The alternative, when ALIGNED is specified, aligns the
> > start bit of each element on a storage boundary.
> >
> >> though it is a common implementation.
> >
> > It has always been the implementation.
> >
> True, but with the proviso that some padding may occur.

When unaligned is specified, NO padding can occur.
That's the meaning of 'unaligned'.

There might, of course, be padding after the element if the
next storage area is required for a variable that needs alignment on
a byte, halfword/word/doubleword boundary.


0
robin_v (2737)
5/18/2006 9:57:45 AM
"robin" <robin_v@bigpond.com> wrote in message
news:4GU4g.19288$vy1.2146@news-server.bigpond.net.au...
> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
> news:qOSdnXkyvvYTN8zZRVn-qw@comcast.com...
> > robin wrote:
> > > "Howard Modell" <hsmodell@bcstec.ca.boeing.com> wrote in message
> > > news:IyAFpJ.8sJ@news.boeing.com...
> >
> > >>One of the things that IBM did in their APL implementation was cause
Arrays
> to
> > >>use the minimal data storage necessary for the elements.  If you created
an
> > >>array of bits ("memory"), then it occupied exactly the number of bits
needed
> > >> by the dimensions (i.e., an array of 1K bits took up exactly 1K bits).
> >
> > > As does PL/I.
> >
> > As far as I know, the language doesn't specify that,
>
> The language has always specified it, that is, since 1966.
> The language makes specific provision for it --
>     BIT data is UNALIGNED by default.
> In this mode, data bits of adjacent elements are placed
> adjacent to each other.
>     The alternative, when ALIGNED is specified, aligns the
> start bit of each element on a storage boundary.
>
> > though it is a common implementation.
>
> It has always been the implementation.

I have found an implementation that did not
unalign bit data - PL/C. [this was, of course,
an implementation restriction]

However, when record I/O was required in PL/C,
the external form was properly unaligned, if required.
This was to permit files to be written by PL/C
and read back in by PL/I-F, and vice versa.


0
robin_v (2737)
5/18/2006 9:57:46 AM
"robin" <robin_v@bigpond.com> wrote in message 
news:tyXag.6246$S7.4782@news-server.bigpond.net.au...

> When unaligned is specified, NO padding can occur.
> That's the meaning of 'unaligned'.
>
> There might, of course, be padding after the element if the
> next storage area is required for a variable that needs alignment on
> a byte, halfword/word/doubleword boundary.
>
Robin, I really wouldn't have expected you to make such a statement. I know 
PL/I programmers coming from C tend to think that's how PL/I works, but it 
most definitely does not, as the following example demonstrates:

 align:proc options (main reentrant) reorder;
   dcl 1 struc unaligned,
     2 onebit bit (1),
     2 onechar char(1);
   put edit (bitloc (struc.onebit)) (f(2));
 end align;

The output is 7, of course, as there is no padding between the structure 
elements. The fact that the next unaligned element (struc.onechar) needs 
byte alignment does not introduce any padding whatsoever after the previous 
element (struc.onebit). 


0
5/19/2006 6:24:42 AM
Mark Yudkin wrote:

> "robin" <robin_v@bigpond.com> wrote in message 
> news:tyXag.6246$S7.4782@news-server.bigpond.net.au...
> 
> 
>>When unaligned is specified, NO padding can occur.
>>That's the meaning of 'unaligned'.
>>
>>There might, of course, be padding after the element if the
>>next storage area is required for a variable that needs alignment on
>>a byte, halfword/word/doubleword boundary.
>>
> 
> Robin, I really wouldn't have expected you to make such a statement. I know 
> PL/I programmers coming from C tend to think that's how PL/I works, but it 
> most definitely does not, as the following example demonstrates:
> 
>  align:proc options (main reentrant) reorder;
>    dcl 1 struc unaligned,
>      2 onebit bit (1),
>      2 onechar char(1);
>    put edit (bitloc (struc.onebit)) (f(2));
>  end align;
> 
> The output is 7, of course, as there is no padding between the structure 
> elements. The fact that the next unaligned element (struc.onechar) needs 
> byte alignment does not introduce any padding whatsoever after the previous 
> element (struc.onebit). 
> 
> 

I believe this is not true for non "Enterprise" PL/I's.  I don't have a 
compiler handy to check just now.

0
Peter_Flass (956)
5/19/2006 10:12:13 PM
Struture alignment rules are part of the language definition. Any compiler 
not yielding the same result is faulty, as it would make it impossible to 
interchange files.

"Peter Flass" <Peter_Flass@Yahoo.com> wrote in message 
news:1prbg.249$W97.168@twister.nyroc.rr.com...
> Mark Yudkin wrote:
>
>> "robin" <robin_v@bigpond.com> wrote in message 
>> news:tyXag.6246$S7.4782@news-server.bigpond.net.au...
>>
>>
>>>When unaligned is specified, NO padding can occur.
>>>That's the meaning of 'unaligned'.
>>>
>>>There might, of course, be padding after the element if the
>>>next storage area is required for a variable that needs alignment on
>>>a byte, halfword/word/doubleword boundary.
>>>
>>
>> Robin, I really wouldn't have expected you to make such a statement. I 
>> know PL/I programmers coming from C tend to think that's how PL/I works, 
>> but it most definitely does not, as the following example demonstrates:
>>
>>  align:proc options (main reentrant) reorder;
>>    dcl 1 struc unaligned,
>>      2 onebit bit (1),
>>      2 onechar char(1);
>>    put edit (bitloc (struc.onebit)) (f(2));
>>  end align;
>>
>> The output is 7, of course, as there is no padding between the structure 
>> elements. The fact that the next unaligned element (struc.onechar) needs 
>> byte alignment does not introduce any padding whatsoever after the 
>> previous element (struc.onebit).
>
> I believe this is not true for non "Enterprise" PL/I's.  I don't have a 
> compiler handy to check just now.
> 


0
5/21/2006 8:46:10 AM
Mark Yudkin wrote:
> Struture alignment rules are part of the language definition. Any compiler 
> not yielding the same result is faulty, as it would make it impossible to 
> interchange files.
> 
> "Peter Flass" <Peter_Flass@Yahoo.com> wrote in message 
> news:1prbg.249$W97.168@twister.nyroc.rr.com...
> 
>>Mark Yudkin wrote:
>>
>>
>>>"robin" <robin_v@bigpond.com> wrote in message 
>>>news:tyXag.6246$S7.4782@news-server.bigpond.net.au...
>>>
>>>
>>>
>>>>When unaligned is specified, NO padding can occur.
>>>>That's the meaning of 'unaligned'.
>>>>
>>>>There might, of course, be padding after the element if the
>>>>next storage area is required for a variable that needs alignment on
>>>>a byte, halfword/word/doubleword boundary.
>>>>
>>>
>>>Robin, I really wouldn't have expected you to make such a statement. I 
>>>know PL/I programmers coming from C tend to think that's how PL/I works, 
>>>but it most definitely does not, as the following example demonstrates:
>>>
>>> align:proc options (main reentrant) reorder;
>>>   dcl 1 struc unaligned,
>>>     2 onebit bit (1),
>>>     2 onechar char(1);
>>>   put edit (bitloc (struc.onebit)) (f(2));
>>> end align;
>>>
>>>The output is 7, of course, as there is no padding between the structure 
>>>elements. The fact that the next unaligned element (struc.onechar) needs 
>>>byte alignment does not introduce any padding whatsoever after the 
>>>previous element (struc.onebit).
>>
>>I believe this is not true for non "Enterprise" PL/I's.  I don't have a 
>>compiler handy to check just now.
>>
> 

Thankfully, the compilers I'm familiar with don't do this.  UNALIGNED 
non-bit data is always aligned on a byte boundary.  Notice that the 
compiler identifies "DWD below as UNALIGNED, but inserts the padding bits.

10H7848 IBM PL/I for OS/2         V1.R1      2006.05.21  12:12:00   Page 
1
  Line.File 


             /* TEST */
     2.1     test: proc options(main);
     3.1       dcl 1 struc unaligned,
                     2 bits bit(1),
                     2 dwd  fixed bin(31);
     6.1       end test;


10H7848 IBM PL/I for OS/2         V1.R1      2006.05.21  12:12:00   Page 
2


                    Attribute/Xref Table


     Line.File Identifier                      Attributes

        4.1    BITS                            MEMBER IN STRUC BIT(1) 
UNALIGNED
        5.1    DWD                             MEMBER IN STRUC FIXED 
BIN(31,0)
                                               UNALIGNED
        3.1    STRUC                           STRUCTURE AUTOMATIC
        2.1    TEST                            CONSTANT EXTERNAL
                                               ENTRY()


10H7848 IBM PL/I for OS/2         V1.R1      2006.05.21  12:12:00   Page 
3


                    Aggregate Length Table

                                   Total         Base
     Line.File         Offset       Size         Size  Identifier


        3.1               0            5               STRUC
                          0         0(7)                 /* padding */
                       0(7)         0(1)                 BITS
                          1            4                 DWD

10H7848 IBM PL/I for OS/2         V1.R1      2006.05.21  12:12:00   Page 
4


File Reference Table

   File    Included From  Name

      1                   C:\pli\test.pli


Component    Return Code    Messages (Total/Suppressed)    Time

MACRO            0                0  /  0                   1 secs
Compiler         0                0  /  0                   6 secs

End of compilation of TEST

0
Peter_Flass (956)
5/21/2006 4:27:55 PM
Peter Flass wrote:
> Mark Yudkin wrote:
> 
>> Struture alignment rules are part of the language definition. Any 
>> compiler not yielding the same result is faulty, as it would make it 
>> impossible to interchange files.
>>

....

>>>> The output is 7, of course, as there is no padding between the 
>>>> structure elements. The fact that the next unaligned element 
>>>> (struc.onechar) needs byte alignment does not introduce any padding 
>>>> whatsoever after the previous element (struc.onebit).
>>>
>>>
>>> I believe this is not true for non "Enterprise" PL/I's.  I don't have 
>>> a compiler handy to check just now.
>>>
>>
> 
> Thankfully, the compilers I'm familiar with don't do this.  UNALIGNED 
> non-bit data is always aligned on a byte boundary.  Notice that the 
> compiler identifies "DWD below as UNALIGNED, but inserts the padding bits.
> 
> 10H7848 IBM PL/I for OS/2         V1.R1      2006.05.21  12:12:00   Page 1
>  Line.File
> 
>             /* TEST */
>     2.1     test: proc options(main);
>     3.1       dcl 1 struc unaligned,
>                     2 bits bit(1),
>                     2 dwd  fixed bin(31);
>     6.1       end test;
> 

....

> 
>                                   Total         Base
>     Line.File         Offset       Size         Size  Identifier
> 
> 
>        3.1               0            5               STRUC
>                          0         0(7)                 /* padding */
>                       0(7)         0(1)                 BITS
>                          1            4                 DWD
> 

The padding is not within the structure.  The structure begins at byte 0 bit 7.

But try this example:

     2.1            test: proc options(main);
     3.1     1       dcl
                      1 struc unaligned,
                       2 bit bit(1),
                       2 dwd fixed bin(31),
                       2 wd bin fixed(15),
                       2 bit2 bit(1),
                       2 dwd2 bin fixed(31);
    10.1     1       end test;

                                   Total         Base
     Line.File         Offset       Size         Size  Identifier


        4.1               0           12              STRUC
                          0         0(7)                 /* padding */
                       0(7)         0(1)               BIT
                          1            4               DWD
                          5            2               WD
                          7         0(1)               BIT2
                       7(1)         0(7)                 /* padding */
                          8            4               DWD2

Notice that bit2 is located at bit 0 of byte 7 and the padding that follows it 
it perforce within the structure.

An aligned bit string always begins at bit 0 of the "next available" byte, an 
unalligned bit string begins at the "next available" bit.

An aligned variable of type other than bit begins at the "next available" byte 
of the required alignment; an unaligned variable of type other bit begins at the 
"next available" byte.

"Next available" is in quotes because it isn't always literally true and there 
is no short description or obvious name for the byte that the structure mapping 
rules choose.  The first bit is an example; whenever padding can be moved from 
within a structure to outside it by shifting one or more items to the right, 
PL/I does that.

Here's another illustration:

     2.1            test: proc options(main);
     3.1     1       dcl
                      1 struc unaligned,
                       2 bit bit(1),
                       2 dwd fixed bin(31),
                       2 wd bin fixed(15),
                       2 minor,
                        3 bit2 bit(1),
                        3 dwd2 bin fixed(31);
    11.1     1       end test;

                                   Total         Base
     Line.File         Offset       Size         Size  Identifier


        4.1               0           12              STRUC
                          0         0(7)                 /* padding */
                       0(7)         0(1)               BIT
                          1            4               DWD
                          5            2               WD
                          7         0(7)                 /* padding */
                       7(7)         4(1)               MINOR
                       7(7)         0(1)                BIT2
                          8            4                DWD2

bit2 now starts at byte 7 bit 7 so that the padding is outside the minor 
structure.  Of course there is no way to move it outside the major structure -- 
You can't have everything.
0
jjw (608)
5/21/2006 7:36:45 PM
On Sun, 21 May 2006 12:36:45 -0700, James J. Weinkam <jjw@cs.sfu.ca> wrote:

> Peter Flass wrote:
>> Mark Yudkin wrote:
>>
>>> Struture alignment rules are part of the language definition. Any  
>>> compiler not yielding the same result is faulty, as it would make it  
>>> impossible to interchange files.
>>>
>
> ...
>
>>>>> The output is 7, of course, as there is no padding between the  
>>>>> structure elements. The fact that the next unaligned element  
>>>>> (struc.onechar) needs byte alignment does not introduce any padding  
>>>>> whatsoever after the previous element (struc.onebit).
>>>>
>>>>
>>>> I believe this is not true for non "Enterprise" PL/I's.  I don't have  
>>>> a compiler handy to check just now.
>>>>
>>>
>>  Thankfully, the compilers I'm familiar with don't do this.  UNALIGNED  
>> non-bit data is always aligned on a byte boundary.  Notice that the  
>> compiler identifies "DWD below as UNALIGNED, but inserts the padding  
>> bits.
>>  10H7848 IBM PL/I for OS/2         V1.R1      2006.05.21  12:12:00    
>> Page 1
>>  Line.File
>>              /* TEST */
>>     2.1     test: proc options(main);
>>     3.1       dcl 1 struc unaligned,
>>                     2 bits bit(1),
>>                     2 dwd  fixed bin(31);
>>     6.1       end test;
>>
>
> ...
>
>> 
>>                                   Total         Base
>>     Line.File         Offset       Size         Size  Identifier
>>          3.1               0            5               STRUC
>>                          0         0(7)                 /* padding */
>>                       0(7)         0(1)                 BITS
>>                          1            4                 DWD
>> 
>
> The padding is not within the structure.  The structure begins at byte 0  
> bit 7.
>
> But try this example:
>
>      2.1            test: proc options(main);
>      3.1     1       dcl
>                       1 struc unaligned,
>                        2 bit bit(1),
>                        2 dwd fixed bin(31),
>                        2 wd bin fixed(15),
>                        2 bit2 bit(1),
>                        2 dwd2 bin fixed(31);
>     10.1     1       end test;
>
>                                    Total         Base
>      Line.File         Offset       Size         Size  Identifier
>
>
>         4.1               0           12              STRUC
>                           0         0(7)                 /* padding */
>                        0(7)         0(1)               BIT
>                           1            4               DWD
>                           5            2               WD
>                           7         0(1)               BIT2
>                        7(1)         0(7)                 /* padding */
>                           8            4               DWD2
>
> Notice that bit2 is located at bit 0 of byte 7 and the padding that  
> follows it it perforce within the structure.
>
> An aligned bit string always begins at bit 0 of the "next available"  
> byte, an unalligned bit string begins at the "next available" bit.
>
> An aligned variable of type other than bit begins at the "next  
> available" byte of the required alignment; an unaligned variable of type  
> other bit begins at the "next available" byte.
>
> "Next available" is in quotes because it isn't always literally true and  
> there is no short description or obvious name for the byte that the  
> structure mapping rules choose.  The first bit is an example; whenever  
> padding can be moved from within a structure to outside it by shifting  
> one or more items to the right, PL/I does that.
>
> Here's another illustration:
>
>      2.1            test: proc options(main);
>      3.1     1       dcl
>                       1 struc unaligned,
>                        2 bit bit(1),
>                        2 dwd fixed bin(31),
>                        2 wd bin fixed(15),
>                        2 minor,
>                         3 bit2 bit(1),
>                         3 dwd2 bin fixed(31);
>     11.1     1       end test;
>
>                                    Total         Base
>      Line.File         Offset       Size         Size  Identifier
>
>
>         4.1               0           12              STRUC
>                           0         0(7)                 /* padding */
>                        0(7)         0(1)               BIT
>                           1            4               DWD
>                           5            2               WD
>                           7         0(7)                 /* padding */
>                        7(7)         4(1)               MINOR
>                        7(7)         0(1)                BIT2
>                           8            4                DWD2
>
> bit2 now starts at byte 7 bit 7 so that the padding is outside the minor  
> structure.  Of course there is no way to move it outside the major  
> structure -- You can't have everything.

And this agrees with what we do under OpenVMS (VAX here)

HHERMES> more bitpad.lis

TEST                                                             
21-MAY-2006 16:31:27    VAX Kednos V3.7-004                 Page 1
01                                                               
21-MAY-2006 16:28:58    [USER.TOM.VAXTMP]BITPAD.PLI;1 (1)



     1           test: proc options(main);
     2    1      dcl
     3    1                           1 struc unaligned,
     4    1                            2 bit bit(1),
     5    1                            2 dwd fixed bin(31),
     6    1                            2 wd bin fixed(15),
     7    1                            2 bit2 bit(1),
     8    1                            2 dwd2 bin fixed(31);
     9    1      end test;
%PLIG-I-NOMSG, Message number 010B802B

Press RETURN to continue



TEST                                                             
21-MAY-2006 16:31:27    VAX Kednos V3.7-004                 Page 2
01                                                               
21-MAY-2006 16:28:58    [USER.TOM.VAXTMP]BITPAD.PLI;1 (1)

                                 +-------------+
                                 | Storage Map |
                                 +-------------+


External Entry Points and Variables Declared Outside Procedures
---------------------------------------------------------------

  Identifier Name                 Storage     Size     Line  Attributes
  ---------- ----                 -------     ----     ----  ----------


  TEST                                                 1     ENTRY, EXTERNAL


Procedure TEST on line 1
Press RETURN to continue

------------------------

  Identifier Name                 Storage     Size     Line  Attributes
  ---------- ----                 -------     ----     ----  ----------


  BIT                                         1 BI     4     OFFSET FROM  
BASE IS 0 BY, MEMBER OF STRUCTURE STRUC, BIT(1), UNALIGNED
                                                             NONVARYING

  BIT2                                        1 BI     7     OFFSET FROM  
BASE IS 7 BY, MEMBER OF STRUCTURE STRUC, BIT(1), UNALIGNED
                                                             NONVARYING

  DWD                                         4 BY     5     OFFSET FROM  
BASE IS 1 BY, MEMBER OF STRUCTURE STRUC, FIXED BIN(31,0)
                                                             ALIGNED,  
PRECISION

  DWD2                                        4 BY     8     OFFSET FROM  
BASE IS 8 BY, MEMBER OF STRUCTURE STRUC, FIXED BIN(31,0)
                                                             ALIGNED,  
PRECISION

  STRUC                           automatic   12 BY    3     STRUCTURE

  WD                                          2 BY     6     OFFSET FROM  
BASE IS 5 BY, MEMBER OF STRUCTURE STRUC, FIXED BIN(15,0)
Press RETURN to continue

                                                             ALIGNED,  
PRECISION


Psect Synopsis
----- --------

  Psect Name                     Allocation  Attributes
  ----- ----                     ----------  ----------

  $CODE                          0 by        position-independent,  
relocatable, share, execute, read
  $DATA                          0 by        position-independent,  
relocatable, read, write
  $ADDRESS_DATA                  0 by        position-independent,  
relocatable, read

TEST                                                             
21-MAY-2006 16:31:27    VAX Kednos V3.7-004                 Page 3
01                                                               
21-MAY-2006 16:28:58    [USER.TOM.VAXTMP]BITPAD.PLI;1 (1)


Procedure Definition Map
--------- ---------- ---

  Line    Name
Press RETURN to continue

  ----    ----

  1       TEST

  COMMAND LINE
  ------- ----

PLI/LIST/SHOW=MAP BITPAD

HERMES>


0
tom284 (1839)
5/21/2006 11:47:06 PM
Tom Linden wrote:
> On Sun, 21 May 2006 12:36:45 -0700, James J. Weinkam <jjw@cs.sfu.ca> wrote:
> 
>> Peter Flass wrote:
>>
>>> Mark Yudkin wrote:
>>>
>>>> Struture alignment rules are part of the language definition. Any  
>>>> compiler not yielding the same result is faulty, as it would make 
>>>> it  impossible to interchange files.
>>>>
>>
>> ...
>>
> 
> And this agrees with what we do under OpenVMS (VAX here)
> ...

Actually, this is very well-defined.  The IBM manuals have about 2-3 
pages describing the mapping algorithm.  Off-hand, I don't know what the 
standard has, but I doubt if it's less.  I thought the OP was trying to 
say that if you had:
dcl 1 s unaligned, 2 b bit(1), 2 f fixed bin(31);
that f would start at bit(2) of the first byte, which is of course 
nonsense, and not what he was saying at all..

0
Peter_Flass (956)
5/22/2006 9:53:55 PM
Mark Yudkin wrote:

> Struture alignment rules are part of the language definition. Any compiler 
> not yielding the same result is faulty, as it would make it impossible to 
> interchange files.

I might believe that for BIT variables, but it is hard to believe for 
anything else.  The actual size of variables is implementation 
dependent, so the alignment pretty much has to be, also.

If I say

DCL 1 S 2 B BIT(1) 2 F FIXED BIN(14);

I might expect the 15 bit (with sign) F to come immediately after the 
one bit S, but on most implementations F will be rounded up to a 
convenient width such as 16 or 32 on a byte addressable machine.

On a 36 bit machine, such as the PDP-10, FIXED BIN(14) might be
36 or 18 bits wide.

Non-BIT variables could easily have different widths and different 
alignment on different implementations.

-- glen

0
gah (12851)
5/22/2006 10:28:20 PM
"Tom Linden" <tom@kednos.com> wrote in message
news:op.s8djusvzzgicya@hyrrokkin...
> On Fri, 21 Apr 2006 08:21:41 -0700, robin <robin_v@bigpond.com> wrote:
>
> > "Tom Linden" <tom@kednos.com> wrote in message
> > news:op.s8bem1tdzgicya@hyrrokkin...
> >> On Wed, 19 Apr 2006 19:52:30 -0700, robin <robin_v@bigpond.com> wrote:
> >>
> >> > "Tom Linden" <tom@kednos.com> wrote in message
> >> > news:op.s79btornzgicya@hyrrokkin...
> >> >> On Tue, 18 Apr 2006 23:33:59 -0700, <adaworks@sbcglobal.net> wrote:
> >> >>
> >> >> > Information hiding and encapsulation have proven their value in the
> >> >> > simple
> >> >> > sense of building well-protected modules -- object-oriented or not.
> >> >> This
> >> >> > idea helps support the concepts of high-cohesion and low-coupling.
> >> >>
> >> >> <SOAPBOX>
> >> >> One of the things that bothers me about CS academia is the
> >> >> indiscriminate
> >> >> proliferation of nomenclature under the mistaken view that putting a
> >> >> name
> >> >> on something is knowledge. Are high-cohesion and low-coupling
> >> >> quantifiable
> >> >> parameters?  I think not, and are better avoided.  I do have a
> >> similar
> >> >> distaste
> >> >> for ad hoc extensions to any language particularly one as well
> >> defined
> >> >> as
> >> >> X3.53,
> >> >> Extensions aren't bad, and indeed may be a very good thing,  but they
> >> >> should be
> >> >> thought out in the context of the describing mechanism of the
> >> language
> >> >> itself.
> >> >> So, for example,  suppose you want to add the keyword FOREVER to
> >> PL/I,
> >> >> you
> >> >> ask
> >> >> yourself, what added functionality does it provide, and the answer is
> >> >> none,
> >> >
> >> > DO FOREVER is absolutely clear and unambiguous.
> >> > It's far better than DO WHILE ('1'B); can be understood by
> >> > anyone, and requires fewer characters.  It's also better than
> >> > GO TO.
> >>
> >> I think you missed the point, or perhaps I din't express myself well.
> >
> > I didn't miss the point.  The point is that an infinite loop came
> > into vogue with structured programming.  GO TO was out.
>
> You did.  That is irrelevant to this discussion.

It's directly relevant.
And I did not miss your point.

> > DO WHILE ('1'B);
> > wasn't a particularly convenient way to express an infinite loop,
> > for the reason that I gave earlier, namely, that it wasn't clear
> > to everyone what it meant.  You could easily make a typo with it
> > (e.g., omit an apostrophe) which just wastes time.
>
> Not convenient?  Come on, we've got bigger fish to fry.
> so type, DO WHILE(1);

Not only is that inefficient, it would elicit a compiler message.

DO FOREVER is absolutely clear and unambiguous.

That's why it's preferred, even if you don't like it.

>  BTW, I have trained many PL/I programmers and
> have never found that this was a confusing construct
>
> You are reaching for straws in your ever present need to have the last
> word.

Don't be absurd.

> >> FOREVER adds no functioanlity to the language other than creating a
> >> synonym of sorts.  The parser doen't need to be extended to support it
> >
> > To an extent, that's true, but then you lose the requirement that
> > no words are reserved, and once 'FOREVER' or any other
> > such word is set up that way, it cannot be used as an identifier.
>
> Pursuing that argument you should forgo using the macroprocessor
> because it would reserve tokens.

That's irrelevant.
Introducing a word for the preprocessor associates a user-defined
meaning with it.

> >> If you prefer such a locution then use the preprocessor
> >> HAFNER> create pp.pli
> >> t: proc options(main);
> >> %replace TRUE by '1'B;
> >> %dcl forever char;
> >> %forever = 'while(TRUE)';

I think that you get no support for that line.

DO FOREVER requires no messing around,
and doesn't have to be re-implemented every time
you use it.

> > You shouldn't need to do all that just to have a clear construct
> > for an infinite loop.
> Apparently what is clear to one person is not to another.
> >
> > DO FOREVER;
> >
> > is such a construct, and it's unequivically clear.
> >
> >> do forever;
> >>   put skip list('hello');
> >>   leave;
> >>   end;
> >> end t;
> >> *EXIT*
> >> HAFNER> pli pp
> >> HAFNER> lin pp
> >> HAFNER> run pp
> >>
> >> hello
> >>
> >> >
> >> >>  Is it
> >> >> a useful locution, maybe, can it be done otherwise, yes, gone.
> >> >
> >> > One could dispense with many constucts in any language.
> >> >     Don't need complex, don't need decimal, don't need character,
> >> > don't need floating-point, etc.  Just need integer.
> >>
> >> That is a non sequitur and irrelvant.
> >
> > It's directly relevant.  You're saying that FOREVER
> > is unnecessary duplication.
>
> No, it is not relevant.  Saying that FOREVER is gratuitous is not the same
> as
> saying that you don't need other features of the language, such as those
> you listed.
>
> > Removing every duplicated facility would make
> > the language tiny - any language.
>
> I am not in favour of removing features from the language and am indeed in
> favour
> of adding functionality that makes sense, and have in fact done so, such
> as certain
> features for systems programming.  Removing duplicate features, would not
> make the language any smaller, since they are duplicates.

That's an oxymoron.

> More than one person has commented on the fact that PL/I is a large
> language and
> can therefore be intimidating to the novice.  Adding new keywords doesn't
> help.

Various subsets have been defined for the novice,
perhaps the best-known are the sp/k series.

> Do you like UPTHRU?

How is that relevant?

(BTW UPTHRU enables a loop to run to 32767 and 2147483647 etc
without raising SIZE or FIXEDOVERFLOW.)



0
robin_v (2737)
5/22/2006 11:47:31 PM
robin wrote:
.... various others quoted here ...
>>>>FOREVER adds no functioanlity to the language other than creating a
>>>>synonym of sorts.  The parser doen't need to be extended to support it
>>>
>>>To an extent, that's true, but then you lose the requirement that
>>>no words are reserved, and once 'FOREVER' or any other
>>>such word is set up that way, it cannot be used as an identifier.
> you use it.

I've mostly avoided this discussion, but FOREVER in this context is a 
keyword like any other PL/I keyword and need no be reserved.  If the 
syntax was "DO WHILE(FOREVER);" you'd have a problem.

>>Do you like UPTHRU?
Having just implemented DO ...BY <expression> when the <expression> is 
not a constant, I can see where UPTHRU and DOWNTHRU can save a fair 
amount of code.  If the programmer knows which way the loop is running 
(as s/he usually does) this keeps the compiler from having to check the 
sign of the BY expression each time thru the loop to determine  which of 
two jump instructions to execute to exit the loop.

0
Peter_Flass (956)
5/23/2006 10:30:03 AM
On Tue, 23 May 2006 03:30:03 -0700, Peter Flass <Peter_Flass@Yahoo.com>  
wrote:

> Having just implemented DO ...BY <expression> when the <expression> is  
> not a constant, I can see where UPTHRU and DOWNTHRU can save a fair  
> amount of code.  If the programmer knows which way the loop is running  
> (as s/he usually does)
>  this keeps the compiler from having to check the sign of the BY  
> expression each time thru the loop to determine  which of two jump  
> instructions to execute to exit the loop.

Not a problem most of it disappears in optimization phase anyway, as tests
are moved to loop bottom.  In some ways this is counter to the original
philosophy of PL/I as a high-level language not bothering the programmer
with such mundane tasks.  You need, of course, to parse BY <expr>

Adding synonyms and similar locutions doesn't improve the language and
is a convenience best left to the programmer, that's my view, and you
can't change it:-)
0
tom284 (1839)
5/23/2006 2:27:31 PM
Peter Flass wrote:

(snip)

> Having just implemented DO ...BY <expression> when the <expression> is 
> not a constant, I can see where UPTHRU and DOWNTHRU can save a fair 
> amount of code.  If the programmer knows which way the loop is running 
> (as s/he usually does) this keeps the compiler from having to check the 
> sign of the BY expression each time thru the loop to determine  which of 
> two jump instructions to execute to exit the loop.

In the case of variable BY where the programmer knows the sign but the
compiler doesn't, I wonder if ABS() would help.  Would the optimizer
then figure out the sign?

DO I=J TO K BY ABS(L);

-- glen

0
gah (12851)
5/23/2006 6:13:52 PM
On Tue, 23 May 2006 11:13:52 -0700, glen herrmannsfeldt  
<gah@ugcs.caltech.edu> wrote:

> Peter Flass wrote:
>
> (snip)
>
>> Having just implemented DO ...BY <expression> when the <expression> is  
>> not a constant, I can see where UPTHRU and DOWNTHRU can save a fair  
>> amount of code.  If the programmer knows which way the loop is running  
>> (as s/he usually does) this keeps the compiler from having to check the  
>> sign of the BY expression each time thru the loop to determine  which  
>> of two jump instructions to execute to exit the loop.
>
> In the case of variable BY where the programmer knows the sign but the
> compiler doesn't, I wonder if ABS() would help.  Would the optimizer
> then figure out the sign?

It might, it would be a special case.  But actually, I have found many  
loops
of this type the induction variable becomes replaced by a shadow variable
representing, for example and address and the increment is some offset into
for example a mult-dimensional array
>
> DO I=J TO K BY ABS(L);
>
> -- glen
>

0
tom284 (1839)
5/23/2006 6:35:35 PM
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:3uSdnRKCqP1eze7ZRVn-tg@comcast.com...
> Peter Flass wrote:

> > Having just implemented DO ...BY <expression> when the <expression> is
> > not a constant, I can see where UPTHRU and DOWNTHRU can save a fair
> > amount of code.  If the programmer knows which way the loop is running
> > (as s/he usually does) this keeps the compiler from having to check the
> > sign of the BY expression each time thru the loop to determine  which of
> > two jump instructions to execute to exit the loop.
>
> In the case of variable BY where the programmer knows the sign but the
> compiler doesn't, I wonder if ABS() would help.  Would the optimizer
> then figure out the sign?
>
> DO I=J TO K BY ABS(L);

The compiler knows the sign.  It doesn't need an optimizer
to figure that out.


0
robin_v (2737)
5/24/2006 1:14:29 AM
"Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
news:LuBcg.1168$W97.66@twister.nyroc.rr.com...

> Having just implemented DO ...BY <expression> when the <expression> is
> not a constant, I can see where UPTHRU and DOWNTHRU can save a fair
> amount of code.  If the programmer knows which way the loop is running
> (as s/he usually does) this keeps the compiler from having to check the
> sign of the BY expression each time thru the loop to determine  which of
> two jump instructions to execute to exit the loop.

It isn't necessary to do that.

The sign of the increment can be tested before the loop is entered.
A branch at the end of the loop can use an index register
that has been loaded with an appropriate value
to enable the branch instruction to pick up the relevant
increment/decrement and test.




0
robin_v (2737)
5/24/2006 1:14:30 AM
Peter Flass wrote:

(snip)

> Having just implemented DO ...BY <expression> when the <expression> is 
> not a constant, I can see where UPTHRU and DOWNTHRU can save a fair 
> amount of code.  If the programmer knows which way the loop is running 
> (as s/he usually does) this keeps the compiler from having to check the 
> sign of the BY expression each time thru the loop to determine  which of 
> two jump instructions to execute to exit the loop.

According to IBM's OS PL/I version 2, SC26-4308-02, the values for BY 
and TO are saved at the beginning of the loop, and used subsequently.
That would seem to indicate that the sign should not be checked each 
time, but only once.

-- glen

0
gah (12851)
5/24/2006 2:06:24 AM
On Tue, 23 May 2006 19:06:24 -0700, glen herrmannsfeldt  
<gah@ugcs.caltech.edu> wrote:

> Peter Flass wrote:
>
> (snip)
>
>> Having just implemented DO ...BY <expression> when the <expression> is  
>> not a constant, I can see where UPTHRU and DOWNTHRU can save a fair  
>> amount of code.  If the programmer knows which way the loop is running  
>> (as s/he usually does) this keeps the compiler from having to check the  
>> sign of the BY expression each time thru the loop to determine  which  
>> of two jump instructions to execute to exit the loop.
>
> According to IBM's OS PL/I version 2, SC26-4308-02, the values for BY  
> and TO are saved at the beginning of the loop, and used subsequently.
> That would seem to indicate that the sign should not be checked each  
> time, but only once.
Generally the way it is done (correctly) is a test outside the loop entry
and the remainder of the tests at the bottom of the loop
>
> -- glen
>

0
tom284 (1839)
5/24/2006 2:15:38 AM
robin wrote:
> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
> news:3uSdnRKCqP1eze7ZRVn-tg@comcast.com...
> 
>>Peter Flass wrote:
> 
> 
>>>Having just implemented DO ...BY <expression> when the <expression> is
>>>not a constant, I can see where UPTHRU and DOWNTHRU can save a fair
>>>amount of code.  If the programmer knows which way the loop is running
>>>(as s/he usually does) this keeps the compiler from having to check the
>>>sign of the BY expression each time thru the loop to determine  which of
>>>two jump instructions to execute to exit the loop.
>>
>>In the case of variable BY where the programmer knows the sign but the
>>compiler doesn't, I wonder if ABS() would help.  Would the optimizer
>>then figure out the sign?
>>
>>DO I=J TO K BY ABS(L);
> 
> 
> The compiler knows the sign.  It doesn't need an optimizer
> to figure that out.
> 
> 
Everybody seems to have missed the point here.

If the increment (L) is negative, using ABS(L) makes it positive which is wrong, 
full stop.  Nothing good can come from this.
0
jjw (608)
5/24/2006 5:03:53 AM
"James J. Weinkam" <jjw@cs.sfu.ca> wrote in message
news:ZORcg.28078$Fl1.16795@edtnps89...
> robin wrote:
> > "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
> > news:3uSdnRKCqP1eze7ZRVn-tg@comcast.com...
> >
> >>Peter Flass wrote:
>
> >>>Having just implemented DO ...BY <expression> when the <expression> is
> >>>not a constant, I can see where UPTHRU and DOWNTHRU can save a fair
> >>>amount of code.  If the programmer knows which way the loop is running
> >>>(as s/he usually does) this keeps the compiler from having to check the
> >>>sign of the BY expression each time thru the loop to determine  which of
> >>>two jump instructions to execute to exit the loop.
> >>
> >>In the case of variable BY where the programmer knows the sign but the
> >>compiler doesn't, I wonder if ABS() would help.  Would the optimizer
> >>then figure out the sign?
> >>
> >>DO I=J TO K BY ABS(L);
> >
> > The compiler knows the sign.  It doesn't need an optimizer
> > to figure that out.
>
> Everybody seems to have missed the point here.

Nobody has missed the point.

> If the increment (L) is negative, using ABS(L) makes it positive which is
wrong,
> full stop.  Nothing good can come from this.

Try:
    DO I=J TO K BY -ABS(L);

when it is known that the increment is negative
(Glen assumed that we could put 2 + 2 together).
But there is no need for that.
The compiler can test the sign before loop entry,
if required.
But there is no need for that either.
(refer previous post)



0
robin_v (2737)
5/24/2006 2:50:25 PM
"Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
news:LuBcg.1168$W97.66@twister.nyroc.rr.com...

> Having just implemented DO ...BY <expression> when the <expression> is
> not a constant, I can see where UPTHRU and DOWNTHRU can save a fair
> amount of code.

A couple of instructions, at most.
Not a "fair amount of code".


0
robin_v (2737)
5/24/2006 2:50:26 PM
"Tom Linden" <tom@kednos.com> wrote in message
news:op.s909wcfxzgicya@hyrrokkin...
> On Tue, 23 May 2006 19:06:24 -0700, glen herrmannsfeldt
> <gah@ugcs.caltech.edu> wrote:
>
> > According to IBM's OS PL/I version 2, SC26-4308-02, the values for BY
> > and TO are saved at the beginning of the loop, and used subsequently.
> > That would seem to indicate that the sign should not be checked each
> > time, but only once.

> Generally the way it is done (correctly) is a test outside the loop entry
> and the remainder of the tests at the bottom of the loop

While one might have a test before entering the loop,
a more typical bare bones implementation does not need a test prior,
but would include a test within the loop.
    However, no test is required to deal with a negative increment.


0
robin_v (2737)
5/24/2006 2:50:26 PM
"Mark Yudkin" <myudkinATcompuserveDOTcom@boingboing.org> wrote in message
news:446d6489$0$31935$5402220f@news.sunrise.ch...
> "robin" <robin_v@bigpond.com> wrote in message
> news:tyXag.6246$S7.4782@news-server.bigpond.net.au...
>
> > When unaligned is specified, NO padding can occur.
> > That's the meaning of 'unaligned'.
> >
> > There might, of course, be padding after the element if the
> > next storage area is required for a variable that needs alignment on
> > a byte, halfword/word/doubleword boundary.
> >
> Robin, I really wouldn't have expected you to make such a statement. I know
> PL/I programmers coming from C tend to think that's how PL/I works, but it
> most definitely does not, as the following example demonstrates:

>  align:proc options (main reentrant) reorder;
>    dcl 1 struc unaligned,
>      2 onebit bit (1),
>      2 onechar char(1);
>    put edit (bitloc (struc.onebit)) (f(2));
>  end align;

That's a special case, of course, when the bit string
heads the structure or minor structure.
In general, however, padding follows the bit string to the next
appropriate boundary.



0
robin_v (2737)
5/24/2006 2:50:27 PM
What are we arguing about? Your listing also shows that the padding precedes 
the bit. It's only Robin who's got it wrong.

"Peter Flass" <Peter_Flass@Yahoo.com> wrote in message 
news:fy0cg.361$W97.40@twister.nyroc.rr.com...
> Mark Yudkin wrote:
>> Struture alignment rules are part of the language definition. Any 
>> compiler not yielding the same result is faulty, as it would make it 
>> impossible to interchange files.
>>
>> "Peter Flass" <Peter_Flass@Yahoo.com> wrote in message 
>> news:1prbg.249$W97.168@twister.nyroc.rr.com...
>>
>>>Mark Yudkin wrote:
>>>
>>>
>>>>"robin" <robin_v@bigpond.com> wrote in message 
>>>>news:tyXag.6246$S7.4782@news-server.bigpond.net.au...
>>>>
>>>>
>>>>
>>>>>When unaligned is specified, NO padding can occur.
>>>>>That's the meaning of 'unaligned'.
>>>>>
>>>>>There might, of course, be padding after the element if the
>>>>>next storage area is required for a variable that needs alignment on
>>>>>a byte, halfword/word/doubleword boundary.
>>>>>
>>>>
>>>>Robin, I really wouldn't have expected you to make such a statement. I 
>>>>know PL/I programmers coming from C tend to think that's how PL/I works, 
>>>>but it most definitely does not, as the following example demonstrates:
>>>>
>>>> align:proc options (main reentrant) reorder;
>>>>   dcl 1 struc unaligned,
>>>>     2 onebit bit (1),
>>>>     2 onechar char(1);
>>>>   put edit (bitloc (struc.onebit)) (f(2));
>>>> end align;
>>>>
>>>>The output is 7, of course, as there is no padding between the structure 
>>>>elements. The fact that the next unaligned element (struc.onechar) needs 
>>>>byte alignment does not introduce any padding whatsoever after the 
>>>>previous element (struc.onebit).
>>>
>>>I believe this is not true for non "Enterprise" PL/I's.  I don't have a 
>>>compiler handy to check just now.
>>>
>>
>
> Thankfully, the compilers I'm familiar with don't do this.  UNALIGNED 
> non-bit data is always aligned on a byte boundary.  Notice that the 
> compiler identifies "DWD below as UNALIGNED, but inserts the padding bits.
>
> 10H7848 IBM PL/I for OS/2         V1.R1      2006.05.21  12:12:00   Page 1
>  Line.File
>
>             /* TEST */
>     2.1     test: proc options(main);
>     3.1       dcl 1 struc unaligned,
>                     2 bits bit(1),
>                     2 dwd  fixed bin(31);
>     6.1       end test;
>
>
> 10H7848 IBM PL/I for OS/2         V1.R1      2006.05.21  12:12:00   Page 2
>
>
>                    Attribute/Xref Table
>
>
>     Line.File Identifier                      Attributes
>
>        4.1    BITS                            MEMBER IN STRUC BIT(1) 
> UNALIGNED
>        5.1    DWD                             MEMBER IN STRUC FIXED 
> BIN(31,0)
>                                               UNALIGNED
>        3.1    STRUC                           STRUCTURE AUTOMATIC
>        2.1    TEST                            CONSTANT EXTERNAL
>                                               ENTRY()
>
>
> 10H7848 IBM PL/I for OS/2         V1.R1      2006.05.21  12:12:00   Page 3
>
>
>                    Aggregate Length Table
>
>                                   Total         Base
>     Line.File         Offset       Size         Size  Identifier
>
>
>        3.1               0            5               STRUC
>                          0         0(7)                 /* padding */
>                       0(7)         0(1)                 BITS
>                          1            4                 DWD
>
> 10H7848 IBM PL/I for OS/2         V1.R1      2006.05.21  12:12:00   Page 4
>
>
> File Reference Table
>
>   File    Included From  Name
>
>      1                   C:\pli\test.pli
>
>
> Component    Return Code    Messages (Total/Suppressed)    Time
>
> MACRO            0                0  /  0                   1 secs
> Compiler         0                0  /  0                   6 secs
>
> End of compilation of TEST
> 


0
5/24/2006 4:29:50 PM
James J. Weinkam wrote:

(snip, I wrote)

>>> DO I=J TO K BY ABS(L);

(snip)

> Everybody seems to have missed the point here.

> If the increment (L) is negative, using ABS(L) makes it positive which 
> is wrong, full stop.  Nothing good can come from this.

I wrote this one thinking that changes to L would take effect within
the loop, but in any case with the ABS the compiler can be sure that the 
increment is never negative, and optimize accordingly.

-- glen

0
gah (12851)
5/24/2006 7:21:14 PM
On Wed, 24 May 2006 12:21:14 -0700, glen herrmannsfeldt  =

<gah@ugcs.caltech.edu> wrote:

> I wrote this one thinking that changes to L would take effect within
> the loop, but in any case with the ABS the compiler can be sure that t=
he  =

> increment is never negative, and optimize accordingly.
>
Doesn't matter, the optimization is the samer anyway.
Tom
0
tom284 (1839)
5/24/2006 9:59:39 PM

robin wrote:
> "Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
> news:LuBcg.1168$W97.66@twister.nyroc.rr.com...
> 
> 
>>Having just implemented DO ...BY <expression> when the <expression> is
>>not a constant, I can see where UPTHRU and DOWNTHRU can save a fair
>>amount of code.
> 
> 
> A couple of instructions, at most.
> Not a "fair amount of code".
> 

pseudocode:
During loop initialization:
   1 get sign of increment
   2 save sign value, 0=pos, 4=neg

At top of loop, after incrementing control variable:
loop_head:
   3. load sign value
   4. compare control variable to limit
   5. jump $+4 indexed by sign value
   6. address of sign_is_positive
   7. address of sign_is_negative
sign_is_positive:
   8 jump if greater end_of_loop
   9 jump loop_body
sign_is_negative:
  10 jump if less end_of_loop
loop_body:
  ...
  11 jump loop_head
end_of_loop:

  Instructions 1 and 2 are extra instructions done once per loop. 
Instructions 5-9 are executed once per iteration, and are unique to the 
case where the sign of the increment is unknown.  If this were a 360 I 
might have built the jump instruction at the head of the loop and just 
EXecuted it, but Intel required the other nonsense.


0
Peter_Flass (956)
5/24/2006 11:21:37 PM
On Wed, 24 May 2006 16:21:37 -0700, Peter Flass <Peter_Flass@Yahoo.com> =
 =

wrote:

>
>
> robin wrote:
>> "Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
>> news:LuBcg.1168$W97.66@twister.nyroc.rr.com...
>>
>>> Having just implemented DO ...BY <expression> when the <expression> =
is
>>> not a constant, I can see where UPTHRU and DOWNTHRU can save a fair
>>> amount of code.
>>   A couple of instructions, at most.
>> Not a "fair amount of code".
>>
>
> pseudocode:
> During loop initialization:
>    1 get sign of increment
>    2 save sign value, 0=3Dpos, 4=3Dneg
>
> At top of loop, after incrementing control variable:
> loop_head:
>    3. load sign value
>    4. compare control variable to limit
>    5. jump $+4 indexed by sign value
>    6. address of sign_is_positive
>    7. address of sign_is_negative
> sign_is_positive:
>    8 jump if greater end_of_loop
>    9 jump loop_body
> sign_is_negative:
>   10 jump if less end_of_loop
> loop_body:
>   ...
>   11 jump loop_head
> end_of_loop:
>
>   Instructions 1 and 2 are extra instructions done once per loop.  =

> Instructions 5-9 are executed once per iteration, and are unique to th=
e  =

> case where the sign of the increment is unknown.  If this were a 360 I=
  =

> might have built the jump instruction at the head of the loop and just=
  =

> EXecuted it, but Intel required the other nonsense.
>
>
That's not the way you want to do it, here's how.  Note this requires
code motion and duplicating the test for the first time.  You don't care=

if the increment is positive or negative.

If it is a constant you will pick it up in the offset calculation
or as part of the add, compare and branch or even constant folding
in some cases.

Here is what it should look like, and if you build a flow graph
this is what you'll get

Initial test
loop head
      body
loop test

If the first test fail you drop to the same as the fall thru path of
loop test.  Then when you do value propogation it moves to just ahead
of loop head.  Now with this structure you can also do loop unrolling
if you want, on some machines it can pay off.

The loop test can be many, e.g.
do <expr> repeat<expr> while<expr> until<expr>;
Tom


-- =

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
0
tom284 (1839)
5/24/2006 11:48:37 PM
Tom LINDEN wrote:
> On Wed, 24 May 2006 12:21:14 -0700, glen herrmannsfeldt 
> <gah@ugcs.caltech.edu> wrote:
> 
>> I wrote this one thinking that changes to L would take effect within
>> the loop, but in any case with the ABS the compiler can be sure that 
>> the increment is never negative, and optimize accordingly.
>>
> Doesn't matter, the optimization is the samer anyway.

It can't be the same. The /meaning/ of BY depends on the sign.

-- 
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
   -- Charles Williams.  "Taliessin through Logres: Prelude"
0
jwkenne (1442)
5/25/2006 2:51:31 AM
Peter Flass wrote:

(snip)

> pseudocode:
> During loop initialization:
>   1 get sign of increment
>   2 save sign value, 0=pos, 4=neg

> At top of loop, after incrementing control variable:
> loop_head:
>   3. load sign value
>   4. compare control variable to limit
>   5. jump $+4 indexed by sign value
>   6. address of sign_is_positive
>   7. address of sign_is_negative
> sign_is_positive:
>   8 jump if greater end_of_loop
>   9 jump loop_body
> sign_is_negative:
>  10 jump if less end_of_loop
> loop_body:
>  ...
>  11 jump loop_head
> end_of_loop:

Nice code, but it is bad for branch prediction.  A loop should
have a predictable branch, but this one doesn't.

Someone a few years ago was timing BXLE and BXH on an ESA/390 machine,
trying each at the beginning or end of the loop.  It seems that BXH 
predicts the branch not taken, and BXLE predicts it taken, independent 
of its position in the loop.

On most machines, indexed branches like you show have no prediction
at all since it depends on a register value that is unknown to the 
prediction logic.  In the S/360 days this made sense, but not anymore.

-- glen

0
gah (12851)
5/25/2006 3:36:47 AM
"Tom LINDEN" <tom@kednos.com> wrote in message
news:op.s92xrbr2lvpiaf@hyrrokkin...

>Here is what it should look like, and if you build a flow graph
>this is what you'll get

>Initial test
>loop head
>      body
>loop test

This is not efficient.
Better is:

B endloop
Loop:

    compare
    Conditional branch to Loop
endloop:




0
robin_v (2737)
5/25/2006 3:40:47 AM
From: "Mark Yudkin" <myudkinATcompuserveDOTcom@boingboing.org>
Newsgroups: comp.lang.pl1
Sent: Sunday, May 21, 2006 6:46 PM

> Struture alignment rules are part of the language definition. Any compiler
> not yielding the same result is faulty, as it would make it impossible to
> interchange files.

The mapping of the components of a structure is
system dependent, of course.




0
robin_v (2737)
5/25/2006 3:40:48 AM
On Wed, 24 May 2006 20:40:47 -0700, robin <robin_v@bigpond.com> wrote:

> "Tom LINDEN" <tom@kednos.com> wrote in message
> news:op.s92xrbr2lvpiaf@hyrrokkin...
>
>> Here is what it should look like, and if you build a flow graph
>> this is what you'll get
>
>> Initial test
>> loop head
>>      body
>> loop test
>
> This is not efficient.
> Better is:
>
> B endloop
> Loop:
>
>     compare
>     Conditional branch to Loop
> endloop:
>
You obviously have not written optimizing compilers, what I wrote
is as good as it gets, or perhaps you didn't understand it.
There can be many tests terminating the loop, so when I wrote loop test,=

this meant them collectively, and implicit is the branch to loop head.
Generally initial test will likely be the same as loop test, but by
copying them to loop bottom and initiating the tests at the top a
better flow graph results more amenable to loop optimizations


-- =

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
0
tom284 (1839)
5/25/2006 4:26:01 AM
On Wed, 24 May 2006 19:51:31 -0700, John W. Kennedy  =

<jwkenne@attglobal.net> wrote:

> Tom LINDEN wrote:
>> On Wed, 24 May 2006 12:21:14 -0700, glen herrmannsfeldt  =

>> <gah@ugcs.caltech.edu> wrote:
>>
>>> I wrote this one thinking that changes to L would take effect within=

>>> the loop, but in any case with the ABS the compiler can be sure that=
  =

>>> the increment is never negative, and optimize accordingly.
>>>
>> Doesn't matter, the optimization is the samer anyway.
>
> It can't be the same. The /meaning/ of BY depends on the sign.
>
doesn't matter.  either it is a constant or it is an expression.  You
create the trees and the optimizer will do what it can, maybe fold  =

constants,
create shadow variables, many things.  You may end up generating differn=
et  =

instructions sequences depending on the architecure.  VAX had, for examp=
le,
a single instruction that did, add compare and branch.  On risc machines=

it is more cumbersome


-- =

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
0
tom284 (1839)
5/25/2006 4:31:20 AM
On Wed, 24 May 2006 20:36:47 -0700, glen herrmannsfeldt  =

<gah@ugcs.caltech.edu> wrote:

> Peter Flass wrote:
>
> (snip)
>
>> pseudocode:
>> During loop initialization:
>>   1 get sign of increment
>>   2 save sign value, 0=3Dpos, 4=3Dneg
>
>> At top of loop, after incrementing control variable:
>> loop_head:
>>   3. load sign value
>>   4. compare control variable to limit
>>   5. jump $+4 indexed by sign value
>>   6. address of sign_is_positive
>>   7. address of sign_is_negative
>> sign_is_positive:
>>   8 jump if greater end_of_loop
>>   9 jump loop_body
>> sign_is_negative:
>>  10 jump if less end_of_loop
>> loop_body:
>>  ...
>>  11 jump loop_head
>> end_of_loop:
>
> Nice code, but it is bad for branch prediction.  A loop should
> have a predictable branch, but this one doesn't.
>
> Someone a few years ago was timing BXLE and BXH on an ESA/390 machine,=

> trying each at the beginning or end of the loop.  It seems that BXH  =

> predicts the branch not taken, and BXLE predicts it taken, independent=
  =

> of its position in the loop.
>
> On most machines, indexed branches like you show have no prediction
> at all since it depends on a register value that is unknown to the  =

> prediction logic.  In the S/360 days this made sense, but not anymore.=


My experience is that branch prediction doesn't have a payoff unless
based on profiling.
>
> -- glen
>



-- =

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
0
tom284 (1839)
5/25/2006 4:33:15 AM
glen herrmannsfeldt wrote:
> James J. Weinkam wrote:
> 
> (snip, I wrote)
> 
>>>> DO I=J TO K BY ABS(L);
> 
> 
> (snip)
> 
>> Everybody seems to have missed the point here.
> 
> 
>> If the increment (L) is negative, using ABS(L) makes it positive which 
>> is wrong, full stop.  Nothing good can come from this.
> 
> 
> I wrote this one thinking that changes to L would take effect within
> the loop, but in any case with the ABS the compiler can be sure that the 
> increment is never negative, and optimize accordingly.

OK, I see now what you were getting at: L varies but the programmer knows enough 
about the expression to be sure that its value is always positive.

However, even if L changes within the loop, any such change (whether L is a 
variable or expression) will have no effect on loop control because according to 
the semantics of the DO statement, the identity of the index variable and the 
values of the initial index value, increment (BY), and limit (TO) are computed 
once and for all and saved in temporaries before the first execution of the loop 
body.  The index variable is actually initialized only after these evaluations 
have taken place, because all three expressions might depend on its value just 
before the do statement.

Here is what the Personal PL/I for OS/2 LRM has to say:

  1.If reference is specified and BY, TO, UPTHRU, or DOWNTHRU options are also 
specified, exp1,  exp2, and exp3 will be evaluated prior to the assignment of 
exp1 to the reference. Then the initial value is assigned to reference, for 
example:

   do Reference = Exp1 to Exp2 by Exp3;


For a variable that is not a pseudovariable, the action of the do-group 
definition in the preceding example is equivalent to the following expansion:

   E1=Exp1;
   E2=Exp2;
   E3=Exp3;
   V=E1;


The variable V is a compiler-created based variable with the same attributes as 
the reference. E1, E2, and E3 are compiler-created variables.

The Optimizing Compiler LRM is even more specific in that it specifies that the 
value of the pointer for V is computed before Exp1, 2, and 3 are evaluated.

Thus once BY has been evaluated, its sign is known and won't change regardless 
of what happens to the variables it depends on during repeated executions of the 
body.

The practical issue is how the compiled code is going to "remember" this 
knowledge.  Unless the compiler generates two copies of the body or invokes it 
as a subroutine from positive and negative instances of the 
increment-test-repeat logic, when the bottom of the body is reached it is going 
to have to rediscover the sign of the increment to choose the proper test.

The two copy method is the only one without performance overhead within the loop.

Here's how Personal PL/I for OS/2 does it:

; 10   do i=a to b by c; d=d+i; end;
00000156 8b 85 54 ff ff ff       	mov	eax,[ebp-0ach];	B
0000015c 89 85 4c ff ff ff       	mov	[ebp-0b4h],eax;	_temp5
00000162 8b 85 50 ff ff ff       	mov	eax,[ebp-0b0h];	C
00000168 89 85 3c ff ff ff       	mov	[ebp-0c4h],eax;	_temp4
0000016e 8b 9d 58 ff ff ff       	mov	ebx,[ebp-0a8h];	A
00000174 89 9d 60 ff ff ff       	mov	[ebp-0a0h],ebx;	I
0000017a 85 c0                   	test	eax,eax
0000017c 7d 00                   	jge	@BLBL3
0000017e c7 85 48 ff ff ff 00 00
          00 00                   	mov	dword ptr [ebp-0b8h],offset FLAT: 
@BLBL4;	_temp3
00000188 eb 00                   	jmp	@BLBL5
0000018a 8d 80 00 00 00 00       	align 010h
                                   @BLBL3:
00000190 c7 85 48 ff ff ff 00 00
          00 00                   	mov	dword ptr [ebp-0b8h],offset FLAT: 
@BLBL6;	_temp3
                                   @BLBL5:
0000019a eb 00                   	jmp	@BLBL7
0000019c 8b c0 8b c0             	align 010h
                                   @BLBL8:
000001a0 8b 85 60 ff ff ff       	mov	eax,[ebp-0a0h];	I
000001a6 01 85 5c ff ff ff       	add	[ebp-0a4h],eax;	D
000001ac 71 00                   	jno	@BLBL14
000001ae ce                      	into	
                                   @BLBL14:
                                   @BLBL9:
                                   @BLBL10:
000001af 8b 85 3c ff ff ff       	mov	eax,[ebp-0c4h];	_temp4
000001b5 01 85 60 ff ff ff       	add	[ebp-0a0h],eax;	I
000001bb 71 00                   	jno	@BLBL15
000001bd ce                      	into	
                                   @BLBL15:
                                   @BLBL7:
000001be ff a5 48 ff ff ff       	jmp	dword ptr [ebp-0b8h];	_temp3
                                   	align 010h
                                   @BLBL4:
000001c4 8b 85 4c ff ff ff       	mov	eax,[ebp-0b4h];	_temp5
000001ca 39 85 60 ff ff ff       	cmp	[ebp-0a0h],eax;	I
000001d0 7d ce                   	jge	@BLBL8
000001d2 eb 00                   	jmp	@BLBL11
                                   	align 010h
                                   @BLBL6:
000001d4 8b 85 4c ff ff ff       	mov	eax,[ebp-0b4h];	_temp5
000001da 39 85 60 ff ff ff       	cmp	[ebp-0a0h],eax;	I
000001e0 7e be                   	jle	@BLBL8
                                   @BLBL11:


Long lines have wrapped.

Observe that after discovering the sign of C the compiler stores the result in 
temp3 in the form of a jump target.  This is essentially the inline subroutine 
method with the return address stored in temp3.  The performance overhead within 
the loop is one unconditional indirect jump.


This compiler's optimizer is not smart enough to spot the use of abs(C) (result 
not shown).

Whether other, more recent compilers are smart enough, someone else will have to 
test.

Another thing that I discovered while investigating this is that at least the 
Personal PL/I for OS/2 compiler does not actually compile code equivalent to the 
  specification given in the LRM.  I tried an example in which Exp1, 2, and 3 
each invoked a parameter-modifying function and all three function references 
involved different permutations of the same arguments.  Because of the resulting 
side effects, different orders of evaluation will give different results 
(certainly not a recommended practice).  By specifying a specific order of 
evaluation in the LRM, the designers intended to make program behavior well 
defined in such a situation.  However, the compiled code evaluates the 
expressions in the order Exp2, Exp3, Exp1 contrary to what the manual says.  I 
have no idea what other compilers will do in this situation.  Since nobody in 
his right mind is likely to use a parameter-modifying function in such a manner, 
this departure from the specification is probably not an issue, but it does show 
that the implementors failed to follow the blue print.
0
jjw (608)
5/25/2006 5:03:51 AM
"Tom LINDEN" <tom@kednos.com> wrote in message
 news:op.s92xrbr2lvpiaf@hyrrokkin...

 >Here is what it should look like, and if you build a flow graph
 >this is what you'll get

 >Initial test
 >loop head
 >      body
 >loop test

 This is not efficient.
 Better is:

B endloop
Loop:

endloop:
     compare
    Conditional branch to Loop



0
robin_v (2737)
5/25/2006 9:20:46 AM
"John W. Kennedy" <jwkenne@attglobal.net> wrote in message
news:XY8dg.266$LO3.65@fe11.lga...
> Tom LINDEN wrote:
> > On Wed, 24 May 2006 12:21:14 -0700, glen herrmannsfeldt
> > <gah@ugcs.caltech.edu> wrote:
> >
> >> I wrote this one thinking that changes to L would take effect within
> >> the loop, but in any case with the ABS the compiler can be sure that
> >> the increment is never negative, and optimize accordingly.
> >>
> > Doesn't matter, the optimization is the samer anyway.
>
> It can't be the same. The /meaning/ of BY depends on the sign.

It can be the same; it depends on the code that is
generated.
For the instance that I gave, the optimizaion would be the same.




0
robin_v (2737)
5/25/2006 9:20:47 AM
Wrong again. There is absolutely nothing system dependent about structure 
mapping in PL/I. The rules for structure mapping are defined by the PL/I 
reference down to the tiniest detail, and are deliberately 
system-independent. Take any structure definition and follow the rules in 
the manual and you'll know every last bit of the structure mapping.

"robin" <robin_v@bigpond.com> wrote in message 
news:4H9dg.10255$S7.9178@news-server.bigpond.net.au...
> From: "Mark Yudkin" <myudkinATcompuserveDOTcom@boingboing.org>
> Newsgroups: comp.lang.pl1
> Sent: Sunday, May 21, 2006 6:46 PM
>
>> Struture alignment rules are part of the language definition. Any 
>> compiler
>> not yielding the same result is faulty, as it would make it impossible to
>> interchange files.
>
> The mapping of the components of a structure is
> system dependent, of course.
>
>
>
> 


0
5/25/2006 10:28:16 AM
"James J. Weinkam" <jjw@cs.sfu.ca> wrote in message
news:XUadg.22107$zn1.13422@clgrps13...
> glen herrmannsfeldt wrote:
> > James J. Weinkam wrote:
> >>>> DO I=J TO K BY ABS(L);
> >> Everybody seems to have missed the point here.
> >> If the increment (L) is negative, using ABS(L) makes it positive which
> >> is wrong, full stop.  Nothing good can come from this.
>
> > I wrote this one thinking that changes to L would take effect within
> > the loop, but in any case with the ABS the compiler can be sure that the
> > increment is never negative, and optimize accordingly.
>
> OK, I see now what you were getting at: L varies but the programmer knows
enough
> about the expression to be sure that its value is always positive.
>
> However, even if L changes within the loop, any such change (whether L is a
> variable or expression) will have no effect on loop control because according
to
> the semantics of the DO statement, the identity of the index variable and the
> values of the initial index value, increment (BY), and limit (TO) are computed
> once and for all and saved in temporaries before the first execution of the
loop
> body.  The index variable is actually initialized only after these evaluations
> have taken place, because all three expressions might depend on its value just
> before the do statement.
>
> Here is what the Personal PL/I for OS/2 LRM has to say:
>
>   1.If reference is specified and BY, TO, UPTHRU, or DOWNTHRU options are also
> specified, exp1,  exp2, and exp3 will be evaluated prior to the assignment of
> exp1 to the reference. Then the initial value is assigned to reference, for
> example:
>
>    do Reference = Exp1 to Exp2 by Exp3;
>
> For a variable that is not a pseudovariable, the action of the do-group
> definition in the preceding example is equivalent to the following expansion:
>
>    E1=Exp1;
>    E2=Exp2;
>    E3=Exp3;
>    V=E1;
>
>
> The variable V is a compiler-created based variable with the same attributes
as
> the reference. E1, E2, and E3 are compiler-created variables.
>
> The Optimizing Compiler LRM is even more specific in that it specifies that
the
> value of the pointer for V is computed before Exp1, 2, and 3 are evaluated.
>
> Thus once BY has been evaluated, its sign is known and won't change regardless
> of what happens to the variables it depends on during repeated executions of
the
> body.
>
> The practical issue is how the compiled code is going to "remember" this
> knowledge.  Unless the compiler generates two copies of the body or invokes it
> as a subroutine from positive and negative instances of the
> increment-test-repeat logic, when the bottom of the body is reached it is
going
> to have to rediscover the sign of the increment to choose the proper test.

No it doesn't, as I pointed out earlier in this thread.
The pre-loop code only has to place zero or k
in a register.
    Just before the test - at the tail of the loop -
a branch instruction using that value as an index
selects the appropriate code for performing the test.
(the value zero or k is the means by which the appropriate
code sequence is selected.)



0
robin_v (2737)
5/25/2006 12:58:53 PM
From: "Tom LINDEN" <tom@kednos.com>
Sent: Thursday, May 25, 2006 2:26 PM

On Wed, 24 May 2006 20:40:47 -0700, robin <robin_v@bigpond.com> wrote:

> "Tom LINDEN" <tom@kednos.com> wrote in message
> news:op.s92xrbr2lvpiaf@hyrrokkin...
>
>> Here is what it should look like, and if you build a flow graph
>> this is what you'll get
>
>> Initial test
>> loop head
>>      body
>> loop test
>
> This is not efficient.
> Better is:
>
> B endloop

This post was cancelled, and replaced immediately with another
with the lines in the correct order.
Somehow the replacement did not go up straight away.


0
robin_v (2737)
5/25/2006 12:58:55 PM
"Tom LINDEN" <tom@kednos.com> wrote in message
news:op.s93alnrnlvpiaf@hyrrokkin...
On Wed, 24 May 2006 20:40:47 -0700, robin <robin_v@bigpond.com> wrote:

> "Tom LINDEN" <tom@kednos.com> wrote in message
> news:op.s92xrbr2lvpiaf@hyrrokkin...
>
>> Here is what it should look like, and if you build a flow graph
>> this is what you'll get
>
>> Initial test
>> loop head
>>      body
>> loop test
>
> This is not efficient.
> Better is:
>
> B endloop
> Loop:
>
> endloop:
>     compare
>     Conditional branch to Loop
>
You obviously have not written optimizing compilers,

I have.

> what I wrote is as good as it gets,

Mine requires less code.  All the tests are in one place.

>There can be many tests terminating the loop, so when I wrote loop test,
>this meant them collectively, and implicit is the branch to loop head.
>Generally initial test will likely be the same as loop test, but by
>copying them to loop bottom and initiating the tests at the top a
>better flow graph results more amenable to loop optimizations

As the compiler prepares the code for the loop test
when it is compiling the DO statement, the compiler
sees the tests as if they flowed into the top of the loop.
Where the tests actually are [in the code] is irrelevant.


0
robin_v (2737)
5/25/2006 12:58:55 PM
robin wrote:
> "James J. Weinkam" <jjw@cs.sfu.ca> wrote in message
> news:XUadg.22107$zn1.13422@clgrps13...
> 
>>glen herrmannsfeldt wrote:
>>
>>>James J. Weinkam wrote:
>>>
>>>>>>DO I=J TO K BY ABS(L);
>>>>
>>>>Everybody seems to have missed the point here.
>>>>If the increment (L) is negative, using ABS(L) makes it positive which
>>>>is wrong, full stop.  Nothing good can come from this.
>>
>>>I wrote this one thinking that changes to L would take effect within
>>>the loop, but in any case with the ABS the compiler can be sure that the
>>>increment is never negative, and optimize accordingly.
>>
>>OK, I see now what you were getting at: L varies but the programmer knows
> 
> enough
> 
>>about the expression to be sure that its value is always positive.
>>
>>However, even if L changes within the loop, any such change (whether L is a
>>variable or expression) will have no effect on loop control because according
> 
> to
> 
>>the semantics of the DO statement, the identity of the index variable and the
>>values of the initial index value, increment (BY), and limit (TO) are computed
>>once and for all and saved in temporaries before the first execution of the
> 
> loop
> 
>>body.  The index variable is actually initialized only after these evaluations
>>have taken place, because all three expressions might depend on its value just
>>before the do statement.
>>
>>Here is what the Personal PL/I for OS/2 LRM has to say:
>>
>>  1.If reference is specified and BY, TO, UPTHRU, or DOWNTHRU options are also
>>specified, exp1,  exp2, and exp3 will be evaluated prior to the assignment of
>>exp1 to the reference. Then the initial value is assigned to reference, for
>>example:
>>
>>   do Reference = Exp1 to Exp2 by Exp3;
>>
>>For a variable that is not a pseudovariable, the action of the do-group
>>definition in the preceding example is equivalent to the following expansion:
>>
>>   E1=Exp1;
>>   E2=Exp2;
>>   E3=Exp3;
>>   V=E1;
>>
>>
>>The variable V is a compiler-created based variable with the same attributes
> 
> as
> 
>>the reference. E1, E2, and E3 are compiler-created variables.
>>
>>The Optimizing Compiler LRM is even more specific in that it specifies that
> 
> the
> 
>>value of the pointer for V is computed before Exp1, 2, and 3 are evaluated.
>>
>>Thus once BY has been evaluated, its sign is known and won't change regardless
>>of what happens to the variables it depends on during repeated executions of
> 
> the
> 
>>body.
>>
>>The practical issue is how the compiled code is going to "remember" this
>>knowledge.  Unless the compiler generates two copies of the body or invokes it
>>as a subroutine from positive and negative instances of the
>>increment-test-repeat logic, when the bottom of the body is reached it is
> 
> going
> 
>>to have to rediscover the sign of the increment to choose the proper test.
> 
> 
> No it doesn't, as I pointed out earlier in this thread.
> The pre-loop code only has to place zero or k
> in a register.
>     Just before the test - at the tail of the loop -
> a branch instruction using that value as an index
> selects the appropriate code for performing the test.
> (the value zero or k is the means by which the appropriate
> code sequence is selected.)
> 
> 
> 
That's just an efficient way to rediscover the sign.  It also presupposes that 
there is a register available to dedicate to that purpose for the duration of 
the loop.  That indexed branch is execution time overhead that wouldn't be 
needed if the compiler knew that the sign would always be the same; it could 
just fall through to the test code.
0
jjw (608)
5/25/2006 6:52:13 PM
James J. Weinkam wrote:

(snip)

>  1.If reference is specified and BY, TO, UPTHRU, or DOWNTHRU options are 
> also specified, exp1,  exp2, and exp3 will be evaluated prior to the 
> assignment of exp1 to the reference. Then the initial value is assigned 
> to reference, for example:

>   do Reference = Exp1 to Exp2 by Exp3;

Oh, I almost forgot about that one.  I once did something like:

    DO I=1 TO I;

> For a variable that is not a pseudovariable, the action of the do-group 
> definition in the preceding example is equivalent to the following 
> expansion:

>   E1=Exp1;
>   E2=Exp2;
>   E3=Exp3;
>   V=E1;

> The variable V is a compiler-created based variable with the same 
> attributes as the reference. E1, E2, and E3 are compiler-created variables.

I always liked pseudo-variables in DO loops, one of my favorite is

    X=0;
    DO IMAG(X)=1 TO 100;

to loop through imaginary values;

Though I always remember doing:

  DCL X CHAR(10);
  DO X='  1' TO '  100' BY '1';
     PUT SKIP LIST(SQRT(X));
  END;

the number of spaces in the constant is important, and I might have it
wrong.  The loop compare is done as characters not as a numeric value.


(snip)


(snip)

> Observe that after discovering the sign of C the compiler stores the 
> result in temp3 in the form of a jump target.  This is essentially the 
> inline subroutine method with the return address stored in temp3.  The 
> performance overhead within the loop is one unconditional indirect jump.

The performance of indirect jump is poor on many modern machines.


(snip)

> Another thing that I discovered while investigating this is that at 
> least the Personal PL/I for OS/2 compiler does not actually compile code 
> equivalent to the  specification given in the LRM.  I tried an example 
> in which Exp1, 2, and 3 each invoked a parameter-modifying function and 
> all three function references involved different permutations of the 
> same arguments.  Because of the resulting side effects, different orders 
> of evaluation will give different results (certainly not a recommended 
> practice).  

I don't know what the aliasing rules are.   I might think that function 
parameters were obvious enough, though.

-- glen

0
gah (12851)
5/25/2006 9:05:47 PM
Mark Yudkin wrote:

> Wrong again. There is absolutely nothing system dependent about structure 
> mapping in PL/I. The rules for structure mapping are defined by the PL/I 
> reference down to the tiniest detail, and are deliberately 
> system-independent. Take any structure definition and follow the rules in 
> the manual and you'll know every last bit of the structure mapping.
> 

The alignment requirements, and therefore the meaning of "ALIGNED" are 
system-dependent, I believe.

0
Peter_Flass (956)
5/25/2006 9:30:51 PM
robin wrote:
> 
> You obviously have not written optimizing compilers,
> 
> I have.
> 
> 
>>what I wrote is as good as it gets,
> 
> 
> Mine requires less code.  All the tests are in one place.
> 

There is lots of discussion of what "optimization" is, and whether it's 
worth it.  Besides the ususl tradeoff of memory size vs. time, 
apparently many optimizations that improve performance on one version of 
Intel's IA-32 architecture will degrade performance, sometimes a lot, on 
other versions.  If you're writing code for Pentiums, for example, it 
should run on all Pentiums, and probably the best you can do is middling 
performance on all, rather than a screamer on some and a dog on others.

The same applies to IBM mainframe architecture, and probably all others.

0
Peter_Flass (956)
5/25/2006 9:37:22 PM
glen herrmannsfeldt wrote:

> Though I always remember doing:
> 
>  DCL X CHAR(10);
>  DO X='  1' TO '  100' BY '1';
>     PUT SKIP LIST(SQRT(X));
>  END;
> 
> the number of spaces in the constant is important, and I might have it
> wrong.  The loop compare is done as characters not as a numeric value.
> 

I'd have to guess that it does the arithmetic in decimal and then 
reconverts the result to character.  Apparently, from what you say, it's 
doing the compare as character (makes sense, sort of).  It's fun poking 
into the odd corners of the language.

0
Peter_Flass (956)
5/25/2006 9:44:51 PM
On Thu, 25 May 2006 14:37:22 -0700, Peter Flass <Peter_Flass@Yahoo.com> =
 =

wrote:

> robin wrote:
>>  You obviously have not written optimizing compilers,
>>  I have.
>>
>>> what I wrote is as good as it gets,
>>   Mine requires less code.  All the tests are in one place.
>>
>
> There is lots of discussion of what "optimization" is, and whether it'=
s  =

> worth it.  Besides the ususl tradeoff of memory size vs. time,  =

> apparently many optimizations that improve performance on one version =
of  =

> Intel's IA-32 architecture will degrade performance, sometimes a lot, =
on  =

> other versions.  If you're writing code for Pentiums, for example, it =
 =

> should run on all Pentiums, and probably the best you can do is middli=
ng  =

> performance on all, rather than a screamer on some and a dog on others=
..
>
> The same applies to IBM mainframe architecture, and probably all other=
s.
>

On VAX we use an all singing and dancing optimizer that pretty much is  =

taken
out of Aho and Ullman.  Otherwise, the optimizer that I favour most is o=
ne
that I have been using for 25 years, and it is both language and machine=

independent.  I think optimization is way overdone.  How many compilers =
do  =

you
know that have caveats about optimization levels.  I never could get the=
  =

Mips
compiler suite to reliable produce excecutable code with full optimizati=
on.
0
tom284 (1839)
5/26/2006 12:06:25 AM
"Mark Yudkin" <myudkinATcompuserveDOTcom@boingboing.org> wrote in message
news:4475869c$0$722$5402220f@news.sunrise.ch...
> Wrong again.

No, this time you're wrong.

The positioning of fields is system dependent.
It depends on the size of a word, halfword, double words,
whether or not data must be aligned on those words,
halfwords, and double words.  In a bit-addressible machine,
padding out fields would be unnecessary.
    In a machine lacking any requirement for alignment,
no padding would be necessary between fields other than
bit fields (assuming byte addressible machine).

    You spoke of interchanging files.
    That is system dependant.

> There is absolutely nothing system dependent about structure
> mapping in PL/I. The rules for structure mapping are defined by the PL/I
> reference down to the tiniest detail, and are deliberately
> system-independent. Take any structure definition and follow the rules in
> the manual and you'll know every last bit of the structure mapping.
>
> "robin" <robin_v@bigpond.com> wrote in message
> news:4H9dg.10255$S7.9178@news-server.bigpond.net.au...
> > From: "Mark Yudkin" <myudkinATcompuserveDOTcom@boingboing.org>
> > Newsgroups: comp.lang.pl1
> > Sent: Sunday, May 21, 2006 6:46 PM
> >
> >> Struture alignment rules are part of the language definition. Any
> >> compiler
> >> not yielding the same result is faulty, as it would make it impossible to
> >> interchange files.
> >
> > The mapping of the components of a structure is
> > system dependent, of course.


0
robin_v (2737)
5/26/2006 2:58:25 AM
From the manual:
<quote>


ALIGNED specifies that the data element is aligned on the storage boundary 
corresponding to its data-type requirement. UNALIGNED specifies that each 
data element is mapped on the next byte boundary,
except for fixed-length bit strings, which are mapped on the next bit.

,------------------------------'------'----------------------------------------.
| 
|
| 
 >>--.-ALIGNED---.--------------------------------------------------------->< 
|
|     '-UNALIGNED-' 
|
| 
|
'------------------------------------------------------------------------------'

Defaults are applied at element level. UNALIGNED is the default for bit 
data, character data, graphic data, widechar data and numeric character 
data. ALIGNED is the default for all other types of data.

Requirements for the ALIGNED attribute are shown in Alignment requirements.

,-----------------------------------------------------------------------------------.
| Table 26. Alignment requirements 
|
|------------------.----------------------.--------------.--------------------------|
|                  |                      | STORAGE      |  ALIGNMENT 
REQUIREMENTS  |
|                  |                      | REQUIREMENTS 
|-------------.------------|
|                  |   STORED INTERNALLY  | (BYTES)      |   ALIGNED   | 
UNALIGNED |
| VARIABLE TYPE    |          AS:         |              |     DATA    | 
DATA    |
|------------------+----------------------+--------------+-------------+------------|
|                  | ALIGNED:             |              |             | 
|
|                  | One byte for each    |              |             | Bit 
|
|                  | group of 8 bits (or  | ALIGNED:     | Byte        | 
(Data can  |
|                  | part thereof)        |  CEIL(n/8)   | (Data can   | 
begin on   |
| BIT (n)          |                      |              | begin on    | any 
bit in |
|                  | UNALIGNED:           | UNALIGNED:   | any byte, 0 | any 
byte,  |
|                  | As many bits as are  | n bits       | through 7)  | 0 
through  |
|                  | required, regardless |              |             | 7) 
|
|                  | of byte boundaries   |              |             | 
|
|------------------+----------------------+--------------+-------------+------------|
| CHARACTER (n)    | One byte per char-   |       n      |             | 
|
|                  | acter                |              |             | 
|
|------------------+----------------------+--------------|             | 
|
|                  | One byte per char-   |              |             | 
|
| CHARACTER (n)    | acter plus           |              |             | 
|
| VARYINGZ         | one byte for the     |      n+1     |             | 
|
|                  | null                 |              |             | 
|
|                  | terminator           |              |             | 
|
|------------------+----------------------+--------------|             | 
|
| GRAPHIC (n)      | Two bytes per        |      2n      |             | 
|
|                  | graphic              |              |             | 
|
|------------------+----------------------+--------------|             | 
|
|                  | Two bytes per        |              |             | 
|
| GRAPHIC (n)      | graphic plus         |              |             | 
|
| VARYINGZ         | two bytes for the    |     2n+2     |             | 
|
|                  | null                 |              |             | 
|
|                  | terminator           |              |             | 
|
|------------------+----------------------+--------------|             | 
|
| WIDECHAR (n)     | Two bytes per        |      2n      |             | 
|
|                  | widechar.            |              |             | 
|
|------------------+----------------------+--------------|             | 
|
|                  | Two bytes per        |              |             | 
|
| WIDECHAR (n)     | widechar plus        |              |             | 
|
| VARYINGZ         | two bytes for the    |     2n+2     |             | 
|
|                  | null                 |              | Byte        | 
Byte       |
|                  | terminator           |              | (Data can   | 
(Data can  |
|------------------+----------------------+--------------| begin on    | 
begin on   |
|                  |                      |   Number of  | any byte, 0 | any 
byte,  |
|                  | One byte for each    |    PICTURE   | through 7)  | 0 
through  |
|                  | PICTURE character    |  characters  |             | 7) 
|
| PICTURE          | (except V, K, and    |  other than  |             | 
|
|                  | the F scaling factor |  V, K, and F |             | 
|
|                  | specification)       |  specifica-  |             | 
|
|                  |                      |     tion     |             | 
|
|------------------+----------------------+--------------|             | 
|
|                  | Packed decimal       |              |             | 
|
| DECIMAL FIXED    | format (1/2 byte per | CEIL((p+1)/2 |             | 
|
| (p,q)            | digit, plus 1/2 byte |              |             | 
|
|                  | for sign)            |              |             | 
|
|------------------+----------------------+--------------|             | 
|
| BINARY           |                      |              |             | 
|
| FIXED(p,q)       |                      |              |             | 
|
|                  |                      |              |             | 
|
| SIGNED           |                      |              |             | 
|
| 1 <= p <= 7      |                      |              |             | 
|
| UNSIGNED         |                      |              |             | 
|
| 1 <= p <= 8      |       One byte       |       1      |             | 
|
|------------------|                      |              |             | 
|
| ORDINAL          |                      |              |             | 
|
|                  |                      |              |             | 
|
| SIGNED           |                      |              |             | 
|
| 1 <= p <= 7      |                      |              |             | 
|
| UNSIGNED         |                      |              |             | 
|
| 1 <= p <= 8      |                      |              |             | 
|
|------------------'----------------------'--------------'-------------'------------|
| Alignment and storage requirements for program control data can vary 
across sup-  |
| ported systems. 
|
| 
|
| Complex data requires twice as much storage as its real counterpart, but 
the      |
| alignment requirements are the same. 
|
'-----------------------------------------------------------------------------------'
,-----------------------------------------------------------------------------------.
| Table 26. Alignment requirements 
|
|------------------.----------------------.--------------.--------------------------|
|                  |                      | STORAGE      |  ALIGNMENT 
REQUIREMENTS  |
|                  |                      | REQUIREMENTS 
|-------------.------------|
|                  |   STORED INTERNALLY  | (BYTES)      |   ALIGNED   | 
UNALIGNED |
| VARIABLE TYPE    |          AS:         |              |     DATA    | 
DATA    |
|------------------+----------------------+--------------+-------------+------------|
|                  | Two-byte prefix plus | ALIGNED:     |             | 
|
|                  | 1 byte for each      | 2+CEIL(n/8)  |             | 
|
| BIT(n) VARYING   | group of 8 bits (or  |              |             | 
|
|                  | part thereof) of the | UNALIGNED:   |             | 
|
|                  | declared maximum     |  2 bytes+n   |             | 
|
|                  | length               | bits         |             | 
|
|------------------+----------------------+--------------|             | 
|
|                  | Two-byte prefix plus |              |             | 
|
| CHARACTER(n)     | 1 byte per character |      n+2     |             | 
|
| VARYING          | of the declared      |              |             | 
|
|                  | maximum length       |              |             | 
|
|------------------+----------------------+--------------|             | 
|
|                  | Two-byte prefix plus |              |             | 
|
| GRAPHIC(n)       | 2 bytes per graphic  |     2n+2     |             | 
|
| VARYING          | of the declared      |              |             | 
|
|                  | maximum length       |              | Halfword    | 
Byte       |
|------------------+----------------------+--------------| (Data can   | 
(Data can  |
|                  | Two-byte prefix plus |              | begin on    | 
begin on   |
| WIDECHAR(n)      | 2 bytes per widechar |     2n+2     | byte 0, 2,  | any 
byte,  |
| VARYING          | of the declared      |              | 4, or 6)    | 0 
through  |
|                  | maximum length       |              |             | 7) 
|
|------------------+----------------------+--------------|             | 
|
| BINARY           |                      |              |             | 
|
| FIXED(p,q)       |                      |              |             | 
|
|                  |                      |              |             | 
|
| SIGNED           |                      |              |             | 
|
| 8 <= p <= 15     |                      |              |             | 
|
| UNSIGNED         |                      |              |             | 
|
| 9 <= p <= 16     |       Halfword       |       2      |             | 
|
|------------------|                      |              |             | 
|
| ORDINAL          |                      |              |             | 
|
|                  |                      |              |             | 
|
| SIGNED           |                      |              |             | 
|
| 8 <= p <= 15     |                      |              |             | 
|
| UNSIGNED         |                      |              |             | 
|
| 9 <= p <= 16     |                      |              |             | 
|
|------------------+----------------------+--------------+-------------+------------|
| BINARY           |                      |              |             | 
|
| FIXED(p,q)       |                      |              |             | 
|
|                  |                      |              |             | 
|
| SIGNED           |                      |              |             | 
|
| 16 <= p <= 31    |                      |              |             | 
|
| UNSIGNED         |                      |              |             | 
|
| 17 <= p <= 32    |       Fullword       |              |             | 
|
|------------------|                      |              | Fullword    | 
Byte       |
| ORDINAL          |                      |              | (Data can   | 
(Data can  |
|                  |                      |       4      | begin on    | 
begin on   |
| SIGNED           |                      |              | byte 0 or   | any 
byte,  |
| 16 <= p <= 31    |                      |              | 4)          | 0 
through  |
| UNSIGNED         |                      |              |             | 7) 
|
| 17 <= p <= 32    |                      |              |             | 
|
|------------------+----------------------|              |             | 
|
| BINARY FLOAT(p)  |                      |              |             | 
|
| 1<=p<=21         |                      |              |             | 
|
|------------------| Short floating-point |              |             | 
|
| DECIMAL FLOAT(p) |                      |              |             | 
|
| 1<=p<=6          |                      |              |             | 
|
|------------------+----------------------+--------------+-------------+------------|
| POINTER          |           -          |              |             | 
|
|------------------+----------------------|              |             | 
|
| HANDLE           |           -          |              |             | 
|
|------------------+----------------------|              |             | 
|
| OFFSET           |           -          |       4      |             | 
Byte       |
|------------------+----------------------|              | Fullword    | 
(Data can  |
| FILE             |           -          |              | (Data can   | 
begin on   |
|------------------+----------------------|              | begin on    | any 
byte,  |
| ENTRY LIMITED    |           -          |              | byte 0 or   | 0 
through  |
|------------------+----------------------+--------------| 4)          | 7) 
|
| ENTRY            |           -          |              |             | 
|
|------------------+----------------------|       8      |             | 
|
| LABEL or FORMAT  |           -          |              |             | 
|
|------------------+----------------------+--------------|             | 
|
| TASK             |           -          |      16      |             | 
|
|------------------'----------------------'--------------'-------------'------------|
| Alignment and storage requirements for program control data can vary 
across sup-  |
| ported systems. 
|
| 
|
| Complex data requires twice as much storage as its real counterpart, but 
the      |
| alignment requirements are the same. 
|
'-----------------------------------------------------------------------------------'
,-----------------------------------------------------------------------------------.
| Table 26. Alignment requirements 
|
|------------------.----------------------.--------------.--------------------------|
|                  |                      | STORAGE      |  ALIGNMENT 
REQUIREMENTS  |
|                  |                      | REQUIREMENTS 
|-------------.------------|
|                  |   STORED INTERNALLY  | (BYTES)      |   ALIGNED   | 
UNALIGNED |
| VARIABLE TYPE    |          AS:         |              |     DATA    | 
DATA    |
|------------------+----------------------+--------------+-------------+------------|
|                  |                      |              |             | 
AREA data  |
| AREA             |           -          |    16+size   |             | 
cannot be  |
|                  |                      |              |             | 
unaligned  |
|------------------+----------------------+--------------| 
|------------|
| BINARY           |                      |              |             | 
|
| FIXED(p,q)       |                      |              |             | 
|
|                  |                      |              |             | 
|
| SIGNED           |           -          |              |             | 
|
| 32 <= p <= 63    |                      |              |             | 
|
| UNSIGNED         |                      |              | Doubleword  | 
|
| 33 <= p <= 64    |                      |       8      | (Data can   | 
byte       |
|------------------+----------------------|              | begin on    | 
(Data can  |
| BINARY FLOAT(p)  |                      |              | byte 0)     | 
begin on   |
| 22 <= p <= 53    |                      |              |             | any 
byte,  |
|------------------|  Long floating-point |              |             | 0 
through  |
| DECIMAL FLOAT(p) |                      |              |             | 7) 
|
| 7 <= p <= 16     |                      |              |             | 
|
|------------------+----------------------+--------------|             | 
|
| BINARY FLOAT(p)  |                      |              |             | 
|
|   54<=p          |  Extended floating-  |              |             | 
|
|------------------|         point        |      16      |             | 
|
| DECIMAL FLOAT(p) |                      |              |             | 
|
|   17<=p          |                      |              |             | 
|
|------------------'----------------------'--------------'-------------'------------|
| Alignment and storage requirements for program control data can vary 
across sup-  |
| ported systems. 
|
| 
|
| Complex data requires twice as much storage as its real counterpart, but 
the      |
| alignment requirements are the same. 
|
'-----------------------------------------------------------------------------------'

ALIGNED or UNALIGNED can be specified for element, array, structure, or 
union variables. The application of either attribute to a structure or union 
is equivalent to applying the attribute to all contained elements
that are not explicitly declared ALIGNED or UNALIGNED.

The following example illustrates the effect of ALIGNED and UNALIGNED 
declarations for a structure and its elements:

  declare 1 S,
            2 X bit(2),      /* unaligned by default  */
            2 A aligned,     /* aligned explicitly    */
              3 B,           /* aligned from A        */
              3 C unaligned, /* unaligned explicitly  */
                4 D,         /* unaligned from C      */
                4 E aligned, /* aligned explicitly    */
                4 F,         /* unaligned from C      */
              3 G,           /* aligned from A        */
            2 H;             /* aligned by default    */

For more information about structures and unions, refer to Structures and 
Unions.

</quote>

So unless we're arguing about the special case "Alignment and storage 
requirements for program control data", to which you need to refer the 
programming guide, I stand by my case. If you are referring to this special 
case, I would point out that program control data cannot be included in 
record I/O.

So for example, the manual explicitly disallows alignment on bit boundaries, 
even for UNALIGNED, with the sole explicit exception of bit strings.

In particular, the machine's requirements are irrelevant. In fact, the PL/I 
requirements are sometimes in direct contradiction to the machine's 
requirements, thus forcing the compiler to generate additional code to 
handle the issues. Here are some cases:
1) widechar and graphic are BYTE aligned (fixed or varz). These characters 
are halfword values.
2) extended float (16-byte) is aligned on 8-byte boundaries.

"robin" <robin_v@bigpond.com> wrote in message 
news:l9udg.10796$S7.9220@news-server.bigpond.net.au...
> "Mark Yudkin" <myudkinATcompuserveDOTcom@boingboing.org> wrote in message
> news:4475869c$0$722$5402220f@news.sunrise.ch...
>> Wrong again.
>
> No, this time you're wrong.
>
> The positioning of fields is system dependent.
> It depends on the size of a word, halfword, double words,
> whether or not data must be aligned on those words,
> halfwords, and double words.  In a bit-addressible machine,
> padding out fields would be unnecessary.
>    In a machine lacking any requirement for alignment,
> no padding would be necessary between fields other than
> bit fields (assuming byte addressible machine).
>
>    You spoke of interchanging files.
>    That is system dependant.
>
>> There is absolutely nothing system dependent about structure
>> mapping in PL/I. The rules for structure mapping are defined by the PL/I
>> reference down to the tiniest detail, and are deliberately
>> system-independent. Take any structure definition and follow the rules in
>> the manual and you'll know every last bit of the structure mapping.
>>
>> "robin" <robin_v@bigpond.com> wrote in message
>> news:4H9dg.10255$S7.9178@news-server.bigpond.net.au...
>> > From: "Mark Yudkin" <myudkinATcompuserveDOTcom@boingboing.org>
>> > Newsgroups: comp.lang.pl1
>> > Sent: Sunday, May 21, 2006 6:46 PM
>> >
>> >> Struture alignment rules are part of the language definition. Any
>> >> compiler
>> >> not yielding the same result is faulty, as it would make it impossible 
>> >> to
>> >> interchange files.
>> >
>> > The mapping of the components of a structure is
>> > system dependent, of course.
>
> 


0
5/26/2006 7:01:44 AM
They are not. The meaning is defined by PL/I and on accasion even 
contradicts the machine's hardware requirements. The sole exception is 
program control data, whose length is system-dependent and which cannot be 
transmitted in an I/O statement.

"Peter Flass" <Peter_Flass@Yahoo.com> wrote in message 
news:fmpdg.2411$W97.1373@twister.nyroc.rr.com...
> Mark Yudkin wrote:
>
>> Wrong again. There is absolutely nothing system dependent about structure 
>> mapping in PL/I. The rules for structure mapping are defined by the PL/I 
>> reference down to the tiniest detail, and are deliberately 
>> system-independent. Take any structure definition and follow the rules in 
>> the manual and you'll know every last bit of the structure mapping.
>>
>
> The alignment requirements, and therefore the meaning of "ALIGNED" are 
> system-dependent, I believe.
> 


0
5/26/2006 7:03:58 AM
"James J. Weinkam" <jjw@cs.sfu.ca> wrote in message
news:x1ndg.23474$zn1.19516@clgrps13...
> robin wrote:
> > "James J. Weinkam" <jjw@cs.sfu.ca> wrote in message
> > news:XUadg.22107$zn1.13422@clgrps13...

> >>The practical issue is how the compiled code is going to "remember" this
> >>knowledge.  Unless the compiler generates two copies of the body or invokes
> >>it as a subroutine from positive and negative instances of the
> >>increment-test-repeat logic, when the bottom of the body is reached it is
> > going
> >>to have to rediscover the sign of the increment to choose the proper test.
> >
> > No it doesn't, as I pointed out earlier in this thread.
> > The pre-loop code only has to place zero or k
> > in a register.
> >     Just before the test - at the tail of the loop -
> > a branch instruction using that value as an index
> > selects the appropriate code for performing the test.
> > (the value zero or k is the means by which the appropriate
> > code sequence is selected.)

> That's just an efficient way to rediscover the sign.  It also presupposes that
> there is a register available to dedicate to that purpose for the duration of
> the loop.  That indexed branch is execution time overhead

Indeed so, but a minuscule overhead.

> that wouldn't be
> needed if the compiler knew that the sign would always be the same; it could
> just fall through to the test code.

There are other more efficient ways, requiring no loop overhead,
but these would make the code non-reentrant.



0
robin_v (2737)
5/26/2006 2:18:50 PM
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:U-OdnZVvQ_6QgevZRVn-qA@comcast.com...
> James J. Weinkam wrote:

> >  1.If reference is specified and BY, TO, UPTHRU, or DOWNTHRU options are
> > also specified, exp1,  exp2, and exp3 will be evaluated prior to the
> > assignment of exp1 to the reference. Then the initial value is assigned
> > to reference, for example:
>
> >   do Reference = Exp1 to Exp2 by Exp3;
>
> Oh, I almost forgot about that one.  I once did something like:
>
>     DO I=1 TO I;

There's nothing wrong with that.
It's well-defined.



0
robin_v (2737)
5/26/2006 2:18:50 PM
"James J. Weinkam" <jjw@cs.sfu.ca> wrote in message
news:XUadg.22107$zn1.13422@clgrps13...

> Here's how Personal PL/I for OS/2 does it:
>
> ; 10   do i=a to b by c; d=d+i; end;
> 00000156 8b 85 54 ff ff ff       mov eax,[ebp-0ach]; B
> 0000015c 89 85 4c ff ff ff       mov [ebp-0b4h],eax; _temp5
> 00000162 8b 85 50 ff ff ff       mov eax,[ebp-0b0h]; C
> 00000168 89 85 3c ff ff ff       mov [ebp-0c4h],eax; _temp4
> 0000016e 8b 9d 58 ff ff ff       mov ebx,[ebp-0a8h]; A
> 00000174 89 9d 60 ff ff ff       mov [ebp-0a0h],ebx; I
> 0000017a 85 c0                   test eax,eax
> 0000017c 7d 00                   jge @BLBL3
> 0000017e c7 85 48 ff ff ff 00 00
>           00 00                   mov dword ptr [ebp-0b8h],offset FLAT:
> @BLBL4; _temp3
> 00000188 eb 00                   jmp @BLBL5
> 0000018a 8d 80 00 00 00 00       align 010h
>                                    @BLBL3:
> 00000190 c7 85 48 ff ff ff 00 00
>           00 00                   mov dword ptr [ebp-0b8h],offset FLAT:
> @BLBL6; _temp3
>                                    @BLBL5:
> 0000019a eb 00                   jmp @BLBL7
> 0000019c 8b c0 8b c0             align 010h
>                                    @BLBL8:
> 000001a0 8b 85 60 ff ff ff       mov eax,[ebp-0a0h]; I
> 000001a6 01 85 5c ff ff ff       add [ebp-0a4h],eax; D
> 000001ac 71 00                   jno @BLBL14
> 000001ae ce                      into
>                                    @BLBL14:
>                                    @BLBL9:
>                                    @BLBL10:
> 000001af 8b 85 3c ff ff ff       mov eax,[ebp-0c4h]; _temp4
> 000001b5 01 85 60 ff ff ff       add [ebp-0a0h],eax; I
> 000001bb 71 00                   jno @BLBL15
> 000001bd ce                      into
>                                    @BLBL15:
>                                    @BLBL7:
> 000001be ff a5 48 ff ff ff       jmp dword ptr [ebp-0b8h]; _temp3
>                                    align 010h
>                                    @BLBL4:
> 000001c4 8b 85 4c ff ff ff       mov eax,[ebp-0b4h]; _temp5
> 000001ca 39 85 60 ff ff ff       cmp [ebp-0a0h],eax; I
> 000001d0 7d ce                   jge @BLBL8
> 000001d2 eb 00                   jmp @BLBL11
>                                    align 010h
>                                    @BLBL6:
> 000001d4 8b 85 4c ff ff ff       mov eax,[ebp-0b4h]; _temp5
> 000001da 39 85 60 ff ff ff       cmp [ebp-0a0h],eax; I
> 000001e0 7e be                   jle @BLBL8
>                                    @BLBL11:

Here's another well-known compiler:

       0006     do i = a to b by c;
       0006 A10200        mov  w ax,A
       0009 A30000        mov  w I,ax
       000C A10400        mov  w ax,B
       000F A30800        mov  w *,ax
       0012 A10600        mov  w ax,C
       0015 A30A00        mov  w *,ax
       0018           @1:
       0018 8B1E0A00      mov  w bx,*
       001C E80000        call   ?IE20N
       001F A20C00        mov  b [000Ch],al
       0022 8B1E0000      mov  w bx,I
       0026 2B1E0800      sub  w bx,*
       002A E80000        call   ?IE20N
       002D 8A260C00      mov  b ah,[000Ch]
       0031 3AC4          cmp  b al,ah
       0033 7409          je     @2
       0035 A10A00        mov  w ax,*
       0038 01060000      add  w I,ax
       003C EBDA          jmp    @1
       003E           @2:


0
robin_v (2737)
5/26/2006 2:18:51 PM
This is in agreement with PL/I for OpenVMS.  Interestingly, I consulted =
the
venerable X3.53-1976 to see what it had to say.  There is no definition =
of
alignment, nor is it mentioned in the implementation defined section.  B=
ut
the definition that Mark provided is how I have understood the meaning o=
f
the word, for 40 years.  I think the members of X3J1 had a similar  =

understanding.
Tom

On Fri, 26 May 2006 00:01:44 -0700, Mark Yudkin  =

<myudkinATcompuserveDOTcom@boingboing.org> wrote:

> From the manual:
> <quote>
>
>
> ALIGNED specifies that the data element is aligned on the storage  =

> boundary
> corresponding to its data-type requirement. UNALIGNED specifies that e=
ach
> data element is mapped on the next byte boundary,
> except for fixed-length bit strings, which are mapped on the next bit.=

>
> ,------------------------------'------'-------------------------------=
---------.
> |
> |
> |
>  >>--.-ALIGNED---.----------------------------------------------------=
-----><
> |
> |     '-UNALIGNED-'
> |
> |
> |
> '---------------------------------------------------------------------=
---------'
>
> Defaults are applied at element level. UNALIGNED is the default for bi=
t
> data, character data, graphic data, widechar data and numeric characte=
r
> data. ALIGNED is the default for all other types of data.
>
> Requirements for the ALIGNED attribute are shown in Alignment  =

> requirements.
>
> ,---------------------------------------------------------------------=
--------------.
> | Table 26. Alignment requirements
> |
> |------------------.----------------------.--------------.------------=
--------------|
> |                  |                      | STORAGE      |  ALIGNMENT
> REQUIREMENTS  |
> |                  |                      | REQUIREMENTS
> |-------------.------------|
> |                  |   STORED INTERNALLY  | (BYTES)      |   ALIGNED  =
 |
> UNALIGNED |
> | VARIABLE TYPE    |          AS:         |              |     DATA   =
 |
> DATA    |
> |------------------+----------------------+--------------+------------=
-+------------|
> |                  | ALIGNED:             |              |            =
 |
> |
> |                  | One byte for each    |              |            =
 |  =

> Bit
> |
> |                  | group of 8 bits (or  | ALIGNED:     | Byte       =
 |
> (Data can  |
> |                  | part thereof)        |  CEIL(n/8)   | (Data can  =
 |
> begin on   |
> | BIT (n)          |                      |              | begin on   =
 |  =

> any
> bit in |
> |                  | UNALIGNED:           | UNALIGNED:   | any byte, 0=
 |  =

> any
> byte,  |
> |                  | As many bits as are  | n bits       | through 7) =
 |  =

> 0
> through  |
> |                  | required, regardless |              |            =
 |  =

> 7)
> |
> |                  | of byte boundaries   |              |            =
 |
> |
> |------------------+----------------------+--------------+------------=
-+------------|
> | CHARACTER (n)    | One byte per char-   |       n      |            =
 |
> |
> |                  | acter                |              |            =
 |
> |
> |------------------+----------------------+--------------|            =
 |
> |
> |                  | One byte per char-   |              |            =
 |
> |
> | CHARACTER (n)    | acter plus           |              |            =
 |
> |
> | VARYINGZ         | one byte for the     |      n+1     |            =
 |
> |
> |                  | null                 |              |            =
 |
> |
> |                  | terminator           |              |            =
 |
> |
> |------------------+----------------------+--------------|            =
 |
> |
> | GRAPHIC (n)      | Two bytes per        |      2n      |            =
 |
> |
> |                  | graphic              |              |            =
 |
> |
> |------------------+----------------------+--------------|            =
 |
> |
> |                  | Two bytes per        |              |            =
 |
> |
> | GRAPHIC (n)      | graphic plus         |              |            =
 |
> |
> | VARYINGZ         | two bytes for the    |     2n+2     |            =
 |
> |
> |                  | null                 |              |            =
 |
> |
> |                  | terminator           |              |            =
 |
> |
> |------------------+----------------------+--------------|            =
 |
> |
> | WIDECHAR (n)     | Two bytes per        |      2n      |            =
 |
> |
> |                  | widechar.            |              |            =
 |
> |
> |------------------+----------------------+--------------|            =
 |
> |
> |                  | Two bytes per        |              |            =
 |
> |
> | WIDECHAR (n)     | widechar plus        |              |            =
 |
> |
> | VARYINGZ         | two bytes for the    |     2n+2     |            =
 |
> |
> |                  | null                 |              | Byte       =
 |
> Byte       |
> |                  | terminator           |              | (Data can  =
 |
> (Data can  |
> |------------------+----------------------+--------------| begin on   =
 |
> begin on   |
> |                  |                      |   Number of  | any byte, 0=
 |  =

> any
> byte,  |
> |                  | One byte for each    |    PICTURE   | through 7) =
 |  =

> 0
> through  |
> |                  | PICTURE character    |  characters  |            =
 |  =

> 7)
> |
> | PICTURE          | (except V, K, and    |  other than  |            =
 |
> |
> |                  | the F scaling factor |  V, K, and F |            =
 |
> |
> |                  | specification)       |  specifica-  |            =
 |
> |
> |                  |                      |     tion     |            =
 |
> |
> |------------------+----------------------+--------------|            =
 |
> |
> |                  | Packed decimal       |              |            =
 |
> |
> | DECIMAL FIXED    | format (1/2 byte per | CEIL((p+1)/2 |            =
 |
> |
> | (p,q)            | digit, plus 1/2 byte |              |            =
 |
> |
> |                  | for sign)            |              |            =
 |
> |
> |------------------+----------------------+--------------|            =
 |
> |
> | BINARY           |                      |              |            =
 |
> |
> | FIXED(p,q)       |                      |              |            =
 |
> |
> |                  |                      |              |            =
 |
> |
> | SIGNED           |                      |              |            =
 |
> |
> | 1 <=3D p <=3D 7      |                      |              |        =
     |
> |
> | UNSIGNED         |                      |              |            =
 |
> |
> | 1 <=3D p <=3D 8      |       One byte       |       1      |        =
     |
> |
> |------------------|                      |              |            =
 |
> |
> | ORDINAL          |                      |              |            =
 |
> |
> |                  |                      |              |            =
 |
> |
> | SIGNED           |                      |              |            =
 |
> |
> | 1 <=3D p <=3D 7      |                      |              |        =
     |
> |
> | UNSIGNED         |                      |              |            =
 |
> |
> | 1 <=3D p <=3D 8      |                      |              |        =
     |
> |
> |------------------'----------------------'--------------'------------=
-'------------|
> | Alignment and storage requirements for program control data can vary=

> across sup-  |
> | ported systems.
> |
> |
> |
> | Complex data requires twice as much storage as its real counterpart,=
  =

> but
> the      |
> | alignment requirements are the same.
> |
> '---------------------------------------------------------------------=
--------------'
> ,---------------------------------------------------------------------=
--------------.
> | Table 26. Alignment requirements
> |
> |------------------.----------------------.--------------.------------=
--------------|
> |                  |                      | STORAGE      |  ALIGNMENT
> REQUIREMENTS  |
> |                  |                      | REQUIREMENTS
> |-------------.------------|
> |                  |   STORED INTERNALLY  | (BYTES)      |   ALIGNED  =
 |
> UNALIGNED |
> | VARIABLE TYPE    |          AS:         |              |     DATA   =
 |
> DATA    |
> |------------------+----------------------+--------------+------------=
-+------------|
> |                  | Two-byte prefix plus | ALIGNED:     |            =
 |
> |
> |                  | 1 byte for each      | 2+CEIL(n/8)  |            =
 |
> |
> | BIT(n) VARYING   | group of 8 bits (or  |              |            =
 |
> |
> |                  | part thereof) of the | UNALIGNED:   |            =
 |
> |
> |                  | declared maximum     |  2 bytes+n   |            =
 |
> |
> |                  | length               | bits         |            =
 |
> |
> |------------------+----------------------+--------------|            =
 |
> |
> |                  | Two-byte prefix plus |              |            =
 |
> |
> | CHARACTER(n)     | 1 byte per character |      n+2     |            =
 |
> |
> | VARYING          | of the declared      |              |            =
 |
> |
> |                  | maximum length       |              |            =
 |
> |
> |------------------+----------------------+--------------|            =
 |
> |
> |                  | Two-byte prefix plus |              |            =
 |
> |
> | GRAPHIC(n)       | 2 bytes per graphic  |     2n+2     |            =
 |
> |
> | VARYING          | of the declared      |              |            =
 |
> |
> |                  | maximum length       |              | Halfword   =
 |
> Byte       |
> |------------------+----------------------+--------------| (Data can  =
 |
> (Data can  |
> |                  | Two-byte prefix plus |              | begin on   =
 |
> begin on   |
> | WIDECHAR(n)      | 2 bytes per widechar |     2n+2     | byte 0, 2, =
 |  =

> any
> byte,  |
> | VARYING          | of the declared      |              | 4, or 6)   =
 |  =

> 0
> through  |
> |                  | maximum length       |              |            =
 |  =

> 7)
> |
> |------------------+----------------------+--------------|            =
 |
> |
> | BINARY           |                      |              |            =
 |
> |
> | FIXED(p,q)       |                      |              |            =
 |
> |
> |                  |                      |              |            =
 |
> |
> | SIGNED           |                      |              |            =
 |
> |
> | 8 <=3D p <=3D 15     |                      |              |        =
     |
> |
> | UNSIGNED         |                      |              |            =
 |
> |
> | 9 <=3D p <=3D 16     |       Halfword       |       2      |        =
     |
> |
> |------------------|                      |              |            =
 |
> |
> | ORDINAL          |                      |              |            =
 |
> |
> |                  |                      |              |            =
 |
> |
> | SIGNED           |                      |              |            =
 |
> |
> | 8 <=3D p <=3D 15     |                      |              |        =
     |
> |
> | UNSIGNED         |                      |              |            =
 |
> |
> | 9 <=3D p <=3D 16     |                      |              |        =
     |
> |
> |------------------+----------------------+--------------+------------=
-+------------|
> | BINARY           |                      |              |            =
 |
> |
> | FIXED(p,q)       |                      |              |            =
 |
> |
> |                  |                      |              |            =
 |
> |
> | SIGNED           |                      |              |            =
 |
> |
> | 16 <=3D p <=3D 31    |                      |              |        =
     |
> |
> | UNSIGNED         |                      |              |            =
 |
> |
> | 17 <=3D p <=3D 32    |       Fullword       |              |        =
     |
> |
> |------------------|                      |              | Fullword   =
 |
> Byte       |
> | ORDINAL          |                      |              | (Data can  =
 |
> (Data can  |
> |                  |                      |       4      | begin on   =
 |
> begin on   |
> | SIGNED           |                      |              | byte 0 or  =
 |  =

> any
> byte,  |
> | 16 <=3D p <=3D 31    |                      |              | 4)     =
     |  =

> 0
> through  |
> | UNSIGNED         |                      |              |            =
 |  =

> 7)
> |
> | 17 <=3D p <=3D 32    |                      |              |        =
     |
> |
> |------------------+----------------------|              |            =
 |
> |
> | BINARY FLOAT(p)  |                      |              |            =
 |
> |
> | 1<=3Dp<=3D21         |                      |              |        =
     |
> |
> |------------------| Short floating-point |              |            =
 |
> |
> | DECIMAL FLOAT(p) |                      |              |            =
 |
> |
> | 1<=3Dp<=3D6          |                      |              |        =
     |
> |
> |------------------+----------------------+--------------+------------=
-+------------|
> | POINTER          |           -          |              |            =
 |
> |
> |------------------+----------------------|              |            =
 |
> |
> | HANDLE           |           -          |              |            =
 |
> |
> |------------------+----------------------|              |            =
 |
> |
> | OFFSET           |           -          |       4      |            =
 |
> Byte       |
> |------------------+----------------------|              | Fullword   =
 |
> (Data can  |
> | FILE             |           -          |              | (Data can  =
 |
> begin on   |
> |------------------+----------------------|              | begin on   =
 |  =

> any
> byte,  |
> | ENTRY LIMITED    |           -          |              | byte 0 or  =
 |  =

> 0
> through  |
> |------------------+----------------------+--------------| 4)         =
 |  =

> 7)
> |
> | ENTRY            |           -          |              |            =
 |
> |
> |------------------+----------------------|       8      |            =
 |
> |
> | LABEL or FORMAT  |           -          |              |            =
 |
> |
> |------------------+----------------------+--------------|            =
 |
> |
> | TASK             |           -          |      16      |            =
 |
> |
> |------------------'----------------------'--------------'------------=
-'------------|
> | Alignment and storage requirements for program control data can vary=

> across sup-  |
> | ported systems.
> |
> |
> |
> | Complex data requires twice as much storage as its real counterpart,=
  =

> but
> the      |
> | alignment requirements are the same.
> |
> '---------------------------------------------------------------------=
--------------'
> ,---------------------------------------------------------------------=
--------------.
> | Table 26. Alignment requirements
> |
> |------------------.----------------------.--------------.------------=
--------------|
> |                  |                      | STORAGE      |  ALIGNMENT
> REQUIREMENTS  |
> |                  |                      | REQUIREMENTS
> |-------------.------------|
> |                  |   STORED INTERNALLY  | (BYTES)      |   ALIGNED  =
 |
> UNALIGNED |
> | VARIABLE TYPE    |          AS:         |              |     DATA   =
 |
> DATA    |
> |------------------+----------------------+--------------+------------=
-+------------|
> |                  |                      |              |            =
 |
> AREA data  |
> | AREA             |           -          |    16+size   |            =
 |
> cannot be  |
> |                  |                      |              |            =
 |
> unaligned  |
> |------------------+----------------------+--------------|
> |------------|
> | BINARY           |                      |              |            =
 |
> |
> | FIXED(p,q)       |                      |              |            =
 |
> |
> |                  |                      |              |            =
 |
> |
> | SIGNED           |           -          |              |            =
 |
> |
> | 32 <=3D p <=3D 63    |                      |              |        =
     |
> |
> | UNSIGNED         |                      |              | Doubleword =
 |
> |
> | 33 <=3D p <=3D 64    |                      |       8      | (Data c=
an   |
> byte       |
> |------------------+----------------------|              | begin on   =
 |
> (Data can  |
> | BINARY FLOAT(p)  |                      |              | byte 0)    =
 |
> begin on   |
> | 22 <=3D p <=3D 53    |                      |              |        =
     |  =

> any
> byte,  |
> |------------------|  Long floating-point |              |            =
 |  =

> 0
> through  |
> | DECIMAL FLOAT(p) |                      |              |            =
 |  =

> 7)
> |
> | 7 <=3D p <=3D 16     |                      |              |        =
     |
> |
> |------------------+----------------------+--------------|            =
 |
> |
> | BINARY FLOAT(p)  |                      |              |            =
 |
> |
> |   54<=3Dp          |  Extended floating-  |              |          =
   |
> |
> |------------------|         point        |      16      |            =
 |
> |
> | DECIMAL FLOAT(p) |                      |              |            =
 |
> |
> |   17<=3Dp          |                      |              |          =
   |
> |
> |------------------'----------------------'--------------'------------=
-'------------|
> | Alignment and storage requirements for program control data can vary=

> across sup-  |
> | ported systems.
> |
> |
> |
> | Complex data requires twice as much storage as its real counterpart,=
  =

> but
> the      |
> | alignment requirements are the same.
> |
> '---------------------------------------------------------------------=
--------------'
>
> ALIGNED or UNALIGNED can be specified for element, array, structure, o=
r
> union variables. The application of either attribute to a structure or=
  =

> union
> is equivalent to applying the attribute to all contained elements
> that are not explicitly declared ALIGNED or UNALIGNED.
>
> The following example illustrates the effect of ALIGNED and UNALIGNED
> declarations for a structure and its elements:
>
>   declare 1 S,
>             2 X bit(2),      /* unaligned by default  */
>             2 A aligned,     /* aligned explicitly    */
>               3 B,           /* aligned from A        */
>               3 C unaligned, /* unaligned explicitly  */
>                 4 D,         /* unaligned from C      */
>                 4 E aligned, /* aligned explicitly    */
>                 4 F,         /* unaligned from C      */
>               3 G,           /* aligned from A        */
>             2 H;             /* aligned by default    */
>
> For more information about structures and unions, refer to Structures =
and
> Unions.
>
> </quote>
>
> So unless we're arguing about the special case "Alignment and storage
> requirements for program control data", to which you need to refer the=

> programming guide, I stand by my case. If you are referring to this  =

> special
> case, I would point out that program control data cannot be included i=
n
> record I/O.
>
> So for example, the manual explicitly disallows alignment on bit  =

> boundaries,
> even for UNALIGNED, with the sole explicit exception of bit strings.
>
> In particular, the machine's requirements are irrelevant. In fact, the=
  =

> PL/I
> requirements are sometimes in direct contradiction to the machine's
> requirements, thus forcing the compiler to generate additional code to=

> handle the issues. Here are some cases:
> 1) widechar and graphic are BYTE aligned (fixed or varz). These  =

> characters
> are halfword values.
> 2) extended float (16-byte) is aligned on 8-byte boundaries.
>
> "robin" <robin_v@bigpond.com> wrote in message
> news:l9udg.10796$S7.9220@news-server.bigpond.net.au...
>> "Mark Yudkin" <myudkinATcompuserveDOTcom@boingboing.org> wrote in  =

>> message
>> news:4475869c$0$722$5402220f@news.sunrise.ch...
>>> Wrong again.
>>
>> No, this time you're wrong.
>>
>> The positioning of fields is system dependent.
>> It depends on the size of a word, halfword, double words,
>> whether or not data must be aligned on those words,
>> halfwords, and double words.  In a bit-addressible machine,
>> padding out fields would be unnecessary.
>>    In a machine lacking any requirement for alignment,
>> no padding would be necessary between fields other than
>> bit fields (assuming byte addressible machine).
>>
>>    You spoke of interchanging files.
>>    That is system dependant.
>>
>>> There is absolutely nothing system dependent about structure
>>> mapping in PL/I. The rules for structure mapping are defined by the =
 =

>>> PL/I
>>> reference down to the tiniest detail, and are deliberately
>>> system-independent. Take any structure definition and follow the rul=
es  =

>>> in
>>> the manual and you'll know every last bit of the structure mapping.
>>>
>>> "robin" <robin_v@bigpond.com> wrote in message
>>> news:4H9dg.10255$S7.9178@news-server.bigpond.net.au...
>>> > From: "Mark Yudkin" <myudkinATcompuserveDOTcom@boingboing.org>
>>> > Newsgroups: comp.lang.pl1
>>> > Sent: Sunday, May 21, 2006 6:46 PM
>>> >
>>> >> Struture alignment rules are part of the language definition. Any=

>>> >> compiler
>>> >> not yielding the same result is faulty, as it would make it  =

>>> impossible
>>> >> to
>>> >> interchange files.
>>> >
>>> > The mapping of the components of a structure is
>>> > system dependent, of course.
>>
>>
>
>



-- =

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
0
tom284 (1839)
5/26/2006 2:22:44 PM
Mark Yudkin wrote:
> They are not. The meaning is defined by PL/I and on accasion even 
> contradicts the machine's hardware requirements.

"The meaning is defined by PL/I" is a bit vague. ANSI PL/I? The ULD?

The definition in section 8.5 of the current Enterprise PL/I Language 
Reference is written in the terminology of 360-family equipment, 
although by changing the vocabulary a little, it might apply to x86, 
AS/400, and Power. But no matter how liberally interpreted, it would not 
apply at all to, say, a 7094 or a 1401.

-- 
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
   -- Charles Williams.  "Taliessin through Logres: Prelude"
0
jwkenne (1442)
5/26/2006 6:29:46 PM
Tom LINDEN wrote:
> On Wed, 24 May 2006 19:51:31 -0700, John W. Kennedy 
> <jwkenne@attglobal.net> wrote:
> 
>> Tom LINDEN wrote:
>>> On Wed, 24 May 2006 12:21:14 -0700, glen herrmannsfeldt 
>>> <gah@ugcs.caltech.edu> wrote:
>>>
>>>> I wrote this one thinking that changes to L would take effect within
>>>> the loop, but in any case with the ABS the compiler can be sure that 
>>>> the increment is never negative, and optimize accordingly.
>>>>
>>> Doesn't matter, the optimization is the samer anyway.
>>
>> It can't be the same. The /meaning/ of BY depends on the sign.
>>
> doesn't matter.  either it is a constant or it is an expression.  You
> create the trees and the optimizer will do what it can, maybe fold 
> constants,
> create shadow variables, many things.  You may end up generating 
> differnet instructions sequences depending on the architecure.  VAX had, 
> for example,
> a single instruction that did, add compare and branch.  On risc machines
> it is more cumbersome

The problem is that what comparison is done depends on the sign of the 
BY. In principle, a compiler that knows that the BY is positive (or 
negative) can create a single test and branch. A compiler that does not 
know the sign of BY must either use a special 
add-and-compare-and-branch-if-high-if-addend-is-positive-or-branch-if-low-if-addend-is-negative 
instruction (I don't know of any architecture that includes one), or 
else must use two nested branches, or play around with something like 
the EX instruction or a nested subroutine call, any one of which is 
likely to upset pipelining.

On any machine I know, 'BY ABS(expression)' is theoretically capable of 
better optimization, possibly massively better optimization, than is 'BY 
expression', except where 'expression' is UNSIGNED.

-- 
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
   -- Charles Williams.  "Taliessin through Logres: Prelude"
0
jwkenne (1442)
5/26/2006 6:39:36 PM
robin wrote:
> "James J. Weinkam" <jjw@cs.sfu.ca> wrote in message
> news:x1ndg.23474$zn1.19516@clgrps13...
> 
>>robin wrote:
>>
>>>"James J. Weinkam" <jjw@cs.sfu.ca> wrote in message
>>>news:XUadg.22107$zn1.13422@clgrps13...
> 
> 
>>>>The practical issue is how the compiled code is going to "remember" this
>>>>knowledge.  Unless the compiler generates two copies of the body or invokes
>>>>it as a subroutine from positive and negative instances of the
>>>>increment-test-repeat logic, when the bottom of the body is reached it is
>>>
>>>going
>>>
>>>>to have to rediscover the sign of the increment to choose the proper test.
>>>
>>>No it doesn't, as I pointed out earlier in this thread.
>>>The pre-loop code only has to place zero or k
>>>in a register.
>>>    Just before the test - at the tail of the loop -
>>>a branch instruction using that value as an index
>>>selects the appropriate code for performing the test.
>>>(the value zero or k is the means by which the appropriate
>>>code sequence is selected.)
> 
> 
>>That's just an efficient way to rediscover the sign.  It also presupposes that
>>there is a register available to dedicate to that purpose for the duration of
>>the loop.  That indexed branch is execution time overhead
> 
> 
> Indeed so, but a minuscule overhead.
> 
True, although if the body is short it can still amount to a significant 
proportion of the total execution time of the loop.

> 
>>that wouldn't be
>>needed if the compiler knew that the sign would always be the same; it could
>>just fall through to the test code.
> 
> 
> There are other more efficient ways, requiring no loop overhead,
> but these would make the code non-reentrant.
> 
> 
> 
The only way I can see to have absolutely no per repitition overhead is for the 
compiler to generate two copies of the body.  Since it sometimes unrolls loops 
by a factor of four or even more, this does not seem unreasonable if the 
additional branch is a large enough fraction of the body.
0
jjw (608)
5/26/2006 7:01:28 PM
On Fri, 26 May 2006 11:39:36 -0700, John W. Kennedy  
<jwkenne@attglobal.net> wrote:

> Tom LINDEN wrote:
>> On Wed, 24 May 2006 19:51:31 -0700, John W. Kennedy  
>> <jwkenne@attglobal.net> wrote:
>>
>>> Tom LINDEN wrote:
>>>> On Wed, 24 May 2006 12:21:14 -0700, glen herrmannsfeldt  
>>>> <gah@ugcs.caltech.edu> wrote:
>>>>
>>>>> I wrote this one thinking that changes to L would take effect within
>>>>> the loop, but in any case with the ABS the compiler can be sure that  
>>>>> the increment is never negative, and optimize accordingly.
>>>>>
>>>> Doesn't matter, the optimization is the samer anyway.
>>>
>>> It can't be the same. The /meaning/ of BY depends on the sign.
>>>
>> doesn't matter.  either it is a constant or it is an expression.  You
>> create the trees and the optimizer will do what it can, maybe fold  
>> constants,
>> create shadow variables, many things.  You may end up generating  
>> differnet instructions sequences depending on the architecure.  VAX  
>> had, for example,
>> a single instruction that did, add compare and branch.  On risc machines
>> it is more cumbersome
>
> The problem is that what comparison is done depends on the sign of the  
> BY. In principle, a compiler that knows that the BY is positive (or  
> negative) can create a single test and branch. A compiler that does not  
> know the sign of BY must either use a special  
> add-and-compare-and-branch-if-high-if-addend-is-positive-or-branch-if-low-if-addend-is-negative  
> instruction (I don't know of any architecture that includes one), or  
> else must use two nested branches, or play around with something like  
> the EX instruction or a nested subroutine call, any one of which is  
> likely to upset pipelining.
>
> On any machine I know, 'BY ABS(expression)' is theoretically capable of  
> better optimization, possibly massively better optimization, than is 'BY  
> expression', except where 'expression' is UNSIGNED.
>
Why do you think it is "theoretically capable of better optimization?   
What I
am telling you it doesn't matter, and even if it did, it would be a  
special case
which the optimizer would pick up anyway.



0
tom284 (1839)
5/26/2006 8:29:12 PM
Tom Linden wrote:
> On Fri, 26 May 2006 11:39:36 -0700, John W. Kennedy 
> <jwkenne@attglobal.net> wrote:
> 
>> Tom LINDEN wrote:
>>> On Wed, 24 May 2006 19:51:31 -0700, John W. Kennedy 
>>> <jwkenne@attglobal.net> wrote:
>>>
>>>> Tom LINDEN wrote:
>>>>> On Wed, 24 May 2006 12:21:14 -0700, glen herrmannsfeldt 
>>>>> <gah@ugcs.caltech.edu> wrote:
>>>>>
>>>>>> I wrote this one thinking that changes to L would take effect within
>>>>>> the loop, but in any case with the ABS the compiler can be sure 
>>>>>> that the increment is never negative, and optimize accordingly.
>>>>>>
>>>>> Doesn't matter, the optimization is the samer anyway.
>>>>
>>>> It can't be the same. The /meaning/ of BY depends on the sign.
>>>>
>>> doesn't matter.  either it is a constant or it is an expression.  You
>>> create the trees and the optimizer will do what it can, maybe fold 
>>> constants,
>>> create shadow variables, many things.  You may end up generating 
>>> differnet instructions sequences depending on the architecure.  VAX 
>>> had, for example,
>>> a single instruction that did, add compare and branch.  On risc machines
>>> it is more cumbersome
>>
>> The problem is that what comparison is done depends on the sign of the 
>> BY. In principle, a compiler that knows that the BY is positive (or 
>> negative) can create a single test and branch. A compiler that does 
>> not know the sign of BY must either use a special 
>> add-and-compare-and-branch-if-high-if-addend-is-positive-or-branch-if-low-if-addend-is-negative 
>> instruction (I don't know of any architecture that includes one), or 
>> else must use two nested branches, or play around with something like 
>> the EX instruction or a nested subroutine call, any one of which is 
>> likely to upset pipelining.
>>
>> On any machine I know, 'BY ABS(expression)' is theoretically capable 
>> of better optimization, possibly massively better optimization, than 
>> is 'BY expression', except where 'expression' is UNSIGNED.
>>
> Why do you think it is "theoretically capable of better optimization?  
> What I
> am telling you it doesn't matter, and even if it did, it would be a 
> special case
> which the optimizer would pick up anyway.

You keep saying "it doesn't matter" and "it would happen anyway" without 
explaining what you mean. It certainly matters on some hardware whether 
a tight loop has a conditional branch in the middle of it, and, for the 
rest, you seem to be saying "all optimizers are perfect".

-- 
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
   -- Charles Williams.  "Taliessin through Logres: Prelude"
0
jwkenne (1442)
5/26/2006 8:37:30 PM
On Fri, 26 May 2006 13:37:30 -0700, John W. Kennedy  
<jwkenne@attglobal.net> wrote:

> You keep saying "it doesn't matter" and "it would happen anyway" without  
> explaining what you mean. It certainly matters on some hardware whether  
> a tight loop has a conditional branch in the middle of it, and, for the  
> rest, you seem to be saying "all optimizers are perfect".
>
No, in fact they aren't, as I stated in another post.  Why is it any  
different
(to take the trivial case) to add, compare and branch or to subtract,
compare and branch?
0
tom284 (1839)
5/26/2006 9:17:32 PM
Mark Yudkin wrote:
> From the manual:
> <quote>
> 
> 
> ALIGNED specifies that the data element is aligned on the storage boundary 
> corresponding to its data-type requirement. UNALIGNED specifies that each 
> data element is mapped on the next byte boundary,
> except for fixed-length bit strings, which are mapped on the next bit.

I just wasted 1/2 hour trying to find the definition of ALIGNED in the 
ANSI standard.  Some day I'm going to have to OCR the d@mned thing.  I 
think your quote defines it: "corresponding to its data-type 
requirement."  I believe this is system dependent.  Some word machines 
(Multics, IIRC), for example, will, I believe,  align "BIT(1) ALIGNED" 
at a word boundary.

0
Peter_Flass (956)
5/26/2006 9:56:50 PM
Mark Yudkin wrote:


> ALIGNED specifies that the data element is aligned on the storage boundary 
> corresponding to its data-type requirement. UNALIGNED specifies that each 
> data element is mapped on the next byte boundary,
> except for fixed-length bit strings, which are mapped on the next bit.

Say, for example, one were writing a PL/I compiler for the DEC PDP-10
(or IBM 7090) with 36 bit words.  Where is the next byte boundary?

It is hard to see how it couldn't be system dependent in many cases.

-- glen

0
gah (12851)
5/26/2006 10:44:47 PM
robin wrote:

(I wrote)

>>Oh, I almost

>>    DO I=1 TO I;


> There's nothing wrong with that.
> It's well-defined.

Yes.  I had forgotten that it was well defined until this discussion.
It doesn't work very will in C, for example:

for(i=1;i<=i;i++)

-- glen


0
gah (12851)
5/26/2006 10:48:19 PM
Peter Flass wrote:

(I wrote(

>>  DCL X CHAR(10);
>>  DO X='  1' TO '  100' BY '1';
>>     PUT SKIP LIST(SQRT(X));
>>  END;

>> the number of spaces in the constant is important, and I might have it
>> wrong.  The loop compare is done as characters not as a numeric value.

> I'd have to guess that it does the arithmetic in decimal and then 
> reconverts the result to character.  Apparently, from what you say, it's 
> doing the compare as character (makes sense, sort of).  It's fun poking 
> into the odd corners of the language.

The SQRT is done in double precision floating point.  The machine I 
first ran this on did FIXED DECIMAL in 32 bit binary arithmetic.
(IBM CALL/OS)  Presumably the conversion rules say what it gets 
converted to for the increment, but I forget.

The numeric to character conversion is related to that for PUT LIST, 
which results in some blanks on the left.  If not done with the right 
number of blanks, it is either an infinite loop or never loops at all.

-- glen

0
gah (12851)
5/26/2006 10:55:13 PM
glen herrmannsfeldt wrote:
> Peter Flass wrote:
> 
> (I wrote(
> 
>>>  DCL X CHAR(10);
>>>  DO X='  1' TO '  100' BY '1';
>>>     PUT SKIP LIST(SQRT(X));
>>>  END;
> 
> 
>>> the number of spaces in the constant is important, and I might have it
>>> wrong.  The loop compare is done as characters not as a numeric value.
> 
> 
>> I'd have to guess that it does the arithmetic in decimal and then 
>> reconverts the result to character.  Apparently, from what you say, 
>> it's doing the compare as character (makes sense, sort of).  It's fun 
>> poking into the odd corners of the language.
> 
> 
> The SQRT is done in double precision floating point.  The machine I 
> first ran this on did FIXED DECIMAL in 32 bit binary arithmetic.
> (IBM CALL/OS)  Presumably the conversion rules say what it gets 
> converted to for the increment, but I forget.
> 
> The numeric to character conversion is related to that for PUT LIST, 
> which results in some blanks on the left.  If not done with the right 
> number of blanks, it is either an infinite loop or never loops at all.
> 
> -- glen
> 
You're all whistling Dixie.

Check out the conversion rules for character strings to/from arithmetic.  There 
are two cases.

1.  X=c; where X is some coded arithmetic variable and c is a character 
expression (or variable or constant).  In this case, provided c represents a 
valid real or complex value its attributes are deduced and its value is 
converted according to the usual rules to the attributes of X; it is essentially 
like list directed input.

2.  In an arithmetic expression involving a non trivial operation, a character 
string appears as an operand.  In this case the arithmetic value the string 
operand represents is converted to the attributes that a FIXED DECIMAL(M,0) 
operand would have been converted in the same context, where M is the maximum 
allowable fixed decimal precision.  (All LRM's that I have seen after the 
Optimizing Compiler fail to state the (M,0) part, a typo that no one seems to 
have noticed for something like 15 years.)

In the case at hand, since everything is sight is a character string containing 
an integer value and we are dealing with a non trivial operational expression, 
the intermediate fixed decimal target is going to be fixed decimal(M,0).

Consequently, upon conversion from fixed decimal back to character, the length 
is going to be M+3.

Since string assignment is done from left to right, the index variable has to be 
M+3 or more in length or you are going to be in trouble, since otherwise you 
will lose some or all of the business part of the converted string assigned to X 
in as much as it is right justified.

Thus in a system where M=15, X must be at least char(18) and in a situation 
where M=31, X must be at least char(34).

I am using limits(fixeddec(31)), so in my case I have to declare X char(34) if I 
expect to get anywhere.

This sort of thing is not for the faint hearted.
0
jjw (608)
5/27/2006 5:04:17 AM
James J. Weinkam wrote:

> [...]
> 2.  In an arithmetic expression involving a non trivial operation, a 
> character string appears as an operand.  In this case the arithmetic 
> value the string operand represents is converted to the attributes that 
> a FIXED DECIMAL(M,0) operand would have been converted in the same 
> context, where M is the maximum allowable fixed decimal precision.  (All 
> LRM's that I have seen after the Optimizing Compiler fail to state the 
> (M,0) part, a typo that no one seems to have noticed for something like 
> 15 years.)
> 
> In the case at hand, since everything is sight is a character string 
> containing an integer value and we are dealing with a non trivial 
> operational expression, the intermediate fixed decimal target is going 
> to be fixed decimal(M,0).
> 
> Consequently, upon conversion from fixed decimal back to character, the 
> length is going to be M+3.
> 
> Since string assignment is done from left to right, the index variable 
> has to be M+3 or more in length or you are going to be in trouble, since 
> otherwise you will lose some or all of the business part of the 
> converted string assigned to X in as much as it is right justified.
> 
> Thus in a system where M=15, X must be at least char(18) and in a 
> situation where M=31, X must be at least char(34).
> 
> I am using limits(fixeddec(31)), so in my case I have to declare X 
> char(34) if I expect to get anywhere.
> 
> This sort of thing is not for the faint hearted.

One of the reasons I learned to use PUT EDIT STRING rather than 
assigning numeric values to string variables.  :-)


Bob Lidral
lidral  at  alum  dot  mit  dot  edu
0
5/27/2006 7:15:02 AM
glen herrmannsfeldt wrote:
> Mark Yudkin wrote:
> 
> 
>> ALIGNED specifies that the data element is aligned on the storage 
>> boundary corresponding to its data-type requirement. UNALIGNED 
>> specifies that each data element is mapped on the next byte boundary,
>> except for fixed-length bit strings, which are mapped on the next bit.
> 
> 
> Say, for example, one were writing a PL/I compiler for the DEC PDP-10
> (or IBM 7090) with 36 bit words.  Where is the next byte boundary?
> 
> It is hard to see how it couldn't be system dependent in many cases.
> 
> -- glen
> 
IIRC, DEC named or renamed that system the DECSystem-10 so people
wouldn't call it a PDP-10.  They wanted people to think of the 10 as a
"real", "production", or maybe even "mainframe" computer and felt the
"PDP-" prefix would give the impression it was "just" a mini-computer
like the PDP-8 or PDP-11.

In any case, I seem to remember the documentation for the DECSystem-10
defined a "byte" as any contiguous series of bits (there must have been
lower and upper bounds on the size of a byte -- perhaps dictated by the
width of that field in the instruction formats -- but I don't remember
what they were).  Byte-manipulation instructions used the initial bit
offset and either the final bit offset or bit length of the byte field
to specify the field.  I don't remember whether bytes were allowed to
extend over word boundaries.

In such an architecture, byte size is unrelated to character size and
the concept of byte boundary alignment for execution efficiency has a
different meaning than on an architecture such as the 360.


Bob Lidral
lidral  at  alum  dot  mit  dot  edu
0
5/27/2006 7:16:16 AM
James J. Weinkam wrote:
(snip)

>>>>  DCL X CHAR(10);
>>>>  DO X='  1' TO '  100' BY '1';
>>>>     PUT SKIP LIST(SQRT(X));
>>>>  END;

(snip)

> You're all whistling Dixie.

> Check out the conversion rules for character strings to/from 
> arithmetic.  There are two cases.


(snip)

> 2.  In an arithmetic expression involving a non trivial operation, a 
> character string appears as an operand.  In this case the arithmetic 
> value the string operand represents is converted to the attributes that 
> a FIXED DECIMAL(M,0) operand would have been converted in the same 
> context, where M is the maximum allowable fixed decimal precision.  (All 
> LRM's that I have seen after the Optimizing Compiler fail to state the 
> (M,0) part, a typo that no one seems to have noticed for something like 
> 15 years.)

I first did this 30 years ago, when I was in high school.  (Wow, that 
long ago?)  I don't remember the length I used for the variable, but 
note that the FIXED DECIMAL(M,0) is only for the intermediate values in 
incrementing the DO variable.  The result is then converted back to 
CHAR, with the appropriate length.  It comes back with some number of 
blanks on the left, if I remember, that is, the value is left justified 
after some number of blanks.   The CALL/OS compiler is somewhat simpler 
than the F compiler, and does FIXED DECIMAL in binary.

> In the case at hand, since everything is sight is a character string 
> containing an integer value and we are dealing with a non trivial 
> operational expression, the intermediate fixed decimal target is going 
> to be fixed decimal(M,0).

> Consequently, upon conversion from fixed decimal back to character, the 
> length is going to be M+3.

It may be M+3, but I believe that is three blanks (or two and a sign) 
followed by the most significant digit.

> Since string assignment is done from left to right, the index variable 
> has to be M+3 or more in length or you are going to be in trouble, since 
> otherwise you will lose some or all of the business part of the 
> converted string assigned to X in as much as it is right justified.

I may have used more than CHAR(10), but see above.

> Thus in a system where M=15, X must be at least char(18) and in a 
> situation where M=31, X must be at least char(34).

> I am using limits(fixeddec(31)), so in my case I have to declare X 
> char(34) if I expect to get anywhere.

Try it and see what happens.

-- glen

0
gah (12851)
5/27/2006 7:19:39 AM
Tom Linden wrote:
> On Fri, 26 May 2006 13:37:30 -0700, John W. Kennedy 
> <jwkenne@attglobal.net> wrote:
> 
>> You keep saying "it doesn't matter" and "it would happen anyway" 
>> without explaining what you mean. It certainly matters on some 
>> hardware whether a tight loop has a conditional branch in the middle 
>> of it, and, for the rest, you seem to be saying "all optimizers are 
>> perfect".
>>
> No, in fact they aren't, as I stated in another post.  Why is it any 
> different
> (to take the trivial case) to add, compare and branch or to subtract,
> compare and branch?

Because the definition of PL/I DO...BY says that two different compare 
and branches are necessary, depending on the sign of BY, and, in the 
general case, this means that when BY gives a variable or expression, 
run-time code has to choose between the two.

-- 
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
   -- Charles Williams.  "Taliessin through Logres: Prelude"
0
jwkenne (1442)
5/27/2006 12:48:03 PM
On Sat, 27 May 2006 05:48:03 -0700, John W. Kennedy  =

<jwkenne@attglobal.net> wrote:

> Tom Linden wrote:
>> On Fri, 26 May 2006 13:37:30 -0700, John W. Kennedy  =

>> <jwkenne@attglobal.net> wrote:
>>
>>> You keep saying "it doesn't matter" and "it would happen anyway"  =

>>> without explaining what you mean. It certainly matters on some  =

>>> hardware whether a tight loop has a conditional branch in the middle=
  =

>>> of it, and, for the rest, you seem to be saying "all optimizers are =
 =

>>> perfect".
>>>
>> No, in fact they aren't, as I stated in another post.  Why is it any =
 =

>> different
>> (to take the trivial case) to add, compare and branch or to subtract,=

>> compare and branch?
>
> Because the definition of PL/I DO...BY says that two different compare=
  =

> and branches are necessary, depending on the sign of BY, and, in the  =

> general case, this means that when BY gives a variable or expression, =
 =

> run-time code has to choose between the two.
>
I think we are confusing two different things here.  Firstly,  you alway=
s
need to execute some number of tests to determine whether to enter the
loop or to branch to loop_exit, lets call the entry point loop_head.
These tests determing whether the loop is ascending or descending.  If t=
his
is not knowable at compile time, then two loops are correspondingly  =

created,
a test and branch to the correct one is executed at runtime.

Secondly, you move all the tests, preserving the order, to a point just
above loop_exit.  The last of these tests will branch to loop_head if tr=
ue
or drop to loop_exit if false.  This usually requires inversion of the
logic.  so if you had DO I =3D J to K by L; then the last test would rea=
d
branch_true(I =3D I + L <=3D K) loop_head,   and >=3D in other case.  If=
 J,K and  =

L
are known at compile time things are obviously much simpler.

The treatment is general and uniform and as loop analysis proceeds furth=
er
simplifications of the code could ensue based on what is known.  This is=

how I have always done it both for fortran and PL/I.
Tom


-- =

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
0
tom284 (1839)
5/27/2006 2:06:27 PM
"James J. Weinkam" <jjw@cs.sfu.ca> wrote in message
news:cgIdg.35559$Qq.15429@clgrps12...
> robin wrote:
> > "James J. Weinkam" <jjw@cs.sfu.ca> wrote in message
> > news:x1ndg.23474$zn1.19516@clgrps13...
> >
> >>robin wrote:
> >>
> >>>"James J. Weinkam" <jjw@cs.sfu.ca> wrote in message
> >>>news:XUadg.22107$zn1.13422@clgrps13...
> >
> >>>>The practical issue is how the compiled code is going to "remember" this
> >>>>knowledge.  Unless the compiler generates two copies of the body or
invokes
> >>>>it as a subroutine from positive and negative instances of the
> >>>>increment-test-repeat logic, when the bottom of the body is reached it is
> >>>
> >>>going
> >>>
> >>>>to have to rediscover the sign of the increment to choose the proper test.
> >>>
> >>>No it doesn't, as I pointed out earlier in this thread.
> >>>The pre-loop code only has to place zero or k
> >>>in a register.
> >>>    Just before the test - at the tail of the loop -
> >>>a branch instruction using that value as an index
> >>>selects the appropriate code for performing the test.
> >>>(the value zero or k is the means by which the appropriate
> >>>code sequence is selected.)
> >
> >
> >>That's just an efficient way to rediscover the sign.  It also presupposes
that
> >>there is a register available to dedicate to that purpose for the duration
of
> >>the loop.  That indexed branch is execution time overhead
>
> > Indeed so, but a minuscule overhead.
> >
> True, although if the body is short it can still amount to a significant
> proportion of the total execution time of the loop.

Well, if the loop is short enough for that, then it's
better to emit two copies of the loop, and to select
one or the other depending on the sign,
That way, there's no loop overhead.

However, I dispute that it is ever a "significant proportion"
of the total execution time of the loop.

In which case, you have no case.

    The code for a PC loop (posted yesterday) requires
12 instructions.  One extra instruction will scarcely
be noticeable.
How many seconds extra will it take if the loop is executed
1,000,000 times?


0
robin_v (2737)
5/27/2006 2:29:28 PM
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:CZmdnSqxhLSvGurZ4p2dnA@comcast.com...
> Peter Flass wrote:
>
> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
>
> >>  DCL X CHAR(10);
> >>  DO X='  1' TO '  100' BY '1';
> >>     PUT SKIP LIST(SQRT(X));
> >>  END;
>
> >> the number of spaces in the constant is important, and I might have it
> >> wrong.

You do have it wrong.

>  The loop compare is done as characters not as a numeric value.
>
> > I'd have to guess that it does the arithmetic in decimal and then
> > reconverts the result to character.  Apparently, from what you say, it's
> > doing the compare as character (makes sense, sort of).  It's fun poking
> > into the odd corners of the language.
>
> The SQRT is done in double precision floating point.  The machine I
> first ran this on did FIXED DECIMAL in 32 bit binary arithmetic.
> (IBM CALL/OS)  Presumably the conversion rules say what it gets
> converted to for the increment, but I forget.
>
> The numeric to character conversion is related to that for PUT LIST,
> which results in some blanks on the left.  If not done with the right
> number of blanks, it is either an infinite loop or never loops at all.

It raises the STRINGSIZE condition when the string variable
is too short.  If it is not enabled, the program is in error.
(Well, it's in error in either case.)
Alternatively, it raises the CONVERSION error.

A better loop, if you want to waste time, it to write
do forever; end;


0
robin_v (2737)
5/27/2006 2:29:29 PM
"Tom Linden" <tom@kednos.com> wrote in message
news:op.s96f3iaazgicya@hyrrokkin...
> On Fri, 26 May 2006 13:37:30 -0700, John W. Kennedy
> <jwkenne@attglobal.net> wrote:
>
> > You keep saying "it doesn't matter" and "it would happen anyway" without
> > explaining what you mean. It certainly matters on some hardware whether
> > a tight loop has a conditional branch in the middle of it, and, for the
> > rest, you seem to be saying "all optimizers are perfect".
> >
> No, in fact they aren't, as I stated in another post.  Why is it any
> different
> (to take the trivial case) to add, compare and branch or to subtract,
> compare and branch?

He is saying that one way is to have the code generator
prepare two sets of tests when the sign of the increment
is unknown :   one for a positve increment and
the other for a negative increment.


0
robin_v (2737)
5/27/2006 2:29:32 PM
On Sat, 27 May 2006 07:29:32 -0700, robin <robin_v@bigpond.com> wrote:

> "Tom Linden" <tom@kednos.com> wrote in message
> news:op.s96f3iaazgicya@hyrrokkin...
>> On Fri, 26 May 2006 13:37:30 -0700, John W. Kennedy
>> <jwkenne@attglobal.net> wrote:
>>
>> > You keep saying "it doesn't matter" and "it would happen anyway"  =

>> without
>> > explaining what you mean. It certainly matters on some hardware  =

>> whether
>> > a tight loop has a conditional branch in the middle of it, and, for=
  =

>> the
>> > rest, you seem to be saying "all optimizers are perfect".
>> >
>> No, in fact they aren't, as I stated in another post.  Why is it any
>> different
>> (to take the trivial case) to add, compare and branch or to subtract,=

>> compare and branch?
>
> He is saying that one way is to have the code generator
> prepare two sets of tests when the sign of the increment
> is unknown :   one for a positve increment and
> the other for a negative increment.
>
Actually I do it before Code Gen at the intermediate code level
in the optimization phase prior.
0
tom284 (1839)
5/27/2006 2:36:10 PM
robin wrote:
> "James J. Weinkam" <jjw@cs.sfu.ca> wrote in message
> news:cgIdg.35559$Qq.15429@clgrps12...

(snip)

>>True, although if the body is short it can still amount to a significant
>>proportion of the total execution time of the loop.

(snip)

> However, I dispute that it is ever a "significant proportion"
> of the total execution time of the loop.

> In which case, you have no case.

>     The code for a PC loop (posted yesterday) requires
> 12 instructions.  One extra instruction will scarcely
> be noticeable.

You haven't been following processor development.  Branch prediction
is a very important part of keeping current processors pipelines filled.
A mispredicted branch could easily take more time than 12 instructions,
and indexed branches are always mispredicted.

> How many seconds extra will it take if the loop is executed
> 1,000,000 times?

How many if that loop is executed 1,000,000 times?

-- glen

0
gah (12851)
5/27/2006 5:38:40 PM
On Sat, 27 May 2006 10:38:40 -0700, glen herrmannsfeldt  =

<gah@ugcs.caltech.edu> wrote:

> robin wrote:
>> "James J. Weinkam" <jjw@cs.sfu.ca> wrote in message
>> news:cgIdg.35559$Qq.15429@clgrps12...
>
> (snip)
>
>>> True, although if the body is short it can still amount to a  =

>>> significant
>>> proportion of the total execution time of the loop.
>
> (snip)
>
>> However, I dispute that it is ever a "significant proportion"
>> of the total execution time of the loop.
>
>> In which case, you have no case.
>
>>     The code for a PC loop (posted yesterday) requires
>> 12 instructions.  One extra instruction will scarcely
>> be noticeable.
>
> You haven't been following processor development.  Branch prediction
> is a very important part of keeping current processors pipelines fille=
d.
> A mispredicted branch could easily take more time than 12 instructions=
,
> and indexed branches are always mispredicted.
Which suggest a method for determining the efficacy of branch prediction=
..
There have been various efforts to simultaneously load paths, the earlie=
st
I saw, was Multiflow out of Connecticut around 1984.  Of course, Fortran=
  =

would
need three:-)
>
>> How many seconds extra will it take if the loop is executed
>> 1,000,000 times?
>
> How many if that loop is executed 1,000,000 times?
>
> -- glen
>



-- =

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
0
tom284 (1839)
5/27/2006 5:57:21 PM
Tom LINDEN wrote:

(snip on branch prediction)

> Which suggest a method for determining the efficacy of branch prediction.
> There have been various efforts to simultaneously load paths, the earliest
> I saw, was Multiflow out of Connecticut around 1984. 

The 360/91 will prefetch on two branch paths.  With memory cycle time 
about 12 times slower than machine cycle time that was pretty important.
Most now do speculative execution on the predicted path.  That was about 
1967.

 > Of course,  Fortran  would need three:-)

Ha ha ha.  I don't know that I ever coded an arithmetic IF in any 
program I wrote, though I know there were some in programs I worked
on written by others.  For most machines a compare instruction will set 
the condition codes (flags) such that multiple conditional branch 
instructions can be used.

-- glen

0
gah (12851)
5/27/2006 8:38:02 PM
glen herrmannsfeldt wrote:

> Tom LINDEN wrote:
> 
> (snip on branch prediction)
> 
>> Which suggest a method for determining the efficacy of branch prediction.
>> There have been various efforts to simultaneously load paths, the 
>> earliest
>> I saw, was Multiflow out of Connecticut around 1984. 
> 
> 
> The 360/91 will prefetch on two branch paths.  With memory cycle time 
> about 12 times slower than machine cycle time that was pretty important.
> Most now do speculative execution on the predicted path.  That was about 
> 1967.
> 
>  > Of course,  Fortran  would need three:-)
> 
> Ha ha ha.  I don't know that I ever coded an arithmetic IF in any 
> program I wrote, though I know there were some in programs I worked
> on written by others.  For most machines a compare instruction will set 
> the condition codes (flags) such that multiple conditional branch 
> instructions can be used.
> 
> -- glen
> 
I used FORTRAN II briefly; it didn't have logical IFs so I had to use
arithmetic IFs.  I learned to phrase expressions in the form "A - B" or
at least to think of them in that manner when reading others' code so I
could think of the branch labels as:

    IF (A - B) A < B, A = B, A > B

and a missing B implied a zero value for B.  (CDC FORTRAN not to be
outdone, of course, had a 2-branch arithmetic IF extension.  Sigh.)  I
believe the 3-branch arithmetic IF was inspired by a machine instruction
that did an arithmetic comparison and had 3 target labels; it had to be
implemented on other machines with multiple comparisons.

After I got out of school, the only time I used a 3-branch arithmetic IF
for anything written in FORTRAN IV or any later version was the one time
I wrote a merge routine.  It seemed to make sense at the time but I
found out a year later that everybody else in the shop refused to work
on any program that used that routine because they didn't understand the
arithmetic IF and were afraid of it (and that was a FORTRAN shop).  I
quickly re-wrote it as two logical IFs and never had to look at that 
routine or any program that used it again.  :-)


Bob Lidral
lidral  at  alum  dot  mit  dot  edu
0
5/27/2006 9:42:37 PM
Bob Lidral wrote:

(snip)

> I used FORTRAN II briefly; it didn't have logical IFs so I had to use
> arithmetic IFs.  I learned to phrase expressions in the form "A - B" or
> at least to think of them in that manner when reading others' code so I
> could think of the branch labels as:

>    IF (A - B) A < B, A = B, A > B

If you really need to test all three separately it seems nice, though.

> and a missing B implied a zero value for B.  (CDC FORTRAN not to be
> outdone, of course, had a 2-branch arithmetic IF extension.  Sigh.)

I thought I saw somewhere a logical 2-branch IF, with two statement
numbers, though I can't say where.

> I
> believe the 3-branch arithmetic IF was inspired by a machine instruction
> that did an arithmetic comparison and had 3 target labels; it had to be
> implemented on other machines with multiple comparisons.

So much of Fortran came from 704 features, but I don't think the 704
had a three way branch.  There aren't enough instruction bits.

> After I got out of school, the only time I used a 3-branch arithmetic IF
> for anything written in FORTRAN IV or any later version was the one time
> I wrote a merge routine.  It seemed to make sense at the time but I
> found out a year later that everybody else in the shop refused to work
> on any program that used that routine because they didn't understand the
> arithmetic IF and were afraid of it (and that was a FORTRAN shop).  I
> quickly re-wrote it as two logical IFs and never had to look at that 
> routine or any program that used it again.  :-)

Yes, for sort and merge programs it always seems like a waste to have
to write the same expression down in two IF statements to get all three
branches.  Hopefully common subexpression will find it, but it still
seems ugly and an extra place to make a mistake.

It might be that I used one in place of a three way computed GOTO.

-- glen

0
gah (12851)
5/28/2006 9:42:20 AM
It's been a long time sine I worked on a DEC System 10, but as far as your 
question is concerned, this would be a typical case of when the PL/I 
definition may lead to additional instructions being generated. This is 
because PL/I defines a character as being a byte of 8 bits (an "octet") and 
machines with 36-bit or 60-bit (CDC 6000 series) words do not accord with 
this. A similar issue surrounds non-octet addressable machines, as PL/I 
defines unaligned in terms of byte (octet) addresses, and machines not 
suppporting such addressing (e.g. CDC 6000 series) require additional 
instructions.

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message 
news:2r-dnfC45LgiGerZnZ2dnUVZ_sGdnZ2d@comcast.com...
> Mark Yudkin wrote:
>
>
>> ALIGNED specifies that the data element is aligned on the storage 
>> boundary corresponding to its data-type requirement. UNALIGNED specifies 
>> that each data element is mapped on the next byte boundary,
>> except for fixed-length bit strings, which are mapped on the next bit.
>
> Say, for example, one were writing a PL/I compiler for the DEC PDP-10
> (or IBM 7090) with 36 bit words.  Where is the next byte boundary?
>
> It is hard to see how it couldn't be system dependent in many cases.
>
> -- glen
> 


0
5/28/2006 9:52:42 AM
Mark Yudkin wrote:
> It's been a long time sine I worked on a DEC System 10, but as far as your 
> question is concerned, this would be a typical case of when the PL/I 
> definition may lead to additional instructions being generated. This is 
> because PL/I defines a character as being a byte of 8 bits (an "octet") and 
> machines with 36-bit or 60-bit (CDC 6000 series) words do not accord with 
> this.

What do you mean by "PL/I"? Neither Y33-6003 nor the ULD say any such 
thing, and it would surprise me if ANSI PL/I did.

-- 
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
   -- Charles Williams.  "Taliessin through Logres: Prelude"
0
jwkenne (1442)
5/28/2006 2:11:47 PM
glen herrmannsfeldt wrote:
> So much of Fortran came from 704 features, but I don't think the 704
> had a three way branch.  There aren't enough instruction bits.

Think outside the box.

=========================================================================
Compare Accumulator and Storage
CAS Y

If the C(Y) are algebraically less than the C(AC), the calculator takes 
the next instruction in sequence. If the C(Y) are algebraically equal to 
the C(AC), the calculator skips the next instruction and proceeds from 
there. If the C(Y) are algebraically greater than the C(AC), the 
calculator skips the next two instructions and proceeds from there. Two 
numbers are algebraically equal when the magnitude of the numbers and 
the sign are both equal. A plus zero is algebraically larger than a 
minus zero.
=========================================================================

-- 
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
   -- Charles Williams.  "Taliessin through Logres: Prelude"
0
jwkenne (1442)
5/28/2006 2:24:59 PM
On Sun, 28 May 2006 07:11:47 -0700, John W. Kennedy  =

<jwkenne@attglobal.net> wrote:

> Mark Yudkin wrote:
>> It's been a long time sine I worked on a DEC System 10, but as far as=
  =

>> your question is concerned, this would be a typical case of when the =
 =

>> PL/I definition may lead to additional instructions being generated. =
 =

>> This is because PL/I defines a character as being a byte of 8 bits (a=
n  =

>> "octet") and machines with 36-bit or 60-bit (CDC 6000 series) words d=
o  =

>> not accord with this.
>
> What do you mean by "PL/I"? Neither Y33-6003 nor the ULD say any such =
 =

> thing, and it would surprise me if ANSI PL/I did.
>

The word "Byte" does not appear in the ANSI standard.  As for CDC, I
don't remember the details of the implementation of PL/I, as the code
generator and port were outsourced to another company.  But the compiler=

has a number of constants that defined the storage units on the target
machine, e.g. BitsPerByte, so it makes no a priori assumptions about the=

units.  Note also that ANSI does not specify the character set other tha=
n
listing 57 symbols which must be supported.


-- =

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
0
tom284 (1839)
5/28/2006 2:49:42 PM
glen herrmannsfeldt wrote:

> Bob Lidral wrote:
> 
> (snip)
> 
>> I used FORTRAN II briefly; it didn't have logical IFs so I had to use
>> arithmetic IFs.  I learned to phrase expressions in the form "A - B" or
>> at least to think of them in that manner when reading others' code so I
>> could think of the branch labels as:
> 
> 
>>    IF (A - B) A < B, A = B, A > B
> 
> 
> If you really need to test all three separately it seems nice, though.
> 
>> and a missing B implied a zero value for B.  (CDC FORTRAN not to be
>> outdone, of course, had a 2-branch arithmetic IF extension.  Sigh.)
> 
> 
> I thought I saw somewhere a logical 2-branch IF, with two statement
> numbers, though I can't say where.
> 
That was probably CDC's FTN4.  CDC went overboard with extensions to the 
language with that compiler.  I always avoided such extensions but 
discovered whole bunches of them in the LRM over the years.  I believe 
it had both a 2-branch logical IF and a 2-branch arithmetic IF.

I don't remember most of their extensions because (1) my first real 
programming job required me to produce source code compatible with 
different compilers written by different vendors (Multics PL/I, PL/I F, 
and one other) and to this day I try to make all my source code as 
portable as possible and (2) most of the extensions were unnecessary.

CDC went to the other extreme with FTN5.  Although, IIRC, it was still a 
FORTRAN IV (1966 Standard) compiler, it flagged anything that might 
remotely be considered an extension or non-portable usage.  Thus, in 
addition to the 2-branch IFs, it flagged such things as any use of 6 (it 
might be related to the character size), 10 (it might be related to the 
number of characters in a word), 60 (it might be related to the word 
size), and a bunch of other numeric values probably including 5, 12, and 
possibly 15, 18, and 30.  It generated so many warning (or 
information-level) messages for almost any piece of code that most 
people turned off that level of diagnostic.  Most programmers (except, 
of course, for those in this ng) don't understand the concept of 
portability or standards-compliance so the messages were just confusing 
to them and the volume of those messages was annoying to those who did 
understand the issue.

> [...]
>> After I got out of school, the only time I used a 3-branch arithmetic IF
>> for anything written in FORTRAN IV or any later version was the one time
>> I wrote a merge routine.  It seemed to make sense at the time but I
>> found out a year later that everybody else in the shop refused to work
>> on any program that used that routine because they didn't understand the
>> arithmetic IF and were afraid of it (and that was a FORTRAN shop).  I
>> quickly re-wrote it as two logical IFs and never had to look at that 
>> routine or any program that used it again.  :-)
> 
> 
> Yes, for sort and merge programs it always seems like a waste to have
> to write the same expression down in two IF statements to get all three
> branches.  Hopefully common subexpression will find it, but it still
> seems ugly and an extra place to make a mistake.
> 
In some cases, it's possible for the programmer to cheat and use 
knowledge of the data to achieve some optimization by ordering the IF 
statements properly, but as you wrote, it's still necessary to write two 
IF statements.


Bob Lidral
lidral  at  alum  dot  mit  dot  edu
0
5/28/2006 3:00:09 PM
glen herrmannsfeldt wrote:
>> I
>> believe the 3-branch arithmetic IF was inspired by a machine instruction
>> that did an arithmetic comparison and had 3 target labels; it had to be
>> implemented on other machines with multiple comparisons.
> 
> 
> So much of Fortran came from 704 features, but I don't think the 704
> had a three way branch.  There aren't enough instruction bits.
> 
It was somewhere in the 704-709-7090 series.  As I recall, the instruction was

   CAS  Compare Accumulator with Stroage

If the CAS was fetched from location n, the next instruction was fetched from 
location n+1, n+2, or n+3 depending on whether the comparision outcome was <, +, 
or > respectively.
0
jjw (608)
5/28/2006 7:38:27 PM
glen herrmannsfeldt wrote:
> James J. Weinkam wrote:
> (snip)
> 
>>>>>  DCL X CHAR(10);
>>>>>  DO X='  1' TO '  100' BY '1';
>>>>>     PUT SKIP LIST(SQRT(X));
>>>>>  END;
> 
> 
> (snip)
> 
>> You're all whistling Dixie.
> 
> 
>> Check out the conversion rules for character strings to/from 
>> arithmetic.  There are two cases.
> 
> 
> 
> (snip)
> 
>> 2.  In an arithmetic expression involving a non trivial operation, a 
>> character string appears as an operand.  In this case the arithmetic 
>> value the string operand represents is converted to the attributes 
>> that a FIXED DECIMAL(M,0) operand would have been converted in the 
>> same context, where M is the maximum allowable fixed decimal 
>> precision.  (All LRM's that I have seen after the Optimizing Compiler 
>> fail to state the (M,0) part, a typo that no one seems to have noticed 
>> for something like 15 years.)
> 
> 
> I first did this 30 years ago, when I was in high school.  (Wow, that 
> long ago?)  I don't remember the length I used for the variable, but 
> note that the FIXED DECIMAL(M,0) is only for the intermediate values in 
> incrementing the DO variable.  The result is then converted back to 
> CHAR, with the appropriate length.  

No.  The final value after the increment is DECIMAL FIXED(M,0).  Regardless of 
the length of the assignment target, the value is converted to character 
representation and right justified in a string of length M+3.  That is then 
assigned to the target according to the rules for string assignment.  It's 
always been that way.  Read the relevant LRM sections on data conversion, 
expression evaluation, and assignment.

An optimizing compiler may take some shortcuts to save time and/or space, but 
the result will be equivalent to having done what the manual says.

It comes back with some number of
> blanks on the left, if I remember, that is, the value is left justified 
> after some number of blanks.   The CALL/OS compiler is somewhat simpler 
> than the F compiler, and does FIXED DECIMAL in binary.
> 
>> In the case at hand, since everything is sight is a character string 
>> containing an integer value and we are dealing with a non trivial 
>> operational expression, the intermediate fixed decimal target is going 
>> to be fixed decimal(M,0).
> 
> 
>> Consequently, upon conversion from fixed decimal back to character, 
>> the length is going to be M+3.
> 
> 
> It may be M+3, but I believe that is three blanks (or two and a sign) 
> followed by the most significant digit.
>
There's no may be about it.  It is M+3.  The extra three spaces are to provide 
for a possible sign, a possible decimal point, and a possible leading 0 before 
the decimal point of a fractional value.  And as stated above, the converted 
result is right justified in a field of length M+3.

Here is an extract from the LRM:

Target: CHARACTER

Source:

FIXED BINARY, FIXED DECIMAL, FLOAT BINARY, and FLOAT DECIMAL

The coded arithmetic value is converted to a decimal constant (preceded by a 
minus sign if it is negative) as described below. The constant is inserted into 
an intermediate character string whose length is derived from the attributes of 
the source. The intermediate string is assigned to the target according to the 
rules for string assignment.

The rules for coded-arithmetic-to-character-string conversion are also used for 
list-directed and data-directed output, and for evaluating keys (even for 
REGIONAL files).

FIXED BINARY (p1,q1)
The binary precision (p1,q1) is first converted to the equivalent decimal 
precision (p,q), where p=1+CEIL(p1/3.32) and q=CEIL(ABS(q1/3.32))*SIGN(q1). 
Thereafter, the rules are the same as for FIXED DECIMAL to CHARACTER.

FIXED DECIMAL (p1,q1)
If p1>=q1>=0 then:

[NOTE:  This case applies to the present example]

oThe constant is right adjusted in a field of width p1+3. (The 3 is necessary to 
allow for the possibility of a minus sign, a decimal or binary point, and a 
leading zero before the point.)

[NOTE: p1=M because of the way the value being converted was obtained.]
[ALSO NOTE the phrase "right adjusted" in the point ablve.]

oLeading zeros are replaced by blanks, except for a single zero that immediately 
precedes the decimal point of a fractional number. A single zero also remains 
when the value of the source is zero.

oA minus sign precedes the first digit of a negative number. A positive value is 
unsigned.

oIf q1=0, no decimal point appears; if q1>0, a decimal point appears and the 
constant has q fractional digits.

If p1<q1 or q1<0, a scaling factor appends to the right of the constant; the 
constant is an optionally-signed integer. The scaling factor appears even if the 
value of the item is zero and has the following syntax:

   F{+|-}nn


where {+|-}nn has the value of -q1.

The length of the intermediate string is p1+k+3, where k is the number of digits 
necessary to hold the value of q1 (not including the sign or the letter F).

If the arithmetic value is complex, the intermediate string consists of the 
imaginary part concatenated to the real part. The left-hand, or real, part is 
generated as a real source. The right-hand, or imaginary, part is always signed, 
and it has the letter I appended. The generated string is a complex expression 
with no blanks between its elements. The length of the intermediate string is:

   2*p1+7     for p1>=q1>=0
   2*(p1+k)+7 for p1<q1 or q1<0


The following examples show the intermediate strings that are generated from 
several real and complex fixed-point decimal values:

Precision     Value     String

(5,0)       2947        'bbbb2947'
(4,1)       -121.7      'b-121.7'
(4,-3)      -3279000    '-3279F+3'
(2,1)       1.2+0.3I    'bbb1.2+0.3I'


>> Since string assignment is done from left to right, the index variable 
>> has to be M+3 or more in length or you are going to be in trouble, 
>> since otherwise you will lose some or all of the business part of the 
>> converted string assigned to X in as much as it is right justified.
> 
> 
> I may have used more than CHAR(10), but see above.
> 
>> Thus in a system where M=15, X must be at least char(18) and in a 
>> situation where M=31, X must be at least char(34).
> 
> 
>> I am using limits(fixeddec(31)), so in my case I have to declare X 
>> char(34) if I expect to get anywhere.
> 
> 
> Try it and see what happens.

That isn't necessary, since the manual is clear; however, I have tested it 
anyway and it behaves as I have described.
0
jjw (608)
5/28/2006 8:55:36 PM
James J. Weinkam wrote:

(snip)

> No.  The final value after the increment is DECIMAL FIXED(M,0).  
> Regardless of the length of the assignment target, the value is 
> converted to character representation and right justified in a string of 
> length M+3.  That is then assigned to the target according to the rules 
> for string assignment.  It's always been that way.  Read the relevant 
> LRM sections on data conversion, expression evaluation, and assignment.

> An optimizing compiler may take some shortcuts to save time and/or 
> space, but the result will be equivalent to having done what the manual 
> says.

(snip)

> There's no may be about it.  It is M+3.  The extra three spaces are to 
> provide for a possible sign, a possible decimal point, and a possible 
> leading 0 before the decimal point of a fractional value.  And as stated 
> above, the converted result is right justified in a field of length M+3.

M+3 sounds right, but I remembered it left justified.  After 30 years, I
could have remembered wrong.  (It probably was May 1976.)
Most likely I had more than CHAR(10), and it took a few tries to
get the blanks right.  This was with the CALL/OS compiler, which may
have done it wrong for all I know.   (It was already outdated at the
time, but the school district probably got it cheap.)

> Here is an extract from the LRM:

(snip)

> That isn't necessary, since the manual is clear; however, I have tested 
> it anyway and it behaves as I have described.

Did you get it to loop from 1 to 100?  That is the tricky part.

-- glen

0
gah (12851)
5/29/2006 3:12:18 AM
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:l9idnZbh6OrA7eTZnZ2dnUVZ_s2dnZ2d@comcast.com...
> Bob Lidral wrote:
> > I used FORTRAN II briefly; it didn't have logical IFs so I had to use
> > arithmetic IFs.  I learned to phrase expressions in the form "A - B" or
> > at least to think of them in that manner when reading others' code so I
> > could think of the branch labels as:
>
> >    IF (A - B) A < B, A = B, A > B
>
> If you really need to test all three separately it seems nice, though.

It's only ever necessary to test two.
The third alternative falls out.

> > and a missing B implied a zero value for B.  (CDC FORTRAN not to be
> > outdone, of course, had a 2-branch arithmetic IF extension.  Sigh.)
>
> I thought I saw somewhere a logical 2-branch IF, with two statement
> numbers, though I can't say where.
>
> > I
> > believe the 3-branch arithmetic IF was inspired by a machine instruction
> > that did an arithmetic comparison and had 3 target labels; it had to be
> > implemented on other machines with multiple comparisons.
>
> So much of Fortran came from 704 features, but I don't think the 704
> had a three way branch.  There aren't enough instruction bits.
>
> > After I got out of school, the only time I used a 3-branch arithmetic IF
> > for anything written in FORTRAN IV or any later version was the one time
> > I wrote a merge routine.  It seemed to make sense at the time but I
> > found out a year later that everybody else in the shop refused to work
> > on any program that used that routine because they didn't understand the
> > arithmetic IF and were afraid of it (and that was a FORTRAN shop).  I
> > quickly re-wrote it as two logical IFs and never had to look at that
> > routine or any program that used it again.  :-)
>
> Yes, for sort and merge programs it always seems like a waste to have
> to write the same expression down in two IF statements to get all three
> branches.

The procedures LLE etc for strings avoid the re-evaluation.


0
robin_v (2737)
5/29/2006 3:38:36 AM
glen herrmannsfeldt wrote:
> James J. Weinkam wrote:
> 
> (snip)
> 
>> No.  The final value after the increment is DECIMAL FIXED(M,0).  
>> Regardless of the length of the assignment target, the value is 
>> converted to character representation and right justified in a string 
>> of length M+3.  That is then assigned to the target according to the 
>> rules for string assignment.  It's always been that way.  Read the 
>> relevant LRM sections on data conversion, expression evaluation, and 
>> assignment.
> 
> 
>> An optimizing compiler may take some shortcuts to save time and/or 
>> space, but the result will be equivalent to having done what the 
>> manual says.
> 
> 
> (snip)
> 
>> There's no may be about it.  It is M+3.  The extra three spaces are to 
>> provide for a possible sign, a possible decimal point, and a possible 
>> leading 0 before the decimal point of a fractional value.  And as 
>> stated above, the converted result is right justified in a field of 
>> length M+3.
> 
> 
> M+3 sounds right, but I remembered it left justified.  After 30 years, I
> could have remembered wrong.  (It probably was May 1976.)
> Most likely I had more than CHAR(10), and it took a few tries to
> get the blanks right.  This was with the CALL/OS compiler, which may
> have done it wrong for all I know.   (It was already outdated at the
> time, but the school district probably got it cheap.)
> 
>> Here is an extract from the LRM:
> 
> 
> (snip)
> 
>> That isn't necessary, since the manual is clear; however, I have 
>> tested it anyway and it behaves as I have described.
> 
> 
> Did you get it to loop from 1 to 100?  That is the tricky part.
>
Yes.  On the first and only try.  Here is the source and output:

Source:

  test: proc options(main) reorder;
   dcl
    x char(34),
    sysprint file print,
    (sqrt) builtin;
   do x='                                 1'
    to '                               100' by '1';
    put file(sysprint) edit('|',x,'|')(col(1),3 a);
    put file(sysprint) edit(sqrt(x))(col(1),f(12,8));
    end;
   end test;


Output:

|                                 1|
   1.00000000
|                                 2|
   1.41421356
|                                 3|
   1.73205081
|                                 4|
   2.00000000
|                                 5|
   2.23606798
|                                 6|
   2.44948974
|                                 7|
   2.64575131
|                                 8|
   2.82842712
|                                 9|
   3.00000000
|                                10|
   3.16227766
|                                11|
   3.31662479
|                                12|
   3.46410162
|                                13|
   3.60555128
|                                14|
   3.74165739
|                                15|
   3.87298335
|                                16|
   4.00000000
|                                17|
   4.12310563
|                                18|
   4.24264069
|                                19|
   4.35889894
|                                20|
   4.47213595
|                                21|
   4.58257569
|                                22|
   4.69041576
|                                23|
   4.79583152
|                                24|
   4.89897949
|                                25|
   5.00000000
|                                26|
   5.09901951
|                                27|
   5.19615242
|                                28|
   5.29150262
|                                29|
   5.38516481
|                                30|
   5.47722558
|                                31|
   5.56776436
|                                32|
   5.65685425
|                                33|
   5.74456265
|                                34|
   5.83095189
|                                35|
   5.91607978
|                                36|
   6.00000000
|                                37|
   6.08276253
|                                38|
   6.16441400
|                                39|
   6.24499800
|                                40|
   6.32455532
|                                41|
   6.40312424
|                                42|
   6.48074070
|                                43|
   6.55743852
|                                44|
   6.63324958
|                                45|
   6.70820393
|                                46|
   6.78232998
|                                47|
   6.85565460
|                                48|
   6.92820323
|                                49|
   7.00000000
|                                50|
   7.07106781
|                                51|
   7.14142843
|                                52|
   7.21110255
|                                53|
   7.28010989
|                                54|
   7.34846923
|                                55|
   7.41619849
|                                56|
   7.48331477
|                                57|
   7.54983444
|                                58|
   7.61577311
|                                59|
   7.68114575
|                                60|
   7.74596669
|                                61|
   7.81024968
|                                62|
   7.87400787
|                                63|
   7.93725393
|                                64|
   8.00000000
|                                65|
   8.06225775
|                                66|
   8.12403840
|                                67|
   8.18535277
|                                68|
   8.24621125
|                                69|
   8.30662386
|                                70|
   8.36660027
|                                71|
   8.42614977
|                                72|
   8.48528137
|                                73|
   8.54400375
|                                74|
   8.60232527
|                                75|
   8.66025404
|                                76|
   8.71779789
|                                77|
   8.77496439
|                                78|
   8.83176087
|                                79|
   8.88819442
|                                80|
   8.94427191
|                                81|
   9.00000000
|                                82|
   9.05538514
|                                83|
   9.11043358
|                                84|
   9.16515139
|                                85|
   9.21954446
|                                86|
   9.27361850
|                                87|
   9.32737905
|                                88|
   9.38083152
|                                89|
   9.43398113
|                                90|
   9.48683298
|                                91|
   9.53939201
|                                92|
   9.59166305
|                                93|
   9.64365076
|                                94|
   9.69535971
|                                95|
   9.74679434
|                                96|
   9.79795897
|                                97|
   9.84885780
|                                98|
   9.89949494
|                                99|
   9.94987437
|                               100|
  10.00000000


> -- glen
> 

Everything you see is necessary:

On the first iteration x is going to be whatever you specify as the initial value.

On subsequent iterations, x is going to be the result of assigning the converted 
result of the increment, i.e., 2, 3, 4, ... right justified in a 34 byte field.

Therefore to compare properly, the limit (TO) (100) must be right justified in a 
field of length 34.  Therefore to compare properly before the first iteration of 
the body is done, the initial value must also be right justified in a field of 
length 34.

You have to realize that character comparison is lexicographic, so if you add or 
remove a leading blank it's like multiplying or dividing by 10.  It definitely 
is not WYSIWYG in as much as the blanks are invisible.

There's just no getting away from it.
0
jjw (608)
5/29/2006 3:56:00 AM
James J. Weinkam wrote:
> glen herrmannsfeldt wrote:

.... big snip
> 
> You have to realize that character comparison is lexicographic, so if 
> you add or remove a leading blank it's like multiplying or dividing by 
> 10.  It definitely is not WYSIWYG in as much as the blanks are invisible.
> 
> There's just no getting away from it.


Sorry to reply to my own post but another thoughtn occurred to me.

Can you explain why this also works and produces (almost) the same output?

  test: proc options(main) reorder;
   dcl
    i bin fixed(15),
    x char(34),
    sysprint file print,
    (sqrt) builtin;
   do x='1' to '100'+'0' by '1';
    put file(sysprint) edit('|',x,'|')(col(1),3 a);
    put file(sysprint) edit(sqrt(x))(col(1),f(12,8));
    end;
   end test;

Without running it, what is the difference in the output?
0
jjw (608)
5/29/2006 4:09:21 AM
James J. Weinkam wrote:
(snip)

> It was somewhere in the 704-709-7090 series.  As I recall, the 
> instruction was

>   CAS  Compare Accumulator with Stroage

IBM later reused CAS as Compare And Swap for S/370.

> If the CAS was fetched from location n, the next instruction was fetched 
> from location n+1, n+2, or n+3 depending on whether the comparision 
> outcome was <, +, or > respectively.

That would do it, though four words, same as a compare and three branch
instructions, and worse than the more common case of only one or two
conditional branch instructions.  It might have simpler logic, though.

-- glen

0
gah (12851)
5/29/2006 4:51:21 AM
Bob Lidral wrote:

> glen herrmannsfeldt wrote:

(snip about byte alignment)

>> Say, for example, one were writing a PL/I compiler for the DEC PDP-10
>> (or IBM 7090) with 36 bit words.  Where is the next byte boundary?
(snip)

> IIRC, DEC named or renamed that system the DECSystem-10 so people
> wouldn't call it a PDP-10.  They wanted people to think of the 10 as a
> "real", "production", or maybe even "mainframe" computer and felt the
> "PDP-" prefix would give the impression it was "just" a mini-computer
> like the PDP-8 or PDP-11.

I didn't completely figure out the naming system.  I thought it was
PDP-10 for the hardware, and DECSystem-10 for the hardware/software
system.

> In any case, I seem to remember the documentation for the DECSystem-10
> defined a "byte" as any contiguous series of bits (there must have been
> lower and upper bounds on the size of a byte -- perhaps dictated by the
> width of that field in the instruction formats -- but I don't remember
> what they were).  Byte-manipulation instructions used the initial bit
> offset and either the final bit offset or bit length of the byte field
> to specify the field.  I don't remember whether bytes were allowed to
> extend over word boundaries.

There are instructions to load and store bytes, between 1 and 36 bits,
I believe not crossing word boundaries.

> In such an architecture, byte size is unrelated to character size and
> the concept of byte boundary alignment for execution efficiency has a
> different meaning than on an architecture such as the 360.

It gets complicated when you need interchange with byte addressable
machines.  There are at least two ways to read and write 9 track tape,
one which keeps 36 bit words intact, and the other which allows writing
arbitrary byte patterns, I believe with four bytes per word.  There is
also ASCII, five characters per word.

If you wanted to read or write tapes compatible with S/360 PL/I you 
would need to write the four bytes per word format.  This would not
work if you had FIXED BIN(35) data in a structure.

-- glen

0
gah (12851)
5/29/2006 4:56:08 AM
James J. Weinkam wrote:
> Can you explain why this also works and produces (almost) the same output?
> 
>  test: proc options(main) reorder;
>   dcl
>    i bin fixed(15),
>    x char(34),
>    sysprint file print,
>    (sqrt) builtin;
>   do x='1' to '100'+'0' by '1';
>    put file(sysprint) edit('|',x,'|')(col(1),3 a);
>    put file(sysprint) edit(sqrt(x))(col(1),f(12,8));
>    end;
>   end test;

Off the top of my head, I'd say that '100'+'0' is FIXED DECIMAL, so 
you're doing an arithmetic comparison, not character.  Making the 
computer do a lot of work to obtain a simple result.

> 
> Without running it, what is the difference in the output?

0
Peter_Flass (956)
5/29/2006 11:46:49 AM
glen herrmannsfeldt wrote:

> Bob Lidral wrote:
> 
>> glen herrmannsfeldt wrote:
> 
> 
> (snip about byte alignment)
> 
>>> Say, for example, one were writing a PL/I compiler for the DEC PDP-10
>>> (or IBM 7090) with 36 bit words.  Where is the next byte boundary?
> 
> (snip)
> 
>> IIRC, DEC named or renamed that system the DECSystem-10 so people
>> wouldn't call it a PDP-10.  They wanted people to think of the 10 as a
>> "real", "production", or maybe even "mainframe" computer and felt the
>> "PDP-" prefix would give the impression it was "just" a mini-computer
>> like the PDP-8 or PDP-11.
> 
> 
> I didn't completely figure out the naming system.  I thought it was
> PDP-10 for the hardware, and DECSystem-10 for the hardware/software
> system.
> 
>> In any case, I seem to remember the documentation for the DECSystem-10
>> defined a "byte" as any contiguous series of bits (there must have been
>> lower and upper bounds on the size of a byte -- perhaps dictated by the
>> width of that field in the instruction formats -- but I don't remember
>> what they were).  Byte-manipulation instructions used the initial bit
>> offset and either the final bit offset or bit length of the byte field
>> to specify the field.  I don't remember whether bytes were allowed to
>> extend over word boundaries.
> 
> 
> There are instructions to load and store bytes, between 1 and 36 bits,
> I believe not crossing word boundaries.
> 
>> In such an architecture, byte size is unrelated to character size and
>> the concept of byte boundary alignment for execution efficiency has a
>> different meaning than on an architecture such as the 360.
> 
> 
> It gets complicated when you need interchange with byte addressable
> machines.  There are at least two ways to read and write 9 track tape,
> one which keeps 36 bit words intact, and the other which allows writing
> arbitrary byte patterns, I believe with four bytes per word.  There is
> also ASCII, five characters per word.
> 
> If you wanted to read or write tapes compatible with S/360 PL/I you 
> would need to write the four bytes per word format.  This would not
> work if you had FIXED BIN(35) data in a structure.
> 

In general it's difficult to interchange binary data.  It's simple when 
everyone uses 32 bits per word, and common floating-point formats.  All 
you have to deal with are endian-ness issues.  We're getting to the 
point where we have mistures of 32- and 64-bit data, still pretty simple.

0
Peter_Flass (956)
5/29/2006 11:50:25 AM
Peter Flass wrote:
> James J. Weinkam wrote:
> 
>> Can you explain why this also works and produces (almost) the same 
>> output?
>>
>>  test: proc options(main) reorder;
>>   dcl
>>    i bin fixed(15),
>>    x char(34),
>>    sysprint file print,
>>    (sqrt) builtin;
>>   do x='1' to '100'+'0' by '1';
>>    put file(sysprint) edit('|',x,'|')(col(1),3 a);
>>    put file(sysprint) edit(sqrt(x))(col(1),f(12,8));
>>    end;
>>   end test;
> 
> 
> Off the top of my head, I'd say that '100'+'0' is FIXED DECIMAL, so 
> you're doing an arithmetic comparison, not character.  Making the 
> computer do a lot of work to obtain a simple result.
>
Right on both counts.  My posts on this subtopic of the thread started when 
someone posted the following:

  DCL X CHAR(10);
  DO X='  1' TO '  100' BY '1';
     PUT SKIP LIST(SQRT(X));
  END;

The code as posted won't work.  My point has been that if you have some reason 
for wanting to write such a loop, just guessing how to do it and saying things 
like the compiler may do it this way or that way is not very effective.  The 
only way to go about it is to study the LRM sections relating to expression 
evaluation, data conversion, and assignment.  Upon doing so you will learn that 
the initial and comparison values must be right justified strings of length M+3 
and the length of X must be greater than or equal to M+3.

If I had some reason for wanting a character variable X to take on the values 1 
to 100 with some specific positioning of the character representation of the 
numeric value within the string, I would do the following:

   dcl i decimal fixed, x char(8);
   do i=1 to 100;
    x=i; ...
    end;

Now if I didn't want the value right justified in a string of length 8, I would 
substitute for x=i some other formulation using put string, numeric character, 
use of the trim function, or the like.

Certainly no one in his right mind would really make a square root table that 
way.
0
jjw (608)
5/29/2006 6:31:27 PM
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:x6OdnToTaNs04OfZ4p2dnA@comcast.com...
> James J. Weinkam wrote:
> (snip)
>
> > It was somewhere in the 704-709-7090 series.  As I recall, the
> > instruction was
>
> >   CAS  Compare Accumulator with Stroage
>
> IBM later reused CAS as Compare And Swap for S/370.
>
> > If the CAS was fetched from location n, the next instruction was fetched
> > from location n+1, n+2, or n+3 depending on whether the comparision
> > outcome was <, +, or > respectively.
>
> That would do it, though four words, same as a compare and three branch
> instructions,

Well, typically only two branches, as the third can be the first instruction
for the case where the A.E. is > 0.
For >= 0, only the first is a branch, the second is a waste instruction
leading to the third word where the >= 0 code begins.


0
robin_v (2737)
5/30/2006 12:03:09 AM
James J. Weinkam wrote:

(snip)

> Can you explain why this also works and produces (almost) the same output?

I think in this case it will be a numeric comparison, though I didn't
check the LRM.

>  test: proc options(main) reorder;
>   dcl
>    i bin fixed(15),
>    x char(34),
>    sysprint file print,
>    (sqrt) builtin;
>   do x='1' to '100'+'0' by '1';
>    put file(sysprint) edit('|',x,'|')(col(1),3 a);
>    put file(sysprint) edit(sqrt(x))(col(1),f(12,8));
>    end;
>   end test;

> Without running it, what is the difference in the output?

The 1 in the first line won't line up with the other lines.

As well as I remember from 30 years ago, I first tried
DO X='1' TO '100' BY '1';
which resulted in an infinite loop, and had the misaligned 1.
The position of the 1 was the suggestion that spaces were important,
and after a few tries I had it working.  This was on CALL/OS, a
timesharing system, I believe older than TSO, which ran BASIC, Fortran, 
and PL/I.  It didn't take long to try a few times.

I believe I was the only one in the school to use PL/I,
which my teacher nicely allowed for assignments.  I had the PL/I (F)
manuals, which described more features than that compiler had.

-- glen

0
gah (12851)
5/30/2006 10:11:42 AM
"Peter Flass" <Peter_Flass@Yahoo.com> wrote in message 
news:5eBeg.707$3B.413@twister.nyroc.rr.com...
>
> In general it's difficult to interchange binary data.  It's simple when 
> everyone uses 32 bits per word, and common floating-point formats.  All you 
> have to deal with are endian-ness issues.  We're getting to the point where we 
> have mistures of 32- and 64-bit data, still pretty simple.
>
Even when using 32 bits per word, it can be tricky.   I remember getting
a mgnetic tape of floating-point values from a VAX and trying to convert them
to IBM 370.   The sign bit for the VAX is in the middle of the word,
not at the high or low end.   If I recall correctly (it has been over 20
years), the sign bit for the VAX floating-point was in the high order
bit of the rightmost halfword.   Apparently this was to preserve
some kind of compatibility with the PDP-11.

Richard Riehle



0
adaworks2 (748)
7/19/2006 2:58:51 PM
On Wed, 19 Jul 2006 07:58:51 -0700, <adaworks@sbcglobal.net> wrote:

>
> "Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
> news:5eBeg.707$3B.413@twister.nyroc.rr.com...
>>
>> In general it's difficult to interchange binary data.  It's simple wh=
en
>> everyone uses 32 bits per word, and common floating-point formats.  A=
ll  =

>> you
>> have to deal with are endian-ness issues.  We're getting to the point=
  =

>> where we
>> have mistures of 32- and 64-bit data, still pretty simple.
>>
> Even when using 32 bits per word, it can be tricky.   I remember getti=
ng
> a mgnetic tape of floating-point values from a VAX and trying to conve=
rt  =

> them
> to IBM 370.   The sign bit for the VAX is in the middle of the word,
> not at the high or low end.   If I recall correctly (it has been over =
20
> years), the sign bit for the VAX floating-point was in the high order
> bit of the rightmost halfword.   Apparently this was to preserve
> some kind of compatibility with the PDP-11.
>
> Richard Riehle
>
>
Not sure where you get the notion of the sign bit.
http://www.kednos.com/pli/docs/REFERENCE_MANUAL/6291pro_007.html

0
tom284 (1839)
7/19/2006 3:23:47 PM
"Tom Linden" <tom@kednos.com> wrote in message 
news:op.tcxzpxpwzgicya@hyrrokkin...
On Wed, 19 Jul 2006 07:58:51 -0700, <adaworks@sbcglobal.net> wrote:

>
> "Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
> news:5eBeg.707$3B.413@twister.nyroc.rr.com...
>>
>> In general it's difficult to interchange binary data.  It's simple when
>> everyone uses 32 bits per word, and common floating-point formats.  All  you
>> have to deal with are endian-ness issues.  We're getting to the point  where 
>> we
>> have mistures of 32- and 64-bit data, still pretty simple.
>>
> Even when using 32 bits per word, it can be tricky.   I remember getting
> a mgnetic tape of floating-point values from a VAX and trying to convert  them
> to IBM 370.   The sign bit for the VAX is in the middle of the word,
> not at the high or low end.   If I recall correctly (it has been over 20
> years), the sign bit for the VAX floating-point was in the high order
> bit of the rightmost halfword.   Apparently this was to preserve
> some kind of compatibility with the PDP-11.
>
> Richard Riehle
>
>
Not sure where you get the notion of the sign bit.

I don't understand that reply.    I know you developed the PL/I
compiler for the VAX.   The format for floating-point on the
VAX was different from the 370.  However, I do recall that
one bit was designnated for a sign bit.

Richard

http://www.kednos.com/pli/docs/REFERENCE_MANUAL/6291pro_007.html



0
adaworks2 (748)
7/23/2006 3:53:02 AM
Reply:

Similar Artilces:

Re: Evolution of PL/I
"Tom Linden" <tom@kednos.com> writes: > On Sat, 29 Apr 2006 18:46:40 -0700, robin <robin_v@bigpond.com> wrote: > > > The language has always specified it, that is, since 1966. > > The language makes specific provision for it -- > > BIT data is UNALIGNED by default. > > In this mode, data bits of adjacent elements are placed > > adjacent to each other. > > The alternative, when ALIGNED is specified, aligns the > > start bit of each element on a storage boundary. > > > >> though it is a common implementation. > > > > It has always been the implementation. > > > True, but with the proviso that some padding may occur. Padding never occurs for UNALIGNED, except after the last item if it does not fill a storage unit. ...

Why xml:lang instead of lang?
What was the reason to introduce a new attribute "xml:lang" instead of "lang"? This bothers both authors and browsers in different language versions: HTML 4, XHTML 1.0, XHTML 1.1. HTML has only "lang"; XHTML 1.1 has only "xml:lang"; XHTML 1.0 has both! For example, Mozilla 1.7 recognizes the lang attribute http://www.unics.uni-hannover.de/nhtcapri/temp/lang-attribute.htm but it does not recognize the xml:lang attribute. http://www.unics.uni-hannover.de/nhtcapri/temp/lang-attribute.xhtml What do we gain from "xml:lang"? Andreas Prilop wrote: > What was the reason to introduce a new attribute "xml:lang" > instead of "lang"? > What do we gain from "xml:lang"? By putting the attribute in the general and predefined namespace http://www.w3.org/XML/1998/namespace it can be used by any XML application (e.g. XHTML, SVG) without any further effort and without any danger of colliding with attributes in no namespace a particular XML application might want to define. -- Martin Honnen http://JavaScript.FAQTs.com/ Andreas Prilop wrote: > What was the reason to introduce a new attribute "xml:lang" > instead of "lang"? Since it is useful to have a means of describing language in the core of XML. It only looks silly from an (X)HTML-centric viewpoint. -- David Dorward http://dorward.me.uk/ In article <Pine.GSO.4.44.0603311415390.8640-100000@s5b004.rrzn.u...

Re: PL/I EXCEPTIONS (was: PL/I)
From: Peter Flass <Peter_Flass@Yahoo.com>, Road Runner Date: Sat, 22 Jan 2005 01:18:55 GMT .. | Well, it never occurred to me either, until I wrote it. I'm not sure | it would work, although it seems valid. Actually, now that I've written | it I've thought of some uses, for example: | IF print_debug_info THEN DO; | ON ERROR PUT DATA; | END; | at the beginning of a program, so the user can control, maybe by a | run-time option, how errors are to be handled. .. You mean :- .. IF print_debug_info THEN DO; ON ERROR BEGIN; ON ERROR SYSTEM; PUT DATA; END; END; Yeah, that. robin wrote: > From: Peter Flass <Peter_Flass@Yahoo.com>, Road Runner > Date: Sat, 22 Jan 2005 01:18:55 GMT > . > | Well, it never occurred to me either, until I wrote it. I'm not sure > | it would work, although it seems valid. Actually, now that I've written > | it I've thought of some uses, for example: > | IF print_debug_info THEN DO; > | ON ERROR PUT DATA; > | END; > | at the beginning of a program, so the user can control, maybe by a > | run-time option, how errors are to be handled. > . > You mean :- > . > IF print_debug_info THEN DO; > ON ERROR BEGIN; ON ERROR SYSTEM; PUT DATA; END; > END; ...

Re: PL/I ON statement (was: PL/I)
From: "Mark Yudkin" <myudkinATcompuserveDOTcom@boing.org>, CompuServe Interactive Services Date: Wed, 26 Jan 2005 07:55:48 +0100 .. | Important correction inline. .. I know that. I was referring to the case when the current procedure has been called by another. I was not clear. .. More than one ON statement can be executed in a given procedure (for the same condition), in which case the new ON-unit merely supplants the previous one. .. | "robin" <robin_v@bigpond.mapson.com> wrote in message news:OUYId.131519$K7.53859@news-server.bigpond.net.au... | > Subject: Re: PL/I ON Statement (was: PL/I) | > From: "Tom Linden" <tom@kednos.com>, Kednos | > Date: Sat, 22 Jan 2005 16:25:07 -0800 | > | On Sat, 22 Jan 2005 19:35:18 GMT, Peter Flass <Peter_Flass@Yahoo.com> wrote: | > | > Right, but only if the statement was executed, that is, the bit | > | > 'print_debug_info' had been set before executing this construct (again, | > | > so I think, I'll have to test it.) The idea is to easily control the | > | > action for ERROR, in this case the generation of debug output, at run | > | > time. | > | | > | I think a test is in order. | > | When the compiler encounters the ON stmnt | > | it knows nothing of the the IF statement, | > | > ON is an executable statement. | > It is perfectly at home in an IF statement. Or a DO loop. Or wherever. | > In this case, it i...

Biomechanical evolution of vertebrate evolution
I posted the following a few minutes ago to a vertebrate paleontology lis= t that=20 I participate in, and I thought that the list might enjoy the video that = I=20 mention in the posting as well. Wirt Atmar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 In a burst of youthful enthusiasm 32 years ago, when I founded AICS=20 Research, the "AICS" stood for "Artificially Intelligent Cybernetic Syste= ms." We=20 long ago tired of explaining what that phrase meant so we condense...

lang
fortran ...

A Lange & Sohne Lange 1 Watches: Quality A Lange & Sohne Discount Watches
A Lange & Sohne Lange 1 Watches: Quality A Lange & Sohne Discount Watches Quality A Lange & Sohne Lange 1 Watches http://a-lange-sohne-watches.pxhelp.com/a-lange-sohne-lange-1.html Thank you for choosing http://www.pxhelp.com/ Discount A Lange & Sohne Watches http://a-lange-sohne-watches.pxhelp.com/ We guarantee our A Lange & Sohne Lange 1 Watches and A Lange & Sohne Lange 1 Luxury Watches aren't just a simple imitation. We use the same fine materials and technology that the original does. Each A Lange & Sohne Lange 1 Watch produced is examined carefully by ...

A Lange & Sohne Grand Lange 1 Watches: Quality A Lange & Sohne Discount Watches
A Lange & Sohne Grand Lange 1 Watches: Quality A Lange & Sohne Discount Watches Quality A Lange & Sohne Grand Lange 1 Watches http://a-lange-sohne-watches.pxhelp.com/a-lange-sohne-grand-lange-1.html Thank you for choosing http://www.pxhelp.com/ Discount A Lange & Sohne Watches http://a-lange-sohne-watches.pxhelp.com/ We guarantee our A Lange & Sohne Grand Lange 1 Watches and A Lange & Sohne Grand Lange 1 Luxury Watches aren't just a simple imitation. We use the same fine materials and technology that the original does. Each A Lange & Sohne Grand Lange 1 Watc...

evolution
Hello, I am using evolution on linux but I can't display the "Junk" folder, which is greyed out. What should I do? Ivan ...

PL/I
Ironspring PL/I is available on OS/2. Free download from: http://home.roadrunner.com/~pflass/PLI/ A Linux version is being prepared also.. robin wrote: > Ironspring PL/I is available on OS/2. Free download from: ...... > Nothing to do with Ironspring. Seems to be a diatribe against Time Warner. Peter Peter J Seymour wrote: > robin wrote: >> Ironspring PL/I is available on OS/2. Free download from: > ..... >> > Nothing to do with Ironspring. Seems to be a diatribe against Time Warner. > Peter Robin posted that. That link is my &qu...

Evolution
Hi, Yesterday we were at this BBQ and the host had something new to entertain us between the various =93rounds=94 : he had rented some old games, stuff our grandfathers used to play, stuff we had maybe heard about, or seen once or twice as kids. Stuff like an old variant on bowling/curling, archery versus a flat-lying target, etc. The thing was that while it was certainly fun, one could easily see why these older forms of popular entertainment had lost much of their appeal and got replaced by more modern equivalents like bowling and archery versus a standard round target : the new...

[PL/SQL] DataBASE Interaction with PL/SQL
Hello Oracle Guru's, I know that PL/SQL does't accept any user inputs. but i need the following functionality like And Please do not ask the reason for. (My question is coming at the end of this part) Algorithm 1.Execute a procedure 2. accept some input parameters 3. check for some condition 4. pass those accepted parameter to the Dynamic SQL/cursor etc.... 5. Print the output using DBMS.Package 6.The END Here is a sample procedure, but this procedure will accept parameters only when a run the entire procedure (first time) ------------------------------------------- create or replace procedure test as t_empno varchar2(10) := '&empno'; t_ename varchar2(100); begin Select empname into t_ename from empmaster Where empno=t_empno; dbms_output.put_line('Name: '|| t_ename); -- p(t_ename) ; --thanks for asktom.oracle.com end; ---------------------------------------------- Out/put (Image only some i/o is translated from japaneseto english) empno....?: E1234567 old 3: v_empno varchar2(10) := '&empno'; new 3: v_empno varchar2(10) := 'E1234567'; Procedure created SQL> exec test nameofthe employ here PL/SQLcompleted succ.... ------------------------------------------------- My question is How can i write a PL/SQL to perform the above algorithm i.e When i say EXEC test the following screnn should appear empno....?: E1234567 old 3: v_empno varchar2(10) := '&...

PL/I
PL/I users might like to view: http://www.users.bigpond.com/robin_v/plistuff.htm ...

PL/I (aka PL/1) ISO Standard
I can't tell if those asking about the PL/1 (should be PL/I?) Standard in the preprocessor thread were talking about the macro preprocessor or the language itself. However, if anyone is actually interested in the ISO Standard for the language, please check out the web site at: http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=12907 to the best of my memory (and I could be totally wrong on this) at least the "mainframe" compiler from IBM *never* actually conformed to this Standard. (There were some pretty obscure but real incompatibles between what the ISO Standard required and what IBM users expected). I do recall that there were several "conforming" compilers on other platforms (notably Unix and I think either Unisys or HP). Unlike Fortran and COBOL, the ISO PL/I (PL/1) standardization process is now "moribund". I think you can submit interpretation request and defect reports, but there is no ongoing work to ever produce another edition of the Standard. "Bill Klein" <wmklein@noreply.ix.netcom.com> wrote in message news:KpuVn.496096$rq1.248525@en-nntp-02.dc1.easynews.com... |I can't tell if those asking about the PL/1 (should be PL/I?) Standard It's "PL/I". | in the preprocessor thread were talking about the macro preprocessor or the | language itself. It was clear that it was the preprocessor. | However, if anyone is actually interested in the ISO | Standa...

Re: Biomechanical evolution of vertebrate evolution #3
Craig writes: > Found this... Wirt's Bigdog on steriods.... >=20=20 > http://www.flixxy.com/john-deere-walking-tractor.htm In that regard, video of the early beta trials of BigDog have just recent= ly been=20 put up on YouTube. It's at: http://www.youtube.com/watch?v=3DbHHU6X1ShAM Wirt Atmar * To join/leave the list, search archives, change list settings, * * etc., please visit http://raven.utc.edu/archives/hp3000-l.html * ...

pl/i
Hi, I am not a cobol programmer (although i know it a little), but for the current project we need a cobol program that will call a pl/i program. Anyone knows how? What things i have to consider? Louis You don't tell us your environment (operating system or compiler) - but if this HAPPENS to be an IBM mainframe environment (where PL/I is medium common), check out: "11.0 Chapter 11. Communicating between COBOL and PL/I" at: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CEEA4110/11.0 -- Bill Klein wmklein <at> ix.netcom.com "Louis De Bevere&quo...

Re: PL/I reads arbitrary files (was PL/I cant ...)
Subject: PL/I cant read arbitrary files From: "David Frank" <dave_frank@hotmail.com>, RoadRunner - Central Florida Date: Fri, 07 Nov 2003 16:25:00 GMT .. PL/I has been able to write and write arbitrary files since the first release back in 1966. .. You know this; you have been told many times before. ...

Converting LIANT PL/I for UNIX to VisualAge PL/I for Windows
Has anyone done this (or other UNIX PL/I to Windows PL/I)? I will receive the VisualAge for Windows compiler next week. Does anyone have suggestions how to proceed? For instance, is it true that I will have to subtract 1 from every RECSIZE declaration and remove 1 character from the corresponding record definition? How do I map the files in the PL/I code to the filenames on my C drive (on UNIX it was 'ln -s theunixfilename THEPLIFILE' in a REXX exec)? Thanks, Diane Alves RECSIZE and record definitions should be OK, but you'll find out quickly enough if your declarations conflict. PL/I will hide the lf - crlf differences for you. Your main problem will indeed by the Unix -> Windows issues, in particular with file names; this is typical of any O/S migration, and is not PL/I specific. <alvesdn@nosc.mil> wrote in message news:1103841610.536162.204130@c13g2000cwb.googlegroups.com... > Has anyone done this (or other UNIX PL/I to Windows PL/I)? I will > receive the VisualAge for Windows compiler next week. Does anyone have > suggestions how to proceed? > For instance, is it true that I will have to subtract 1 from every > RECSIZE declaration and remove 1 character from the corresponding > record definition? > How do I map the files in the PL/I code to the filenames on my C > drive (on UNIX it was 'ln -s theunixfilename THEPLIFILE' in a REXX > exec)? > Thanks, > Diane Alves > > How do I map the files...

Random ACM References
Here are a couple of random ACM references - CDC PL/I: "Abrahams, 1979 "The CIMS PL/I compiler" CIMS PL/I is an implementation of PL/I on the Control Data 6600 computer. (no DOI) PL/I Virtual Machines: Sitton, et.al., 1973 "The PL/EXUS language and virtual machine" This paper describes a high level general purpose language which evolved from another high level systems programming language. As well, the compiler, pseudocode, and virtual machine are discussed in some detail. http://doi.acm.org/10.1145/953144.953164 Wade and Schneider, 1973 "A general-purpose high-level language machine for minicomputers" (no DOI) PL/I Hardware: Sugimoto, 1969 "PL/I Reducer and Direct Processor" A computing system is discussed which is aimed at high speed execution of programs written in a problem-oriented language. This computing system has a new machine language. Parallel processing of consecutive instructions and the type of data conversion required for an operation can be easily indicated in the machine language. PL/I is selected for a problem-oriented source language. (no DOI) ...

A Lange & Sohne Grand Lange 1 Prices
A Lange & Sohne Grand Lange 1 Prices Lower Price A Lange & Sohne Grand Lange 1: http://www.fashion163.com/A_Lange_Sohne_Grand_Lange_1.html Luxury Watches Lower Prices: http://www.fashion163.com/ Cheapest A Lange & Sohne Watches http://www.fashion163.com/a_lange_sohne.html We guarantee our A Lange & Sohne Grand Lange 1 and A Lange & Sohne Grand Lange 1 aren't just a simple imitation. We use the same fine materials and technology that the original does. Each A Lange & Sohne Grand Lange 1 produced is examined carefully by our quality test department and every watch...

XHTML 1.1 spec: lang and xml:lang
Hello, I've looked at the latest XHTML spec from 2009-05-07. Referring to http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_commonatts In the I18N module, there are only two attributes listed: dir and xml:lang. The note in the last paragraph says: "Finally, note that the I18N collection only contains the xml:lang attribute unless the Bi- directional Text Module module is selected." This is fine, but... http://www.w3.org/TR/xhtml11/doctype.html says (last paragraph): "This specification also adds the lang attribute to the I18N attribute c...

PL/SQL: What is wrong with the INSERT in this PL/SQL program?
Hello, just started learning PL/SQL (and I'm a complete novice at SQL). Consider the following script: $ cat withdraw_or_deposit.sql -- Insert into database by issuing: -- SQL> @ withdraw_or_deposit -- If compilation errors occur, view them by issuing: -- SQL> show errors -- Run procedure by issuing: -- SQL> EXECUTE withdraw_or_deposit(); SET TERMOUT OFF CREATE SEQUENCE transaction_seq starts with 100 SET TERMOUT ON set serveroutput on; CREATE OR REPLACE PROCEDURE withdraw_or_deposit(accnum IN INTEGER, amount IN INTEGER, empnum IN INTEGER) IS num_acc I...

java.lang.NoClassDefFoundError: org/aspectj/lang/Signature
Hi, Can anyone help me for this exception which I am getting whil trying to conenct to MYSQL server thru TOMCAT. Thanks Maneesh org.apache.commons.dbcp.SQLNestedException: Cannot load JDBC driver class 'com.mysql.jdbc.Driver', cause: java.lang.NoClassDefFoundError: org/aspectj/lang/Signature at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:164) at org.apache.commons.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:730) at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:518) at foo.DBTest.init(DBTest.java:23) at org.apache.jsp.test_jsp._jspService(test_jsp.java:51) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:137) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:210) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256) at org.apache...

Problem running mwc.pl and mpc.pl on Windows 8
Hi, When i try to run the following command: mwc.pl -type vc10 Test.mwc It prompted the following message: MPC_ROOT was set to C:\ACE_wrappers\MPC. Using C:/ACE_wrappers/bin/MakeProjectCreator/config/MPC.cfg CIAO_ROOT was used in the configuration file, but was not defined. DANCE_ROOT was used in the configuration file, but was not defined. ERROR: There is no longer a default project type. Please specify one in MPC.cfg or use the -type option. The following software are installed on my machine: - Windows 8 Pro x64 - ACE+TAO-2.2a p0 - ActivePerl-5.16.3.1603-MSWin32-x64-296746 I do not have this issue when running on Windows 7 SP1 x64. Any help will be appreciated. Regards, Wei Keong Hi Wei, >When i try to run the following command: >mwc.pl -type vc10 Test.mwc > >It prompted the following message: >MPC_ROOT was set to C:\ACE_wrappers\MPC. >Using C:/ACE_wrappers/bin/MakeProjectCreator/config/MPC.cfg >CIAO_ROOT was used in the configuration file, but was not defined. >DANCE_ROOT was used in the configuration file, but was not defined. >ERROR: There is no longer a default project type. > Please specify one in MPC.cfg or use the -type option. > >The following software are installed on my machine: >- Windows 8 Pro x64 >- ACE+TAO-2.2a p0 >- ActivePerl-5.16.3.1603-MSWin32-x64-296746 > >I do not have this issue when running on Windows 7 SP1 x64. > >Any help will be ...

Web resources about - Evolution of PL/I - comp.lang.pl1

Evolution - Wikipedia, the free encyclopedia
Evolution is the change in the inherited characteristics of biological populations over successive generations . Evolutionary processes give ...

Evolution - Wikipedia, the free encyclopedia
This article is about evolution in biology. For related articles, see Outline of evolution . For other uses, see Evolution (disambiguation) . ...

Evolution - Wikipedia, the free encyclopedia
This article is about evolution in biology. For related articles, see Outline of evolution . For other uses, see Evolution (disambiguation) . ...

Evolution - Wikipedia, the free encyclopedia
This article is about evolution in biology. For related articles, see Outline of evolution . For other uses, see Evolution (disambiguation) . ...

Evolution - Wikipedia, the free encyclopedia
This article is about evolution in biology. For related articles, see Outline of evolution . For other uses, see Evolution (disambiguation) . ...

Internet Evolution - The Macrosite for News, Analysis, and Opinion about the Future of the Internet
The next big leap forward in the history of the Internet is happening now: Internet Evolution (www.internetevolution.com) is a Web 2.0 online ...

IoT Evolution World
The Evolution of the IoT and how it is transforming everything

'Out of Africa' theory of human evolution under fire
Two ancient teeth may rewrite our knowledge of how humans spread across the earth and the evidence points to a migration beginning almost 130,000 ...

Two new studies undermine “over-simplistic models of human evolution”
You've probably heard the story about how Neanderthals were living in Europe for hundreds of thousands of years, when suddenly a bunch of Homo ...

W.Va. Schools Consider Creationism And Evolution Scientific Equals
... asks about the teaching of both Creationism, which is absolutely unproven mythology versus teaching the scientific evidenced-based evolution. ...

Resources last updated: 3/19/2016 6:43:21 PM