Submitted RFE for PL/I enhanement of the ALLOCATE builtin function

[Robert AH Prins]

http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=31632

You need an IBM ID to vote, should you be inclined to do so.

Description:

Since many releases, Enterprise PL/I allows the allocation of defined amounts of
heap using the "ALLOCATE" builtin, to quote the manual:

"ALLOCATE allocates storage of size n in heap storage and returns the pointer to
the allocated storage."

It would be highly advantageous if this builtin function could be enhanced to
allocate a defined (rounded to 8/16 bytes) number of bytes inside an AREA, while
returning a pointer.

Use case:

Parsing XML (and similar) documents frequently result in complex list or tree
structures. Clearing up those structures does require a substantial amount of
processing as each node needs to be FREE'd individually in the correct order to
avoid memory leaks.

By building such lists and/or trees inside an AREA, removal of the entire list
or tree is reduced to a single "AREA=EMPTY();" statement, which saves
significant amounts of CPU time.


Added note for c.p.pl1: It _is_ possible to perform this function directly by
manipulating the AREA header directly (as was (and probably still is) done by a
Belgian bank), but letting the compiler take care of the dirty nitty-gritty
would seem rather more appropriate.

Robert
--
Robert AH Prins
robert(a)prino(d)org

[Shmuel Metz]

In <ap44vs...@mid.individual.net>, on 02/26/2013

at 05:10 PM, Robert AH Prins <spam...@prino.org> said:

>It would be highly advantageous if this builtin function could be
>enhanced to allocate a defined (rounded to 8/16 bytes) number of
>bytes inside an AREA, while returning a pointer.

>Use case:

>Parsing XML (and similar) documents frequently result in complex
>list or tree structures. Clearing up those structures does require
>a substantial amount of processing as each node needs to be FREE'd
>individually in the correct order to avoid memory leaks.
>By building such lists and/or trees inside an AREA, removal of the
>entire list or tree is reduced to a single "AREA=EMPTY();"
>statement, which saves significant amounts of CPU time.

I would expect IBM to respond that the ALLOCATE statement already
provides the requested functionality. You need to provide a case for
needing it in both the statement and the BIF.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org

[Robert AH Prins]

On 2013-02-27 13:32, Shmuel (Seymour J.) Metz wrote:
> In <ap44vs...@mid.individual.net>, on 02/26/2013
> at 05:10 PM, Robert AH Prins <spam...@prino.org> said:
>
>> It would be highly advantageous if this builtin function could be
>> enhanced to allocate a defined (rounded to 8/16 bytes) number of
>> bytes inside an AREA, while returning a pointer.
>
>> Use case:
>
>> Parsing XML (and similar) documents frequently result in complex
>> list or tree structures. Clearing up those structures does require
>> a substantial amount of processing as each node needs to be FREE'd
>> individually in the correct order to avoid memory leaks.
>> By building such lists and/or trees inside an AREA, removal of the
>> entire list or tree is reduced to a single "AREA=EMPTY();"
>> statement, which saves significant amounts of CPU time.
>
> I would expect IBM to respond that the ALLOCATE statement already
> provides the requested functionality. You need to provide a case for
> needing it in both the statement and the BIF.

No it does not in the way requested:

- ALLOCATE {var} IN {area} cannot allocate a discrete amount of storage inside
an AREA
- the ALLOCATE() builtin can only allocate storage on the HEAP, not inside an AREA

[Shmuel Metz]

In <ap8sc4...@mid.individual.net>, on 02/28/2013

at 12:14 PM, Robert AH Prins <spam...@prino.org> said:

>No it does not in the way requested:

>- ALLOCATE {var} IN {area} cannot allocate a discrete amount of
>storage inside an AREA

It can if you declare the variable correctly. People were doing it
before there was an ALLOCATE BIF.

[Robert AH Prins]

On 2013-02-28 14:33, Shmuel (Seymour J.) Metz wrote:
> In <ap8sc4...@mid.individual.net>, on 02/28/2013
> at 12:14 PM, Robert AH Prins <spam...@prino.org> said:
>
>> No it does not in the way requested:
>
>> - ALLOCATE {var} IN {area} cannot allocate a discrete amount of
>> storage inside an AREA
>
> It can if you declare the variable correctly. People were doing it
> before there was an ALLOCATE BIF.

And how would you declare your text? As VAR with a maximum length of how many
bytes, and waste oodles of storage for short data from the XML file? Using the
ALLOCATE builtin, you can request 16 bytes, or 1600 and use one and the same
structure, something like

dcl 1 xml_node based,
2 left ptr,
2 right ptr,
2 child ptr,
2 parent ptr,
2 data char(32767) var;

for every node, and you do not have to use a SELECT to find an appropriately
sized one.

I've already mentioned that it's easy, relatively speaking, to actually
manipulate the AREA header, just as easy as using three substr builtin
functions, or a "BY NAME" assignment to convert a date from the
less-than-logical US MM/DD/YYYY to the ISO 8601 YYYY-MM-DD format, rather than
having the specific format modifier that is now present on every date and time
related builtin. Are you now going to say that these useful(ish) extra arguments
to those functions are also unnecessary additions?

Hell, I guess you cursed they day the developers added a HEX builtin function,
it made all those nice loops and look-up tables obsolete.

You want to see more people using PL/I? Give them the functions they already
have in other languages.

Robert

[John W Kennedy]

On 2013-02-28 16:39:20 +0000, Robert AH Prins said:

> On 2013-02-28 14:33, Shmuel (Seymour J.) Metz wrote:
>> In <ap8sc4...@mid.individual.net>, on 02/28/2013
>> at 12:14 PM, Robert AH Prins <spam...@prino.org> said:
>>
>>> No it does not in the way requested:
>>
>>> - ALLOCATE {var} IN {area} cannot allocate a discrete amount of
>>> storage inside an AREA
>>
>> It can if you declare the variable correctly. People were doing it
>> before there was an ALLOCATE BIF.
>
> And how would you declare your text? As VAR with a maximum length of
> how many bytes, and waste oodles of storage for short data from the XML
> file? Using the ALLOCATE builtin, you can request 16 bytes, or 1600
> and use one and the same structure, something like
>
> dcl 1 xml_node based,
> 2 left ptr,
> 2 right ptr,
> 2 child ptr,
> 2 parent ptr,
> 2 data char(32767) var;
>
> for every node, and you do not have to use a SELECT to find an
> appropriately sized one.

Actually, the sensible way is to use REFER; that's what it's for, and
it avoids nasty problems like, "How many bytes in a pointer?"

However, given that the ALLOCATE b.i.f. exists, there's no point in
crippling it.

> I've already mentioned that it's easy, relatively speaking, to actually
> manipulate the AREA header, just as easy as using three substr builtin
> functions, or a "BY NAME" assignment to convert a date from the
> less-than-logical US MM/DD/YYYY to the ISO 8601 YYYY-MM-DD format,
> rather than having the specific format modifier that is now present on
> every date and time related builtin. Are you now going to say that
> these useful(ish) extra arguments to those functions are also
> unnecessary additions?
>
> Hell, I guess you cursed they day the developers added a HEX builtin
> function, it made all those nice loops and look-up tables obsolete.
>
> You want to see more people using PL/I? Give them the functions they
> already have in other languages.

Like OO, a formal resolution of the boolean/shortcut issue,
byte-oriented files, data in virtual, overloading without the GENERIC
hack, namespaces, and integer variables as distinct from fixed? And, it
goes without saying, a Language Specification that actually specifies
the current language?

--
John W Kennedy
"Only an idiot fights a war on two fronts. Only the heir to the throne
of the kingdom of idiots would fight a war on twelve fronts"
-- J. Michael Straczynski. "Babylon 5", "Ceremonies of Light and Dark"

[Peter Flass]

Do something like >> dcl 1 xml_node based,

>> 2 left ptr,
>> 2 right ptr,
>> 2 child ptr,
>> 2 parent ptr,

>> 2 data char(0) var;

p = ALLOCATE( stg(null()->xml_node) + length_of_text );

Then you don't care how many bytes in a pointer. I always try to avoid
explicit lengths in favor of letting the compiler figure it out.

--
Pete

[Robert AH Prins]

On 2013-02-28 16:45, John W Kennedy wrote:
> On 2013-02-28 16:39:20 +0000, Robert AH Prins said:
>
>> On 2013-02-28 14:33, Shmuel (Seymour J.) Metz wrote:
>>> In <ap8sc4...@mid.individual.net>, on 02/28/2013
>>> at 12:14 PM, Robert AH Prins <spam...@prino.org> said:
>>>
>>>> No it does not in the way requested:
>>>
>>>> - ALLOCATE {var} IN {area} cannot allocate a discrete amount of
>>>> storage inside an AREA
>>>
>>> It can if you declare the variable correctly. People were doing it
>>> before there was an ALLOCATE BIF.
>>
>> And how would you declare your text? As VAR with a maximum length of how many
>> bytes, and waste oodles of storage for short data from the XML file? Using
>> the ALLOCATE builtin, you can request 16 bytes, or 1600 and use one and the
>> same structure, something like
>>
>> dcl 1 xml_node based,
>> 2 left ptr,
>> 2 right ptr,
>> 2 child ptr,
>> 2 parent ptr,
>> 2 data char(32767) var;
>>
>> for every node, and you do not have to use a SELECT to find an appropriately
>> sized one.
>
> Actually, the sensible way is to use REFER; that's what it's for, and it avoids
> nasty problems like, "How many bytes in a pointer?"

Maybe now that more access to REFER based structures is being in-lined, yes, but
REFER used to be an absolute killer as far as performance was considered.

One of the changes I made at a client in 1996 (which in combination saved them
around eur 120,000 per year) was to pass "BASED REFER" structures to a
procedure where they were declared with '*' extents. Peter Elderon almost
verbatim copied my suggestion to do so to save CPU into chapter 13 of the PL/I
Programming Guide.

[Shmuel Metz]

In <ap9bsr...@mid.individual.net>, on 02/28/2013

at 04:39 PM, Robert AH Prins <spam...@prino.org> said:

>And how would you declare your text?

DECLARE FOO CHAR(BAR);

>As VAR with a maximum length of how many bytes, and waste oodles
>of storage for short data from the XML file?

VAR is your idea, not mine.

>Using the ALLOCATE builtin, you can request 16 bytes, or 1600 and
>use one and the same structure, something like

>dcl 1 xml_node based,
> 2 left ptr,
> 2 right ptr,
> 2 child ptr,
> 2 parent ptr,
> 2 data char(32767) var;

I could do the same thing using the ALLOCATE statement, but I'd rather
not create a buffer overrun bug. If I allocate 16 bytes then I want a
structure that is only 16 bytes long.

>I've already mentioned that it's easy, relatively speaking, to
>actually manipulate the AREA header,

There are many easy ways to shoot yourself in the foot.

>Are you now going to say that these useful(ish) extra arguments to
>those functions are also unnecessary additions?

Have you stopped beating your wife? Please respond to what I wrote and
not to your fantasies. I am saying that if you want IBM to take you
seriously then you need to provide a better justification than "I want
a pony." If you'd prefer feeling self-righteous about their refusal to
give you what you asked for, by all means skimp on the business case.

>Hell, I guess you cursed they day the developers added a HEX builtin
>function,

Your guesses are worth almost as much as I paid for them.

>You want to see more people using PL/I? Give them the functions they
>already have in other languages.

I'm not IBM, but I've dealt with them for decades. I can predict the
likely outcome if you don't provide an adequate business case. I'm not
the one that you have to convince.

[James J. Weinkam]

Robert AH Prins wrote:
>> Actually, the sensible way is to use REFER; that's what it's for, and it avoids
>> nasty problems like, "How many bytes in a pointer?"
>
> Maybe now that more access to REFER based structures is being in-lined, yes, but REFER used to be an absolute killer as
> far as performance was considered.
>
> One of the changes I made at a client in 1996 (which in combination saved them around eur 120,000 per year) was to pass
> "BASED REFER" structures to a procedure where they were declared with '*' extents. Peter Elderon almost verbatim copied
> my suggestion to do so to save CPU into chapter 13 of the PL/I Programming Guide.
>

I think you are missing the point on the use of refer. The extra overhead you are objecting to only occurs if you access
the allocated storage using the declaration used to allocate it. The following function is equivalent for all intents
and purposes to what you want:

alloc: proc(a,n) returns(ptr);
dcl
a area, n bin fixed(31) byvalue, p ptr,
1 space based(p),
2 amt bin fixed(31)
2 bytes(n refer(amt)) char(1);
n-=4; allocate space in(a); return(p);
end alloc;

After executing p=alloc(a,n); you can use the n bytes pointed at by p using whatever based declaration you wish just as
you would after having allocated n bytes using the allocate built in function.

Emptying the area will free everything in one fell swoop as you want. If you should want to free some of the storage
piecemeal, you would have to restore the correct value of p->amt before executing free p->space in(a) or all hell would
break loose.

In Personal PL/I for OS/2 and, I suspect, in the other workstation implementations as well, storage of whatever class
allocated by the allocate statement as well as storage allocated by the allocate built in function is taken from the
heap. Heap allocation has an allocation granularity of 16 bytes and a hidden overhead of 16 bytes and is always
paragraph aligned. Controlled storage has additional hidden overhead. allocate(n) consumes 16+16*ceil(n/16) bytes. On
the other hand, based variable allocation within an area using the allocate statement has an allocation granularity of 8
and no hidden overhead. Thus allocation in an area of an item that requires n bytes consumes 8*ceil(n/8) bytes of the
area. It is the 16 hidden overhead bytes on the heap that enables plifree(p) to work. There is no way your suggestion
could be implemented without a major redesign that would affect the behavior of existing programs.

[Peter J. Seymour]

On 2013-02-26 17:10, Robert AH Prins wrote:
> http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=31632
>
> You need an IBM ID to vote, should you be inclined to do so.
>
> Description:
>
> Since many releases, Enterprise PL/I allows the allocation of defined
> amounts of heap using the "ALLOCATE" builtin, to quote the manual:
>
> "ALLOCATE allocates storage of size n in heap storage and returns the
> pointer to the allocated storage."
>

>.....
>
> Robert

I have a question on Allocate/Free having been doing some coding in the
subject area of this thread recently.
I am doing something like: PTR P = ALLOCATE(alength);
So I get a pointer to the allocated storage which is on the heap but not
in an area. The question is how do I free this allocated storage? I
cannot see a way of doing it. The manuals say "FREE basedvariable", but
I do not have a based variable that corresponds in length with the
allocation. If I do "FREE P->anybasedvariable" no error occurs but I
have no idea if it was correct. What I really want is "FREE (ptr)" and
trust the system to know what I mean.
(Far better to use REFER but that is another story at the moment).
Any comments?

[Robin Vowels]

On Mar 2, 7:54 pm, "Peter J. Seymour" <Newsgro...@pjsey.demon.co.uk>
wrote:

> I have a question on Allocate/Free having been doing some coding in the
> subject area of this thread recently.
> I am doing something like: PTR P = ALLOCATE(alength);
> So I get a pointer to the allocated storage which is on the heap but not
> in an area. The question is how do I free this allocated storage? I
> cannot see a way of doing it. The manuals say "FREE basedvariable", but
> I do not have a based variable that corresponds in length with the
> allocation. If I do "FREE P->anybasedvariable" no error occurs but I
> have no idea if it was correct. What I really want is "FREE (ptr)" and
> trust the system to know what I mean.
> (Far better to use REFER but that is another story at the moment).

You use the PLIFREE built-in subroutine.

[Robert AH Prins]

On 2013-02-26 17:10, Robert AH Prins wrote:

http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=31632

Status: Planned for Future Release

As you can see, even a relative nobody can come up with something that may some
day become part of the language, and now that even individuals can submit
requests for enhancement (RFE's), and make a case for them, what's stopping
*YOU* from improving our favourite language.