cobolforgcc-devel — For discussion about development of COBOL for GCC

[Cobolforgcc-devel] Re: Numeric Moves, Unedit, & Unedit Moves and other changes.

[Tim J. <te...@me...>]

Ted,

I have incorporated all your files with some minor changes into
the source tree. I will send a tar file seperately - could you
use this as the base for any future changes. I will try and do
the CVS update tomorrow.

The file temp_cobr_config.h had slightly different versions in
the various directories and I have brought that together. It may
be best for you to keep it all in one directory. I turned off the
128 bit versions of the bindec until we work out houw to use the
bin128 code in them.

Tim Josling


[Cobolforgcc-devel] Re: Numeric Moves, Unedit, & Unedit Moves

[Tim J. <te...@me...>]

"Theodore J. Seward, Jr." wrote:
> 
> Tim,
> 
> Here are the Numeric Move, unedit, and unedit move routines.  I
> think I've got it working okay, but as before I'm sure errors
> will be there and fixed over time.  Before things are done,
> these routines would most likely be rewritten as needed.
> 
> I'll try to finish the display in the next few days.
> 
> Good Luck - Ted Seward
> 
> Numeric Edited Moves
> ------- ------ -----
> 
> 
> --------
> Overview
> --------
> 
> Routines like these have to start with an apology.  They are
> sometimes slow, take
> lots of arguments.  The main reason is processing of all data
> types versus all data
> types.  The argument list look more complex than they really
> are.  Please look at
> the examples in test_cobr_editMove.c for examples.
> 
> 
> These routines provide 3 basic types of functionality;
> 
> *  Moving non edited fields to edited fields
> *  Moving edited fields to edited fields
> *  Unediting a fields
> 
> 
> There are two minor services:
> 
> *  Changing the currency symbol
> *  Swapping the meaning of the Decimal and comma.
> 
> 
> Typical, the compiler will call one function to do some basic
> analysis of the picture
> clauses.  The results of this call will provide the arguments
> needed to generate the
> call to be inserted into the output.
> 
> 
> For example, to move a non edited field to an edited field:
> 
> 1.  The compiler will call the routine cobr_emEditMove_Analyze
> to encode the
>     source and destination pictures, plus provide a few
> counters pertaining to
>     the decimal points relationship between the picture
> clauses.
> 
> 2.  The compiler will emit code to call cobr_emEditMove, with
> arguments pointing
>     to the source and destination fields along with the output
> returned by the
>     analysis program.
> 
> 
> The supplied functions are (See prototypes later in this file):
> 
> 
> 
> cobr_emEditMove_Analyze   - Compiler analysis routine for
> EditMove
> cobr_emEditMove           - Move numeric fields
> cobr_emUnedit_Analyze     - Complier analysis routine for
> unedit of edited field
> cobr_emUnedit             - Unedit an edited field
> cobr_emUneditMove_Analyze - Compiler analysis routine for
> unedit move
> cobr_emUneditMove         - move an edited field
> cobr_emSetCurrencySymbol  - Set the Currency Symbol (defaults
> to Currency='$')
> cobr_emSetDecimalIsComma  - Set Decimal is Comma flag (defaults
> to Decimal='.')
> 
> 
> ------------------------------------------------------------------
> 
> Typical code for compiler -- Note printf below implies emited
> code
> ------------------------------------------------------------------
> 
> 
> 
>    Moving non edited field to edited field
>    ---------------------------------------
> 
>    char destPic[32];   /* Destination Picture */
>    char sourcePic[32]; /* Source Picture */
>    char outArea[32];   /* Output Area */
> 
>    int  digTotal;      /* Total digits in destination */
>    int  digLeft;       /* Digits to left of decimal in
> destination */
>    int  digRight;      /* Digits to right of decimal in soruce
> */
>    char editPic[32];   /* Encoded desintation picture */
> 
>    cobr_emEditMove_Analyze (editPic, &digTotal, &digLeft,
> &digRight, destPic, sourcePic);
> 
>    printf("cobr_emEditMove (outArea, sizeof(outArea),
> cobr_typeDisplay, cobr_flagNull,\n");
>    printf("                 \"%s\", %d, %d, %d,\n", editPic,
> digTotal, digLeft, digRight);
>    printf("                 inValue, inLen,
> cobr_typeDisplay,\n");
>    printf("
> cobr_flagSignLead|cobr_flagOverpunch);\n");
> 
> 
>    Moving Edited field to edited field
>    -----------------------------------
> 
>    char destPic[32];   /* Destination Picture */
>    char sourcePic[32]; /* Source Picture */
>    char outArea[32];   /* Output Area */
> 
>    int  digTotal;      /* Total digits in destination */
>    int  digLeft;       /* Digits to left of decimal in
> destination */
>    int  digRight;      /* Digits to right of decimal in soruce
> */
>    int  digUnedit;     /* Digits unedited */
>    char editPic[32];   /* Encoded desintation picture */
>    char uneditPic[32]; /* Source unediting Picture */
> 
>    cobr_emUneditMove_Analyze (editPic, &digTotal, &digLeft,
> &digRight,
>                               uneditPic, &digUnedit, destPic,
> sourcePic);
> 
>    printf("cobr_emUneditMove (outArea, sizeof(outArea),
> cobr_typeDisplay, cobr_flagNull,\n");
>    printf("                   \"%s\, %d, %d, %d,\n", editPic,
> digitTotal, digitLeft, digitRight);
>    printf("                   \"%s\", %d, inValue,
> cobr_typeDisplay, cobr_flagNull);\n",uneditPic,digUnedit);
> 
> 
>    Unedit fields
>    -------------
> 
>    char sourcePic[32]; /* Source Picture */
>    char outArea[32];   /* Output Area */
> 
>    int  digUnedit;     /* Digits unedited */
>    char editPic[32];   /* Encoded desintation picture */
>    char uneditPic[32]; /* Source unediting Picture */
> 
>    cobr_emUnedit_Analyze (editPic, uneditPic, &digUnedit,
> sourcePic);
> 
>    printf("cobr_emUnedit (outArea, sizeof (outArea), \"%s\",
> %d,\n",uneditPic,digUnedit);
>    printf("               inValue, cobr_typeDisplay,
> cobr_flagNull);\n");
> 
> 
> ---------------------------------------------
> Defeind bit flags for data types and modifier
> ---------------------------------------------
> 
> //      Usage Types
> 
> #define cobr_typeNull         0x00000000 /* Null type */
> #define cobr_typeText         0x80000000 /* Text Type */
> #define cobr_typeDisplay      0x40000000 /* Display */
> #define cobr_typePacked       0x20000000 /* Packed Decimal */
> #define cobr_typeBinary       0x10000000 /* Signed binary */
> #define cobr_typeUnsigned     0x08000000 /* Unsigned binary */
> #define cobr_typeFloat        0x04000000 /* Floating point */
> 
> 
> //      Usage Flags
> 
> #define cobr_flagNull         0x00000000 /* Null type */
> #define cobr_flagSignLead     0x80000000 /* Display with SIGN
> IS LEADING */
> #define cobr_flagSignTrail    0x40000000 /* Display with SIGN
> IS TRAILING */
> #define cobr_flagOverpunch    0x20000000 /* Display with SIGN
> IS TRAILING SEPARATE CHARACTER */
> 
> ------------------------------------------------
> Actual data type definitions defined in config.h
> ------------------------------------------------
> 
> Singed Integer Binary Data Types
> 
> #define INT8    signed char          /* 8 bit signed binary */
> #define INT16   short                /* 16 bit signed binary */
> 
> #define INT32   int                  /* 32 bit signed binary */
> 
> #define INT64   long long            /* 64 bit signed binary */
> 
> #define INT128  long long            /* 128 bit signed binary
> */
> 
> Unsinged Integer Binary Data Types
> 
> #define UINT8   unsigned char        /* 8 bit unsigned binary
> */
> #define UINT16  unsigned short       /* 16 bit unsigned binary
> */
> #define UINT32  unsigned int         /* 32 bit unsigned binary
> */
> #define UINT64  unsigned long long   /* 64 bit unsigned binary
> */
> #define UINT128 unsigned long long   /* 128 bit unsigned binary
> */
> 
> Floating point Binary Data Types
> 
> #define FLOAT32 float                /* 32 bit floating point
> */
> #define FLOAT64 double               /* 64 bit floating point
> */
> #define FLOAT128 long double         /* 128 bit floating point
> */
> 
> ----------
> Prototypes
> ----------
> 
> char     *
>           cobr_emEditMove_Analyze  /* Destination */
>             (char *Picture,        /* Output Picture */
>              int *destDigitTotal,  /* Digits in destination */
>              int *destDigitLeft    /* Destination digits left
> of decimal */
>              int *sourceDigitRight,/* Source digits right of
> decimal */
>              char *destPic,        /* Destination Picture */
>              char *sourcePic);     /* Source Picture */
> 
> int     cobr_emEditMove
>             (void *dest,           /* Destination */
>              size_t destLen,       /* Destination Length */
>              int destType,         /* Destination Type */
>              int destFlags,        /* Destination flags */
>              char *picture,        /* Destination Encoded
> Picture (from cobr_emEditMove_Analyze) */
>              int destDigitTotal,   /* total digits in number
> (from cobr_emEditMove_Analyze) */
>              int destDigitLeft,    /* digits to left of decimal
> in destination (from cobr_emEditMove_Analyze) */
>              int sourceDigitRight, /* digits to right of
> decimal in source (from cobr_emEditMove_Analyze) */
>              void *source,         /* Source */
>              size_t sourceLen,     /* Source Length */
>              int sourceType,       /* Source Type */
>              int sourceFlags);     /* Source Flags */
> 
> char     *                         /* destPicture */
>           cobr_emUnedit_Analyze
>             (char *editPicture,    /* edit Picture (for
> cobr_em_editMove) */
>              char *uneditPicture,  /* Unedit picture (for
> cobr_emUnedit) */
>              int *uneditDigits,    /* Digits in unedited
> picture (for cobr_emUnedit) */
>              char *sourcePic);     /* Source Picture */
> 
> char     *                         /* Destination */
>           cobr_emUnedit
>             (void *dest,           /* Destination */
>              size_t destLen,       /* Destination Length */
>              char *uneditPic,      /* Unedit Encoded Picture
> (from cobr_emUnedit_Analyze) */
>              int uneditDigits,     /* Unedit Digits (from
> cobr_emUnedit_Analyze) */
>              void *source,         /* Source */
>              int sourceType,       /* Source Type */
>              int sourceFlags);     /* Source Flags */
> 
> int     cobr_emUneditMove_Analyze
>             (char *Picture,        /* Encoded Output Picture */
> 
>              int *destDigitTotal,  /* Digits in destination */
>              int *destDigitLeft,   /* Destination digits left
> of decimal */
>              int *sourceDigitRight,/* Source digits right of
> decimal */
>              char *uneditPicture,  /* Unedit Picture */
>              int *uneditDigits,    /* Digits in unedited
> picture */
>              char *destPic,        /* Original Destination
> Picture */
>              char *sourcePic);     /* Original Source Picture
> */
> 
> int     cobr_emUneditMove
>             (void *dest,           /* Destination */
>              size_t destLen,       /* Destination Length */
>              int destType,         /* Destination Type */
>              int destFlags,        /* Destination Flags */
>              char *Picture,        /* Destination Encoded
> Picture  */
>              int destDigitTotal,   /* total digits in number
> */
>              int destDigitLeft,    /* digits to left of decimal
> in destination */
>              int sourceDigitRight, /* digits to right of
> decimal in source */
>              char *uneditPicture,  /* Picture for unedited data
> */
>              int uneditDigits,     /* Digits in unedited
> picture */
>              void *source,         /* Source */
>              int sourceType,       /* Source Type */
>              int sourceFlags);     /* Source Flags */
> 
> int     cobr_emSetCurrencySymbol
>             (char symbol);         /* New currency symbol */
> 
> int     cobr_emSetDecimalIsComma
>             (int flag);            /* True if Decimal characer
> is comma */
> 
> 
> 
>                            Name: cobr_editMove.tar.gz
>    cobr_editMove.tar.gz    Type: Unix Tape Archive
>                                  (application/x-tar)
>                        Encoding: base64

[Cobolforgcc-devel] Re: Cleaned 128 bit math

[Tim J. <te...@me...>]

"Theodore J. Seward, Jr." wrote:
> 
> Tim,
> 
> I think I have all the routine names and warning messages cleaned up.  If you find any errors, please let me know and I'll gladly fix them.
> 
> Good Luck - Ted Seward
> 
> --------------------------------------------------
> Signed 128 bit routine (LL = stands for long long)
> --------------------------------------------------
> 
> typedef name:         binLLL
> typedef pointer name: binLLLPtr
> 
> Note:  binLLL is the same definition as binULLL
>        binLLLPtr is the same definition as binULLLPtr
> 
> INT128_MIN  = Binary minimum value: -170141183460469231731687303715884105728
> INT128_MAX  = Binary maximum value: +170141183460469231731687303715884105727
> INT128_ZERO = Binary value:          0
> 
> Header File:  COBR_BIN128LLL.h
> Routines:     COBR_BIN128LLL.c
> 
> 
> Example
> -------
> 
> #include "COBR_BIN128LLL.h"
> 
> binLLL a,b,c,r;
> char  str[50];
> 
> cobr_LLL_i32toi(b,57);
> cobr_LLL_i32toi(c,10);
> cobr_LLL_div(a,r,b,c);
> printf("a = %s\n",cobr_LLL_itoa(str,a));  /* prints 5 */
> printf("r = %s\n",cobr_LLL_itoa(str,r));  /* prints 7 */
> 
> 
> Arithmetic
> ----------
> 
> cobr_LLL_add(a,b,c)        - a := b + c
> cobr_LLL_sub(a,b,c)        - a := b - c
> cobr_LLL_mul(a,b,c)        - a := b * c
> cobr_LLL_div(a,r,b,c)      - a := b / c; r := b % c
> cobr_LLL_complement(a)     - a := -a
> cobr_LLL_copy(a,b)         - a := b                        [Macro]
> cobr_LLL_zero(a)           - a := 0                        [Macro]
> 
> 
> Comparisons
> -----------
> 
> cobr_LLL_compare(a,b)      - a::b; -1 := a<b,  0 := a==b, +1 := a>b
> cobr_LLL_eq(a,b)           - a::b,  1 := a==b, 0 := a!=b   [Macro]
> cobr_LLL_ne(a,b)           - a::b,  1 := a!=b, 0 := a==b   [Macro]
> cobr_LLL_lt(a,b)           - a::b,  1 := a<b,  0 := a>=b   [Macro]
> cobr_LLL_le(a,b)           - a::b,  1 := a<=b, 0 := a>b    [Macro]
> cobr_LLL_gt(a,b)           - a::b,  1 := a>b,  0 := a<=b   [Macro]
> cobr_LLL_ge(a,b)           - a::b,  1 := a>=b, 0 := a<b    [Macro]
> cobr_LLL_ifzero(a)         - a::0,  1 := a==0, 0 := a!=0   [Macro]
> 
> 
> Convert from LL to other type
> -----------------------------
> 
> cobr_LLL_itoa(&ascii,a)    - returns ASCII   ascii := a (returns ptr to ascii)
> cobr_LLL_itod(&pd,pdlen,a) - returns Packed  pd    := a
> cobr_LLL_itoi8(&i8, a)     - returns INT8    *i8   := a
> cobr_LLL_itoi16(&i16,a)    - returns INT16   *i16  := a
> cobr_LLL_itoi32(&i32,a)    - returns INT32   *i32  := a
> cobr_LLL_itoi64(&i64,a)    - returns INT64   *i64  := a
> 
> 
> Convert other types to LL
> -------------------------
> 
> cobr_LLL_dtoi(a,&pd,pdlen) - sets Packed  a := pd
> cobr_LLL_atoi(a,&ascii)    - sets ASCII   a := ASCII
> cobr_LLL_i8toi(a,i8)       - sets INT8    a := i8
> cobr_LLL_i16toi(a,i16)     - sets INT16   a := i16
> cobr_LLL_i32toi(a,i32)     - sets INT32   a := i32
> cobr_LLL_i64toi(a,i64)     - sets INT64   a := i64
> 
> 
> Shifts
> ------
> 
> cobr_LLL_shl(a,n)          - a := a << n
> cobr_LLL_shra(a,n)         - a := a >> n  [arithmetic]
> cobr_LLL_shr(a,n)          - a := a >> n  [logical]
> 
> 
> --------------------------------------------------------------
> Unsigned 128 bit routine (ULL = stands for unsigned long long)
> --------------------------------------------------------------
> 
> typedef name:         binULLL
> typedef pointer name: binULLLPtr
> 
> Note:  binULLL is the same definition as binLLL
>        binULLLPtr is the same definition as binLLLPtr
> 
> UINT128_MIN  = Binary minimum value: 0
> UINT128_MAX  = Binary maximum value: 340282366920938463463374607431768211455
> UINT128_MAX  = Binary value:         0
> 
> Header File:  COBR_BIN128ULLL.h
> Routines:     COBR_BIN128ULLL.c
> 
> 
> Example
> -------
> 
> #include "COBR_BIN128ULLL.h"
> 
> binULLL a,b,c,r;
> char  str[50];
> 
> cobr_ULLL_i32toi(b,57);
> cobr_ULLL_i32toi(c,10);
> cobr_ULLL_div(a,r,b,c);
> printf("a = %s\n",cobr_ULLL_itoa(str,a));  /* prints 5 */
> printf("r = %s\n",cobr_ULLL_itoa(str,r));  /* prints 7 */
> 
> 
> Arithmetic
> ----------
> 
> cobr_ULLL_add(a,b,c)        - a := b + c
> cobr_ULLL_sub(a,b,c)        - a := b - c
> cobr_ULLL_mul(a,b,c)        - a := b * c
> cobr_ULLL_div(a,r,b,c)      - a := b / c; r := b % c
> cobr_ULLL_copy(a,b)         - a := b                        [Macro]
> cobr_ULLL_zero(a)           - a := 0                        [Macro]
> 
> 
> Comparisons
> -----------
> 
> cobr_ULLL_compare(a,b)      - a::b; -1 := a<b,  0 := a==b, +1 := a>b
> cobr_ULLL_eq(a,b)           - a::b,  1 := a==b, 0 := a!=b   [Macro]
> cobr_ULLL_ne(a,b)           - a::b,  1 := a!=b, 0 := a==b   [Macro]
> cobr_ULLL_lt(a,b)           - a::b,  1 := a<b,  0 := a>=b   [Macro]
> cobr_ULLL_le(a,b)           - a::b,  1 := a<=b, 0 := a>b    [Macro]
> cobr_ULLL_gt(a,b)           - a::b,  1 := a>b,  0 := a<=b   [Macro]
> cobr_ULLL_ge(a,b)           - a::b,  1 := a>=b, 0 := a<b    [Macro]
> cobr_ULLL_ifzero(a)         - a::0,  1 := a==0, 0 := a!=0   [Macro]
> 
> 
> Convert from ULL to other type
> ------------------------------
> 
> cobr_ULLL_itoa(&ascii,a)    - returns ASCII   ascii := a (returns ptr to ascii)
> cobr_ULLL_itod(&pd,pdlen,a) - returns Packed  pd    := a
> cobr_ULLL_itoi8(&i8, a)     - returns INT8    *i8   := a
> cobr_ULLL_itoi16(&i16,a)    - returns INT16   *i16  := a
> cobr_ULLL_itoi32(&i32,a)    - returns INT32   *i32  := a
> cobr_ULLL_itoi64(&i64,a)    - returns INT64   *i64  := a
> 
> 
> Convert other types to ULL
> --------------------------
> 
> cobr_ULLL_dtoi(a,&pd,pdlen) - sets Packed  a := pd
> cobr_ULLL_atoi(a,&ascii)    - sets ASCII   a := ASCII
> cobr_ULLL_i8toi(a,i8)       - sets INT8    a := i8
> cobr_ULLL_i16toi(a,i16)     - sets INT16   a := i16
> cobr_ULLL_i32toi(a,i32)     - sets INT32   a := i32
> cobr_ULLL_i64toi(a,i64)     - sets INT64   a := i64
> 
> 
> Shifts
> ------
> 
> cobr_ULLL_shl(a,n)          - a := a << n
> cobr_ULLL_shr(a,n)          - a := a >> n
> 
> 
> 
> ----------------------------
> Ideas on Future Optimization
> ----------------------------
> 
> The divide routine is the slowest.  Anything that speeds up a routine that is called by division will speed up division (shl, shr, add, sub).
> 
> Modify the routines to use register types for the most commonly called routines.
> 
> Consider special macro forms of commonly called routines from (add, sub, shl, shr) for divide & multiply.  Use these macros inside of the other math routines so there is a savings on function linkage.
> 
>                          Name: cobr_bin128.tar.gz
>    cobr_bin128.tar.gz    Type: Unix Tape Archive (application/x-tar)
>                      Encoding: base64

Re: [Cobolforgcc-devel] Cleaned Decimal / Binary routines

[Tim J. <te...@me...>]

"Theodore J. Seward, Jr." wrote:
> 
> Tim,
> 
> I think I have the file names all cleaned up as you requested.  The compile options have all the requested warning checks.  I've gone through and removed all warnings.  Even as I send this I notice there are inconsistencies in the readme file.
> 
> Good Luck  - Ted Seward
> 
>               Decimal / Binary Conversion Routines
>               ------- - ------ ---------- --------
> 
> The following routines are provided by these files:
> 
>    Packed Decimal to:
> 
>       Signed 16 bit binary    cobr_dtb_INT16
>       Unsigned 16 bit binary  cobr_dtb_UINT16
>       Signed 32 bit binary    cobr_dtb_INT32
>       Unsigned 32 bit binary  cobr_dtb_UINT32
>       Signed 64 bit binary    cobr_dtb_INT64
>       Unsigned 64 bit binary  cobr_dtb_UINT64
>       Signed 128 bit binary   cobr_dtb_INT128
>       Unsigned 128 bit binary cobr_dtb_UINT128
> 
>    Packed Decimal from:
> 
>       Signed 16 bit binary    cobr_btd_INT16
>       Unsigned 16 bit binary  cobr_btd_UINT16
>       Signed 32 bit binary    cobr_btd_INT32
>       Unsigned 32 bit binary  cobr_btd_UINT32
>       Signed 64 bit binary    cobr_btd_INT64
>       Unsigned 64 bit binary  cobr_btd_UINT64
>       Signed 128 bit binary   cobr_btd_INT128
>       Unsigned 128 bit binary cobr_btd_UINT128
> 
>    Validation:
> 
>       Validate Packed Number  cobr_validate_packed
> 
> Several problems arose while I was coding these routines, which I
> now think are fixed:
> 
> *  My PC at home is only capable of 32 bit binary.  When I
>    display the size of long, I get 4 bytes.
> 
> *  The GNU C compiler does not even support type "long long",
>    i.e. 128 bit binary.
> 
> *  The code for each version (16, 32, 64, 128) was so close,
>    except for a few constants and data types, that any maintenance
>    would likely skip one of the types.
> 
> *  The 2**128 is a large number exceeding compiler limits, e.g.
> 
>     128
>    2    = 340,282,366,920,938,463,463,374,607,431,768,211,456
> 
>    but
> 
> The problems were solved as follows:
> 
> *  While I could not test the 64 or 128 bit versions, I could
>    make sure that they used the same logic path as 16 and 32 so
>    that the chance of failure would be low since the paths were
>    already tested.
> 
>    This was done by placing all the code in a single header file
>    (cobr_decbinxx.h) with macro symbols for the routine names and
>    for any type specific constant.  For each routines, e.g.
>    cobr_decbin32.c, the source member would set symbols for the
>    routine names, data types, and data width prior to including
>    the header file.
> 
>    The header file, has some conditional tests at the top which
>    will set the constants for the given type based on the width
>    of the type (set in the file including it).  This stops any
>    warnings or errors caused by a hard coded constant that the
>    machine does not support.  For example (The actual source code
>    has comments not included in this example):
> 
> 
>    +----------+
>    | config.h |
>    +----------+
> 
>     ...
>    #define INT32       int
>    #define UINT32      unsigned int
>    #define INT32_WIDTH (4)
>     ...
> 
>    +---------------+
>    | cobr_decb32.c |
>    +---------------+
> 
>     ...
>    #include "config.h"
>     ...
>    #define INT_WIDTH     INT32_WIDTH
>    #define INT_BTD_NAME  cobr_btd_INT32
>    #define INT_DTB_NAME  cobr_dtb_INT32
>    #define INT_HANDLER   cobr_INT32_handler
>    #define INT_TYPE      INT32
>    #define UINT_BTD_NAME cobr_btd_UINT32
>    #define UINT_DTB_NAME cobr_dtb_UINT32
>    #define UINT_HANDLER  cobr_UINT32_handler
>    #define UINT_TYPE     UINT32
>     ...
>    #include "cobr_decbxx.h"
> 
>    +---------------+
>    | cobr_decbxx.h |
>    +---------------+
> 
>     ...
>    #elif INT_WIDTH == 4
>    #define INT_MAXCHAR       (10)
>    #define INT_MAXPOS_CHAR   "2147483647"
>    #define INT_MAXNEG_CHAR   "2147483648"
>    #define INT_MAXNEG_BIN    (-2147483647-1)
>    #define INT_MAXNEG_PACK   "\x02\x14\x74\x83\x64\x8D"
>    #define INT_MAXNEG_PACKL  (6)
>    #define UINT_MAXCHAR      (10)
>    #define UINT_MAXPOS_CHAR  "4294967295"
>    #elif INT_WIDTH == 8
>     ...
>    void
>    INT_BTD_NAME (INT_TYPE *  binary,
>               int         decimal_length_in_bytes,
>               void *      decimal_value,
>               INT_HANDLER ErrorRout)
>     ...
> 
> *  The same problems struct the test driver.  At the top of
>    test_decbin.c, there are some similar tests to define the test
>    data based on the current widths of INT64 and INT128.
> 
> *  A special note is needed here for the INT128 type, since there
>    is no support for it at this time in the gcc compiler, nor did
>    I find it in my ANSI C manuals, I could not find out what type
>    qualifier to place after the constants.  Once the compiler has
>    support for this, these lines will have to change.  See the
>    warnings at the top of the following two files and make the
>    described changes:
> 
>    cobr_decbxx.c
>    test_decbin.c
> 
> *  If this code is to execute on a machine that supports long as
>    an 8 byte value and/or long long as a 16 byte value, then you
>    will need to adjust file config.h.  See the warnings at the
>    top of that file.
> 
>                          Name: cobr_decbin.tar.gz
>    cobr_decbin.tar.gz    Type: Unix Tape Archive (application/x-tar)
>                      Encoding: base64

RE: [Cobolforgcc-devel] Runtime routines - confused

[William M. K. <wm...@ix...>]

Pardon me for "jumping it" (as I am now subscribed to this list).

A few comments included within (and some GENERAL comments at bottom)


> -----Original Message-----
 <snip>
>
> > >
> > > The "flags" field in the prototype for the cobr_display() routine was
> > > intended to pass arguments like trailing sign, and over punch.  This
> > > does present a small problem since it could imply an over punched sign
> > > for a binary type.  My books seem to indicate that only something with
> > > usage DISPLAY is permitted to use the "S" picture element.
>
> True so that some flag values would be invalid for some data
> types. You can either assume they are valid (so a pic x(n) would
> not even check the flag for leading overpunch), or check and
> abort() if inconsistent flags are used.

I haven't checked the '85 Standard yet, but this canNOT possibly be true (at
least in practice).
     PIC S(4) COMP (or BINARY)
is one of the most common data definitions that there is. Do you want me to find
a Standards reference to support this?

 <snip>

>
> > > On the other hand, if you are planing to add expanded functionality to
> > > the DISPLAY routine, then it would be better to keep the flag field.
> > > Perhaps special flags for languages, character sets, output to stderr
> > > instead of stdout.
>
> Yes, the number of possibilities can grow quickly. Although for
> display upon I would  probably have another routine with an extra
> parameter for the FILE*.

I assume that you are "planning" on allowing for DISPLAY to go to MULTIPLE
places.  For example in most of the current implementations you can do

   Display ... UPON CONSOLE
   DISPLAY ... UPON SYSOUT

in the same program (and they may well be "different" places (windows, or
whatever).

FYI,
  I assume that you know that the "UPON" phrase is SUPPOSED to be an "indirect"
reference to the place where output goes.  The relationship between this "name"
and the acutal place is put in the Special-Names clause.  However, almost (but
not quite all) vendors allow you to put the actual name in the DISPLAY (or
ACCEPT) statement.

  ***

General

Concerning PIC's with "S" and DISPLAY - are you aware that this is

A) an extension (but one that ALMOST all implementations allow)
B) not portable (with current implementations)

If you have

   05 NumField  Pic S99 Value -12.
        ...
   Display NumField

then,

IBM (mainframe, WinTel, and Unix) display *two* characters - with the last
character being the ALPHANUMERIC that has the same hex value as the single byte
for "-2".

On the other hand, MERANT display *three* characters "-12".  (Notice the
"switch" from sign-trailing to leading)

  ***

Again, concerning "S" and numeric fields.

Have you followed the debate on whether the following is or is NOT legal:

  05 NumField  Pic S999 Blank When Zero.

The problem beeing whether or not this is a numeric or numeric-edited field - or
not valid at all.  I beleive (but won't swear to it) that the committees (and
next Standard) have ended up saying that this is NOT valid.  However, the
following ARE valid.

  05 NumEdit1  Pic  99v99  Blank When Zero.
  05 NumEdit2  Pic  99ppp  Blank When Zero.

P.S.  That last raises the "question" of what you need to/should do with "P"
when doing a DISPLAY statement.

P.P.S. Another area for which there are multiple implementations is DISPLAY with
NO ADVANCING.

IBM returns to the beginning of the line - but "overwrites" it (no advancing).

MERANT (and most WinTel implementations) leave the "cursor" where it is so the
next Display FOLLOWS the last.

  ***

I hope this helps (and is appropriate input to this list)

Re: [Cobolforgcc-devel] Runtime routines - confused

[Tim J. <te...@me...>]

Tim Josling wrote:
> 
> (forewarded by Tim Josling from initial email by Ted Seward)
> 
> > If you wish to pass these questions by some other people, that will be
> > fine as well.  I realize that you have a busy schedule as well, and
> > might not see these until later in the week.  I'll do the following on
> > Wednesday if I haven't heard from you, and then adjust the code based on
> > your answers:
> >
> > 1.  The cobr_editMove() currently uses an enumerated type where the
> > various sign and length values are part of the data type.  I'll leave
> > that in for now, just so you can have a working piece of code.  If you
> > decide, based on the questions below, that you would prefer hard coded
> > bit flags, e.g. #define name 0x00800000, I'll replace the enumerated
> > types with the bit types.
> >

I prefer enumerations for the basic type, flags for variants (eg
'has leading overpunched sign'). This way you can avoid having
too many enumerations, I think. But if the number of variants is
not too bad you could dispense with the flags. You have probably
thought about this a lot more than me.

> > 2.  I'll pass the bit flags to the cobr_display() routine, translate
> > them to the enumerated types, and then call cobr_editMove() to do all
> > the editing with display to standard out.  This implies that a simulated
> > Picture will be generated based on the precision flag.
> >

OK just don't forget about variable length fields. The PIC needs
to be considerably shorter than the actual data in such a case.

01 x1.
  02 x2 pic x occurs 1 to 10000000 depending nbr1.
01 nbr1 pic 9(9).

> > Questions:
> >
> > Until I can figure out how to get that modem to work on Linux, which
> > seems to be a requirement to upload to CVS, where do I E-mail to?

See my other email. You have three alternatives.

a) email me
b) email the development list
c) submit a patch using the sourceforge patch manager. To do this
you need to register with SF and have me add your userid to the
project. This doesn't require linux. 

> >
> > Now the real questions:  I held off one last time sending you the
> > editMove, since I was hoping to standardize the flags used by
> > cobr_editMove() & cobr_display().  These questions are all related to
> > that.  Part of my concern is looking at 4000+ lines of code using an
> > enumerated type, and now bit flags show up in the display.  I would
> > stand up for the enumerated types, but I actually see a great deal of
> > merit in the bit flags.
> >
> > 1.  Did you want the flags defined as an enum type or individual
> > #defines?

#defines 

probably or maybe as bit fields (as long as you have less than 32
it will fit in an int).

unsigned int flag1:1;

As you point out it is pushing what enum means to use enums for
flags.

> >
> > The enumerated type is nice because it groups things together and
> > automatically generates the assigned enumerated types.  It lacks in the
> > fact that compiler differences do not guarantee an integer type nor does
> > it permit such things as OR'ing flags together.  Type conflicts can also
> > be a problem if a given compiler does not define the usage of enumerated
> > type as an integer, e.g. strict type checking my cause an error message
> > trying to pass the value when the argument is defined as integer.
> >
> > The #define type is nice, but does require values to be hard coded,
> > perhaps causing problems if a typographical error replicates a given
> > value.  It is easier to OR these values together and the compiler will
> > permit them to be handed to an integer type.  They are tricky to use in
> > a switch statement if someone does OR the values together.

enums and bit fields are nicer in the debugger which does not
know about #defines

> >
> > 2.  Is the "flags" argument in the cobr_display() intended only for sign
> > and over punch usage?

That's all I thought of so far. Maybe character set (ascii ebcdic
unicode (this would be a two bit 'flag'), maybe not.

> >
> > The "flags" field in the prototype for the cobr_display() routine was
> > intended to pass arguments like trailing sign, and over punch.  This
> > does present a small problem since it could imply an over punched sign
> > for a binary type.  My books seem to indicate that only something with
> > usage DISPLAY is permitted to use the "S" picture element.

True so that some flag values would be invalid for some data
types. You can either assume they are valid (so a pic x(n) would
not even check the flag for leading overpunch), or check and
abort() if inconsistent flags are used. 

> >
> > I'm wondering if the "type" argument should carry this value as well.
> > Instead of just having types like:  display, packed, binary, etc., the
> > display type would be expanded to 5 types including the 4 special signed
> > versions:  display, displayLead, displayLeadSep, etc.
> >

My only concern here is an explosion of types

eg 

ebcdic numeric overpunched leading sign
ascii numeric overpunched leading sign....
unicode numeric overpunched leading sign

If I has enums like this I would probably convert to a basic type
plus flags.

> > On the other hand, if you are planing to add expanded functionality to
> > the DISPLAY routine, then it would be better to keep the flag field.
> > Perhaps special flags for languages, character sets, output to stderr
> > instead of stdout.

Yes, the number of possibilities can grow quickly. Although for
display upon I would  probably have another routine with an extra
parameter for the FILE*.

> >
> > 3.  Should the same flags be used for cobr_editMove() and
> > cobr_display()?

Preferably.

> >
> > 4.  Should an optional picture clause be passed to cobr_display()?  The
> > idea here is to have cobr_display() call the cobr_editMove function to
> > do the editing.  Maybe pass an optional picture and it would be used in
> > the call to cobr_display(), otherwise it would generate a picture and
> > then call cobr_display().
> >

I would prefer display to do a basic generic format, no need for
a PIC to be passed to it. You can generate a PIC internally and
pass to editMove and thereby reuse that code - that would be a
good idea.

> > 5.  Ready for the Olympics?
> >

You do not want them enywhere near you. Thanks to the olympics I
am having to fly home via Hong Kong due to contention for
bookings. All the con men descend upon your country, etc. 

General Comment
***************

We will no doubt rework this code a few times so it is probably
better to get it going 'reaonably well' and not worry too much
about getting it perfect first time. The open source model is
that antithesis of 'big design up front' - we will approach the
target in increments. I have rewritten parts of the compiler
several times.

Within reason of course. But there is probably lots of stuff we
don't know about - just do what makes sense for what we know
about and we will cross the other bridges when we come to them.

The compiler is not putting anything into the flags so far so in
no sense am I locked into using them.


Tim Josling

[Cobolforgcc-devel] Runtime routines - confused

[Tim J. <te...@me...>]

(forewarded by Tim Josling from initial email by Ted Seward)

> If you wish to pass these questions by some other people, that will be
> fine as well.  I realize that you have a busy schedule as well, and
> might not see these until later in the week.  I'll do the following on
> Wednesday if I haven't heard from you, and then adjust the code based on
> your answers:
> 
> 1.  The cobr_editMove() currently uses an enumerated type where the
> various sign and length values are part of the data type.  I'll leave
> that in for now, just so you can have a working piece of code.  If you
> decide, based on the questions below, that you would prefer hard coded
> bit flags, e.g. #define name 0x00800000, I'll replace the enumerated
> types with the bit types.
> 
> 2.  I'll pass the bit flags to the cobr_display() routine, translate
> them to the enumerated types, and then call cobr_editMove() to do all
> the editing with display to standard out.  This implies that a simulated
> Picture will be generated based on the precision flag.
> 
> Questions:
> 
> Until I can figure out how to get that modem to work on Linux, which
> seems to be a requirement to upload to CVS, where do I E-mail to?
> 
> Now the real questions:  I held off one last time sending you the
> editMove, since I was hoping to standardize the flags used by
> cobr_editMove() & cobr_display().  These questions are all related to
> that.  Part of my concern is looking at 4000+ lines of code using an
> enumerated type, and now bit flags show up in the display.  I would
> stand up for the enumerated types, but I actually see a great deal of
> merit in the bit flags.
> 
> 1.  Did you want the flags defined as an enum type or individual
> #defines?
> 
> The enumerated type is nice because it groups things together and
> automatically generates the assigned enumerated types.  It lacks in the
> fact that compiler differences do not guarantee an integer type nor does
> it permit such things as OR'ing flags together.  Type conflicts can also
> be a problem if a given compiler does not define the usage of enumerated
> type as an integer, e.g. strict type checking my cause an error message
> trying to pass the value when the argument is defined as integer.
> 
> The #define type is nice, but does require values to be hard coded,
> perhaps causing problems if a typographical error replicates a given
> value.  It is easier to OR these values together and the compiler will
> permit them to be handed to an integer type.  They are tricky to use in
> a switch statement if someone does OR the values together.
> 
> 2.  Is the "flags" argument in the cobr_display() intended only for sign
> and over punch usage?
> 
> The "flags" field in the prototype for the cobr_display() routine was
> intended to pass arguments like trailing sign, and over punch.  This
> does present a small problem since it could imply an over punched sign
> for a binary type.  My books seem to indicate that only something with
> usage DISPLAY is permitted to use the "S" picture element.
> 
> I'm wondering if the "type" argument should carry this value as well.
> Instead of just having types like:  display, packed, binary, etc., the
> display type would be expanded to 5 types including the 4 special signed
> versions:  display, displayLead, displayLeadSep, etc.
> 
> On the other hand, if you are planing to add expanded functionality to
> the DISPLAY routine, then it would be better to keep the flag field.
> Perhaps special flags for languages, character sets, output to stderr
> instead of stdout.
> 
> 3.  Should the same flags be used for cobr_editMove() and
> cobr_display()?
> 
> 4.  Should an optional picture clause be passed to cobr_display()?  The
> idea here is to have cobr_display() call the cobr_editMove function to
> do the editing.  Maybe pass an optional picture and it would be used in
> the call to cobr_display(), otherwise it would generate a picture and
> then call cobr_display().
> 
> 5.  Ready for the Olympics?
> 
> Thanks Much - Ted Seward

[Cobolforgcc-devel] FYI - Of Possible Interest to those following the COBOL Standardization effort

[William M. K. <wm...@ix...>]

I thought that some of you who "follow" COBOL Standards might be interested in
the "Convener's Report" for the upcoming SC22 meeting. Sorry if some of you get
multiple copies of this - or have already seen it.  If you have any "concerns"
that you think should be dealt with related to this report, the ONLY way to get
them conveyed is via your "National Standards Body".

To find out "who is" and "how to contact" your individual "National Standards
Body", see

  http://www.iso.ch/addresse/membodies.html


Full text follows:

"Business Plan and Convener's Report
JTC1/SC22/WG4 - Programming Language COBOL

August 1, 2000

Period Covered:
September 1999 - August 2000

Submitted by:
Ann Bennett
Convenor, ISO/IEC JTC 1/SC 22/WG 4
 <snip>

1.    Management Summary
1.1    JTC1/SC22/WG4 Statement of Scope
Development and maintenance of ISO/IEC standards related to programming language
COBOL.

1.2    Project Report
1.2.1    Completed Projects
None in this period.

1.2.2    Projects Underway
22.01.07 Revision of ISO 1989:1985 --
The revision provides major new features, including: cultural adaptability,
large character set support, object orientation, condition handling, new
data-types (bit, floating point, native binary), portable arithmetic,
conditional compilation, user-defined functions, file sharing/record locking,
and improved interoperability with other programming languages.

Combined CD registration and CD ballots N2260 closed in January 1997. The
summary of voting is contained in N2382. WG4 responded to comments in N2616.
Development of changes in response to specific technical comments was completed
in 1998. Three national bodies requested that the document be improved in
quality. In response, WG4 held an internal quality review in 1999, which
resulted in substantial rework and the need for further internal review. That
review completed in May 2000 and associated rework is is progress. WG4 intends
to forward a document for Final CD ballot in February 2001.

1.2.3     Cancelled Projects
None

1.3    Cooperation and Competition
WG4 cooperates closely with NCITS COBOL Technical Committee J4, to whom SC22 has
delegated the technical development and maintenance of COBOL.

WG4 has liaisons with the following groups:

	SC22/WG20 - Ann Bennett
	SC22/WG11 - Don Nelson

2.    Period Review
2.1     Market Requirements
COBOL continues to be widely used for development and for enhancement and
re-engineering of existing applications. Many factors drive the market for COBOL
standardization:

Technology advances and the resulting spread of computers to end users makes it
mandatory that computer systems adapt to the languages of users. This gives rise
to a need in COBOL for support of large character sets and cultural
adaptibility. The current draft includes substantial support for large character
sets and cultural adaptability.

The trend in the industry is to web-enable COBOL applications, with COBOL
running on a server interacting with a non-COBOL user interface. This gives rise
to the need for enhanced interoperability with other programming languages and
system services. A variety of new datatypes, user-defined functions, and call
enhancements are provided in the current draft to support interoperability.

Market pressure for new technology led COBOL vendors to cooperate on
object-oriented design through the standardization process. Early
implementations of the object-oriented features in the draft are now available
and users are designing them into new applications.

Deployment of applications across workstations and distributed environments and
the growth of COBOL in Unix environments generated requirements for new features
in the language. These needs were met by implementor extensions to the language,
in different ways by different implementors, leading to a need for
post-implementation standardization. Many of these extensions are included in
the draft.

Growth of COBOL in the Unix market led X/Open (now Open Group) to develop a
Common Application Environment (CAE) providing a portable definition of features
essential in a Unix environment, but lacking in standard COBOL. The need for
portability with non-Unix platforms has resulted the inclusion of some of these
features in the draft.

The impact of year 2000 date handling generated a requirement for portable
year-2000 features; these are included in the draft and have been implemented.
Their utility extends beyond the year-2000 conversion requirements.

The current draft addresses many of the market requirements for COBOL, but not
all of them. Continued evolution of the international standard for COBOL is
essential to provide the benefits of new technologies and new environments to
COBOL users worldwide.

2.2     Achievements
WG4 completed technical work to address CD comments and comments in a subsequent
internal quality review. Corrections resulting from that review are in progress.

2.3     Resources
WG4 meets as needed, usually once a year, and works by electronic correspondence
between meetings. Five countries are participating in meetings: Germany, Japan,
The Netherlands, the UK, and the USA.

Detailed technical development is delegated to NCITS J4. J4 has 13 members
participating in detailed technical development - - 6 COBOL vendor organizations
and 7 user organizations.

3.     Focus Next Work Period
WG4 will focus on quality and preparing the draft for Final CD ballot.

3.1     Deliverables
WG4 anticipates delivering a document for FCD ballot in the first quarter of
2001.

3.2     Strategies
Focus on progression of the draft to FCD ballot.

3.2.1     Risks
In order to support extended identifiers, WG4 is dependent on a normative
specification of character attributes, particularly upper and lower case
equivalents. WG4 has been planning to reference WG20's TR 14652. Certain issues
with respect to case folding need to be resolved to avoid divergence of
approaches across programming languages.

3.2.2     Opportunities
None

3.3     Work Program Priorities
WG4's highest priority is preparation of the draft for Final CD ballot. The next
priorities are development of a technical report for a finalizer feature,
development of a technical report for an object-oriented class library, and
processing of defect reports - in that order.

4.     Other Items
This section includes items that are part of the Converner's report, but not
part of the Business Plan.

4.1     Action Requests at the Forthcoming Plenary
WG4 requests that SC22 authorize development of a technical report for a
finalizer method and associated object-oriented language.

A quality review comment noted a deficiency in object-oriented design because
there was no feature for finalizing an object before garbage collection. Efforts
to design a finalizer method failed for lack of design consensus and concerns
that the technology is not yet stable. WG4 therefore proposes that a finalizer
method and any associated O-O language features be developed in a Technical
Report. WG4 requests that SC22 approve a subdivision of the COBOL work item for
development of that TR.

The following draft resolution is proposed:

ISO/IEC JTC 1/SC 22
authorizes a subdivision of the COBOL work item for development of a technical
report for a finalizer method and associated object-oriented language elements,
and delegates the technical development to NCITS J4.

The WG4 convener requests that SC22 allocate time for a working session to
identify issues and anomalies in case folding and determine a consistent
approach across program languages, where appropriate.

4.2     Schedule
The schedule for project 22.01.07 is as follows:

	Final CD start  February 2001
	DIS start June 2002
	Forward IS to ITTF December 2002

4.3     WG4 Meetings
4.3.1     Recent Meetings
May 2000, Newbury, UK     (co-located with an NCITS J4 meeting)

4.3.2     Future Meetings
November 2001,     tentatively USA (to be co-located with an NCITS J4 meeting)
  "

[Cobolforgcc-devel] cobol.el

[Matthew V. <lin...@ho...>]

I checked in a new revision of cobol.el.  Highlights are:

 - Redefined comment-line-start-skip from nil to "^......\\*"
 - Added (define-key cobol-mode-map "\t" 'cobol-indent-line)
 - Redefined is-a-comment from "      \\*" to "^ *\\*"
 - Fixed a typo in the calculate-cobol-indent function--extra 
   parentheses

Basically fixed an irritation with the TAB key.  If there are no
objections, I'm going to leave it the way it is--in order to properly
indent a line, you must go to beginning of line and TAB--if you are in
the middle of a line, or if you just indented by above procedure, TAB
will tab 4 spaces.  Since I use TAB a lot (it being quicker and more
accurate than the spacebar), I decided to leave it's behavior alone. 
It's the simple things that make coding fun. ;)

Two projects remain--making some COBOL abbrevs, and trying to find a
better way to do syntax highlighting than regexp.

Work progresses on the FILE front.  Slowly, to be sure, but this week I
start another position at work that will afford a little more free time.

ciao,
-- 
Matthew Vanecek
perl -e 'print
$i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
********************************************************************************
For 93 million miles, there is nothing between the sun and my shadow
except me.
I'm always getting in the way of something...

[Cobolforgcc-devel] Re: Can't get cvs co going

[Aldy H. <al...@re...>]

>>>>> "Tim" == Tim Josling <te...@me...> writes:

 > Aldy,
 > Try
 > $ cvs co .
 > I tried it and it works.
 > Also for anyone else trying it, the anonymous password is
 > 'nothing' ie just hit return when it asks for the password.

You should probably put all this in the project web page.

Aldy

[Cobolforgcc-devel] Re: Can't get cvs co going

[Aldy H. <al...@cy...>]

>>>>> "Tim" == Tim Josling <te...@me...> writes:

 > Aldy,
 > Try
 > $ cvs co .
 > I tried it and it works.
 > Also for anyone else trying it, the anonymous password is
 > 'nothing' ie just hit return when it asks for the password.

Ahhh, voila.

Thanks.

Aldy

[Cobolforgcc-devel] Re: Can't get cvs co going

[Tim J. <te...@me...>]

Aldy,

Try
$ cvs co .
I tried it and it works.
Also for anyone else trying it, the anonymous password is
'nothing' ie just hit return when it asks for the password.

Tim Josling

Aldy Hernandez wrote:
> 
> hello folks.
> 
> I've unsuccesfully tried to check out the sources from CVS:
> 
> vieques:~/t$ export CVSROOT=:pserver:ano...@cv...:/cvsroot/CobolForGCC
> vieques:~/t$ cvs login
> (Logging in to ano...@cv...)
> CVS password:
> vieques:~/t$ cvs co CobolForGCC
> cvs server: cannot find module `CobolForGCC' - ignored
> cvs [checkout aborted]: cannot expand modules
> vieques:~/t$ cvs co -c
> 
> What is the name of the module name?  I can't get a module listing
> with "cvs co -c".
> 
> Hints?
> 
> Aldy

Re: [Cobolforgcc-devel] Re: gnubol: which list, and cobol.el

[Aldy H. <al...@re...>]

hello folks.

I've unsuccesfully tried to check out the sources from CVS:

vieques:~/t$ export CVSROOT=:pserver:ano...@cv...:/cvsroot/CobolForGCC
vieques:~/t$ cvs login
(Logging in to ano...@cv...)
CVS password: 
vieques:~/t$ cvs co CobolForGCC
cvs server: cannot find module `CobolForGCC' - ignored
cvs [checkout aborted]: cannot expand modules
vieques:~/t$ cvs co -c

What is the name of the module name?  I can't get a module listing
with "cvs co -c".

Hints?

Aldy

Re: [Cobolforgcc-devel] Re: gnubol: which list, and cobol.el

[Tim J. <te...@me...>]

Abbrevs
*******

I didn't realize the abbrevs weren't implemented. Maybe just put
a comment in about this.

I would like the common statement starting verbs like GO TO (just
kidding), MOVE, PERFORM, COMPUTE, ADD/SUBTRACT/MULTIPLY/DIVIDE,
IF and the respective END-Xs, maybe also something for data
division like $n -> 0n xxx PIC X(1) USAGE DISPLAY, EXIT
PROCEDURE, DISPLAY, STOP RUN.

Two Projects
*************

Yes I do want to maintain COBOL For GCC and GNU COBOL2C as two
separate projects. This is dues to the different approaches taken
by the two projects:

- Use GCC back end vs generating C code.
- Extreme programming (testing) used in COBOL4GCC
- Stricter approach to standards on COBOL4GCC
- Using Source Forge - Source forge offers a really good
infrastructure for running an open source project

GNU COBOL2C has been inactive for some time. But it is not for me
to say that the project is over. It has achieved a lot especially
in terms of getting the parsing issues resolved, but nothing has
been happening for a while. 

My hope is that it will work like this. People will join
COBOL4GCC and contribute code, tests and documentation. We will
have a viable COBOL subset soon, to allow COBOL programmers to
contribute to the project. As momentum grows, more and more
developers and users join in. Soon we have it all done. We
leverage the experiences of the earlier free COBOL projects
(cobcy, cobol2c) and share code with Tiny COBOL (this is possible
especially in the complex runtime such as sort/merge - I'd love
to write that but I need to concentrate in the parsing and GCC
interface).

In 17 months COBOL4GCC has accumulated 39,000 lines of code
(6,000 lines of Ted Seward's code are not checked in yet), far
more than any other free COBOL project. I know that LOC is an
imperfect measure, but if you use the same language and have
similar levels of documentation and use similarly skilled
programmers it is a fair comparison. While functionally it is a
baby, the 39,000 lines represent all the hard problems solved. So
we can move forward at a rapid rate from this sound base. 

I would urge anyone wishing to contribute to register themselves
to www.sourceforge.net and let me know your ID, then I can put
you in the project and we can track tasks and bugs etc, and give
you CVS write access in due course.

Tim Josling


Matthew Vanecek wrote:
> 
> Duly noted.  abbrevs were never implemented--I guess the original
> developer never got to it.  I will, soon.  The thing to decide is,
> what's important enough to include as an abbrev?  Consider opinions
> solicited...

> Are you wanting to maintain gnu-cobol and cobolforgcc as two seperate
> projects?  How's that gonna work?

> Matthew Vanecek

[Cobolforgcc-devel] Re: gnubol: which list, and cobol.el

[Matthew V. <lin...@ho...>]

Tim Josling wrote:
> 
> They are both official, for different projects.
> 
> By the way, an easy upgrade for the cobol.el would be to put some
> cobol-esque abbrevs in it.
> 
> Tim Josling
> 
> Matthew Vanecek wrote:
> >
> > Which is the official list nowadays? :)  Good to have a home.  I've had
> > a temporary position change at work (going to do 2nd tier support for a
> > while--blech!), so I think I'll have a little more time to devote to
> > coding.
> >
> > Matthew Vanecek

Duly noted.  abbrevs were never implemented--I guess the original
developer never got to it.  I will, soon.  The thing to decide is,
what's important enough to include as an abbrev?  Consider opinions
solicited...

Are you wanting to maintain gnu-cobol and cobolforgcc as two seperate
projects?  How's that gonna work?

-- 
Matthew Vanecek
perl -e 'print
$i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
********************************************************************************
For 93 million miles, there is nothing between the sun and my shadow
except me.
I'm always getting in the way of something...

[Cobolforgcc-devel] Version 0.1.2 Released

[Tim J. <te...@me...>]

The generated code now has file and line numbers for the
debugger. Also upgraded the sample apps to work with the 7 August
GCC snapshot. Matthew now has a bug report to fix. Lots of code
from Ted 'the coding machine' Seward for numeric handling. Added
consistent version numbers across all the executables. Lots of
tweaks to the documentation.
Tim Josling