Re: gnubol: "Extensions" that aid in C/COBOL ILC

[Tim Josling <tej@melbpc.org.au>]

Thanks Bill,
Very sound thinking IMO. See below.
Tim Josling

William M. Klein wrote:

> 1) USAGE POINTER

That's needed for C interfacing and IBM compatibility and it's in
my grammar now for those reasons.

> 2) USAGE PROCEDURE-POINTER

This is needed for some C interfacing, where you have to pass a
procedure address.

> 
> 3)CALL extensions.
>   I would recommend supporting the "BY VALUE" phrase and the "RETURNING"
> phrase.  Both of these are fairly common extensions already and are supported
> in the draft.

Returning is in there now, will have to think about by value
(requires to make a copy). X/Open has strong limits on what can
be passed by value - are these limitations OK (basically only
binary ints).

> 
> 4) CALL-CONVENTION

I am hoping to make the calling convention compatible with C so
this should not be needed, unless I want to interface outside the
GCC environment. 

> 
> 5) Floating-Point data items.
>   The draft adds USAGE
>          FLOAT-SHORT
>          FLOAT-LONG
>          FLOAT-EXTENDED
>   which I think should be added.

Yes agree.

> 
> IBM (and those that emulate it) use COMP-1 and COMP-2.


These are be synonyms for float-short and float-long. These all
map easily to the gcc back end.

>  FYI,  several of the
> "PC" emulators do try and give a choice between S/390 floating-point and IEEE
> floating-point.  This does NOT seem necessary to me in a first
> implementation, but is something to think about.

Definitely one for phase II. IBM has introduced IEEE onto the
mainframe for compatibility reasons. I think I will wait for a
while and see if the old mainframe format dies. At present the
old format runs faster that the IEEE on the mainframe though.

> 
> NOTE WELL:
>   The draft Standard also includes "floating-point numeric-edited" data items
> for "displaying" floating-point items. ...
>
 There is also the concept of
> "ARITHMETIC IS STANDARD" in the draft - which is "really nice" but adds a LOT
> of complexity to the language. It also relates to the expansion of numeric
> data types from 18 to 31 digits.

I will have to look into the f-p numeric edited.

I think the arithmetic is standard is a very useful idea. I
stopped using compute because of 'surprising' results from
truncation etc, which standard arithmetic should resolve.

> 
> 6) "BINARY data"
>  At a minimum, I would recommend adding (from the draft) USAGE
>          BINARY-* each with SIGNED/UNSIGNED sub-options)

There are in the grammar now for C compatibility.

> 
>  In addition, you may want to look at COMP-5 which is an X/Open extension
> (which unlike the draft USAGES does include a PICTURE clause - which can
> include a decimal point).

The X/Open documentation is a bit vague - this sound like a
synonym for IBM COMP (binary), with pic, but it does say it is a
synonym for C int. Where does it say that these can have a
decimal point?

> 
> The "biggest" questions are what to do about the existing extensions which
> handle:
>    - Big-Endian/Little-Endian issues (different PC vendors handle this in

FJ COBOL on intel uses big-endian with no option I could find to
change it. This makes interfacing to C very difficult.

Version I will be native format and we would have to look at the
demand for non-native formats - they are a lot of work. Some code
I know is endian-dependent.

>    - TRUNC/NOTRUNC compiler options which "override" the rules for decimal
> truncation on USAGE BINARY items

I must admit I don't fully understand what the IBM manuals are
talking about here. It is something to do with allowing the full
16 or 32 bits to be used in binary numbers. usage binary-* is a
cleaner way to do this but there may be a significant legacy that
depends on NOTRUNC. It would not be hard to do becase you just
stop generating the extra truncation code which looks like this:

load a
add  1
>>> cmp  9999
>>> jump_not_greater ok1
>>> subtract 9999
>>> ok1:

>    - What does "COMP" mean.  (Although it is COMMON for COMP to equal BINARY;
> there are also implementations where it equals PACKED-DECIMAL and even a few
> where it equals DISPLAY).  In addition, you may want to look at COMP-3 (often
> PACKED-DECIMAL) and COMP-4 (often BINARY) and COMP-6 (often UNSIGNED
> Packed-DECIMAL)
> 

We can have a default that can be overridden; this is not hard to
do.

> A) User-Defined functions.

That's all in the grammar for the reasons you state and for C
compatibility reasons.

>   If you are going to "write your own intrinsic functions in COBOL" - then
> you will need MOST of the stuff required by the draft for these.  On the
> other hand, there are things that the intrinsic functions require that are
> NOT included in the draft Standard for user-defined functions (such as the
> "ALL" subscript and FUNCTION MAX being able to take a variety of types of
> arguments).

They will have to be mapped to user defined functions in some way
(eg the ALL will have to map to a count plus the address of the
first; the variants for MAX and others would either have to be
passed a type or you would need to have multiple versions).

> 
> B) CALL (and function) "proto-types" which allow for argument checking at
> compile-time. (I know that this was mentioned in another thread, so I am
> including it here.  It is in the draft, but not in the '85 Standard).


They are needed to make user defined functions work (otherwise
there is no way to know the return type). A couple of questions:

- do you have any knowledge of how the 'REPOSITORY' is being done
by various vendors?

- IBM has RETURN-CODE which is also in X/Open. I would think that
and GOBACK would be very good to have - is that right?

> 
> C) (*NOT* in the draft Standard)  You need to think very early about whether
> or not you are going to try and provide any "real" EBCDIC support.  If you
> are interested in providing a "supportive" environment for (many) existing
> COBOL programs, this becomes a real issue.  HOWEVER, providing such an
> environment is a LOT of work.

X/Open has EBCDIC as 'STANDARD-1'. You have to think about 

- source code in EBCDIC
- files in EBCDIC
- data items

Overall I think it is a big job. GCC does have a lot of
internationalisation support, so perhaps you could leverage that.
Definitely in phase II+ but worth thinking about.

It's a bit like the big-endian issue, in that you have to
duplicate half the runtime.

> I may think of more items for "C-ificiation" - but did think that this was a
> good starting place for a discussion (both of the desirability and the
> difficulty of some of these extensions).
> 

Much appreciated Bill. A great start.


--
This message was sent through the gnu-cobol mailing list.  To remove yourself
from this mailing list, send a message to majordomo@lusars.net with the
words "unsubscribe gnu-cobol" in the message body.  For more information on
the GNU COBOL project, send mail to gnu-cobol-owner@lusars.net.